howtos

Vamos a empezar por lo más fácil: Cuando. La respuesta es muy simple: ahora

El mejor momento para liberar cualquier contenido, sea código, sea código con un informe explicativo o trabajo científico, siempre es ahora. Si lo que deseas es que su trabajo se conozca y también beneficiar a la comunidad que te ha dado financiación o simplemente apoyo, es mejor hacerlo desde el principio, desde la primera línea de código de un fichero README. El hacerlo ahora manda un mensaje claro: estoy abierto a cualquier sugerencia, y cualquiera puede copiar y mejorar mi trabajo en cualquier estadio de su desarrollo; también podéis sugerir cambios o mejoras y hacerlo durante el desarrollo del mismo, no al final cuando ni yo me puedo beneficiar ni posiblemente nadie porque la cantidad de información, código más informe, sea demasiado apabullante para que le sirva a nadie. Estamos en el mes de abril y te quedarán dos meses, quizás cinco si es en septiembre. Abre tu repositorio ya. Y si vas a empezarlo próximamente, crea el repositorio en abierto desde el principio y trabaja con él. Habla con tu tutor para que interaccione contigo también en abierto y a través del repositorio. Y, por supuesto, la liberación es un camino de dos vías. Si algún compañero tuyo también lo ha liberado, ayúdale, échale una mano, comprueba el código, hazle pull request. Nada más transparente que un repositorio para saber quién ha hecho qué.

Y el hecho de que se sepa que ese trabajo lo has hecho tú es precisamente uno de los porqués, el más importante. Las empresas usan tu repositorio como un currículum vitae, hasta el punto de que hay empresas que se dedican exclusivamente a hacer data mining de GitHub buscando a personas que tengan un perfil determinado, reflejado en lo que tienen publicado en GitHub. Seguramente estés usando una tecnología interesante en tu TFG/TFM/tesis que tenga demanda en el mercado. Ten por seguro que alguien lo va a ver, o que lo va a tener presente en la entrevista de trabajo para publicarlo o no. Git y GitHub es la herramienta que tienen en común todas las empresas y el hecho de que demuestres que lo conoces y lo usas también va a contar a tu favor.

Y finalmente, eso nos da el dónde. Hoy en día el sitio para liberar proyectos es GitHub. Las facilidades sociales y de gestión de proyectos que tienen no tienen ahora mismo igual. Aunque hay otros repositorios gratuitos como BitBucket o GitLab, este incluso libre, lo cierto es que tener un proyecto en un sitio popular como GitHub facilita su visilibidad y también que se interacciones con el resto de los programadores. Además, es el que se utiliza en ránkings provinciales como el de Israel Blancas; aparecer en ese ránking va a permitir también que conozcan tu trabajo y eventualmente que te den uno, que es de lo que se trata.

Nos queda un como. Liberar un trabajo es simplemente cuestión de asignarle una licencia. Y asignarle una licencia es tan fácil como colocar un fichero que se llame LICENSE en el directorio principal, que contenga los términos de la licencia; también se debe añadir una referencia a esa licencia en las cabeceras de todos los ficheros. Por ejemplo, Synapse de Marco Fernández Pranno (un proyecto liberado ya y que se leerá próximamente) tiene licencia MIT. Por otro lado, el texto en sí suele tener licencias Creative Commons, licencias específicas para contenido, como la tesis de Pablo García Sánchez, por ejemplo, que también se liberó desde el principio. Para no mezclar licencias el texto suele ir o en otro directorio o directamente en otro repositorio, aunque no pasa nada para que vayan juntos.

Practica también la ciencia abierta. Si tu tesis tiene un componente de investigación, habrás hecho experimentos, tendrás ficheros de configuración, una bitácora de resultados, los datos. Eso también se puede, y se debe, liberar. Puedes ir publicando los datos y subiéndolos a Figshare o algún otro sitio que te permita asignarle un URL permanente y también citarlo como si de un trabajo se tratara. Esto se escapa de la temática estricta de esta historia, pero puedes informarte en esta presentación y esta otra que explica los conceptos y las herramientas que se pueden usar.

¿A qué esperas pues para liberar tu TFM? Recuerda que el mejor momento siempre es ahora, y si necesitas ayuda y asesoramiento por parte de la Oficina de Software Libre, ya sabes donde encontrarnos.

Bios Chip

Algo que siempre se ha asociado al sistema operativo Windows es, entre otras cosas, la actualización de la Bios.

Cuando adquirí mi portátil lo primero que hice, antes de eliminar Windows, fue actualizar todo lo actualizable desde ese sistema. Después ya instale Ubuntu 15.04 o la 15.10 con Gnome.

