¿El despertar de OpenClinic?

Fue a principios del año 2014 cuando la idea de reescribir OpenClinic en un framework de programación empezó a retumbar con más fuerza en mi cabeza. Por aquel entonces, estaba dedicando mucho tiempo a aprender Django para el proyecto migasfree y quería explorar otros aspectos de esta herramienta. Una vez más, eché mano de mi antiguo proyecto para que me sirviera de conejillo de indias en mis experimentos.

Esos experimentos duraron alrededor de un mes, lo necesario para indagar sobre las clases de vistas genéricas de Django, y volví a meter el juguete en el cajón de los recuerdos. Sólo llegué a terminar muy por encima el bosquejo del nuevo modelo de datos y las operaciones básicas sobre uno de los modelos. También me entretuve en descubrir componentes de terceros para simplificar algunas de las tareas (como paginaciones de elementos, construcción de formularios y un nuevo interfaz de administración).

El tiempo ha vuelto a pasar, más rápido de lo que a uno le gustaría... y me paré a pensar sobre algo que escribí hace ya un par de años. Sobre la idea de renovar OpenClinic en otro lenguaje, con un framework que ayudara a concentrarse en la lógica de negocio... pero sobre todas las cosas, en publicar en abierto un proyecto desde el inicio. Tengo que reconocer que sigue siendo una de mis asignaturas pendientes y que he vuelto a caer en la falacia de querer que estuviera mínimamente decente antes de subirlo a un repositorio público. Si sirve alguna excusa, ni siquiera tenía claro el nombre del proyecto, por lo que estas dos últimas semanas, con energías renovadas (y gracias al tiempo libre extra), me he concentrado en construir la funcionalidad básica y dejar la elección del nombre para última hora.

Sí, habéis leído bien el tiempo que me ha costado realizar la tarea: dos semanas. Eso ha sido gracias a dos elementos cruciales:

1. la experiencia acumulada en Django
2. la facilidad que otorga este framework para realizar tareas básicas

Pero, aunque el resultado final está casi a la altura del proyecto original, esto no significa un nuevo resurgir de la aplicación. Simplemente he sacado de mi cabeza una tarea pendiente, he sentado los mimbres de lo que podría ser la evolución de la idea (si alguien contribuye con código adicional al repositorio, lo revisaré encantado) y he constatado la importancia de integrar nuevo código a partir de librerías y proyectos de terceros. Como dije en su día, al no tener colaboración directa de profesionales de la medicina, no se puede probar la eficacia de la idea, ni ampliarla en la dirección adecuada (pese a las más de 34.500 descargas del original, el feedback obtenido no es significativo).

Quito de mi mente esa idea que resurgía cada poco de reorientar el proyecto, con el objetivo de dejar sitio libre para otros nuevos planes. Y la quito definitivamente, volcando el código en un repositorio público. Como dijo Linus Torvalds, no hay mejor copia de seguridad que publicar las cosas para todo el mundo.

He cambiado el lenguaje de programación a Python, el cual me parece mucho más boyante y con mejores cimientos que PHP. Y me he decantado por Django por ser un proyecto con mucho recorrido y en el que ya tenía muchas horas de vuelo. Gracias a esta herramienta, se ha eliminado mucho código repetido y no ha hecho falta (casi nunca hace falta si se busca lo suficiente) reinventar el fuego ni la rueda.

Django tiene una comunidad muy activa y esto también se demuestra en la cantidad de aplicaciones que existen. Para cada funcionalidad que quería añadir, he buscado una aplicación ya existente que la cubriera. Alguna de ellas es tan reciente que aún tiene errores en el código. Otra, al no estar demasiado actualizada, no me he permitido usar la última versión liberada de Django (la 1.9). Es el precio que se debe pagar por código que en principio no controlas, pero las ventajas, para mí, son más importantes que estos inconvenientes. Decía que en un principio no controlas ese código... pero en realidad no es así. Al apoyarte en otros programas que también son software libre, puedes mandar las mejoras pertinentes para que todos nos beneficiemos. Además, el currículum personal no sólo se alimenta de contribuciones propias sino que también son muy importantes las colaboraciones se que hacen en proyectos de otros. Diría que enriquecen todavía más.

