MarioDebian, mi devlog

 

Thinetic Systems

Quería contar mis dichas y despichas en el desarrollo de la nueva MaX40 pero me veo un poco atado, por decirlo de alguna manera, por algo parecido a lo que sería secreto profesional aunque no sea tal.

Una de las condiciones que puse cuando fui contratado es que todo el desarrollo fuera abierto, y de hecho lo he conseguido, en gran parte, tenemos un SVN (sólo accesible por ssh) pero que se puede ver desde un TRAC, el repositorio tiene deb-src y todo lo que se sube se compila desde las fuentes (cuando es posible).

Hace un tiempo criticaba el sistema de distros españolas,  quejándome sobre todo de aquellos desarrollos que no eran transparentes y dando muy buena puntuación a la gente de Guadalinex y Emergya de los cuales tengo el enorme placer de ser amigo de varios de ellos. Creo que los ciudadanos tenemos el derecho de poder acceder al código que paga nuestra administración ya que lo pagamos todos y ninguna empresa tiene el derecho de hacer suyo ese código y menos poner trabas para que ni el mismo cliente pueda acceder a él.

MaX tiene la suerte de estar menos profesionalizada que el resto de las distribuciones, es algo serio, importante y que se usa mucho, pero no hay una gran empresa detrás, sino un grupo de voluntarios (profesores TIC) y varios desarrolladores, no más de 3 o 4 (alguno novatillo como es mi caso).

MaX también tiene sus problemas (supongo que como todas), el primero es la lucha a muerte primero por conseguir un arranque dual (en la Comunidad de Madrid se usa bastante el sistema de las ventanas) y segundo por conseguir atraer a gente que necesita huir de él, que cada día van siendo más. Esta labor la llevan muy bien y espero que en muy pocos años empecemos a ver sus frutos quitando para siempre el arranque dual.

Una de las muchas cosas que se ven cuando haces algo para la administración es la fuerza que algunos fabricantes de hardware o distribuidores de software hacen para que sus productos estén presentes (muchas veces tambien se hace al revés, pedirles permiso para incluir su producto), no quiero decir nombres ni marcas pero ya he visto casi todo lo que podía ver, drivers/aplicaciones desarrollados por novatos o becarios que se saltan a la torera todos los estándares, que editan archivos críticos del sistema, que se instalan en /miproducto (porque yo lo valgo) o que no incluyen los fuentes (algo que se entiende sino quieren hacerlo) pero que no permite confiar demasiado en lo que hace su binario.

Mis consejos en estos casos es la presión... recuerdo lo que me contaba mi amigo Rodrigo que trabaja en el CGA de Sevilla, no compraron tarjetas gráficas de determinada marca hasta que la empresa que las fabricaba desarrolló unos drivers decentes.

Esto me ha hecho pensar si ya va siendo hora de renombrar el blog (Bitacora de un desarrollador newbie) pero prefiero pecar por novato que no por chapucero. 

El mercado de Micorsoft poco a poco va decreciendo, cada día en los medios se habla más de software libre pero no nos engañemos, vivir del software libre aún es muy dificil (prefiero no hablar del proyecto TCOS o de nuestra empresa)

En fin, resumiendo, estoy muy contento de haber trabajado este año para la Comunidad de Madrid y espero seguir trabajando muchos más, el viernes voy a la feria Madrid es Ciencia, donde presentaremos la Max40-beta4 (nuestra release candidate 1) recién salida del horno, ya casi con los paquetes estables de Ubuntu Hardy y estaré allí hasta el domingo, si alguien de Madrid le apetece pasarse (la entrada creo que es gratuita) pabellón 14, stand 152 del IFEMA. El lunes y martes estaré en Zaragoza, vuelvo a las andadas, vuelvo a ser Willi Fog.

Ayer por la tarde acabamos de pulir lo que es la primera versión beta (Max4.0beta1) de la distribución educativa de la Comunidad de Madrid. Como muchos ya sabeis está basado en Ubuntu Hardy (8.04) que aún es beta y que será sino ocurre nada LTS (Long Term Support).

