¿Donde terminarán los sistemas de archivos...?

Existe mucho ruido últimamente con la historia de winfs, spothlight, reiser 4, sus padres, sus madres, sus cuñados y las madres que los parieron. Y uno se pregunta: ¿A donde coño va a ir a parar todo esto?

La premisa de winfs (que aunque la gente se centra en la historia de las busquedas, es algo bastante más complejo que lo que pretende spothlight) es que "el usuario no debería preocuparse de donde están los archivos". Que todo debería ser una "busqueda, incluyendo la configuración de los archivos, etc. Aunque se anuncie como nuevo, resulta que el AS 400, un sistema operativo de IBM que no tiene "sistema de archivos", sino una base de datos enorme donde todo son peticiones. O eso dicen, porque yo no he visto uno en mi vida y la documentación al respecto no parece salir debajo de las piedras. El caso es que la idea no es nueva (para variar), y aparentemente pretenden reemplazar a los sistemas de archivos tradicionales

Ahora bien, sabemos porque unix tuvo en su diseño un sistema de archivos basado en archivos/directorios: Lo escogió porque era "simple y estúpido". Realmente, no hay nada más simple que un sistema de archivos basado en archivos y directorios, especialmente si lo comparas con la complejidad de una base de datos. Ahora bien, ¿tendrán éxito las alternativas basededatos-escas que están apareciendo hoy en día? Tal vez en los 70 los sistemas de archivos basados en bases de datos no tuvieran sentido, pero con la cantidad de miles de archivos que manejamos hoy, quien sabe. ¿Triunfarán las alternativas de bases de datos? ¿O prevalecerá la simplicidad de los sistemas de archivos tradicionales? ¿Sustituiran las bases de datos a los sistemas de archivos tradicionales como AS400, o simplemente se creará software database-esco que funcione por encima de sistemas de archivos tradicionales, como spothlight y parcialmente winfs? He de reconocer que me gustaría ser como Rappel y saber que ocurrirá en el futuro, pero....

A Rob Pike en su entrevista a slashdot le preguntaron exactamente eso, que qué opinaba de la moda de hacer a los sistemas de archivos UNIX más basededatos-escos, y la respuesta fue:

This is not the first time databases and file systems have collided, merged, argued, and split up, and it won't be the last. The specifics of whether you have a file system or a database is a rather dull semantic dispute, a contest to see who's got the best technology, rigged in a way that neither side wins. Well, as with most technologies, the solution depends on the problem; there is no single right answer.

What's really interesting is how you think about accessing your data. File systems and databases provide different ways of organizing data to help find structure and meaning in what you've stored, but they're not the only approaches possible. Moreover, the structure they provide is really for one purpose: to simplify accessing it. Once you realize it's the access, not the structure, that matters, the whole debate changes character.

One of the big insights in the last few years, through work by the internet search engines but also tools like Udi Manber's glimpse, is that data with no meaningful structure can still be very powerful if the tools to help you search the data are good. In fact, structure can be bad if the structure you have doesn't fit the problem you're trying to solve today, regardless of how well it fit the problem you were solving yesterday. So I don't much care any more how my data is stored; what matters is how to retrieve the relevant pieces when I need them.

Grep was the definitive Unix tool early on; now we have tools that could be characterized as `grep my machine' and `grep the Internet'. GMail, Google's mail product, takes that idea and applies it to mail: don't bother organizing your mail messages; just put them away for searching later. It's quite liberating if you can let go your old file-and-folder-oriented mentality. Expect more liberation as searching replaces structure as the way to handle data.

debugging

Los posts en el planet de gnome sobre "como depurar sin símbolos" me han recordado a un magnífico post de Raymond Chen en el que explica una manera muy curiosa de identificar pérdidas de memoria

Ahora bien, leyendo el post de gnome me pregunto: ¿Es realmente necesario que las distros quiten la información de depuración de los binarios? Teniendo en cuenta que son los usuarios finales los que se encuentran con los fallos, y que son ellos los únicos que los pueden reportar, incluir la información de depuración de todos los binarios por defect no suena tan mal. El espacio de disco es barato. El de los CDs por supuesto no, y supongo que esa es la razón por la que muchas distros nunca harán algo así

Otra cosa curiosa es lo del bug-buddy: La cosa de gnome que cuando casca un programa te abre una ventana preguntandote si quieres enviar la información del fallo a los desarrolladores. Le hace a uno pensar si sería posible crear un bug-buddy que afectara a todos los programas de sistema (a todos los posibles) y que fuera configurable, para que las distros pudieran recibir automáticamente los fallos de todas las aplicaciones a través del sistema de seguimiento de bugs.

Por otra parte, cairo ha anunciado su versión 1.0.

El fracaso de las aplicaciones web

Con todo el ruido de las aplicaciones web, AJAX, javascript & friends y todo eso, parece ser que nadie se atreve a decirlo, pero es evidente: Las aplicaciones web han fallado

¿Por qué? No hay mas que ver Google Talk: Es un programa normal y corriente: Al igual que google maps en la versión del programa, al igual que google/msn desktop, al igual que....

A día de hoy, tenemos cosas como gmail hechas a base de poner a los programadores a tirar de AJAX, pero para llegar a tener cosas como esas, se ha explotado al 100% las capacidades de javascript, xhtml, css & friends.

