MarioDebian, mi devlog

Resulta que desde hace ya varios días estoy intentando adaptar o por lo menos hacer funcionar TCOS sobre ubuntu. No me considero un hacker pero tampoco un usuario novato por lo que creo que las cosas que voy a contar tienen cierto peso.

He instalado en un chroot la última versión "Edgy" y he empezado a compilar todos los paquetes de TCOS en ubuntu, después de innumerables dependencias parece que todo instalaba bien sin forzar nada.

En el chroot he instalado los paquetes ubuntu-live y todos los de TCOS y PulseAudio.

Me dispongo a generar las imágenes que usarán los terminales con gentcos -tftp -allmodules y gentcos -nfs -rootfs cuando salen una manada de errores impresionante.

1.- Parece ser que no hay X instaladas, pues instalar xserver-xorg y xorg.... ubuntu-live depende de ubiquity (el instalador) y no depende de xorg ??? mal empezamos. Uno espera, cuando va a hacer un livecd basado en ubuntu, que tomando ubuntu-base y ubuntu-live ya tiene TODO lo que necesita para arrancar.

2.- En debian grub se instala en /usr/sbin y /usr/lib/grub, pues para ser retorcidos en ubuntu lo instalan en /sbin y /lib/grub ??? lo he solucionado haciendo unos if en los scripts de construcción de la imagen.

3.- Si desinstalas discover1 para instalar discover (tcos lo necesita porque no depende de perl) se carga los metapaquetes de ubuntu-base, xserver-xorg y alguno más, antes miré si se llevaba algún archivo pero parece que no.

4.- El paquete alsa-base de ubuntu edgy y el de debian unstable se parecen también bastante poco, los scripts de arranque y la forma de llevarse con modprobe son distintas (otros cuantos if)

5.- El binario dhclient3 de ubuntu parece ser que usa el usuario dhcp para no ejecutarse como root por lo que me obliga a meter un /etc/passwd /etc/shadow dentro de la imagen, cosa que antes no hacía.

6.- Los binarios que hay en /lib/udev cambian de nombre por lo que no es ni siquiera viable pensar en incluirlos...

7.- El apt que lleva edgy me dice que hay paquetes que no se usan y que ejecute apt autoremove. No se si esto entrará en debian pero lo veo harto cansino ¿no habíamos quedado que aptitude elimina las dependencias que no se necesitan cuando se desinstala algo? ¿apt lo está imitando?
.....

Consigo solucionar casi todo de manera que hasta que no arranque no puedo probar si realmente funciona.

No quería usar casper para generar un livecd y probarlo por lo que he adaptado también mi versión del calzador de metadistros.... y aquí han llegado más problemas....

1.- el udev de ubuntu en cuanto arranca no hace las labores coldplug ya que hasta que no ejecuto MANUALMENTE udevtrigger no se crean los dispositivos hda hdb hdc o /dev/disk/... pues nada un hack todo guarro:

# hack for ubuntu udev
if [ -x /sbin/udevtrigger ]; then
  log_begin_msg "Wait until livecd devices are ready"
  /sbin/udevtrigger

  # wait until some devices creation
  follow=0
  while [ $follow = 0 ]; do
    sleep 1
    if [ -d /dev/disk ]; then
      follow=1
      break
    fi
  done
  log_end_msg
fi

2.- Una vez hecho esto edgy es incapaz de arrancar un tema cualquiera de usplash y me sale con el test ese que se parece a la carta de ajuste. Aquí no hay hack que valga, lo dejo por imposible. La nueva versión de usplash parece no pillar los temas...

3.- Aleatoriamente y sin causa aparente algunas veces que arranca el livecd dice que no existe /dev/ram0 y otras si, :| pofale, el mosqueo es ya bastante gordo.

