los estándares no importan

No lo digo yo, lo dice Linus Torvalds. Y la cosa es que tiene toda la puta razón. Un par de emails cojonudos de él sobre el tema, el primero de hoy y el otro de hace años...(si, guardo los emails que me parecen interesantes). Pero por si alguien no se los lee, no puedo evitar resaltar esto del segundo email: "Call me cynical, but I believe in standards papers just about as much as I believe in the voices in my attic that tell me to kill the Queen of England"

On Thu, 29 Sep 2005, Arjan van de Ven wrote:
> 
> a spec describes how the hw works... how we do the sw piece is up to
> us ;)

How we do the SW is indeed up to us, but I want to step in on your first 
point.

Again.

A "spec" is close to useless. I have _never_ seen a spec that was both big 
enough to be useful _and_ accurate.

And I have seen _lots_ of total crap work that was based on specs. It's 
_the_ single worst way to write software, because it by definition means 
that the software was written to match theory, not reality.

So there's two MAJOR reasons to avoid specs:

 - they're dangerously wrong. Reality is different, and anybody who thinks 
   specs matter over reality should get out of kernel programming NOW. 
   When reality and specs clash, the spec has zero meaning. Zilch. Nada.
   None.

   It's like real science: if you have a theory that doesn't match 
   experiments, it doesn't matter _how_ much you like that theory. It's
   wrong. You can use it as an approximation, but you MUST keep in mind 
   that it's an approximation.

 - specs have an inevitably tendency to try to introduce abstractions
   levels and wording and documentation policies that make sense for a 
   written spec. Trying to implement actual code off the spec leads to the 
   code looking and working like CRAP. 

   The classic example of this is the OSI network model protocols. Classic 
   spec-design, which had absolutely _zero_ relevance for the real world. 
   We still talk about the seven layers model, because it's a convenient 
   model for _discussion_, but that has absolutely zero to do with any 
   real-life software engineering. In other words, it's a way to _talk_ 
   about things, not to implement them.

   And that's important. Specs are a basis for _talking_about_ things. But 
   they are _not_ a basis for implementing software.

So please don't bother talking about specs. Real standards grow up 
_despite_ specs, not thanks to them.

  Linus

Y....

On Mon, 22 Nov 2004, Len Brown wrote:
> 
> I agree that the system should work properly even if the legacy device
> drivers are broken.  Please understand, however, that the legacy device
> drivers _are_ broken.  The BIOS via ACPI clearly tells them if the
> devices are present or not, and Linux isn't yet listening.

I really disagree.

I realize that you like ACPI, or you would have shot yourself long long 
ago.

But I have a totally different view on things. To me, firmware is not 
something cool to be used. It's a necessary evil, and it should be avoided 
and mistrusted as far as humanly possible, because it is always buggy, and 
we can't fix the bugs in it.

Yes, the current ACPI layer in the kernel is a lot better at working
around the bugs, and it's getting to the point where I suspect Linux
vendors actually decide that enabing ACPI by default causes fewer problems 
than it solves. That clearly didn't use to be true.

> ACPI-compliant systems have three types of interrupts:

Stop right there. 

"ACPI-compliant systems". The fact is, there is no such thing. There are 
systems that users buy, and they are not "ACPI compliant", they are "one 
implementation of ACPI that was tested with a single vendor usage test".

Call me cynical, but I believe in standards papers just about as much as I 
believe in the voices in my attic that tell me to kill the Queen of 
England. 

Papers is so much dead trees. The only thing that matters is real life.  
And like it or not, real life does NOT implement standards properly, even
if the standards are well written and unambiguous (which also doesn't
actually happen in real life).

> If somebody bolts motherboard hardware on and doesn't tell ACPI about
> it, then they need to disable ACPI, which _owns_ configuration of
> motherboard devices when it is enabled.

No. The only thing that owns the motherboard is the user. ACPI shouldn't 
get uppity.

> The damn good reason is that doing otherwise breaks systems.

And not doing it breaks systems.

See a pattern?

This is why I don't trust firmware. It's always buggy. 

  Linus

pa que luego los de solaris digan de linux

En la última actualizacion de opensolaris tienen una novedad interesante:

'intrd' arrives. intrd is a daemon which evaluates whether or not interrupts on the system are properly balanced between CPUs. If needed, intrd reassigns interrupts from CPU to CPU. [5017144]

Curioseando la base de datos de bugsde solaris, sus clientes llevan pidiendoselo desde el 2000, y ademas lo piden con insistencia

