Detección asíncrona de dispositivos en Linux 2.6.19

Suena raro, pero en realidad es muy simple. A día de hoy, cuando el kernel inicializa los dispositivos lo hace de forma síncrona. Es decir, se inicia el kernel, se van iniciando los subsistemas, se ejecutan los drivers que están incluidos dentro del kernel...y se espera a que termine para continuar haciendo otras cosas. O sea, se hace de un modo lógico: Se carga el driver, se detecta el dispositivo, se termina y se sigue haciendo otra cosa.

Este sistema tiene problemas. Por ejemplo: Mucha gente recordará, antes de que se pusieran de moda las pantallas de arranque (bootsplash) y de que se silenciara la salida del kernel, que el kernel se pasaba un rato (¿segundos, quizás?) "escaneando" el bus IDE. Y qué decir de SCSI, que puede tirarse medio minuto perfectamente.

El problema aquí es que ese método de detección de dispositivos es ineficiente: El kernel se pasa segundos parado, esperando a algo, a pesar de que aun tiene cosas de hacer. Lo eficiente sería que el kernel continuara inicializando otras cosas, mientras que se termina de detectar lo que sea. Más aun, sería recomendable que se pudiera detectar simultaneamente lo dispositivos IDE, SCSI, USB, mientras el kernel continua arrancando. Este problema afecta principalmente a los dipositivos embebidos, que aspiran a tener un inicio lo más corto posible.

Así que Greg Kroah-Hartman, el gran asesino de devfs, ha implementado la infraestructura para cambiar las cosas. Se crea un nuevo thread (porque los kernels bien hechos tienen infraestructura interna para lanzar threads propios y mejorar el diseño de algunos puntos, a diferencia de lo que cuentan desde el mundo de los microkernel) que inicializa el dispositivo, mientras que el kernel sigue ejecutándose. Cuando llega la hora de ejecutar init, el kernel espera a que terminen los threads que inicializan los dispositivos, si es que no han terminado (con procesadores multicore, los threads se ejecutarían en paralelo). Es más, supongo que esta idea se podría extender para permitir que se pueda montar el sistema de archivos raiz y que se ejecute aunque no hayan terminado de detectarse, pongamos, los dispositivos USB - bien por lentitud del proceso, o bien por un fallo de hardware o software.

De momento no está activado - por mucho que se diga, los hackers del kernel no meten cosas inestables a go-go -, pero ya se han mandado parches experimentales para implementarlo para el subsistema PCI, para SCSI...en fin, algo interesante

Firefox tiene más fallos de seguridad que IE. ¿Y qué?

Los pro-Microsoft se están poniendo las botas con esta noticia, que cuenta como Firefox ha tenido 47 fallos de seguridad en los últimos seis meses, mientras que Internet Explorer solamente ha tenido 38.

Si, exactamente. Firefox 47 - IE 38, Firefox perdedor por goleada.

No es una buena noticia. Y sin embargo, no se de qué se sorprende la gente. Hace más de un año, y quizás aun más, predije que Firefox en el futuro podría superar fácilmente el número de fallos de seguridad de IE, aunque creo que he borrado el mensaje por desgracia. La razón es de lo más simple: Firefox/Mozilla ha cambiado, Internet Explorer no. Con esto quiero decir que la base de código de Firefox ha estado evolucionando los últimos 4 años, e Internet Explorer no.

Los fallos de seguridad se introducen cuando se cambia código, y se introduce más código cuando se introducen nuevas características y se modifican las existentes. Cuando dejas de modificar un programa y te dedicas tan solo a arreglar fallos, el programa se hace más seguro y estable porque estás tapando agujeros sin crear agujeros nuevos. Esta es la razón por la que auténticas bazofias en materia de seguridad como sendmail o bind son más o menos seguras: Se han encontrado tantos fallos que es ya dificil encontrar fallos nuevos. Si, hay programas mas o menos seguros, plataformas más o menos seguras, pero a grandes rasgos lo que acabo de decir afecta a todo tipo de programas.

Firefox tiene fallos porque lleva los últimos 4 años (los primeros años en mozilla, cuando aun no existía firefox) cambiando, evolucionando, mejorando el soporte de estándares, implementando estándares nuevos. Y todo esto sobre una base de código nueva, la de mozilla, que tampoco había ganado en el pasado la suficiente cuota de mercado como para hacer que los crackers buscaran agujeros, con lo cual Firefox heredó una base de código relativamente poco probada.

Eso es en esencia lo que hace que Firefox tenga esta cantidad de fallos. Sin embargo, los cambios que han producido esos fallos son los mismos que han hecho posible el éxito de Firefox. El Ying y el Yang. El precio que hay que pagar. Esa balanza se puede intentar desequilibrar con métodos de desarrollo seguros, lenguajes, ayudas del compilador, talento, pero tan solo se consigue desequilibrar ligeramente, la esencia nunca se modifica. Probablemente sea posible instaurar un régimen de desarrollo y de control de calidad que mejore las estadísticas de seguridad de Firefox (y no hay que olvidarse de ello), pero lo esencial nunca cambiará. Firefox solamente empezará a tener menos fallos de seguridad cuando madure y se estabilize la base del código, que ocurrirá algún día.

Pero el fracaso de Firefox no significa que Internet Explorer se libre de la quema. De hecho, las estadísticas anteriormente citadas me parecen mucho más desfavorables para Internet Explorer. ¿Por qué? Porque como he mencionado antes, cuando un programa deja de modificarse, se estabiliza, como pasa con sendmail y bind. Sin embargo, Internet Explorer no ha sufrido cambios radicales en su estructura durante cuatro años, y aun despues de todo este tiempo sigue teniendo una altísima cifra de fallos de seguridad (el único cambio que ha sufrido son los del XP SP2, una distinta gestión de los "objetos" y las zonas de donde provienen, y un retoque a la manera de gestionar el active x, nada radical realmente, y cero cambios al renderizador de páginas).

