MarioDebian, mi devlog

Hasta no hace mucho tanto LTSP como PXES usaban dos arquitecturas de sonido muy semejantes (ESD o NASD), el sonido viajaba entre el servidor (donde se ejecutan los programas y se generan los sonidos) hasta el terminal de una manera más o menos sin comprimir.

Esto provoca que a partir de cierto número de terminales el sonido constante (escuchar música) consuma casi todo el ancho de banda de la red.

Con los desarrollos de nuevas soluciones, en LTSP se han dado cuenta de esto y están empezando a adoptar PulseAudio como servidor de sonido, el cual además de comprimir el «stream» también permite la compatibilidad con otros protocolos.

He preparado un pequeño diagrama, sobre cómo era, y como puede llegar a ser.

La línea naranja indica el cómo era antes, las aplicaciones usaban como plugin de salida «eSound» y a través de la red sin comprimir enviaban el audio que el terminal ligero recibía mediante un servidor de sonido escuchando en el puerto 16001 (normalmente).

ESD tiene varios problemas pero sin duda el más importante es que no es compatible a la vez con OSS y ALSA, de hecho en la mayoria de las distribuciones hay un paquete para OSS y otro para ALSA (en debian/ubuntu libesd0 y libesd0-alsa)

Con la llegada de PulseAudio nacen muchas opciones nuevas, y sobre todo mejor rendimiento ya que el audio va comprimido (pudiendo escoger entre varios algoritmos).

TCOS fue el primero en usar PulseAudio en terminales ligeros (allá por verano del 2006) y ha demostrado ser una de las opciones más viables. Los problemas vienen cuando intentamos que el montaje sea estandar para todos los equipos, mezclando OSS y ALSA en la misma red.

Con ALSA y PulseAudio (zona lateral derecha del esquema) es muy sencillo, el programa reproduce a través del plugin PulseAudio, y mediante un protocolo propio se envía por red el audio, el terminal que tiene un servidor de sonido recibe el «stream» y lo manda a la tarjeta de sonido.

Con OSS la cosa se complica. PulseAudio puede autodetectar tarjetas de sonido de cualquier tipo, pero hace cosas extrañas con las tarjetas antíguas, como por ejemplo empezar a reproducir y si alguien accede al dispositivo /dev/dsp se congela y hay que reiniciarlo.

Tenemos dos opciones:

• Cargamos el módulo oss y bloqueamos todo acceso al dispositivo /dev/dsp
• Arrancamos ESD sobre /dev/dsp y cargamos el modulo de redirección esound-sink, esto lo que hace es configurar la salida de PulseAudio como la entrada de ESD.

Aunque parezca mejor solución usar sólo un servidor, la ventaja de usar dos es la estabilidad, ya que PulseAudio no se lleva demasiado bien con OSS directamente, el inconveniente es el aumento de requerimientos (no mucho)

Otra de las cosas que he descubierto con estas pruebas es que amixer, (mezclador de niveles de volumen en consola) es sólo compatible con ALSA, por lo que no disponemos de ninguna herramienta que suba el volumen de 0 para OSS, aunque creo que por defecto al cargar el módulo se ponen al 67%... Supongo que tendré que ir pensando en otro mezclador como aumix.

Todas estas pruebas de compatibilidad con OSS nacen de la necesidad de tener sonido en el ya famoso MicroClientJr que compramos hace tiempo y que en su día me dí por vencido para hacer funcionar. Ahora mismo lo tengo conectado como terminal ligero con TCOS y el audacious de mi portátil suena por sus altavoces ;)

El driver de sonido se llama sis7019, por lo visto funciona hasta el kernel 2.6.18, en el 2.6.19 habrá que volver a investigar como parchearlo. He subido las fuentes a mentors.debian.net por si algún DD quiere patrocinar la subida. El paquete deb crea un paquete nuevo llamado sis7019-sources y mediante module-assistant crea el módulo para el kernel que se necesite, lo que no acabo de entender es por qué cuando ejecuto algo como esto «m-a -t build sis7019» se compila dos veces, también me pasa con usbvision, otro paquete que tengo en mentors.debian.net (driver de mi capturadora USB de televisión).