Curiosamente, linux tiene algo así desde el 2004. Digo curiosos porque me sorprende ver algo en linux en el terreno de servidor que otros que estaban ahi no tuvieran ya. Creo que NT tampoco tiene algo similar.

La otra cosa curiosa es que lo han implementado en un script de perl

¿vista mueve el subsistema de sonido a espacio de usuario? Nah...

En Osnews han destacado una entrada del blog de Larry Osterman (uno de esos programadores de microsoft que SI que hacen las cosas bien) en el que habla de como han movido cosas de audio del kernel al espacio de usuario

En osnews lo han tomado como que "han movido todo el subsistema de audio a espacio de usuario". ¿Todo? Uh...

"The first (and biggest) change we made was to move the entire audio stack out of the kernel and into user mode. Pre-Vista, the audio stack lived in a bunch of different kernel mode device drivers, including sysaudio.sys, kmixer.sys, wdmaud.sys, redbook.sys, etc. In Vista and beyond, the only kernel mode drivers for audio are the actual audio drivers (and portcls.sys, the high level audio port driver)"

Si uno se fija en el post de larry, no se dice exactamente que se estén moviendo todo fuera del kernel: Los drivers siguen dentro: "the only kernel mode drivers for audio are the actual audio drivers"

¿Entonces que han sacado del kernel y a que viene la noticia, si los drivers siguen ahi? Pues viene a que por lo visto (y no era desconocido), en los windows de hoy, el subsistema de sonido en el kernel no tiene solo drivers: Tiene drivers y más cosas. Ejemplo: Ese "kmixer.sys" del que habla Larry. Equivalente al dmix de ALSA - excepto que el dmix de alsa se implementa en las librerias de espacio de usuario de ALSA. Es decir, no es que Vista este "moviendo todo el subsistema de sonido fuera del kernel". Es que está sacando del kernel cosas que no deberian estar ahí. En otras palabras, están dejando en el kernel básicamente lo equivalente a ALSA. Tal como yo lo entiendo.

Y hay otro detalle muy sutil, pero muy curioso: The amount of code that runs in the kernel (coupled with buggy device drivers) causes the audio stack to be one of the leading causes of Windows reliability problems.. No se que tipo de organización tiene windows con respecto a los codecs, pero los malos codecs siempre han sido fuente de inestabilidad en windows, y me temo que esté relacionado con todo esto: Con que los codecs tuvieran que tocar más internalidades de las necesarias para hacer su trabajo, y que a veces lo hicieran mal

Pero el detalle realmente sutil es este, no el anterior. En este mismo blog he escrito mas de una vez el infierno que iba a suponer para microsoft el dual core. Un driver no preparado para maquinas SMP significa un cuelgue potencial en una máquina con dual core. Y los fabricantes de hardware, cuyos programadores y clientes nunca han utilizado máquinas SMP, tienen los drivers como yo le diga a usted. Me alegra saber que no estaba equivocado, porque este comentario de ese blog lo atestigua perfectamente...:

"one of the leading causes of Windows reliability problems" - tell me about it. I had to return about 90% of audio cards I bought because the drivers simply would not work for more than few minutes of playing audio on a multiple cpu system (and I mean multiple CPU, not just HT). Mixing multiple sources when you can actually have multiple requests coming in at literally the same time proved to be beyond most hardware manufacturers' skill. The only card that worked reliably for me was an old AWE32 running Microsoft's drivers but I can't use that anymore as my current mobo does not have an ISA slot. I'm currently using a card based on VIA's Envy24-HF chip with VIA's drivers, it doesn't sound as good as some other cards but at least it does not crash my box.

Podría apostarme algo a que los desarrolladores del subsistema de audio de windows van a sentir tentaciones de poner un pedazo de punto de sincronización a la entrada del subsistema de audio para evitar que más de dos procesos puedan entrar simultaneamente en esa parte del kernel...y que dejen de echarles la bronca cuando los dualcore se usen mucho...

pensamientos matutinos

El otro día yendo por ahí por la noche con un amigo, vimos a un par de chicas que estaban sentadas a las que no conociamos de nada. Como estabamos aburridos nos pusimos a darlas la tabarra como quien no quiere la cosa (con buenas intenciones)

