29 de diciembre de 2004

mensaje interesante

From: Lee Revell
To: linux-kernel
Cc: Ingo Molnar , Andrew Morton
Subject: Latency results with 2.6.10 - looks good
Date: Wed, 29 Dec 2004 14:33:40 -0500
Sender: linux-kernel-owner@vger.kernel.org
X-Mailer: Evolution 2.0.3

After testing JACK with vanilla 2.6.10, it appears that the scheduling latency of 2.6.10 is a vast improvement over previous kernel releases. JACK seems to be usable with a period of 32 and 64 frames, I cannot produce xruns by moving the mouse or any amount of display or disk activity. Previous kernel releases were somewhat worse than Windows XP in this area, 2.6.10 is definitely better, maybe as good as OSX.

So, it appears that all of the latency fixes going upstream from Ingo and others have really made a difference. More testing is needed but it looks like we may finally have a kernel that's usable (and in fact quite good) out of the box for low latency audio. Good work!

Lee

Y esto es con un 2.6.10 normal, sin los parches de RT de ingo & cia, y aun tendrá que mejorar para futuras versiones, supongo

17 de diciembre de 2004

Unix, el sistema operativo ¿"seguro" y "fiable"?

Por si alguien lo dudaba...:

"The first fact to face is that UNIX was not developed with security, in any realistic sense, in mind; this fact alone guarantees a vast number of holes.

Dennis M. Ritchie 1974; "On the security of Unix"

Tambien hay que recordar que los grandes gusanos de Windows XP que "casi paran" internet no son nada. Ha habido gusanos antes de la existencia de Windows de los que se puede decir que pararon internet literalmente.

Me hace gracia que luego la gente ponga a Unix como "ese sistema operativo tan solido y bien diseñado que lleva durante 30 años manejando el trafico de internet" etc etc cuando es bastante obvio que la realidad ha sido mucho menos bonito

15 de diciembre de 2004

peazo comentario

Acabo de hacer un GRAN comentario en osnews, y odio ir por ahi chuleando pero es verdad. Un tipo dice que es gracias a Microsoft a que tenemos hoy un PC en cada casa. Y yo he respondido esto, fuera de pro/anti Microsoiftismos. Con faltas en ingles incluidas:

"The question is obvious. Why didn't they? Why didn't IBM trounce MS? "

Marketing incompetence.

I really don't buy that "microsoft made possible to have a PC in each home". But Microsoft was put in every home PC out there, that's true

When Microsoft was playing with MSDOS, Apple already had a operative system with a user-friendly GUI.

If "user friendliness" is the reason why Windows succeed, *WHY* people kept buying PCs with MSDOS when Mac's where available with nice GUIs? Perhaps people liked more the MSDOS obscure command line than Mac's user-friendly GUI? I mean, graphic interfaces were available *years* before windows come out...

The right answer is: PCs were cheaper than Macs. That's the only reason. People ignored the user-friendly Apple computers because the equivalent commandline-based PC's were cheaper. Any OS maker that would have put a cheap OS with a nice GUI in the Peecees before Microsoft would have kicked them, and that OS *would* have happened regardless of Microsoft. IBM managers just needed a kick in their butt to realize they could sell OS/2 as a "desktop OS", however they didn't and so Microsoft won the market. I don't really understand why people says we should "thank microsoft". Thanks for what? For being good at marketing?

If anything, I'll thank Intel because their price/performance ratio was great. Cheap enought, fast enought, that was the only reason PCs took the world, and that's the reason they're taking the server world today with the amd opteron, except that the server market is already there and the user one not.

We would have had a PC in every house *even* if Microsoft would have kept developing MSDOS and no OS maker would have launched a "GUI desktop OS" for the general public. I will NEVER thank Microsoft for putting "a PC in every home". It's just not true, hardware price *was* the true key.

14 de diciembre de 2004

Threads vs processes

Me acaba de alegrar ver en un email de Linus que internamente el kernel no diferencia especialmente a los procesos y los threads. Con la claridad y el estilo y la absoluta falta de "rigor" y de uso de terminos extraños. Como tiene que ser, vamos:


Please do not confuse things.

There still are no such things as "threads" vs "processes" as far as the 
kernel is concerned.

They are all the same thing, and they are all threads or processes or
whatever you want to call them. I've tried to call them "contexts of
execution" just to clarify the fact that they are _not_ threads of
processes. And they all have a unified ID space.

They just happen to share different things. We should try to avoid at all
cost to take on stupidities from legacy systems. We've got a unified
process/thread/whatever space, and that's a good thing.

Yes, when you share the signal state (and you have to share the VM and
signal handlers to do so), you end up looking like a pthreads "process".
But dammit, people should NOT think that that is all that special from a
kernel standpoint.

Este mensaje me hace pensar que despues de todo implementar rfork() probablemente sea mas un problema de "falta de ganas y de romper cosas" que por "incapacidad técnica". Al fin y al cabo no es mas que otro SMOP. En la parte de threads al menos. Los espacios de nombre por procesos, tuve la gratificante experiencia de probarlos el otro día, no hay mas que usar clone() y CLONE_NEWNS como flag. El plan de ataque fue lanzar un shell con ese flag, monte un sistema de archivos dentro de ese shell y voila - el sistema de archivos montado no existia en el resto del sistema. El problema es que requiere privilegios de superusuario. Sería un gran avance que todos pudieran usarlo. Quizas no sea mas que otro SMOP, veremos que nos prepara Al Viro para 2.6.7...

En otras noticias, parece que alguien de Microsoft ha expuesto el bonito problema que surge con la ansiada compatibilidad 32-64 bits del amd 64. Resumiendo: El kernel necesita drivers de 64 bits, por lo tanto las aplicaciones de 32 bits que funcionen en un sistema de 64 bits y que se comuniquen con los drivers (las llamadas al sistema no son el unico medio de comunicacion con el kernel hay mas mecanismos, concretamente del que habla el tio son las ioctls) no funcionarán. No todo va a ser tan simple y tan bonito a la hora de cambiarse a los 64 bits, especialmente en el mundo propietario. A veces pienso que la propuesta del amd64 da mas problemas que los que resuelve. Empezar una nueva arquitectura de escritorio de cero hubiera sido bonito, aunque habria fracasado por supuesto. Maldito dinero....

12 de diciembre de 2004

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.

9 de diciembre de 2004

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)