4.- En debian no hay problema con el arranque de gdm (dnetro de una jaula, fuera, en un unionfs...) , en ubuntu simplemente se lanza pero no va y además no veo logs por ningún sitio :( así que al principio de /etc/init.d/gdm he metido otra chapuza de las mías:

# hack for start UBUNTU TCOS
if [ -f /.dirs/dev/META/settings.conf ]; then
 . /.dirs/dev/META/settings.conf
 XUSER=$conf_username
 su -c "startx" $XUSER
 exit 0
fi

Una vez en ubuntu (después del calzador y el initramfs) el cdrom es accessible desde /.dirs/dev y lo que hace esto es ejecutar startx como el usuario que esté configurado en ese archivo. Problema, el gdm en ubuntu, para aparentar que carga antes el sistema, se ejecuta muy pronto (S13) y todavía no se han configurado dbus hal y compañia (S20), muchos más problemas....

5.- Despues de arrancar las X intento lanzar tcosmonitor y se queda congelado, la última línea del debug dice algo como TcosDBusClient() starting client... por lo que sospecho que el dbus de ubuntu o no ha arrancado bien o no le gusta mi archivo de configuración o directamente pasa de mi. :( He probado a reiniciar dbus y sigue igual. (a propósito si se reinicia dbus a mano parece ser que a nautilus no le gusta y se muere, esta es la forma en la que he conocido el nuevo bugbuddy)

No me parece nada bien que se haga una herramienta como esa (Bug Buddy) sabiendo que no todo el mundo usa un escritorio en inglés, por lo que si alguien con muy buenas intenciones y un poco novato lo ve, escribirá lo que estaba haciendo cuando el programa hizo pofff en su lengua materna, desconozco si el bugzilla de gnome soporta bugs en idiomas distintos del inglés... sino, caerán en saco roto. Me quedo con el anterior diálogo de gnome 2.14 en el que se puede escoger que hacer (reiniciar, cerrar, informar)

Resumiendo, estoy a menos de un pelo de rendirme y mandar ubuntu a tomar por el saco, para escritorios, para gente que no tiene ni pajolera idea, para frikis ubuntu está muy bien (mi hermano lo usa con Xgl y el último compiz-beryl) pero una vez que le empiezas a hacer perrerías casca por todos los sitios. Larga vida a debian, hasta siempre ubuntu.

Si alguien (usuario o desarrollador de Ubuntu) se anima, quizás pueda ayudarme a solucionar los problemas que me faltan, sino TCOS funcionará sólo en Debian... eso sí al 110%, ya que en debian funciona perfecto.

Si normalmente leeis este humilde blog, habreis visto que una de las últimas mejoras de TCOS es el acceso a dispositivos extraibles en el terminal mediante una mezcla (bastante rara) de udev, shell scripts, XMLRC y python.

Pues bien tcos-devices, que dista mucho de ser perfecto, tenía algún fallo que he ido descubiendo poco a poco:

• Memorias USB con más de una partición
• Memorias sin etiqueta (LABEL)
• Autenticación
• Refresco de 1 segundo, mucha carga
  

Si la memoria USB tiene varias particiones iba montando todas una encima de otra en el mismo punto de montaje, hay muy pocos que usen más de una partición pero si nos vamos a discos duros USB, mp3's, o cámaras de fotos, la cosa no es tan general, así el primer arreglo es mirar si el directorio que vamos a usar existe (mal asunto) y buscar otro acabado en -X (siendo X un número) hasta que no exista (el comportamiento anterior de gnome-volume-manager, por ejemplo, usbdisk-1, usbdisk-2)

No es muy usual que una partición de las memorias USB tenga etiqueta así que el punto de montaje será primero la etiqueta y si no el fabricante (siguiendo la regla anterior)

Para el tema de autenticación es donde más horas de neuronas he metido, no sirve la misma autenticación de tcosmonitor ya que el usuario y contraseña son de administrador de todos los terminales (habría que duplicar por todas las home de usuarios y sería muuuuyyyy inseguro), así que tenía que pensar otro método rápido que comprobase si la persona que intenta usar el disquete está sentado delante del equipo donde ha metido el disquete (esto en PXES es como la casa de «tocameroque», ya que metes el disquete en un terminal y lo puedes leer desde cualquiera, cosas de "sambas" mal configurados...)

Pensando otras formas me acordé que ltspfs usa la cookie de las X, he leido montones de páginas man (xauth, Xserver, mcookie, Xauth, Xau, Xsecurity) y algunas webs [1], y ya lo refinitivo, el código fuente de varios paquetes: libxau6, mtools, floppyd.... Total que al final he decidido usar parte de ltspfsd pero sin sockets, una función simple que reciba una cookie, la guarde en un archivo temporal exporte la variable de entorno XAUTHORITY a ese archivo temporal e intente conectarse mediante XOpenDisplay, si conecta se deja usar USB, disquetes, cdrom, sino se devuelve un error. Al final el código de xauth no ha quedado muy mal... En el terminal y por medio de python se captura la cookie de sessión y se procesa con una nueva clase TcosXauth.py

Al obligar a la autenticación, la cantidad de datos que se envian y reciben aumenta por lo que he tenido que disminuir el intervalo de escaneo del demonio USB, a 3 segundos, que en el peor de los casos ese será el retraso entre enchufar un pendrive y que empiece a detectarlo, en el mejor de los casos puede ser 0.

Resumen de la autenticación:

1. tcos-devices, por medio de TcosXauth lee la cookie que coincida con su $DISPLAY
2. Prueba a conectarse con ella con la función TcosXauth::test_auth()
3. tcosxmlrpc recibe esa cookie y el hostname, crea un archivo .Xauthority temporal e intenta abrir la pantalla
4. Si falla devuelve error, en caso contrario devuelve OK.
   
5. Si falla la xauth tcos-devices se cierra sino empieza a ejecutarse el demonio
6. Cada 3 segundos (intervalo sujeto a cambios) tcos-devices le pide a tcosxmlrpc un resumen de los eventos USB de udev
7. tcosxmlrpc lo envía, si está vacío se esperan otros 3 segundos, sino se buscan los eventos programados (básicamente BUS=usb y ACTION=add/remove)
8. Se lanza el evento que corresponda en un hilo (thread) así si tiene un problema no congela el demonio o no lo cierra.
9. El evento termina y se guarda en un diccionario el dispositivo y el punto de montaje para cuando se desmonte.
10. Vuelta a empezar....

De paso con la autenticación por cookies he eliminado el parámetro -ac del arranque de las Xorg por lo que ahora los terminales tienen unas X seguras que sólo pueden usar ellos y el administrador de red mediante tcosxmlrpc. Hoy no hay capturas como no sean de gedit....

Ya he montado un pequeño video mostrando como funciona tcos-devives.

Screencast de tcos-devices mostrando acceso a unidades.

Una de las cosas más útiles y que peor funcionan en las redes de clientes ligeros es el acceso a los dispositivos locales (soluciones como samba o mtools no me acaban de convencer), en TCOS, he añadido soporte para varias formas de acceder a los dispositivos remotos:

• ltspfs: que pertenece al proyecto LTSP y que por medio de la autenticación de las XWindow y FUSE monta el sistema de archivos remoto en un directorio local.
• shfs: no pertenece a ningún proyecto pero vengo usándolo desde hace un tiempo, es un módulo del kernel que permite por medio de SSH montar un sistema de archivos remoto en local.

Cualquiera de las dos soluciones esta muy bien, pero ¿qué pasa con la comunicación terminal-sesión de usuario? En LTSP están usando su propio gestor de eventos parecido a dbus (lbus), y en PXES directamente no se usa nada, cuando quieres leer lo montas con samba (cuando funciona).

En TCOS aprovechando que uso XMLRPC para casi todo, he programado una pequeña aplicación que se ejecuta dos veces, una como demonio (y automonta todo lo que sea USB como pendrives, mp3, cámaras de fotos) y otra que se queda residente en la barra de tareas y permite montar el disquete o el cdrom (de momento uno, es trivial que funcione con más de uno). La aplicación la he bautizado como tcos-devices.

Aquí unas capturas del invento funcionando:

1.- Se ve en la bandeja del sistema el icono TCOS, que dice que está atendiendo las señales del equipo tcos27, lo que sería el terminal ligero. Para el modo demonio, funciona gracias al udev que se ejecuta en el terminal y una pequeña regla que guarda algunas variables de entorno de udev en un archivo que a intervalos regulares leo por medio de XMLRPC.



De repente conectamos una memoria USB, (parece ser que en las nuevas versiones de vmware-server lo toma directamente si tiene el foco y no se apodera el sistema anfitrión, antes había que descargar los módulos en el sistema anfitrión para que vmware usase los dispositivos...) Desde la conexión hasta que se monta y aparece todo pasan alrededor de 3-4 segundos, y es que udev tarda un ratillo en darse cuenta.



Como se ve en el escritorio crea un directorio (cuyo nombre es la etiqueta del pendrive si tuviera o sino la marca, este tiene una etiqueta USB-LIVE) además crea un archivo *.desktop que al ejecutarlo desmonta y limpia todo para dejarlo como estaba, permitiendo así una extración segura. He usado python-notify para mostrar los mensajes, y además de quedar más chulo es mucho más sencillo para saber que ocurre en cada momento.

Si pulsamos ese icono desktop, ocurre lo siguiente:



Cuando se monta algún dispositivo se abre el gestor de archivos del escritorio que se esté usando:

gnome -> nautilus
kde -> konqueror
xfce4 -> Thunar

Si se desenchufa a lo bestia (porque solo hemos leido cosas) también se desmonta todo.



Los disquetes y los cdrom no generan eventos UDEV cuando introducimos un medio para leer/escribir, es por esto que al pulsar en el icono de la bandeja del sistema aparece la otra parte que os hablaba al principio, el gestor de disquetes y cd's:



Vamos a montar un disquete.....



... y ahora un cdrom...



No viene al caso pero el cdrom usado para las pruebas es la iso de SuperGrubDisk ;)
Si tengo un rato instalaré x11vnc en el terminal, y haré una pequeña demo (screencast) con vnc2swf...


A todo esto han entrado hoy en debian unstable las Xorg 7.1 y parece ser (segun el log) que tengo el AIGLX activado lo que no he podido es compilar compiz y la versión de ubuntu me dice que falta una extensión GXL_COMPOSITE (supongo que por no usar los ultimos paquetes mesa) sería la repanocha que con la mierda de gráfica que tengo (via KM400) funcione compiz con aiglx. De momento me conformo con la aceleración gráfica de 400 fps.

Pues bien, después de muchas pruebas ya he instalado y probado TCOS en un entorno real, un aula de 24 terminales.

Aula Magna de la Escuela Universitaria Politécnica de Valladolid:

• 24 terminales Pentium II 350 64 Mb de ram, disco duro de 2.1 Gb, tarjeta de red integrada INTEL con soporte PXE, 2 USB, tarjeta de sonido integrada, posiblemente ISA, compatible sound blaster, segunda mano, precio 30euros más IVA cada uno. Monitores de 17" o 19" de segunda mano. Teclados nuevos, ratones ópticos nuevos.
• Servidor (conocido como idefix) Pentium IV 3.200 con 2Gb de RAM y dos discos SATA de 160 Gb. Tiene algo más de dos años. Distribución DEBIAN testing.
• Red de la Universidad con routers Cisco 10/100/1000
• Algunas tomas de red o de alimentación no funcionan por desperfectos varios (es un aula destinada a estudio, exámenes y de libre acceso) los puestos funcionales son 21.
• Tcos: última versión 0.54.5
• TcosMonitor: versión 0.0.14.pre1
• Tiempo de arranque medio entre descarga del kernel y conexión gdm 40-50 segundos, con usplash parece más corto.
• Escritorio usado: Xfce 4.3.90
• Posibilidad de usar swap local ya que los discos de los terminales no tienen nada.
  

Aquí unas cuantas fotos:







Esta es la que más me interesa, TcosMonitor funcionando sobre los 21 terminales:



Se puede ver a más resolución aquí.

Arranque de algunos con usplash:




Escritorio xfce con iconos:





Todas estas fotos y alguna más se pueden ver a mejor resolución ( y algunas borrosas ) aquí.

Como anécdota decir que con la pedazo cámara que era, las fotos no salen muy bien (será mi pulso) y como segunda anécdota decir que he copiado las fotos desde un terminal (el servidor está en otro sitio).

Con pyhton el tema de programación multihilo es bastante delicado, sobre todo cuando estamos programando interfaces (pygtk, pyqt) ya que si tenemos varios hilos en ejecución y dos de ellos o más acceden al interfaz para cambiar algo podemos tener errores aleatorios (errores de X11 async, o incluso violaciones de segmento)

Para TcosMonitor necesitaba de alguna manera algo que bloquease el lanzamiento de nuevos hilos en determinadas circunstancias, por ejemplo, al descargar información de un equipo, si se seleccionaba otro antes de acabar el primero, se obtienían errores bastante raros....

He estado reescribiendo algunas partes multihilo, y ahora todas ( o casi todas ) usan una clase que había programado casi al principio pero que no usaba porque no funcionaba bien. La clase se llama Workers y tiene un perro guardian que si se activa, lanza otro hilo esperando que acabe la función que hemos ejecutado para así hacer de bloqueo en nuevas peticiones. En los threads de python existen los bloqueos y los semáforos pero creo que no es necesario complicarse tanto ya que el perro guardián hace la misma función y es desactivable desde la llamada. Pequeño ejemplo (se puede descargar del svn: prueba.py):

# -*- coding: UTF-8 -*-

from time import sleep

from threading import Thread


class Workers:
    def __init__(self, main, target, args, dog=True):
        self.dog=dog
        self.main=main
        self.target=target
        self.args=args
        if self.main.worker_running == True:
            print "worker() other work pending"
        else:
            print "worker() no other jobs"
            self.th=Thread(target=self.target, args=(self.args) )
            self.__stop=True
    
    def start_watch_dog(self, dog_thread):
        if not self.dog:
            print "start_watch_dog() dog DISABLED"
            return
        print "start_watch_dog() starting watch dog"
        watch_dog=Thread(target=self.watch_dog, args=([dog_thread]) )
        watch_dog.start()

    def watch_dog(self, dog_thread):
        print "watch_dog()  __init__ "
        dog_thread.join()
        self.set_finished()
        print "watch_dog() FINISHED"
        
    def start(self):
        if not self.dog:
            self.th.start()
        else:
            
            if self.main.worker_running == False:
                self.th.start()     # start thread
                self.set_started()  # config var as started
                self.start_watch_dog(self.th) # start watch_dog
            else:
                print "worker() other work pending... not starting"
    
    def set_finished(self):
        self.__finished = True
        self.__stop=False
        self.main.worker_running=False

    def set_started(self):
        self.__finished=False
        self.__stop=False
        self.main.worker_running=True


class Prueba:
    def __init__(self):
        self.worker_running=False

    def con_perro(self):
        # ejecución con perro guardian
        self.worker=Workers(self, target=self.hacer_algo, args=(["soy el proc 1"]) )
        self.worker.start()

        # lanzamos un nuevo proceso despues de 2 seg
        sleep(2)
        self.worker=Workers(self, target=self.hacer_algo, args=(["soy el proc 2"]) )
        self.worker.start()

    def sin_perro(self):
        # ejecución con perro guardian
        self.worker=Workers(self, target=self.hacer_algo, args=(["soy el proc 1"]), dog=False)
        self.worker.start()

        # lanzamos un nuevo proceso despues de 2 seg
        sleep(2)
        self.worker=Workers(self, target=self.hacer_algo, args=(["soy el proc 2"]), dog=False)
        self.worker.start()
    
    def hacer_algo(self, arg1):
        print "::::::::::::::haciendo algo....arg1="%s"" %(arg1)
        sleep(4)
        print "::::::::::::::hemos acabado arg1="%s"" %(arg1)
        # avisamos a worker que hemos acabado (por si no tenemos perro)
        self.worker.set_finished()

if __name__ == "__main__":
    print "CON PERROS"
    Prueba().con_perro()
    sleep(10)
    print "nnAHORA SIN PERROS"
    Prueba().sin_perro()
    sleep(10)

Lo que vamos a hacer es ejecutar una función ociosa que por ejemplo tarda 4 segundos en ejecutarse.

Nos pueden ocurrir dos casos, primero, que no permitamos que una segunda llamadase ejecute si la primera no ha terminado o que sí.
Prueba().con_perro() no permite que la segunda llamada a la función se ejecute ya que sólo han pasado 2 segundos desde que comenzó la primera (que necesita 4), en Prueba().sin_perro() tenemos deshabilitado el perro guardián y dejamos que se ejecuten ámbas. Esta es la salida de consola:

$ python prueba.py
CON PERROS
worker() no other jobs
start_watch_dog() starting watch dog
::::::::::::::haciendo algo....arg1="soy el proc 1"
watch_dog()  __init__
worker() other work pending
worker() other work pending... not starting
::::::::::::::hemos acabado arg1="soy el proc 1"
watch_dog() FINISHED


AHORA SIN PERROS
worker() no other jobs
::::::::::::::haciendo algo....arg1="soy el proc 1"
worker() no other jobs
::::::::::::::haciendo algo....arg1="soy el proc 2"
::::::::::::::hemos acabado arg1="soy el proc 1"
::::::::::::::hemos acabado arg1="soy el proc 2"

Como puede verse en la primera parte se detecta que ya hay algo funcionando y no se deja arrancar lo siguiente. Este tipo de clase rechaza las llamadas consecutivas, se podría haber hecho una cola FIFO para no perder esas llamadas pero creo que para TcosMonitor complica las cosas más que mejorarlas.

El otro día junto con Maci y FChip estuvimos pensando que otras cosas necesitaba TcosMonitor y una que se nos ocurrió es un gestor de volumen, algo hasta ahora imposible, para controlar por red, la tarjeta de sonido de los terminales y no sólo los canales que controla PulseAudio. Espero que el desarrollador de PulseAudio prepare una librería en python para usarlo desde mi código.

Como ya tengo mucho trabajo hecho en xmlrpc he creado un nuevo metodo que recibe acciones y parámetros para después llamar a amixer a traves de un script.

En python programar luego unos controles de volumen y unas casillas para los mute son cuatro líneas.... (¿como puedo traducir mute? ¿mudo? ¿enmudecido? ¿sin sonido?)

Así que ahora hay una nueva sección dentro del apartado información llamada servidor de sonido, que cuando carga muestra algo como esto:




Ni más ni menos que un control de volumen mediante deslizadores, y casillas. No aparecen todos los controles, sino sólo los más importantes.

Además por debajo de esto aparece información sobre el servidor PulseAudio, como consumo de memoria, el sink y el source, y el tipo de salida en MHz
Los botones lanzan las aplicaiones del PulseAudio que ya os he enseñado otras veces: paman, pavucontrol, pavumeter.



Esta captura vuelve a ser desde dentro del vmware-server con una máquina virtual de 64 Mb, como veis he programado una nueva aplicación: tcos-volume-manager que muestra y permite modificar el nivel de volumen y estado del mute de todos los canales, tanto los más normales como los extra (phone, video, capture, mic boost, etc...) Lo bueno que tiene es que lee la variable DISPLAY y se intenta conectar al servidor TcosXmlRpc en esa misma dirección (sino puede, dará un mensaje de error) En un principio pensaba que iba a ser demasido lento la modificación de los niveles pero cuando solo permites que se envíe la petición cuando se suelta el ratón (o con la rueda del ratón no se hace demasiado lento)

 

Creo que con todas estas cosas Tcos tiene muchas más ventajas que LTSP o PXES, y empiezo a considerarlo un proyecto bastante maduro, cada vez salen menos fallos tontos de programación y cada vez tiene mejor pinta. Supongo que va siendo hora de empezar a documentar todo el invento y hacer un artículo que debo a un amigo y un tutorial de instalación y uso.

El otro día estuve con Jorge (aloriel), enseñando y probando TcosMonitor en nuestro pequeño banco de pruebas de la Universidad y la verdad o me engaño o le ha gustado bastante el nuevo jugete. De paso estuvo revisando las cosas que le gustaban y las cosas que no, y una de ellas es que quedaban un poco feo lo que se dibujaba en el cuadro de texto inferior.

He estado buscando la manera para que el contenido de un gtk.TextView fuera un poco más elegante y la he encontrado (en parte). Resulta que un desarrollador de gnome ha escrito una clase htmltextview.py que hace una pseudo conversion de algunas etiquetas html para insertarlas en un textview.

Así he añadido alguna cosa más para poder usarla y eliminar el antiguo textview que usaba, quedando mi htmltextview.py, las diferencias son básicamente dos, he añadido el atributo file a la etiqueta img (ya se que en html no existe) para que en vez de usar urlib para descargar las imágenes pueda tomarlas del disco duro, ya vereis en alguna captura luego para qué he usado esto, y la otra mejora que he hecho a la clase es aceptar el objeto input con el atributo type='button' para, ni más ni menos, insertar botones, algo bastante sencillo antes pero que ahora se ha complicado bastante....

UPDATE: He metido las capturas en la versión extendida del artículo, por lo visto ahora que salgo en el planeta.debian.org no le gusta demasiado las imágenes que genera plog.

Sigue...
 (Más)

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)