Pues bien, el tema esta en que una vez que la versión 16.04 ya paso a estable me salían un par de errores referentes a Intel, decir que mi portátil es un Think Pad X1 Carbon de 3ª generación con un Intel Core i7-5600U CPU @ 2.60GHz x 4 y que tiene menos de 1 año desde que lo compre.  Decir también que funciona extraordinariamente bajo GNU/Linux y no hay nada que envidiar a otros sistemas operativos ni Hardware existentes en el mercado., pues bien, estuve buscando soluciones en la red y también expuse lo que me sucedía en Launchpad y foros especializados en GNU/Linux. Mi pequeña obsesión por tener siempre lo último, o lo más actualizado posible, me llevo a encontrar un tutorial sobre como actualizar la Bios desde GNU/Linux, cosa rara, ya que normalmente es algo peliagudo de realizar y ya no digamos desde cualquier distribución GNU/Linux.

Este tutorial dice lo siguiente:

Entrar en la web de Lenovo para descargar el archivo más reciente de nuestro modelo de portátil.

Descargar el archivo ISO más reciente, nombrado como Bios Update (Bootable CD)

Convertir ese archivo ISO en un .img con la utilidad geteltorito, si no la tienes instalar con un simple:

sudo apt install genisoimage

ejemplo del comando para crear el bios.img:

geteltorito -o bios.img n14ur11w.iso

Insertar una memoria USB, teniendo en cuenta que el .img que generamos no pesa más de 40 o 50 MB.

Comprobar muy bien donde nos monta el USB para crear con él un booteable con el bios.img, por ejemplo yo lo llevaba en Descargas:

cd Descargas

Con el comando dd realizamos el proceso:

dd if=bios.img of=/dev/sdb bs=1M

Reiniciamos el portátil y con F12 booteamos.

Yo tuve que entrar en la Bios y volver a activar el Secure boot y cambiar al modo UEFI desde Legacy mode, ya que he preferido tenerlo así. Además es una tontería mantener una Bios con estos sistemas de control por parte de Windows.
Si no cambiamos estos valores nos nos dejará bootear y por tanto actualizar la Bios.

bios7

Una vez cambiando y guardado volvemos a reiniciar y entrar con el USB. Se nos abrirá un menú con 3 sub-menús.

Dejar el USB hasta después del reinicio que es cuando se actualizará la BIOS, de hecho yo no lo quite hasta cambiar de nuevo la BIOS al modo Legacy y estar ya en mi flamante Ubuntu 16.04 con Gnome.

La versión que tenía de la Bios era la 1.10:

sudo dmidecode -s bios-version sudo dmidecode -s bios-release-date
N14ET32W (1.10 )
08/13/2015

Y ahora llevo la última 1.12, pero ha habido como 4 versiones intermedias entre una y otra:

sudo dmidecode -s bios-version sudo dmidecode -s bios-release-date
N14ET34W (1.12 )
02/04/2016

Feliz flasheo y leer siempre, siempre los Readme.

En ocasiones, necesitamos tener varios entornos de trabajo distintos, con distintas versiones del intérprete, distintas librerías, etc.

Una de las soluciones más comunes es usar varios ordenadores o varias máquinas virtuales, cada una con una instalación diferente.

Pero Python nos provee de una herramienta simple y útil para facilitarnos ese trabajo, sin necesidad de recurrir a soluciones más complicadas. Esta herramienta es “virtualenv”.

virtualenv es un programa que permite crear entornos virtuales de Python. Un entorno virtual consta de un intérprete (podemos elegir la versión concreta) acompañado de todos los módulos que necesitemos instalar. Se pueden tener varios entornos distintos, instalando en cada uno los módulos que necesitemos, sin que unos entornos afecten a los otros.

Vamos a verlo de forma práctica.

Para empezar, necesitamos instalar la propia aplicación virtualenv. Esto se puede hacer desde el gestor de paquetes de tu distribución (apt-get, emerge, yum, pacman…) o, de manera más general, con pip (en cualquier caso, hacen falta permisos de superusuario):

pip install virtualenv

Tras esto, ya tendremos el programa instalado y podemos comenzar a usarlo.

En Python 3 nos podemos ahorrar el paso de la instalación, porque ya viene por defecto.

virtualenv guarda cada entorno virtual en un directorio con el nombre de ese entorno. Dentro de ese directorio se guardarán todos los archivos necesarios (de ellos nos interesan, en particular, los módulos que instalemos en el entorno y el script que lo inicia).

Es una buena idea tener en tu home un directorio donde agruparemos todos los entornos virtuales. En mi caso, en una escandalosa falta de originalidad, ese directorio se llama “virtualenvs”.

Crear un entorno virtual es muy simple, del siguiente modo:

virtualenv DIRECTORIO-DEL-ENTORNO-VIRTUAL

Por ejemplo:

virtualenv nuevo-entorno