Esta versión trae muchas mejoras, algunas de ellas herdadas directamente de Ubuntu, como la nueva versión de NetworkManager (Max3.0 estaba basada en Dappe) donde no había estas cosas aún... GNOME 2.22, las nuevas Xorg 7.3, mejoras en niveles de seguridad con AppArmor y PolicyKit, en cuanto a aplicaciones, tenemos el gestor de control remoto VNC: Vinagre, gestor de Bittorrent: Transmission y en cuanto a multimedia, por fin, Pulseaudio y libflashsupport instalados por defecto.

La mejoras de Max4.0 son varias entre las cuales tenemos un instalador mucho más simple que el de Ubuntu, permitiendo seleccionar varios tipos de instalaciones, un tema gráfico bastante trabajado, disposición de menús similar a Max3.0 y actualizadas la mayoría de aplicaciones educativas (geogebra, atnag, jclic, etc...)

Incluso tenemos firefox3.0b4 con la localización en español (Ubuntu hardy aún no lo ha empaquetado) 

La parte de la que me siento más contento es la preinstalación de Max4.0 como servidor de terminales TCOS y clonado Backharddi. Digamos que seleccionando esta opción (y aunque no está terminado) se podría tener listo un servidor de terminales en 30 minutos. (las cosas que faltan por añadir es la configuración del servidor DHCP y la generación de usuarios remotos, además de un pequeño manual PDF para dejarlo en el escritorio del administrador y que lo lea una vez arranque la versión instalada)

Como las betas de la versión 3.1, en esta versión también es posible pasar de Ubuntu (Hardy, no valen otras) a Max, símplemente añadiendo el repositorio:

deb http://max.educa.madrid.org/max40 max main

Instalado el paquete max-keyring y luego instalando max-dekstop-all.

 

 

He hecho unas cuantas capturas de pantalla y las he dejado en nuestro TRAC: Introducción gráfica a Max4.0beta1 

Tengo un improvisado control de cambios en esta otrá página del TRAC: Max4.0 TODO

Espero que os guste, los enlaces para la descarga están en el TRAC.

Cuando aterricé en el mundo del software libre, y de GNU/Linux en particular, no entendía la necesidad de que hubiera tanta distribución o lo que es lo mismo distintas formas de «envolver» ese conjunto de herramientas, programas y archivos que hacen el sistema operativo. Con el tiempo he visto que esto tiene una razón de ser, y es que cada grupo de gente entiende la filosofía y la forma de trabajar de esas herramientas de una forma distinta.

Así es como nacieron muchas distribuciones, algunas aportando un valor especial que el resto pudo (o no) aprovechar (ventajas del software libre) y otras que remaron en una dirección equivocada y desaparecieron.

De un tiempo a esta parte y por diferentes razones me he visto en las tripas de algún proyecto y he visto las formas de trabajar y organizarse del grupo de desarrolladores, y aquí es donde quiero entrar a hablar sobre las distribuciones autonómicas.

Debian ha sido (y sigue siendo) la distribución base de todas ellas (aunque ahora con el nombre de Ubuntu). En su día cuando empecé a colaborar (por llamarlo de alguna manera) en el proyecto Metadistros me parecía genial que todos hubieran tomado lo mejor del proyecto y hubieran contribuido a solucionar los fallos que tenía o ampliar sus características.

Desde hace algo más de un año las distribuciones más importantes (sin contar Linex que sigue siendo Debian) se han ido pasando a Ubuntu (Guadalinex, Molinux, MaX, Lliurex...) y cada una ha ido remando para conseguir una distrubución sencilla de manejar pero en general sin compartir la base de su trabajo.

Las distribuciones autonómicas son desarrolladas por empresas (consultoras) que, contratadas por la comunidad autónoma correspondiente, se ganan un dinero (no voy a entrar si bien o mal, o mucho o poco, porque no lo sé) mediante el empaquetado, personalización, mantenimiento y demás complementos que indiquen «los que pagan».