¿Por qué Internet Explorer no se estabiliza, como le ocurre a otros programas? ¿Por qué un programa que a estas alturas debería ser sólido como una roca y debería tener un índice de fallos de seguridad bajísimo llega a unas cifras que aun si son mas bajas que antes siguen siendo escandalosas? Se me ocurre una buena respuesta, que tiene que ver con la calidad del código de Internet Explorer, pero mejor lo dejo a la imaginación de cada uno. Firefox se ha dedicado en los últimos años a mejorar hasta el punto de que ya pasa el ACID2. Internet Explorer, sin embargo, está en la edad de piedra aun en la versión 7.0. Internet Explorer 7 traerá más fallos de seguridad a la cuenta de Internet Explorer, pero el soporte de estándares sigue siendo escandaloso. Tal vez tengamos que esperar a Internet Explorer 8.0 para ver el número de fallos de seguridad que introduce su implementación. Claro que por aquel entonces, Firefox tambien será muy distinto. La realidad es que Internet Explorer se ha convertido en un tipo de aplicación muy, muy, muy distinta a Firefox, Opera y el resto de navegadores, hasta el punto que es algo dificil hacer comparaciones.

"Linux está preparado para el escritorio"

Y eso ya sin entrar a mencionar la interfaz y la maravillosa idea de enumerar las unidades y las particione en una lista con nombres tan expresivos como "particion 1", en vez de la típica y más expresiva barra horizontal de colores, que indica de un modo intuitivo el tamaño de cada una. ¿Y por qué un botón de "aceptar" o "cancelar", es que esto es acaso un diálogo de preferencias? ¿Despues de haber pulsado el botón "formatear" tengo que pulsar "aceptar" para que se formatee, o voy a poder pulsar "cancelar" si en realidad no quería formatear nada? Gracias a dios el botón de ayuda está muy accesible, porque es lo que el usuario va a necesitar, aparte de una bendición divina y un master en paciencia informática. El gestor de discos de Microsoft es una delicia comparado con esto.

Sobre dtrace, su equivalente linuxero kprobes, qué son y como funcionan

Act.: Se me olvidó contar que systemtap tiene incluso una interfaz gráfica (capturas y más capturas)

Los que anden al loro en noticias de sistemas operativos habrán oido hablar de Dtrace, la maravillosa herramienta de Solaris que permite obtener cualquier información del sistema. Lo primero que habría que contar sobre este tipo de herramientas es que aparentemente no tienen nada de nuevo, y que como tantas otras cosas ya se implementaron en los sistemas operativos de los años 60; incluso parece ser que OS/2 tuvo un "dtrace". Ver para creer. La segunda cosa que habría que contar es que el mundo Linuxero no está ni ha estado arrinconado en este aspecto. Dtrace se merece todos los aplausos del mundo, pero Linux se merece un cierto abucheo, porque ya desde el 2000 o antes ha habido gente intentando implementar un equivalente de lo que hoy es Dtrace. Es decir, comenzaron a implementarlo más o menos al mismo tiempo que Sun, pero Sun lo ha terminado y el mundo Linuxero no.

Existen dos proyectos principales que tratan de implementar un sistema de "instrumentación": LTT (Linux Trace Toolkit) y Kprobes + Systemtap. LTT hace "instrumentación estática" y Kprobes "instrumentación dinámica". La diferencia entre ambos es muy divertida e interesante porque consta de varios detalles de esos que son decisivos y hacen que algo fracase o tenga éxito con respecto a la alternativa. LTT inserta en lugares estratégicos del código fuente unas llamadas a funciones que recogen estadísticas variadas. La clave de LTT es que es estático, es decir, se tiene que compilar y una vez compilado no lo puedes cambiar. Por esa misma razón es eficiente, puesto que el compilador puede incluso optimizar las cosas, una ventaja. Pero otra desventaja es que esa recolección de datos ocurre - puesto que está insertada en el kernel - incluso cuando nadie está pidiendo estadísticas, y eso tiene un coste que se traduce en una pérdida de rendimiento, pequeña pero existente.

De eso se pueden empezar a sacar conclusiones: Ninguna distribución va a instalar por defecto un kernel con LTT activado, puesto que afecta el rendimiento. Necesitas recompilar y reiniciar, y ese es un aspecto clave, porque si quieres saber porque tu servidor de correo es tan lento necesitas saberlo en ese momento y no puedes permitirte reiniciar.

Lo ideal sería un sistema que no tuviera coste alguno de rendimiento cuando se está utilizando. Eso es lo que hacen los entornos dinámicos como kprobes + systemtap, y Dtrace, que tambien funciona así. En esos sistemas, no hay que insertar ningún "punto de recolección de datos" en el kernel, por lo tanto no tiene ningún (cero) coste de ejecución mientras no se está utilizando. Eso permite que las distribuciones activen kprobes y que por lo tanto, un administrador pueda conectarse a un sistema via ssh y empieze a utilizar kprobes inmediatamente, sin tener que reiniciar, ni recompilar.

¿Y como funcionan? Lo que hacen kprobes y dtrace es casi magia: Pueden insertar "puntos de recolección" en prácticamente cualquier punto del kernel. Lo que hacen es ir a la zona de memoria donde se encuentra el código ejecutable de la parte del kernel que se quiere analizar (la localización de la zona se obtiene mirando en la información de depuración, la misma que utiliza GDB), quitan (pero literalmente) la instrucción ejecutable que se encuentra en el punto deseado, insertan una llamada al código de kprobes que se encarga de recolectar los datos, ejecutan la instrucción que se había borrado para insertar el salto de kprobes, y continuan ejecutandose donde lo habían dejado.

Como dije, se trata de casi magia, una idea que parece absurda y dificil (me pregunto como narices han implementado eso en el caos de instrucciones de longitud variable que es x86) pero que realmente funciona, es implementable y está ahí. Es por ese sistema por lo que no necesitan insertar puntos de recolección en tiempo de compilacion y por lo que es tan atractivo. La desventaja es que son ligeramente más lento que ĺos puntos de recolección estáticos de LTT, pero solo ligeramente, y se están ensayando con alternativas (djprobes) que reducen esa desventaja aun más.