O, en mi caso, que estoy usando ese directorio llamado virtualenvs que ya he comentado para agrupar todos mis entornos:

virtualenv virtualenvs/nuevo-entorno

Al hacerse en espacio del usuario, ni la creación de un entorno virtual ni (como veremos más adelante) la instalación de paquetes en él, necesitan permisos especiales.

Esto crea el nuevo entrono en el directorio que le hemos indicado, creando en él una estructura de directorios, copiando allí el ejecutable de Python y otros archivos necesarios, e incluyendo algunos módulos por defecto (en realidad, la mayoría de ellos son enlaces simbólicos a los originales, a menos que usemos la opción –always-copy, que cambia este comportamiento).

Para que virtualenv nos dé más detalles durante la creación de nuestro entorno, podemos usar la opción –vervose (o -v en su versión corta):

virtualenv --vervose virtualenvs/nuevo-entorno

Si necesitamos que nuestro entorno virtual ejecute una versión concreta del intérprete de Python (que, lógicamente, debemos tener instalada en nuestro sistema), podemos indicarlo con la opción -p de este modo:

virtualenv -p /usr/bin/python3.5 virtualenvs/nuevo-entorno

Si no se indica la opción -p, se usará el intérprete en /usr/bin/python.

Una vez creado nuestro entorno virtual, necesitamos activarlo para poder usarlo. Para ello vamos a usar uno de los scripts que se han instalado por defecto al crearlo. El script necesario es activate, y se encuentra en el directorio bin que se ha creado dentro del de nuestro entrono virtual:

source mis-virtualenvs/mi-entorno-virtual/bin/activate

La orden source se encarga de ejecutar en la sesión de shell actual el script que se le pasa como parámetro (es decir, que el efecto es el mismo que si el usuario tecleara esas instrucciones en su consola) en lugar de en su propia shell, como se ejecutan normalmente los scripts.

Al hacer esto, el prompt de shell cambiará para indicar que se ha activado el entorno virtual, poniendo el nombre de este delante del prompt habitual, de un modo parecido a este:

(nuevo-entorno) usuario@host:~ 

A partir de este momento cualquier comando o script de python que se ejecute lo hará en el entorno virtual. Y, lo que es más importante, cualquier módulo que se instale (con pip, no con el gestor de paquetes del sistema) lo hará también en el entorno virtual y no afectará ni al resto de entornos virtuales que podamos tener, ni a la instalación de Python del sistema.

Naturalmente, esto se aplica sólo a la sesión en la que se ha activado el entorno virtual. Si abrimos otra sesión en otro terminal, por ejemplo, esa sesión tendrá el entorno de Python normal de nuestro sistema. Por supuesto, se pueden tener varios entornos virtuales distintos corriendo simultáneamente en diferentes sesiones sin ningún problema.

El comando deactivate desactivará el entorno virtual, volviendo al entorno normal:

deactivate

Cualquier módulo que se haya instalado en el entorno virtual se “desvanecerá” como si nunca hubiese estado ahí, hasta que se active de nuevo el mismo entorno virtual.

Para eliminar un entorno virtual que no queramos volver a usar, sólo es necesario borrar el directorio de su mismo su nombre con todo su contenido.

virtualenv es una herramienta muy útil que tiene otros usos más allá de lo que se comenta en este artículo. Se pueden ver más opciones de este programa en su propia ayuda:

virtualenv --help

¿Te interesa? Este artículo se ha escrito como parte del curso virtual Introducción al lenguaje de programación Python que se iniciará el próximo 24 de octubre. ¡Aún quedan plazas libres!

HITACHI STARTBOARD DRIVER

pizarra

Fotos: Makova

pizarra1

 

Hace unos días nos encontramos con el problema de que GNU/Linux, más concretamente Ubuntu de 64 bits, no funciona con la pizarra electrónica Hitachi StarBoard que están instaladas en las aulas del edificio CEVUG.

Después de realizar varios intentos con distintas versiones de driver de su página oficial no conseguíamos que funcionará. Al día siguiente y después de realizar una búsqueda más exhaustiva encontramos un tutorial en GitHub del que me atreví, a parte de seguirlo con éxito, de actualizar al castellano en mi repositorio Makova GitHub .El repositorio y tutorial original viene como un script en Bash para su instalación, algo que yo cambié para hacerlo de línea en línea de ejecución en una terminal.

hitachi1

Una vez instalado y configurado todo, recordar que hay que cargar el módulo cómo se indica en el turorial, ya que al principio no conseguíamos conectarlo y por tanto no se podía utilizar como tal.

Al instalar los driver para esta pizarra electrónica instalará un configurador para calibrar la pizarra que sólo funcionará cuando ya se este conectado a la pizarra.

