¿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.