Lo realmente impresionante de Dtrace y kprobes es su espectro de aplicaciones. Se podría utilizar kprobes para ideas que hoy en día resultan dificiles de imaginar, como utilizar su infraestructura para parchear en caliente el kernel en caso de un fallo de seguridad. Tambien se puede utilizar, y es uno de sus principales atractivos, para sustituir otras técnicas de depuración. ¿Cuantas veces has visto código con código de depuración desactivado por defecto con un "#define DEBUG 0", que necesita ser recompilado (y reiniciado en el caso de un kernel no modular) para obtener información de depuración? Con kprobes y dtrace se pueden eliminar todos esos horribles printk()s de depuración de las fuentes: Puedes utiliar kprobes para monitorizar cualquier punto de tu código, obtener información de las variables, etc etc, y puedes hacerlo sin tener que recompilar nada, y puedes cambiar instantaneamente de opinión sobre qué información quieres conseguir, o obtener al mismo tiempo información de otras partes del sistema. Puedes pasar a un usuario a miles de kilómetros un script de dtrace que te facilite información sobre un servidor en funcionamiento, y saber qué ocurre, sin tener que pedirle que cambie ese define a "#define DEBUG 1" y que recompile y reinicie.

Y aun hay más. Dtrace no solo puede monitorizar el kernel, tambien puede monitorizar el espacio de usuario, asi que todo lo que se aplica aquí puede aplicarse tambien a los programas normales y corrientes. Kprobes aun no puede hace: no ha madurado aun lo suficiente, pero están trabajando en ello. Dtrace sin embargo si que lo hace, y se han implementado ya "monitorizadores" para java o incluso javascript, de manera que puedes utilizar dtrace para analizar como funciona el sistema de arriba a abajo mientras se ejecutan cálculos intensivos en el navegador. Tambien se puede utilizar para reemplazar a herramientas de estadísticas. Por ejemplo, en 2.6.17 o 2.6.16 se incluyó blktrace, una infraestructura que permite obtener estadísticas detalladísimas de todo lo que ocurre en las peticiones a disco. En realidad blktrace es algo similar a LTT, un instrumentador estático: inserta "puntos de recolección de datos" en las fuentes, aunque su intención no fuera otra que obtener estadísticas del disco. Tambien podrían englobarse aquí a herramientas como sar, vmstat, o incluso ps. En el caso de blktrace, el desarrollador que lo implementó ya ha anunciado que en cuando kprobes + systemtap estén maduros, eliminará todo el código de blktrace, puesto que podrá ser implementado en forma de scripts de kprobes + systemtap.

En Linux, por cierto, systemtap es la otra parte del sistema (el término dtrace engloba al equivalente de kprobes + systemtap): kprobes se encarga del reemplazo de instrucciones, almacenamiento de la información capturada, etc etc; systemtap implementa un lenguaje que permite escribir scripts; posteriormente son analizados por otra parte de systemtap que se encarga de validar las peticiones del usuario (es posible construir peticiones de kprobes que cuelguen el sistema, y no se deben permitir) y finalmente construyen las peticiones que se mandan a kprobes, y se recolectan y se muestran los datos al usuario. Y eso es todo. Kprobes + systemtap se puede empezar a utilizar hoy mismo, tan solo hay que activar kprobes en el kernel, que ya está (a diferencia de LTT) en el kernel, e instalar el paquete systemtap, y a disfrutar.

ESTAMOS ACABADOS

No serán ni el islam radicalizado ni una invasión extraterrestre ni un cambio climático lo que acabará con la civilización. La suerte del ser humano está echada, y son LOS ELEFANTES

¿Existe una mirada más aterradora?

Los humanos creen que los elefantes son imbéciles por ser animales, pero apuesto a que ellos no están de acuerdo. Los elefantes, por ejemplo, son capaces de recordar los huesos de sus familiares muertos despues de muchos años y kilómetros en las patas; mientras que los seres humanos jamás vuelven a sus cementerios, porque el día antes es Halloween (fiesta que no tiene nada que ver con la cultura de este pais pero que a base de imbéciles y de gilipollez hemos dejado que nos impongan) y la gente prefiere estar de resaca.

"No hay que olvidar que es un animal de gran tamaño", dice un tal Valdecillo. No lo olvidamos, compañero Valdecillo. Sin duda, un buen consejo que recordar para los tiempos que se avecinan.

Impresionantes efectos 3D

Me he encontrado con este video en youtube, mostrando lo increiblemente avanzado que está el tema de compiz:



Ahora bien: Algunos de esos efectos, como dicen en compiz.net, son útiles y pensados y destinados para mejorar la usabilidad. Otros son experimentales y para probar la tecnología en si y son una mierda, como ese blur inicial que no te deja ver un cristo. Pero el efecto onda a mi al menos me gusta: Las ondas centran la mente del usuario en los contornos de la ventana. O al menos a mi me centran, creo. Quizás son unas ondas un poco exageradas, pero no me molestan, aunque tendría que probarlas.

¿Pueden llegar a ser útiles esos efectos? ¿Si, no? No lo se, pero lo cierto es que desde que salió Mac OS X con sus transparencias y sus animaciones no se había visto semejante progreso en el campo de los efectos visuales (aka: eye candy). Lo irónico es que los subsistemas gráficos de Mac OS X y Windows Vista son mucho mejores que lo que tenemos hoy en Linux, pero es Linux el que está metiendo ese tipo de efectos. Y antes que alguien venga y me diga: "Es que eso son cosas inútiles, Mac OS X/Vista no mete esos efectos porque cansan" "los efectos de ese tipo no son para tanto" "los efectos visuales son inutiles", que piense en la revolución que supuso Mac OS X. Mac OS X y su interfaz se han hecho famosa, además de la usabilidad, por ser muy eyecandy: Por tener transparencia, por el uso de las capacidades de la tarjeta gráfica para hacer al escritorio más bonito (Expose). Todos los sistemas operativos aspiran a tener transparencias hoy: ¿Por qué?.

No existe ninguna razón por la que compiz no puede aplicar el cuento de Mac OS X a lo que tenemos hoy y hacerse mejor que los demás mediante la utilización de efectos. No de cualquier efecto, por supuesto: De aquellos que tengan sentido. Del mismo modo que Mac OS X no utiliza transparencias en todos lados porque sería un caos, no tienen sentido muchos de los efectos de compiz. Pero otros si. Tampoco hay ninguna razón para no creer que Apple y Microsoft trabajan en efectos similares desde hace tiempo, especialmente Apple, pero parece que se guardan los ases en la manga.