Recordar también que todo estos pasos se han realizado para la instalación en una arquitectura de 64 bits en GNU/Linux y en Ubuntu 16.04 y Ubuntu 14.04, aunque probablemente funcione en otras distribuciones como Debian o Linux MInt. Supongo que si la distribución ya es de 32 bits se puede seguir el mismo tutorial pero obiando las librerías de 32 bits del comienzo del tuto.

Si no saliese el indicador en la barra superior para realizar la conexión habrá que instalar el siguiente paquete:

sudo apt update
sudo apt install libappindicator1

hitachi2

Bueno, espero que con este mini-tutorail disfruten de estas excelentes pizarras electrónicas.

Saludos.

 

¿Por qué Ubuntu?

Pues después de haber instalado otras distribuciones GNU/Linux como Linux Mint, ArchLinux, Debian, Fedora, etc. Personalmente he llegado a la conclusión, ojo que es mi conclusión y no por ella quisiera entrar en debates o discusiones sobre cuál es mejor o peor, que Ubuntu es fácil de instalar con soporte LTS durante 5 años, que con fácil no debe interpretarse como instalación a la windosera de siguiente, siguiente, sino más bien, que para el usuario que jamás ha probado o instalado o no sabe que es GNU/Linux, le sea una tarea sencilla y tremendamente documentada en tutoriales que abundan con una simple búsqueda por la Internet. Todo ello sin meternos en redimensionar el disco duro HDD o SSD, ya que la función que lleva incorporada para facilitar la instalación deja alojarse junto a Windows 7, 8 y 10 y es compatible con los sistemas de seguridad que trae el propio Windows en la BIOS, cómo EFI y UEFI, Ubuntu soporta UEFI desde hace algunas versiones a través del Secure Boot System oficial de Microsoft para Linux.

Una vez instalada o en su defecto iniciada desde un DVD o USB Live se puede comprobar que lleva de todo lo necesario para su utilización, desde navegador, editor de texto, lector de pdf, suite ofimática, editor de imágenes, programas para escuchar y editar música o vídeo, seguridad y sobre todo y ante todo, sencillez, estabilidad y seguridad.

Además de todo lo necesario para funcionar desde el primer momento se pueden instalar otra serie de programas y/o aplicaciones, ya sea desde el nuevo Centro de Software o Software on-line

Synaptic 

o en búsquedas por la red, eso sí, siempre acompañadas de las palabras Ubuntu o Linux, ejemplo:

obteniéndose resultados específicamente para nuestra distribución y sistema operativo, digo nuestra ya que espero qué, por lo menos, al leer este articulo se animen a probarla y dejen sus impresiones en los comentarios.

También estamos todas las mañanas en el edificio del CEVUG, primera planta de la calle Real de Cartuja 36-38, para que puedan venir a instalar, probar, configurar y aprender lo que es el Software y Hardware Libre. A parte, esta la gran comunidad dispuesta en todo momento a ayudar con tutoriales, foros, listas de correo y web especializadas, totalmente altruista.

En fin, que prueben y comparen, que bicheen lo que se les ofrece de manera free para poder hablar con propiedad sobre lo que últimamente esta en boca de todos, ser un poco más libre y sobre todo no dejen que tomen el control de sus equipos informáticos y hasta de su privacidad.

Saludos.

 

Acaba de ser actualizada la versión 2.9.4 después de casi un año sin actualizaciones de este excelente editor de imágenes, GIMP. Yo acabo de actualizarlo vía repositorios en Ubuntu 16.04 y aparece como versión 2.9.3 aunque si lleva las mejoras, tanto visuales en la interfaz de usuario como nuevas funcionalidades y usabilidad en los menús.

Nuevo_Gimp

Cabe destacar en la parte visual que podemos cambiar tanto el tema general y el de iconos

gimp-2-9-4-themes

temas_Gimp

iconos_gimp

Gestión de mejoras en el color, realizándose una revisión completa. Se ha añadido una capa de abstracción que hace menos dependiente GIMP de LittleCMS.

Depuración de código e introducir una aplicación limpia de la gestión de color para varios bits de GIMP como: vistas previas de muestras de color y gradientes, patrones, varios widgets de color (incluyendo la de arrastrar y soltar widget de color), la herramienta Selector de color, capa y la imagen de vista previa, etc.  El único bit no administrado por el momento es el widget de color en los script-Fu y Python-Fu plug-ins. Por otra parte, GIMP hará un seguimiento que controlan el widget se encuentra actualmente en (diferentes monitores tendrían diferentes perfiles ICC que se les asignan) y corregir el color en consecuencia.

Todos los trabajos en los iconos de Klaus Staedtler se hace en las imágenes vectoriales (SVG), lo que debería permitir un mejor soporte para pantallas HiDPI (también conocido comúnmente como Retina en los “maqueros”) en poco tiempo.

