What Does The Future Hold For Linux?

Nailer asks: "With kernel 2.4 in the final stages of bug hunting, and on track for a December release, I thought it might be pertinent to discuss the future of Linux. What now? ReiserFS will apparently be in 2.4.1, but there's very little information about the mid to long term available. Where do you think Linux [the OS, as well as the kernel] will head in the future? Personally, I'd really like to see POSIX ACLs as the default permission system [allowing the fine grained access control that many apps try and implement themselves]. What do you think?"

Comments

Re:Incorporate kqueue/kevent from FreeBSD

[edhall]

Linus' comment on this:

I've actually read the BSD kevent stuff, and I think it's classic over-design. It's not easy to see what it's all about, and the whole <kq, ident, filter> tuple crap is just silly. Looks much too complicated.

All due respect to Mr Torvalds, but I'm not sure he understands the intent behind the kqueue interface. It's not just intended to be a poll() on steriods, though it serves that function. A kevent does not need to be related to a file descriptor--for example, signals and the status of other processes can also be monitored with the appropriate filter. Other filters will be added as time goes on. The tuples Linus objects to are actually the simplest way to provide this level of generality through a single interface.

-Ed

My wish list

[Salamander]

Here are some of the ways I'd like to see Linux evolve in the near future:

• Better modularity. There's still way too much interdependency between what should be separate subsystems. Sometimes this is in the form of explicit references to each others' data or functions, but just as often it's a more subtle but still undocumented reliance on "X never does this so I won't even check for it, and God help the guy who comes after me if X ever changes".
• A better VFS layer. Just having one isn't enough because, to be blunt, some folks did a pretty piss-poor job of specifying, implementing, or testing it. This fact is the primary reason 2.4 isn't out yet.
• A mature persistent-module-data interface. We don't need anything as overburdened as the Windows registry or AIX ODM, but we do need something and recent steps in this direction are a very good sign.
• Journaled, soft-update, and atomic-update filesystems. Not one, but several. Let them compete. This is an area where Linux can be the foundation for significant improvements in the state of the art.
• Better testing. We need a serious test suite for each of the major kernel components, and one for the whole system as well. We should be beyond the point where the current near-total lack of unit or regression tests is acceptable.
• Better performance management and monitoring tools. How many of you have used PerfMon on NT? The way it's implemented is kind of crufty, but the flexibility and functionality it provides makes Linux look really bad by comparison. It should be a standard part of Linux kernel or major-subsystem (e.g. database, webserver) development to define and export counters for a general tool like PerfMon to use. A lot of the bickering on linux-kernel about where the bottlenecks are would be neatly settled by a five-minute session with such a tool.
• ACLs? I'm still not 100% convinced we need them, but they are more powerful than the current system and there seems to be a demand. In any case they're likely to become a checklist item for a lot of folks soon.

Lastly, there's one more thing I think Linux needs, but explaining why takes more than should go into a single list item. Linux needs a good forking. Seriously. Competition is good. The cabal - yes, there is one in effect, even if its exact membership is debatable - generally has good ideas and provides incredible value in bringing order to chaos. On the other hand, the Powers That Be sometimes suffer from severe Not Invented Here syndrome, and sometimes they use their bully pulpit to shout down perfectly good ideas that conflict with their own biases (or even projects that would compete with what they want to work on). Several have recently seemed to start believing that they're omniscient, as though merely being a genius wasn't good enough. Linus and the others deserve our gratitude, and our respect, but not worship or unquestioning obedience. They need a wakeup call, in the form of someone defying their wishes and achieving superior results in the process.

This will happen, sooner or later, one way or another. We have two choices:

• Embrace the possibility as a generator of innovation and healthy competition, and as a way to keep everyone honest and humble.
• Let it become a source of chaos and dissension, until someone else eats our lunch for us.

That's it. There are no other choices. I know this will probably not "resonate" with the younger members of the audience, but I would compare the situation to a divorce. The most amicable divorces, where people still remain friends, occur when the people accept the reality and work together on making necessary change go smoothly. The messiest, most destructive divorces happen when people have stayed together long after their interests diverged and they've spent years learning how to hate each other. I don't want Linux to turn into War of the Roses.

Why Not Just Read Kernel Traffic?

[Carnage4Life]

Nailer asks:
With kernel 2.4 in the final stages of bug hunting, and on track for a December release, I thought it might be pertinent to discuss the future of Linux. What now?

If you are truly interested in Linux kernel development and the future of the OS, why not just just subscribe to the Linux Kernel mailing list, browse the archive or read the digests on Kernel traffic?

Slashdot is comprised primarily of Linux users not Linux developers. Questions like this are better sent to mailing lists frequented by the people who make these decisions than to a bunch of armchair critics. This article is similar to asking a bunch of random Windows users where Windows&#153 development should go and expecting a coherrent answer.

Second Law of Blissful Ignorance

Re:A move to XML would be meaningless...

[__donald_ball__]

But back to my earlier point point: simply moving to XML buys you nothing but complexity. What you really want is a common ordering and syntax to the different files such that they can be edited by a common tool. That's all well and good, but that can be achieved *without* XML just as easily as it can with. I see no inherit advantage in using XML, except the gain in "buzzword compliance".

