Entrevista a Linus

En forbes

Q: So you are leaving the door open?
A: Hey, I'm flexible. Some people call it being indecisive, but personally, I think it's a sign of intelligence when a person is able to change his mind when circumstances change.

"If you're a mad scientist, you can use GPLv2'd software for your evil plans to take over the world ("Sharks with lasers on their heads!!"), and the GPLv2 just says that you have to give source code back. And that's OK by me. I like sharks with lasers.

"El fin de los discos duros" II + Intel

Una vez dije que el fin de los discos duros estaba relativamente cerca y que ahora si que iba a ser ssustituido por memorias flash (en el plazo de 10 años)

Quizás alguien estuviera en desacuerdo conmigo, pero la realidad es que la transición ya está empezando. Se empieza por un cache para acelerar el arranque del sistema (es lo que llevan los imac intel por cierto), luego se aumenta de tamaño, etc etc. Se utiliza esa memoria flash porque a diferencia de la mecánica del disco la memoria flash no necesita hacer movimientos del brazo y por tanto es infinitamente más rápido en cuanto tienen que leerse datos de varios sitios. Ahora que se empieza a ver memoria flash por todos los lados surgirán empresas e inversiones orientadas a producir mejores productos flash, las memorias flash disminuirán de precio y aumentarán el número de ciclos de escritura a un número razonable (recordar que los discos no son eternos, tambien tienen un uso limitado solo que la técnica los han perfeccionado lo suficiente como para poder ser utilizados continuamente durante años). Otras cosas interesantes en theregister hoy:

• Nueva plataforma "core" de Intel que tiene todas las posibilidades de poner en verguenza a los AMD (sería ridículo que no lo hiciera, si Intel no es capaz de responder enérgicamente al pelotazo de AMD de los últimos 2 años sería una empresa condenada al fracaso)


• Esa plataforma saldrá en el 2007 para portátiles e incluirá soporte de 802.11n


• Tambien hizo benchmarks Intel, y parece que las cosas le van bien. No tanto como muestran ahí (a saber lo que podían haber hecho a las máquinas para joder a los amd), pero probablemente bien.


• La plataforma "ultra-mobile PC" va a ser la novedad de este año. Básicamente se trata de hacer cosas como el 770, parecen apetecibles


• Y por último, notas de una presentación de google que a los googleros se les han escapado y en las que dicen que quieren convertir al PC en una especie de "cache". Microsoft gana dinero del software de los clientes y si el valor de las cosas acaba estando en la red (ej: te da lo mismo utilizar linux que windows para acceder a esos servicios) y los clientes son simples "terminales tontos", el valor de Microsoft se reduce. Asi que es oficial: Los terminales tontos han vuelto.