Resumiendo, el "nuevo" OpenClinic sigue manteniendo la esencia de la simplicidad (incluso se han recortado elementos superfluos respecto al original), pero no está recomendado para su uso en producción. No se ha pensado en cómo facilitar la instalación para el público en general, por ejemplo. Es sólo una pieza de código para que sirva de ejemplo para otros. Y lo mejor es que si lo probáis, sea a través de un entorno virtual para que no cause problemas con otras cosas que tengáis instaladas.

El software libre y yo: dos caras de la misma moneda

El presente artículo es el original que, posteriormente, se tradujo y se adaptó en lo que sería Migasfree developer journeys from graduation to open source career, un encargo de Jean Wike para la publicación online opensource.com. Tan solo he actualizado algún enlace que había quedado desfasado.

---

Desde que era bastante joven, siempre me ha atraído la programación. Y la mejor forma de aprender algo es estudiar cómo lo hacen otros, para luego aplicarlo a lo que uno hace.

En un principio, cuando lo único que interesa es aprender, el tema de las licencias queda bastante alejado de lo que uno quiere saber. En mi pequeño ecosistema de estudiante (en el que todavía no existía Internet), era práctica común compartir el código fuente de los programas que se hacían. Era lo normal, porque entendíamos que así podíamos aprender unos de otros. Pero había algunas personas recelosas (no muchas), que no seguían esas reglas tácitas. Nunca logré comprender porqué si ellas sí se aprovechaban de conocimientos e ideas de otros, no colaboraban con los demás enseñando sus propios programas.

Después, cuando uno se va haciendo más mayor y empieza a descubrir el mundo empresarial, comienza a comprender el intrincado sistema de leyes de patentes, propiedad intelectual y demás trabas que unos a otros se van poniendo en el complicado mundo de los negocios. Muchas veces he pensado que sin tantos obstáculos (todos ellos artificiales a la naturaleza humana), el avance de la tecnología (entre otros muchos campos) podría haber sido mucho más rápido y ético en los resultados obtenidos. Pero la afirmación de que la información es poder, sigue pesando mucho más que los beneficios a largo plazo para todos.

Por suerte, también descubrí que aquellas ideas que había tenido años atrás, eran compartidas por muchas otras personas. Gracias a ellos, hoy puedo estar aquí y escribir sobre mis experiencias. Soy quien soy por la suma de pequeñas partes y hay muchas más que han sido legadas por otros, que mías originales. Y es así para todos, porque así es como hemos ido evolucionando como especie.

Cuando iba a terminar mi carrera universitaria, tenía que realizar un proyecto completo de software para finalizar mis estudios. Me pareció algo completamente natural que dicho proyecto fuera software libre, pero no me imaginé que fuera el primer proyecto de estas características en mi pequeña universidad, ya que no se acomodaba a las normas que se estipulaban en los documentos que tenía que generar. Fue triste descubrir que no se fomentaran proyectos e ideas sobre software libre en mi círculo universitario. Espero que con los años, haya cambiado esta situación.

Afortunadamente, las trabas burocráticas que encontré para realizar mi proyecto, desaparecieron en el terreno técnico. Decidí enfocar la idea de la aplicación a la web, pero no tenía todavía formación adquirida en este área. Gracias al software libre, rápidamente pude aprender de otro proyecto, llamado OpenBiblio, para hacer el mío: OpenClinic. Al principio, como se puede apreciar ya del nombre, eran programas con el código muy parecido, aunque sus ámbitos de aplicación eran muy diferentes. Pero conforme pasó el tiempo y puede aprender conceptos de otros proyectos, empezaron a ser más notables las diferencias en la codificación. Sin embargo el valor que tuvo para mí haber aprendido conceptos sobre la programación en web de este proyecto, sigue siendo incalculable. Desde luego, no lo hubiera hecho en tan poco tiempo como lo hice.

Otro de los proyectos que me sirvieron para publicar OpenClinic, fue Gallery. De él adapté la forma en que manejaban las traducciones para cargar el idioma adecuado en la aplicación. Colaboré como traductor de la aplicación al español (en la versión 1) durante unos meses y esa experiencia me sirvió para aprender cómo funcionaba un proyecto basado en comunidad.

Una vez acabada mi etapa estudiantil, tocaba empezar la etapa laboral. La comencé haciendo prácticas en un par de empresas que basaban su negocio en hacer software privativo. Y las herramientas que se usaban para crearlo eran también privativas. Hace 10 años, esta era la situación habitual de las empresas de software de mi ciudad. No existían otras opciones. No se habían probado otras opciones...

