Citas

Esta vez de Pavel Machek.

"No-o. Kernel is not designed like that.

Often, more complex and slightly faster code exists, and we simply use slower variant, because it is fast enough.

10% gain in speed is NOT worth major complexity increase."

Se admiten apuestas

¿Cuanto tiempo tardara Google u otros buscadores generalistas en sacar un buscador especializado en ser capaz de buscar dentro de podcasts y videos de youtube, utilizando software de síntesis de voz para hacer una transcripción del video/podcast? (Act.: Como este cuya URL me ha pasado Ramón Rey, pero para el gran público) Yo apostaría a que lo sacarán durante el 2007, junto con más propuestas relacionadas con el tema, sobre todo google, a raiz de su infiltración en el mundo de la publicidad en la radio

Sobre las unidades de memoria flash y la memoria RAM

Despues de haber conseguido echar a tres de las cuatro personas que leian este blog con mi Revertavalancha, y una pausa no eneramente deliberada de varios días, continuo mi tradicional vómito de mis mal llamadas ideas.

Ya escribí en su día explicando brevemente porque creo que los dispositivos de almacenamiento de datos van a dejar de estar basados en los dispositivos mecánicos actuales de una puñetera vez - lleva décadas prediciendose - y van a basarse en memorias "flash" a medio plazo; basándo el razonamiento en la lentitud y la decreciente fiabilidad de los discos mecánicos y la ausencia de tipos de datos que nos fuerzen a necesitar con urgencia mayores tamaños de almacenamiento. Las noticias de avances de ese sector no han hecho más que confirmar mis teorías, que por otra parte no son precisamente el secreto de la eterna juventud. Habrán oido ustedes noticias de que han creado técnicas para aumentar la capacidad de los discos duros y dirán que no tengo razón en mi predicción, pero apuesto a que ninguna empresa ha inventado un sistema mágico para mejorar y poder seguír mejorando sensiblemente en el futuro la latencia de acceso aleatorio a ese supersistema de almacenamiento.

El caso es que hoy quería hacer una reflexión de una tontería que en realidad no va a pasar: La unificación de la memoria ram con los dispositivos de almacenamiento.

En los sistemas modernos, la RAM y los discos duros son entes separados, y el procesador solo puede referenciar directamente datos. Eso básicamente quiere decir que cuando el procesador hace un jmp 0x12345678, ese 0x12345678 debe estar en memoria RAM. Para que se pueda ejecutar un programa hay que copiarlo del disco duro a la RAM y, ahí ya si, ejecutarlo. ¿Por qué esto es así? Principalmente por la jerarquía de los caches, es decir, la lentitud del discos duro respecto a la RAM, L1/L2 y registros. Mover el brazo de un disco duro hace que el procesador desaproveche algunas decenas de millones de ciclos, que aunque a nivel global pueda corregirse mediante la multitarea - ejecutar otro proceso mientras se espera -, a efectos reales del usuario que espera que se arranque su programa, es el mismo: Lentitud. Crear una memoria RAM de varios gigas es factible, pero muy caro, asi que se recurre al disco duro. Cuando hay que ejecutar, leer, mapear algún dato del disco duro, se mueve a RAM y se ejecuta, se gestiona el cache, se escriben los cambios a disco. Pero como ya he dicho, el mundo de los discos duros va a acabar. Esto provocará la aparición de discos duros basados en memoria flash. ¿Por qué no ir más allá y hacer lo más "lógico": Establecer ese disco duro flash como memoria RAM?

Es bastante improbable que esto suceda. En primer lugar porque siempre será más barato construir los discos duros flash de memoria con peor velocidad de acceso que la memoria RAM, siempre; más aun teniendo en cuenta que la RAM no está obligada a conservar el estado entre reinicios. Pero si ocurriera, ¿a que retos se enfrentarían los sistemas operativos?

Los sistemas operativos están construidos bajo el concepto de que nada más arrancar, la RAM esta vacia. Esto, que puede parecer una tontería, es la madre del cordero, porque con un disco duro-RAM con persistencia de datos sería continua. A día de hoy el sistema operativo arranca, la BIOS se mapea - creo - en una parte de la RAM y el procesador comienza a ejecutar el código. Se carga el núcleo del kernel y voilá, lo primero que se hace es mirar cuanta RAM hay, construir las estructuras de datos para gestionarla (tablas de páginas y demás), y siempre se asume que esa memoria está vacia.