You've evidently never read the XML specification, or tried to use XML anywhere. Here's the deal. XML takes ASCII to the next level. ASCII lets you encode strings (in latin characters) in files in standard fashion. XML lets you encode trees (in arbitrary character sets) in files in a standard fashion. Trees are the natural data structure for most configuration files.

Even more useful stuff - you get validation with DTDs and Schemas. That means each program doesn't necessarily have to check its own configuration files for sanity, it can rely on the parser to catch the syntactical and much of the grammatical errors. Hell, each program doesn't have to write its own parser any more, making it simpler and reducing the possible number of bugs in the system (if all daemons shared a common configuration file parser).

Finally, by using XSLT stylesheets, it's very easy to transform XML files between different formats - giving you a relatively simple upgrade procedure when a daemon changes its configuration file format, and giving you a relatively simple way to convert configuration files between daemons - from postfix to sendmail, say. Think I'm blowing smoke? I already have all of my system data centralized in one XML file from which I generate the various daemon's configuration files. I think this is probably going to be the way this unfolds - userland tools will arise that use XML files to generate the collection of oddities that is the /etc filesystem.

I really don't understand the Linux community's perceived resistance to XML. I think it's because Microsoft was an active participant in the development process, and because many of the early implementations of the XML tools were written in Java. I really wish that attitude would change, because XML is an important standard for taking UNIX to the next level. One of the things that made UNIX great was the proliferation of small command line tools that cooperated by passing ASCII streams around. Imagine how much more powerful that paradigm could be if you they passed trees around!

Re:foolishness...

[Alomex]

I'm only going to say this once - XML is *a* solution to the trivial problem of syntax;

Syntax is not a trivial problem between advanced applications. Designing a protocol that is expandable, be it for config files or interprocess communication is a pain in the neck. We started using SGML for config files and interprocess communication in 1995. You have no idea how much work we saved by using standard parsers and a protocol that wouldn't break if we added a column to the message...

it does not, however, assault the intractable problems of semantics.

True enough. XML only gets you half-way there. Isn't that still better than nothing? Moreover, since the semantics is intractable, as you well state, the solution is to manually provide syntactic markings through, you guessed it... XML tagging.

After 6 years of adminning systems, I feel more secure with each daemon checking their config files than passing it onto an independent parser daemon.

Reality check. What is likelier to be buggy: a one-off parsing routine or a well established and universally tested parser such as SAX?

We know the answer to that one since the whole open source movement is predicated on it. The publicly available routine will be less buggy.

The world is moving en-masse to XML. Yes, it is overhyped (just as high-level languages, structured programming, OOP and Java were in their time). Yet all of those were clear steps forward in computing.

Same goes with XML. Linux can be either ahead of the curve, or behind it, always destined to be a late copy of a thirty-year old operating system.

Now that Linux is stable and of amazing quality it is time to start looking towards the future and make sure a good operating system becomes hands down the best.

foolishness...

[denshi]

You've evidently never read the XML specification, or tried to use XML anywhere.

So you wade right into it with an ad hominum attack - how nice.

I'm only going to say this once - XML is *a* solution to the trivial problem of syntax; it does not, however, assault the intractable problems of semantics. Your fantasy of trees magically passed between programs with no knowledge of each other falls down when you realize that each program assigns different meanings to each file/tree/whatever.

Other points:
Programs don't have to check their own config files: After 6 years of adminning systems, I feel more secure with each daemon checking their config files than passing it onto an independent parser daemon. Each program gets to test once with the parser code inside the program; if you move parsing out then you move that work onto the sysadmin (or home user) - the world is filled with minor API changes that screw you over. Feel like running regression tests on every piece of software you install?
Programs avoid bugs in their parsers: Parsing text is a solved problem. When was the last bug where Apache couldn't parse its own files? Compare that to XML, which is an evolving standard - even if you never have a bug in the XML parsers, who's to say that total backwards compatibility will be maintained?
When the daemon changes its config file format: Riiiggghht.. I've seen this happen only a handful of times over the hundreds of software packages I've fucked with. Copying config between applications? Best idea in your post, but most of us will still handcheck it, because of Semantic Complexity. Does postfix's 'address' field mean IPv4, and sendmail's 'address' field allow IP or DNS hostname? When you move to IPv6, does postfix break silently? These are issues that sysadmins everywhere deal with on a daily basis - none of it will go away with a common syntax.

I really don't understand the Linux community's perceived resistance to XML. I think it's because Microsoft was an active participant in the development process, and because many of the early implementations of the XML tools were written in Java.

I think it's because XML is not relevant for most of our problems. I use XML for foreign database data exchange. (I also use Java, so I don't understand your reasoning.) Thus far, I don't have any better uses for it, and I'm not hurrying to find any.

I do like your idea about changing streams to structured streams, though. Most apps these days are moving to shared memory in the absence of any such solution.

Standards...

[jackb_guppy]

Stop using flat files for .conf, Use XML as standard configuration format. This includes the make tools, lilo, and the rc.d as well.

With this grand unification:

1) XML parser API could be added so all modules will not have to create thier own.

2) A single config tool could be written so that the options and help information can be entered and checked. Lowering the entry skill level for general users.

Anothe wish is to get the /etc back. Move the conf data for a /.conf directory or some thing.