Despues de unos cuantos días de trabajo acabo de subir al svn (y en breve colgaré los paquetes deb y tar.gz) de nuevas versiones de estos programas.

Ámbas tienen un gran desarrollo y notables diferencias con las anteriores, por ejemplo:

initramfs-tools-tcos 0.54.1:

* Mejorar / añadir soporte para arranque NFS ( al estilo LTSP ), ahora con TCOS es posible arrancar terminales de menos de 28 Mb de RAM
* Arreglar el autopasswd del arranque (faltaba el archivo /etc/login.defs)
* Reorganizar scripts de arranque para que sean usados por tcos o tcos-nfs
* Crear un archivo /tftpboot/tcos/pxelinux.cfg/default con más ejemplos.
* Muchos cambios en el script de construcción gentcos. Uso:
- gentcos -tftp (genera imágenes para arranque con >= 64 MB)
- gentcos -nfs (genera imágenes muy pequeñas >=16 MB para arranque por NFS)
- gentcos -rootfs (genera el sistema de archivos que se exportará por NFS)
El mejor modo para generar arranque NFS la primera vez es gentcos -nfs -rootfs
* Mejorado el soporte para PulseAudio, ahora permite pasar como argumento la calidad de sonido del enlace, además el arranque es más silencioso.
* Actualizada la página man de gentcos
* Cambiar editar initramfs.conf por exportar variables.
* Cientos de minibugs !!! ;)

