Hoy gracias a la Debconf he tenido oportunidad de charlar un poco con Jose Luis Redrejo uno de los responsables de la implantación de Linex en Extremadura (España).
Nos ha dado una charla sobre como quieren organizar la educación gracias a Linex, como organizar los sistemas operativos, portátiles, terminales ligeros y otros temas.
Entre otras cosas comentaba que algunas de las aplicaciones se podían ejecutar en los terminales ligeros en local. En especial el firefox y quizás algún visor de videos. De esa manera no hay tantos problemas de streaming.
También comentaba que usaba nfs. Yo, sorprendido, le preguntaba por eso y le comentaba el trabajo de Mariodebian en TCOS que no empleaba nfs sino que lo cargaba en RAM.
Pues no era del todo así. Después de la explicación que me dio hete aquí como lo resumiría:
Primero estaba el ltsp que usaba el nfs para exportar el sistema completo.
Después del ltsp vino pxes. Pxes como novedad usaba la RAM del ordenador no sólo para ejecutar el servidor de las X sino para guardar el sistema operativo que solamente se enviaba una vez desde el servidor al cliente al inicio.
Comparese esto con ltsp que usa nfs y que necesita constantemente interactuar con el servidor.
Entonces apareció Tcos de Mariodebian que era algo así como un Pxes escrito desde cero. El sistema se cargaba a la RAM desde el inicio tal y como hacia pxes.
El tema es que, poco a poco, los terminales necesitaban funciones algo especiales para los terminales pero bastante normales para el usuario comun. A saber: Abrir un pendrive como si estuviera conectado fisicamente al servidor (en la práctica como si empleases ese ordenador sin darte cuenta de que en realidad trabajas desde el servidor). Activar el sonido en los clientes. Y, alguna vez, compartir impresoras.
Todas estas caracteristicas necesitan de programas especificos como pulseaudio que funcionan directamente en el terminal, es decir, consumen RAM del mismo. Entonces, ¿Qué pasa? Pues que el terminal se queda sin RAM.
¿Como se arregla esto? Se arregla con nbd. Nbd permite exportar desde el servidor un dispositivo de bloues que puede ser un disco entero, una partición, un archivo swap o, por ejemplo, un archivo squashfs. En tema de carga de red no es tan malo como nfs en la carga de la red y es read-only.
Así que el inconveniente que tiene es que si tienes que modificar algo en el cliente el cliente tiene que reiniciar porque tienes que volverle a enviar la imagen. También tengo que añadir que la imagen servida por nbd está comprimida con squashfs.
Tengo que añadir que en el caso de ltsp esa imagen de squashfs se monta, se mezcla, con el sistema de archivos raiz que se ha iniciado en RAM inicialmente. Para realizar esa mezcla en el caso de ltsp se usa aufs (evolución de unionfs).
Bien. Entonces en las versiones de desarrollo de ltsp empezaron a toquetear con nbd. En TCOS también se permitió habillitar NBD.
Así que volviendo al presente las cosas están así:
El ltsp5 hoy en día soporta ambos nfs y nbd. El tema es que, por ejemplo, el sistema por defecto en Debian es nfs y en Ubuntu han puesto por defecto el nbd.
Curiosamente el tcos no usa nbd sino que realmente descarga un fichero squashfs al inicio y lo carga en memoria. A partir de ahí el único tráfico que se genera es tráfico Xorg.
No obstante TCOS permite de forma automática que los sistemas con menos de 38 megas (este valor se puede variar) usen nfs.
Y añadir que en Ltsp5 al final usan un fichero squashfs (pero sobre NBD) inspirándose en el trabajo de Mariodebian.
Así pues seguramente en Extremadura reconfiguraran Ltsp para usar nbd en lugar de nfs y listos.
J.L. Redrejo habló en la charla sobre dos particiones. Una se usa y otra se sincroniza con una hipotetica actualización del sistema para evitar los problemas de los terminales pero con sus, más o menos, ventajas, pero eso, puede, que sea para otro post.
Actualizado: Aclarado concepto squashfs. Gracias a J.L. Redrejo por el apunte.
Actualizado(2): TCOS en realidad no usa NBD. Gracias a MarioDebian por el apunte.
adrian15's freedom quest 