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.
Tell us more about the "bleeding edge filesystems"
before Unix that did have metadata and resource forks and "whizbang ideas". Can you give us the name of one of those filesystems?
Metadata can and are sent over the network. It's
called HTTP for example. Or RFC 822. You know, "Subject", "Keywords", "References" etc...
For HTTP: "Expires", "Content-Language",
"Content-MD5" etc...
A mailer will make good use of metadata
(see Evolution for example. Any search within Evolution is instantaneous because all your mails are indexed on metadata.)
I can only dream of typing a find command and having the results displayed instantaneously.
I can't understand why I must wait only one second when doing a search on Google on the whole Internet, and I should wait minutes on my machine. I can't understand. This is probably because of people like you, people who "learn from history".
Unix uses metadata. Last modification time. Owner.
It's a poor man's metadata. It's not indexed.
I want metadata. I want indexes. I want *power*.
Can you imagine such a command:
find / --schema ID3 --artist foo -year -10
That would be power. In fact, that would be Unix, if Unix means power.
Metadata are the soul of our data.
Do you use a package manager for example? Metadata are what makes RPM or APT possible. Your files are not a bunch of stupid bytes: somewhere there is a database, full of metadata. The RPM or APT database.
Also, metadata are data, a bunch of bytes, so it's easy to dump them to tape. Do you think Apple users never made a backup?
Let's break from the current conservatism. Let's
depart from the "I know grep and sed now, so don't change anything" stance. Let's choose power, as Unix did a long time ago.
Slashdot Mirror
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.
Those applications for which metadata are OK will use metadata. The others won't. Simple.
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.
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.
Tell us more about the "bleeding edge filesystems" before Unix that did have metadata and resource forks and "whizbang ideas". Can you give us the name of one of those filesystems? Metadata can and are sent over the network. It's called HTTP for example. Or RFC 822. You know, "Subject", "Keywords", "References" etc... For HTTP: "Expires", "Content-Language", "Content-MD5" etc... A mailer will make good use of metadata (see Evolution for example. Any search within Evolution is instantaneous because all your mails are indexed on metadata.) I can only dream of typing a find command and having the results displayed instantaneously. I can't understand why I must wait only one second when doing a search on Google on the whole Internet, and I should wait minutes on my machine. I can't understand. This is probably because of people like you, people who "learn from history". Unix uses metadata. Last modification time. Owner. It's a poor man's metadata. It's not indexed. I want metadata. I want indexes. I want *power*. Can you imagine such a command: find / --schema ID3 --artist foo -year -10 That would be power. In fact, that would be Unix, if Unix means power. Metadata are the soul of our data. Do you use a package manager for example? Metadata are what makes RPM or APT possible. Your files are not a bunch of stupid bytes: somewhere there is a database, full of metadata. The RPM or APT database. Also, metadata are data, a bunch of bytes, so it's easy to dump them to tape. Do you think Apple users never made a backup? Let's break from the current conservatism. Let's depart from the "I know grep and sed now, so don't change anything" stance. Let's choose power, as Unix did a long time ago.