Si alguien está interesado en esponsorizar la subida (en castellano suena bastante mal) los dos paquetes son lintian-limpios.

No asustarse !!! no me he pasado al lado oscuro.

El título puede parecer un poco exagerado pero realmente es así.

Acabo de hacer el commit en TCOS para soporte de rdesktop (RDP). Realmente ha sido muy sencillo (hooks-addons/rdesktop).

El problema más grande ha sido instalar Windows MalaVista (AKA BadVista) en un Vmware Server, desde casa, con una imagen ISO y el instalador del MalaVista emperrado en que le diera los drivers del cdrom virtual antes de instalar.

Como de soluciones raras estan los sistemas operativos propietarios, he tenido que instalar primero Xp, actualizar (sin mantener XP) a MalaVista, crear un disco duro donde he copiado los drivers de vmware en otra máquina virtual y «enchufar» el disco para que instalase el driver de red (el del cdrom sigue sin ir...) La ventaja de usar Vmware es que el servidor de terminales si tiene suficiente RAM y CPU puede servir sesiones remotas Linux o Windows (de éste último más bien pocas porque consume bastante por usuario).

Rdesktop funciona bastante bien con conexiones lentas siempre que no se abusen de los efectos gráficos (umm wait !!!) que he tenido que desactivar ...

Bueno con este pequeño añadido creo que se puede pensar en migraciones de oficinas donde dependan de software exclusivo para Windows... (ya no hay disculpas)

Creo que redirecciona el sonido (al menos eso pone en el mezclador) lo que ya no se es como recogerlo desde el terminal. Los soportes extraibles USB, disquetes y demás no funcionan a menos de una forma tan sencilla (quizás usando SAMBA). También he leido que es posible ejecutar aplicaciones windows sueltas sin ver el escritorio completo, o al menos eso dice el man de redesktop. Tanto Windows Xp como Windows MalaVista permiten mediante lo que se conoce como compartir escritorio que se conecte un usuario simultáneamente. Para más usuarios hay que usar Windows 2000 o 2003 Server con Terminal Server.

Las pruebas las empecé ya hace un tiempo con un Windows 2003 server, pero en la universidad sólo me han facilitado las claves y los datos del contrato de campus, pero no me han dicho como activar el Terminal Server por lo que si algún alma caritativa sabe, agradecería el comentario (la web de microsoft me da un error 0x01) y desde el teléfono de activación me piden enviar por fax no se que gaitas !!! manda narices que sea más fácil piratearlo que usarlo legal, claro, así les va...


UPDATE:

Dos capturas para los incrédulos:





Para que arranque con windows hay que añadir al cmdline «startx=W rdesktop=xxx.xxx.xxx.xxx» Siendo las XXX la dirección IP ( o nombre de la máquina ) con un windows.

Esta mañana según he llegado a casa tenía un sobre con matasellos de Polonia y al abrirlo ha aparecido esto:



Tres revistas Linux+ en las que sale publicado un artículo, bastante completo sobre terminales ligeros basados en TCOS.

Gracias a su redactora jefe: Paulina y gracias a Luis por el contacto !!!

Pillaos una antes de que se agote en vuestro kiosko favorito.

En otros artículos y como tarea pendiente en TCOS estoy intentando minimizar los requerimientos mínimos para que un equipo viejo pueda ser usado con TCOS.

Repasando los requerimientos de otros sistemas:

• PXES: mínimo 32 Mb, recomendable 64 MB
• LTSP: En LTSP 5 32 Mb, conozco de instalaciones que con 16Mb o 24Mb funciona (usando swap en el servidor por la red) mínimos oficiales
• TCOS: hasta ahora los mínimos estaban en 32/64 Mb pero no eran demasiado precisos ni explicaban las condiciones.
  

¿A qué viene todo esto?

Pues empiezo a preparar presupuestos de instalación, visito colegios con ordenadores prehistóricos y ya es cuestión de orgullo hacerlos funcionar (uno de esos es un Pentium 100 con 32 Mb)