Todas los cambios se pueden ver en el siguiente enlace: GIMP 2.9.4 RELEASED

más que nada por el pésimo Inglés que manejo, aunque el traductor de Google no es que sea la para tirar flowers 🙂 . En fin, para actualizar a está nueva versión por repositorios de Launchpad se ha de añadir lo siguiente en una terminal Linux:


sudo add-apt-repository ppa:otto-kesselgulasch/gimp

sudo apt update && sudo apt upgrade

o en caso de querer  instalarlo, ejecutar después de añadir los repositorios:

sudo apt install gimp

También podemos descargarlo, siendo un programa de Software Libre, multiplataforma y totalmente gratuito, para Windows y Macintosh. De esta manera se pueden ir probando programas y aplicaciones Open Source, a parte de Gimp existen otras como Inkscape, Geany
LibreOffice, Blender, Audacity
 

GIMP DONWLOAD

 

Hasta la próxima.

Estos son algunos consejos para optimizar Ubuntu en equipos con pocos recursos. Teniendo en cuenta que se podría llegar a un nivel de optimización mucho mayor, como el que publique en mi blog hace ya un tiempo, aunque se tratase de Debian y en un modelo de portátil en concreto. Pero para portátiles y PC con 512MB, 1 o 2 GB de RAM va a ser interesante y de esta manera conseguiremos mejorar la duración de batería, así como la velocidad y buena optimización de disponer de un equipo con características similares. En este grupo se podrían incluir los portátiles de la Junta de Andalucía y en la que tenemos abierta una opción de intercambio o instalación de Ubuntu.
Las particiones van a gusto de cada uno, pero yo suelo dejar unos 30GB como partición primaria en EXT4 como / raíz dónde irá el sistema de archivos, otra partición primaria como Swap o memoria virtual (normalmente el doble de la memoria física, si son 2GB pues dejaremos 4GB de Swap)y una tercera partición primaria como EXT4 en /home para los datos del sistema. Todo ello teniendo en cuenta que sería el único sistema a instalar. De esta manera si necesitásemos crear otra partición como Datos o almacenamiento extra podemos crear una partición extendida y dentro otras particiones lógicas.
Más sobre el particionado del sistema.
Sigue leyendo

Con este modelo de portátil en concreto nos encontramos con el problema EFI/UEFI del “cordial” SO Windows en su afán de zancadillear cualquier intento de convivir con otro SO, en este caso GNU/Linux. Lo normal es que al probar desde un Live, ya sea un CD o DVD o USB, detecte la instalación o reconozca el SO anfitrión. Pero no, no detectaba ningún SO y al ver la tabla de particiones, aparecía el HDD vacío, como si no hubiera nada.

Lo primero que hice fue entrar en la bios y comprobar si se podía cambiar EFI/UEFI por Legacy, en este caso si se podía, aún así lo deje con el sistema EFI activado, ya que las versiones superiores a Ubuntu 12.04 en 64 bits están preparadas para poder arrancar bajo este, digamos sistema, especificación o algo. Un inconveniente sería que Windows estuviese instalado bajo el EFI/UEFI y al instalar la distro de GNU/Linux lo hiciésemos en modo Legacy, aquí si entraría en conflicto cada vez que cambiásemos de SO en el arranque. Lo ideal es tener los dos, o tres o los que sea, instalados bajo el mismo modo de arranque.
Aclarar que este portátil viene de serie con un Windows 7 Home Premium de 64 bits y la distro que eligió su dueño (@rafa_GJ) fue Linux Mint.

Seguimos.
“Engañamos” a Windows, eso mola eh!.
Linux vs Windows
Desde el propio Live iniciamos Gparted para comenzar con el particionado. Como Windows solo quiere estar en la primera partición del HDD lo que hice fue lo siguiente:
Con los 500 GB de HDD realice una partición extendida de 100 GB al final y dentro cuatro lógicas para /boot en ext3, / raíz, /home y swap en ext4. El resto se puede dejar tal cual o darle un formato NTFS o FAT32 o no darle ni las gracias, puesto que al volver a instalar Windows ya se encargara él de darle su propio formato, y lo mejor es que los 100 GB que dejamos al final para Linux Mint ni los vera. Very important hacer backup del Windows o clonarlo con un programa que se llama Clonezilla, aunque Rafa (el propietario del portátil) me dejo machacarlo por completo. Si se tiene una .iso de windows7 Home Premium no hay problema al volver a instalarlo por el tema de la licencia, se vuelve a poner la que tiene y la reconoce sin problemas, además se da por hecho que ya nos sacaron la pasta por ella una vez.