Sin embargo, en la tercera empresa donde comencé a realizar prácticas laborales, había algo diferente. Parte del modelo de negocio seguía estando basado en software privativo, pero muchas de las herramientas que podía usar para mi trabajo, eran software libre (PHP, Python, CVS, Bugzilla, Wordpress, Mediawiki, Firefox, ...). Ni que decir tiene que para mí era un entorno mucho más atractivo que los anteriores, y estuve allí, ya como empleado, durante los siguientes 5 años. Esta situación es algo cada vez más normal en las empresas (y más ahora, en estos tiempos de crisis): utilizan herramientas libres para sus labores aunque el resultado no sea software libre.

Tras esos años como programador web, cambié de aires y de tareas. Pasé a trabajar en la administración pública de mi ciudad en un proyecto de implantación de software libre en los equipos de trabajo de los empleados municipales. Parte de mi actividad consiste en adaptar Linux a las características de los empleados de la organización. A esta distribución derivada la llamamos AZLinux.

Pero este nuevo trabajo, me ha permitido ir un paso más allá en mi relación con el software libre, ya que he podido colaborar en varios eventos de promoción (Gnome 3.0 Marketing Hackfest, Libre Software World Conference 2011, OpenDNIe Hackfest, Software & Barra Libre) y me he vuelto a embarcar en otro proyecto de software: migasfree. Esta aplicación cliente/servidor nace para cubrir una necesidad en nuestro trabajo diario de administración de los equipos con Linux, pero estamos adaptándola para que también se pueda usar en otros entornos.

Otro aspecto, todavía más importante, es la calidad de las personas que he ido conociendo en este mundillo. La lista sería muy larga, por lo que sólo nombraré a una pequeña, pero selecta parte:

• Jesús González Barahona, profesor, estudioso y evangelizador de software libre. Empecé a leer sus artículos cuando era estudiante y luego he podido conocerlo personalmente en diversos eventos. Siempre me ha servido de inspiración.
• José Félix Ontañón, todoterreno donde los haya. Entre otros proyectos importantes, colabora en Opendata Sevilla.
• Juanje Ojeda Croissier, lleva años acercando el software libre a las personas. Ha trabajado en proyectos tan importantes como el desarrollo de Guadalinex y Guadalinfo.
• Ramón Ramón Sánchez, fundador de Iniciativa Focus, vicepresidente de Hispalinux y consultor internacional TIC en latinoamérica, serían 3 vertientes a destacar en su larga trayectoria.
• Juan Antonio Martínez, profesor de universidad, se ha empeñado en conseguir que nuestro documento digital de identificación nacional funcione en entornos linux.
• Agustín Benito Bethencourt, miembro de KDE España, también ha trabajado en openSUSE, dinamizando su comunidad.
• Ignacio Correas, fundador de Zentyal, ha sido también presidente de CESLA y es miembro del consejo asesor de CENATIC.
• Eduardo Romero Moreno. Aunque la pasión por el software libre le ha llegado un poco tarde, ahora es toda una apisonadora en este tema. Es el coordinador del proyecto de migración a software libre que estamos llevando a cabo en el Ayuntamiento de Zaragoza.
• Alberto Gacías Mateo, es mi compañero de fatigas. Él ve la profundidad del bosque mientras yo me peleo con los árboles. Ideólogo y opinólogo del grupo de software libre del Ayuntamiento de Zaragoza, es también el creador de migasfree.

Resumiendo, el software libre me ha ido definiendo como persona tanto en el aspecto profesional como en el personal, y se ha convertido en el mejor de los currículum vítae posibles. Si publicas tu trabajo, cualquiera puede fijarse en él y puede convertirse en tu mejor tarjeta de presentación. En los últimos años, dos grandes empresas (una de ámbito nacional y otra internacional), han contactado conmigo gracias al hecho de tener liberados proyectos de software libre en Internet. Desde luego, esto nunca hubiera sido posible si me hubiera dedicado a realizar sólo software privativo.

Pero lo mejor del software libre y de todo lo que le rodea, no es todo lo que he aprendido, sino todo lo que me queda por aprender.

