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.