Para evitar problemas y que el uso sea más sencillo he juntado (hace ya unas versiones) los modos de arranque TFTP y NFS, es decir, con un límite de 38 Mb (configurable en tcos.conf) y al principio del arranque decido si tengo memoria suficiente para descargar el usr comprimido o mejor monto NFS y hago la jaula.

He reducido radicalmente los tamaños del initramfs quedando «casi» en lo que ocupan los de debian:


Ahora:

mariodebian:~$ du -ha /boot/initrd.img-2.6.17-2-486 /tftpboot/tcos/initramfs-2.6.17-2-486*
4,7M    /boot/initrd.img-2.6.17-2-486
4,8M    /tftpboot/tcos/initramfs-2.6.17-2-486
3,0M    /tftpboot/tcos/initramfs-2.6.17-2-486-nfs

Antes:

FALBALA:~# du -ha /boot/initrd.img-2.6.17-2-486 /tftpboot/tcos/initramfs-2.6.17-2-486*
4,4M    /boot/initrd.img-2.6.17-2-486
6,1M    /tftpboot/tcos/initramfs-2.6.17-2-486
3,0M    /tftpboot/tcos/initramfs-2.6.17-2-486-nfs

He marcado en negrita, donde más trabajo he tenido (1,3 Mb menos es mucho en tan poco, casi el 30% menos)

Tengo que decir que los dos initramfs tienen soporte para las mismas cosas (sonido, usb, discos locales, cdrom, todas las tarjetas de red...) Aún es posible minimizar más si en vez de dejar a mkinitramfs meter todos los módulos indicamos que módulos de red o placas vamos a usar...

El proceso de arranque sería así:

1.- Configurar en el DHCP los equipos que tengan menos de 38 Mb para que descarguen el initramfs NFS (creo que se hace con el option-string 128-129) si van a ser todos se deja por defecto en pxelinux.cfg/default.tpl y listo..

2.- El equipo arranca, detecta menos de 38 megas y monta por NFS un initramfs completo (con su /usr) hace chroot al nuevo punto de montaje y sigue como si nada.

3.- Los equipos con más de 38 Mb toman el initramfs normal descargan el usr.squashfs por tftp, lo montan y arrancan.

Sería la leche que pxelinux detectara el tamaño de ram y seleccionar el initramfs correcto así como el ramdisk_size pero creo que esto ya es pedir mucho... así que el que mezcle equipos demasido viejos tendrá que configurar un dhcpd.conf más complejo

Con todas estas mejoras he preparado mi vmware server (donde hago casi todas las pruebas) con una máquina virtual de 24 Mb de memoria, y he aquí:



He cerrado las X para hacer la captura de pantalla, pero las X funcionan y aún le sobra 1Mb. De esta forma no es usable ya que no tiene swap y a la mínima que se abra alguna ventana Xorg no tendrá memoria y seguramente se cierre o de un kernel panic. Para esto la mejor solución es usar los discos duros de los equipos para primero, ahorrar lo que vale una tarjeta de red buena que soporte PXE (arrancamos desde disco duro gracias al nuevo instalador de TCOS), y segundo poder swapear sin congestionar ni la red ni el servidor.

Después de sucesivas pruebas reduciendo RAM, puedo asegurar que 24 Mb es un buen límite (sin swap), porque aunque con 20 Mb también arrancan las Xorg, prácticamente no tiene ram suficiente y lo tiene que intentar varias veces... con 16 Mb se queda sin memoria antes de montar el NFS.

Resumiendo y como orgullo personal, he conseguido que el invento funcione con 24 Mb de memoria (el límite del procesador impondrá la velocidad de arranque) y que sea bastante sencillo el escalado/mezcla de distintos equipos en la misma red.

También hay que reconocer que un equipo pentium 200 con 24 Mb de ram funcione con los últimos kernel, las últimas Xorg, udev, un servidor de sonido como PulseAudio y algún daemon más, es un «milagro».

