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?"
I think one of the biggest threats to linux is the quick
change of needs. The dotcom age has come and gone. The ASP age
was full of promises...
And now, time to change your mind, we see the XML-peer-to-peer
model gaining speed ( ok, don't remind me p2p is there from
the beginning... I know this well. I mean there is now XML
to make it rule seriously over the world ).
Linux is efficient as a server ( maybe a little less
than FreeBSD, but that is just an opinion ), has quite good
security and it can be made use of these strong points to
be a player in the new scheme.
But a huge pressure will soon appear, if it hadn't already,
on the windows side of the industry to push this OS higher
than it never has been.
The Linux community would have to react *quickly* but as far
as I see, nothing happens. Just take a look at the HUGE wave
of XML docs and software that are coming... there are nearly
all win-related !
Ideas, docs and work are needed bad !
Anon
Nice use of 'ad hominum'.
-Paul Komarek
Have a central repository of configuration data stored in a database, accessible through a special API. Call it a "registry".
If you have more than one mode line, X will let you change resolutions on the fly with a key combination.
Bingo! What all those XML-loving types don't seem to understand is that XML is just a glorified text file. You are right on the money in saying that a common config file format is what's needed, not "buzzword compliance" as you nicely put it. However, I don't think this can be achieved not only because different projects have to accept it but simply because it may not be practical to do so. Is is possible to make fstab and named.conf use the same format? Maybe. Would that make it more convenient to configure them? Doubt it.
___
___
If you think big enough, you'll never have to do it.
You mean recompile the kernel?
___
___
If you think big enough, you'll never have to do it.
It's not realistic to expect a volunteer to write device drivers for harware they don't have access to either.
Seriously, and don't give me that "Well, Linux will never achieve world-domination with that attitude" crap. Hardware manufacturers generally write drivers for Windows, Microsoft doesn't even have to pay anyone to do it. Linux is a volunteer effort, if people can write a device driver for hardware they need, they do it.
If you really want a driver for a piece of harware, maybe you could ask one of the developers that wrote similiar drivers and send him or her a sample of the hardware. There is simply no other way, unless you expect driver developers to buy and write drivers for every piece of hardware in the world out of the kindness of their hearts.
"Free your mind and your ass will follow"
Linux will not die until no one is interested in playing with it anymore.
I would hesitate using the term 'extreme weakness' for the security model. It is simply the Unix security model which, while far from perfect, is at least reasonable with proper administration.
"Free your mind and your ass will follow"
XML has some potentially useful 'meta' features. There are a lot of parsers, and other tools and standards that interoperate with it well.
From the perspective of config files, one of the more important things is that you could define a set of schema fragments that can be used to assemble the config files for particular systems.
Its certainly not necessary to use XML, but it does seem to add something over the creation of an entirely new and different syntax,
It would be pretty interesting to see where did you get this list from. As I have seen completely different evaluations. Besides I am a systems integrator/administrator/hacker and my practice goes tremendously different from yours
You forget Solaris AND _AIX_ on the Web servers. If there is one thing where AIX performed very well was on Web Servers. Solaris is the big gammer for complex Internet tasks and big Database systems.
Linux is the big gammer on Web servers. Try a look at http://netcraft.com and search for their July report. Windows is beaten by Linux!!! (truly by a very narrow margin).
BSD on the Web? Good for fixed, glued and inflexible implementations carrying high performance. With a special note on security if OpenBSD I is called onto the show. On the rest a headache.
Small office servers? NT, Novell, Linux, BSD. I still haven't seen real and serious W2k implementations on such environment.
Embedded, realtime? You are right on what concerns QNX. In terms of its quality. But not in terms of how spread it is.
Games? W2k???? Are you kidding? Maybe WinME (You? No thenks!), 98, 95, Whistleblower. But never W2k or NT. On W2k only a small number of action and quite very new games may preform well and stable.
Besides you forget several other Internet servers like ftp, DNS, Mail, etc. There Linux has also a big piece in the pie.
You forget about some very specific application servers like DB servers and Fax servers, where also Linux has gained some good points.
And on what concerns Worstations. Please add Linux to your list. The fact that Linux is not ready for the dumb installer does not mean that Linux users don't exist. Only in this city there are a few thousands.
On what concerns w2k. Very good for desktop office tasks and some professional graphics processing. Average for some games. Not too bad for very small office server tasks. On the rest: no comments...
I don't use DSound3D w/EAX and don't see the meaning for hunting a SBLive. My Archi-old GUS MAX is still enough for me. I need OpenGL but not only on X. My tradtions are to put everything on /usr. My colleagues either put on /opt or /usr/local. One puts in /usr/src (...). RedHat/Mandrake config file layout is tractor for servers but Slackware's is too dumb for a desktop station. RPMS are good but bloat. Tarballs are primitive but stick to the minimal demands. Drivers on 2.4.0 should be recompiled for 2.4.17 as there are several features that will always grow in incompatibility (M$ featurefix DLLs are an example of this). I use glibc 2.1.9x/2.2 only. Not long ago, in one station, I used mostly the latest libc5. Ncurses can be 3,4,5 as long as they fit the package I need to use and I don't wanna run every five minutes to the developer, asking him for upgrade features. Sometimes, I need joe's-own-stupid-lib.so because I still have old stuff or some other demands hacks (ex. I need 3 libglides.so.* on my comp) On Perl/Python you may have some point. I use bash, but my solaris friends highly prefer tcsh to it. And I need sash on init 1 for deep dives on the system.
One note. People should stick to some baselines but not on stating "ncurses 5 and nothing else!" The rules should tell not about the apps or versions but how to implement a file without raping the whole system. Things like if two libs with similar names and different incompatible versions, then apps should link strictly to the libs with version number and not libXXX.so. And, when upgrading, making warnings that "libXXX.so.#.## is used by app", but not unilaterally deleting it. If this happened then all conflicts would become minimal.
1) Agree.
2) Partially agree. Some standards should exist but no one should stick to them if they don't cover the features of specific device systems. However standards shbould be followed as far as possible.
3) Hooks? What the Hell is this? Redmond's flamebait? I don't use KDE, Gnome, GTK, or anything else. I use all of them and none of them in preference. If anyone tells me to stick to some KDE or anything then I prefer Bora-Bora to this.
4) Configure stuff should have some more organisation. But "NO THANKS!" to automatic loads if there will be no choice. Such automatisation will be only useful for some users. Others, like me, would highly prefer to have hand control on drivers. Besides a more flexible hand control than now...
5) Replace OSS? No. I prefer Alsa to OSS but there are issues where OSS is much better than Alsa. Specially if this concerns hand control of these drivers or you need minimal use of sound capabilities with good quality. Alsa is too bloated/unstable for some sound server implementations.
6) Ok. Fraction the kernel. REALLY! Fraction it. Divide it. Cut it in half, a third, a tenth. Slander it. The thread oriented problem is serious but it possesses its minuses, specially on some performance issues. And i believe that sticking into the "ONE UNIQUE" kernel is probably the most stupid thing ever established. The only problem is how well we may perform the fractioning. But I believe that people may find solutions much similar to those that happened when we passed from a.out to the ELF based kernels.
Don't confuse Linux and KDE/Gnome/WM... These things are not even Linux rooted. And I hope no one of kernel developers will ever dream on integrating the kernel with such stuff.
You may be right that they are still relatively slow. But that's a problem that 70% is due to X. Yes, I think that most *NIX developers should think about deeply reforming this system. Even 4.0.1 with a super-patched structure of DRI/XVideo/GL and other drivers is still slower than Windows.
Distros more standard? No thanks... I prefer to go through a shelf and see 10 Linux distros instead of one Windows pack...
Another view:
Windows: Pay for Hardware and Windows. You come home and note that your embedded Windows is a year old. If you are a good citizen go back and buy a new fresh Windows version. If you're mad at M$ you get a pirate copy. Each end of month you reinstall Windows.
Linux: You come to the shop and tell what you need. You warn them that you will it them alive if the HDD is not clean, virgin, nude and fresh new. You send them to Hell all Windows emblazements and remind them of a Commitee for Consumer's Protection. You come home, grab a Linux distro. You take a month fine tuning and recompiling the whole stuff. For a year you forget about reinstalls...
Solaris: You buy hardware the same way as Linux but grab a copy of Solaris. You cry Hell on the lack of drivers, apps, fine tuning for a month or two. In the end you wait a year to reinstall Linux. In the end you reinstall Solaris the same way as before.
BSD: You buy hardware the same way as Linux and Solaris but install BSD. For a year you "make world" and think why BSD is not so flexible and available as Linux.
"rwx" permissions existed in Unix from its creation, so by definition they are Unix-like. That doesn't mean they are the best way (look at Plan 9's credential system for more recent ideas from Unix's creators), but they are what Thompson & Ritchie used in place of the more more capable (and complex) mechanisms of Multics.
First of all, the reason it's not in CVS is so that the code base can be controled. So some evil hax0r from Microsoft can't go and make it mutate like their ads in germany clame that linux will do. Besides that, The decision is up to Linus, If he wants to move it into CVS, thats his choice, but I think it would be a bad idea.
:) (The kernel on my exchange server at work is 26 megs when running)
Two, Win2k is not all that stable. My Win2k laptop has just frozen from time to time, and youc can still get BSODs from just using Win2k, Though they are much more rare.
I have several things I also dislike about Win2k:
- It goes to some ip address starting with 169 when your dhcp server lease runs out. It also has this tendecy to crash my ISC DHCPd, Yet I haven't bothered to sniff the conversation yet.
- IPSec is a bitch to get working with free/swan
- I have found that IE 5 and IE 5.5 on win2k have this tendency to grind the system to a halt within 3 hours of it being booted in some cases.
I admit, I like the fact that it has IPSec, PPTP, and L2TP support built in. I beleave that Win2k is designed for telecommuters.
Oh, Did I forget to mention that Win2k is a memory hog, It's kernel is 28 megs when running, and they call it a microkernel
-LW
Yes, LW is a MCSE, Though he hates Microsoft Products, they have their uses, like making a system for only one person at a time, and slowing work down so Network/Systems Administrators can sleep peacefully in their cubicals w/o any overhead florecent lighting.
BTW, What kind of code can we now type into our messages? C? C++? Perl? Pascal? god forbid vbscript
This misses the point completely. By the same argument, C is just a glorified text file.
--
Life's a bitch but somebody's gotta do it.
Sorry, but this is not a good idea. The reason being that any call to any such driver requires two full context switches. One for the call and one for the return from the call. Since a context switch is monstrously expensive, compared to a simple method call (which is all it takes to do a driver call with the current architecture), it's a MAJOR speed bump.
My point was that it's probably necessary to do it despite the speed hit. Vendors are just starting to notice Linux now; we'll be seeing an explosion of hardware support some time soon. Many of these drivers will be badly written, and stability will suffer a *lot* if a driver crash can take down the rest of the kernel.
Now, regarding the speed hit. I think that it's possible, with clever programming, to mask most of the performance degradation. While individual calls to the driver will still have a high cost, you can minimize the number of calls that need to be made.
For things like mouse and keyboard drivers, that have dozens to hundreds of events per second, speed is a non-issue. Context switches aren't *that* slow.
Sound drivers are similarly not much of a problem. Modern sound cards have large on-board buffers, and only need new data a few dozen times per second - few driver calls needed. Similarly, if the block size is set to something reasonably large by *default* when writing to the driver, you won't lose much sending sound data _to_ it.
The big performance-eaters will be network and video drivers, as both have to deal with large amounts of data. Again, though, the logical way around the problem is to queue substantial amounts of data before sending it to the driver. Make the default driver access points operate on long lists of primitives (for graphics drivers) or large blocks of data (for network drivers), and *remove* single-primitive functions. Add sample code or a user-space library to handle queueing, that the user can use if they don't feel like writing their own queueing code. Add a "flush" command that can purge the queue. Problem solved; the number of driver calls drops greatly, thus making context-switching overhead much less relevant.
I've done driver development under Linux, and my main complaint is having to reboot after every test until I've stomped all of the pointer errors in the driver. Having driver modules live in their own processes would solve this problem, and would also add insurance against the Windows destabilization effect (half of the instability of Windows comes from buggy drivers scribbling over memory, and it's just a matter of time before the same thing happens to Linux).
Yes, this is already present in other operating systems, and yes, this would slow down driver functions with the overhead from additional context switching, but that doesn't change the fact that it's still a Good Thing for Linux to have.
You should even be able to do this without breaking most of the kernel programming interface. You'd just need to add extra functions for doing things like messing with PCI configuration space (which most drivers do, but few do extensively, so no great imposition here).
The big advantage to XML is that there's been lots of energy put into it, it's been pushed through the standards committees already, and there's lots of good, free tool support. The disadvantage is of course the verbosity and the supposed editing difficulty (although anyone one who can make an HTML page shouldn't have any real trouble with XML in their text editor, not to mention that it can be validated, so you'll know when you screwed up before your program goes freaky).
/etc) Which means, you're right, it would take a lead distributor like RedHat or Debian to back the project, although having cross-Unix commercial support from someone like Sun wouldn't hurt either.
So it's not a clear Win-Win, obviously. But the problem is that nobody else has a standard structured format ready to go. You might find a lot of anti-XML sympathy among Unix admins, but then the anti-XML faction will have to spend the next 5 years arguing over what the best format actually is, and then you would have to go and build bug-free tool support for it.
And, of course, the efforts to build a non-XML standard syntax will likely devolve into arguments about square versus angle versus curly brackets and line-ending characters, and will eventually fork and fork again and probably fail. And then we will be in the same situation as we are now -- several rolled-their-own open parsers and formats, except now each with the glossy sheen of bogostandard declarations.
But let's be realistic here -- the argument isn't really about XML versus some non-XML alternative. The argument is about GUI'd admin tools and an newbie-friendly system versus the crusty ego and fat paychecks of unix wizardry. You need a little of the former if you are ever going to get Linux/Unix on the desktop, but you can never get rid of the latter. That means that both systems will need to be in place, and there will need to be near seemless conversion between both. That's lots of engineering and lots of mucky code. (I'm thinking of something like NeXT netinfo which imports/exports to
--
Business. Numbers. Money. People. Computer World.
Well, I could be completely wrong about this, but it seems like every Unix system I've ever seen is built up from the core assuming 8-bit (or even 7-bit) text streams. Kludging Unicode onto that would seem like a nightmare (or a complete rewrite of user space), and the config file issue is minor in the big picture.
--
Business. Numbers. Money. People. Computer World.
You wont have to edit xml by hand.
Well, I was thinking about single user mode, and you will always have the VI-or-die faction to deal with.
It would be [a win-win] if the only objection was the one you raised
Tell that the the significant faction of Unix users that like things they way they are. I'm an XML proponent here, BTW.
What's being transferred - in the unix world, anyway - will remain out the newbies reach just as it always has.
To some extent, yes -- I'm not expecting XML to solve anyone's sendmail configuration problems. However the most compelling reason for doing this is to build a system that has a better/more friendly toolset for configuration changes. (See linuxconf, which imo is just dangerous.) XML-for-XML alone is not going to fly
--
Business. Numbers. Money. People. Computer World.
Linux needs a good forking. Seriously. Competition is good.
While this may be true, it seems unlikely for such a fork to develop without animosity between the two sides, especially if both are targeting the general marketplace. (Niche markets will be more readily tolerated as forks, especially if they have conflicting needs.) XEmacs vs. GNU Emacs is a good example of this animosity. On the other hand, EGCS did resolve its differences with GCC. (But did they actually achieve their goals as stated?)
That being said, I suspect there is a window of opportunity for someone to attempt to create a mainstream fork of the Linux kernel. Since Linus has eschewed most software engineering suggestions (CVS server, regression testing, etc.) and many people feel this is hampering Linux development, someone dedicated to maintaining a fork with a more engineered development process might actually have a chance at gaining mindshare. Unfortunately, this would almost certainly cause animosity and risk dividing the community. "United we stand; divided we fall." There's a delicate balance between encouraging competition and self-destructive infighting. GNOME and KDE may benefit from competition, but the entire Unix community was damaged by the Unix wars between vendors in the 80's...
How do we strike the proper balance, and should we take the risk?
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
In user land, I'd like to see more kde /gnome /pick your wm integration. Yes they are compatable, but more compatability inin things like themes, and theme creation tools. Applications need better performance as well. So many kde and gnome applications take forever to start up, on my dual 233 w/128Meg of RAM. That is bad. maybe this could be fixed by more compatibility in th elibraries them selves and then the libraries that these programs use could be loaded into RAM at window manager startup. Or this could be an option for those with the memory. Thus the applications could start up real quick.
Next I'd like to see the distros become more standardized across the board. I.E. I should be able to install an RPM from one distro on another with no recompile and no problems, like this is not Mandrake or SUSE error messages on Redhat.
I don't want a lot, I just want it all!
Flame away, I have a hose!
Only 'flamers' flame!
FINALLY!!!
I have been complaining/whinging/asking about the lack of fscking ACL's for over a year an a half. They are (IMHO) one the BIGGEST limitation of linux. If anybody has attempted to use linux for a large number of users, they soon find out that they need ACLs!! Yes, there are patches and such, and I have tried them - although they are very unreliable.
ok.. lets say every user has a public_html folder in their home dir.
you want
1. for default files in their home dir to be read only by the user.
BUT
2. any file in public_html to be read and execute by world.
you want these permissions to apply TRANSPARENTLY. So whether if they put the files there from their shell, samba, ftp, appletalk, nfs WHATEVER - those files in public_html are available to the world.
go on.. try do that without ACL's.
you _cant_ do this transparently without ACLs.
This command won't work. Look at the output of "ps -ae". Something like this is closer:
ps -C "tcsh" --format=pid= | xargs kill -9
or if you really want to do it with a grep and regex:
ps aux | egrep ".*tcsh.*" | awk '{print $2}' | xargs kill -9
----
Celebrate the finer things in life
^tcsh^clip
----
Celebrate the finer things in life
Gee, I have a single config tool: it's called vi (on a minimal system).
Microsoft really f*cked up windows for many of us when they moved away from *.ini to the registry. Personally, I think flat-files for configuration are the pinnacle of configuration methods. XML might seem equally easy to edit, but the parsers would need to preserve formatting and comments. Why not just standardize on
# this is a comment
keyword=setting
We're almost there already and there are plenty of libraries out there to read and write them.
I guess the only real advantage of XML conf files would be that your GUI config utility wouldn't have to know about a new tool before it could give you the config options for it. But my philosophy is that if you have to use a GUI to config your system, maybe you shouldn't be config'ing it.
On kernel-traffic you can see a recent discussion about select and poll on Linux. They just don't scale well AT ALL.
Last week's Kernel-Traffic summary, Linus actually says the opposite:
what you're showing is that Linux actually is _closer_ to the perfect scaling (Linux is off by a factor of 5, while Solaris is off by a factor of 15 from the perfect scaling line, and scales down really badly).
Now, that factor of 5 (or 3, for 2.4.0) is still bad. I'd love to see Linux scale perfectly (which in this case means that 10000 fd's should take exactly 100 times as long to poll() as 100 entries take). But I suspect that there are a few things going on, one of the main ones probably being that the kernel data working set for 100 entries fits in the cache or something like that.
Either
1. Solaris has solved the faster-than-light problem, and Sun engineers should get a Nobel price in physics or something.
2. Solaris "scales" by being optimized for 10000 entries, and not speeding up sufficiently for a small number of entries.
cpeterso
Linux needs a good forking. Seriously.
;-)
Yeah, me too, I could definitely use a good forking. Perhaps I should spend less time with you guys and more with my girlfriend
--Gfunk
Send lawyers, guns, and money!
Although it isn't point and drool.. The Gnu CFENGINE (http://www.iu.hioslo.no/cfengine/) allows easy management of 1000's of systems. It is scripting based, but the scripting language is very, very, very simple and easy to learn.
I believe PIKT (http://pikt.uchicago.edu/pikt/) is another similar app..
As for one click managment, even in the NT world I've never seen a decent system for managing large numbers of systems that is totally point and click. Even Microsoft System Managment Server requires some scripting. (as well as requiring you to set up SQL server).
There is no "+1, Pun" moderation option so the moderator had to select another reason. Some moderators recognize how enthusiastic some people are about the grape.
Also, it would be nice to be able to adjust the resolution of X while actually in X
It is called xvidtune
Does anyone have an online resource explaining what ACL's enable you to do? Maybe even comparing the Unix flavor(s) to the ACL's they have on Windows NT? Just some introductory text.
1) Speed is already one of the most emphasized design goals of the Linux kernel. If you have never read the Linux kernel source, then you're probably not aware of the numerous gcc-specific tricks and tangled code that is used to speed optimizations. Trust me. The kernel is as fast as it's going to get.
2) It is standardized between every incremental revision, as much as any driver model can be standardized. The major changes only come between minor and major revisions, such as 2.2 -> 2.3/2.4.
3) Whatever.
4) Nonsense. The kernel uses the user-level helper tasks for efficiency's sake. If you haven't studied the kernel module loading system, then you shouldn't really be talking about it. Standardization of config files is also impossible in many cases do to the differences between said devices.
5) Might be nice.
6) Okay, now this just shows total ignorance of how Linux and software/system interaction in general works. The kernel's treatment of threads is that they are equal to processes that share the same memory mapping structures. The Linux scheduler handles thread-switching quite admirably, and you will be hard-pressed to find any desktop OS scheduler that performs as well as Linux's. The major misconception here is in assuming that "pervasive multi-threading" is all the kernel's responsibility. That is all the responsibility of the user-level library and application code. The kernel schedules and relegates threads. It's the user-level code that responsible for taking advantage of the threading facilities available.
You seem to be bound up in the desktop world of "GUI == part of OS." In Linux, the GUI is a user-level application, as well it should be in the case of what they have available. God forbid anyone attempt to weld the Unseelie monstrosity that is X11 into the kernel. That would introduce bloat and instability into the entire system. This is why there aren't kernel-level SAMBA implementations, BTW. The responsiveness of the desktop interface is not the Linux kernel's fault. The fact is that QNX and BeOS both have very well written GUI layers. However, to claim that they are in general more responsive is a little bit of marketing/evangelism propoganda. The responsiveness of the Linux kernel is very, very nice on a process/thread level.
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
Flat text files are good for simpistic yes/no answers and for storing strings of domain names and such - but it's just linear expansion and there's no nature of child/parent and nesting.
Not at all. Mathematically, XML and ini file are probably equivalent with respect to the kinds of graphs they can represent, if you allow values to reference keys in other sections.
The main strength of XML is as a markup language, to combine content and meta data into a single data stream in an easily separable way. As a way of describing assigning bindings to parameters it is neither as simple as ini files nor as powerful as BNF grammars.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I agree, but with a caveat. The alternative you present is not what I'm suggesting, and it wouldn't be allowed to happen anyway. The idea here is just an extension of the odd-number/even-number idea we already have. There would always be exactly one official Linux, compared to which any forks have a somewhat inferior status. It's like after 2.4 we allow both 2.5red and 2.5blue to go ahead, with a promise that when the time comes to make 2.5 into 2.6 fair consideration will be given to basing 2.6 on 2.5blue instead of 2.5red.
Looked at another way, it's like Linus (used here for convenience as a personification of Linux authority) saying, "I don't believe in this enough to devote my own time and effort to it, but I recognize that I'm not infallible. I'm willing to let the community decide which they prefer, instead of branding anyone who disagrees with me as a renegade splinter group unworthy of attention or support." Wouldn't that be nice? What I'm suggesting is that the dictator - however benevolent he may be - allow elections to be held once in a while, with real candidates given a real opportunity to present their own views to the electorate. The Linux "brand" has become too important to be the exclusive property of one person, even Linus. Linus does other things besides Linux, and Linux can be done by other people besides Linus.
Slashdot - News for Herds. Stuff that Splatters.
Here's another point I forgot to mention. If, as in your example, A has better drivers and B has a better scheduler but code cannot be readily shared between the two, I'd say it might be because the code isn't modular enough. In an ideal world one could mix and match "best of breed" kernel components - even things like drivers and schedulers - in the same way that we already do for applications. There's nothing fundamentally different about kernels that precludes this, and if you'll look back at my original post you'll see that modularity was the very first item on my wish list. Maybe the idea of a fork will be more palatable when things have been made more modular...which IMO makes it all more important that modularity be improved.
Slashdot - News for Herds. Stuff that Splatters.
That seems like a reasonable outcome. Some of us - myself included in this example - might not like it, but if that's what "the people" want...
Whoa, wait a minute. I'm suggesting that the community be allowed to decide between work products, not between people. "Who's in charge" wouldn't be affected; it would still be the same not-quite-meritocracy it is now. Those same people would be making a promise to give other people's ideas a fair chance, not to give up their leadership positions.
In any case, even if our leadership were elected, if they started making bad technical decisions the same remedy would apply that always applies in a democracy: vote them out. The scenario you describe, of people getting "into power" and remaining there despite inferior technical decision-making, just seems impossible to me.
Yes, if possible. However, as you seem aware, sometimes it's not. Sometimes there really is just "this way" and "that way" and they're fundamentally incompatible. Furthermore, sometimes it's not clear even to the most highly informed people which will turn out better. All I'm saying is: do the experiment. Right now, when such an impasse is reached, only one option is pursued - the one that Linus and/or other senior developers happen to favor, for reasons that may or may not be entirely supportable from a technical standpoint. I think we have enough developers now that, in at least a few of the hardest cases, we can try both and see what happens, but I don't think that can work if one group is "real Linux" and the other group is "a bunch of renegades who are trying to destroy real Linux".
As I pointed out in an earlier post, one critical part of making this work is an agreement on both sides to share information about common problems and solutions. I would expect that, any time there's a fork, a "winner" would eventually be declared and the "loser" would then abandon the fork in favor of trying to apply lessons learned during the process to the new official Linux. Maybe that's too idealistic, maybe people are too stubborn and territorial and ego- or profit-driven to allow things to happen that way. *shrug* It's just an idea that I think deserves at least a moment's consideration, even if it's later rejected, and in general it doesn't seem to get considered at all.
Slashdot - News for Herds. Stuff that Splatters.
I thought that a somewhat-concrete example might help clarify what I'm suggesting.
Let's say that I, and a significant number of other folks, want to rework the Linux SCSI mid-layer using the CAM-based BSD code as a model. We'll call this group "red" in reference to 1917. The "white" group, which includes some individuals with more clout than any of the reds, also wants to rework the SCSI mid-layer but wants to reinvent the wheel and do it a whole new way unlike any other platform. In addition to the project-specific "core code" for each version, a certain number of tweaks would be necessary to common code to make the core code "fit". Here's what would happen now:
Now, here's how I think things would work with an approved fork.
Doesn't that just seem a whole lot better?
Slashdot - News for Herds. Stuff that Splatters.
Simply wrong. Read/write/execute gives eight combinations, and user/group/world only allows three to be expressed simultaneously, and expressiveness is further limited by the fact that most users can't add/delete/modify groups to suit their purposes. ACLs, by contrast, can be used to express all eight possibilities at once, and apply each to arbitrary sets of users.
Anyone who ever studied even one minute of logic can see that the two systems are not equivalent.
Slashdot - News for Herds. Stuff that Splatters.
I knew someone would say that. I don't strongly disagree, but I do disagree. Anyone capable of doing meaningful work knows of the *BSD option. If they have foregone that option, there's probably a reason. Most often it's because they're more familiar with Linux. It could also be because they want to address a perceived deficiency in Linux, and working on *BSD doesn't do that. Their idea might not even apply to *BSD. In any case, I think they should have that option.
In order for this to work, there has to be at least lukewarm support from the regular Linux cabal. For example, the following:
I don't think that's too much to ask. It's not like asking for the insiders to devote gobs of their own time to further a project they don't believe in. If the people involved can be mature enough to make and keep these kinds of promises, and let the community decide in a semi-democratic way which set of changes produced the best result[1], a fork could be a very good thing. On the other hand, if they decide to be territorial about it, if they decide to put their egos or their prospects for financial gain as full-time paid "Linux gurus" ahead of technical progress, then it could be really ugly. I could not recommend an "unsanctioned" fork; that would only hurt everyone. The only way a fork can be beneficial is if the cabal members can be persuaded of the benefits. Quite honestly, I don't think they're up to it, so a productive fork is an extremely remote possibility.
[1] Of course, the community that really matters is the community of distribution providers, who get to decide which version to use as the basis for what they provide, and in many cases they'd be "voting" for what their own members/employees happened to be involved in. It's hardly in Red Hat's interest, for example, to say that someone else's kernel mods worked out better than the ones they paid their own highly-touted employees to produce. This is hardly what I'd call an example of democracy in action, but it's at least a little bit closer than the current autocracy.
Slashdot - News for Herds. Stuff that Splatters.
I don't think that's necessarily true. At a certain point it's perfectly reasonable to say "too late, you lose, better luck next time" and yank the slow group's approved-fork status.
The problem I see with your proposal is that it doesn't solve the basic problem of placing unreasonable - and non-technical - barriers before people who want to try something different. In my example two posts ago of how things work now, the red team not only has to do their own original work but faces the formidable extra obstacle of tracking changes made by the white team. The white team, by contrast, is given carte blanche (heh) to proceed without worrying about the red team's changes, or even whether their own changes will adversely affect the red team's efforts. This is not a small issue. With all of the interpendencies in the kernel (see my comments on modularity or lack thereof), this makes it extremely difficult for red to keep up unless they have many more developers than white - and if they did have such a majority they'd be the white team.
This is actually very similar to a current political debate about winner-take-all vs. proportional representation. What we have now is very close to winner-take-all; those in the minority are effectively shut out of the process. Approved forks are like a loyal opposition; they give the dissenters at least some chance to get their point across. What's important is that we find some way to turn dissent and competition into productive forces. Are approved forks the best or only way to achieve that? Do they achieve it at all? Maybe; maybe not. What's certain is that continuing to let good ideas get "killed in committee" (this political analogy works better than I thought) is not healthy for Linux in the long term.
Slashdot - News for Herds. Stuff that Splatters.
the one thing that i believe linux should really be looking at improving substantially is user friendliness. especially with installing software. that was the one thing that made me so angry when i first tried using linux
The linux kernel is never going to be "user-friendly" territory. You're probably talking about distriubtion issues, which are beyond the scope of the discussion here.
-- Post No Gravy
The most important thing we need is a everthing becoming more modular.
Linux is already as modular as it needs to be for the moment. QNX and Be are fine OS's, but saying that their hardware installation procedures are without their own problems is just wishful thinking.
OS modularization is more-or-less a religious issue. Advocating more modularity in every aspect of the Linux kernel is to slide down the slippery slope of micro-kernel advocacy, and that way madness lies.
-- Post No Gravy
Sorry, I"m not going to try to convince you. You can simulate ACL's through users/groups/ownership/permissions just fine. The only other thing I'd do is remove the root restriction on ports 1024. On many Linux machines, root is no smarter than the other user of the machine. Ports 1024 are no more secure on these machines.
-russ
Don't piss off The Angry Economist
"Well, let's just say, 'if your VCR is still blinking 12:00,you don't want Linux'".
thats funny. i never set the clock on my vcr and linux is the onlything i use. i tried to set it once, but i couldnt find the etc directory so i had nowhere to put the ntp.conf file. : >(
john
-- john
Not really, the discussion is about the kernel and the OS. Although the installer is definitely tied to the distro, it would be nice if Linux had a singular installation system.
I think Linux needs to add Wizards and paperclips, if only for the sheer pleasure of doing stuff like this:
ps -ae | grep "*clip*" | kill -9
George
XML gains you i/o more structured than the stream, which is a Good Thing. However, that's not directly related to configuration files. What it /does/ do for configuration files it make it possible for there to be a single 'universal' configuration tool. The semantics of 'what does this mean' can be embedded the same way the kernel build system has its help section; that's not a problem. The configuration tool doesn't actually need to understand the semantics. Why XML? It's an open and well-supported standard. There's no need to invent something.
Regarding a standard format for this -- is there a reason we can't clone Apple's? Didn't they already solve this problem for OS X?
-_Quinn
Reality Maintenance Group, Silver City Construction Co., Ltd.
It seems to me the bloat ACLs add to the file systems, all the utilities that work with files, AND of course, the kernel need to be considered versus the functionalty that not a lot of people will ultimately need (if ACLS work smoothly everyone will use them, but it will be functionality that the current model does ok...) Are ACLS a fundamentally good idea?
I think a good question to be asked is "Is Linux/*BSD with ACLs still Unix?". My gut feeling is that it is not... In Unix, everything is supposed to be a file. Directories are just files that describe files. When ACLs are introduced, where are those lists going to be saved? In the directory (how)? In an entire shadow file system? As secret blocks with the file? Then whatever mechanism is used, it will certainly break ALL of the major file interchange tools (dump, tar, cpio) since they don't support ACLs. Poof, the same problem we have with idiot Macintosh files (namely resource forks) appears in *nix -- UGH! Fsck will be broken too. I, being an old person (at least in this business), don't like the idea that my new tars won't be in the same format of my old tars. I *do* read tapes from the 1970s. And yes, there will be 'compatibility switches' so one can move back and forth, but are these kludges really a good idea?
As a result, perhaps it is time for a fork in the road where the ACLers go their own way and the Unix people go another. Perhaps it is time now to re-assess where this is going. Is it time to build a new O/S that has B1 or B2 as it's goal?
I've worked on ACLed systems both in the pre-computers-are-cool days (IBM mainframes) and I've worked on them in the contemporary world (NT). I find the abstraction painful to deal with and the tools to deal with it nearly impossible to reliably use, especially in the hands of junior system administrators. One of the neat things about Unix is I can teach a new person about the filesystem (FFS for example) in an eligant way in about 3 hours to a level I've not a hope of doing with messes like NTFS or HFS+ no matter what amount of time.
Finally, I think it is also time to ask when is an operating system 'done'? I'm not talking about the continual addition and subtraction of devices and services to keep the O/S vibrant & alive, but new core functionality like changing the security abstraction or the concepts of processes and files. ACLs will change the security abstraction of Unix and introduce a new entire class of functionality along with an entire new class of problems... I think they don't fit well in the normal Unix way of doing things and so I think that this is one feature *nix should probably let go by.
nonononono....
The only place I can see XML being used, as far as a universal configuration file format, is only as a large central repository, with well-defined semantics...perhaps RDF or something.
Otherwise, for the majority of small programs, XML is cracking a nut with a jackhammer. Before we even talk of XML, we should talk of some standard flat file. Take the java.lang.Properties format for instance. Straightforward key=value pairs. No magic, no whitespace wierdness. Very simple. Applicable for probably 95% of general applications. Only when you start needing to introduce *structure* do you really want XML. Which leads me to think the most applicable place for XML as far as configuration files, would be a central XML settings registry which *all* applications read through some standard API (but were not allowed to directly manipulate). XML is not a panacea. I think the vast majority of programs could do just find with a *standardized* flat file format. The problem now is just that there are so *many* different flat file formats being used.
It's 10 PM. Do you know if you're un-American?
This article is about Linux (the popular OS kernel). You are talking about GNU/Linux, or some Linux based distribution.
Your suggestions should be aimed at the XFree developers who have nothing to do with Linux development.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
The difference between a database and an XML-centralized-parser system is pretty small. It feels like what you're arguing for is a registry. Personally, I think a registry is an excellent thing, Linus' opinions on the matter otherwise. But, I recognize the fear that as we move away from simple ASCII, the files will become too complex to edit by hand, and people will be at the mercy of the tool interfaces. And some people just don't like that. You're job is to convince them this is not something to fear.
First, make it work, then make it right, then make it fast, then, make it bloated!
If you're going to complain, you'll have to do better than that.
You seem to believe that Microsoft Products can automatically determine what network they're running in, the DNS servers, the gateway, and so forth, but it isn't true. In order for a windows client to autoconfigure, you need to have a DHCP (Dynamic Host Control Protocol) server on the network. Linux networking drivers can use DHCP, too, and have been able to do that for a couple of years.
snol also wrote:
While there is no reason to be afraid of compiling software, there also isn't any reason to compile software, not with any of the current distributions. I don't usually compile any of the bits of my system, and compiling isn't part of the basic installation process of any Linux distribution or commercial application of which I am aware. (FreeBSD is a different matter, but FreeBSD takes a whole different approach to things and it's not all that hard to type "make install".)
I can do nothing but sympathise with you on your failed installs, but maybe my sympathy is worth something. It usually takes me a couple of days to figure out the installation procedure for a new operating system whether it be Windows NT, FreeBSD, or yet another Linux distribution. While they all ask pretty much the same questions, the wording and context is different enough that the consequences of the choice may not be immediately apparent. I usually treat an install like a particularly easy-to-solve adventure game. If I don't get all the way through it the first time, I can figure out what choices to make different the second time. Or the third. Or...
snol also wrote:
Speaking as someone who has done his share of front-line Internet tech support, many people find the Windows "control panel" to be the height of confusing software. I'm glad you've learned to navigate it, but you did have to learn. It didn't "jump out at you" the first time. (Well, maybe it did, but that was unlikely. For most Windows Users, the Control Panel is definitely unfamiliar territory.)
Under Unix-like systems, most everything configuration-wise is under /etc. If looking at that is "digging through unfamiliar directories via the command prompt" then you need to become as familiar with it as you do with your Control Panel. Either that, or familiarize yourself with the mechanisms that you're given for easily manipulating those files. I wouldn't know what they are because I don't want to climb that particular learning curve (not after having climbed the much steeper one to learn about the whole /etc tree) but they're there and many people like them.
Of course, another option to take is the one you took: You can simply not run Linux until you've got a more compelling reason to make the effort. However, Linux and Windows are always going to be different, so those people who define "easy to use" as "works just like Windows" will forever complain about how hard Linux is to setup and use even though, for someone unfamiliar with either, the effort is actually comparable and has been for some time.
embedded: QNX, Beos
>>>>>>>>>>
You do realize that BeOS is a desktop OS and not an embedded one? BeIA is probably what you're referring to. In the embedded market, there are MANY other OSs besides QNX and BeOS. These two are probably best for stuff like handhelds or web pads, but you go into the automated machinery OSs and these two don't cut it.
workstation: w2k,
>>>>>>>>>
Huh, funny. NT4 kicks Win2K's ass all over the place on the workstation. If it fits right (ie its got the software you want), then BeOS also makes a great workstation OS. Linux also makes a pretty decent workstation OS that's getting better everyday.
small office server: w2k, novell, osX
>>>>>>>>>>
osx-server is totally unproven. Win2K is easy to admin, but Linux, FreeBSD or Novell are probably best here.
web server: *BSD, w2k
>>>>>>>>>>>>>>>
Agreed, but Linux can do this too.
realtime: Inferno, QNX
>>>>>>>>>>>
Who actually uses Inferno? QNX is good but there are a lot of other hard realtime OSs that are better depending on the use. In this catagory, the OS is so use dependant, that you can't classify any one OS as the best.
games: w2k (+aka "whistler")
>>>>>>>>
Bullshit. Win95 all the way. Win98 is slower and more unstable, Millenium is significantly slower, and Win2K's OpenGL support is crappy. If you're games run well in OpenGL, then NT4 kicks everything's ass as a game OS. When more games get ported to BeOS (and if the OpenGL is as good as the previews show it to be) then BeOS will also be competitive as a gaming OS.
A deep unwavering belief is a sure sign you're missing something...
1) Speed it up. The kernel already does a great job with speed, but don't trade speed for gee-wiz features that 1% of the population uses. That's what third party patches are for. Keep the standard kernel as general/lightweight as possible.
;)
2) Standardize the driver interface. Yea, it takes actual thinking to come up with a good interface and stick with it, but it would only have to hold between major version changes (a nice trade-off between a single driver interface forever) and you really shouldn't be changing the driver interface between 2.4.1 and 2.4.18 anyway.
3) Put hooks in to only allow KDE to run. Although methinks that's not going to happen anytime soon
4) Standardize configuration. modules.conf, moduels.rc and all of the config programs (iptables, ipchains, etc) are too much. Get rid of modeprobe, kerneld, etc, and have the kernel automatically load modules itself, maybe with some help from config files. BeOS can automatically load the correct drivers for its hardware and there is no reason Linux shouldn't be able to do the same. Finally, standardize the configuaration of kernel modules. All kernel modueles, from iptables to joystick drivers should be configured the same way, either through a strict hierarchy of config files, or through a standard program.
5) Replace OSS with ALSA and tie it to the standard configuaration mode discussed above. I know they're working on that, any idea when it will be finished?
6) Make it more thread rather than process oriented. Make it totally reentrant, and make it highly multi-threaded. As anyone whose used BeOS will tell you, "pervasive multi-threading" is far more than just a buzz-word. QNX, AtheOS, and BeOS are all highly multi-threaded and are three of the most responsive desktop OSs available. That's no coincidence.
A deep unwavering belief is a sure sign you're missing something...
The sysadmins need to get their heads out of their asses and learn something new? And if they aren't, they should probably be using Windows. How many times have you heard the argument, "Linux is different, users should learn how to use it!" The same thing should apply for sysadmins.
A deep unwavering belief is a sure sign you're missing something...
The registry isn't the thing that's bloated, its the apps that use the registry irresponsbily. The apps that leave dead wood lying around and write to wrong keys. The problem persists wheter or not that feature is in Linux.
A deep unwavering belief is a sure sign you're missing something...
Ignore reading the source code -- follow the kernel list discussions -- its about algorithms, not GCC optimisations.
- Michael T. Babcock (Yes, I blog)
As for the HURD model (which is also the design plan of Windows NT, btw), I believe Linux refers to micro kernels, message passing in particular as an excercise in "computer science masturbation" -- it feels good, but you don't get anything done.
... )
-- (Probably a quote of Linus Torvalds
- Michael T. Babcock (Yes, I blog)
Youre a troll, but I'll bite.
root doesn't log in. That's the point of the exercise! In an ACL based environment, all users [including administrators] log in with the permissions they need to get their work done, and nothing more. And no, you do not need to have full access to the system to administer it properly.
* Re: your graphics card. Many distributions now include TNT / GeForce / GeForce2 / Quadro drivers out of the box, and set up acceleration for them too. I know firsthand Mandrake 7.2 will set up 2D and 3D accleration for TNT2s and Voodoo3, and I believe GeForce shoudl do the same thing.
/conf [or /settings], unfortunately little innovation comes in the FHS due to a number of people complaining that since Unix does it a certain way, Linux should too. There's a difference between Unix philosphy and implementation. Lets follow the philisophy and come up with out own implementation. This is happening with things like devFS and anti-aliased X extensions, but should happen more. Configuration files warrant their own place the file heirarchy.
- You're right here. Conf files should be in
* DHCP should work fine on Linux. But you're right in that most Linux PPP tools [asides from Red Hat's excellent rp3] have poor defaults, requiring unnecessary scripting and extra data entry on behalf of poor users to connect to the same setup that 95% of ISPs use.
* Mandrake put all their software on their menus and provide a [control panel like] configuration tool on their desktop. More distributions should follow this habit, but most still don't even install software into application menus.
It's not off topic at all. You've just provided valid feedback about where Linux should go in the future. If I wasn't posting I'd mod you up.
I totally agree - let's keep things compatible and allow the improvemtns for those that need it. I think, as a rule, that in situations where rwxs compatibility isn't a concern [and if you coded it smartly, this would be the case], ACLs would be the preferable access control system.
The dangers of having someone log in as root to perform basic tasks [which goes against Unix philiosophy of giving users only the permission they need on the system] and the numbers of services which run as root [there's either soemthing wrong with rwxs, or the authors of quite a few Linux daemons, and I think the authors know what they're doing] would mean ACLs would probably been the default standard once compatibility issues had been ironed out.
In my opinion anyway.
I agree that Linux should most definitely support both rwxs and ACLs for quite some time, so to give those who prefer the existing system some time to .
:-)
But the specifics of NTs ACL implementation won't really be replicated on Linux, nor will the specifics of VMS implementation. NTs mix of ACL and share permissions is [although good security practice by gicing the user the least permission of the two] difficult to comprehend.
And I don't think ACLs would change Linux tradition of giving users limited default permissions. In fact, I'm quite sure they would do the opposite - most daemons and admoinistrators would definitely not use the root account for their day to day work, and their new accounts would have very little system permissions outside of their regular work. A very Unix like concept.
Performance issues could be overcome with some smart engineers. Remember, journalling filesystems are supposed to be slower than non-journalling, yet everything depends on the specifics of the implementation. Thus ReiserFS is faster than Ext2.
I'm afraid I pretty much completely disagree with the idea of "elections."
Imagine there's a very serious issue at hand; let's say whether or not to sacrifice limited-resource(ie: desktop) platform performance with the idea of improving near-unlimited-resource platform(ie: 100s of CPUs, terabytes of memory) performance.
Chances are, a large number of voters(I think they should be developers) would vote to keep good desktop performance; after all, that's what most of them will be programming for.
Next thing you know, someone is in charge for a year or two, making horrible technical decisions. Sure, they kept good desktop performance, but also initiated rewrites of major subsystems. They became over-zealous in their removal of cruft, and we thereby lose a lot of backward-compatibility(hardware-wise). You get the idea.
Elections are far too often based on a very few rather important issues, but the result is a net loss in quality. Issues that are very big(ie: Big Iron support) should be resolved through compromise(if a compromise is technically feasible), as opposed to "this way" or "that way".
I actually agree with your idea of a fork; but not with the concept of elections. There is far too much room for error.
Dave
'Round the firewall,
Out the modem,
Through the router,
Down the wire,
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
In short, Windows has a GUI display control panel, MacOS has a GUI display control panel, so why doesn't Linux have one yet? They've only had about five years to make one, so there's no excuse.
Shut up. Yeah, you heard me. Shut your bloody mouth before you learn the hard way that there's always someone willing to shut it for you.
What the hell do you mean by "there's no excuse"?!? Nobody had developed one yet(actually, there are several GUI XFree86 config tools, so that's not entirely true), because no-one has WANTED one. "Linux" meaning the whole complete operating system, including apps, is for the most part GIVEN to you. Stop sniveling, you dolt. If you want something, do it yourself, stop demanding that others do it for you.
Damn it, I hate this type of "newbie".
Dave
'Round the firewall,
Out the modem,
Through the router,
Down the wire,
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
I might be mistaken, but the "Big Iron" optimizations are available in the kernel under the BIGMEM options; but I might be mistaked.
Dave
'Round the firewall,
Out the modem,
Through the router,
Down the wire,
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
In many ways, linux is heading toward being the standard unix. Not it will be "king", but more and more unix's (or whatever) will start to look more like linux (on the outside at least). This will be for two reasons: 1. portability 2. Companies like IBM and HP have finally realized that they don't want to reinvent the wheel. Why bother creating new software/manuals/support/etc... when there is something that everybody knows, everybody supports, and they get a jump start because they have the source.
.NET.
As far as where linux-proper will go... it depends. Frankly, kde2 rocks. Sure, its not win2000 yet (grumble grumble, sorta impressed), but its showing stability, functionality, and for the first time INNOVATION! I keep showing coworkers and friends the useability features that have been integrated into KDE2 and they've become quite jealous.
Where should distro's go? Toward the desktop sure, but what really needs to happen? Apache + OpenLDAP + Linux/*BSD + kerberos + imap + ical + cvs + webdav + (add more good OS projects here). There is a TON of great OS software out there that CAN be integrated, it just hasn't been pre-integrated ala exchange and in the future,
I suppose I'm not too threatening, presently, but wait till I start Nautilus
The warship was running Windows NT (albeit customized). IIRC, the reason for the systems crash was that someone entered a 0 into an entry field in some user app, causing a division by 0, and bringing the whole bloody ship down. Having a ship dead in the water from that is kinda lame.
-- "Is this death or is this Ohio?"
DESCRIPTION
The Mozart threading model uses logic variables to create synchronization between threads. This can be viewed as automatic construction of dataflow dependency graphs, or as what logic programming calls "AND-parallelism". Either way, synchronization falls out of functional or relational dependency inherent in the semantics of the program rather than being an additional thing for the application programmer have to write and therefore possibly write wrong. Constraints may be added to logic variables consistent with prior constraints but they may not be deconstrained once successfully constrained.
Comparing Java to Mozart, a simple consumer-producer multithreaded application running within:
The same processor:
Java execution time 17.6 seconds
Mozart execution time 3.9 seconds
Java code 108 lines
Mozart code 28 lines
Distributed processors:
Java execution time 1 hour
Mozart execution time 8.0 seconds
Java code 220 lines
Mozart code 32 lines
(See ref 1.)
IMPLEMENTATION
Mozart's threading model has been implemented for other languages (see ref 2). Central to this model is Mozart's "computation space" construct. Computation spaces are heirarchical collections of threads and logic variables. Each thread and each logic variable belongs to exactly one computation space. When a logic variable is introduced that is "local" to a thread, it spawns a new computation space. "local" as used herein has the same scoping as the Perl "local" keyword: upward visibilty and downward invisibility. When a thread attempts to add a binding (constraint) on a logic variable that is inconsistent with prior bindings, the thread fails thus raising the associated exception. (See ref 3)
For simplicity of initial implementation, constraints could be limited to simple single-assignment dataflow variables and later expanded to numeric relations like >, < and != and might someday become as sophisticated as performing regular expression algebra to determine consistentcy of adding regular expression constraints to variables.
REFERENCES9 .htmlo de12.html#label65
(1) "An Example of Programming in Mozart versus Java" by Per Brand (http://www.sics.se/~perbrand/javaVSMozart/)
(2) "Efficient Logic Variables for Distributed Computing" by Haridi, Van Roy, Brand, Mehl, Scheidhauer and Smolka http://www.mozart-oz.org/papers/abstracts/TOPLAS9
(3) "Computation Spaces" from the Mozart documentation http://www.mozart-oz.org/documentation/tutorial/n
Seastead this.
My god, that story keeps changing and changing and the lies grow larger by the second. It was a very early copy of NT4, it was NOT the OS that failed. It NEVER BSODed at all, the database application failed.
It happened before W2K was a twinkle in Bill's eye.
I mean, I know you are afraid of how good W2K is but making this shit up THIS obviously lame is just, well... lame.
W2K is THE most stable OS I've ever used. Period.
Much like windows apps can store their configuration in the registry, but without the bloat/mess.
"Video bona proboque; deteriora sequor." -- Ovid
Confucious said that? Man, I've got to go read some more Confucious - he's a little more down-to-earth than I thought :)
LIDS is a big step in the right direction though. ACLs and Kernel capabilities let you work toward eliminating all those nasty SetUID programs that most of your system compromises arise from. Combine that with locking down of /bin, /sbin, /usr/bin, /usr/sbin and /etc so that even root can't touch them outside of single user mode and you'll have a nice tight system.
Then all we'll need is a way to stop and track DOS attacks over the net and life will be beautiful.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
How about compliance with Microsofts' .NET architecture?
KIDDING! Just kidding! Relax, put the baseball bat down!
hoser: Slashdot reader since 1987.
The most important thing we need is a everthing becoming more modular.
two different kinds of distro's. Server and Desktop. Absolute technical enhancements aside, you will have on one hand those that want to use linux as a server OS and those that want to get their hands dirty. For this group the current crop of tools and capabilities (with some added features) is/will be great. They don't mind editing configuration files manually, patching things and the like. .02
The other kind of distro will be a desktop distro. This distro may or may not have more or less horsepower but it will be easier to get around in. Specificly, it will also be much easier to use, configure and install software. apt-get and all that other stuff will be rolled into an easy to use gui client. linuxconf will grow up to include many more options such as real PRINTING configuration.
Like it or not, this is the future and here's why: companies like Redhat and other commercial entities know that while the hobbiest/server market is their bread and butter right now, the *real* untapped market, and thus the path to expanded sales/support revenue is the the desktop market. IMHO the real question is wether or not any of these companies have the resources/willpower to make it happen. If not, linux's growth will reach a certain percentage and level off while its feature set is surpassed by commercial (Winxx) offerings. At that point, non-technical publications coverage of Linux will dissapear and we will all slide into a quiet backwater. Hopefully this doesn't happen but that's my
I don't see any reason that ACLs couldn't be implemented as a kernel feature that could be enabled or disabled when building the kernel. Sure, the hooks would have to be built into various parts of the kernel and may cause a little speed penalty, but I think the performance hit would be tiny.
If we're going to implement an ACL system for Linux, then we might as well make it MACL (mandatory access control) rather than the NT implementation of discresionary access control.
"Linux would start forking" - it's getting a bit boring hearing these kind of unjustifiable claims.... Rgds, Sam
"Mary had a crypto key, she kept it in escrow, and everything that Mary said, the Feds were sure to know."
I've been using Unix since 1982, but my attempt to get Linux running on my machine (a mac G4) was a failure, and a very time-consuming one at that. I'd been assuming that this was just because support for non-Intel hardware was worse, so it was interesting to hear about snol's problems.
Look, I'm not afraid of "rm" and "ps." I was using vi before some of you were born. (Ow, that makes me feel old!) I even did some summer work as a systems programmer when I was in college. But personal-computer OSes have gotten a lot more complex since the days of CP/M. It's not realistic to expect everyone to be a kernel hacker and write their own device drivers.
--
Find free books.
Windows. Pay for hardware and Windows. Open box, thereby agreeing to a EULA that says you can't sell Windows. Plug in. Push power button. Buy MS Office, and install it with a GUI installer.
Linux. Pay for hardware and Windows. Open box, thereby agreeing to a EULA that says you can't sell Windows. Plug in. Push power button. Buy Linux distro. Erase Windows, and spend a weekend trying to get Linux to boot. If successful, go websurfing for free office software and a copy of DeCSS so you can use your DVD drive. If unsuccessful, reinstall Windows from recovery disk.
MacOS X. Pay for hardware and MacOS. Open box. Plug in. Push power button. Go websurfing for free office software. Use Unix.
OK, to be fair, the MacOS part really describes what you'll be able to do a year from now, not today.
--
Find free books.
Opera is on Beta-2 at the moment, that will fill that gap nicely.
the reason a vast majority of people use computers in the first place - IT'S BECAUSE OF THE INTERNET!
No, the Internet is a small minority reason people use computers. The vast majority use them to do work, and the majority of them are using Word, Excel, and Powerpoint.
It is true that email is very important for the transport of the documents they produce, but I don't think that's what you meant by using the internet.
No doubt most Linux users will agree it only makes sence to find practical and revolutionary ways to merge Linux with the web.
I doubt it. The web is cute and all that but if it disapeared overnight I wouldn't miss it. If the net disapeared I would miss it - email is very useful.
I use my computer for work which is imporant to me, none of which I need the web for.
Outside of website-based companies the web has nothing important to offer. I'm counting fun as "not important" here.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
That's your loss :- free and crap is still crap and there's no way Moz is going to stop being crap this side of 2002.
Of course people are buying computers to web surf and chat endlessly on irc, among countless other reasons.
I assume by "people" you mean "people like me". Walk into any office in the world and look at the number of people using irc. Since there are more computers being used in offices than in homes that pretty well knackers your argument.
That intensely stupid statement needs no rebutal.
So you're saying that the web (not the net) is such a useful part of your life that you would find it hard to live without? What the hell do you use it for that's so fantastic? I'd love to know what I'm missing; after using it for about four years I find that I'm visiting about five sites on a regular basis, although one of those is Google and I use that to try to find out specific things like why pppd sometimes refuses to hang up. "Surfing" the web is just a way to get real bored real quick.
computer use and administration is moving from delivering packaged software that has to be installed and deployed to delivering it as a web-based service
Microsoft and the other dinosaurs are moving that way, sure. But they're doing it because they see it as the only way to fight off the threat of the net. They need a way to stop their software becoming free (in both senses) and are trying to move to this model as a form of lock-in. I don't need it, you don't need it, and Linux sure as hell doen't need it.
I don't actually have anything against dinosaurs, I just used that as an analogy.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Forget POSIX. Focus more on all the little bugs distros are introducing that give root permissions to processes that shouldn't need them. Think RedHat's printer bug from a while back...
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
ACLs (Access Control Lists) are handled either by an operating system, or by an enterprise level application, ie Lotus Notes and Lotus Domino Servers. They provide to control freaks a near-total grip over who can access which bits of data. Granted, that much control can lead to headaches, since every IT department in the enterprise needs a good sense of what they're doing in order to avoid getting locked out of the data they need for doing their jobs.
A year or two ago, The Salvation Army, whose International Headquarters is in London, made an enterprise level decision to deploy Lotus Notes as their mail-and-database vehicle throughout every Territory on the planet. It's amazing, everything from directories to hymn books (containing nifty little MIDI accompaniments) can be replicated across the globe, with record by record synchronization.
When Notes Domino is running, even ROOT (NT's "Administrator" account) cannot violate sharing on these files. So while Lotus Notes does run on Linux, it would be more secure if Linux ran POSIX compliant ACLs on its own.The complexity of sendmail configuration arises from the semantics of what the config does, not its syntax.
Mod this parent up!
This is why XML would be meaningless (as the subject-line indicates). Moving to XML increases the complexity of the file format (from an admin perspective), but does nothing to reduce the complexity of the file contents (i.e., semantics). sendmail.conf written in XML would be just as incomprehensible to someone unfamiliar with it as it would be in its current format.
A. This strikes me as complaining the windows 3.1 does not support your cool new card. It does not, you need to upgrade to Win95 or maybe even win98. It's the same deal with Xfree. Rather than complaining that Xfree does not support why don't you complain that the manufacturer does not provide drivers for his card? Or join the effort to get the next release of your favorite distro out the door with the newest X?
B. Do you know where the config files are in windows? Do you ALWAYS edit the registry to change things? their are gui's in linux as well if you install them. Linuxconf(no flames please) as well as many others abstract you from the config files. Xconfigurator? As to DNS I am not sure of your problem. Window's can not "find" your DNS without some info. If you don't have a DHCP server on the network you need to know that info yourself under both OS's. As to finding such in PPP I agree, It's to the point that the developers can assume a standard PPP and fill in some of the info automatically. Just leave Slip and otheres as an option.
C. Can't help you there. If your afraid of "install" in windows your SOL as well. In package managed system's "redhat/rpm,debian/apt" you never have to compile. and if you want to you can compile from source(rpm. not so familiar with debian)
D. Many distroes have this. Once again Linux conf. there is a whole directory in X for redhat based systems. Debien has this as well now AFAIK.
That said I agree that linux has it's problems. there are often to many options to the user. their is not enought vendor support even in terms of opening their hardware. Their is also some badpublicity about Linux. Users expect it to be a "better windows" that is totally free. It is not. it is another operating system with it's own quirks and streanghts and weaknesses. Their is a cost involved in setting up a linux box. It's the learning curve. For some of us we have paid it once and futer installs are cheap. For others they still must learn. Have you every watched a long term mac user try to learn windows? To find the controle panels and use them. to figure out hardware installs? It is informative. Mac's have excellent userinterfaces and hardware compatability. To a mac user windows is complicated and more work than it's woth. draw your own parrallells.
this article might give some insight
As you mentioned ReiserFS is quick with small files, which pretty much is most web content.
Also just look on the ReiserFS main page look at the middle logo "Squid cache optimization sponsored by ThresholdNetworks" I'm absolutely no expert on file system concepts so don't take me too seriously.
"Mommy, mommy! The garbage man is here!" "Well, tell him we don't want any!" -- Groucho Marx
JFS will appear to save you time after a crash, but you will more than pay for that in extra time spent while doing each and every disk operation. If your production machine dies once every few months, you will be spending a total of days or weeks in wasted computer time on JFS operations, compared to a few minutes of running fsck at boot time. And with all that, JFS still doesn't guarantee that your data is intact.
And, again, the journalling only recovers file system structure; it makes no guarantees about your file system contents.
However even if some or another JFS becomes the standard with Linux that doesn't mean you have to use it.
One of the big attractions of Linux is that it's easy to install. If distributions start standardizing on some form of JFS, everybody will have to deal with it. Even if I have the wherewithal not to configure my systems to use it, other people will be doing it. They'll be complaining about lousy performance and unexpectedly lost data, putting Linux in a bad light.
And stating you dropped AIX for Linux is quite ridicolous because the two don't really use the same hardware.
What does using the same hardware have to do with that? Of course, I started using PC hardware and retiring the PPC-based machines. Some of us really do use Linux for real-world applications and have a choice of hardware, you know.
It runs wine better so I can get to my real apps...
I would have to say that the best place for improvement is user friendliness. Until Linux can overcome this issue, it will always remain a niche OS. Most poeple can barely turn on their computer let alone be able to decipher the arcane commands of the unix world. It would be nice if Apple would open source the entire Mac OS X, but I don't think that will happen. I know Linux was never designed to be easy to use, and it probably never will be, but if windows is going to be dethroned, I think there needs to be significant improvements in this area.
Excuse me? Most people use CVS precisely because it offers control over large projects.
So some evil hax0r from Microsoft can't go and make it mutate like their ads in germany clame that linux will do.
You dont know what CVS is, do you?
Besides that, The decision is up to Linus, If he wants to move it into CVS, thats his choice, but I think it would be a bad idea.
Version control is not a bad idea. Linus is a bad idea. Version control is sound engineering practice. Patches are to version control as the abacus is to a scientific, plotting calculator. End of story.
Please read Eric Raymond's extremely accurate assesment of Linus' formal engineering skills. As good as he is, Linus is retarding Linux's development. And it is starting to show, W2K or no W2K. The Linux development model is complete bullshit and needs - desperately needs - to move to the BSD model. This benevolent dictator mythology has got to go.
The days of "hacking" an OS are over and the sooner we bid them good riddance, the better.
--
--
Eat right, exercise regularly, die anyway.
so if I'm writing Joeblowedit and I check my xml based config file I've *still* got to do some sanity checking.
Yes, for complex configuration files that is so. Hell, always get a second opinion of your data, check the sanity of all input regardless of its source or complexity.
writing part of a config parser is harder than writing a full parser.......
Well, not in this case. You simply traverse a tree and sanity check interesting nodes. No parsing.
It can be done (quite easily with small files, but your talking a "Windows Registry" like situation)
No one is advocating a Windows Registry situation. We're saying
/etc/xml.d/app1/conf.xml
/etc/xml.d/app2/conf.xml
The vast majority of those xml files will be dead simple, without associated DTDs. Some will be more complex but hardly more complex than sendmail.conf or named.conf. I mean, come on. The XML spec, grammar and examples, is a single document 1/10th the size of the page you are reading. Sendmail.conf requires the bat book, in reality bible.
Also, a curses based xml editor can be very small - as small as vi, easily. Such an editor would obviate the need for any xml knowledge.
Vast changes to programs required,
Yep. But its a given that more and more new code will use an xml parser. Windows didnt have a problem when it moved to the registry and an xml "registry" for linux is a much saner, much more attractive model for developers. It'll happen sooner rather than later.
--
--
Eat right, exercise regularly, die anyway.
I really like this idea. All the software I write nowadays uses XML for configuration. However, there are a few problems:
(1) This is a distribution and userland issue, not a kernel (Linux proper) issue. There's a lot of developers in userland and you cant mandate their whosale migration to XML anymore than you can herd cats.
This is where the Windows registry is superior to
(2) Its often _much_ easier to bang out a customized config file parser than it is to write something to interpret the output of an xml parser (I use the expat streaming parser because tree parsers are comparatively much bigger and slower. YMMV.) So while you've standardized on a config file format, you _still_ have to write functions to interpret it. There are config files and then there are CONFIG files, if you know what I mean.
In conclusion, XML is a good thing, but not necessarily sliced bread for _developers_. In order to get programmers to adopt it for their apps, Linux will need to offer some sort of registry api based on XML. Not a difficult thing to do but obviously something that will be extremely useful.
host +
|
+ user1 +
| |
| app1 +
| |
| foo bar parameter
| |
| etc, etc
|
sendmail, etc, etc
This kind of structure can quickly become large, complex and slow to navigate ("windows is checking installed software," anyone?) so its probably a good idea to have a registry daemon start on boot.
The windows registry of course contains a lot more than config data for userland programs. I'm not as sure that that's such a good idea,
--
--
Eat right, exercise regularly, die anyway.
# this is a comment
keyword=setting
Because most apps arent helloworld.c. Most apps have nested, tree like structures for preserving data and options between invocations. Because an XML standard is just that, a standard that can be interchanged between distributions, can be displayed on a web browser with suitable formatting, the list is as endless as the imagination.
Certainly you can do all this with your proposed format, but why on earth would you want to? No one else with a clue is.
--
--
Eat right, exercise regularly, die anyway.
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.
"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
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