Y digo yo, si esa distrubución la pagamos todos con nuestros impuestos, ¿no tenemos derecho a saber como está hecha y poder aprovechar parte de ese trabajo para que la distribución de la comunidad vecina no tenga los mismos fallos? Yo creo que sí, el problema es que se está dejando de lado la filosofía de software libre y esos programas que remasterizan la distro son los que dan de comer a los trabajadores de la consultora....

No todos son así, ni mucho menos conozco uno por uno los casos de todas, pero puedo decir que una sobresale sobre los demás y es el caso de Guadalinex donde el desarrollo es totalmente abierto e incluso se puede participar solucionando fallos, o simplemente fisgar sus «trucos» en un svn público. Mi más sincera felicitación al equipo de Emergya, y todos sus desarrolladores.


NOTA.- Puedo estar metiendo la pataza hasta el fondo (y rectificaré si fuera necesario), pero por lo que he estado investigando el resto de distros no comparten mucho de su «know-base».

NOTA-2.- Primer artículo del año: FELIZ AÑO NUEVO A TODOS.

Despues de mil dolores de cabeza he descubierto porque el servidor NFS se negaba a servir los directorios exportados así he descubierto que NFS no funciona sobre algo que no sea un dipositivo de bloques verdadero (una partición o disco)

Así con estas puedo anunciar que ya tengo listo SOLEUPIX-tcos-0.0.3 con las novedades de permitir arrancar los termianles tanto en modo normal (>= 64 Mb ram) como en modo NFS ( 32 Mb RAM). Otra novedad es el salto de versión del kernel al último de debian unstable => 2.6.17-2-486.

UPDATE (12-sep-2006 13:20)

Ya está lista la versión 0.0.3, que puedes conseguir junto a su md5 aquí.

UPDATE (23-oct-2006 11.30)

El md5 de la versión 0.0.3 no coincide, se ha actualizado el sistema y los paquetes de TCOS y ya está disponible la versión 0.0.4.

Cambios:

• He puesto un fondo de pantalla y un splash.... (no soy diseñador, ya lo sabeis)
• NFS arranca correctamente (terminales de 32 Mb, aunque parece que van a necesitar algo de swapeo...)
• Sonido va bien.
• Jclic va bien.
• y la más importante.... los usuarios se crean durante el arranque (desde tcos11 hasta tcos30)

YA PODEIS JUGAR CON TCOSMONITOR!!!!!


Como hace mucho que no ponía capturas y a la gente es lo que le gusta, aquí van unas cuantas. El gnome de momento está sin modificar, es tan dificil como ponerlo a gusto de cada uno, hacer un tar.gz de la home y guardarlo en el directorio META del cdrom (remasterizandolo se entiende).

UPDATE: Paso las capturas a la versión extendida.

Sigue...
 (Más)

Pues en una de esas ideas tontas que se le ocurren a uno, me ha dado por hacer una metadistro para que la gente se acabe de animar a probar TCOS, y todas las herramientas que tiene.

Al niño le hemos bautizado como SOLEUPIX-TCOS.

Básicamente es un livecd de 273 MB con un escritorio GNOME muy básico, navegador (Firefox), y Tcos con sus herramientas (TcosMonitor, TcosConfig, etc...), lo que convierte este livecd en un servidor de terminales de arrancar y funcionar (~0% conf).

Lo más sencillo de todo es que se arranca el livecd y seguido se arrancan los terminales, hay proyectos parecidos (ILEX, knoppix, etc..) pero este ocupa 273 megas y lo he hecho yo ;)

