MarioDebian, mi devlog

Hasta ahora los terminales ligeros consistían en una serie de piezas hardware que en los casos más exigentes redibujaban la pantalla que le mandaba el servidor (visto a groso modo), ninguna de las plataformas (LTSP, PXES, ThinStation...) pensaba en poder usar los dispositivos locales, mas allá del sonido, o la impresora...

¿Qué pasaría si convertimos un equipo normal (digamos que con un windows 98) a un terminal ligero?

Ese sistema que tiene instalado seguramente tenga datos (léase Mis documentos) incluso puede tener varias particiones...

Con las pruebas de tcos-devices-ng me he dado cuenta que es posible usar un terminal con disco duro local y usar este disco duro para guardar pequeñas cantidades de información (no se hasta que punto de forma segura):



De esta forma se pude configurar cualquier equipo con arranque dual (red/local) y que así pueda compartir datos sin tener que tocar el servidor para nada...

A todo esto, la versión que acabo de subir a los mirror de TCOS ya soporta la lectura/escritura en varios tipos de sistemas de archivos como son vfat, ext2, ext3, reserfs, xfs, o el mismísimo ntfs gracias a ntfs-3g.

Con la configuración por defecto de TCOS basta añadir un archivo con este contenido: 

stat_before
    manual_add_modules reiserfs
    manual_add_modules ntfs
    manual_add_modules xfs

    force_load fuse
    cpifexists /usr/bin/fusermount  /usr/bin/

    cpifexists /sbin/mount.ntfs-3g     /sbin/
stat_after "Filesystem modules"

Hay que tener instalados los paquetes correspondientes (ntfs-3g) y guardarlo como /etc/tcos/hacking/filesystems

Estoy preparando una nueva versión de tcos-devices (bautizada como tcos-devices-ng) mucho más simple ya que se crea un menú en la barra de tareas dinámicamente con las unidades encontradas en el terminal ligero...



ACTUALIZACIÓN:

Ya está disponible un pequeño video (en flash) con el funcionamiento del nuevo tcos-devices-ng.

Por cada menu aparece un submenú con las opciones de montar y desmontar y para ser un poco más intuitivo, la opción que se puede hacer, activada.

Hasta aquí bien....

Resulta que necesito que la aplicación tenga dos hilos de ejecución, el primario es el que carga el menú, se conecta al terminal para ver dispositivos y se encarga de cdrom y disquetes, necesito otro segundo hilo que cada x segundos (3 es un buen número) compruebe los eventos udev del terminal.

Para lanzar este segundo hilo y que no interfiera con el primero hay varias opciones:

• lanzarlo en un nuevo thread
• lanzarlo en un thread y hacer un fork
• usar un parámetro para arrancar uno u otro y lanzar los dos

Hasta ahora usaba la última opción por ser más sencilla pero tiene sus inconvenientes. Un proceso independendiente no puede acceder (y menos modificar) las variables de otro porque se ejecutan en distintos espacios de memoria. Algo tan obvio no lo parece tanto cuando te metes a programar y no sabes porque tu actualizador de menús siempre dibuja lo mismo.

La opción del thread es la más lógica pero no he sabido porqué el thread queda congelado hasta que no termina la aplicación principal ( gtk.main() )

Como último recurso queda la segunda opción, lanzar un thread y un fork, pero nos encontramos de nuevo con el problema de no poder modificar las variables...

¿Para que demonios voy a modificar las variables de una aplicación desde otra?

Pues para algo tan «cool» como cuando pinchemos una memoria USB, udev genere el evento, el "escuchador udev" lo detecte y se añada al menú un nuevo elemento con la memoria (modelo, marca) y la posibilidad de desmontarla (se montaría automáticamente)

Llegados a este punto he empezado a buscar metodos que me sirvan para que los dos hilos hablen entre si:

• pipes (las pruebas que he hecho no me acaban de convencer ya que en la aplicación gráfica necesitaría otro "escuchador" del pipe)
• sockets (demasido complicado, además este proceso se ejecuta una vez por cada cliente...)
• memoria compartida, colas de mensajes... (muchos procesos, complica el tema)
  
• guardar/leer variables desde un archivo (metodo más grotesco pero que en teoría podría salvar el problema)

¿Alguien programa en multihilo?
¿Sugerencias?

UPDATE 20:18:

Ya me vale la tontería, escribiré mil veces que hay que avisar al módulo gtk cuando vamos a usar hilos con «gtk.gdk.threads_init()», ya lo tengo funcionando con dos simples threads, en breve un screencast...

Poco a poco voy documentando las partes menos obvias de TCOS:

El primer afortunado ha sido TcosConfig, no es que haya documentado mucho, ya que con las capturas de pantalla (13 para cada idioma) creo que queda bastante claro como funciona.

El segundo y el que más tiempo me ha llevado por el gráfico que tiene, es TcosDevices, o también conocido como tcos-devices, es el script en python encargado de acceder a las memorias USB, disquetes y cds de una manera realmente sencilla.

El esquema que he hecho (con inkscape) es un poco grande por lo que pido disculpas a los RSS y planets a los que estoy subscrito:


¿Cómo funciona TcosDevices?

Cosas que entran en juego:

• En el terminal ligero se ejecuta un servidor XMLRPC que atiende las llamadas de varias aplicaciones python.
• La autenticación de TcosDevices (y la de TcosVolumeManager del que hablaré otro día) se hace con la cookie de sesión de las Xorg. De esta forma podemos estar seguros que el usuario al que le damos acceso está sentado en el equipo donde ha conectado el pendrive o el disquete. Se acabó usar SMB para este tipo de cosas.
  