Se instala o se copia la imagen clonada de Windows en los 400 GB que dejamos en partición primaria y se ponen todos los controladores, drivers y demás cosillas, para esto lo mejor es entrar en la página web de la marca del portátil y descargarlos directamente. Un problemilla que hubo es que al instalar Windows de nuevas no reconocía ni el wifi ni la Ethernet ni los puertos USB, fácil, descargamos el driver .exe de los puertos USB, los metí en un CD y se instalo. No todos los caso ni todos los portátiles tienen que ser así de complicados, pero este si que lo es. Tampoco se os ocurra intentar hacerlo con el driver o archivo comprimido en .zip .rar .tar u otro compresor ya que, menos aún, tendréis un programa para descomprimir, aunque después tampoco, al igual que si queréis abrir un fichero en .pdf o tantos programas y herramientas que, por ejemplo, si vienen de serie en la gran mayoría de distribuciones GNU/Linux, por no decir todas.

Ahora ya se puede instalar Linux Mint o Ubuntu o Arch o la que más te guste (para gustos los colores), en la partición de 100 GB, Rafa opto por darle 100 MB para /boot donde alojar el grub de arranque en ext3, (bueno esto en realidad fue idea de @jjmerelo ya que con el grub en la raíz no arrancaba el SO y me estaba volviendo loco buscando una solución), 20480 MB a la / raíz, 4048 MB como memoria de intercambio o Swap y el resto para /home.
Ahora ya si, el Grub de Linux Mint o Ubuntu reconocerá al Windows y dará la opción de elegir el SO de inicio.

Bueno pues creo que, en este caso, el propietario sigue feliz con su dual boot y en especial con GNU/Linux.

Hace algún tiempo estaba yo soltando un rollo sobre compatibilidades entre licencias de software y alguien me dijo (más o menos): “Vale. Pero sin follones ni líos: Supongamos que yo he hecho un programa y quiero liberarlo. ¿Qué hago?“.

Liberar un software puede llegar a ser tremendamente complicado e incluso, a veces, literalmente imposible. A menudo la cosa se complica por desacuerdos entre los autores, o con la empresa para la que trabajan, o líos legales con las distintas licencias que pueda tener un programa complejo…

Pero, en la mayoría de los casos, cuando dices “He hecho este programa y quiero liberarlo” es algo muy fácil, simple y rápido. De modo que, en adelante, supondremos que eres el autor del software y que no estás usando librerías ni código de otros autores.

Paso 1 Elegir Licencia:

Hay un montón de licencias libres para elegir, cada una de ellas con unas características propias. Algunas licencias son compatibles con unas pero con otras no. Si usas librerías o parte del código de otros, o si tu programa es una modificación del de otro, tendrás que usar su misma licencia o una licencia compatible con la suya. Si usas código de varias fuentes con licencias distintas, necesitarás encontrar una licencia compatible con todas ellas (y eso puede llegar a ser un lío tremendo en el mejor de los casos, o incluso imposible en el peor).

Pero sigamos suponiendo que todo el código es tuyo y no dependes de las licencias de otros. Entonces puedes elegir la licencia que quieras. Personalmente, te recomiendo que uses la licencia GPL. Es una licencia libre que permite todos los usos de tu software (incluso comerciales), permite redistribuirlo, modificarlo y crear software derivado, pero exige que todo ese software derivado se distribuya con esa misma licencia GPL. Esto es importante porque, de este modo, todas las mejoras, modificaciones o software derivado que hagan los demás de tu código también tendrán que ser libre (a esto, concretamente, es a lo que se llama “Copyleft”). Es también la licencia libre más usada y, de hecho, la que usa Linux.

Una vez elegida la licencia, tendremos que indicarla en cada uno de los archivos del código fuente. Veamos cómo.

Paso 2: Copyright.

Sólo la persona (o personas, si son varias) que tiene el copyright de un programa puede liberarlo. En principio, esa persona (o personas) es el autor (o autores) de ese programa.

Así que lo primero que tienes que poner en la cabecera de tu programa es un anota diciendo quién eres y que que tienes el Copyright, con algo parecido a esto:

Copyright 2013 Allan Psicobyte.

(si hubiera más de un autor se pondría una línea como esa por cada uno de ellos)

Después de la nota de copyright se pone un pequeño texto que indique concretamente la licencia que estamos usando. Suele haber un texto estándar para cada una de ellas, y en el caso de la GPL es este:

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.

Paso 3: Archivo con la licencia

Además de poner el texto con copyright y licencia en cada uno de los archivos del código fuente, es conveniente acompañarlo con otro archivo que contenga el texto completo de la licencia. Por tradición, ese archivo es de texto plano y se llama README (así, en mayúsculas y sin extensión) o, mejor, LICENSE. El texto de la licencia, en el caso de ola GPL, se puede copiar de la versión que hay en la página del proyecto GNU (tal cual, sin modificar nada).