Otras mejoras que están por llegar al repositorio es la gestión de consolas (que funciona regular), es decir, ya no queda un shell de root abierto sino que pide usuario y contraseña (si se configura así), así como también una reducción radical del tiempo de carga (un equipo con 64 Mb carga en 5 seg menos) ya que he quitado las dependencias de los scripts de arranque ,como están ordenados por números no hace falta... así como la gestión del archivo pxelinux.cfg/default que ahora lo hace gentcos (configura la versión del kernel)


Iba a escribir un artículo nuevo pero creo que puedo ponerlo como coletilla de este que no ha quedado tan mal :P

Siguiendo con su constancia en el apoyo al software libre, la asociación GNUMAX vuelve a convocar las II Jornadas de Software Libre y Comunicaciones, que tendrán lugar los próximos 13 y 14 de Abril en Puerto del Rosario, Fuerteventura, Canarias.
Aún recuerdo lo bien que me acogieron en su anterior edición, y lo buena tierra y buena gente que es Fuerteventura y lo bien que se come. Un saludo Luis !!!
Espero poder escaparme a veros.

Estoy depurando algunas cosas de tcos y entre ellas el tamaño de la imagen.

Uno de los elementos «prescindibles» que me he encontrado es el binario seq (man seq), pertenece a coreutils.

Entre otras cosas si se le pasa un número como parámetro hace un bucle entre 1 y ese número, por ejemplo:

$ seq 5
1
2
3
4
5

hace muchas más cosas como poder empezar en algo distinto de 1 o configurar el incremento a otro valor distinto de 1. Tenemos entre manos un programa (en teoría) la mar de sencillo.

¿Donde esta el problema?

Hasta ahora cuando se activa el soporte tcosmonitor en la imagen copiaba /usr/bin/seq al initramfs, pero me he dado cuenta que ocupa la no despreciable cifra de 18 Kb, por lo que le he programado un sustituto en shell script:

#!/bin/sh


MAX=$1
NUM=1

if [ "$MAX" = "" ]; then
   echo "Usage:"
   echo "      seq NUMBER"
   exit 1
fi

if [ $MAX -gt 100 ] || [ $MAX -lt 1 ]; then
  echo "ERROR: 100 is max number to seq and 1 min"
  exit 1
fi

while [ $NUM -le $MAX ]; do
  echo $NUM
  NUM=$((NUM +1))
done

Es decir paso un número como parámetro y si es mayor de 100 (para evitar bucles demasiado largos) o menor de 1 (para evitar bucles infinitos) hago el bucle e imprimo la salida.

Diferencias de usar este script o el binario:

Tamaños:

• binario 18Kb
• script 0.2 Kb

Tiempos de ejecución para un contador de 100:

$ time busybox sh bin/seq 100 > /dev/null

real    0m0.343s
user    0m0.084s
sys     0m0.204s

Tengo que simular el entorno real de alguna manera y como el initramfs usa el shell ash de busybox esa es la forma en la que lo he lanzado...

$ time seq 100 > /dev/null

real    0m0.003s
user    0m0.004s
sys     0m0.000s

Como se puede apreciar la diferencia en tiempo es de 0.3 s, si nos vamos a 1 millón de iteraciones quizás sea de varios segundos.

¿Cuál elegir?

Como el uso que se está pensado hacer del comando seq es para pequeños bucles, me quedo con el script, aligeramos el tamaño del initramfs un poquito (17Kb) y aunque perdemos rendimiento no es algo realmente alarmante...

UPDATE:

Me había quedado con la duda, con 10.000 iteraciones mi script tarda 23.675s segundos (para un millon no he tenido paciencia de esperar), el binario tarda casi nada: 0.079s

UPDATE 2:

Ya que estamos he probado a hacerlo en otro lenguaje interpretado como es python y los resultamos me han sorprendido bastante:

$ time ./seq.py 100 > /dev/null

real    0m0.070s
user    0m0.020s
sys     0m0.004s

$ time ./seq.py 10000 > /dev/null

real    0m0.120s
user    0m0.052s
sys     0m0.016s

El código del programa en python puede ser algo como esto:

#!/usr/bin/python

import sys
max=sys.argv[1]

i=1
while 1:
  print i
  i=i+1
  if i > int(max): break

