You have to understand what the primary objective of an OS is: to create a virtual environment that is simple and sane to program against....

Have you learned nothing at all from DOS and Windows?

Have you no taste?

And do you not realize that features never get dropped: they just end up increasing the binary size and icache pressure forever?

-----

I'll talk really slowly.

HFS has resource forks. They are not directories. Linux cannot handle them well.

I'm all for handling HFS resource forks. It's called "interoperability".

It's also realizing that maybe, just maybe, UNIX didn't invent every clever idea out there. Maybe, just maybe, resource forks are actually a good idea. And maybe we shouldn't just say "Oh, UNIX already has directories, we don't need no steenking resource forks."

-----

I actually think that Linux with the stuff that is going on in 3D, desktops, etc., has a chance to become the first real user-friendly UNIX.

-----

Hey, that is an implementation issue, not a design issue, so that's the point where I don't care all that much any more. I'd not be all that likely to use this feature (I still do "zcat < file.tar.gz | tar xvf -" instead of using "tar zxvf file.tar.gz", because I'm an old-fashioned old fogey. I don't need my tar-files auto-mounted for me).

-----

I care about the fact that our internal design has to be robust. It doesn't have to make everybody happy, but it has to be clean both conceptually and from a pure implementation standpoint. I don't want a "hack that works."

-----

This is not negotiable. We used to have a damn mess in 2.2.x with all the capabilities stuff, and 2.4.x finally cleans it up and gets it right across different CPU's, exactly because we have a clean "this CPU can do X" approach without any if's, but's and why's.

The fact that 2.2.x has bad control over capabilities and is messy is NOT an excuse to screw up forever.

----

Bad design. I'm not touching it with a ten-foot pole.

-----

But no, vendors aren't everything. And there are other vendors than just SuSE and RedHat. So take all of the above with a pinch of salt. And remember: these are just the 2.4.x rules - it's a different game when the development kernel opens again, and "vendor wishes" are much less of an issue when that happens. In the meantime, I see the stable kernel mainly as a way to support vendors, and am thus always weighing things from that angle when worrying about 2.4.x features.

-----

Never over-design. Never think "Hmm, maybe somebody would find this useful". Start from what you know people _have_ to have, and try to make that set smaller. When you can make it no smaller, you've reached one point. That's a good point to start from - use that for some real implementation.

Next: Linux on hardware »