Paso 4: Publicar el código:

Lo siguiente es poner todo esto en algún lugar público al que se pueda acceder. Lo puedes poner para descargar como un archivo comprimido en tu página personal, usar tu propio servidor FTP o el método que prefieras pero, lo más recomendable con diferencia, es usar alguno de los muchos repositorios de Software Libre o forjas que existen. Estos sitios te permiten fundir el proceso de desarrollo, producción y distribución en uno sólo, y suelen estar dotados de herramientas muy útiles.

Hay muchos diferentes y, dependiendo del sistema de control de versiones que uses (y, si no usas ninguno, deberías hacerlo), preferirás uno u otro. Sourceforge, por ejemplo, es un clásico que usa subversion, aunque últimamente el que está pegando fuerte es github, que usa git y tiene un montón de herramientas de tipo “red social” que sirven de mucha ayuda.

Además, siempre que distribuyas el programa deberá ir acompañado del código fuente o, en su defecto, de un enlace o texto indicado cómo conseguirlo.

Por último, dependiendo de cómo sea tu programa, es una buena idea incluir algún aviso sobre la licencia en la documentación, la ayuda (el clásico “Acerca de…”), el manual, etc.

Y con esto, ya eres un programador de Software Libre. Enhorabuena.

(Publico este texto simultáneamente en mi blog y en el de la Oficina de Software Libre de la Universidad de Granada)

A menudo, la primera pregunta que se hace alguien que quiere empezar a colaborar en un desarrollo de software libre es cómo hacerlo.

Al comenzar a programar en una empresa o cualquier clase de proyecto con una estructura jerárquica tradicional, simplemente llegas y alguien te muestra una silla y te dice lo que tienes que hacer y cómo tienes que hacerlo. En una comunidad de software libre las cosas son muy distintas.

El desarrollo de software libre tiene un componente social muy importante, y las comunidades se estructuran, de forma deliberada o espontánea, como una meritocracia.

Esto tiene muchas ventajas de cara al desarrollo en sí mismo, pero puede dificultar mucho entrar en un proyecto.

Además, cada proyecto es un ecosistema en sí mismo y funciona de forma autónoma y distinta a todos los demás. Lo que vale para uno no tiene necesariamente que valer para otro. Lo que pongo aquí son unas reglas básicas, meramente orientativas, en base a lo que cuentan miembros de distintas comunidades (En especial recomiendo esta magnífica presentación de Plablo Neira, que es miembro del Core Team de Netfilter).

En algunos casos, sobre todo proyectos pequeños o incluso unipersonales con poca o ninguna comunidad, te bastará con escribir un correo al administrador para que te dé permisos de escritura en el repositorio, pero aquí vamos a suponer que estás pensando en un proyecto “grande”, en el que no va a ser fácil que te hagan caso o incluso la recepción sea más que fría.

En un proyecto grande, un administrador puede recibir cada día cientos de parches de desconocidos que, directamente, no puede pararse a leer para ver siquiera si son simplemente válidos. Lo más probable es que los descarte directamente. Para entrar hay que hacerlo poco a poco, siguiendo los pasos correctos.

Insisto en que esto está escrito pensando en el caso más “difícil”: No quiero asustar a nadie XD

Para empezar, ármate de paciencia.

Elegir proyecto

Naturalmente, tiene que ser algo que te guste, porque no tiene mucho sentido meterte en algo que te aburra y que seguro que vas a abandonar más pronto que tarde.

Además debes buscar algo más o menos concreto. “Quiero trabajar en GNU/Linux” no es decir mucho.

Siempre es mucho mejor, si es posible, que trabajes en algo que usas, conoces y a lo que le has visto fallos/bugs/deficiencias/posibilidades de mejora.

Los proyectos pequeños con pocos miembros suelen ser más receptivos a la hora de admitir nuevos miembros, y más dados a ponértelo fácil, explicarte cada cosa, etc.

Conocerlo

Una vez que has decidido en qué quieres participar, tienes que buscar tres cosas principales (que, a menudo, van juntas) y darte de alta en ellas:

  1. Los foros/listas de correo de desarrolladores (no los de usuarios, ni howtos, aunque también conviene conocerlos).
  2. El bus tracería.
  3. El repositorio (cómo se usa el CVS que tenga, y bajarte el código, claro).

En los tres puntos de arriba, además, debes leerte los consejos de uso, buenas maneras y esas cosas.

Una vez hecho esto, meterse a enviar código como un loco es un error. Es el momento de “lurkear”. Lee los mensajes, las peticiones, las respuestas…

La idea es que veas “el ambiente”, cómo pregunta y responde la gente y cómo funcionan las cosas en general.

Empezando a participar