Una prueba más de que los controladores no libres son una puñetera bazofia

Pues si, porque resulta que yo tengo aquí no uno, sino dos equipos con tarjeta gráfica radeon 9200, que es exactamente la misma versión que ATI ha dejado de soportar en su última versión de sus horrendos - e ilegales - controladores propietarios para Linux. En realidad la cosa no es tan mala, porque en los drivers para Windows habían dejado de soportarlas hace ya un tiempo; parece que el soporte para linux ha durado unos pocos meses más, aunque sea debido al retraso que sufre el citado soporte con respecto al de Windows. Algo es algo.

Afortunadamente, en linux hay drivers libres para esas tarjetas. Eso me libra de tener que comprarme tarjetas nuevas, por el momento. Pero oigan, yo tengo aquí mismo la caja donde venía la tarjeta con chip ATI y en ningún lado te pone cual va a ser la fecha máxima de soporte. Que no es que me importe, porque su mierda de drivers - o los de Nvidia, que son tal para cual - los van a usar su puñetera madre, pero creo que como usuario tengo derecho a saber esas cosas. Al menos que ahora los ultraliberales ultragilipollas de turno argumenten que reivindicar derechos como usuario afecta al margen de beneficio de las empresas y que por tanto entorpece el progreso de la humanidad. Porque tanto en el caso de los drivers de Windows como en los de Linux sufro cuelgues con esos malditos drivers, y alguien tendrá que hacerse responsable, digo yo.

Asi que sospecho que acabaré mandando a tomar por saco todo y lo sustituiré algún día por hardware Intel, que será lo que sea pero publica drivers libres para sus cosas. Desvanecida ya mi ira, quiero atraer la atención sobre este maravilloso programa libre.

Integrando Linux con el Directorio Activo

En este blog un trabajador de Suse cuenta el magnífico trabajo de integración que están haciendo para que un cliente linux pueda integrarse sin problema alguno en entornos con servidores Windows y Carpeta Activa, perdón, Directorio Activo.

Como dicen en esa entrada, una empresa no tiene porque ser pro-Microsoft para no querer poner escritorios Linux: Basta con depender de la integración que proporciona la Carpeta Activa y que el mundo del software libre, se ponga como se ponga quien quiera, no sabe proporcionar. Y no me refiero solo a que Linux no se integra correctamente en entornos Windows, que es algo de esperar, especialmente cuando Microsoft se niega a cumplir las directrices de la Unión Europea que exigen que Microsoft documente la Carpeta Activa, algo que algunas empresas hacen sin necesidad de que se lo pidan ni tan siquiera sus propios clientes. Me refiero tambien a que Linux es incapaz de proporcionar funcionalidad similar a la de la Carpeta Activa en entornos en los que tanto el servidor como los clientes corren Linux. A ver como va a poder Linux competir al 100% con servidores Windows cuando nos faltan herramientas como estas. Y que nadie me venga con lo de que un administrador de verdad no debe utilizar interfaces gráficas ni asistentes o alguna una chorrada similar, que me da la risa y el médico ya me ha dicho que tengo que moderarme: Una de las virtudes de los administradores Unixeros ha sido siempre la vagancia y el buscar maneras de trabajar aun menos, y las interfaces gráficas y los principios de usabilidad se ajustan perfectamente al servicio de esa virtud.

Menos mal que Suse está poniendo manos y sobre todo pasta a la obra, y las cosas mejorarán; para algo se trata de Novell, que de directorios sabe un rato.

Por cierto, en gnome-look.org hay una magnífica maqueta con un radical cambio de diseño al escritorio Gnome.

Bravo por Intel, de nuevo

La liberación de driver completos para sus chipsets graficos i965 ya fue un gran paso a favor del software libre. Ahora Intel ha anunciado otro proyecto de software libre: "The Linux-ready Firmware Developer Kit"

Quien lo anuncia es Arjan van de Ven, ex-trabajador de Red Hat y conocido y muy respetado hacker del kernel. Hace tiempo que se fue a Intel, ahora se ve en que tipo de cosas ha estado trabajando hasta ahora. La idea de este proyecto es simple: Se trata de un Live-CD que comprueba si tu máquina es compatible con Linux. Pero no se queda en decirte si es o no es compatible, tiene una interfaz basada en ncurses que te cuenta los fallos que tiena la BIOS, el ACPI, las tarjetas PCI conectadas...básicamente se trata de pasarle unos test para poder estamparle la pegatina "Linux-compatible", si hubiera pegatinas "Linux-compatible". Si los jefazos de las empresas forzaran a sus programadores a pasar este CD por el hardware en desarrollo, ganaríamos mucho. Supongo que la intención del proyecto es que lo acaben haciendo.

Que si, que el final de los discos duros se acerca

Ya predije en su día el fin definitivo de los discos duros mecánicos en el plazo de 10 años, pero las empresas se empeñan en llevar la contraria y hacer ese plazo aun más corto.

Samsung ha creado un nuevo tipo de memoria flash (o quizás se trate de la aplicación de marketing a algún tipo de memoria ya existente) que es 30 veces más rápida que las memorias flash convencionales, dura 10 veces más, y es más barata de producir.

No hace falta ni mencionar que las acciones de las empresas dedicadas a fabricar flash se están volviendo cada día más "interesantes".

Qué tendrá Ubuntu Edgy

Esta se trata de una lista detallada e interesante, no de una de esas listas que dicen "oh, han añadido un menú nuevo". Ahora que ya soy Ubuntero, estoy obligado moralmente a hacer publicidad de Ubuntu. O quizás no estoy obligado, pero me entran ganas de hablar sobre ello, que para eso me monté un blog. Asi que voy a hablar de qué traerá la próxima versión de Ubuntu a partir de la información que se encuentra disponible en las páginas de Ubuntu, porque ni de coña voy a bajarme yo las ISOs de desarrollo que sacan. Quizás hasta me meneen, porque no he visto ningún blog de nadie que sea tan estúpido como para perder el tiempo con estas cosas.

