Google rules

Supongo que a estas alturas todo el mundo habrá probado el nuevo juguete de google. Una maravillasa idea oiga: Según vas escribiendo te sale una ventana con sugerencias. Como Joel ha explicado, lo que hace es interactuar con el usuario sin necesidad de recargar la página, el mismo truco que utilizan para gmail. El navegador se siente como una GUI real.

Google está sorprendiendonos cada día con este tipo de aproximaciones. Todo lo que google está haciendo, desde Google groups pasando por Gmail y terminado por este nuevo buscador, está orientandose a concebir a Internet no como un conjunto de "páginas web", sino como aplicaciones normales y corrientes que tienen parte de su funcionalidad implementada en un servidor remoto, o "aplicaciones web" como lo llaman ahora. La mayor desventaja es que los navegadores que no soporten javascript no podran acceder a todo esto, que es algo que francamente no me importa. El mundo avanza. La mayor ventaja es que puede que hasta sea un ahorro para google. Con esas sugerencias mientras escribes probablemente puedes ahorrarte unas cuantas busquedas que globalmente a google podrian a llegar a costarle mas. Gmail es igual, en vez de saltar de página en página descarga la interfaz en el cliente con el consiguiente ahorro de ancho de banda retransmitiendo la página, calculando que datos poner en los campos, etc. Es algo bien hecho, desde el principio al final.

Threads

Hace unas semanas dimos en clase hilos POSIX. Por supuesto, POSIX es el "estándar", asi que todo el mundo usa POSIX:

int pthread_create(pthread_t *restrict thread, const pthread_attr_t *restrict attr, void *(*start_routine)(void*), void *restrict arg);

Asi es la cosa en el mundo Unix. Esta tambien fork(), y clone() (este último solo en linux), pero es interesante observar con que elegancia se solucionan los problemas en sistemas operativos bien hechos, como Plan9. En Unix el mundo de los "threads" vino despues de ser diseñado, y como tantas otras cosas de unix, no está integrado de una forma precisamente "elegante". En Plan9 no existen threads: Simplemente hay procesos y punto. Lo que hay son múltiples métodos para decidir como se comparten los recursos, pudiendo crearse nuevos procesos que funcionen como threads, o no, o ir más allá de lo que Unix puede hacer permitiendo a los procesos tener su propio espacio de nombres (*). En Unix se tiene la dualidad fork()/pthread_*(), y pthread_*() palidece y se convierte en una una API horriblemente compleja y bastante windosera en su diseño. rfork() de Plan9 es muy superior, en mi opinión:

int rfork(int flags)

donde "flags" es un argumento donde se espefifican que recursos no se deben compartir. La página man de rfork está disponible online. Solo con comparar esta API con la API de pthread_*()...

(*)DISCLAIMER: Si, se que Linux SI soporta espacios de nombre por cada proceso, o al menos algo parecido. Es otra de las "sorpresas escondidas" de 2.6, y el artífice es Alexander Viro, quien sino. Aunque mucho me temo que todo esto está aun años luz de Plan9 :( . Otra de las "sorpresas" de 2.6, relacionada con este tema, es mount --move, que permite "mover" puntos de montaje de un lado a otro)

actualizaciones a go-go

Estamos que no paramos. En el BK de 2.6 acaba de entrar, justo despues de sacar 2.6.9, esta serie de cosas según se ve a bote pronto:

• IO schedulers intercambiables en caliente. Si amigos, ahora podemos hacer "modprobe as-iosched; echo as > /sys/block/hda/queue/scheduler". Es fantástico, porque diferentes discos necesitan diferentes schedulers. Un lapiz USB realmente quiere utilizar "noop" y un disco normal "as".
• CFQ v2. Jens Axboe es increible, con esto y lo anterior me pregunto cuantos sistemas operativos pueden igualarnos en este área
• Actualizaciones de USB, ARM, PPC, SH, S390, M32R, swsusp
• Hacer a reiserfs más resistente frente a errores. Es importante, mucha gente utiliza reiserfs, y reiserfs no es tan resistente a errores como ext3 (que cuando detecta un error puede montarse en modo read-only, ignorar el error o colgarse, a opción del administrador)
• "packet writing", incluso para DVDs
• "in-kernel keys & keyring management". La criptografía y yo no nos llevamos bien asi que no se ni quiero saber que hace esto pero tiene pinta de ser "importante"
• Acelera /proc/kallsyms. Recuerdo que hace muucho tiempo cat /proc/kallsyms > /dev/null tardaba como 7 segundos, o quizás eran más. Es bueno que se hayan preocupado de que no fuera *tan* lento
• Aunque no ha entrado aun, pero ya ha sido posteado, tenemos un driver para AHCI, un "estándar" SATA, que ha sido publicado por Intel, que lejos de hacer guarrerias binarias como Nvidia o no soportar nada, ha proporcionado las especificaciones, que nos servirán para soportar todas las controladoras AHCI que salgen en el futuro. Al igual que con sus tarjetas de red o gráficas, Intel sigue marcando la diferencia y haciendo sus propios drivers libres o proporcionar especificaciones. Yo por mi parte no compraré nada SATA que no esté basado en esta especificacion o en otra igual de libre y bien soportada. Principalmente por estabilidad.