(Espero que tras leer esos enlaces la gente comprenda porque http://www.theregister.com es un sitio imprescindible)

Me gustan los errores devueltos en cadenas de error

Aparentemente a alguien no le ha parecido buena queja mi queja sobre que Unix debería volver códigos de error en forma de cadenas en forma de enteros. Creo que debería haber explicado exactamente que quiero decir por devolver cadenas de error en vez de números (lo cual no quiere decir que me vaya a arrepentir de algo de lo que dije, más bien lo contrario)

Básicamente, mi queja era que yo quisiera que se pudiera hacer "si 'cvs update' = 'No updates found"" en vez "si 'cvs update' = 0". ¿Por qué? Porque "No updates found" significa algo, y "3", no. Si me gustaría probar cadenas de error en vez de códigos es porque tienen significado, y eso es bueno.

Pero vayamos por partes. Algo que no admito es que la gente se ponga a hablar de "filosofía Unix", de potencia, de scripts y de extendibilidad en un post que supuestamente va a críticar a las cadenas de error. Las cadenas de error no restan extendibilidad ni potencia ni nada por al simple razón de que son prácticamente lo mismo. El programador quiere saber lo que ha devuelto el comando y en vez de utilizar un código, utiliza una cadena de error, punto. Las posibilidades son exactamente las mismas.

La persona a la que le gustan los códigos de error tambien dice que se evitan problemas como que en una actualización/modificación del software un cambio en una simple letra tire al traste todo lo que se haya construido encima. Me gustan ese tipo de afirmaciones en las cual se dice que tal cosa tendrá tal efecto y ese efecto es efecto secundario (indirecto), porque en muchas ocasiones la asociación que se hace a ese efecto secundario no tiene porque tener ni pies ni cabeza, como en este caso: Si las cadenas de error son malas porque al cambiar una letra todo se va a la mierda, los códigos de error son malos porque cambiando un "2" a un "3" tambien mandarás todo a la mierda, y puestos a ser cínicos tal vez sea solo yo, pero mientras que cambiar un número apenas se notaría a primera vista - porque en realidad no significan nada por si solos sin una asociación a un código de error - una falta en una cadena de error se notaría mucho más. Si nos ponemos a buscarle siete patas al gato, porque no afinar un poco y sacar ocho. Lo de traducir ni lo comento: en ningún lado he propuesto que dichas cadenas de error deberían ser traducidas. Eso es como proponer que el "if" debería traducirse a "si" cuando compila un español. Los programas deben funcionar correctamente al margen del idioma del usuario, punto.

Pero voy a explicarme más: No me he sacado esto de la manga, repito, y no son solo sistemas operativos como Plan 9 los que me hacen pensar que las cadenas de error son mejores (llamarlas "cadenas de error" es un poco inadecuado, porque para empezar no tienen porque indicar un error, pero bueno). Aquí va un ejemplo de por qué lo que pido no es ninguna fantasía absurda

if (malloc(...) == NULL)

¿Se ve, o no se ve? NULL no es más que un define a "(void *) 0". No solo es NULL: Hay millares de defines de C en el mundo desde hace décadas, algunos de ellos se utilizan para comprobar el retorno de las funciones (no tan a menudo como se podría por desgracia). Tengo un preload.c aquí que hace un switch y luego tiene un "case PROC_EVENT_FORK", "case PROC_EVENT_EXIT", y un "case PROC_EVENT_EXEC".

¿Por qué en C se hace esto desde hace décadas y esta bien, y cuando propongo que bash haga lo mismo a la gente no le gusta, tan metida tiene la gente los "estándares" en la cabeza como para no tener un poco de imaginación e imaginarse cosas distintas a las que utilizamos? ¿Tan mala es la idea de poder hacer un "if cvs update = 'no update found'"? ¿O por qué no puedo hacer un case "$(cvs update)" in en bash, y a continuación poder poner "no update found"), "no repository found") igual que hago en C con los switch, en vez de poner 5), 2) y -1)?.

Si fuera yo, diseñaría el sistema para que los programadores proporcionaran esas cadenas de error y que estas cadenas se pudieran utilizar en bash, en C y en cualquier lenguaje de manera uniforme. La manera simple de implementar esto es utilizar códigos números que se correspondan con las cadenas de error y dejar que el lenguaje de turno se las arregle de la manera que le plazca. Si uno quiere utilizar el preprocesador en C, pues bien. Si bash quiere comprobar cadenas de texto, pues cadenas de texto. Eso es el método "conserva la compatibilidad". Pero la idea de que unix devuelviera cadenas enteras tal como hace 9P en Plan 9 (que tiene por cierto más "espiritu Unix" que Unix y que es el sistema operativo que utiliza desde hace años uno de los dos creadores de Unix) no me parece absurda (incluso considerando los inconvenientes) en absoluto, porque aunque parezca inútil el facilitar la gestión de errores ayudaría a hacer más fácil la gestión de errores que es uno de los problemas que tienen muchos programadores para construir software más robusto, y por eso estoy dispuesto a pagar un precio, al igual que los creadores de Unix se arriesgaron cuando decidieron utilizar un lenguaje interpretado para programar el kernel, un sistema de archivos jerárquico y un shell fuera del kernel (en aquel tiempo la norma era implementar el kernel en ensamblador, meter dentro el shell y los sistemas de archivos no jerárquicos). Para tener lo que tenemos hoy se tomaron en su día decisiones arriesgadas que en aquel tiempo eran medio herejías para algunos. Si tuviera oportunidad (que no la tendré nunca pero pongamos que si por el bien de este post) no me importaría tomar una decisión arriesgada como el que los procesos devuelvan cadenas de texto en las llamadas al sistema, por muy herejía que parezca.