Una de las diferencias de la próxima Ubuntu Edgy con respecto a la anterior Dapper es que la anterior estaba llamada a ser especial, con soporte a largo plazo (LTS), que es una de esas cosas que se ha inventado Canonical para estructurar su modelo de servicios alrededor de Ubuntu. El caso es que por esa razón Dapper no incluia mejoras demasiado radicales, para evitar problemas y hacerla más estable. Y en Edgy no sufrirán esa limitación, asi que habrá mejoras bastante sustanciales. Dicen.

Con respecto al desarrollo, Ubuntu es un proyecto bien organizado. A la hora de trabajar para la distro, aparte del trabajo típico que encuentras en cualquier distro por famosa o rara que sea, existe una lista de "especificaciones": Una lista de cosas que deben hacerse. Un TODO, un roadmap, vamos. Se aprueban antes de empezar a desarrollar la distro, y se trabaja durante todo el desarrollo en implementarlas. Aquí están la lista de las cosas importantes que acabará teniendo Edgy. La primera de todas las "especificaciones", aunque no aparezca en esa lista, es Gnome 2.16. Y probablemente sea la más importante: en una distribución de escritorio lo importante es el...escritorio; Edgy tendrá por tanto todo lo que trae Gnome 2.16. Para mi gusto las mejoras importantes de Gnome 2.16 son: mejoras al ya de por si estupendo applet de control de energía, mejoras al plugin de totem para firefox hasta el punto de hacerlo usable (en serio, en mi opinión el tener un plugin de un reproductor de video con interfaz gráfica disponible para firefox es una de las mejoras de integración más relevantes que ha habido ultimamente en el mundo del escritorio linuxero) y mejoras de rendimiento, tanto en el inicio de gnome en si como en el inicio de nautilus, gnome-terminal, yelp, evolution. Quizás no sea gran cosa para la opinión de muchos (sigo sin poder tener una vista de miniaturas de fotos y videos en el selector de archivos de gtk, vital para las aplicaciones que necesitan abrir archivos de ese tipo), pero si miras el vaso de otra manera no ha empeorado, y aunque no haya grandes mejoras funcionales y que no me vaya gnome, he de reconocer que es muy loable dedicarse a mejorar el rendimiento y uso de recursos de la aplicación. Casi nadie dedica mucho tiempo a esas cosas, y es importante. En fin, siguiendo con el tema, aquí van las "especificaciones":

• Separación de los símbolos de depuración de los ejecutables: Esta es una grandiosa idea, implementada ya por Fedora y otras distros. En Debian lo normal es que los paquetes vengan sin símbolos; algunas veces (muy pocas) hay paquetes terminados en "-dbg" que uno puede instalar en sustitución de los originales y que incluyen el mismo programa pero compilado con símbolos de depuración. Bien, la solución de Ubuntu es suministrar paquetes que contienen solo la información de depuración de un programa, y suministrarlo para todos los programas, no solo para los que suministran paquetes alternativos -dbg. Eso implica que yo puedo instalar gaim, y luego instalarme el paquete gaim de información de depuración, que es adicional, no sustitutivo, para instalar la información de depuración y poder reportar los mil cuelgues que sufro cuando lo uso.


• Relacionada con la anterior, un sistema para enviar información de cuelgues de aplicaciones automáticamente, al estilo del de XP


• Borrado automático de paquetes no dependientes: Cuando instalas un paquete foo y se te instala libfoo, y posteriormente lo borras borrando foo, libfoo se te queda instalado. Es un fallo, libfoo se debería desinstalar junto con foo


• Posibilidad de actualizar Ubuntu fácilmente metiendo las actualizaciones en un cdrom


• Activar SSP, una protección contra buffer overflows (-fstack-protector) que trae GCC 4.1. No se compilan todos los paquetes, de momento solo algunos paquetes importantes (perl, python, libc, firefox, gtk, apache), en la próxima versión se activará por defecto para todos.


• Soporte de XEN


• Volcado de memoria del kernel en caso de cuelgue del kernel, utilizando el fabuloso método kexec + kdump.


• Programa para hacer copias de seguridad utilizable por el usuario de a pie.


• Upstart, el reemplazo de init


• Relacionado con lo anterior, Apagado rápido
  
• Cerrar el pico a Grub. Se refiere a los mensajes esos que te indican que se está cargando el kernel, y tal y cual. No deberían aparecer, a los usuarios no les interesa el tamaño del kernel, ni leer un "Loading kernel...."


• Hacer más sencilla la instalación de codecs. Como ya sabrá todo el mundo, Ubuntu no incluye ciertos códecs por defecto por razones de patentes. Pero eso no es lo peor: Lo peor es que si vas a abrir un DVD o un video con un codec no disponible en la instalación por defecto de Ubuntu, te da un mensaje de error tipo "no se ha podido leer el medio". Un error que nadie entiende, y que confunde: ¿Está el DVD rallado y no ha podido leerlo? ¿Es un fallo de Ubuntu? ¿Por qué no utilizar la idea (e incluso la infraestructura) del comando file y ayudar al usuario con un mensaje tipo: "Ha intentado visualizar un video en formato divx/mp3/foo, pero actualmente no hay instalado ningún codec que permita verlo. Visite esta página para recibir ayuda sobre como instalarlo". O algo así.


• Un "servidor de swap", para poder hacer swap en sistemas remotos a través de la red. He de comentar aquí que esto es una idea nada trivial de implementar en el kernel


• Sustitucion de b/bin/sh por dash, un shell alternativo que cumple los requisitos POSIX y no consume tanta memoria: Buena idea teniendo en cuenta que /bin/sh es lo que se utiliza para ejecutar scripts


• Comportarse como un buen sistema operativo cuando el usuario quita una llave USB o algo asi sin desmontarlo previamente: Hacer desaparecer los iconos que pudiera haber creado, advertir de la posible pérdida de datos...


• Traducción de las descripciones de los paquetes. Otro ejemplo de como Ubuntu beneficia a Debian


• Si una persona intenta ejecutar un programa (ejemplo: está cansado de gaim y quiere ejecutar kopete) pero ese programa no está instalado....¿Por qué no avisarle de que para conseguir el programa puede instalar x paquete ?