Con una memoria RAM basada en memoria flash persistente todo sería muy diferente. Nada más arrancar el kernel, tendría que detectar que zonas de la RAM están siendo utilizadas para datos - lo estamos utilizando como disco duro, al fin y al cabo - y que zonas hay libres. La "gestión de memoria" pasaría a ser al mismo tiempo el sistema de archivos. Habría que volver a pensar algunos conceptos básicos: La frontera entre los datos y la memoria sería inexistente. Hacer un malloc() sería idéntico a hacer un open() + write(). De hecho, teóricamente habria que unificarlo todo, eliminar malloc(). Eliminar toda la gestión de memoria anónima y sustituirlo, supongo, por las APIs de gestión de archivos. En el caso de que queramos seguir utilizando sistemas de archivos jerárquicos para la ocasión. Ńo haría falta suspender el sistema, ni apagarlo: Tan solo salvar el IP, los registros y demás en una zona fija de la memoria que el cargador pudiera encontrar al arrancar. ¿Y que me dicen de las particiones de sistemas operativos? Puesto que la frontera entre datos y memoria sería nula, no tendría sentido partir un disco flash de 40 GB en dos particiones de 20 GB: Al arrancar un sistema de 20 GB perderías los GB de memoria aun no utilizada por la otra particion (recordar que no existiría el swap ni nada parecido). Tendrían que utilizar ambos el mismo sistema de archivos, es decir, el mismo gestor de memoria. ¿Y que me dicen del procesador? En una arquitectura como las viejas de 32 bits no se podría utilizar un disco duro flash de 100 GB, porque el procesador solo podría acceder a los primeros 2^32 (4 GB), y a los procesadroes de 64 bits algún día les pasará algo parecido.

En fin, como ya he dicho es muy probable que esto no pase jamás porque es más conveniente seguir teniendo "discos duros" por separado, sean flash, mecánicos, o lo que sean. Pero es interesante comprobar como es posible dar la vuelta al mundo cambiando un par de conceptos.

Usabilidad del IE 7

Conversación con mi querida amiga Silvya:

una cosa
donde cojones esta en el nuevo IE
las opciones???
lo de archivo y demas


Despues de recordar como se hace reaparecer el menú y contárselo:

pero macho
estos son gilipollas o ke


Dice odiar que encontrar el menú tradicional cueste tanto. Y eso que es de las que si se ponen adivinan las cosas sin que nadie se lo diga: ¿Que pasará con los millones de personas que solo saben mover un ratón? Cambiar de manera tan radical la interfaz a la que los usuarios están acostumbrados no tiene ningun sentido en el programa más utilizado por el usuario medio de ordenador. Si se tratara de algo mas leve o algo explusivo de Windows Vista vale, sería comprensible, pero este cambio ha sucedido de la noche a la mañana en un sistema operativo en producción. Además rompe las reglas históricas de diseño de interfaces de Microsoft, todas las aplicaciones tienen su menu. Ni tan siquiera hay una opción para cambiar a la antigua interfaz. Esto es confundir a la gente, una confusión que con 40.000 millones de dólares de ingresos anuales no se debería producir.

Adios, falsa multitarea

Como quizás muchas de vuesas mercedes sepan, Intel ha mostrado al público un procesador con 80 'cores'. A pesar de que yo mismo he escrito en este blog que los fabricantes de CPUs van a ganar rendimiento a partir de ahora más que nada añadiendo 'cores' en vez de Ghz cmo hasta ahora, siempre he tenido y tengo muchas dudas sobre esa aproximación a la hora de conseguir rendimiento. La multiprogramación con multiples hilos de proceso compartiendo recursos cuya integridad se garantiza mediante diferentes sistemas de bloqueo es tan dificil que a día de hoy la mejor aproximación a la hora de crear un programa que utilize ese estilo de programación es que comparta lo menos posible y utilize los menos bloqueos posibles como principio fundamental de diseño, para que la complejidad del código sea manejable.

