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."
¿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
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.
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.
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á.
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.
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.
Esta es una selección personal de los artículos semanales de Arturo Pérez-Reverte que se publican en El Semanal (ahora XL Semanal). "Nadie escribe así en los periódicos en España, y me sorprende que se lo permitan" escribió un lector en una carta a la revista. A riesgo de romper el encanto de la frase, diré que no es del todo cierto que sea Arturo Pérez-Reverte el único, aunque si de los pocos que quedan, que habla con claridad de ciertas cosas en España y que se niega a rendirse a la deidad nacional del correctismo político, pero si que su manera de contarlo, a menudo apasionado o incluso cabreado -justificadamente, en mi opinión-, es único, aunque algunos se empeñen en quitarle méritos o incluso tacharle de ultraderechista o rojo, según le cuente las cuarenta a los nacionalismos nacionales o a la Iglesia. Aunque sus artículos están lejos de reducirse a esos temas -incluyen tambien recuerdos personales, bellas historias del Mar, edificantes anécdotas históricas, es precisamente este último punto el que me movió a crear esta recopilación que no tiene mucho de legal: la certeza de que en sus artículos denunció muchas veces la imbecilidad política aparentemente congénita de este pais que ha invadido todos los espacios.
La "recopilación" es extensa - 50 artículos, de los 700 y pico que ha escrito. Los he dividido en varias secciones. Repito que es una recopilación absolutamente personal y por tanto no es representativa de todo lo que él ha escrito. Si quieren una visión real compren las recopilaciones "No me cogereis vivo" (recopilación 2001-2005), que se ve mucho por ahí (andan incluso por carrefour), y si ese les gusta el anterior, "Con ánimo de ofender" (1998-2001). De esos dos libros es de donde he sacado estos artículos. Tambien pueden, si lo prefieren, leer los nuevos artículos que va publicando en esta página de capitanalaatriste.com, o en el semanal XL Semanal, fabuloso dominical incluido con multitud de periódicos todos los domingos.