Y bueno, esas son las cosas que parecen interesantes. Como ya he dicho hay más, algunas de ellas han sido postergadas por no poder estar a punto para edgy y probablemente se implementen en la siguiente versión. Cosas realmente curiosas, como irte avisando por el altavoz de mensajes de inicio del sistema y cosas asi.... En cualquier caso, es bonito ver como en Ubuntu hay una serie de objetivos claros y como la gente pelea para lograrlos. Eso es lo que hace que Ubuntu sorprenda tanto en cada versión.

Adios cinco años de Debian, hola Ubuntu

Pues si, despues de alrededor de cinco o seis años utilizando mi Debian, me cambio. No me refiero a utilizar distintas instalaciones de Debian durante ese periodo de tiempo, sino a que durante esos cinco años, he utilizado la misma instalación de Debian, que ha sobrevivido a cambios de disco duro, de placa base, de todo. Desde que conocí APT supe que todo usuario tiene derecho a no tener que reinstalar un sistema operativo, y a diferencia de Windows donde desactivar la ACPI en la Bios de un sistema con un windows que cuando se instaló lo tenía activado significa que el sistema no arrancará y que necesita reinstalar (no es coña), Debian y APT forman una sólida pareja capaz de aguantar lo que les echen. En ese aspecto, Debian ha ido mucho más allá de donde mi imaginación podía soñar.

¿Por qué me cambio, entonces? Las razones son varias. Una, que hace cuatro o cinco años no sabía lo que se ahora, y sabe Dios la de hacks que he hecho a lo largo y y ancho de estos años. He mantenido simultaneamente paquetes de testing, unstable, experimental, repositorios externos, proyectos externos compilados a mano y "sobrecargados" tocando /etc/ld.so.conf. Hasta ahí bien, lo norma, pero tambien he hecho hacks a lo largo de todo el sistema, modificando scripts tanto en /etc como en /usr, modificaciones que no he anotado jamás (fallo que ningun administrador debería cometer) y que por tanto ya no recuerdo, pero que están, están por ahí. Mi Debian no estaba tan limpia como debiera. Pero tambien hay más razones: Ubuntu comparte todo lo bueno de Debian, con el añadido de cosas buenas propias, lo cual convierte a Ubuntu en un "Debian++", en mi opinión. Jamás piqué con el ridículo cuento chino de muchos debianeros (incluidos algunos desarrolladores e incluso Ian Murdock cuando tenía el día malo) de que Ubuntu "roba" a Debian y que sus desarolladores son malos malotes. La gente que critica a Ubuntu siguiendo ese sendero no tiene ni puñetera idea de que significa realmente el software libre y de que va todo esto. Dicen que Ubuntu utiliza los esfuerzos de Debian: por supuesto que lo hace. ¿Y como podría ser de otra manera? Cuando uno apoya realmente el software libre y acepta que cualquier persona puede descargar y modificar tu código fuente, acepta tambien que alguien pueda utilizar ese software para hacerse rico, para encriptar el correo de Bin Laden, para crackearte tu propio ordenador, para tirarse por un barranco o para lo que le de la puñetera gana, y lo acepta sin complejos ni de ningún tipo. Eso va implicito en la palabra "libre" de la expresión "software libre", pero a muchas personas les encanta poner zancadillas a la libertad, si ello sirve para que el mundo se ajuste mejor a su concepto personal del bien y el mal.

Naturalmente, tampoco es que Ubuntu no colabore con Debian y que lo anterior sea una excusa. Hay que ser muy canalla para mantener, y hay mucho canalla por ahí, que Ubuntu se beneficia de Debian sin dar nada a cambio mientras los debianeros sudan la gota gorda para mantener a Ubuntu. En realidad es la popularidad, el ganar comparativas por todas las esquinas, el que los usuarios nuevos y no tan nuevos prefieran Ubuntu, lo que inspira las criticas de algunos. Es lo que animó a varios gilipollas (incluido algún desarrollador de debian) que en la última debconf abuchearon a algunos de los que trabajaban para Ubuntu, insultaron a uno que llevaba una camiseta de Ubuntu y aplaudieron al que llevaba la camiseta de "Fuck you, Ubuntu". Simple y llana envidia: Gente que quizá ignora (y lo peor es que en algunos casos no lo ignora, pero mantiene su odio) que el empaquetamiento de las nuevas versiones de gnome se hace primero en Ubuntu y posteriormente se pasa a experimental, sid y compañia. Gente que ignora que la transición de la ABI de C++ a GCC 4.0 se hizo en Ubuntu antes que en Debian, que cuando se modularizó X.org se empaqueto antes para Ubuntu que para Debian y Debian se benefició de ello. Gente que no lee los changelogs y que por tanto no ve las numerosas contribuciones que Ubuntu ha hecho a APT y dpkg; el núcleo de Debian, además de hacer de batería de pruebas con fuego real de todas esas modificaciones. Gente que ponen a parir a Ubuntu pero no a Linspire, ni a Xandros, ni a Libranet, ni mucho menos a Progeny, la distro comercial de Ian Murdock, porque esas a pesar de ser comerciales no tienen el éxito arrollador de Ubuntu. Envidia, como decía, de gente que ignora que el éxito de Ubuntu es su éxito y les beneficia. Afortunadamente no son todos, claro, pero son los suficientes como para llamar la atención: Ha habido proyectos de software libre que se han venido abajo por el deterioro del ambiente (xfree86, free/dragonflybsd).