Las instrucciones completas para descargarlo y ejecutarlo en el wiki (de paso si alguien se anima a traducirlo a ingles, no tiene más que picar en el enlace SOLEUPIX-TCOS/en que aparece en rojo y escribir.


Aún estoy preparando la iso, dadme un ratillo para acabar....

UPDATE: Ya esta la iso y el md5 listos, si alguien sabe porque apache2 da un error 403 cuando tiene que listar un directorio (mod_autoindex) (ejemplo) estaría agradecido... Nos pasa en los dos servidores de la escuela SOLEUP e IDEFIX, con el apache2 de testing o de unstable, y en bug.debian.org parece no haber nada igual.

UPDATE2: Asunto apache2 solucionado. Resulta que en las nuevas versiones de apache cuando hay más de un virtual host hay que poner el ServerName a cada uno porque si no el apache no sabe por donde pillar la configuración de la raiz (o algo así)....

UPDATE3: Asunto apache2 de nuevo. Resulta que no son los virtualhost sino que no sabe cual es el archivo índice por directorio ¿BUG?, sólo hay que añadir la línea en negrita al archivo /etc/apache2/sites-avalaible/default

NameVirtualHost *
<VirtualHost *>
        ServerName idefix.eup.uva.es

        DocumentRoot /var/www/
        DirectoryIndex index.html index.htm index.shtml index.php index.php4 index.php3 index.phtml index.cgi

        <Directory />
                Options FollowSymLinks
                #IndexOptions NameWidth=*
                AllowOverride None
                Order allow,deny
                Allow from all
        </Directory>

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

Este artículo trata sobre la construcción de nuestra propia distro (basada en debian/ubuntu) para que funcione desde una memoria USB (pendrive).

Metadistros es la arquitectura para facilitar la creación de distros NO ES UNA DISTRO en particular. Al igual que existe la metaprogramación (programas que hacen programas) metadistros son herramientas que hacen distros...

Antes de empezar a soltar comandos o paquetes a instalar debo aclarar los siguientes puntos:

• Tan pronto como la web de consoltux esté montada colgaré el artículo de allí. (necesitamos pagerank !!!)
• Este «invento» ha sido presentado en la II Conferencia Internacional de Software Libre de Málaga (gracias a Ramón) así como el el II Congreso de las tecnologías en la educación TICC's celebrado en Valladolid estos días, donde he participado con Consoltux.
• Se puede decir que el desarrollo de esto no acaba más que empezar y aunque funciona puede contener aún muchos fallos.
  

• Mi blog no es un foro, es decir, en este artículo no voy a permitir los más de 80 comentarios que hice en el otro artículo sobre metadistros...
• Si quieres seguir el artículo y reconoces que no sabes mucho, DÉJALO. Busca algo hecho o espera a que alguien lo haga, por muchas ganas que tengas de aprender no es algo sencillo. Al final de esta página hay indicaciones sobre qué descargar y copiar a un pendrive.
  
• Complemento del punto anterior, para llevar a cabo una metadistro USB personalizada necesitas saber de shell scripts, compilar módulos del kernel, e instalar/empaquetar paquetes debian. En resumen: usar debian con los ojos cerrados.
  
• Saber descargarse código de un SVN.
• Saber configurar un debian EDITANDO ARCHIVOS DEL SISTEMA.

(Siento ser tan brusco pero hay gente que se mete a hacer cosas sin saber realmente lo que está haciendo: «zapatero a tus zapatos»)


El artículo es válido para ubuntu, PERO:

• Los paquetes de debian y ubuntu no son muy compatibles, si aún así te propones hacerlo en ubuntu tendrás que empaquetar tú mismo algunas cosas para tu distro. Yo no lo voy a hacer....
• En ubuntu breezy las versiones son menores que en debian testing o unstable.
• Ubuntu usa sudo para hacer laboras de administración puedes obtener un shell de root con «sudo -s»

Se que existen cosas hechas como DamnSmall o Feather Linux pero esto es más bien hacer algo a medida de cada uno... no usar algo que ya existe. Es como hacerse un traje a medida o comprarse uno hecho...

Xarnoppix tiene algo parecido a esto.

ACTUALIZADO 20 feb 17:30

Parace ser que en la vanguardia digital hablan del invento presentado en Málaga con el nombre clave «USEBIX». Gracias a Ramón de Iniciativa focus, y a Hispalinux con Roberto como comandante, y eso que me dijo que sólo lo habían visto algunos frikis...
 (Más)

Estamos a puntito de presentar una solución bastante innovadora hasta ahora, que es llevar nuestro linux en el bolsillo (justo lo que ocupa una memoria USB), junto con uno o dos programas indispensables para la vida de cualquier «technosexual» de hoy como es una aplicación de correo.

Imaginamos el caso de la persona que está todo el día moviendose entre oficinas de distintas empresas y que necesita además de estar comunicado no tener que cargar con un pc portátil. Una solución puede ser un pda pero vamos a otra solución aún más económica que es tener un pendrive (entre 256 Mb y 1Gb) en el que tenemos un Linux (debian por ejemplo) instalado y que podemos arrancar como un livecd => liveUSB en cualquier equipo donde estemos. Nuestros correos en una partición (archivo) encritados, así como laconfiguración del programa de correo. Con la posibilidad de conectarse a un servidor de terminales mediante nxclient, vnc o similares para aplicaciones más pesadas.

Las distros USB no son nuevas, lo que sí es nuevo es este nuevo punto de uso. Desde xarnoppix he tenido noticias de que se está usando algo muy parecido a lo que tengo yo. El problema más chungo que le veo es la posibilidad de hacer arrancar el equipo desde USB, ya que algunas BIOS, dar con la tecla es bastante complicado, en unas el pendrive es detectado como un disco duro y hay que cambiar el órden de boteo en la sección de discos duros, en otras, hay una opción llamada USB-HD, etc...

Es en esto en lo que estoy trabajando últimamente, con el fin de presentarlo en el próximo congreso de la FERE sobre TIC. Hace unos días recibí la llamada de Roberto Santos interesándose por el proyecto y dándome algunas ideas (sino conoceis a Roberto, os estais perdiendo una gran persona, y el mejor brainstorming que conozco), a los pocos días se puso en contacto conmigo Ramón Ramon, Analista-programador de la UNED en Málaga, y participante de la Conferencia Internacional sobre Software Libre que se celebra dentro de 15 días en Málaga. Me han propuesto presentar allí el invento del pendrive e incluso instalarlo en los pendrives que lleve a gente desde su stand.

No todo puede ser bonito, por entonces coincide el congreso TIC de la FERE por lo que, lo primero es lo primero y como núcleo de Consoltux que soy creo que mi lugar está en este congreso. Las fechas casi se solapan y aún barajo la posibilidad de hacer una escapada a Málaga un par de días antes...

Así que manos a la obra he empezado a crear una imagen tan pequeña como pueda de una instalación base de debian con las Xorg, thunderbird y un escritorio ligero (estoy entre blackbox, xfce4, fluxbox, icewm...) La idea es que ocupe comprimido como mucho 100 megas para poder ser usado en un pendrive de 256 con el archivo encriptado de la home persistente. Intentar meterlo en un pendrive de 128 Mb va a ser una labor muy dura.. quizás haya que remasterizar un damnsmall o un featherlinux... pero con eso ya se pierde la idea de METADISTRO.

Espero tener muy prontito una pequeña imágen funcional para que puedan redistribuirla desde Málaga, tal como comenta Ramón en su blog.

ACTUALIZACIÓN (2 Feb 2006 17:34):

Parece que no ha quedado claro el concepto, copio y pego del comentario que hay más abajo:

Como dice la canción no es lo mismo.

Imagina que necesitas un traje. Tienes varias formas de hacerte con uno:

1.- Vas a la tienda XXXXXX y te compras uno.
2.- Vas a un sastre y te haces uno a medida.
3.- Haces un curso de corte y confección de 1 hora y te lo haces tu a tu gusto y medida.

¿Cual es mejor? pues mira, depende de lo que necesites el traje y de la pericia que tengas con la aguja... ( y pude también del sentido del ridículo...)

Metadistros es un proyecto que consiste en hacer una serie de programas, paquetes, scripts, etc... para hacer distros.

METADISTROS NO ES UNA DISTRO MÁS.

Metadistros es como la metaprogramación (hacer programas que hacen a su vez programas, como por ejemplo ROR:ruby on rails)

Damnsmall y distros parecidas es el traje que te compras en la tienda y que es como es, si necesitas arreglarle la bastilla o te queda corto no puedes hacer nada más que buscar otro.

Metadistros es una mezcla de sastre y curso de confección ya que es una distribución hecha por tí a medida pero con ayuda de alguien que ha programado ciertas cosas para que sea mucho más sencillo todo.

Espero que ahora si se entienda la diferencia.

Después del tutorial de metadistros y la gran aceptación que ha tenido y visto que en el calzador de Guadalinex poco se puede hacer ya, ya que su funcionamiento es perfecto me estoy dedicando a nuevos sistemas.

Se nos ha ocurrido ( Equipo I+D de Consoltux ) la genial idea de usar el calzador desde una memoria USB. Las diferencias sobre un cdrom son muchas pero el pseudocódigo del arranque es similar.

Como inconveniente creo que sólo he encontrado la posibilidad de que los equipos no tengan arranque desde un dispositivo USB, pero mi portátil que tiene ya dos años si lo tiene, así que supongo que cualquier pc medianamente nuevo y con una BIOS seria tenga esa posibilidad.

Ventajas muchas:

• Sistema operativo en el bolsillo
• Posibilidad de escribir en el pendrive la configuración
• Posibilidad de crear un directorio persistente rw y olvidarse para siempre de instalar linux.
• Menor desgaste que en un cdrom que es propenso a sufrir rayones o deterioro.
• Sistema de archivos FAT 16/32, por lo que se puede leer/escribir desde winbugs (posibilidad de hacerlo como ext2 o jffs2)
• Poder usar apt-get / aptitude / synaptic desde el USB sin/con instalación permanente
  
• Prueba rápida de Linux en equipos.
• Ahora sí, las prácticas en la universidad pueden hacerse donde se quiera (primero habrá que convencer a los docentes a que usen GNU/Linux)
  

Mis primeras pruebas se basan en:

Equipo (servidor Soleup)

• Pentium IV 2.400 MHz
  
• 1Gb de RAM
• Tarjeta gráfica integrada sis
• Tarjeta de red 3com
• Pendrive Toshiba 1Gb 2.0-USB.
  

Sistema

• Instalación base de debian etch(udev discover...)
• kernel 2.6.14-2-386 (en breve migraré al 2.6.15 que parece que ya es estable)
• Xorg
• Xfce4 + Gdm
  
• Firefox
• OpenOffice.org (versión 2.0 de debian)
  
• Calzador de Guadalinex modificado para arranque de USB.

Resultados (cronómetro en mano)

• Arranque desde pulsar Intro en grub hasta tener el escritorio de xfce preparado: 1 minuto 0 segundos.
• Arranque Firefox: 3 segundos
• Arranque OpenOffice.org Writer (en español): 8 segundos.

Intentaré hacer las pruebas con algo más serio como bootchart disponible como paquete debian.

Las pruebas de velocidad con hdparm dan más de 800 megas desde cache y casi 10 megas sin cache.

Como se puede observar por estas pruebas los resultados son impresionantes, y ganan por goleada al arranque desde cdrom, el acceso a datos desde cdrom es casi secuencial pero el acceso a una memoria flash es aleatorio real.

Las modificaciones al calzador original han sido carga de controladores SCSI y USB y espera a que el dispositivo esté listo, además he descubierto que en equipos con SATA hay que saber si accedemos a un disco USB o SATA mediante el archivo /sys/block/xxx/removable. Con un bucle de espera ya está solucionado. Otro añadido que he hecho es que durante el arranque se descomprime un archivo home.tar.gz guardado en el pendrive por lo que tenemos la configuración del usuario fuera del skel y fuera del squashfs por lo que la personalización es externa a la metadistro.

En unos días espero tener el código lo suficientemente presentable como para poder colgarlo además de colgar un archivo comprimido con un squashfs de prueba y las instrucciones para preparar/instalar un USB-live.

Se que hay varios proyectos que han hecho esto pero, mi idea de reinventar la rueda me ha hecho ceñirme a lo que ya existe de Guadalinex y modificarlo, la verdad no se como funciona feather linux, catux o similares. Creo que no usan kernel estándar y que no usan grub. Quizás en esta versión pueda incluso incluir Super disco Grub, ya que el autor del programa ya se había interesado en incluir su paquete en Soleupix.

Ya me contareis que os parece la idea, inconvenientes/ventajas que he pasado por alto y los resultados obtenidos.