MarioDebian, mi devlog

Bitácora de un desarrollador newbie.

Progresos sobre TCOS
Hace unos cuantos día empecé a desarrollar TCOS (thin client operating system), un nuevo modelo de arranque de terminales ligeros (similar a PXES) pero basado totalmente en arquitectura y paquetería debian.

Estos últimos días he terminado de pulir ciertas cosas que no funcionaban bien y creo que el proyecto está en un estado que se puede considerar como beta, es decir, es usable y estable auqnue le falten cosas.

Mi conejillo de indias ha sido el Aula Magna de la Escuela Universitaria Politécnica donde tenemos 24 equipos servidor por idefix.

He creado unas páginas en nuestro wiki con información sobre TCOS, y estoy esperando que un buen colega me envíe unos logos menos chapuceros que los que he hecho con gimp en 5 minutos...

Como mejoras que _ya_ _funcionan_ cabe destacar:

* Splash de pxelinux personalizado


* Multitud de opciones pasadas como parámetros de arranque:

* Kernel 2.6.16-1-486 de debian (ya se incluyen paquetes precompilados para unionfs y squashfs)
* Arranque silencioso (con usplash por ejemplo):


* Accesso a sistema de ficheros del terminal mediante ltspfs y autofs para montar. (Autentica mediante el protocolo de las X, adios samba y adios nfs) falta añadir para completar la guinda lbuscd y así cuando se conecte un pendrive o un cdrom al terminal aparezca un icono en el escritorio del servidor.
* Limpieza de cosas que sobran /lib/tls por ejemplo
* Posibilidad de arrancar en sistemas con 32 Mb de RAM (usando swap en el disco duro del terminal)
* Uso de swap local o creación de archivo swap en particiones ext3 o vfat.
* Generación de un cdrom arrancable (isolinux o grub) en terminales que no disponen de tarjetas PXE
* Nuevo árbol de directorios /tftpboot/tcos con todo lo necesario para que funcione el terminal:

/tftpboot/tcos/
|-- help.msg
|-- initramfs
|-- logo.lss
|-- pxelinux.0
|-- pxelinux.cfg
| `-- default
|-- tcos.msg
`-- vmlinuz-2.6.16-1-486 -> /boot/vmlinuz-2.6.16-1-486


y varias cosas más....

Espero pronto tener un artículo presentable para poder mostrar toda la potencia y sencillez, de momento en el wiki hay bastante más información que la que puedo poner: WIKI Proyecto TCOS

Captura de arranque sin splash:



Captura de comandos mount y free, como se puede ver consume 38 Mb en modo FULL (sonido, autofs, usb, discover, etc...)





Gedit y los snippets
El nuevo gedit (2.14) trae bastantes novedades, y la que más me ha gustado sin nunguna duda es el soporte de snippets según el tipo de archivo que estemos editando.

¿Qué son los snippets? Pues dicho mal y pronto es aplicar la magia del tabulador de consola pero a programación, por ejemplo, editamos/creamos un nuevo archivo e indicamos a gedit que es php, a continuación llega la magia:

php(TABULADOR) escribiría

#code
?>

Dejándonos el tabulador en la parte code, otro ejemplo sería for(TABULADOR) lo que nos pone:

for ( $i=0; $i < ; $i++ )
{
# code...
}

Con el tabulador pasamos por cada uno de los puntos necesarios para personalizar el for, es decir, por los tres campos contador y por fin, dentro de las llaves.

Para demostrar un poco toda esta magia he preparado un pequeño video, (hecho con byzanz):



Si quereis probar esta versión de gedit en debian podeis usar (gedit-cvs) este paquete (se instala en opt, por lo que no se debería fastidiar nada)




Xfce4.4 ya está aquí...
Después de haber leido artículos como Major changes in Xfce 4.4BETA1 he estado compilando todos los paquetes (4.3.90.1) para debian TESTING (supongo que en unstable se instalará sin problemas..., en ubuntu no creo)

Actualizar a xfce 4.4:

ACTUALIZADO (23 Abr 2006): He separado el mirror en unstable y testing debido a incompatibilidades de bibliotecas de Xorg 6.9 y Xorg 7.0. Si usas testing pon solo los mirror de testing, si usas unstable pon los dos (en unstable hay alguna versión más nueva de algunos paquetes no todos) También he añadido el directorio addons con los siguientes plugins:

* thunar-archive-plugin
* thunar-media-tags-plugin
* xfce4-artwork
* xfce4-mount-plugin
* xfce4-quicklauncher-plugin
* xfce4-verve-plugin
* xfce4-xkb-plugin

Estan compilados en unstable pero no debería haber problemaspara instalarlos en testing.


Editar sources.list y añadir:
#DEBIAN TESTING
deb http://soleup.eup.uva.es/xfce4.4/testing ./
deb-src http://soleup.eup.uva.es/xfce4.4/testing ./

#DEBIAN UNSTABLE
deb http://soleup.eup.uva.es/xfce4.4/testing ./
deb-src http://soleup.eup.uva.es/xfce4.4/testing/ ./
deb http://soleup.eup.uva.es/xfce4.4/unstable ./
deb-src http://soleup.eup.uva.es/xfce4.4/unstable ./

#ADDONS (testing o unstable)
deb http://soleup.eup.uva.es/xfce4.4/addons ./
deb-src http://soleup.eup.uva.es/xfce4.4/addons ./




Actualizar lista de paquetes:

# apt-get update

Instalar:

# apt-get install xfce4-all

(esto instala todos los binarios que he compilado)

o

# apt-get install xfce4-devs

(esto instala los paquetes *-dev por si necesitamos compilar algo relaccionado con xfce)

A disfrutrarlo...




TCOS Thin Client Operating System
Después de pensarlo un poco no merece la pena trabajar sobre un nombre del que no pertenecemos, lease el caso de llamar PXES a algo que se parece preo no tiene nada que ver....

Así que después de preguntar a los compañeros de Soleup he decidido rebautizar metapxes como TCOS, (aka Thic Client Operating System).

TCOS es un proyecto libre que consiste en crear un micro sistema operativo (basado en debian/ubuntu) para que al ser copiado en un directorio tftp sea servido a terminales que con bajos recursos (pentium 350, 64 RAM) arranquen por red y se conecten al entorno gráfico (las X) del servidor, donde se loguean y ejecutan aplicaciones. El proyecto se parace bastante a PXES en la idea pero no en la forma ya que pxes usa software bastante viejo y kernel especiales. Mi idea es usar un kernel debian normal y darle toda la potencia que permiten los scripts.

He añadido importantes mejoras:

* La configuración se gestiona desde un simple y comentado archivo de texto. (se puede hacer un asistente pygtk en tres patadas)
* He reducido el consumo de ram de los terminales a algo menos de 40 megas. (contando que usan Xorg, alsa y esound es todo un record)
* Las particiones ahora si se reconocen al arranque, el script fstab del calzador de guadalinex no es compatible con busybox.
* Si hay partición swap en el sistema se monta, si no se buscan particiones ext3 o fat32 y se prueba a crear un archivo de poco menos de 60 megas para ser montado como swap. En próximos reinicios el archivo, si existe se formatea y se monta sin tener que crearse (aquí tengo que investigar porqué no me deja crear un archivo mayor que la memoria en el sistema, quizás para crearlo grande primero hay que crear uno de menos tamaño...) el error dice algo de out of memory.
* La imagen de arranque es el kernel (1,2 Mb) y el initramfs (7 Mb), después se descargan los extras por tftp (10-15 Mb).
* Como la imagen de extras es un squashfs se monta como sólo lectura, asunto que he solucionado creando un ramdisk de 2 megas y solapándolo al squashfs mediante unionfs.

En un artículo anterior ya comentaba ventajas e inconvenientes sobre PXES, espero reducir los inconvenientes y aumentar las ventajas.

Antonio Quesada uno de los gurús de LTSP y PXES en España (además de profe de mates) ya ha dado su visto bueno :P

Si alguien desea probarlo y tiene ya un aula con un servidor pxes en marcha puede hacer lo siguiente:

1.- Descargar los tres archivos necesarios de tcos y copiarlos en /tftpboot/pxes/
2.- Editar /tftpboot/pxes/pxelinux.cfg/default y añadir lo siguiente al final:

label tcos
kernel vmlinuz-tcos
append ramdisk_size=65536 initrd=initramfs-tcos root=/dev/ram0 BOOT=tcos quiet