Reflexiones de un desarrollador web

Hay una canción de Jorge Drexler que dice: "Cada uno da lo que recibe y luego recibe lo que da, nada es más simple". Sin embargo, cuando uno está en el mundo del software libre, se suele recibir mucho más de lo que se da.

Eso es lo que me ha pasado con un proyecto que inicié hace ya más de 10 años y con el que he ido adquiriendo algunas deudas pendientes. Una de ellas es el presente artículo.

OpenClinic es el proyecto con el que desembarqué en el proceloso mundo web y en el cautivador desarrollo de software libre. Me sirvió para acabar mis estudios universitarios como PFC y me abrió las puertas para conseguir mi primer trabajo a jornada completa.

Desarrollo web

OpenClinic fue siempre un campo de juegos (entiéndase juego por aprendizaje) y pruebas para mí. Y por eso equivoqué el propósito de la aplicación. En lugar de atraer o buscar profesionales del espectro médico para evolucionar el proyecto, me concentré en los aspectos técnicos de programación para conseguir una especie de framework propio que me sirviera para hacer otras aplicaciones.

El año 2003, cuando ya tenía una versión bastante estable del programa, era una época ideal para haber explotado la idea. Era su momento, pero no supe ver cómo sacarle partido. Actualmente ya es demasiado tarde. Hay otros proyectos como Gnu Health, OpenEMR u OpenClinic GA (sí, ¡me han plagiado el nombre ;)!, era inevitable) que ya han cubierto el espectro con buenos productos.

Pero algo que conserva OpenClinic es su sencillez y sus escasas pretensiones. Supongo que por eso, a lo largo de todo este tiempo, la gente lo ha seguido descargando y, de vez en cuando, alguien me escribía acerca del estado del proyecto. Pero últimamente estaba recibiendo demasiadas quejas sobre problemas en la instalación. Esa ha sido la principal razón por la que 8 años después, he liberado una nueva versión.

La historia de OpenClinic ha ido muy de la mano de la historia de PHP. Cuando tuve la idea del proyecto (en la que ayudó mucho a modelarla Emilio Cazcarra) y de encaminarlo hacia la web, no tenía ni la menor idea de qué tecnologías usar. Descubrí Perl y empecé a estudiarlo cuando, casi por casualidad, me encontré con PHP. En el año 2002 era uno de los proyectos de moda y me convenció desde el principio como lenguaje para el backend. Aunque la primera versión de PHP4 se publicó en el año 2000, era la versión 3 la que por entonces predominaba tanto en aplicaciones como servidores de hosting.

Cuando tuve que decidirme por una de ellas, opté por la más nueva: PHP4. Ya que tenía que aprender un nuevo lenguaje de programación, lo más sensato era estudiar la última versión. Para cuando estuviera en condiciones de terminar la aplicación, al ritmo que se desarrollaba PHP, habría una versión muy estable del intérprete. Y no me equivoqué.

Pero hacia mediados de 2004, liberé OpenClinic 0.7 (eternamente beta) y ahí terminé su evolución. Como he dicho antes, no supe encaminar la adquisición de nuevas características al programa y por eso me concentré en aspectos más técnicos a partir de entonces. Tal vez por eso, aunque seguía con el desarrollo no veía razones de peso para publicar nuevas versiones (no aportaban nada nuevo en cuanto a funcionalidad para los usuarios).

En aquel mismo año, 2004, nació PHP5. Al contrario que con el cambio de PHP3 a PHP4, que fue rápidamente adoptado por los proyectos más importantes que usaban PHP y por los servidores de hosting, el cambio a PHP5 fue traumático y tortuoso para todos. A nivel personal, no lo empecé a usar hasta que me interesé por Zend Framework hacia el año 2007 (¡nada menos que 3 años después de la primera versión de PHP5!).

Pasados los años, OpenClinic adolecía de dos graves problemas:

• No estar basado en PHP5 (que es la versión actual, desde hace muchos años, del lenguaje).
• Y el más grave: no estar programado en un framework de desarrollo.

Adaptar el código a PHP5 (en cuanto a sintaxis, no en metodología) no ha sido muy costoso. El problema radicaba en que no era muy sencillo alojar en un mismo sitio web aplicaciones con PHP4 y PHP5.