• TcosDevices en modo «tcos-devices --daemon» pregunta al terminal (cada 3 segundos) por los eventos del tipo bloque de udev (udev los guarda en un archivo en /tmp/
• Si hay eventos nuevos se envían al programa en python que se ejecuta en el servidor, y se borran del terminal y dependiendo del tipo de evento, dispositivo, etc.. se ejecuta un método (una acción para entendernos)
• Por ejemplo, si se conecta un pendrive se generarán dos eventos, el primero es «dispositivo /dev/sda creado» y el segundo «dispositivo /dev/sda1 creado», si nos fijamos en el tipo de sistema de archivos el primero no tiene (es un disco completo) y el segundo sí (es una partición), de esta forma al recibir dos eventos podemos usar memorias USB con varias particiones o incluso memorias sin particiones.
• El programa en python detecta el evento y manda la órden de montar el que tiene partición, udev genera un nuevo evento «dispositivo /dev/sda1 montado» entonces con LTSPFS montamos el punto de montaje del cliente en el escritorio del usuario.
• Para desmontar de forma segura se hace doble click en el icono del escritorio (solución un poco rara) para generar los eventos en sentido inverso.
  

Para disquetes y cdrom la cosa se complica un poco (por eso de «tcos-devices --hidden» ya que al introducirse no generan este tipo de eventos de bloque por lo que en si día preparé un pequeño interfaz para montar y desmontar (un poco más manual) los dispositivos.

Estoy pensando en reunir el código de los dos en uno sólo y crear un pequeño menú en el que se pueda ver lo que hay montado y montar desmontar... (tiempo al tiempo...)

No confundirse, no pensaba hablar ni de bancos ni de pisos (eso para otro día que también tiene tela), sino del conocimiento.

Ahora que tanto se habla del conocimiento libre han llegado nuestros gobernantes a poner puertas al campo, a hipotecar el futuro de nuestros hijos y nietos a una (sólo una, y nada más que una) empresa llamada Microsoft.

Intercambio de maletines cual final de liga de fútbol o especulación inmobiliaria, o lobbys desesperados por frenar el terremoto es lo que me parece que hay detrás de esta historia.

Lo peor no es el que se lleva el dinero sino la cara de tontos que se nos queda al ver que las cosas no cambian de un lado a otro de la política, todos los grupos mayoritarios han frenado enmiendas tales como eliminación de cualquier tipo de canon a entidades de derechos de autor en los equipos de la administración pública (¿con mi dinero de contribuyente estoy pagando los palacios a la SGAE?, parece que así es...) o uso de estándares en la administración. Te recominedo , sino lo has hecho ya, que revises las enmiendas.

Ya no entro en las enmiendas más relacionadas con el software libre como liberación o al menos auditación del software que se usa en la administración (algo que por ejemplo ayudaría a desarrollar más rápido, más barato y marcar con el dedo a empresas chapuceras)

Mientras muchas comunidades autónomas se suben al tren del software libre cuyos railes fueron cimentados por Extremadura y Andalucía y otras desarrollan (por la puerta de atrás) soluciones sin que se enteren sus cargos políticos (se de alguna pero no puedo decir nombres).

Y tu te preguntarás, ¿cuál es el modelo de negocio del software libre?

Esta mañana hablaba con un amigo sobre la empresa y el código abierto, no entiende (como mucha gente) cómo nos ganamos las castañas los que estamos en esto... es muy sencillo, el software es libre pero no gratis.

¿y donde esta la ventaja?

Imagina que compras un programa de facturación super completo (realmente lo que pagas es el poder usarlo no la aplicación) pero de código cerrado y que sólo lo lleva una empresa o en el peor de los casos una persona. Mañana «se le cae un piano encima» (ponga aquí cualquier cosa que no deseamos que le pase a esta persona) y nos deja sin soporte.

Ahora voy yo (o cualquiera de esas personas que amamos el software libre) y te hago un presupuesto un poco más caro que su licencia de uso, pero en cambio te doy el código fuente y la documentación del «cómo está hecho», si mañana yo desaparezco o cierro, tranquilamente podrás contratar a otra persona, ya que tienes la receta para que eso funcione. Además añadido al importe tienes la libertad de revenderlo, liberarlo o hacer lo que quieras con él, también tienes la libertad de que el mantenimiento te lo lleve la empresa que tu quieras que en la mayoría de los casos será la madre de la criatura, ahora piensa que tu empresa crece y empiezas a abrir sedes alrededor del mundo, no tienes porque pagar más, el programa ya lo tienes... si está bien programado (diseño modular y esas cosas) seguramente escale bien y pueda con muchas más transacciones.

¿se ven las ventajas?
¿alguien se las explica a nuestros políticos?


NOTA: sé que llega tarde un tipo de artículo como este pero no esperaba que las enmiendas no llegasen a ser aceptadas (iluso de mí)

Hace unos días empecé a buscar en serio a un Debian Developer, me conecté a varios IRC, estuve fisgando por el QA de Debian, hasta que caí en la cuenta de que conozco (al menos virtualmente) más DD de los que yo pensaba.

Un ejemplo es Ghe Rivero con el que comparto planet desde bastante tiempo, y al que he seguido con bastante envidia sana en su proceso de New Mantainer.

Esta semana le mandé un correo y después de explicarle un poco que contenían los paquetes acabo de recibir uno de los correos más inesperados:



¿Cuánto tiempo pasan en NEW los paquetes como media?

He intentado (y estoy trabajando en ello) seguir las normas y al menos creo que no incumplo alguna de las condiciones más importantes de la Reject FAQ , puede faltar una o dos páginas «man» triviales (de aplicaciones gráficas con dos opciones --help y --debug) así que no creo que sea demasiado importante.

Quiero dar las gracias primero a Ghe por ser el sponsor de esta subida y también a xerakko que conocí en #debian-mentor-es de irc.debian.org y que estuvo guiándome e indicándome los fallos de los paquetes.