Nunca hubiera imaginado que python (lenguaje interpretado) fuese tan rápido. La prueba de fuego ha sido comparar seq (C) y seq.py (python) en un bucle de 1.000.000:

C: 1.408s
python: 2.957s

Hacía mucho que no decía «python mola».

Alguien puede acceder a forja.rediris.es ???

A mí me sale la web de la Federación Andaluza de Atletismo :|



Mis DNS son:

157.88.18.189 (Universidad de Valladolid)
192.168.0.1 (mi router, es decir, los DNS de yacom, que espero que no se hayan vuelto a pasar con el tema de la publicidad encubierta!!!)

Tengo algún cambio importante en el SVN de TCOS y no puedo subirlo.

UPDATE (19:20):

Yacom viene liándolas muy gordas con sus dns y en vez de mostrar un error de página no encontrada, sale su web y te redirige a publicidad.
Que se traspapele de esta forma ya me parece denunciable, es más, les quedan menos de 3 meses hasta que se cumpla el año de contrato.


PD.- Desde la universidad funciona correctamente.

PD2.- Acabo de venir del Palacio de Santa Cruz en el cual hemos tenido el primer acercamiento con el Rector de la Universidad de Valladolid. Puedo adelantar que la universidad está muy interesada en el reciclaje de equipos obsoletos mediante aulas TCOS... ya hablaré de las conclusiones en otro artículo.

He actualizado los paquetes de TCOS para las distribuciones soportadas (Debian testing/unstable y Ubuntu dapper, edgy y feisty) en el mirror de TCOS.

Uno de los problemas a los que me voy a tener que enfrentar a partir de ahora son 3 versiones diferentes de usplash y para más complicaciones, INCOMPATIBLES entre sí.

1.- Usplash de Ubuntu dapper (el más viejo), versión 0.2-4, el tema es un png de 640x480 con una paleta de 16 colores y se compila dentro del propio paquete usplash con bogl

2.- Usplash de Debian, versión 0.3a, el tema es un png de 640x480 pero se han añadido definiciones de tema en forma de ficheros .c que se compilan junto con bogl para producir el tema. Este tema no es compatible con la versión 0.2-4. Los temas pueden compilarse independientemente del paquete usplash, de hecho el paquete usplash trae un tema parecido a la carta de ajuste (testcard).

3.- Usplash de Ubuntu edgy/feisty, versiones 0.4-33 y 0.4-34, los temas ahora son más completos, tienen varias resoluciones y ha aumentado la paleta de colores a 255, un throbber (barra) que se mueve como las luces del coche fantástico en los principios del arranque y después como barra de progreso. Tiene un fichero .c que es donde se indican todas las resoluciones soportadas y para compilar se convirten todos los png a .c (se guarda la paleta y los pixel como un static char), se compila a código objeto y se unen todos en un .so bastante más grande que los anteriores (1.8 Mb). Ahora usplash soporta dinámicamente el tamaño de splash en /etc/usplash.conf pero no es compatible con ninguno de los dos anteriores...


Y yo me pregunto... en el mundo del software libre se intenta que cada aplicación sea lo más compatible con versiones anteriores (ejemplos como gcc o muchas otras librerías lo afirman) ¿tan dificil era haber hecho retrocompatibilidad con usplash?

Es que un problema como este, me recuerda cuando el propio Microsoft Office Word 97 no podía abrir algunos documentos del Office 2000 !!!!

En fin, seguiremos solucionando algunos pequeños detalles para que funcione lo mejor que pueda en sistema tan distintos.

Llevo todo el día pensando en las formas de hacer funcionar TCOS sobre wireless y así evaluar el rendimiento.... y por fin he conseguido arrancar un terminal ligero sobre wireless...

Ingredientes:

• El ubuntu edgy de mi hermano (Pentium IV 3.2 GHz 1Gb RAM y tarjeta wireless con chip atheros ~ madwifi)
• Kernel 2.6.17-10-generic (el que viene en ubuntu) + linux-restricted-modules (por el driver madwifi que no es libre del todo)
  
