Re:Extending the Unix doctrin. (Score 1)

It's metadata for *files*. What you seem to want is metadata for applications, but you want to stick the code that manipulates application metadata inside the filesystem driver. Insanity! How is the kernel meant to best judge the needs of an application? No matter what tradeoffs the kernel makes for metadata - size, speed, number, whatever - it's going to be OK for some applications but downright useless for others.

This is not insanity. Every modern filesystem does allow an application to store metadata. Whether BeFS, XFS, ReiserFS etc. Metadata are data. A file system is there to store data. Metadata have a particular flavor: they must be associated with data.

The kernel does not judge the needs of an application, the kernel doesn't mind which metadata are stored, if they are stored etc... (unless some metadata are mandatory: permissions...) The kernel only allows data to be stored, and doesn't leave the applications with kludgy schemes to store their metadata.

I concede that in the case of HTTP and HTML, metadata (language, file type, robots) are stored within the file (META tag) or in the file name (content type, or storing metadata, the file type, inside metadata, the file name).

But you have some metadata you wouldn't be able to store with the file: versionning information. Unless you resort to a kludge, which is the Unix modern philosophy.

No matter what tradeoffs the kernel makes for metadata - size, speed, number, whatever - it's going to be OK for some applications but downright useless for others.

Those applications for which metadata are OK will use metadata. The others won't. Simple.

Metadata really falls flat when you have many users on a system. Imagine when one user wants to assign the tag "red" to the attribute "iconcolor" and another user wants to use "blue". Great. Now we need 1 instance of metadata per file per user on the system. Look at the filesystem bloat grow!

This is ridiculous. You have system defaults, user defaults. If the user is not happy with the user default for a particular file, she only needs to store metadata on that file. The other files stay unchanged.

Because google is 1000s machines with all of the database content in RAM, and you have a pissy little PC scanning over a low-end hard disk?

I learned my computer science: to achieve speed, you need a better algorithm. If you have a bad algorithm, whatever the machine power, you will have a lame performance. The algorithm for grep or find is simple, yes, but slow. Whatever the hardware.

Even if I use a top gun SCSI disk or a top gun disk appliance, the performance is abysmal. It's not a question of hardware ressources. The end user today has access to some great hardware. The software side is lagging.