Slashdot Mirror
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?"
More functionality moved into user space as separate modules/ and less functionality in kernel space. A reduced need for recompiling the kernel. Yes, there will be some performance hits here but now that we're starting to move into Ghz range we might be able to shed a few percentage points of performance in return for more modularity. The ideal world involves going to something like HURD but I don't think that's going to happen. Still, a direction towards more modularity is good.
Honestly, most of the suggestions that have been going on here have been in the area of layers on top of the kernel. Not that they don't need to be done, but they're the sort of things that Linus is not going to be messing with. I think that replacing X with something with a more well thought out API, or taking the standard GNU tools and replacing them with tools that use a set of XML configuration files are nifty things, but these are not strictly things that concern the kernel.
I think there will be a crisis and I hope for it.
The present kernel architecture is mostly the result of 2.0's times. And I believe that it is starting to get a little overused. Right now we have a good working base on 2.4. But continuing to perfect this will be nonsense, no matter the problems that still exist. Some people may claim that now we don't need to recompile kernels as before. WRONG! You may not feel the utter need because your machine is already running fast. However there is still too much bloatness on traditional kernels that come from distros. Today the complexity of supported hardware turns a kernel 2 times bigger than you really need. And I am talking only about vmlinuz. You run full gas at 180Km/h but the speedometer shows that you could reach 250Km/h...
In the mean time the module architecture is getting old. Presently. I'm feeling that loading and unloading modules on the run has become more frequent. And this system has troubles and it is quite inflexible in some terms. Specially if modules are in a large chain dependency like Alsa.
I don't really know how near we should go trough a more HURD-like model. But we should start thinking that we will need something like this soon. Specially when the PC starts to dissolve among smaller, bigger, medium devices of different nature and purpose. If suddenly the market starts calling for the interaction of all this trash, then Linux will be a looser. If it keeps its hybrid/awkwardish nature of the present architecture.
I believe that we also need to restructurize the divisions between several drivers/devices. Somehow that is being done (IDE section got off from the Block devices one). But I think it is not enough. IP kernel section needs some clarification as many options there are not needed for a desktop world.
I think it is a Bad Idea (TM) to think about ACL's and such similar things on Linux. Yes the traditional model is getting old. But my experience on NT has shown that the ACL's are a stupidity as a realization. They picked up a few basic rules, mixed them in God Knows What and gave them as a final product for all cases. The result is always confusion. Frankly I haven't seen no one doing serious work on NT's ACL's as the kernel of this structure has holes everywhere (starting from allowing full rights to some \WINNT stuff). Personally I prefer NDS to this. Rules are simple but you have some freedom to combine them. But i don't think that even NDS would be good for Linux.
Sincerly, on such cases like ACL's, NDS's and alikes, Linux should be neutral. Yes there should be a protocol/specification on how to insert them into kernel. But kernel itself should be fully away from these things. It should carry only a minimum of security features. ACL is costy in performance, it is bloatness in some cases, and it carries some doubts on its real effectivness. Such things and other security issues should go parallel from kernel development to avoid compromising Linux with serious security issues that may arise from chosing a wrong path.
Well anyway this is not all. I believe it is time for Microsoft to think on replacing kernel32.dll by ms-linuz64.o.
ACL sounds nice until you try to do a security audit on an ACL based system.
Unfortunately, the previous poster picked an example that was too simple to highlight the weaknesses of the rwxrwxrwx permission system. Nonetheless, you still managed to get it wrong on two counts. In the first place, as other posters have since pointed out, the problem specification did not say that the file should be writable by bob or readable by carol, both of which your "solution" allows. Here's where you have a fundamental problem: you have three different kinds of permission you need to specify (read-only for bob, write-only for carol, and none for anyone else) and only two places (group and world) to specify them. It just doesn't work. The model simply isn't up to the task.
Your second error is in assuming that alex is able to create/modify/delete groups on the fly to suit his needs which may differ for every single file he owns. This would not be the case on most systems - almost never on a well-run one. Even on a system that allowed any user to edit /etc/group, the rapid proliferation of groups that would result from this attempt to use a weak model to simulate a stronger one would quickly run into problems with scalability and manageability.
In short, you just can't make rwxrwxrwx do ACLs' job. The current permissions system is an artifact of a very time- and environment-specific tradeoff between functionality and resources (space, processor time).
Slashdot - News for Herds. Stuff that Splatters.
"Buzzword compliance" has certain advantages in this case: ubiquity.
/etc.
/etc babelfish.
Right now there are multiple XML parsers in multiple programming languages. Their common standing? They all try to be compliant with W3C specs. For example on Java, you can use the ASF Xerces parser for a while and, assuming you used the W3C java interfaces (publicly available) in your program as you should, you could swap it out for Oracle's XML parser. As long as you maintain standards, you will have support.
XML advantages: hierarchical, normalized, Unicode compliant, simple APIs (DOM and SAX), human readable as much as HTML (ie. basically self-documenting if done correctly). FYI: DOM creates a data structure/tree representation in memory and SAX is a low memory, event-based API.
Now let's look at the alternatives:
Sendmail's config file: Many people understand it. Everything but the kitchen sink (or maybe the kitchen sink is in fact in there and undocumented). Easy to understand? No. Human readable? About as much as a programming language. Universally loved? Only by the sendmail priesthood. Unicode compliant? Umm.. what?
Apache's config file: Many people understand it. Basically a flat model of key value pairs with a second level of depth patched on because of the module and multi-server support. Easy to understand? Yep (especially with comments). Human readable. Yep (especially with comments). Universally loved? Well... much more than sendmail's config file. Unicode compliant? Oops.
Generic key/value pairs: Fast and easy to parse. Flat model -- no hierarchy. Okay, granted you could use could tweak the model to allow hierarchy. Universal key/value delimited file? Not even close. Do you use the '=' as a delimiter? What about ':'? Are comments preceeded by a '#' character or a ';'? Ready to use? Nope; everyone must write their own from scratch much of the time.
People who knock XML have obviously never used it to solve any problems. Go to the W3C site (http://www.w3.org/) and check out all of the projects related to XML that are coming to fruition. All of the projects that follow rules and have publicly created and discussed implementations.
Development tools. Libraries. Easy road to entry. XML has these in abundance. It is the simplest, most complete way to solve the babel on Linux known as
The only thing preventing a Linux-universal config file format in XML is the unified schema/DTD. That's a non-trivial task, but it's a whole hell of a lot closer than any other technology. And, in fact, universal consensus on the file format is not strictly necessary for a first step. Just by moving to XML alleviates the need for multiple types of parsers in the elusive universal configuration tool. Specifying a separate schema/DTD for each config file still affords a much easier job for the config tool authors.
I do agree with you about inertia. It's hard to change entrenched methods of doing things. However if people were to submit patches that allowed the possibility of XML config files and not unilaterally replacing the exisiting ones so that if people want XML, they can have it. Does this solve the babel problem? No, but once again, it's a viable first step.
./configure --configformat=XML
make all
You use a public parser such as the James Clark "expat" parser. You look up the internal data structure for a particular program. You connect the dots. How hard is that?
Linux/UNIX have always suffered from the babel. It's time for the
- I don't need to go outside, my CRT tan'll do me just fine.
Linux needs a good forking. Seriously. Competition is good.
Woohoo! Advanced Linux Kernel Project! I'd like an integrated, supported kernel debugger, modularity, and the various "big system" vendor patches to be integrated. And a better VFS (not the current "virtual ext2 interface"). I'd also like to see more capability on the small end -- i.e., the ability to leave stuff out without triggering stupid dependancy bugs. This would come along, in large part, with better modularity. Oh, and much better planning, cummunication and forethought. And development done with CVS, not patches from the current broken system just checked into cvs. It would be cool for the big players -- IBM, SGI, HP, perhaps others -- to get together and form and operate an Advanced Linux Kernel Project.
The cabal -- [...] 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
Also, "posixitis." Refer back to the discussion about supporting named streams ("NTFS streams") to see a sever case of "it's not posix, so it sucks." Even Linus was arguing that we need it for interoperability, and so what if Posix doesn't say anything about it. Alan Cox was actually making the bizzare claim that the HFS way of representing streams in a posix-acceptable way was good. So, gee, we have a free OS designed by the government, but only partially implemented. Yay, Posix.
Linus and the others deserve our gratitude, and our respect, but not worship or unquestioning obedience.
The Emporer Has No Clothes.
Thanks for the good post!
________________________________________
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
The "problem" with going to a 169.x.x.x address is a new way to automatically set up a home network, without DHCP being needed. It's an RFC and is standard. So if you have 3 PCs at home, you can boot them all up and they'll talk over IP without using a DHCP server. They figure out which addresses are taken.
And exactly because Slashdot is comprised primarily of Linux users, not Linux developers. I'd hope the users input has some influence on the direction of this OS.
User's aren't armchair critics. They're the sole reason Linux is popular today. Thank God other developers don't share this attitude or nobody would be using Linux at all. Users are the the people that are testing your OS for you, and previding the feedback necessary to make it better. And yes, they even contribute, without writing a single speck of code, through running user groups, creating bug reports, advocacy, paying developers salaries, giving up time and money to organize Linux events, and more.
Slashdot Linux users are generally more at the power user level, but then again [at the current point in time] most Linux users are. I would see nothing wrong with asking a large body of Windows power users [eg, NT admins] where they think their OS should go.
But I wouldn't expect a coherent answer, and I wouldn't today. The benefit is the discussion and the issues it brings on to the table. This little discussion might be the start of some wonderful projects, as developers may get inspired by the issues raised today and start a project. And when that happens, more people will use Linux because it will be better. There also be more people willing to put bread [and caviar] on your table, more software for you to use to develop, etc. Software evolution is a dance between developers and users, and what had spiralled Linux into its current greatness today.
Somebody should hit you with a clue stick.
Oddly enough, optimizing the Kernel for massive systems with a plethora of processors and RAM could hurt Linux if the big Unix companies see it as a threat.
Did you know that there are kernel patches(available to the kernel folks, but I've never seen them around myself) that have exactly those optomizations? And guess who wrote those patches? Yeah, the Big Iron vendors. Jeeze. Even I'm not that cynical.
Dave
'Round the firewall,
Out the modem,
Through the router,
Down the wire,
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
The reasons why this luser lisn't lusing Linux mostly have to do with the fact that I found it so durned hard to get the thing working --
- At any given point my graphics card is unsupported or else requires a more advanced version of XFree86 or else there's something in XF86Config (capitalization? oh well) that I'm missing. In other words, no matter what I do I wind up at 320x200 4-bit, when it doesn't just crash. I know, I know, I oughta have bought a compatible (read: older than my leet Geforce2) graphics card...
- I have no idea where to look for config files. Don't tell me; if I really wanted to know I'd buy a book. Also, it seems to me that Linuxes are typically less willing to try and figure things out their own durn selves than Windowses. In MS desktop OS's once you install your nic driver it goes and FINDS the darn DNS and gateway and all that shit, which yes I should know but why the hell should I have to type it in? If Windows can find all that stuff Linux should be able to.
- I'm afraid of the word "compile". I know, I know, you can't get away from it when you have software that has to be compatible between different distros. Probably it's all very easy; now go and convince your mother of that and I'll eat my words. Seriously, maybe APT is as good as everyone says it is; I'm just talking from the experience of four aborted installs.
- I want things that I need to know about to jump out at me - I don't want to dig through unfamiliar directories via the command prompt. I want a folder called "Control Panels." Maybe I'm just choosing the wrong distros or something.
Maybe I'm offtopic cause none of these are real kernel hardcore shit but leet-haX0r or no, if you want more otherwise-capable computer users to go over to Linux, these are the things that have to be taken care of. I'm not unsympathetic to issues about hardware mfgrs making drivers difficult to write but that doesn't change the fact that if my card don't work, my card don't work.
It ain't flamebait, it's food for thought, and if you MUST mod it down use "offtopic." Thanks.
The problem with most software is not lack of features. It is rather the opposite: you can't get rid of particular features that are absolutely unpleasant under particular, given circumstances.
I'm sure ACLs may be useful for some people, in some situations.
We know of the existence of the concept. We probably came across them in some other setting (e.g. NT) and not everybody is impressed.
ACLs are not generally useful. If they were, everybody and their little sister would be clamouring for them, and they obviously aren't.
Undoubtedly, there must be kernel patches available for you to have your ACLs, without forcing them on everybody.
If Linus built ACLs right into the kernel, I would be forced to put in serious effort and rip it out again. If he does too much of this kind of things, Linux would start forking.
XML is *the* general solution to the untrivial problem of *extensible* syntax. There are no other contenders waiting in the wings.
it does not, however, assault the intractable problems of semantics.
No shit. What configuration format does?
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.
Fine. They should continue to do so. XML parsers dont interpret, they parse. The onus of interpretation lays upon the individual app writer. That's not going to change; we already knew computers werent thinking machines.
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.
Really? Do you also think compilers are the work of the devil? Do you hand assemble source code into binary 1's and 0's?
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.
Nonsense. The app defines the xml, the parser parses that xml and the app interprets the results. People dont write a compiler to compile their source, why should they write a parser? Given a well defined schema, I would much sooner trust an xml parser than I would a hand rolled parser.
I dont understand what api changes you are refering to. If XML changes, you rewrite your xml file, not your app and you upgrade your system's parser without dropping the older version. There are several versions of ncurses on my machine, for example. This sounds like a red herring. Already XML is far more standard than the unix api.
I dont think you quite understand what xml is.
I think it's because XML is not relevant for most of our [Linux's] problems.
I'm sorry, XML is here to stay and for good reason. It will become manifest in everything from docs to configuration files. There's nothing to debate.
--
--
Eat right, exercise regularly, die anyway.
without a corresponding "standard" to describe the structure the file should have. If you want regularity, we need a well-accepted consensus on the different styles of options that can be used, and syntax for representing them.
If you had standard meanings for different kinds of config options and a standard format, you could get your wish of a single tool (be it command-line, slang, or X) being used to parse and modify all compliant config files. I've considered implementing something like this, myself. The problem, of course, is less in implementing it than in getting all of the disparate projects to accept it.
The only groups that might have the power to start this change are the distros. Red Hat seems reluctant to define standards, as they don't want to be seen as "pushy". Mandrake doesn't have the clout. To me, that leaves Debian and possibly Suse. If Debian came out with a standard, started using it for their tools, and developed a nice, simple interface, I think they could start persuading others to follow suit. It's a good idea, but it will take a great deal of persuasion.
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".
--Lenny
--JRZ
As long as there is Unix, there will be Linux and BSD.
Why? Simple. Sun, IBM and HP all see Linux as a way to gain mind share. Let's look at two hypothetical:
A business builds a small web server and database server using NT or 2000. Their business grows and soon they realize they need more power. Microsoft promises to scale infinitely. A salesman from Sun shows up and offers a Solaris solution. Better stability, scales better, and Oracle is kicking MS-SQL's but in exactly the kind of business they're running. But running Solaris would require retraining of staff, replacing all their software and migrating their data to a new system. Sun looses the sale.
A business builds a small web server and database server using Linux. The business outgrows the memory model of Linux because the same memory optimizations that allow you to have a 4,000 hit per day web server running on a 386 cause some problems when you reach eight processors and 24 gigs of RAM. Solaris walks in and offers a solution that scales better, runs ports of all the software they're using and because they know how to run Linux, Solaris is a small skip and a jump away in IT skills.
The more people who run Linux or BSD on their home systems, the more sales the big Unix vendors will be able to make, because there will be more people who know how to operate the systems. This is exactly why NT has gained so much ground. People know how to run Windows, so they figure a web server running NT can't be that big a leap.
Oddly enough, optimizing the Kernel for massive systems with a plethora of processors and RAM could hurt Linux if the big Unix companies see it as a threat.
www.matthewmiller.net
"Live Free or Die." Don't like it? Then keep out of the USA
In UNIX, there are three entities that can be given rights to an object; the owner, a group and everybody. Thusly, no more than one group can have control over a an object. In other words, Finance and Marketing cannot be both given write access to a directory; you'd need a third group which had, as members, the first two groups. Access Control Lists start out by stating the default permissions (usually 'nobody can do anything') and then applying exceptions (Bill can read, Lucy can read/write, Doug can read/write/execute.) ACLs also allow for more options; with UNIX, you're stuck with read/write/execute. With an ACL, you can define almost any operation and allow/deny it. Read, write, execute, list contents, create subdirectory, grant rights to others, revoke rights from others, copy files in, copy files out, etc etc. ACLs are a requirement of any level of Trusted Computing above c2, I think. They're very powerful, but also much more difficult to maintain than UNIX style permissions.
Vintage computer games and RPG books available. Email me if you're interested.
As already mentioned integrating some kind of Journalling Filesystem will maybe the most important task.
May it be XFS, JFS, ext3, ReiserFS, or Tux2, i think this will and must be one of the next addition to the kernel tree(probbably ReiserFS in 2.4.1). There is no big and bright future for Linux if we don't get to a filesystem with better data integrity. I think that in fact the diversity of Jfs's is a great thing because:
It will create competition
There will be FS's optimized for certain tasks(something that is already happening now, look at ReiserFS SQUID Optimization)
The existence of XFS and JFS for Linux already shows that both IBM and SGI are really willing to put their Unix experience into the future of Linux (At least that's what I hope)
I think the involvment of companies like IBM and SGI will maybe the biggest chance for Linux over the next years
There is the Unix experience of two of the biggest players on the market going into the most active Developer community in the world. We can really hope for a bright future
"Mommy, mommy! The garbage man is here!" "Well, tell him we don't want any!" -- Groucho Marx
Dun Dun DUN!!!!
:)
2.4.1
then!
2.4.2 maybe 2.4.3!
It's a joke, don't kill me
Linus' comment on this:
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.
Here are some of the ways I'd like to see Linux evolve in the near future:
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:
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.
Slashdot - News for Herds. Stuff that Splatters.
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™ development should go and expecting a coherrent answer.
Second Law of Blissful Ignorance
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.
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:
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.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 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.
Stop using flat files for .conf, Use XML as standard configuration format. This includes the make tools, lilo, and the rc.d as well.
/etc back. Move the conf data for a /.conf directory or some thing.
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