• Copia del SVN de initramfs-tools-tcos (0.57-1svn200061227)
• Router de YACOM wireless (3Com OfficeConnect blanco con 2 antenas, modo protegido de wireless: WPA TKIP)
• Mi portatil con debian SID, servidores: DHCP TFTP y XMDCP activado en el GDM

Instalamos los paquetes de tcos en la ubuntu y configuramos /etc/tcos/tcos.conf cambiando estas variables:

TCOS_KERNEL="2.6.17-10-generic"
TCOS_WIRELESS_MODS="madwifi"
TCOS_WIRELESS_ENC="WPA"

El resto de la configuración se puede dejar como está. Lo que estamos haciendo es cambiar el kernel al que usa ubuntu, decirle qué drivers wireless vamos a usar (madwifi es un alias para cargar ath-pci, ath-hal y otro puñado de módulos) supongo que funcionará también con ipw2200, ipw2100 (tenemos que tener el firmware en /lib/firmware), con ndiswrapper lo voy a tener un pelin más crudo ya que el programa ndiswrapper está escrito en perl y no es mucho plan meter 20 megas de perl y sus módulos en el initramfs...

Una vez tenemos tcos configurado generamos la imagen de arranque:

# gentcos -tftp

Sino tenemos errores (si los tenemos habrá que instalar lo que nos pida) tendremos varios archivos por nuestro sistema, lo que hay que hacer ahora es generar otra entrada al final del menu.lst de grub con este aspecto:

# tcos
title TCOS, kernel 2.6.17-10-generic
root (hd0,0)
kernel /boot/vmlinuz-2.6.17-10-generic ramdisk_size=65536 root=/dev/ram0 quiet boot=tcos wifi=1 essid=MarioDebian server=192.168.0.3
initrd /tftpboot/tcos/initramfs-2.6.17-10-generic
boot


La diferencia entre una entrada de grub normal y esta es que el dispositivo root será /dev/ram0, hay que añadir un tamaño de ramdisk en Kbs (64Mb puede valer) y para que arranque por wireless añadir las siguientes variables:

wifi=1
Le dice al script que configura la red que queremos arrancar por wifi, por lo que se cargaran los módulos que hayamos indicado en TCOS_WIRELESS_MODS y se buscará un interfaz wireless en /sys/class/net/