Cuando cargue el terminal se escribe en boot: tcos y si todo ha salido bien debería cargar, obtener ip por dhcp realizar alguna tarea y conectarse a las X del servidor. TCOS admite variables en la línea de comandos para poder personalizar los terminales cuando arrancan de modo que si se pone server=192.168.1.1 esta variable será usada como servidor donde nos conectaremos a las X remotas o volume=60% pondrá el volumen del master y el pcm al 60%. Según vaya creciendo el proyecto intentaré que la mayoría de la configuración interna sea controlable mediante la línea de comando de arranque (cmdline) La imagen incluye los módulos necesarios para arrancar el sonido de una sound blaster, pero se puede añadir cualquier módulo disponible en el kernel de debian 2.6.15-1-486 (el kernel que uso). Esto permitirá crear un default por ip para que cada máquina arranque de una manera distinta compartiendo imagen.


Por otra parte he añadido a jclic-browser (0.0.4) al manejo de hilos (threading) para que tareas como escribir en la barra de estado o leer de la base de datos se realicen asíncronamente, dando un poco más de fluided al interfaz. Podeis descargarlo y probarlo desde este directorio: jclic-browser (antes de ejecutar sería bueno leer el /usr/share/doc/jclic-browser/README) Si alguien desea mirar el tema de los hilos a ver si está bien hecho será bien recibido.




Televisión P2P
Una de las cosas que echaba en falta en mi debian es poder ver la televisión P2P.

La televisión P2P consiste en que alguien captura un canal de televisión haciendo streaming y para no colapsar su línea de subida el streaming se retrasnmite por medio de una red peer to peer.

Lo que necesitamos como clientes es un programa que capture el stream, siga compartiéndolo y permita conectar un reproductor a ese hilo.

En linux hay alguna cosa como gnome-peercast pero es bastante complicado de usar para ver símplemente la tele un rato. Así que buscando encontré que sopcast tiene una versión para linux.

Este es el aspecto:



La configuración:



Como reproductor en linux se puede usar cualquiera que soporte reproducción desde red, por ejemplo yo he probado con mplayer o gxine pero seguro que se pueden usar muchos otros.



En la captura no se ve video. Pero haberlo hailo.... de hecho esto es una captura hecha desde el propio gxine:



La mayoría de los canales son chinos pero por ejemplo es posible ver futbol de la liga española con un retraso de 5 a 10 minutos.... útil para las aburridas tardes de los domingos, aunque no me gusta demasiado el fútbol.

El paquete lo he descargado de esta web y me he permitido traducirlo a español y empaquetarlo como paquete debian.

Luego sólo hay que ir a alguna web [1] [2] [3] y mirar "qué echan".