Eso me hace ser terriblemente escéptico con respecto a los procesadores multicore. Intel dice - en realidad no solo Intel, el mundo de las CPUs que acaba de despertarse con el multicore - que para aprovechar todos esos núcleos hará falta que los programadores se espabilen. Que se inventen maneras de sacar provecho a 80 núcleos. Ellos van a colaborar, dicen, mandando a sus ingenieros a evangelizar por el mundo y lanzando librerias y utilidades, y tal y tal. Y todo eso suena muy bonito, pero la última vez que Intel intentó hacer cambiar a alguien de "paradigma" fue a los programadores de compiladores, con su Itanium. Y ya ven como les fue y les va la cosa. En fin, ellos sabrán.

Lo que venía a contar aquí es una de las cosas que ocurrirán si de verdad acabamos utilizando un chisme de 80 cores. Hasta ahora, los ordenadores tenían que recurrir a la multitarea: se activa una interrupcion cada 1/1000 segundos que ejecuta el código del gestor de procesos que determina que proceso seguir ejecutando, si el mismo u otro. Añadiendo la virtualización del espacio de direcciones y demás se consigue que en un ordenador con un solo procesador se puedan ejecutar N procesos diferentes; dando así la apariencia de que el ordenador ejecuta varios procesos a la vez, cuando en realidad solo ejecuta uno.

¿Que ocurrirá cuando tengamos 80 cores, y aun más? Que ya no será necesario la multitarea tal y como la hemos conocido hasta ahora. Tendremos multitarea real: Cada proceso, hilo o lo que carajo sea se ejecutará en un procesador. Y no será necesario interrumpirlos. Lo cual implica, a largo plazo, por qué no, decir adios a los cambios de contexto y esas cosas (lo cual implica, por cierto, que los microkernels podrían ser factibles, no como hasta ahora, que han intentado hacer lo imposible en arquitecturas claramente diseñadas para kernels monolíticos). Incluso al "modo kernel/modo usuario": La diferenciación entre modo kernel y modo usuario surgió entre otras cosas para poder ejecutar varios procesos en una sola CPU, y que un proceso no metiera las narices ni monopolizara los recursos de los demás. Aunque incluso en un sistema de 80 procesadores, sería necesario un supervisor, para administrar la memoria, que sin ningún tipo de duda seguirá siendo homogénea: Un solo espacio de direcciones, muchos procesos rondando alrededor de ella.

Pero en el fondo todo lo dicho es una tontería, con un procesador de 80 cores no nos moveríamos a un modelo "proceso por procesador". ¿Como aprovecharíamos la potencia de cada core, si relegaramos cada procesador a un proceso, cuando el único modo posible de aprovechar esos 80 cores es precisamente repartir procesos o hilos por todos los cores lo más posible, como quien va sembrando semillas? Lo dicho, que francamente no tengo ni puñetera idea de como van a ser los ordenadores de dentro de cinco años y como se aprovechará su potencia. Y admiro profundamente a quienes dicen saber como se hará.

¿Qué tendrá Ubuntu Feisty?

Una de las entradas más exitosas de este blog, meneada y todo, fue Qué tendrá Ubuntu Edgy, una lista detallada de novedades recolectada a partir de las especificaciones de Ubuntu que aparece en tercer lugar en los resultados 'españolizados' de Google al buscar "ubuntu edgy", detrás tan solo de la página oficial. Buscando solamente páginas en español, el primer resultado.

Motivado únicamente por la obsesión de conseguir más y más y más y más visitas a cualquier precio -nunca por el deseo de informar, ayudar, colaborar con la comunidad; seamos sinceros-, aquí viene la edición del artículo para Feisty 7.04. Como en el anterior, la información está extraida de aquí; y ojo 1) Puede que alguna especificación de las mencionadas se 'caiga' y no sea implementada al final 2) Aquí solo hago recopilación del trabajo coordinado por Ubuntu. Hay un montón de novedades para ubuntu Feisty 7.04 que no está indicado aquí porque son las novedades incluidas en los propios paquetes de software: Gnome 2.18, kernel actualizado, openoffice actualizado, etc etc.

