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)

20 de octubre de 2004

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.

8 de septiembre de 2004

"Piensa, no seas un borrego"

Esta es la frase que me he encontrado ayer en una pintada de la facultad de informática (no es ese el nombre del edificio, pero cualquiera se aprende esos nombres extraños que les ponen) de la universidad de Valladolid.

Me la encontré levantando la mirada cuando salía del coche, sin avisar, sin que te de tiempo a protegerte. Y con una pared no se puede discutir, asi no me queda mas remedio que hacerle caso. O al menos intentarlo (siempre se dice que lo importante es participar).

El caso es que la frasecita me impactó. Siempre suele haber pintadas, mas o menos certeras (que si no a la guerra, que si ZP a tus zapatos, etc etc), pero esta no es como las que suele haber. A diferencia de otras esta no estaba "firmada" por algun grupo izquierdista/anarquista (grupos de derecha descartados, ningún grupo de derechas pediría a sus partidarios que pensaran por si mismos - y esto no es una ironía). Esta estaba ahí, sola, sin ningún tipo de compromiso añadido. La tomas o la dejas. Y si la tomas no te obliga a nada mas. De hecho es que no te obliga a nada, es una simple sugerencia. Que no habría sido el mismo caso de haber una A de anarquía pintada debajo o de ser una frase tipo "piensa si no quieres te exploten". La primera porque ya te obliga, quieras o no quieras, a plantearte que tiene que ver el pensar con la anarquía, y la segunda porque intenta engañarte directamente (nadie quiere ser explotado, por lo tanto todos piensan -además, que yo sepa, nadie internamente se considera tonto-, por lo tanto todos los que lean la frase deberían sentirse inmediatamente "afines" al partido/ideología que firme la frase, o al menos plantearselo; que total, apuntarse a una ideología es gratis. Aun...)

En definitiva, una gran frase. Con especial sentido a las puertas de una universidad, que pisaba para hacer un examen de una asignatura, y que no pienso pisar para hacer el resto de asignaturas que tengo suspensas porque lo llevan listo los profesores/compañeros de turno si creen que voy a malgastar mi valioso tiempo matandome a estudiar unos contenidos diseñados por monos con títulos. En su lugar me quedo escuchando música, que tiene que ver con la informática lo mismo que la física (y si alguien piensa que si, que vaya y exiga la implantación de física a los estudiantes de derecho, que ya se sabe, los abogados utilizan mucho papel, y a ver por qué un abogado culto no debería conocer los fundamentos físicos del material con el que va a trabajar, tipos de papel, porque el papel se arruga y no vuelve a su estado original etc.) y enseña bastantes más cosas y mucho más útiles. Por cierto, párrafo patrocinado por "La casa sobre el tejado" de Adolfo Cabrales alias "Fito".

Me ha gustado tanto la frase, que si fuera rector de la universidad de Valladolid (o como se llame al que manda) que sustituyera esa frase del escudo de la universidad, la que dice "Sapientia Aedificabit sibi domum", por esta otra. (no es que la frase actual sea mala, es que esta es mejor, asi de simple). Y la frase la mandaría poner en letras bien grandes a la entrada de cada una de las facultades. No vaya a ser que por no haber tenido oportunidad de leerlo, alguno se convierta en un borrego.

19 de agosto de 2004

Larga vida, Digital

HP ha lanzado la última línea de AlphaServers. Les venderá hasta el 2006, y estarán soportados hasta el 2011. Lo bueno de esta noticia es que todavía tengo tiempo para adquirir uno de segunda mano que esté en buen estado. Este blog está dedicado a una empresa que aunque no supo lidiar con los entresijos del capitalismo consiguió crear procesadores que se han convertido en algo mas que un mito: un objeto de culto para muchos (entre los que me incluyo). Larga vida a los Alpha.