Para el archivo TODO, falta hacer un manejador para firefox (protocolo sop://) que al picarlo cargue la url y abra el reproductor...





¡ Qué triste !
Pues como habeis podido observar en el anterior artículo llevaba sin conexión a internet en mi casa desde el 18 de marzo, no está mal que el 10 de abril hayan conseguido arreglarlo.

Estos días he estado comparando proveedores de internet con sus pros y sus contras, hace 2 meses era un feliz cliente de wanadoo hasta que llegó el corte, en este último mes habré llamado al servicio de atención al cliente muchas más veces que a mi anterior novia :P

Durante el corte tuve la suerte de recibir una llamada de una empresa cuyo nombre no recuerdo acerca de la satisfacción de clientes de telecomunicaciones, y digo la suerte porque puse a wanadoo bastante mal en TODOS los puntos, más tarde he descubierto que hay una comparativa bastante básica sobre los proveedores españoles y que wanadoo no es de las mejores valoradas.

Ahora me entero que durante el peridodo que no me han facturado (porque no me han dado servicio) me van a cobrar las llamadas y que me las descontarán el mes que viene... en fin, que no estoy para volverme a fiar de ellos ni un día más.

Por esto y varias cosas más ando en la búsqueda de nuevo proveedor de internet, me gusta bastante la oferta de ya.com con 4 Mb + llamadas que me regalan router wifi y me ahorro 10 euros al mes, aunque no le hago feos a Telefónica/Terra que aunque es la más cara supuestamente es la que mejor atiende a sus clientes. En una de las llamadas al 1004 me dijeron que la distancia a la central impide que llegue mucho más de los 4 Mb que tengo, así que ofertas de 20 Mb de Jazztel me dan la risa....

Por un momento pensaba en pasarme a la fibra óptica (Ono) pero ahora mismo no lo veo una opción de peso, el porqué, no lo se.

¿Qué proveedores teneis vosotros?
¿Os han hecho alguna "pirula"?
¿Qué compañía recomendarías a un amigo? ¿y a un enemigo?

Mañana hay apagón eléctrico por la tarde en la Escuela Politécnica, así que tanto mi blog como las webs que estan hospedadas por aquí no tendrán acceso hasta el miércoles 12 por la mañana si se acuerda alguien de encender los equipos. Idefix también entra en el saco.




Pxes y METAPXES
Como llevo más de 15 días sin conexión a internet en mi casa por culpa de unos verdaderos inútiles e ineptos, los fines de semana me estoy dedicando a desarrollar cosas nuevas. La cosa funciona así, viernes por la tarde aburrido, idea feliz y sábado y domingo convirtiendo la idea en código.

La semana pasada fué PyPersistente, «front-end» de cryptsetup para crear y montar home persistentes encriptadas, esta semana le ha tocado un repaso a PXES.

PXES es una tecnología desarrollada para el aprovechamiento de clientes livianos, por lo cual un equipo pentium 166 con 32 Mg de RAM puede conectarse a un servidor XDCMP (servidor gráfico) y ejecutar aplicaciones pesadas en un servidor de forma trasnparente para el usuario. El proyecto tiene y ha tenido un gran impacto sobre todo en cibercafés, aulas de libre acceso o incluso ahora en colegios e institutos para reaprovechar viejos equipos «las 3 R's» (Reciclar Reutilizar Reaprovechar).

Hace unos meses Diego Torres Millano, principal desarrollador de PXES, fue contratado por la empresa 2x.com quedando así Pxes con no menos que un futuro incierto. Se que ha habido correos en la lista LTSP-ES, explicando que iba a pasar con el proyecto pero a raíz de esto he conocido otras alternativas como LTSP, Diet pc, etc...

Pensando en reaprovechar código y viendo el enorme potencial aún sin explotar de initramfs-tools he programado una serie de scripts que crean un micro sistema Linux dentro del initramfs (20 megas) con servicios como inetd, ssh (todavía no he conseguido arrancarlo) telnet e incluso algunos script que escuchan en ciertos puertos. Además incluye el binario Xorg ( y otros necesarios) para que una vez configurado el equipo lance la sesión gráfica contra un servidor. El arranque es bastante rápido, en mi equipo de pruebas apenas tarda 20-40 segundos desde que acaba de leer el vmlinuz + initramfs hasta que se tiene el login de gdm remoto.

Ventajas sobre PXES:
  • La construcción del initramfs es muy intuitiva y somos nosotros los que decidimos que aplicaciones queremos meter en la imagen. Por ejemplo no sería muy complicado meter firefox (algo así como copy_exec /usr/lib/firefox/firefox-bin) /usr/bin y sus dependencias para que sea ejecutado desde la máquina tonta. (copy_exec es una función bash que copia el binari y sus dependencias => ldd /usr/lib/firefox/firexof-bin)

  • Usa un kernel debian, sin parches, con todas las ventajas del equipo de seguridad de debian, muy actualizado, con el soporte a todo el hardware nuevo. Mis pruebas han sido con el kernel 2.6.15-1-486, el que estoy usando en metadistros.

  • Ahora el soporte de sonido está en nuestras manos (se puede incluir esound o el demonio que queramos con sus dependencias)

  • Podemos meter en el kernel los módulos que necesitemos y obviar los que nunca vayamos a usar (raid, iptables, crypto, etc...)

  • Todas las aplicaciones que tiene nuestro micro sistema se copian de nuestro sistema real lo que conlleva a que se actualizarán a medida que actualicemos nuestro sistema base (que en la mayoría de los casos será el servidor)

Desventajas sobre PXES (alguna desventaja tiene que tener esto...):
  • Necesita más RAM, calculo, aunque no lo he probado, que el mínimo de RAM aumenta a 64 Mb, no es mucho problema ya que hoy un ordenador obsoleto puede ser perfectamnete algo con 64 o incluso 128 Mb de RAM.

  • Hay que valorar que se necesita dentro de la imagen y que se puede usar por red (incluso por nfs) para que el proceso de arranque sea menos pesado para la red. Si los terminales sólo se encienden una vez al día no es mucho problema.

  • Por si no hubiera pocos proyectos se une uno más la ventaja de este es que no se necesitan grandes conocimientos ni del kernel ni de hardware para que nuestra red de THIN CLIENTS funcione.

No os podeis imaginar lo que cuesta hacer cuatro líneas de código sin la ayuda de google......

Espero que os guste :P