Este último fue un grave error de concepto. Quería convertir OpenClinic en un framework. En aquella época (la del PHP Far West), cuando el lenguaje recibía constantes críticas por no ser demasiado estricto en sus formas, cada aplicación de cierta envergadura estaba hecha en un framework propio para intentar poner algo de orden en el caos. No es extraño que también cayera en ese error (intentar reinventar la rueda) pero no me di cuenta a tiempo y es algo que ha perjudicado al proyecto. Tanto que ha firmado su certificado de defunción. Si hubiera estado basado en un framework, entre otros aspectos positivos, habría sido más fácil que otras personas hubieran contribuido añadiendo funcionalidades.

Software libre

Pero no todo ha sido tan negativo. De hecho, el proyecto, como he empezado diciendo, me ha dado mucho más de lo que le he dado. Y me lo ha podido dar porque es software libre y porque está basado en tecnologías libres:

• PHP como lenguaje de backend,
• HTML como lenguaje de marcado,
• CSS para la capa de diseño,
• JavaScript para la capa de interacción,
• MySQL como servidor de base de datos (aunque ha ido cambiando su status a lo largo del tiempo...),
• gettext para las traducciones,
• y Docbook para la documentación.

Para aprender todas estas tecnologías sólo he tenido que invertir tiempo. Los recursos están disponibles de forma libre (y gratuitos muchos de ellos). Y los beneficios obtenidos siguen siendo constantes y consistentes. Además, ha habido algunas personas que han podido contribuir, generando traducciones y temas CSS para la aplicación.

Y pese a los problemas mencionados, las críticas han sido bastante satisfactorias. La aplicación ha tenido unas 20.000 descargas y de vez en cuando me encontraba algún dominio en Internet con el programa funcionando. También me han escrito personas que lo han estado usando en ONGs en países en vías de desarrollo. Todo lo cual contribuye en una recompensa personal inmensa. Al fin y al cabo, uno desarrolla software para que las personas lo usen.

Conclusiones

A día de hoy no haría las cosas como las hice, pero eso lo puedo decir ahora porque las he hecho de esta manera. Uno aprende o sucumbe, no hay término medio.

Si algún vez vuelvo a rehacer la aplicación (no sería la primera vez...):

• lo haría con un framework de desarrollo,
• lo haría en un repositorio público de código desde el principio,
• independizando totalmente el motor de base de datos del código de la aplicación,
• pediría abiertamente ayuda a la gente para que colaborara, incluso dejando la dirección del proyecto a otros que se involucraran más.

Mientras tanto, sigo dedicando mis esfuerzos a otros proyectos de software libre. Uno de ellos es migasfree y, aunque tiene muchas cosas que mejorar, ya he empezado a poner en práctica mis conclusiones.

Actualización: 2013-02-23

Traducción del presente artículo al inglés, publicado amablemente por Rich Bowen.

Cómo cambiar el menú de aplicaciones de Gnome 3

Como primera opción, se podría modificar el menú nuestro usuario con la aplicación alacarte. Si tenemos más usuarios en la máquina, podemos copiar los ficheros resultantes en el resto de perfiles. Es un método más o menos sencillo y que, si sólo tenemos una máquina que administrar, puede ser suficiente.

Pero si tenemos que administrar varios ordenadores y queremos obtener una solución algo más limpia y fácilmente replicable, tenemos que leer con atención la especificación de menús de escritorio.

En dicha especificación se advierte que hay un fichero principal, que suele estar en la ruta /etc/xdg/menus/applications.menu y que se puede extender añadiendo más ficheros en /etc/xdg/menus/applications-merged/. Esto conlleva un gran avance respecto a la primera opción, ya que sólo tenemos que preocuparnos de una única ubicación global por máquina y parece que no tenemos que modificar ningún fichero del sistema. Y digo parece, porque si queremos añadir aplicaciones a los menús sí que sirve, pero si lo que queremos es quitar (u ocultar) lanzadores o categorías, puede ser bastante complicado (por no decir, en algunos casos, imposible). La razón es que en el fichero applications.menu, se añaden primero las modificaciones de los archivos que se hayan puesto en applications-merged/ y luego se sobrescriben con las reglas del propio applications.menu.

Pero si seguimos leyendo con atención la especificación, veremos que existe la solución perfecta. No hace falta escribir complicadas reglas que no interfieran con las del sistema (applications.menu) ni tener que modificar el fichero de configuración (estas modificaciones podrían incluso perderse si se actualiza el paquete que contiene el archivo: gnome-menus).

