I've seen much bigger projects that were easier to grok and maintain.
Bully for you. What were they? Do tell.
If modularity is merely madness then one has to be a certified raving lunatic to understand rhyme and reason in the current Linux source.
No, I wrote that the maniacal pursuit of modularity above all else is "the way to madness". There's this amazing thing call "reading for content", you know.
'Where do you think Linux [the OS, as well as the kernel] will head in the future?'
Sounds to me like it's a valid discussion from the quesiton!
Talking about the kernel and it's associated structures is one thing; flying off into tangets about distributions [Your distro sux!] is another. That's what I was trying to avoid.
IMHO, there really isn't a canonical "Linux OS" anyway. There's the kernel, and lots of flavours and distributions. That's part of the attraction of Linux for me!
>Well, for a start you're introducing an
>irrelevant XFree issue into a Linux discussion
Topical? Yes. Read the blurb at the top: Linux [the OS, as well as the kernel]
Well, I'd disagree with that, as IMHO X cannot be considered part of the OS proper, but of course YMMV.
I would have thought that a true "DPI-on-the-fly" system would have needed something like Display Postscript - surely we're just talking plain ol' resolution changing here?
And yes, I just remembered that Windose only ever needed to be rebooted if you changed the default font size for some reason.
Easy - Linus is Uncovinced. Once again, check out Kernel-Traffic for the details. Basically, it's the old user-space versus kernel-space argument, with lots of good arguments from either side.
Maybe I'm missing something. Anyone here want to try and convince me?
They allow much finer grained access control than the tradition user/group/permission model. They're definitely a "how did I get along without this" kind of feature.
Here's a fairly old and clunky URL that may be of interest - I'm sure others can come up with something more persuasive!
Also, it would be nice to be able to adjust the resolution of X while actually in X. When you tweak with the XF86Config in vim and then try to start X, only to have it terminate becauseit doen't like one line, it just becomes so exasperating.
Well, for a start you're introducing an irrelevant XFree issue into a Linux discussion, but I can only assume you knew that. Whee.
The feature you're looking for is in XFree86 4.0, with it's Magical Monitor Detection support (the correct acronym escapes me for the moment). X can already change resolutions on the fly (ctl-alt-minus and ctl-alt-plus), so it really falls back to how clever the desktop can be.
If GNOME or KDE or whoever manage to get that happening, then the non-Windows tribe can then claim that *nix can do on-the-fly resolution changes without having to restart the OS. Note that I've no idea if Windows 2000 or ME can do this.
But enough of that diversion - we return you to your regularly scheduled kernel wishlist.
It would be nice to have in 2.5 a kqueue/kevent interface similar to FreeBSD 4.x Maybe something like Schedular Activations
There's been some discussion along these lines in Kernel Traffic that might be of interest. I'm no kernel hacker, but it's a fine way to expand the frontiers of my ignorance!
So my computer science texts say, but experience seems to suggest that this may not neccesarily be written in words of fire upon the firmament by the Creator.
For the most part I agree with you. However, I think the problem lies in that the search for algorithmic and procedural elegance can become the tail that wags the dog, in terms of kernel design at least.
In other words, don't sweat the small stuff. More modularization will occur in 2.5 for the 2.6 series, I'm sure, but only when and where appropriate. The right tool for the right job after all - isn't that the Unix way?
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.
Stop using flat files for.conf, Use XML as standard configuration format. This includes the make tools, lilo, and the rc.d as well.
A great idea, and just the sort of thing XML is good for. However, the sheer weight of years of development and deployment of tools with there own config quirks makes this a "ten years time" kind of idea. Think bind &c.
Same thing with the current directory hierarchy as is stands.
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.
I had some problems installing KDE 2.0 over freshly installed RedHat 7.0. It seems that the packages are missing the required library libmng.so.0, and KDE won't start without it!
They're in the latest rawhide, and install fine.
It's a pity about this, though:
Oct 24 13:22:16 gladys PAM_unix[963]: (system-auth) session opened for user robk by (uid=0)
Oct 24 13:22:18 gladys PAM_unix[963]: (system-auth) session closed for user robk
Oct 24 13:22:18 gladys gdm[963]: gdm_auth_user_remove:/home/robk is not owned by uid 0.
Oct 24 13:22:18 gladys gdm[963]: gdm_auth_user_remove: Ignoring suspiciously looking cookie file/home/robk/.Xauthority
Optus@home in Australia reccomends the use of firewalls. It's all there in the startup docs.
The installing tech also suggested that we turn off (not power-cycle) the modem when not in use, killing the link.
The KDE 2.0 RPMS from the main site crash in gdm, but I can use stuff like konqueror in Gnome. In fact, I'm using it now and it looks pretty good. It still doesn't do a:hover { text-decoration: underline; } yet - quel horror!
The internet is a big scary place, and it behooves the prudent to do the basics - for example, install a firewall.
@home can't do all your homework for you - if you're connected full time to the net, then you have to take responsibility for that.
Slashdot Mirror
I'll consider Linux seriously again only when there's a kernel fork and a democratic organization of peer review behind it.
It's all GPL, genius. Knock yerself out!
I've seen much bigger projects that were easier to grok and maintain.
Bully for you. What were they? Do tell.
If modularity is merely madness then one has to be a certified raving lunatic to understand rhyme and reason in the current Linux source.
No, I wrote that the maniacal pursuit of modularity above all else is "the way to madness". There's this amazing thing call "reading for content", you know.
'Where do you think Linux [the OS, as well as the kernel] will head in the future?'
Sounds to me like it's a valid discussion from the quesiton!
Talking about the kernel and it's associated structures is one thing; flying off into tangets about distributions [Your distro sux!] is another. That's what I was trying to avoid.
IMHO, there really isn't a canonical "Linux OS" anyway. There's the kernel, and lots of flavours and distributions. That's part of the attraction of Linux for me!
Oh, wait, you said Linus was unconvinced
About the implemntation, not the idea proper. That much was self-evident, but you'd rather shit-stir. Dull.
Good to see Linux move beyond the festering corpse that is 1970s UNIX.
Flamebait, and clueless flamebait at that.
Keep it up, boys, I hear the next version of bash will be so advanced that it will test against kernel 2.6 in its Makefile.
Is there a story behind this?
>Well, for a start you're introducing an
>irrelevant XFree issue into a Linux discussion
Topical? Yes. Read the blurb at the top: Linux [the OS, as well as the kernel]
Well, I'd disagree with that, as IMHO X cannot be considered part of the OS proper, but of course YMMV.
I would have thought that a true "DPI-on-the-fly" system would have needed something like Display Postscript - surely we're just talking plain ol' resolution changing here?
And yes, I just remembered that Windose only ever needed to be rebooted if you changed the default font size for some reason.
BTW, is there a roadmap for XFree anywhere?
Easy - Linus is Uncovinced. Once again, check out Kernel-Traffic for the details. Basically, it's the old user-space versus kernel-space argument, with lots of good arguments from either side.
[regarding ACL's - threat or menace]
Maybe I'm missing something. Anyone here want to try and convince me?
They allow much finer grained access control than the tradition user/group/permission model. They're definitely a "how did I get along without this" kind of feature.
Here's a fairly old and clunky URL that may be of interest - I'm sure others can come up with something more persuasive!
RATIONALE FOR SELECTING ACCESS CONTROL LIST
FEATURES FOR THE UNIX SYSTEM
Also, it would be nice to be able to adjust the resolution of X while actually in X. When you tweak with the XF86Config in vim and then try to start X, only to have it terminate becauseit doen't like one line, it just becomes so exasperating.
Well, for a start you're introducing an irrelevant XFree issue into a Linux discussion, but I can only assume you knew that. Whee.
The feature you're looking for is in XFree86 4.0, with it's Magical Monitor Detection support (the correct acronym escapes me for the moment). X can already change resolutions on the fly (ctl-alt-minus and ctl-alt-plus), so it really falls back to how clever the desktop can be.
If GNOME or KDE or whoever manage to get that happening, then the non-Windows tribe can then claim that *nix can do on-the-fly resolution changes without having to restart the OS. Note that I've no idea if Windows 2000 or ME can do this.
But enough of that diversion - we return you to your regularly scheduled kernel wishlist.
It would be nice to have in 2.5 a kqueue/kevent interface similar to FreeBSD 4.x Maybe something like Schedular Activations
There's been some discussion along these lines in Kernel Traffic that might be of interest. I'm no kernel hacker, but it's a fine way to expand the frontiers of my ignorance!
A modular solution is always an elegant solution.
So my computer science texts say, but experience seems to suggest that this may not neccesarily be written in words of fire upon the firmament by the Creator.
For the most part I agree with you. However, I think the problem lies in that the search for algorithmic and procedural elegance can become the tail that wags the dog, in terms of kernel design at least.
In other words, don't sweat the small stuff. More modularization will occur in 2.5 for the 2.6 series, I'm sure, but only when and where appropriate. The right tool for the right job after all - isn't that the Unix way?
Be pragmatic about dogma, that's what I reckon.
Serious question - what does this have to do with anything?
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.
Stop using flat files for .conf, Use XML as standard configuration format. This includes the make tools, lilo, and the rc.d as well.
A great idea, and just the sort of thing XML is good for. However, the sheer weight of years of development and deployment of tools with there own config quirks makes this a "ten years time" kind of idea. Think bind &c.
Same thing with the current directory hierarchy as is stands.
Not to be rude, but is there any reason there's been so many Aussie stories on Slashdot as of late.
Not to be rude, but is there any reason there's been so many US-only stories on Slashdot as of the past three years?
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.
As root, edit the file /etc/sysconfig/desktop to read KDE instead of GNOME, to use KDM.
What if I prefer gdm? Am I then stuck?
These are available in the latest Rawhide.
I had some problems installing KDE 2.0 over freshly installed RedHat 7.0. It seems that the packages are missing the required library libmng.so.0, and KDE won't start without it!
/home/robk is not owned by uid 0.
/home/robk/.Xauthority
They're in the latest rawhide, and install fine.
It's a pity about this, though:
Oct 24 13:22:16 gladys PAM_unix[963]: (system-auth) session opened for user robk by (uid=0)
Oct 24 13:22:18 gladys PAM_unix[963]: (system-auth) session closed for user robk
Oct 24 13:22:18 gladys gdm[963]: gdm_auth_user_remove:
Oct 24 13:22:18 gladys gdm[963]: gdm_auth_user_remove: Ignoring suspiciously looking cookie file
Optus@home in Australia reccomends the use of firewalls. It's all there in the startup docs.
The installing tech also suggested that we turn off (not power-cycle) the modem when not in use, killing the link.
Is it network-transparent?
The KDE 2.0 RPMS from the main site crash in gdm, but I can use stuff like konqueror in Gnome. In fact, I'm using it now and it looks pretty good. It still doesn't do a:hover { text-decoration: underline; } yet - quel horror!
The internet is a big scary place, and it behooves the prudent to do the basics - for example, install a firewall. @home can't do all your homework for you - if you're connected full time to the net, then you have to take responsibility for that.
I could have sworn so, but then again I get brain-fade occasionally just like anybody else.
Yep! All the time.
rpm -ivh something.src.rpm
hack hack hack the specfile
rpm -ba something.spec
Whee! Just like tarballs, but with sprinkles!
Bugger! I had a closing anchor tag in there when I pressed submit - sorry people.