• 'Roaming', o 'itinerancia' entre diferentes redes. Es decir, relativo a la capacidad de conectarse a nuevas redes cuando te mueves. Ejemplo: Cuando vas en coche con el móvil y sales de la cobertura de una antena y entras en otra, tu móvil se conecta a la nueva red de manera absolutamente transparente. Pues bien, se trata del mismo principio aplicado a los ordenadores, especialmente a los portátiles con conexioens inalámbricas/físicas. El objetivo es hacer que la transición entre esas redes - autenticación DHCP, etc - se haga de la manera más sencilla posible en tu ordenador (que no lo hace de manera tan limpia como el móvil). Entre otros cambios, esto significa la incorporación de network-manager a Ubuntu


• X a prueba de bombas: Esta especificación no se sabe aun si se incluirá en Feisty o no. Al margen de eso, el objetivo de esta especificación es que, pase lo que pase, el servidor gráfico arranque. Aunque cambies de tarjeta gráfica o monitor, aunque el driver normal no funcione: Siempre deberías tener gráficos, como mínimo en vesa y a malas resoluciones. Robustez, en otras palabras.


• Aceleración gráfica: utilización de AIGLX allí donde sea posible, con el propósito de comenzar el camino hacia el escritorio gráfico moderno. Al principio estaba la especificación composite-by-default que incluía la incorporación de un gestor de ventanas tipo beryl, pero al parecer se ha postergado para la próxima versión. Aun así, aunque no traiga beryl por defecto el activar AIGXL es un paso más hacia un escritorio gráfico moderno, y será muy sencillo instalar beryl a mano sin tener que agitar la varita mágica para que todo funcione.


• Educación sobre drivers propietarios: Debido a la especificación anterior, Feisty, instalará drivers propietarios de nvidia/ati por defecto. Esta decisión ha sido muy discutida: Ubuntu lo ha hecho, según fuentes oficiales, con el propósito de hacer posible los escritorios acelerados, sin que el usuario se complique, pero no renuncia al largo plazo a los ideales del software libre. En cualquier caso, el propósito de esta especificación es avisar a los usuarios de que están utilizando software no libre para soportar su hardware, e informará a los usuarios de lo negativo de dicho software, e incluso incluirá enlaces a páginas con listas de hardware soportado por drivers libres.


• Autenticación en red en servidores con directorio activo. A día de hoy hacer que un equipo se autentifique en un servidor Windows es algo complicado, lo ual dificulta la adopción de Ubuntu en esos entornos.


• Reporte de fallos maś sencillo: Herramientas que recolecten información útil cuando el usuario reporte el bug para que sea más sencillo encontrar el fallo; y envio automático a los servidores de Ubuntu sin necesidad de otras mediaciones. Esto es imprecindible para que los desarrolladores no anden buscando a ciegas los fallos.


• Mejoras a la actualización automática entre distros: Ubuntu puede actualizar a través de red de una versión a otra nueva. Pero a veces hay problemas en esa actualización: en esta especificación se coordina el trabajo necesario para disminuir esas posibilidades de error.


• Portado de controladores: Supuestamente se trata de incluir actualizaciones de drivers de kernels nuevos en el kernel estable de Feisty. No huele nada bien por lo complicado que resultará, pero eso es lo que es.


• Instalación sencilla de códecs: Una característica única, ningún otro sistema operativo lo hace. Cuando se abra un video en un formato desconocido, el reproductor intentará detectar el formato y lanzará la herramienta de instalación para instalar los paquetes de códecs necesarios. Relacionada: gnome-app-install-codecs


• Activacion de 'universe' y 'multiverse' por defecto. Para hacer más sencilla la instalación de codecs y derivados. Y para hacer más sencilla la instalación de software que los usuarios quieren instalar de todas formas.


• Descarga automática por internet de controladores de impresoras: Alivia problemas de espacio en el CD, el soporte de nuevas impresoras se actualiza con el tiempo, y resuelve eventuales problemas de redistribución.


• Eliminación de un pequeño "destello" en el inicio. Mientras se arranca, al intenta configurar la fuente y el teclado de la consola virtual, uspash hace como un pequeño "destello", y esta especificación lo elimina


• Soporte de Bonjour, antes conocido Rendezvous. Es un sistema diseñado por Apple, incluido en Mac OS X por defecto y portado a Windows. Permite el descubrimiento y configuración automática de equipos, dispositivos y servicios dentro de redes IP sin la necesidad de introducir direcciones IP o DNS. Es una alternativa a uPNP de Microsoft. Apple lo ha mandado a la IETF para convertirlo en RFC. Más información en la Wikipedia.