Se trata de hacer uso de la variable XDG_MENU_PREFIX. Sólo tenemos que darle un valor (por defecto es vacío para que coincida con la ruta del fichero applications.menu) y crear el fichero con las modificaciones del menú.

Por ejemplo, se podría definir un valor para esta variable de entorno en el fichero /etc/environment de la forma:

export XDG_MENU_PREFIX="abc_web-"

Y después crear el fichero /etc/xdg/menus/abc_web-applications.menu. De este modo, ya no se analiza el archivo /etc/xdg/menus/applications.menu, por lo que no será necesario tener en cuenta las reglas de ese fichero, para hacer el nuestro.

Control de volumen simple en Gnome 3

En Gnome 3, hay nuevos applets para los paneles del escritorio. También hay shell extensions, que permiten añadir funcionalidades al escritorio. En uno de estos applets, el que se hace llamar miniaplicación completa de indicadores, aparece el control de volumen. Pero ya no es un simple slider para manipular el volumen, sino que integra el control de la aplicación reproductora de audio por defecto del sistema (Rhythmbox en Ubuntu 12.04).

¿Dónde se encuentra entonces el applet que estaba disponible en Gnome 2? ¿Acaso ha desapararecido?

Para los nostálgicos de aquel control, o para los que sólo quieren el control de volumen y no el resto de indicadores del nuevo applet de Gnome 3, voy a desvelaros qué ha pasado.

En realidad no ha desaparecido, sino que se encuentra oculto. Supongo que es para promocionar el uso del nuevo (que realmente tiene una funcionalidad más completa), pero se ha perdido en personalización, ya que no es muy sencillo mostrar sólo los indicadores que nos hacen falta, de entre todos los que muestra la miniaplicación completa de indicadores.

La solución para que vuelva a mostrarse en el área de notificaciones (este área es un applet más que habrá que añadir en alguno de los paneles del escritorio) es muy sencilla. Tan sólo debemos modificar el atributo OnlyShowIn del fichero /etc/xdg/autostart/gnome-sound-applet.desktop. Debería quedar así:

OnlyShowIn=GNOME;

Si os fijáis en su valor original (OnlyShowIn=;), al estar vacío, no se mostraba en ninguno de los escritorios disponibles, aunque sí está preparado para iniciarse en el comienzo de la sesión gráfica (existe un lanzador en /etc/xdg/autostart/).

Cómo cambiar la imagen de fondo de LightDM en Ubuntu 12.04

Con Simple LightDM Manager, en Ubuntu Oneiric, podíamos personalizar el logo y la imagen de fondo de LightDM. Sin embargo, la configuración del gestor de sesiones ha cambiado y ya no se realiza a través de un fichero (el archivo /etc/lightdm/unity-greeter.conf ha desaparecido), sino a través de dconf. De todas formas, en el fichero /etc/lightdm/lightdm.conf se siguen modificando algunos parámetros del programa (como la sesión gráfica por defecto o si se muestra la lista de usuarios, por ejemplo).

Para empezar, vamos a escoger una imagen adecuada a la resolución de nuestro monitor. Un buen sitio para elegir es Gnome-Look. En la sección de wallpapers hay una amplia selección donde, en cada imagen, viene documentada la resolución y la licencia de uso. En mi caso, me he decantado por Ovalized Wallpaper. Tras descargarla, la he copiado en el directorio /usr/share/backgrounds/ con el nombre lightdm-wallpaper.jpg (con el usuario root).

La posición de la caja para la elección de usuario de la máquina no se puede modificar, por lo que es mejor que no haya nada significativo en la imagen que escojamos para el fondo en dicha área. Como tampoco se puede cambiar la posición del logotipo que aparece abajo a la izquierda. Así que, si también queremos modificarlo, será mejor hacer uno de unas dimensiones parecidas al original (/usr/share/unity-greeter/logo.png).