Pero lo que más me atrae de Ubuntu es su forma de organizar los esfuerzos, su política interna. Como ejemplo que alguien puso en un blog, upstart (el reemplazo de init de Ubuntu) es algo que hubiera sido imposible de desarrollar en Debian, porque introducir upstart hubiera requerido la modificación de muchos paquetes, algo que en Debian significan una negociación (y por tanto posible rechazo) con cada uno de los mantenedores de los paquetes afectados, y pedir a los empaquetadores cuyos paquetes tengan scripts de inicio, que escriban scripts para upstart. Y por supuesto, haciendo de upstart un paquete estrictamente opcional, no un reemplazo de init, fiel a esa equidistancia moral de no inclinar la balanza y dejar que sea siempre el usuario el que la incline. En Ubuntu es distinto: Se fijan unos objetivos y se va a por ellos, y se mueve cielo y tierra para lograrlos. Y se le echa cojones, tambien, como con upstart, una pieza crítica del sistema que va y se reescribe porque lo que hay ahora es una mierda, y los egos personales de los desarrolladores se ven obligados a echarse a un lado y a tragar con lo que sea. En Debian, la ausencia de objetivos concretos, el sonrojante ridículo de las pocas que se toman - eliminar documentación GFDL y firmware: piezas claves para el sistema operativo del siglo XXI - y la más que excesiva burocracia alrededor de todos los procesos hacen que el proyecto se mueva por inercia, dejándose arrastrar, mas que por una iniciativa fuerte que guíe y marce el camino no ya del propio proyecto, sino del resto de distribuciones linuxeras.

Y la razón está en la política, en el proceso de hacer las cosas día a día. Una de las cosas que me gusta de Ubuntu es la excelente calidad técnica de las soluciones: upstart, el instalador basado en un livecd que copia sus propios archivos a la partición destino, gráficos durante el arranque implementados totalmente en espacio de usuario, un applet como Dios manda para ayudar al usuario de pie con la instalación de actualizaciones, el uso de python como lenguaje de primera categoría. Y al ver lo que hacen me pregunto: ¿De dónde ha salido esta gente tan experta, con tan buen gusto para hacer las cosas, con tanta capacidad para innovar? La respuesta es: de Debian. No es un secreto que muchos de los desarrolladores clave de Ubuntu salieron de Debian, o de comunidades afines. ¿Y por qué, continuando la pregunta, esos expertos no hacían en Debian las cosas tan maravillosas que hacen ahora en Ubuntu? Respuesta: La estructura política de Debian devoraba el talento de esos expertos. La burocracia del proceso se les comía. El simple hecho de instalar por defecto un applet que avise al usuario de nuevas actualizaciones quedaría paralizado con tan solo pararse a decidir si debe hacerse para gnome, kde, wmaker, xfce o fluxbox. Se ha intentado hacer cosas así y mejorar Debian, pero los esfuerzos se han visto siempre frenados en seco por el sistema. Debian se convierte así en una especie de gigantesco almacen de empaquetado que tiene muchísimo software, pero no hace nada de esfuerzo por integrar ese software entre si. Y hay tareas de integracion que solo pueden hacer las distribuciones.

Y esa es la razón principal por la que me paso. En Debian no hago nada, no soy desarrollador, pero tampoco encuentro una motivación para serlo, cualquier intento de mejora sustancial al sistema se vería frenado por las políticas. En Ubuntu puedo ponerme a utilizar upstart, migrar scripts para que los usen otros programas, reportar o arreglar bugs, o en cualquier otra parte, cosas realmente útiles: ¿Cuando adoptará Debian oficialmente (si es que les parece bien la idea) upstart?. Ubuntu hace, arregla innova, marca el paso, da que hablar cada seis meses, mientras que en muchos aspectos Debian parece más una distribución de segunda o tercera.

Inmenso Google

Ejemplo: Noticias de la guerra civil desde 1936 a 1939, noticias de la Batalla de Brunete, de la proclamación de Franco del fin de la guerra, noticias sobre como Hitler va ganando poder, noticias de su muerte...

Pero eso es demasiado fácil. Aun hay más: Canovas del Castillo gobernando a finales del siglo XIX, menciones de Isabel II, y cosas así. El contenido irá aumentado según pase el tiempo, supongo. Inmenso GOOGLE. Con la ayuda de los diarios que han digitalizado sus contenidos. Pero con una interfaz de búsqueda a lo google que es una delicia.

Act.: Se me ha olvidado comentar que he puesto enlaces a páginas de noticias, pero no al buscador de google en si. Por cierto, en la noticia sobre la batalla de Brunete es interesante notar como los periódicos estadounidenses estaban limpios de la influencia de la propaganda nazi y llaman al bando nacional "insurgentes", pues la denominación de "nacionales" fue una estrategia del ministro de propaganda nazi Goebbels, con la intención de que el bando al que ellos apoyaban pareciera "bueno"

El día en que murió sysvinit ...

...día para enmarcar, como bien dice un comentarista en este blog.

Cambiando de noticia, un buen articulito sobre las medusas de tito Arturo.

getgnulinux.org

Aun a riesgo de escribir demasiados mensajes en un día y hacer que la gente tenga fobia a mi blog, diré que he encontrado este sitio que acaba de ser creado recientemente, y que me parece una maravilla. Es un sitio de marketing al estilo de los que hay para firefox: Sencillo, directo. ¿Por qué no se había hecho esto antes?

Un ejemplo cualquiera

Aquí (ironicamente, un sitio de novell) te explican como configurar Ubuntu dapper (la última versión) para autenticarse contra un servidor Windows con Directorio Activo (gracias a Dios, no se les ocurrió llamarlo Carpeta Activa)

Un cacao. Un revuelto de scripts y modificaciones de archivos de texto a mano que incluso a mi, que soy linuxero viejo como diría Sancho Panza, me asusta a primera vista. ¿Quien dijo que los asistentes gráficos son malos?

Alatriste

Hoy voy a intentar hacer la competencia al Esquiva esto de Ramón Rey con una especie de critica de cine. Digo especie de, porque los críticos artísticos me parecen (sea música o cine o literatura) seres abyectos que deberian estar prohibidos por ley, por razones que no vienen a cuento. Asi que esto oficialmente no es una crítica: Son comentarios personales sobre un tema determinado.

No tengo mucha idea de cine (el único campo en el que me atrevo a meterme es en el de la música, 13 años de guitarreo dan para mucho). Con eso quiero decir que jamás en mi vida he sido capaz de notar cosas como si un actor actua excepcionalmente bien o rematadamente mal o si lo hace mucho mejor en una película que en otra. En ese aspecto no se como será Alatriste, ni me importa. Puedo decir que la iluminación y esas cosas, muy inspiradas según han contado en las técnicas que utilizaba Velázquez al pintar, es sencillamente genial. Ese tipo de cosas, los decorados y demás, están boradadas, y consiguen una representación viva del decadente Imperio Español del siglo XVII. La verdad es que da gusto ver que alguien en este pais haga una película asi, sobre su pasado, sin complejos, porque en la españa democratica post-franquista el subconsciente de la gente sigue confundiendo la historia con la caspa ultranacionalista del régimen de Franco, que no tiene nada que ver.