Recuerdo que alguien pregunto a una de ellas algo sobre un ordenador, y ella dijo que no tenía. No solo eso, dijo que no le gustaban los ordenadores. Me sorprendio la respuesta, y me puse a "interrogarla" para averiguar de donde venía ese odio, porque me sorprendía que una chica de hoy en día odie los ordenadores. Conozco a gente que no tiene ordenador porque no lo cree necesario o por lo que sea, pero no conocía a nadie que no tuviera ordenador porque lo odiara. Asi que me puse a hablar de lo útil que son cosas como el messenger, que te permiten estar en contacto con la gente, cosas que a todo el mundo le gustan, lo usen o no

Eso pensaba, pero me equivoque. Me respondió que no comprendia los ordenadores. No que no supiera usarlos o algo de esos, sino que no les "entendia", que ya había visto y probado el messenger por ahi, que los ordenadores eran demasiado complicados de usar y que para hablar con sus amigos prefería usar el telefono, que era mucho más práctico

¿Y que puedo aprender yo como "informático" de cosas como esta? No lo se, pero supongo que algo

más DRM

En slashdot han hablado de un magnífico artículo que analiza el "hogar digital" desde un punto de vista de un economista. Me gusta especialmente estos párrafos sobre DRM:

In DRM, the situation is even more chaotic. Microsoft pushes its Windows DRM; RealNetworks, which makes rival media software, has Helix; Sony has OpenMG; Apple likes FairPlay, and so on. The upshot is that consumers cannot mix online services, gadgets and software from different vendors and be sure that the content they have paid for actually works. Music bought online from Microsoft's MSN or Yahoo!, for instance, does not work on Apple's iTunes or iPod, and vice versa.

This challenge is daunting because DRM technologies should not only be compatible today, but for all eternity. Otherwise, consumers will be afraid to pay for content, and will stick with CDs and DVDs, which seem painless and safe by comparison. “If consumers even know there's a DRM, what it is, and how it works, we've already failed,” says Peter Lee, an executive at Disney. The same goes for codecs. “The user shouldn't know or care what format they're using,” says James Poder, an engineer at Comcast, America's largest cable company and broadband internet service provider, because “consumers don't want to be IT administrators for their own home.”

Mac OS X vs linux vs threads

Los de Anandtech han hecho unos benchmarks de Mac OS X vs linux como plataformas de servidor en el cual muestran lo exageradamente lento que es mac os x en ese campo: It is clear that if you plan to run MySQL on Apple hardware, it is better to install YDL Linux than to use OS X. If you need excellent read performance, the maximum performance of your server will be up to 8 times better

Pero lo mas interesante es el análisis de por qué es así. Pocas veces en una comparativa el comparador se pone a hacer un análisis detallado de porque esto es así y asá, en vez de conformarse con dar los resultados y concluir el artículo diciendo "fulanito es mas rápido". http://www.anandtech.com/mac/showdoc.aspx?i=2520&p=7 y http://www.anandtech.com/mac/showdoc.aspx?i=2520&p=8

escritorio y last.fm

Picado por el post de Javier Santana, yo tambien voy a poner una foto de mi escritorio (y asi, de paso, probar la cosa esta que añadieron al blogger de "subir archivos")


(Update: he puesto las imagenes como enlaces, me salian demasiado grandes y pense que podria dañar al planet) Escritorio


En el cual se pueden observar varias cosas: 1) que uso XFCE (aunque a veces cambio a KDE) 2) que en la barra de tareas, el texto del botón se sale del botón. Es un bug que me apareció al instalar GTK 2.8 (el basado en cairo, etc etc) 2) que uso sylpheed, y fuentes gigantescas para no quedarme ciego. 3) un post de un auténtico gilipollas. Jeff Merkey, el tipo que propuso a los del kernel comprarles el copyright para licenciar el kernel bajo la BSD 4) que uso amarok y que en ese momento estoy escuchando un album cuyas canciones están compuestas por uno de los mejores guitarristas de este pais


Y sobre last.fm, decir que Ramón Rey me picó, y que me he apuntado a la moda. Mi URL es http://www.last.fm/user/diegocg/ . Apuntarme fue sencillisimo, y hacerlo funcionar mucho más porque Amarok trae audioscrobbler integrado

Tambien iba a decir algo sobre como el huracán que está matando a miles de estadounidenses es consecuencia del Flying Spaguetti Monster, mi nuevo Dios. Pero la verdad es que es una putada lo que ha pasado allí, especialmente sabiendo que estados unidos tiene los recursos para evitar "catastrofes" de ese tipo, en el sentido de evacuaciones y eso


Aun así no puedo evitar poner una foto del Flying Spaguetti Monster, creador del Universo

Flying Spaghetti Monster