• Pantalla de autenticación consistente: Hay una pantalla de autenticación para iniciar la sesión, otra para quitar el salvapantallas y otra para autenticarse como usuario cuando hay otra sesión de usuario activa y bloqueada. Esta especificación unifica esas pantallas


• Menu 'Slab': importación del menu que usa Novell en su distribución.


• Actualización de las herramientas básicas para feisty: Gcc 4.1.2, glibc 2.5 y binutils 2.17.0.50.6, con soporte de DT_GNU_HASH, gcj 4.1 o 4.2 dependiendo de la fecha de salida de 4.2, y cambio del tipo de datos "long double" en sparc y ppc de 64 bit a 128; actualización de automake 1.4 a automake 1.10.


• gnome-mount: Una nueva herramienta del proyecto Utopia. El objetivo del mismo es que gnome-vfs y compañía utilizen directamente gnome-mount, y éste se encargará de interactuar con mount, HAL y compañía, sirviendo tambien de abstracción para gestinar cosas como volúmenes encriptados.


• Soporte para Macs Intel


• Uso de libata para discos IDE: La capa libata utilizada para implementar SATA en linux ha sido extendida para soportar controladores PATA, y se han reescrito los controladores correspondientes a cada chip. Es una base mucho más firme que la de los viejos controladores IDE.


• Kdump: Soporte para volcado al disco del kernel en caso de cuelgue. Está basado en kexec: El kernel detecta un fallo, ejecuta un kernel nuevo, se inicia el sistema, detecta el cuelgue y guarda la memoria del anterior en un archivo.


• Importación de configuraciones: Herramienta para permitir importar cuentas de usuarios de otros sistemas junto con sus datos de manera sencilla.


• Campo 'Breaks:': Implementación del campo 'Break:' en la gestión de paquetes.


• Reemplazo de scripts init.d de inicio por scripts upstart. En la versión anterior de Ubuntu se había implementado upstart y una capa de compatibilidad con init.d; en esta versión se añaden scripts nativos upstart.


• Herramienta para facilitar la actualización de servidores, análoga a las existentes para escritorio.


• Mejorar el particionador del instalador, con vistas a una mejor integración y mayor usabilidad.


• Gráficos de entretenimiento en el instalador, para que la gente no se aburra esperando. No es muy útil, supongo, pero....


• Instalaciones total o parcialmente automatizadas con el nuevo instalador, que al parecer no funcionaban a pesar de estar basado en el instalador debian


• Soporte GCJ nativo. Por cada paquete java, habrá un equivalente -gcj compilado con gcj. GCJ es la versión GCC de java: compila código java a código máquina nativo.


• Python: Python 2.5 por defecto.


• Soporte de Braille, y otras mejoras para usuarios con discapacidades.


• Soporte de APT para SHA256, con la intención de ir dejando atrás MD5.

Posibles soluciones a problemas

There are only two solutions to any operating system problem which are of interest: (1) the one which is easiest to program with, and (2) the one that performs the best. Either you go for programmability or you go for performance. There is /no/ middle ground for us in the kernel! - Ingo Molnar.

Un poco editado de aquí, pero es lo que quiere decir. O la más fácil de programar - la que es más fácil de mantener, la que es menos propensa a fallos por parte de los cientos de programadores que trabajan en drivers y que no son tan buenos programadores como los líderes -, o la que da más rendimiento, que puede ser menos sencilla pero merece la pena por el rendimiento. Resume muy bien el estilo de desarrollo que se ha seguido en el kernel durante todos estos años, alejado de la complejidad y del sobrediseño.

Para completa esta entrada, aquí está esta otra cita de Linus:

"Also, quite frankly, I tend to find Uli [mantenedor de la libc] over-designs things. The whole disease of "make things general" is a CS disease that some people take to extreme.

The good thing about generic code is not that it solves some generic problem. The good thing about generics is that they mean that you can _avoid_ solving other problems AND HAVE LESS CODE. But some people seem to think that "generic" means that you have to have tons of code to handle all the possible cases, and that *completely* misses the point.