Cuando te sientas cómodo, puedes empezar a responder cuestiones en los foros o aportar soluciones a los bugs. Es mejor empezar con cuestiones simples, aunque sean tonterías o demasiado simples para tus conocimientos. Es probable que sean cosas de uso o configuración, que no requiera código. También es bueno que vayas viendo los parches que sube la gente, probándolos tú mismo, etc.

Si ves que hay buena recepción, ya podrás meterte en temas más serios y empezar a aportar soluciones a bugs reales (para estas alturas, ya deberías saber manejar la herramienta “diff”). Si todo va bien y confiando en tu habilidad y dedicación, para estas alturas ya te estás “haciendo un nombre” (o sea, que ya no eres un desconocido que acaba de aparecer). La mayoría de estos parches van a ser ignorados o descartados por la razón que sea (porque el formato no es el correcto, porque están demasiado/demasiado poco comentados, porque hay oro parche mejor…) pero, en algún momento, uno de tus parches acabará siendo aceptado. Enhorabuena.

Probablemente pases mucho tiempo escribiendo parches y, conforme tú aprendas a conocer el programa y la comunidad, y la comunidad aprenda a conocerte a ti y a tu código, irás “escalando puestos” en la meritocracia (que es una forma “chic” de decir que se irán fiando de ti e incluso te irán dando responsabilidades).

Básicamente, se trata de ir demostrando poco a poco lo que vales en base a tus aportaciones. No puedes llegar gritando “Aceptad mis commits, que soy un genio programador“, porque no serás bien recibido. No basta con programar bien, también hay que seguir las reglas de la comunidad y ponérselo a la gente que tiene que descubrir que programas bien.

Web Jornadas de Software Libre
Logo y enlace Web Jornadas de Software Libre 2018
Web SereIngeniera
Logo y enlace Web SereIngeniera 2018
Web Campus Infantil 2018
Logo y enlace Web Campus Infantil 2018
Calendario
junio 2018
lunes martes miércoles jueves viernes sábado domingo
28 mayo, 2018 29 mayo, 2018

Categoría: General10:00 am: #SereIngeniera18 - Sto. Tomás de Villanueva

10:00 am: #SereIngeniera18 - Sto. Tomás de Villanueva
30 mayo, 2018 31 mayo, 2018 1 junio, 2018

Categoría: General12:00 pm: Admisiones provisionales Campus de Chicas

12:00 pm: Admisiones provisionales Campus de Chicas

Categoría: General12:00 pm: Cierre III Campaña de Donación

12:00 pm: Cierre III Campaña de Donación

Categoría: General10:00 pm: Pre-inscripción Campus de Chicas

10:00 pm: Pre-inscripción Campus de Chicas
2 junio, 2018 3 junio, 2018
4 junio, 2018 5 junio, 2018 6 junio, 2018 7 junio, 2018 8 junio, 2018

Categoría: General12:00 pm: 1ª asignación III Campaña de Donación

12:00 pm: 1ª asignación III Campaña de Donación

Categoría: General12:00 pm: Admisiones definitivas Campus de Chicas

12:00 pm: Admisiones definitivas Campus de Chicas
9 junio, 2018 10 junio, 2018
11 junio, 2018

Categoría: General12:00 pm: 2º Asignación III Campaña de Donación

12:00 pm: 2º Asignación III Campaña de Donación

Categoría: General12:00 pm: Admisiones provisionales Campus Infantil

12:00 pm: Admisiones provisionales Campus Infantil
12 junio, 2018 13 junio, 2018 14 junio, 2018 15 junio, 2018

Categoría: General12:00 pm: Admisiones definitivas Campus Infantil

12:00 pm: Admisiones definitivas Campus Infantil
16 junio, 2018 17 junio, 2018
18 junio, 2018 19 junio, 2018 20 junio, 2018 21 junio, 2018

Categoría: General10:30 am: Taller de la III Campaña de Donación

10:30 am: Taller de la III Campaña de Donación
22 junio, 2018 23 junio, 2018 24 junio, 2018
25 junio, 2018

Categoría: General9:00 pm: Campus Infantil - 1º turno

9:00 pm: Campus Infantil - 1º turno
26 junio, 2018

Categoría: General9:00 pm: Campus Infantil - 1º turno

9:00 pm: Campus Infantil - 1º turno
27 junio, 2018

Categoría: General9:00 pm: Campus Infantil - 1º turno

9:00 pm: Campus Infantil - 1º turno
28 junio, 2018

Categoría: General9:00 pm: Campus Infantil - 1º turno

9:00 pm: Campus Infantil - 1º turno
29 junio, 2018

Categoría: General9:00 pm: Campus Infantil - 1º turno

9:00 pm: Campus Infantil - 1º turno
30 junio, 2018 1 julio, 2018
Archivos
Categorías