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.

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....

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.