essid=MarioDebian
Este es el nombre de la red wireless a la que nos conectaremos. En el servidor deberiamos tener un archivo en /etc/wpa_supplicant/*.conf con la clave de la red ya que vamos a usar una red protegida con WPA, si no encuentra ese archivo preguntará por la clave y lo generará cuando arranque.

server=192.168.0.3
Como el router wireless va a hacer de servidor DHCP tenemos que indicarle que nuestro servidor de verdad (el que tiene tftp y gdm) es otra máquina.

Con esto ya tenemos todo listo para hacer la prueba. Reiniciamos y seleccionamos la entrada de TCOS en grub. Si no hay problemas con la clave WPA en más o menos 1 minuto deberiamos estar en frente al gestor de entrada GDM.

Para dar soporte a wireless, simplemente he creado un nuevo hook-addon (extensión) llamada wireless , he tenido algun pequeño problema con las librerías a las que está enlazado wpa_supplicant pero lo he solucionado metiendolas en /lib en vez de /usr/lib (/usr se descarga más tarde y no es accesible cuando se necesita). También he tenido que modificar el script de arranque que configura la red ( 05network ) para poder configurar red por cable o wireless desde la línea de comando.

He hecho unas fotos con el móvil (no tienen mucha calidad pero se pueden leer los mensajes)






En esta se puede ver TcosMonitor funcionando con una sesión SSH al terminal donde vemos el interfaz ath0 (he emborronado la key y las MAC por si tengo algún vecino listo) de paso he probado el sonido (PulseAudio) y parece que funciona muy bien en ubuntu.



Si alguien quiere las imágenes para poder probar TCOS por wireless que me lo diga y las subo junto con un pequeño texto explicando como cambiar la clave WPA.

Quizás los números de versión de TCOS no reflejan la calidad, el trabajo o las horas que llevo metidas en este proyecto pero creo que un buen proyecto debe tener versiones inferiores a 1.0 mientras:

• lo usen cuatro gatos :(
  
• cuando cualquier día se cambian partes importantes no manteniendo compatibilidad con versiones anteriores
• hay cambios casi diarios en el SVN
• nuestro código contiene varios «#FIXME»
  

Aún así los números de versión de TcosMonitor (0.0.16), TcosConfig (0.0.8) y un poco menos tcos (0.56.18) creo que están haciendo un flaco favor al proyecto así que, que nadie se sorprenda si la próxima versión pasa a ser 0.1.1 ó 0.2.1 ...

He estado solucionando unos temas estéticos de las multicapturas (añadir una leyenda en vertical) y he añadido una nueva variable de información, el «uptime» o tiempo que lleva encendido el terminal. No es que sea de gran utilidad pero los terminales ligeros no conviene tenerlos demasiado tiempo encendido por problemas como fugas de memoria de algún programa (no suelen tener RAM de sobra) o calentones, así que mirando esta variable se puede tomar la decisión de que es hora de reiniciar el equipo desde TcosMonitor.

Este es el aspecto con el que quedan las multicapturas (a tres clientes), pronto colgaré otra con más...



El modo multicaptura tarda demasiado (24 equipos más de 1 minuto), ya que cada terminal necesita poco más de 3 segundos para «hacerse una foto», probé a realizar las capturas usando Threads que lanzaba a la vez, pero en python por muchas veces que se instancie una clase no se pueden usar variables distintas de esa clase, así que la solución será crear una nueva instancia de esa clase por Thread, o lo que es lo mismo por cada captura, lo que reduciría el tiempo a lo que tarda python en generar los hilos y esperarlos más tarde (de la misma forma que tengo la clase que hace ping a la red) calculo que de esta forma puede tardar como 10-15 segundos.

Aquí se ve la nueva variable «uptime»:




En mi lista de cosas por hacer están:

• Acabar de mejorar el instalador (permite arrancar los clientes ligeros desde disco duro y así ahorrarnos una buena pasta en tarjetas de red buenas u olvidarnos de los malditos disquetes)
  
  
• Añadir soporte wifi, un buen amigo (Lluís Gras) se le ocurrió la genial idea de arrancar TCOS mediante wireless así que en un par de cruces de emails hemos preparado un pequeño «hook-addon» o extensión para que TCOS pueda funcionar con dispositivos wireless (hay que investigar sobre WEP y WPA)
  
  
• Añadir soporte para clonado de equipos. Idea de Xabi Ezpeleta. Muchos administradores de red conocen GHOST y saben lo que se tarda en reinstalar un aula por red (muy poco), la idea es usando partimage conseguir algo parecido.
  
  
• He recibido más sugerencias, como por ejemplo hacer un paquete de TCOS para equipos instalados y que permita tomar el control de ellos de la misma forma que se hace con clientes ligeros.
  

Los paquetes con las nuevas versiones estarán hoy a última hora o mañana en el repositorio de TCOS.

Felices fiestas a todos.

Una de las últimas cosas que se ma había ocurrido para TcosMonitor es la posibilidad de ver lo que estan haciendo todos los usuarios conectados en una aula TCOS de un vistazo (ya era posible hacer capturas de uno en uno).

Así que aprovechando que el menú de acciones para todos los usuarios era un gran desconocido he puesto un botón en la barra para que aprezcan las acciones para todo el aula y la nueva acción «MetaGranHermano», Capturar todas las pantallas:



He aquí lo que aparece en el htmltextview:



El tamaño de las minicapturas se puede configurar desde las preferencias (por defecto creo que está al 15 o 25% de la pantalla de usuario) he probado a meter las capturas todas juntas (sin saltos de línea pero no hay manera de saber que captura es la de qué equipo, tendré que mirar como lo pongo "más potito", tipo <span> o algo así)

El código está en el SVN pero de momento no hay paquetes....

Si hace unos días publiqué el interés de la Comunidad de Madrid por TCOS, puedo avanzar que se avecina algo bastante más gordo (y eso que lo de la Comunidad de Madrid es muy grande...).

Dentro de poco en sus navegadores o lectores de RSS ;)