Vamos a cambiar 2 propiedades de la configuración gráfica de LightDM: la imagen de fondo y quitar la malla (grid) que se dibuja por defecto. Estas propiedades se cambian en el esquema com.canonical.unity-greeter de dconf. Se podrían cambiar a través de la utilidad dconf-editor (que habría que instalar porque no viene por defecto), pero teniendo en cuenta que deberíamos hacerlo con el usuario lightdm. No serviría modificarlas con nuestro propio usuario, ya que LightDM se ejecuta con su propio usuario y hace sólo caso a los valores de su configuración.

Voy a explicar entonces un método alternativo y en el que sólo es necesario un intérprete de comandos y un editor de texto. La receta consiste en modificar globalmente las propiedades (a nivel de sistema) para que aplique a todos los usuarios de la máquina. Además, las voy a bloquear para que ningún usuario pueda sobreescribir estos valores. La explicación teórica del proceso se puede encontrar en la página dconf System Administrator Guide.

Debo decir que el nuevo sistema de configuración de Gnome 3 es bastante más sencillo de modificar para los administradores que el anterior (basado en GConf en Gnome 2). La mala noticia es que todavía hay bastantes aplicaciones de Gnome que siguen con GConf, en lugar de utilizar el nuevo sistema.

En primer lugar, vamos a crear la estructura de directorios necesaria. Como vamos a necesitar escribir en /etc, deberemos hacerlo como root:

$ sudo su
# mkdir -p /etc/dconf/db/local.d /etc/dconf/db/local.d/locks /etc/dconf/profile

Después, vamos a crear los ficheros de configuración.

En el archivo /etc/dconf/db/local.d/light.conf establecemos los nuevos valores de las propiedades:

[com/canonical/unity-greeter]
background='/usr/share/backgrounds/lightdm-wallpaper.jpg'
draw-grid=false

En el fichero /etc/dconf/db/local.d/locks/lightdm, le decimos al sistema dconf qué propiedades están bloqueadas para que no puedan modificarlas los usuarios:

/com/canonical/unity-greeter/background
/com/canonical/unity-greeter/draw-grid

Por último, crearemos el fichero /etc/dconf/profile/user para especificar la prioridad de las bases de datos de dconf.

user-db:user
system-db:local

Sólo falta ejecutar el comando dconf update (como root) para que el sistema dconf rehaga las bases de datos y se apliquen los cambios.

Y eso es todo. Este mismo método de cambio de propiedades sirve para el resto de esquemas disponibles en dconf.

Proyectos varios

Mis inquietudes y quehaceres van más allá del mundo de la web. Hace ya varios años que cambié de modus vivendi y me introduje en la administración de sistemas. Además, me he ido involucrando en proyectos de programación y sociales. He aquí la lista:

AZLinux

Formo parte del equipo de desarrollo de la distribución y he escrito algunos de los artículos del blog:

• 2011-11-02: El núcleo de AZLinux 3


• 2011-10-31: Certificados digitales en AZLinux 3


• 2011-08-25: Razones para hacer una distribución propia


• 2011-06-17: Charla de migasfree en Software y Barra Libre


• 2011-06-02: Conclusiones del OpenDNIe hackfest


• 2011-05-16: Hackfest del OpenDNIe en Cádiz


• 2011-02-16: OpenDNIe en AZLinux


• 2010-05-19: Ponencia en el Gnome 3.0 Marketing Hackfest


• 2010-03-23: Cómo modificar un Live CD de openSUSE y convertirlo en un Live USB


• 2009-10-29: Cómo configurar el servicio NetworkManager en el arranque de openSUSE


• 2009-10-26: Cómo forzar un chequeo de disco

Software & Barra Libre

He colaborado desde el principio con el proyecto y también he escrito algunas entradas en el blog:

• 2011-07-22: El Tao de la programación


• 2011-06-30: Hora de tomar decisiones


• 2011-06-18: Migas para todos en el Pabellón Digital del Agua


• 2011-06-13: Charla de migasfree en el Digital Water Pavilion


• 2011-06-03: Otro miércoles de pensamiento libre

Proyecto migasfree

En este sitio web todavía no me he estrenado como blogger, pero también he colaborado haciendo el tema para el blog, programando en Python la parte cliente de la solución y echando una mano en el instalador del servidor.

Libre Software World Conference 2011

Aprovechando la oportunidad que me brinda estar trabajando en el Grupo de Software Libre del Ayuntamiento de Zaragoza, estaré como ponente hablando de paquetes RPM y su distribución en una organización con migasfree y de AZLinux: evolución del proyecto.