En resumen, las tecnologías de los navegadores de hoy permiten hacer "aplicaciones web", pero a base de explotar una tecnología que es una basura. Tanto javascript como CSS no son más que parches puestos a (X)HTML. Las web forms de firefox o el equivalente monopolista de Microsoft cambiarán las cosas, pero a día de hoy la verdad es que para aplicaciones web reales y competitivas, como uno no tire de java...

"Dep 1127 disbanded"

El "departamento 1127" era el departamento de los laboratorios Bell que se dedicó a crear y mantener Unix

Y ahora se ha ido para siempre. Tampoco es que sea muy relevante, despues de todo como dijo Rob Pike en el 91, "not only Unix is dead, it's starting to smell really bad"

Como curiosidad, 3 de los miembros están ahora en google. ¿Casualidad?

certificación de drivers en Windows - el HORROR

En la última entrega de "The Old New Thing" (blog de uno de los mejores ingenieros de Microsoft, etc etc), explica uno de los métodos más curiosos que utilizan las empresas para saltarse el diálogo de "Está a punto de instalar un driver no certificado por los laboratorios de Microsoft etc etc":

El método que cuenta esta vez (hay más) es escalofriante: El programa de instalación pide al usuario que "no mueva el ratón ni toque el teclado". Entonces, el propio programa de instalación procede a mover el puntero del ratón manualmente, para actualizar el driver y aceptar el diálogo como si fuera el usuario el que lo está haciendo

Terrorifico.

Y relacionado con el tema, y sacado de la keynote del todopoderoso John Carmak: "The quintessential PC game programmer then dropped a bit of a bombshell by announcing that he had recently moved his primary development efforts over to the Xbox 360, and that he expected to continue development there for the next six months—although the PC version of id Software's next game will still be released first. One of his reasons for the move to Xbox 360 for development, Carmack said, was the headache of driver issues on the PC platform. The several layers of abstraction on the PC make it hard to nail down exact graphics performance because the programmer is held at a distance from the hardware. By contrast, the Xbox 360's more direct approach was "refreshing." Carmack also praised Microsoft's development environment as easily the best of any of the consoles, thanks to the company's background as a software provider"

Y ya que estamos: "Carmack was less pleased with the PowerPC processors for the new consoles, questioning the choice of an in-order CPU architecture. He estimated the console CPUs' performance at about 50% that of a modern x86 processor and expressed skepticism about the returns of multi-core designs and multithreaded software, especially in the short term. Graphics accelerators are a great example of parallelism working well, he noted, but game code is not similarly parallelizable.

"La razón real por la que IE7 no soportará CSS2"

En http://dean.edwards.name/weblog/2005/03/the-reason han escrito un par de lineas decentes en las queda una razón bastante lógica para que IE7 no vaya a soportar CSS 2 (y ni hablar de CSS 3): Por que no pueden

Las razones que da son bastante coherentes: Internet Explorer es un navegador que no ha sido modificado en 3 años (excepto cambios en el SP2 de XP, en materia de seguridad especialmente en el tema de zonas, en cualquier caso nada relacinado con CSS & friends), y el motor de renderizado está completamente obsoleto como para implementar cosas "avanzadas" con facilidad.

Lo cierto es que en los blogs de los desarrolladores de mozilla hablan sobre como la futura migración a cairo les permitirá implementar tal o cual característica de forma mas sencilla. O en otras palabras: Uno no va e implementa CSS como si tal cosa, el diseño del navegador te lo pone más o menos dificil.

Asi que lo mas probable es que el tipo ese tenga razon y que el motor de renderizado de IE7 sea a día de hoy "viejo", y que implementar CSS 2 & 3 no sea cuestión de gustos, sino de complejidad y falta de tiempo: Firefox está ahí, y necesitan sacar algo que compita con ellos. Tal vez si se les diera tiempo podrían implementar más cosas, pero es obvio que no van a retrasar la salida del IE7 por esas razones. Tambien dice que IE es el nuevo netscape 4.7, y que para IE tiene mas sentido una reescritura que continuar parcheando

"algoritmos de reemplazo"

Rik van Riel, el tipo que hizo el famoso "-rmap", está atacando de nuevo

OO y el futuro de la programación

Acabo de encontrar en mis bookmarks un enlace que consideraba perdido, pero que afortunadamente no lo esta: Una entrevista con Victoria Livschitz, una tipa que trabaja para sun y que es campeona de ajedrez de su pais. La entrevista va sobre la programación, sobre nuestra incapacidad para crear grandes programas que no esten plagados de fallos, de como la orientación al objeto ayudó a mejorar las cosas, de como no ha ayudado a arreglar todos los problemas, y todo eso:

[...] However, we seem to have reached the point where OO is no longer effective. No one can comfortably negotiate a system with thousands of classes. So, unfortunately, object-oriented programming has a fundamental flaw, ironically related to its main strength.

In object-oriented systems, "object" is the one and only basic abstraction. The universe always gets reduced to a set of pre-defined object classes, some of which are structural supersets of others. The simplicity of this model is both its blessing and its curse. Einstein once noted that an explanation should be as simple as possible, but no simpler. This is a remarkably subtle point that is often overlooked. Explaining the world through a collection of objects is just too simple! The world is richer than what can be expressed with object-oriented syntax.

vista tendrá enlaces simbólicos

Parece que Microsoft sigue con su plan de alcanzar el nivel de la tecnología de los 70. Lo cual por cierto no es malo, y nos hace ponernos a su misma altura si no avanzamos y nos quedamos atrancados en la misma historia. Curiosamente, Plan 9 no tiene enlaces simbólicos (a propósito, como consecuencia de sus rollitos-de-espacios-de-nombres)