Para TcosMonitor 0.0.12 también hay muy buenas noticias:

* Hacer que la función populate_datatxt() funcione en modo multihilo (falla a veces)
* Cambiar codificación de cabeceras de UTF8 a UTF-8
* Arreglar errores de cadenas de traducción y actualizar traducción a Español.
* Soporte inicial a DBUS (nueva clase y nuevos lanzadores), inspirado en algunas cosas que me gustan de Student-Control-Panel de Ubuntu he añadido soporte DBUS para que se pueda ejecutar aplicaciones, cerrar las que hay o mandar mensajes de texto de una forma mucho más sencilla.

* Nuevas opciones del menú derecho:
- Ver procesos ejecutandose ( y poder matarlos ) Además los procesos tienen asociada una nueva variable de configuración para ocultar los que son de arranque del escritorio (gam_server, gconfd, dbus, etc... que no se deberían matar)
- Ejecutar aplicación en la pantalla de usuario (y como usuario) gracias a DBUS esto ahora funciona como la seda. El diálogo de entrada tiene autocompletado para 5 o 6 aplicaciones comunes en breve añadire bastantes más.
- Matar aplicación remota (de entre una lista de procesos)
* Nueva clase PingPort (que no pingpong) basada en sockets con timeout para ver si una máquina está viva y el puerto abierto (adios echoping)
* Actualizadas dependencias (+dbus +python-dbus +zenity -echoping)
* Fallos conocidos (threads que intentan acceder al interfaz a la vez producen errores asíncronos => crear bloqueos ??)
* Borrados los lanzadores shell script (ahora se ejecuta directamente el .py desde /usr/bin/)
* Añadido ESTABLISHED al filtro de netstat para conexiones locales (sólo máquinas activas) esto arregla bastentes fallos del interfaz.
* Añadidas cabeceras GNU/GPL a casi todos los archivos (*.py *.c *.h)

En resumen, novedades más importantes, soporte (por fin) para máquinas con poca ram por medio de arranque NFS y soporte para DBUS y comunicación TcosMonitor->Usuario del terminal mucho más simple.

En un ratillo ya estarán ámbas disponibles en el repositorio:

deb http://soleup.eup.uva.es/tcos/debian unstable main