> Linux is not UNIX(R) at all. Linux is a hot new operating system
> designed for the next century^H^H^H^H^H^H^H38 years. UNIX(R) is dead.
UNIX(R) is dead, long live UNIX! ;-)
Seriously, Linux definitely *is* one of Unices. And this family will live
long after the current crop Frankenstein creatures will be dead.
Linux, BSD, Plan 9, Inferno, etc. are here to stay. MacOS kernel will be
dead in a couple of years. NT will follow. Monsters do not procreate -
they only infect each other. Having sex with them is *not* a healthy idea.
One of the nastiest STDs in that area is called featuritis...
> > Good luck doing that. If you are going to invent a new uniform
> > scheme - fine, go ahead, implement it as filesystem and I will write a
> > loopback-mount-on-the-fly. Oh, and don't forget to make them switch to new
> > format. Deal?
>
> That is one way to implement the API, but it won't let the document
> share allocation and namespace support with the filesystem.
> You still end up going through two filesystem(-like) layers.
Sheesh... Once more. Slowly. Those crapplications already support
monolitic formats. Mutually incompatible. They are not, I repeat, *not*
going to switch to any new scheme. No matter what this scheme will be. For
them it means massive rewrite. And they will have to support other
platforms (2.0/2.2 if we are talking about Linux) anyway, so it's *adding*
new code. Making the kernel understand their current formats means that
*we* will have to do the same job instead of them. For every vendor. For
every crappy format. So either you can con/blackmail/persuade those
vendors to switch to unified format or you are calling for massive pain in
the ass.
Two filesystem-like layers are not that terrible, BTW. Especially
with the new page cache - provided that format in question will not be too
horrible you'll get almost no difference in performance.
The main problem being to make them *use* whatever API you will
provide. Good luck doing that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/