Como digo, en ese aspecto la película esta bien. Lo que no esta bien, es la estructura de la película. No es que este bien, es que está (francamente, en mi opinión) bastante mal. Durante toda la película el telespectador tendrá que enfrentarse con el hecho de que la gran mayoría de las escenas no tienen ninguna interconexión clara entre si, que lleva al espectador a hacerse continuas hipótesis de: ¿Lo que está haciendo ahora es consecuencia de la escena anterior, o de la anterior de la anterior? ¿estara en madrid ahora? ¿o estará en otro lado? Y la película es larga, que es un dato que sin ser de por si malo, se convierte en una pequeña tortura añadida al hecho de que es casi imposible seguir la historia. A mi me ha costado un montón seguirla, y yo soy el típico personaje capaz de estar buscando interconexiones Numoreanas entre el Silmarillion y El Señor de los Anillos, asique no quiero imaginarme como será la cosa para la gente normal ("anormal", me corrige mi sexto sentido friki). En Internet he leido comentarios de gente que simplemente se ha salido de la sala. Y he de decir que lo entiendo.

Un ejemplo claro es la cautividad de Iñigo. De repente, Alatriste vuelve a casa y se encuentra con que la guardia se está llevando a Iñigo por espia, y que le llevan a las galeras. En la siguiente escena, Alatriste visita a Angélica (una chica relacionada con la corteque estuvo enamorada platónicamente de Iñigo) y le pide que le de una carta al Conde-Duque de Olivares, porque a él no le dejan visitar al Conde-Duque. Le dice que es sobre Iñigo y que lleva un año en galeras. O sea, que Alatriste de repente ha esperado...¿un año? a darse cuenta que no le dejan entrar en un palacio y acudir a Angélica. Pues vaya. Quizás (seguramente) sea así en el libro, y por eso dice que ha pasado un año. Pero a la hora de adaptarlo ¿por qué no hacerlo más continuo? Y no se por qué no le dejan visitar al Conde-Duque, porque en las escenas anteriores si que le dejaban (la película es tan difusa que quizás hay una razón de la que no logré darme cuenta). Y en la escena siguiente, aparece Alatriste con el Conde-Duque de Olivares, que le cuenta con demasiada confianza como Dios ha abandonado a España y que todo se va a la mierda. Con esa confianza, cuesta creer que no le dejaran entrar durante un año. Y uno llega a la conclusión de que si ha logrado entrar es porque Angélica ha dado la carta al Conde-Duque y que están reunidos para hablar de Iñigo, pero Alatriste le pregunta al Conde-Duque que si ha leido la carta. O sea, que no había ido a hablar en concreto de esa carta, porque sino no hubiera sido necesario preguntar por ella, digo yo.

Pero hay más. De hecho, toda la película está, como digo, llena de escenas mal conectadas entre si que no ofrecen sensación de "continuidad", de que te cuenten una historia. En los libros seguramente esté justificado como Dios manda - la película de Alatriste intenta resumir nada menos que cinco libros - pero en la película hay muchas cosas que no tienen sentido. Es en esos puntos donde un guionista no solo puede, sino que debe traicionar al libro y ofrecer una película coherente. Uno de los más sonados es ese en el que Alatriste pierde una lucha contra un espadachin - Alatriste es un heroe real que a veces fracasa estrepitosamente, a diferencia de las pantominas falsas de superheroes y policias con las que sueñan los americanos - y en la que queda en el suelo, malherido, tumbado y lleno de sangre. La escena es la típica que da la impresión de que el que está en el suelo se va a morir en nada. Pues bien, la escena desaparece y aparece otra en la que Iñigo va a casa del que había matado a Alatriste en la escena anterior. Es decir, tu piensas que Alatriste se ha muerto, porque no hay razón para no pensarlo: En la escena anterior su contrincante le había rematado con la espada despues de dejarlo caido en el suelo, con una estocada que piensas que fácilmente habrá atravesado al pulmón, y ahora lógicamente Iñigo va a vengarse. Como Alatriste está muerto, ahora la historia continuará con Iñigo, te dices a ti mismo. Un cambio radical en la trama, veamos que nos depara la película a partir de ahora, si la historia es buena bien puede resultar que esto acabe bien. E Iñigo mata al malo y venga a Alatriste en una bonita lucha. Y termina, y se cambia a una nueva escena en la que te cuentan otras cosas.

Y de repente, quizás despues de 2 ó 5 minutos y otras dos escenas o qué se yo, se abre una nueva escena en la que aparecen Iñigo y Alatriste sentados en su casa. Pues entonces Alatriste no esta muerto, concluyes. Solo estaba herido gravemente y se recuperó. Pero nadie te lo dice hasta despues de 5 ó 10 minutos, despues de ver la venganza y otras escenas que no estaban relacionadas. Sin ser experto de cine, me parece una soberana chapuza, que se hubiera mejorado con soluciones simples como hacer que Maria de Castro, que está al lado de Alatriste despues de herirle, termine la escena diciendo "tranquilo, ahora te llevaré a un hospital". O hacer que Alatriste diga a María "no es demasiado grave, igual no me muero" (aunque esta opción queda descartada por no encajar con el carácter de Alatriste). O hacer que Iñigo, al ir a vengarse, diga "Vas a pagar por haber mandado a Alatriste al hospital".

O algo así. Se me ocurren mil soluciones. A mi, y a cualquiera, lo que sea menos mezclar escenas al tun tun sin interconexión alguna entre si. Y no son excepciones: Son la regla. Quizás parezca yo exagerado con el ejemplo anterior, pero podría contar unos cuantos y puedo asegurar que tras una hora de película la cosa se hace cansada, y despues de ver la película no serás capaz de contar la trama a nadie porque eres incapaz de concretar qué ha pasado. Me ha parecido un guión y una producción más que deplorable, una pena en una película en la que todo lo demás parece excelente. Lástima.