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?"
Alot of the gripes here are in no way releated to Linux (the kernel, as the original post had intended) but to various software packages, configuration, etc. For instance, several folks mentioned general configuration enhancements (esp. to X) such as a control-panel type app. These enhancements are in no way related to the kernel, but to the respective package (ie. X). A resolution control panel, for example, would not be implemented into the kernel since this would be a compenet of XF86, Gnome, KDE, etc. I think there is a misunderstaning in what "Linux" actually is. When you purchase a distro, you are receiving a UNIX-linke OS with the Linux *kernel*. This argument has been made time and time again, but the distinction still is not clear, even to some of the /. crowd.
Although the kernel is by no way perfect, most of the enhancements mentioned above are not kernel material. These convieniences are the responsibility of people who produce the various software components that comprise the distribution. Alot of this functionality is being addressed by projects such as KDE and Helix-Code, the latter is working on a "generic" system configuration plug-in for the Gnome Control Center that should replace utilities such as Linux Conf and YaST.
Try to support a large user base without ACL's and you'll probably start seeing the point. In general you want to provide fine-grained control over who has what permissions on files. The old user/group mechanism can be adapted to cover most cases, but with work. You end up creating tons of mini groups so that you can exclude this person or that person, or include just one person in another group, which basically mirrors what you would do with ACLs, but with ACLs it would be much cleaner and easier to maintain. It is my firm opinion that the user/group functionality of Unix is, like 90% of Unix functionality, outdated. This is coming from a strong Unix supporter. Just because Unix is good does not mean that we can't or ought not to improve it. So many Unix traditions and technologies are from a time when computers and their use was so much different than it is now. Let's stop resisting improvement and change, and start accepting suggestions for things, such as ACLs, which, although different from what we might be used to, are really interesting and valuable things.
As I look around, I am very dissapointed at all these posts. Why? Because when I saw the topic on the front page I thought to myself 'ooh, this will produce some interesting, exotic posts about what GNU/linux will be like in 10 or 20 years'. All the posts I've read are instead "add this feature!" "blah don't add this feature". This is pointless, short sighted and boring. I'll give it a shot though. I see linux slowly expanding in all directions as it does now for the next few years.. Then at somepoint, linux will take off in the desktop market. The kernel will have several popular forks although Linus will be doing his bit full time. By that time however Microsoft will have found a way to hook customers into its .NET2 service, which won't care whether the client is a linux desktop or whatever. Blah, I need sleep and caffeine so someone else should give this a shot. What is GNU/Linux going to be like in 10 years? Will it be much the same as today or completely unrecognizable?
There's no point arguing about stability (it varies from computer to computer and install to install), so I'll just say that Win2K is the most stable OS I've ever used.
Yup, I've found W2K (+apps.) to be better than Linux (+apps.). In fact, I no longer keep a Linux partition around anymore. I'll try it again when 2.4 is offically out, just to see if anything cool has been added.
The easiest way to think of the 'code' option is like extrans, but with the <tt> html option set so that it in displays fixed-width font. It's useful for mirroring DeCSS on Slashdot, but not for much else.
Ok a bit of info here..
/etc/TextBasedConfigFile is a hell of a lot easier than decyphering an XML file at 2 A.M.
I *have* used XML (actually I'm a bit of a RSS fan).... your idea on the surface has some good merits, but please, think it through.... consider this...
1. the XML parser can, and will validate most syntatical and grammerical errors, but it *cannot* check invalid values (unless you use DTDs to check, and that would mean a change for that every single time a allowable value changed), so if I'm writing Joeblowedit and I check my xml based config file I've *still* got to do some sanity checking. writing part of a config parser is harder than writing a full parser.......
2. system crashes, you bring it up in single user mode, with no services running a need to fix some braindead value in a config file, whatcha gonna edit it with? vi? cool....now understand what and where you need to change. It can be done (quite easily with small files, but your talking a "Windows Registry" like situation). reading my
3. Vast changes to programs required, I'm quite impressed you've moved much of your config's to XML, but I'd have to ask...WHY? Does the average Programmer or System Administrator have problems understanding the syntatical rules of his/her postfix/sendmail/XF86config/hosts file? Is it really that hard to understand a simple text based file?
I'm not sure why anyone would want ACLs.
Handling users/groups/ownership/permissions seems much cleaner and more maintainable under Unix than NT, for instance. ACLs just seem like overkill. If Linux had them, I can't see them becoming the normal mechanism for this sort of thing.
Maybe I'm missing something. Anyone here want to try and convince me?
-- Mike Greaves
/*
REPEAT: The question is what does the future hold for linux, not Wolenczak's impression of W2K. W2K works very
well with or without Wolenczak, thank you very much. Linux doesnt. What are we going to do about it?
*/
OK, I can't comment at all on W2K since I haven't even touched it (nor do I plan to unless paid to do so.) However, I'm wondering what you mean by the statement "Linux doesn't (work). What are we going to do about it?"
Huh? I'm sending this from Netscape Communicator, which is running on my Linux box right now. Obviously, Linux works. Could you be more specific?
Stating on Slashdot that I like cheese since 1997.
You know, the reason I started reading Slashdot (and I found out about it, well, a couple of weeks after it started) was because it had a Linux bias. Well, what's go great about that? Well, what was so great about it was that, other than peoples' home pages and Linux Journal, most media seemed to be sucking up to Microsoft. It was refreshing to see someone willing to run a site devoted to Not Microsoft and Not Macintosh.
/. has been overrun by Microsoft whores.
Frankly, I really don't understand why
Stating on Slashdot that I like cheese since 1997.
And you would get an Insightful from me if I had moderator points. Well done. =)
Stating on Slashdot that I like cheese since 1997.
Hrm, obviously you've never had to do an install of Windows by hand.
Stating on Slashdot that I like cheese since 1997.
* A distribution mechanism for distributing only the portion of the kernel tree that the user is interested in (i.e., no sun code, no drivers for things I don't have, etc; I can get them later if I want them later)
* A really good way to move functionality out of kernel space without making it non-kernel-like
* Modularity; not enough to prevent principled change of interfaces (e.g., a few which need badly need it each major development release), but enough to prevent constant minor changes due to lack of defined interfaces
* The right primatives for an efficient implementation of POSIX threads
* Video drivers good enough that the XFree86 people don't duplicate them
I think the current situation of a Linus-blessed official version with a ton of people's patches available is possibly better than an actual fork; it lets the alternatives acquire the benefits of new versions for a limited amount of updating work, and thus you see competition on which patches get into distributions and into the main kernel rather than competition between "Linux with Performance Monitoring" and "Linux with Journaling Filesystems" and so on.
The Linux model of having a bunch of stuff out there competing does a better job of getting the winners into widespread use than a system where one version may (e.g.) have better drivers but a worse scheduler than another version, because they forked and can no longer just take each other's code when one of them is clearly better.
I think a good set of specified interfaces among parts would make it easier to maintain patches, and thus easier to have patches compete on thier merits; patches which don't depend on any of the interfaces which are changing in a particular release won't have to be updated.
One problem I see with this is that it means that
both branches have to be ready at the same time in order to make the descision. Neither one has any advantage to being done before the other, so neither will move to stablize. Even if the call to become stable comes from on high, it will be more difficult to synchronize the schedules of the two portions.
The other is that it makes the process of making a stable version harder-- the official version of each part has to be chosen, after everything is working.
I think a better way of handling alternative versions is to have the official kernel distribution mechanism let you get patched versions:
in addition to (my earlier wish-list item) being able to ask for a kernel source tree without those parts you don't want (drivers for hardware you don't have, filesystem you don't want, platforms you're not on), you should be able to get it with your choice of patches. The patches would be maintained by whoever wrote them, and essentially any patch that applied would be distributed, assuming the patch maintainer had blessed it for the kernel version you were getting. Your standard config tool would keep track of the patches you were using and could get a new version with the same patches.
That way patch versions would be on a somewhat more equal footing with the official version. Furthermore, there would be less pressure to bless the white code with official status from the beginning, since it would still be easy to find. So the default would be to keep the old SCSI code, with both red and white trying to beat an easy target, and both having to deal with modifications to the interface from other sources.
I've used versions of Solaris, IRIX, and HP/UX :) Anyhow, you can expect the ACLs to be
..)
with acl support, and they all still feel very
Unixy
stored in the filesystem, just like permissions,
symlinks, and all that other stuff is. Filesystems
change... maybe WRT formats, we'll just have it
all handled by moving to a new filesystem. People
using other Unixes are used to having different
dump commands. Not unlike fsck (e2fsck, efsck,
In any case, ACL support won't be a disaster,
and the other Unixes are evidence that it can be
done well.
For every problem, there is at least one solution that is simple, neat, and wrong.
> Stop using flat files for .conf, Use XML as standard configuration format.
Hm. How are you going to store the XML if not in a flat file?
It would be nice to have in 2.5 a kqueue/kevent interface similar to FreeBSD 4.x Maybe something like Schedular Activations
> Please read Eric Raymond's extremely accurate assesment of Linus' formal engineering skills. As good as he is, Linus is retarding Linux's development.
Yes, you're right. So let's all use the Hurd. Debian has made a pretty usable distribution out of it.
xer.xes -- 4181
That's the first time I hear about that. Could you elaborate a little? I do know that Reiserfs works really well with small files, is that what you are talking about?
___
___
If you think big enough, you'll never have to do it.
good point. One nitpick though -- execute permissions should never be enabled by default. Can you say ILOVEYOU?
___
___
If you think big enough, you'll never have to do it.
"Anything that says GNOME or has a K prepended onto it's name, I avoid like the plague."
Like a "Kernel"???
Lol.
And if you don't like dselect, use Stormpkg from
Storm Linux... It's really well done (moreso than
gnome-apt)
Patrix.
I don't see what POSIX capabilities has to do with this. Perhaps you can enlighten me?
Back to the discussion at hand: I can set MAX_TASKS_PER_USER and MIN_TASKS_LEFT_FOR_ROOT in linux/tasks.h. I can also limit the maximum memory usage of any given task with the ulimit mechanism you mention. (I can do that as root from getty or login before the user has a chance to do anything.) Both of those mechanisms would work towards preventing a mortal-user fork-bomb from trashing the machine. (A "max total memory per user" would be nice, but I would think the way modern UNIX VM's work make such an idea rather difficult to pin down, in practice.)
What I understand capabilities to be (referring to POSIX capabilities here) is just fine-grained access to the abilities that normally only root has. I don't see how that prevents a fork-bomb from happening (although I suppose I do see how this prevents a fork-bomb from happening accidentally as root).
So what am I not understanding?
--Joe (Genuinely interested)--
Program Intellivision!
Program Intellivision!
Good question. What's really sad here is that SVID, POSIX, and BSD all probably do state that these sorts of non-ANSI APIs are supposed to show up in string.h (or maybe even strings.h !!) as part of their interface definition. Ick. To change that now would be tantamount to changing these standards. (Not that that would necessarily be bad, but then you'd have another set of not-quite-compatible standards to try to be compatible with.)
One way to adapt your code in a semi-portable (or at least in a somewhat self-documenting) fashion is to #define _POSIX_SOURCE and #define _SVID_SOURCE (or _BSD_SOURCE depending on your code) explicitly to enable some of these features even in the presence of -ansi. By explicitly defining these in your code (say, in a configuration header), you effectively state to the human reading the source that you rely on non-ANSI APIs being exported in these otherwise standard headers.
The unfortunate mess that we've inherited has all of these non-standard APIs spewn across all of these standard headers. It's for that reason that tools like GNU autoconf exist. I'd rather these APIs all be confined to their own headers as you suggest. *sigh*
--Joe--
Program Intellivision!
Program Intellivision!
I disagree. An application that starts thrashing the machine sometimes can only be brought under control via a reboot. Imagine if a privileged process starts the equivalent of
I don't care what OS you have, the easiest way to reign that one is is to reboot. Things get even worse if said task is allocating other resources along the way (such as file descriptors, network sockets, what-have-you).
--Joe--
Program Intellivision!
Program Intellivision!
Uhm, two things of my own:
In short, it's your own damn fault for using -ansi while trying to use an API entry that's not part of ANSI C's standard library.
--Joe--
Program Intellivision!
Program Intellivision!
So does Linux. Sometimes I wished Windows did.
At any rate, if you have your resource limits cranked up for some reason, or a privileged process develops a bug and goes ape-shit, well then... :-) As the poster a couple levels up said, the reason the one machine needed a reboot was because some in-house application did exactly that.
--Joe--
Program Intellivision!
Program Intellivision!
BTW, why do all of your periods come up as copyright symbols on my screen? Am I the only person who sees that?
--Joe--
Program Intellivision!
Program Intellivision!
Lots and lots of penguins.
---
seumas.com
I can see problems with this...
>The accountant problem is solved by giving the
>accountants one account, and a tarball of all
>the accounting records.
What if they need access to live data, are you going to create a new one every few hours?
>The student problem can be solved by posting
>your work to your public_html directory,
>password restricting access with HTTP
>authentication, and giving your pals the
>password to your website.
Which is promptly hacked by someone... Secure? Nope...
I've got the earlier GForce256. Although I downloaded the NVidia Linux (XFree 4) drivers I have yet to get them working.
However, after I installed Mandrake 7.2 it used the (S)VGA driver and still gave me 1024x768 at a decent colour depth, so I haven't bothered. Can't get Parsec's Lan demo working on it, but that isn't a problem...
My suggestion would be to go with Mandrake (or any other ditribution that manages this - I haven't tried many others, having switched after Redhat 6.2). KDE 2 (included) also has a 'control panel' and between that and DrakConf it provides a fairly easy way to configure a fair amount of stuff. I did have an issue creating a ReiserFS drive with DiskDrak (would not format - had to do it from a console), but unless you plan to try that you should be fine.
>users would be forced to learn something about computers.
Oh I can just see it now:
User accosts me as I am passing.
"My computer crashed, so I copied the core dump and emailed it to you, OK? Oh and then I reformated the disk, only... What do you mean I shouldn't have those Micky Mouse fridge magnets on top? They look nice..."
(So speaks a harassed Sys Admin)
>If you make a system so easy an idiot can use
>it, you should not be surprised that idiots are
>using it.
Hmm... So the kick-arse graphics card driver programmer who can't find how to configure his linux box to be really secure is an idiot?
Until Windows Millenium, I used Win95 (B) because I found it more stable than Win98(+SE). I had no problems with installing up to date OpenGL support (although my current machine will quite happily run anything in software mode...).
Win2K I like (and use as my desktop at work), but I could not get it to run the correct graphics drivers without crashing, even the recent ones...
On the Linux side (just to show I'm not one OS man), I'm working with Mandrake 7.2 at the moment to try and set it up how I want it.
>Highlight with the left button and paste with the middle button.
...Except when you highlight with the left button and press ctrl-c then have to paste with ctrl-v; or highlight with the left button and paste with the right button (yes I have a 3-button mouse...).
Confused?
I'm back home now.
/etc/lilo.conf to this theoretical /proc/settings/lilo
/proc/lilo/default
Other ideas that came to me while I was driving back was:
- Backward compatability:
symlink
- other command line actions:
cat
[eg response:] linux
Anyone get what I'm suggesting?
ARGGH! Preview - must use preview...
/proc/settings/lilo in both examples as per my previous post...
meant to type
Although we really are OT, since this is X not Linux and the change would apply to anything Unixoid on an x86 CPU.
But I would greatly enjoy a window, maybe 2/3 the size of the current screen, with a picture of a monitor on it that you could stretch and shrink and move around with your mouse in real time, having the corresponding effect on the actual display area within the monitor. Plus a little label that says ``Use Backspace to revert one step, Esc to revert to last known good parameters.'' (-:
Got time? Spend some of it coding or testing
my graphics card is unsupported or else requires a more advanced version of XFree86
And this is not a problem for Windows NT? Oh, my! (-:
Seriously: many, many graphics cards (including this Banshee) run just fine out of the box, and new versions of things are not as risky to install under Linux as they are under Windows.
I have no idea where to look for config files. Don't tell me;
/etc - and don't give me any of that ``don't tell me'' crap, this isn't a write-only forum.
I'm afraid of the word "compile".
I'm afraid of the term ``painted into a corner,'' which is where you often wind up if you're unable (or unwilling, same thing in effect) to do a compile. Let's try one of these fearsome compiles, just to see how hard it is: ``make bzImage'' - ooh, tough one! Not that I've had to recompile a kernel for months, and I do a variety of Linux installation and support for a living.
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.
They're there. Just click on the K or the footprint and select ``Configure.''
I want a folder called "Control Panels."
Would you settle for typing ``control-panel'' on a command line, or putting same behind an icon? Hey, it works for me! (-:
if you want more otherwise-capable computer users to go over to Linux, these are the things that have to be taken care of
Great, because they have been taken care of. And folks like Helix are working to make them ridiculously easy, and have been making good progress.
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.
This seems to be your basic bitching point, and will only be fixed by Linux's popularity outweighing Microsoft's funny deals and lawyerisms. It's got sweet Fanny Adams to do with technical issues.
The move to platform-independent X drivers is a brilliant one in that OpenBSD and all of the other even-less-mainstream operating systems like The Hurd can have updated X drivers at the same time that Linux gets them. Would that this could also be done for Windows and other devices; the hardware manufacturers would be dancing and singing in the streets, flinging their hats in the air (and in some countries discharging firearms, hopefully skywards). As things stand, careful manufacturers are taking advantage of common-code designs and it won't be too long before they're producing one standard driver and one Windows driver.
Got time? Spend some of it coding or testing
Hey,
I've got a question for people using 2.4.0pre10 or alan's 2.2.18pre22: Why does NFS mounting take WAY longer?
I've tried enabling/disabling NFS3 in the 2.4.0pre kernel, and have NFS3 disabled in 2.2.18pre22, whenever I mount an NFS export it takes about 5 seconds to mount on 2.2.18 and over a minute to mount on the 2.4.0pre10 kernel. Am I the only one seeing this? Is it a bug? Am I doing something wrong?
BTW, the client is running Debian Woody, my NFS server is running FreeBSD 4.1-stable.
Thanks for any help,
Ben
"NT4 kicks Win2K's ass all over the place on the workstation."
Sure it does. Uh huh. The vastly restricted hardware support, poor support for 16-bit software, shonky DirectX and complete lack of self-healing features truly raise it above the level of W2K, which has all of these problems *fixed*.
"Win2K is easy to admin, but Linux, FreeBSD or Novell are probably best here."
Sounds like you've never used NetWare. Or Windows 2000 Server. W2K is *not* easy to admin; it just *looks* like it is.
"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."
Eh? Are you running the same operating systems as the rest of us? W2K has *excellent* OpenGL support, and NT4 has so-so. Win95 and derivatives has *poxy* stability. Smart people play their games under W2K.
--
Peter
APT is great, but I couldn't stomach the license bigotry in the debian camp. I gave up on the GNU-and-improved GNU/Debian GNU/Linux and wiped the whole damn thing off my GNU/hard drive. Besides, if I wanted to run a system that's 6 months behind the bleeding edge I would use win98.
0 1 - just my two bits
Mandrake 7.2 installs XFree 4.0.1 by default (and KDE2, and the latest GNOME, and about a dozen other windowmanagers too), and it has a nice GUI install program.
0 1 - just my two bits
You give him too much credit.
He still has yet to match the keen intellect of The Glorious Meept.
0 1 - just my two bits
What are you smoking? Weed?
You have to be smoking something because this is all worse then firtilizer.
windows 95 could do this, depending on your video driver, and how you had the advanced options set. it was possible to change resolutions without rebooting. sometimes.
---
I post links to stuff here
In the latest v2.4.0test11pre-patches, this should be solved, mostly. There are still some problems with PCMCIA to be solved, but they should be ironed out before the release.
Bugs in userspace has very little to do with where the kernel is headed next... But of course, there are probably distro-specific bugs in the kernel too, as most vendors costumise their kernels.
Hah! Who says I'm going to "cd" into a directory before creating a file in it?
(Nitpicking? Nah... I consider this a valid, if minor, objection).
This is certainly true. I'm no newbie, but I've spent upwards of two days dorking around with upgrading php, apache, mysql, and openssl. I could have probably used the respective RPMs, but even configuring and compiling, though I suspect these will never be fodder for "newbies," could be a lot less troublesome.
I don't know, to me asking for Linux to be a Windows software platform is like asking for a VTOL jet with four-wheel drive....
On the other hand, I suspect that deep down it isn't "Windows Applications", specifically, that you 'need' and want, but rather applications that do the same thing at least as well, and in a similar manner to and compatible with the Windows versions (especially, to be blunt ,games and easier-to-set-up hardware accelerated 3D, and more support for the media formats (e.g. 'WMF') that Microsoft is force-feeding everyone through their present control of the market [in my opinion]). This I can certainly agree with.
Widely available good replacements for proprietary formats will hopefully become more common. I can't afford 'flash' authoring utilities (and I don't think they're available for Linux anyway), but would love to see some progress with the '.mng over .ogg' concept that someone mentioned some time back, for example.
A vote for the lesser of two evils is still a vote for Evil.
Hacker Public Radio is our Friend
Unix used to benefit from a sort of darwinism.
Yeah, it benifited all the way to a shrinking to negigible marketshare on only the largest upmarket boxes. Or were you talking about the paycheck and dicksizing common among Unix SAs?
Unix beat VMS by being simpler and easier, believe it or not. Microsoft took that lesson to the bank.
--
Business. Numbers. Money. People. Computer World.
But, a correct implementation of ACLs would require the module, and the other 650MB of software on the distribution disk to be configured and installed correctly. By then, you've probably gone past the point you can reconsile the ACL and UGO systems, and you essentially have an OS-level fork.
--
Business. Numbers. Money. People. Computer World.
Fah. The success NT ACL support had nothing to do with the bogus POSIX subsystem.
It was a required feature because Novell NetWare, the previous LAN server incumbent, had ACL support and Microsoft needed that feature checkbox.
BTW, Notes does have a massive number of security options, including pretty fine grained ACLs. To contrast the Unix ACL skeptics out there, it is actually not that hard to set security policy and audit such an environment, and it's the only way that you could possibly manage a large scale distributed system. The only tough bits are when you get down to the security bits that are added by developers (reader fields and the like).
--
Business. Numbers. Money. People. Computer World.
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)
NT 3/4's ACL implementation was hamstrung by the marketing requirement that all Win 3.1 and 9x single user system programs must run without modification. (Notable examples being MSOffice 97 and Netscape 4.x). Win2000 fixes this with distingishing between a "User" (tight default) and a "Power User" (can run older software).
A linux based implementation wouldn't have this problem for the most part because Single User backcompatiblity wouldn't be a requirement, and you can fix the broken software for the most part.
--
Business. Numbers. Money. People. Computer World.
Two things I 'd like to see in future versions of Linux:
1. I'd just like to emphasize your point that Linux needs to make printer setup and printing much easier than it currently is. I know I'd like to see that happen. And
2. Fonts. It should not be so difficult to install truetype fonts. It would be nice, too, if printing truetypes was automatic.
Ignore the above wish list if you don't want Linux to be a desktop operating system.
Seth
sigh...
Offtopic, of course, but I can't stand it...
on SVR4 variants (Solaris, HP/UX, etc.):
ps -ef | grep "*clip*" | awk '{print $2}' | xargs kill -9
on BSD variants:
ps ax | grep "*clip*" | awk '{print $1}' | xargs kill -9
(Both of them work on Linux too... note that you can't use "killall" because you aren't searching for a specific command, but a pattern. Saving the above in a script that accepts the pattern as a command line argument is left as an exercise to the reader ;-) )
and of course it is actually):
grep clip
instead of:
grep "*clip*"
(thus going to prove that I probably shouldn't be replying to posts on slashdot in the morning)
Instead of clamoring for them, they just run their below-port-1024 daemons as root.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
This is, indeed, a bit of a problem with it for many of my uses. OTOH, config files are typically small, so we really don't need a full-scale database.
Still, there is much to be said for that. Disks are large enough now to include, say, postgres with the distribution. So config file editors would just need to be able to read postgres files. That, too, is a well-defined standard. I'm sure that unicode is no problem. Or included icons. Or included dialog boxes. Or, oh, entire theme sets.
When we change the config setup, perhaps we should look at a significant change. XML has it's points, but it still has the limitations of a text file. A database permits true random access, and, if it supports blobs, many other capabilities. The drawback is that you need a tool fancier than a text editor to read it. But if you are using a KDE or Gnome or X-window editor, you are already using something a lot fancier than a simple text editor.
Problems to be solved: Database corruption is not a viable option. Everything needs to be transaction based. A backup copies of the entire database needs to be made after every complete round of changes is comitted (or, perhaps, verify the database when the latest changes are 12 hours old, and THEN copy it to the backup). And recovery tools need to be available in text mode. But these are small problems. These are basically selecting from tools that already exist and improving the user interface. They do need to be executable from a floppy, but I don't think that would be a real problem if one were allowed to use two floppies rather than one. (Pity that Zip drives didn't become the standard!)
Caution: Now approaching the (technological) singularity.
I think we've pushed this "anyone can grow up to be president" thing too far.
Well, since there is no requirement to not fork, I don't see the need to force one. Just let them show up naturally. Ideally there would be a natural barrier between them, rather like the language barrier between KDE and Gnome. BSD Unix comes to mind. The normal Linux forks have a tendency to remerge with the standard kernel, but the BSD groups remain separate, because they have too much separate code right down at the base. Of course, there's also the license issue to help maintain the separation. But I think that *BSD is the fork that you were wishing for. So what is needed is to help them gain visibility, prominence, etc. It would also be nice if there was and even easier transition path between them for high level (non-kernel) code. So developing, say, JBuilder, for one didn't mean that it had to be redeveloped for the other. This would help keep them both economically viable choices.
Of course, there are the RTOS Linuxes, the embedded Linuxes, etc. But I don't think that they do quite what you want (though they, too, have their barriers that prevent remergence).
Caution: Now approaching the (technological) singularity.
I think we've pushed this "anyone can grow up to be president" thing too far.
Possibly what one needs is to be able to set user permissions as: A can do anything that B can do, also A can do anything that C can do, etc.
Then one could define (pseudo-)users, like ModemDialer, and FloppyDiskReader that have control of certain resources.
Then if A can do anything that ModemDialer can do, then A would be able to dial the modem.
Of course, "can do anything" is just an example. As I see it, read, write, and execute are still the basic permissions. One would actually have A can read anything that B can, A can write anything that B can, and A can execute anything that B can. But if certain things can only be done by a particular user, then that is an effectively fined grain limitation.
Also, perhaps one could separate out other rights. (Novell's system comes to mind...guess what I use at work.)
Questions:
1) Is this what ACLs are? (If not, why not?)
2) Are the rights transitive? (Should they be? Novell didn't think so.)
3) Would the pseudo-users have home directories? It seems to me that they should. This would be a place for them to store their private data files and executables.
If my understanding is correct, then this isn't actually anything that couldn't be done with the current system. Just define the users as the singleton members of their groups, and give the groups selected rights, and them add users to the groups as auxillaries to particular users. (A is also to be considered as a member of group B.) But this would require about three times as many groups as the proposed procedure would requrie users (since one would need a group for read, a group for write, and a group for execute).
Caution: Now approaching the (technological) singularity.
I think we've pushed this "anyone can grow up to be president" thing too far.
Nothing needs to change.
New drivers, DRI, and sack full of penguins !!!
The willingness of humanity to follow without question is the fall of them.
LIDS
IPSEC eg freeswan
ACL's
A faster/dev/random wouldn't hurt.
Glückwünsche, haben Sie Slashdot ermordet, indem Sie zum korporativen Druck beugten und Subskriptionen einlei
You've got an 'Interesting', without actually saying anything interesting.
As much as I would like, I don't moderate my own comments.
Can you explain what the problems with ACLs and audits are?
The added fine grained security management adds a lot more complexity to the process of validating that system is secure.
Highlight with the left button and paste with the middle button. What could be simpler?
Available now
Barnaby
It uses a doc for all its configuration, when I saw it I felt that it made so much sense it should be standard. ;P
-Shieldwolf
just = (My)Opinion.toCents();
To me, the most compelling reason to continue using X is its implicit networking support. This really sucks when you want to play games, but absolutely rocks in a networked system admin world. (which is where UNIX has been primarily used in the past)
:)
What I would like to see is something like Berlin, that will run native on local hardware sans networking, but also have the option of sending the display to a remote client. What would be great is if the 'server' could just send descriptions of what is needed for the gui to the 'client'. Say, I want a scrollbar widget on the right with 5 buttons across the top....etc. Then, the client would be responsible for using his/her own local hardware/processing for rendering everything locally. Then, every network server that you connect to would also have a similar look and feel, since your own local preferences would be what is used when rendering the actual display.
Also, I would like to see something like TLS/SSL implemented right away, as the above described system sounds to me as if it would be *very* insecure
Thoughts?
At $39 US a pop? I don't think so.
Are you from Earth, or an extraterrestrial casual observer? Of course people are buying computers to web surf and chat endlessly on irc, among countless other reasons. Word, Excel, and Powerpoint are for lamers and casual computer users. Like yourself.
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.
That intensely stupid statement needs no rebutal.
To reiterate on my previous post, 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. Linux needs to implement these new developments into the core operating system.
SEO Copywriter. Just Say ON
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?
www.everything2.com
www.disinfo.com
www.deja.com
www.yahoo.com
There are plenty others. Check these sites out if your looking for good content and interactivity.
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.
Linux is already doing it. Look at Nautilus, downloads and installations/upgrades with the click of a button, file sharing, storage space...
It's a smattering of what the near future holds, because users like me request these services. You may not need it, but don't speak for me or anyone else!
SEO Copywriter. Just Say ON
Open Source developers - God bless every one of them - need to look at the reason a vast majority of people use computers in the first place - IT'S BECAUSE OF 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.
Please moderate this message up so Open Source developers will read this post. Thank you.
SEO Copywriter. Just Say ON
The kernel section of the Linux Weekly News seems to be a good place to get a quick idea of what's planned for the Linux kernel. Digging quickly through the last few issues, I came up with a fair list of probables for 2.6, which I won't post here for fear of garbling the message horribly. (I know only slightly more about kernels than your average freshwater fish.)
I see, and on what planet is this? Why in grud's name would anyone buy a copy of Windows if they want to install linux? And to be frank, If you would contemplate giving up on installing a bunch of kernel patches/modules to get your DVD working then you are a big girls blouse :P My Creative Labs DXR2 works very nicely thank-you-very-much.
What you said notwithstanding, you can of course:
A) Buy hardware, plugin, download/borrow/buy OS(for $5), install via GUI direct from CD/Floppy/Networked Interface. Use.
-- OR --
B) Buy hardware with Linux preinstalled. Plugin, turn on and use. -- Full GNOME or KDE office suite already installed.
Dell, IBM, Penguin Computing and many others will all do this, which is even simpler than your MacOS analogy (and not to mention, cheaper):
MacOS X. Pay for hardware and MacOS. Open box. Plug in. Push power button. Go websurfing for free office software. Use Unix. #
I think you forgot (i) Pay for software upgrades with a major revision number (ii) lament lack of hardware upgrade ability. Harsh, but fair...
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.
Yep, for the record, even Win95 and NT4 could do it.
What's your damage, Heather?
nice troll
Are you joking???? To paraphrase: 'Root on many Linux machines are as stupid as their users, so let's open up the machine for attacks/exploits even further.' I'm sorry, it just doesn't make any sense to me. What's next? Root pw is hard-coded to 'password' because they're to stupid to remember anything else??
Oh, wait, I know... Let's just remove all permissions in the filesystem. That way, the idiot roots won't have to deal with scary things like chmod and chown... Then, we wouldn't have to worry about having ACLs either. Brilliant!
Where the value of X-Mailer: is the true measure of a man...
Agreed .. I've gotten pretty annoyed at some of the supposed-to-be-user-friendly window managers on Linux. And the worst part of it is, horribly enough, not *big* things but *little* things. Lots of *little things* are just plain wrong or stupid. And it's the little things that are so easy to fix.
I've just re-set-up my Linux box at home (it's still RH 6.1 so admittedly it's old) and I fired up KDE, and a few things bothered me within a few minutes: (1) No netscape available either on the KDE menu or the Gnome submenu (these days a web browser is such a basic, commonly used thing, what were they thinking?). (2) No GIMP available on either the KDE menu or the Gnome submenu (one of Linux's finest points, and it's not on the menu?) (3) Right-click on a file on the desktop to delete something: (3a) No keyboard shortcuts on the Yes/No message box!!! In windows I always just press 'Y' but I had to use the mouse for KDE. Windows might be crap as hell, but at least you can use the keyboard for basically everything. (3b) I don't know where to turn off the "ask me if I'm sure" delete option. In windows I can turn it off, I don't like it, it's one of the lousiest aspects of Windows file manager design (to perpetually ask "are you sure, are you really really totally sure" to everything, but at least most of the annoying message boxes can be turned off.)
Also the default window manager in Gnome is stupid enough to place windows by default so that *half of the window is off the screen*. So whenever a new window pops up, you have to manually drag it back onto the display. I'm sorry, that's just plain stupid.
And like I said - all of these things are *little things* .. I mean, I think both KDE and Gnome are really impressive, the *big things* are all in place. So there is little excuse for not having all the little things in place .. I'm going to install the latest RH sometime soon, and I just know I'm going to be extremely annoyed if those things aren't fixed yet .. I mean, it's been more than long enough now.
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.
-- Post No Gravy
Serious question - what does this have to do with anything?
-- Post No Gravy
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.
-- Post No Gravy
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?
-- Post No Gravy
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.
-- Post No Gravy
'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!
-- Post No Gravy
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.
-- Post No Gravy
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.
-- Post No Gravy
>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?
-- Post No Gravy
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!
-- Post No Gravy
Is there any particular need for the asterisks when you're greping?
Carnage4Life wrote (accurately enough): "This article is similar to asking a bunch of random Windows users where Windows(TM) development should go and expecting a coherrent answer."
:)
... what's the problem? :)
OK, but what's wrong with that?!
You're right that asking a lot of users (vs. developers) won't result in definitive, future-defining moments. What it might do is provide a public place where a *lot* of users can point out what they'd most like to see.
Linus et al are free (by definition) to make / not make whatever changes they want, but fixing annoyances and adding cool features seems to make them happy.
so
timothy
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
a) snol, you're right. Putting on Linux is far harder than it ought to be, and there are a lot of non-intuitive steps to it. [Everyone who's given up on a Debian installation, please raise your hands ...]
... RedHat 7.X is way better than the 6.X series when it comes to installation, for instance. I forget whether it includes a tool like DiskDrake, which is the chief reason I rank Mandrake so high.
... On the other hand, I've never been a big fan or user of Windows, and I have plenty of complaints about the windows interface (to modify my internet connection, I hit a button called start, then choose a line that says "Settings" then a line that says "control panels" before opening a folder which may or may not allow me to establish a connection? Yoiks! Call *that* intuitive;)
b) However, I don't think you're *all* right;) I recently put together a box in order to do nothing but play around with different distros (and esp. their installation procedures) in order to better understand them all. I would suggest to you these distros as being easier to install than others:
1) Mandrake: Even if you decide not to stick with this as your final distro, Mandrake uses the DiskDrake formatting tool, so other distros which have no partitioning tool included can use the spaces you create with it. Also, Mandrake does the nicest job I've seen of nicely *keeping* an underlying Windows partition if that's what you want to do. Also, I think that Mandrake 7.2 is the most likely to support your cool video card.
2) Stormix: It's debian based, but with much less confusion than the raw Debian install you can get X and other things working.
3) SuSE 7.X - much nicer install than the 6.X versions, really walks you through things, with good sidebar explanations of what each step in the process means.
But there are lots of others to try, too
The ease of use issues you mention are very important, undeniably
We're all affected by different things differently; I get along better with the design decisions (esp. for file placement etc) on the Mac than Windows, but linux / unix systems fall somewhere between those two.
Autotodetection of more settings would be a good thing, sure, but as you mention there are some big issues on the hardware makers' end too. For the particular hardware (none of it bleeding edge or terribly obscure -- mostly low-end as of 18 months ago and definitely low-end now), the current distros seem to find and recognize most of it. (But not, as you say, network parameters, etc.)
And of course, companies like to hear specific probs or complaints;) If something doesn't work and you tell them about it, could be that next time it will work.
timothy
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
Not just you.
Bye!
A comment about the first point: "the XML parser can, and will validate most syntatical and grammerical errors, but it *cannot* check invalid values". I agree this is a major problem with DTDs, which is why XML Schemas make so much sense. Check out the Primer for more info. It's not a silver bullet, but it's a heck of a lot better than DTDs (although they do have their place)
Already been done...check out 'vigor' (the paperclip at least)
--buddy
What a good idea. Unified access to config files. All the files in the same standard locaations accross distributions. Why don't you just get windows and regedit?
It was your idea.
See, this kind of chaps my ass. Generaly posts like these are submitted by people which have no real experience with running the operating system in question; in this case Win2K. This is just backed up by the fact that the person references 'crashes' which he did not experience himself. Personally, I manage twelve Win2K servers (both Server and Advanced Server) and have only had good exepriences with them. In fact, since their installation this past summer, I have only had to reboot one of them once due to a home-grown application error, not an OS error. Win2K sure may have it's stability problems, but I'm sure as heck not seeing 'em.
ALG
Yes I did, you are correct. =) It was exactly that; an application running as a privileged process went nuts and brought down everything else with it. And as another posted a couple of levels up said, it would be nice to have included resource limits in 2000... however, I am stoked that you can now set processor affinity. That makes my life a whole lot easier. Give a really processor intensive app a couple of processors to run on, and the OS the rest.
ALG
OK, you got me. When I said "readable by bob", what I meant was "only readable by bob", i.e. not writable or executable.
The Daemon problem isn't solved by ACLs, it's solved by Capibilities, which are something entirely different.
The accountant problem is solved by giving the accountants one account, and a tarball of all the accounting records.
The student problem can be solved by posting your work to your public_html directory, password restricting access with HTTP authentication, and giving your pals the password to your website.
As far as I can tell, there is no clean way to implement ACLs so that they don't slow the filesystem down immensely at the kernel level. It just seems like a kludge to me.
-- The act of censorship is always worse than whatever is being censored. Always.
Why would you ever want to do something that complex and difficult? In what real situation is it nessisary?
Even if it is nessisary, why do it in kernel space? It seems like it would kill file system efficiency in one fell swoop. A user space program could emulate the functionality for the few cases in which it may actually be nessisary.
-- The act of censorship is always worse than whatever is being censored. Always.
Well, to comply with the restrictions you identified exactly, I would use the following: Users alex, bob, and carol are in group thisfile. The permissions on the file are u:rw g:rw o:none
-- The act of censorship is always worse than whatever is being censored. Always.
Unfortunately if you use windows 2000 in combination with Office 2000 there is a 40% chance of it losing list items in a numbered list
the basic .conf file is usually a series of key/value pairs. Meaning, option "a" is set to "foo", option "b" is set to "bar", etc. When an app needs to have configuration that is more complicated than this, say option "a" is a list of items, or option "a" is a list of items each of which having sub-options "b", "c", and "d", all the apps start improvising their own methods.
File formats that have confounded me include the .procmailrc format (which attempts to use "english"-type expressions), the sudoers file (which is sort of BNF-ish) format, and forget about sendmail.cf (i have no idea about that one). With XML, there would be no more special pseudo-languages and sub-syntaxes to learn. To represent named value trees of arbitrary depth or lists is inherent in the XML format, and all of these formats could be converted into simply a particular tag relationship. When given a DTD, can be immediately displayed in any number of ways by tons of different tools and understood by all with only minimal man page overhead.
The files would become much bigger and spread out, which I can certainly see goes against the grain of a lot of UNIX culture, i.e. the culture of representthemostcomplexamountoflogicinthemosttextu allyshortstringpossible, but personally ive never found that particular quirk of the culture to be so productive.
procmailrc is confusing, but i meant the .fetchmailrc format as the one that tries to look like english...
> If you want a single configuration tool 'Windows
> Registry Editor' then why not just go to a binary
> configuration file format. It's much easier and
> faster to parse binary data than text, and since
> you have a universal configuration utility it
> really doesn't have to store it in a human
> readable format.
Well, we'd have to write the binary format. Which negates some advantages of XML (prebuilt parsers, established standard). And the canonical reason not to go binary is simple -- what if I'm rescuing my system from that rescue floppy with only vi on it? (And so on.) XML has all the advantages of an arbitrary text format, fewer of the disadvantages, and a few advantages an arbitrary text format doesn't.
-_Quinn
Reality Maintenance Group, Silver City Construction Co., Ltd.
The problem is that the basic Unix permission concept is *too* simple for many needs.
As one poster points out, most every daemon runs as root. Why? Because there's no easy way to say that arpwatch just needs raw read access to the ethernet devices. So it gets full access to everything.
It also requires administrators to be involved in a lot of things that they shouldn't care about. Say you're a student at a large university. You and a couple of other people get assigned a joint project. Why shouldn't you be able to created a shared directory and give your pals access? With standard Unix permissions, you need somebody with root to create a group entry (and then delete it two weeks later when you get another project).
Or consider the case of a file that needs to be accessed by two groups. Say you have a team of auditors turn up for a month who need to look over some (but not all) accounting records. With ACLs, you create a new group that is the union of the two groups, you change permission on all the files, and change it all back when they leave. Plus in the meantime when they add a new accountant, you need to make sure to remember to add him to the common groups. You can do it, but it's a big pain.
And if ACLs exist, it's not like you're required to use the added power; you can still do owner, exactly-one-group, and everybody-and-their-brother permissions.
It's available as a patch for 2.4.x already, written by Jens Axboe. Its very stable for me also (although the mailing list mentioned some ide-scsi probs lately, so I can't speak for atapi owners)
Get it from http://packet-cd.sourceforge.net/
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
Why on earth are all these people saying we need XML files, XML files, XML files, because we need nested, uniform data structures?
Flat files are small, efficient, well-understood, and extremely fast to parse compared XML files. They are also more human-readable, and less prone to error when modifying with a text editor (Oops, I forgot the , now Apache won't work). Programs can verify their own configuration files, and do it well at this moment. Also, when is the last time you heard of a bug in a program's configuration file parser?
There is no inherent reason a flat file cannot have unicode support, either.
As for nested data structures, we already *have* a very well-developed, efficient, and well-understood data store. It's called the filesystem.
There is no inherent reason why a flat file can't be unicode compliant.
XML is overkill for most things people want to use it for, including configuration files.
No, I'm not a troll -- Linux is undeniably a better OS than Windows but you have to remember something:
Yes, Apache will beat MS Exchange into a bloody pulp, but this fight has evolved past Application A vs. Application B.
The future is about collaboration and the majority of tools which perform collaborative tasks (read "Lotus Notes")
are usually coded for the Windows platform, where the best version exists (read Netscape). It's great that tools such as
VMware exist (needs speed improvements) but they are costly. Flex86 (the Bochs descendant) is better but hasn't run
anything substantial yet.
These tools need to be improved so that they can run Windows applications flawlessly.
When that day is reached, Bill G. will be preaching to an empty choir.
This post encoded with ROT26. If you can read it, you've violated the DMCA. Handcuffs please, sergeant.
Will you educate yourself before you whine? XFree86 Config file do not need modelines from version 4 on.
And have you ever used XF86Setup? xvidtune?
Windows. Let's talk about Windows. Windows pretty much do not allow you to fine tune your hardware to run as what it's capabile of. Windows only uses lower refresh rates, and it basically burn your monitor for a few seconds and see if you think it's out of sync. wow. What a innovation.
A couple links to throw your way before the rest of you start spewing all the grandios wonders of the ACL systems. BTW, NT's ACL lists don't fit the bill anyway. I've worked with them, and they're a pain in the behind.
EROS has some serious potential, folks! And if you want serious Linux security, look into LIDS...
assert(expired(knowledge));
All my input hardware is USB and I run Linux just fine with it.
slackware doesn't costumize their kernel.
When Notes Domino is running, even ROOT (NT's "Administrator" account) cannot violate sharing on these files.
:-).
Wrong. NT's Adminsitrator account is exactly what Linux should have - a fairly capable priviledged account that still does not have full access to the system.
NTs equiv of root is SYSTEM. No, it doesn't have permission to log on locally
Well, I'm arguing modern Unix-like philosophy is good, but the implementation doesn't always stick to that philosophy [which is poor]. There's many aspects on Unix that have evolved from 30 years ago.
Another thing you have to remember is that Linux isn't Unix, and doesn't have to be Unix-like down to the last details [especially an aging permission system]. DevFS, and the upcoming XFree86 X extensions, are improvements in Linux [and other XFree86 systems] which are not Unix compatible [or Unix-like is the sense that Unix does not hadle these functions in the same way]. But the trade off is more than worth it.
Correct. Or he could use [Crtl] [Alt] [+/-].
But I think he means color depth - AFAIK, there's no way X can do colordepth on the fly. Does anyone have any info on changing X colordepth without restarting the server?
Actually, as the person that posted the article, I for one am talking about Linux, the Operating System. And I think, these days, most people are talking about Linux, the operating system [including most of the kernel developers], and defining the kernel as `the Linux kernel'.
And is there any reason why the FSF needs to take credit for their contribution by changing the name of the OS? Because, personally, my own OS of choice and most other variations of Linux use vastly more software that is not FSF created than software that is. Many of the important components of my system are based on BSD code and then GPLed [not that I don't love the GPL, but credit where its due]. Many, many other parts are GPLed, but not FSF/GNU software.
I'm sorry, but while I believe the FSF deserves some credit to creating an innovative license, there are many others who have made similar contributions and don't ask for the OS name to be changed to include their contribution.
Printer support is a problem with XFree?
I don't use XFree86 for my printer, do you?
Of course I also prefer headless print servers I can throw in the closet and ignore.
On the desktop, sure. Nobody has ever said that *nix desktops were better than winderze.
I suppose I'm not too threatening, presently, but wait till I start Nautilus
try mandrake 7.2 or redhat 7.0 /etc (as opposed to being scattered around, or in a single huge unmanageable file). I dont like compiling unless absolutely necessary. RPMs make this mostly unnecessary and manage dependencies. Compiling things is only rarely necessary and even then there are detailed instructions. If you need to compile something, its usually because the software writers have a good reason for not wanting to make that version or program easy to install !
the latest cards will only be supported by the latest XFree's and distros (if you don't want to manually upgrade to the latest XFree). Mandrake 7.2 has been the best install I have done to date, and DrakConf seems to be almost what you want. For doing more interesting stuff (like webserver or ftp server) you will still have to know that almost all config files are in
Good luck,
Smthng
PS I am a happy linux user, but it took 3 aborted tries and 2 hard drive f***-ups (unnecessary stupidity).
single 'universal' configuration tool
If you want a single configuration tool 'Windows Registry Editor' then why not just go to a binary configuration file format. It's much easier and faster to parse binary data than text, and since you have a universal configuration utility, it really doesn't have to store it in a human readable format. Applications can add their own piece for its configuration options.
After a while you might end up with all the extra applications to edit small pieces of that massive tool, TweakDUN, TweakUI, TweakEveryThing. Eventually you might end up at the same spot, except instead of having multiple text files for configuration, you'll have multiple command line and GUI applications for configuration 'Control Panel', along with one really big configuration tool that is difficult to browse through 'Windows Registry Editor'.
Sounds like what you want is Windows. ~:(
Here's an example to use, I read it somewhere in regards to goverment security certifications.
Suppose I have top secret clearance but you only have secret clearance. There is no mechanism to *prevent me* from giving you top secret information.
Fsck cluebie moderators. I'll say what I want, offtopic or not. And fsck having to qualify every bloody statement just
- 3D user interfaces / window managers
- Artificial Intelligence (e.g. agents) tied to
...
- Voice recognition
I'd like to be able to say "Computer, please find out information on this topicSomething more realistic: I would like to be able to renice a process' disk activity and disk buffer cache usage, for example when the updatedb process trawls my hard disk to update the (s)locate database. I used to run this every hour until I got sick of just about everything grinding to a halt (I have plenty of RAM and MHz).
I did a search on Google and found that this was discussed recently on Kernel Traffic.
Rohan
I must first say I'm not a kernel developer and don't plan on being one. However from an outside looking in it appears to be that the way the kernel is developed needs to change drastically. Change 1. Impliment CVS. How the kernel has come this far without CVS (or similar) support is a mystery to me. Change 2. Bug/Patch tracking system. Guys, download Bugzilla (or Fenris or whatever), set it up and USE IT. From what I've seen it appears that kernel development is ruled over by Linus just a little too much. Everything must pass by him or one of his lutenants. I guess this isn't a bad thing. All code should be audited by those in the know but to me it seems far too pyramid like at the moment. To tightly controlled from the top. I fear that without more open access to core linux kernel code base that there is a kernel source fork in Linux's not too distant future. Later
-- Oliver Jones - Deeper Design Limited
This article isn't specifically about the kernel, but Linux in general.
-----
"People who bite the hand that feeds them usually lick the boot that kicks them"
Higher Logics: where programming meets science.
Just a minor correction: SAX is an API, not a parser. Many parsers (universally tested or not) implement SAX.
The kernel is as fast as it's going to get...
I know the kernel does a good job with speed. However, it is NEVER fast enough. There is always some more tuning that can be done, somewhere.
Suppose, for the sake of argument that I'm a dolt that wants to run Linux fast.
Either that, or I'm too lazy or have too many other things going past due that I cannot afford to spend days poring over documentation to get up to speed about tuning Linux for my particular piece of hardware and set of applications. My time costs more than the hardware does.
How about a compile time option to run with profiling?
Let the kernel measure how many httpd's get spawned for your 4 high speed NICs under typical loadings for a week, or, alternately, how much interactive response you need for a framebuffer using DRI if you happen to be using your system for desktop abuse. Then, let the kernel be recompiled with this information.
The kernel developers are doing a fantastic job, but it's always bothered me that many of contentious algorithms (eg, picking the process to kill on OOM, a recent example of where heuristics enter the arguments) can't be tailored more to the particulars of the situation.
Perhaps kernel modules can accomplish the same effect without the need to resort to recompilation. The key thing is that the algorithms and settings should be
By in large, though, I've been pretty happy with Linux development. The improved NFS performance was my biggest gripe until lately.
"Provided by the management for your protection."
I disagree. Sure, Slashdot is frequented by linux users... AND most of them are very technically literate; certainly moreso than the average Windoze user. They know what they want out of the future of their OS and are not afraid to tell you. I suspect Windoze users just sit and wait for the next release to come down the pike.
Rich...
Ignore Alien Orders
Re: Config Files
/etc. User specific config files are usually in the format .XXXXX in your home directory where XXXXX is the name of the program. And yes, the system is a a mess, though linuxconf and the Mandrake utils help a lot (see below).
./configure;make;make install is pretty easy, but its a nightmare when you don't have the right includes/libs/etc.. I wish more people would use source RPMs or DEBs when distributing source. For one, it keeps your system nice and pristine and easy for uninstalling etc. and 2, it's easy to wrap a nice GUI around an rpm --rebuild, which would ease the pain of compiling software for a lot of people, and 3, it makes checking for dependencies so much nicer. I spent hours on the weekend hunting around for some obscure include file that a tarball needed to compile.
System-wide config files are in
Re: Control Panels,
The Mandrake *Drake utilities are very good. I love RPMDrake - It already has a catalogue of the RPMs on the installation CDs, and makes it a cinch to find what you want, and satisfies dependencies. DrakFont is good too - simplifies the unnecessary messing around with xset fp rehash and all that crap.
Re: Compiling
Yes,
I really agree that these fairly simple things (like config files) are still stuck long ago in the past. I think most of these things don't get changed because they're "how it's done" rather than the best way of doing things.
The typical excuse that people use for not bothering to consider usability. The idea that it's always the user's fault that they can't adapt to the way the developer things is absurd. Imagine if cars were so unnessecarily complicated that you couldn't drive a car until you were an experienced mechanic and could 'figure it out'. Software is made *to be used*. I suppose it never occurred to you that the developer may not be an all-important omniscient being that instinctively does things in the most logical and common-sensical way?
Re: your comment about
Hmm, I wonder why not...perhaps because *BSD doesn't have the perceived deficiency?
(Half ;-), since I'm still wondering why people are writing a GPL'ed Fortran 95 front end when there already is one that's part of SGI's Pro64 Project.)
Practice random senselessness and act kind of beautiful.
Perosnally I encourage everyone to steal linux and to use it for your own purproses.
The linux kernel should be used to run Microsoft OS. It will be slow and buggy becaue linux is so unstable, but we can blame that on Transmeta HW.
Why, just the other day I stole linux from Bob at the local computer computer store. He was charging 39.99 for it but I gave him 20 bucks and told him to beat it.
Will they add usb mouse support to the 2.4 kernel? Isn't what that reiserfs thing is? I think they spelled it wrong - it should be raiserfs. I wrote a mouse driver for the amiga once. Maybe I should just send that in? What do you think?
Take this personaility test.
"Prefiero morir de pie que vivir siempre arrodillado!"
The assertion was "Linux doesn't work". He's disproven the assertion by providing a counterexample.
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
I.e. you value your personal bias more than what other people got through objective tests. Great. You know, this is beginning to sound like a reasonably good attempt at FUD by a Microserf.
Claiming that Linux is not stable is downright ridiculous and goes against tons of evidence, e.g. This one. Personally, In over 2 years of using Linux, I've had exactly one crash that didn't result from me knowlingly doing very dangerous things.
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
IMO the question of /usr vs /usr/local is very minor (me, I see /usr/local as "the subtree for stuff I install manually" vs /usr as "where packages are installed") while I see the inability of source installs to uninstall and handle dependencies as an extreme disadvantage and hence, very imperfect.
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
Once yenta_socket officially supports i82365 I'm dumping 2.2.x. Finally, ALSA. Now if they can integrate the international patches... and low-latency support.. Umm.. better brush up my C and start hacking the kernel or forever (read 2 years) hold my peace :)
Michel
Fedora Project Contribut
Last time I checked the i82365 PCI PCMCIA (not Cardbus) controller is still not supported... I would *love* to be the first to jump into the 2.4 bandwagon (plus ALSA doesn't like kernel 2.2.17 + DevFS), but without my Internet connection using Linux is rather... irksome
Michel
Fedora Project Contribut
XML is a real pain to read with Emacs or anything else. I much prefer a choice between the fancy program config routines or to just edit in a text editor.
Anyway, what's wrong with nesting by indentation? C has been doing it for quite a few years and no-one I know has complained... Are there any languages left that don't condone indentation?
Email Settings {}
http://blog.grcm.net/
Though it doesn't directly pertain to Linux, most all games I know of (Unreal, Quake, etc) use nice, easy to edit text files for their preference files. I kinda don't think that all apps need the ultra-configurability of XML, even if they aren't helloworld.c.
So... what exactly would you gain by this?
It's not like specific configuration programs will be magically able to work on all configuration files because they are in XML. It doesn't make a lot of difference.
Second point: it doesn't have much to do with the kernel. how many things in etc are really linked to the kernel? and for procfs? Ideally we would have just a elaborate directory structure where each file just has _one value_, and not a whole text to parse. No use putting xml there or you'll get trees (xml) within files in trees (directories), kinda beats the point.
If you like the idea of unifying things that much, look into Gconf and the like.
But my vote is to keep it out of the kernel
Or we have to stop making excuses and admit that systems running hundreds or thousands of threads are highly flawed.
The point people tend to forget is that making a system run acceptably for this kind of workload will hurt it for more realistic everyday workloads. Just because it can be done doesn't mean it should be done. The people in charge of the kernel seem to have understood this very well.
--
I do not like the men on this space ship!oh bugger my tags got wiped
.oO0Oo.
bah, i lost a point for it
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
www.qnx.com
Regards, Tommy
XML is a way of giving plain-text data enough structure that it becomes possible to automate complex manipulation of the data.
There would be lots of both GUI and command line tools available to manipulate such config files. This would make life a lot easier for users.
There would also be a lot of libraries for manipulating standard XML, so application developers wouldn't have to spend much time writing the config file maintenance portions of their apps and could concentrate on creating better apps.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Most Internet software isn't of the standalone local variety, like old "productivity apps" were. For this reason, the old style of localizing separate versions for separate locales is obsolete. Internationalization is the way to go. Even if your interface isn't localized, your *functionality* should still work everywhere because your code goes everywhere.
The big multinationals have all figured this out. Sun, Microsoft, Oracle, IBM, etc. wouldn't even consider creating a new system that wasn't based on Unicode. "Scratch my own itch" Linux developers usually have a more provincial perspective of the problems they are trying to solve, unfortunately.
That's changing, though. As the major tools and protocols all update to Unicode, users will demand that all their tools work seamlessly with Unicode.
XML, for example, is UTF-8 unicode by default. XML-compliant systems are *required* to support unicode and not required to support anything else. Larry Wall recognized this trend and the upgrade to UTF-8 was the biggest reason for the jump to Perl 5.6. He saw the exponential increase in Unicode-encoded (esp. UTF-8) text and realized that the world's best text manipulator was going to have to be rearchitected to deal with the new standard text encoding.
The xterm developers saw this, too, and have now upgraded xterm to handle (UTF-8) Unicode. Now, we can all reimplement ls, cat, head, tail, etc. in Perl 5.6 and work in xterm.
Creating your own versions of standard tools is really doing it the hard way, though. We need all of our standard tools to work in Unicode. Old favorites like vi should work seamlessly with multilingual text encoded in UTF-8. All of the tools, and all of the glue (pipes, the X clipboard, all forms of copy and paste), the file system, the fonts, should all be Unicode. Copying Japanese text out of an email and pasting it into a French file in vi should be seamless. Copying a Korean word off a Web page and pasting it as an argument on the command line should work the same as if it were English -- on everybody's Linux box. It's just text.
That's the future of all other software systems (even most *new* handheld platforms are Unicode-based), so I hope it's the future of Linux. This business of having to tweak each tool separately for some subset of Unicode functionality, if it's available at all, is very primitive. A more universal, ubiquitous, transparent use of the ASCII-compatible UTF-8 Unicode is sorely needed.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
While that's true, few non-commercial developers are tuned in to what's going on outside their own small circle of buddies well enough to recognize the necessity of Unicode. Those who do see the writing on the wall often aren't sure how to deal with it. They're not sure how to write code to work with a Unicode config file.
Since *all* XML-compliant applications are required to support Unicode (and not required to support anything else), it would be easier to support Unicode config files by just making them XML files and using open source XML libraries for their config file manipulation.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
This is exactly the point. Why am I writing my own parser as a programmer when there is a superior, existing one? Why am I learning yet another file format as an administrator when it's just another tree style configuration file?
Yes, there will still be time spent on semantics - another way of saying that is "learning the system" - but my time is not wasted on syntax.
actually, you can....you just have to use "xargs"
i'd do it like this:
ps -auxww | grep -i clip | awk '{print $2}' | xargs kill -9
FluX
After 16 years, MTV has finally completed its deevolution into the shiny things network
"It is seldom that liberty of any kind is lost all at once." -David Hume
There's no reason an OS in the year 2000 shouldn't be able to dynamically allocate memory to an application as needed.
Will I retire or break 10K?
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]
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.
There have been "DPI on the fly" system extensions in Mac OS since about 1992, and it's been a standard part of the system since at least 1995. It's also part of Windows 98. (This just shows how the Mac clone known as Microsoft Windows lags behind the real thing.)
Will I retire or break 10K?
http://uptime.netcraft.com/graph?display=uptime&si te=www.microsoft.com
and
http://uptime.netcraft.com/graph?display=&site=www .suse.com
and draw your own conclusions. (But, please, keep those conclusions to yourself, or I'll be modded -1, flamebait!)
I fully agree with you, but it's sort of funny that your sig completely contradicts your comment. :)
-raph
He could use his ZX Spectrum... Ahh, "Use small key on door" You see a small trap door. Memories!
Maths would be about as easy as it is now. *Arithmetic* would be much harder.
My post was in answer to the point that the previous poster seemed to be making which was "hey, let's use XML then I won't need the Bat Book (Sendmail, O'Reilly)" Unfortunately, he will probably be disappointed because Sendmail configuration is inherently very complex because of the functionality of the product. I'm just saying that XML is not a panacea
In general, inappropriate choice of notation makes tasks harder for human beings. Computers can just translate whatever notation into something that is convenient for them (which is precisely what happens with high level language compilers), so let's make config files easy for *us* to understand. My gut feeling is that for *most* config files, XML is over-engineering and for the others, it will allow you to use generic tools to view the files in a pretty way (which is good), but apart from that does not offer huge benefits compared with, say, a common API for config files, something along the lines of what is provided to Windows MFC programmers (you use the same set of function calls no matter whether your config is in the registry or an ini file).
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
They used "kernal" in C64s and VIC20s because that's what it was in the Commodore PET - silly.
Anyway, they paid for their mistake by going bankrupt.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
Random access: read your text config file into memory on app start-up. If it's too big, there's something wrong with your app - rewrite it... Even sendmail reads its entire config into RAM. Backup and recovery: Make a copy of your text file. Better still, manage it with your favourite source code control tool, but make a backup anyway incase your changes screw the source code control tool. Personally I think config files should be edittable with any text editor. You can probably assume a worst case of "vi" although in my early days of working with Unix I did once have to edit a config file with ed because the customer hadn't installed vi and I didn't have time to learn emacs. Of course, being able to change the config with a text editor is no excuse for not having a friendly graphical interface too. The syntax should be simple and easy to understand for a human techy. That may disqualify XML with all its tags and angle brackets etc. I tend to go for a format similar to the old MS ini format. e.g. # this is a comment [section] keyword=value Also, separate files for separate programs. The big problem with the M$ registry is that your program is configured in the same database as all of those nasty and yet essential device drivers and so on.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
Sendmail.conf requires the bat book, in reality bible.
If the Sendmail conf was in an XML file it would still require a bible. The complexity of sendmail configuration arises from the semantics of what the config does, not its syntax.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
If your config was all in a binary format, then your rescue floppy will have a config editor on it, not vi (or as well as vi).
That's the one objection gone, so let's define our common binary format....
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
I use symlinks./
/home/username
/opt/www/ etc.
/etc
/etc
/bin
/bin
/etc/group, at some low level the user/process can only have one uid and one gid at a time. So even though that uid is a member of a group, if a process starts with a particular gid it does not have the access of the other gids, even if it's uid is in those other groups.
/etc/group and /etc/password, I still had these problems.
You create a public_html symlink (I usually call it www anyway).
e.g.
/home/username/public_html->/opt/www/username/
/home/username2/public_html->/opt/www/username2
Only username can get into
But the webserver and those in the www group have access to
Tada. That said, I still would like ACLs.
And also I'm having other problem with Linux's handling on normal unix permissions.
For example I created the following groups:
fetc, fbin, fusr, fproc, ftmp, fvar, fhome and so on.
I then made sure that only the relevant groups have access to those directories.
e.g.
chmod o-rwx
chgrp fetc
chmod o-rwx
chgrp fbin
The trouble I found is that even though the user is a member of the group in
Even when I allowed full access to
I suppose there's a good core reason why things are like this, but I was a bit annoyed - I was trying to stop any processes from accessing anything _by_ default - no chroot business - the filesystem was to be locked tightly down by default.
Cheerio,
Link.
Ever hear of a requirements analysis?
Sorry to be blunt, but users are an important part of the software development process. It's not enough to build technically competent software. You have to build the right software. Software people want to use.
--- Brent Rockwood, Senior Software Developer
BRENT ROCKWOOD, EST'd 1975
- better device handing/management
This is not a rip on driver availability, I'm talking about the ability to manage existing disks and existing (mostly scsi/fibre channel) devices. I can add entire new disk subsystems to Solaris and bring them online with a few commands (drvconfig, devlinks, disks). I need to reboot linux.
Along those same veins, how about support for much more mem (ala SGIs patches) and more processors?
- optimizations for Java/XML/whatever
- more kernel modules, fewer kernel hacks
- rework the dev chain to make more sense (/dev/hda1 just doesn't cut it anymore). Specifically, when I manage many disk subsystems I want pci/controller/hardware info. Look to Solaris for the best example: take a look at what /dev/rdsk/c0t0d0s0 points to...it's a long device path that I can use to ascertain the exact location of hardware (down to which bank an IO card sits in inside an E10000).
This is not a spiteful bash -- how many of you can claim you've been running since pre 1.0 kernels? BUT...it's use in large data centers is limited to web servers and network management stations. I want this kernel to run with the big boys.
I read the kernel mailings, it's pretty obvious that those "on top" have their own ideas and aren't so interested in the Enterprise management capabilities of linux -- I see work being done to make linux work better on a $1500 PC than on a departmental workgroup server. Look at the shamefull non-support of NFS v3 until now!
I buy lots of systems and manage hundreds of servers around the world. I focus on RAS: Reliability, Availability, and Serviceability. It can be argued that linux has the first two, but I would disagree with the last until I can hot-swap/add-in forty fibre-channel disks without a reboot.
On a side note, Embedded Linux will probably succeed where "regular" linux does not
Trust me when I say that Sun's new systems are going to make it even harder for linux to make the big leagues next year.
It would be nice to see the capabilities system completed so that it can actually be used. I think this would only involve adding capability bits to the filesystems and checking and setting those before executing programs. Finishing this would go really far to get rid of programs running as root unnecessarily. Anyone know why it hasn't been done already?
Dont ever do this again while im trying to drink Coffeé! Lispy
Linux should be improved to make it the choice platform for running web application servers (e.g. BEA WebLogic), enterprise databases and B2* e-business and e-commerce suites. For the kernel this means better SMP and perhaps even NUMA support. Means demonstrably better security than old UNIX or NT.
This is important because if the pure Linux companies want to be profitable, especially on a service or hardware model, then they have to be able to supply and be the choice for more complex solutions than firewalls, http servers and file/print. It's starting to happen, but more must be done.
Aide: Grant drinks too much to command an army. Lincoln: Find out what he drinks and give it to my other generals!
Just as a clarification to Where do you think Linux [the OS, as well as the kernel] will head in the future?:
There is no operating system called Linux. Linux is strictly a kernel. In most cases, the kernel Linux is a part of the operating system GNU.
(RMS would be very upset with you.)
Getting a little off topic, I would love to see Windows "dethroned" while GNU/Linux stays in its current state. Why? Because then users would be forced to learn something about computers. If you think about it, where do most computer problems, helpdesk questions, etc. come from? People who don't know a thing about computers and therefore can't figure out the simple problems on their own.
The patch system isn't stupid as you like to call it. Though the drop of incremental patches was sort of annoying. Also, rsync is already in use, there would be no benefit to opening up a CVS repository. Too many people would commit or change too many things and it would just create a big mess. And besides, if you can't figure out how to use patch, you're a dumbass anyways. As for your cheap attempt at trying to claim there is no innovation in linux, I would suggest you first get a clue before attempting to sound knowledgeable on the subject. Stability isn't everything, though I can use any number of experimental kernels on a busted system and still outlast w2k. There is innovation on an hourly basis, instead of judging development in such a truly idiotic manner, maybe you should try actually helping out.
If you have that much unsupported hardware, stop crying about it and start writing drivers for it. Don't expect other people to do your work for you.
The kernel isn't there to cater do windows users, development isn't going to suddenly stop just because its reached some sort of milestone (or whatever you want to call it). Due to its scalability and constant innovation its not something that will ever truly be 'done'.
*cough* berlin *cough* http://www.berlin-consortium.org *end cough*
Okay, so we go with your idea of commit reviews, thats just as tedious as a patch, even moreso. a patch anyone can make, it can be viewed by lots of people, commented on, rewritten, and then when its done it can be sent off for later inclusion in something. Not tedious by any account. CVS works well for a group of developers working on something, but when you have to go through a central entity -- Linus, then CVS is just added hassle. Yes, I am claiming that linux is more stable and more innovative then w2k. Its pretty hard to find an operating system thats less stable then w2k. If w2k were as stable and technologically advaced as you claim it is, then there wouldn't be a need (and a huge market) for alternatives. As for w2k and innovation, I don't see how the hell you can put those things together in the same sentence. Hell, even the most basic of filesystems from a decade ago did more then ntfs/fat is capable of. If you prefer to think about the environment as innovative, thats sorta like calling Oracle the ultimate embedded app. Its utterly ludicrous. By the time microsoft catches up to the 1.2 kernel (which should take them about another 10 years), then we can sit down and wait for some innovations to pop up. But innovations from microsoft are still a _long_ ways off. As for helping out, there are more ways to help out with kernel development then sending a patch directly to Linus (in fact, sending a patch to Linus should be a last resort). Depending on your patch and what subsystem it applies to you should typically go through them and let them hand it off to Linus later. Chances are, if your patch sucks, it'll get commented on and you can fix it, then resubmit it. Wasting Linus' time shouldn't be an option at all unless you absolutely have to. Also, if your patch does happen to get rejected by Linus, that doesn't stop you from maintaining it and getting it out to the people who might find it useful. There are lots of very important patches floating around that don't have a chance of kernel inclusion, but they're just as important. In your comment about freebsd, I find it peculiar that you would rant about linux's lack of innovation, and then advocate freebsd. freebsd is incredibly slow at adapting new things, and for good reason -- stability. What FreeBSD lacks in features (which is quite a bit), it makes up for in stability. Also, your comment about 'being heard' is also rather amusing. In your advocating win2k I find it odd you would care about 'being heard', considering thats the last thing you'll get under win2k. Being heard in the Linux community is not complicated at all, but if you waste peoples time then don't expect to be paid attention to.
Linux is incredibly more useful from the get go then w2k is, the reason people buy w2k instead of linux is primarily marketing and the fear of the unknown. If you compare the number of linux users today to the number of linux users 5 years ago you'll notice a huge increase, even though linux is still not all that heavily marketed. W2k is _not_ a professional os, it chokes on simple tasks and doesn't even support most of what people _want_ out of an os. Of course, since microsoft never supported much of anything useful, anything new is viewed as an innovation or a new feature, even though everyone of the alternatives have supported it for years and years beforehand. I don't know about you, but when I tell my OS to do something, i want it done, I don't want my os second guessing me and not being able to do what i want it to. As for your remark about a 70's unix implementation, why not? If it was done right 30 years ago and microsoft still can't get it right now, then what possible benefit is there to using w2k? Not a damn thing linux can do that w2k can't? Well, lets see, since I was talking filesystems, how about a _proper_ JFS? or lets go even simpler, _proper_ SMP support? NT has never supported SMP worth a damn and it still sucks in w2k, course linux hasn't had a major problem with it since it was first implemented.. but I suppose thats beside the point. As for what FreeBSD is lacking, sure.. drivers are a big part of that. Take a list of supported hardware under linux, compare it to freebsd, you can claim whatever you want, freebsd still doesn't support jack in ways of hardware. If FreeBSD worked fine for you under heavy load for a porn site thats nice and all, but I bet you haven't compared it to the new linux kernels, or did any hacking to the linux kernel to get the most out of it for your specific task.. hell, even some RT extensions in there would give you better performance for that kind of thing. There are many different things that _could_ have been done, but too many people think a default redhat install represents all the community has to offer.. *shrug*. Why you wouldn't want to work under Linus is up to you, several hundred patches floating around are most likely geared at several hundred _different_ things. Those several hundred different things are not essential to the operating system, they are things you can use if you want to. No one is forcing you to use third party patches, but depending on the task, you often need them. Sure, everything of value _could_ be embedded into the kernel, but then you'd have a huge bloated kernel and alot of things would have to be rewritten to comply with the patch, which is just a waste of time, its better to leave that thing in patch form. (example, SGI NUMA patch). Thats sorta the whole point behind a massively scalable operating system, it can work by itself on any number of different systems, and you can grab patches to get more out of it for a specific task. When w2k or FreeBSD can do that they might be more widely used in a wider variety of markets , but until then, they're still not going anywhere fast. And they're especially not going any new places that linux hasn't already been.
Yeah well, the people that think linux is a mess are generally the same buncha people that don't know jack about it. Most people might not be interested in learning how it works, which is fine. Theres a fine line between users/developers/kernel hackers, you don't need to know anything about the kernel in order to take advantage of its stability and innovations. As for the reference to a hacked together os, thats not really the case. While a good amount of the things in the kernel progress through trial and error, that doesn't make it a hacked together system.
I disagree with you a little on the ideas that ACLs would cause a fork. Most
likely, ACL support would be attributed to a module, and possibly an option in
the standard make config, but not "forced". No doubt we would all [most likely]
be happy with that.
You are right, though, that ACLs aren't important to everybody.
depends on your application. Some areas, ACLs are great...other areas, they're
nothing but a pain in the ass. I'm a bit more interested in splitting the
standard root capabilities into separate users, none with the same access as
the others; ex: user netdaemon having control over the ports 0-1024, locked
into a chrooted environment and having no control over filesystem, which would
be held by root or another account. User mount would have capability to mount
filesystems, but no real read/write permission over anything except what's
absolutely necessary. My interest would be in having a NOEXEC bit [like
on a partition] for directories, where you could have certain directories
specified not to allow any kind of executable file within, but would still
allow you to work in that directory. chmod a-x [directory] is a way to pull
your hair out (:
I also like the idea of rating items by confidential, classified, secret,
top secret, etc...but, that's just after having played around on B2 and B1
systems for a little while.
Linux reflects the needs of its developers (their itches, to use Eric Raymond's terms). High security and restricted access are not common needs for people who enjoy hacking code, and thus the extreme weakness of the Linux security model, of which ACLs are but one component.
Yeap, I might lose Karma on this one, but hey I'll die for "the greater good".
This is a non-issue - you can have those features Right Now.
The biggie I see is easier-for-newbies odd hardware support (USB, ATA66,100, etc), and the multithreaded TCP stack.
I want to delete my account but Slashdot doesn't allow it.
Never happen. Think about what syslog.conf would look like in XML(beleive me, I tried it).
I agree however that setting and retriveing persistant data stored as human readible conf files via a programmable interaface would be a big plus. The main problem is that the application developers don't give a damn about how programmatically accessable the data in their configs are. Someone would have to write parsers which is a major pain in the ass if the application's requirements change. I think someone would have to convince the applicaiton developers to require that the application itself actually use your programmatically smart configuration file component. Actually I think a lot of applications would welcome this. It takes off a little burden and presumably would cleanup the interface.
Then you could add support for XML separatly so that users have a choice(at a small cost in performance as your duplicating changes in two places).
NO! Linux doesn't need Wizards and paperclips... EMACS does!
If Mr. Edison had thought smarter he wouldn't sweat as much. --Nikola Tesla
If you really want ACLs (I know I do, but maybe that's just because I *like* ACLs due to tons of experience with it on NT), why not support the poor guys doing the NTFS-for- Linux driver?
The arguments about ACLs being too difficult is IMHO crap. They aren't. I've done a lot of stuff directly manipulating ACLs, and the only difficult part was finding out where the docs for the pertinent parts of the Win32 API were. Doing ACL stuff at API level requires that you know what you're doing, but show me a serious API that doesn't. I mean, come on - everything looks difficult until you've tried. Speaking from experience, ACLs were no harder to learn than sockets programming.
Black holes are where God divided by zero
Printtool is nice, but magicfilter's dithering seems to be much better, and it doesn't require a gui to setup (nice for a headless file/print server).
--
Soma: because a gramme is better than a damn.
Sounds a bit silly to me. Maybe car mechanics think all car users should be forced to repair their own cars. Or maybe we should all be making our own clothes, then we wouldn't have time to worry with this computer nonsense.
I've got a keyboard with a few extra keys at the top. I'd like to assign the keys to do different tasks. I've got buttons for:
Volume Controls
a button for starting TV software
starting a web Browser
CD-Rom Controls
a button to load a calculator
a button to load a text editor
etc. etc. etc.
I'd like to be able to assign these unused buttons to different tasks. Maybe a button to load an X-Term to my desktop, a button for my screenlock, mp3 player, misc. Batch files, or maybe use the windows start button to actually start a program!
< cough > VMWare < Cough >
If there isn't a linux program that would help me do this, I'd like to write it, but I'm not sure where to start.
Editing the keyboard map could be risky. Just imagine not being able to type your login password! I'm thinkin' that there should be a way to write a GUI based program that would let me click my mouse to abort changes.
If anybody has any suggestions, please let me know!
brad3378@NO.SPAM.hotmail.com
Frankly, I don't think that the real problem is in the kernal, I think we need more emphasis on appz that make not only Linux, but computing in general more user friendly.
;-)
For Example, Take a look at most Linux Newbies (such as myself), Most of us just go out and buy a computer from a brick & Mortar store if it's our first computer. So we try Windoze for a little bit. Once we start to "master" it, we decide we want to upgrade to linux, but keep windoze. Newbies need an idiot proof way to dual boot. System commander 2000 is a good start, but it's been pretty buggy and I wouldn't expect my parents to figure out how to download & install the patches.
I'd like to see an open source program that integrates the features of Norton/Symantec-Ghost, System Commander 2000, and Partition Magic. Hopefully with support for not only EXT2, but the Reiser File system as well.
Perhaps something that installs in MS-Dos.
Something else that would be cool would be a special Newbie Rescue disk. Suppose your Newbie friends buy a Linux box from Dell or Gateway. IMHO, both companies offer excellent support, but wouldn't it be great if you could just have newbies boot to a special floppy disk that dials the internet & creates a temporary helpdesk account? That way the help desks could remote login to the Newbie's machine, and fix most software problems themselves. Lets face it. Do Newbies want to learn how to recompile the kernal when somebody else could do it for them?
This just in > My sister suggested having dialup access during the linux install procedure itself. Then when I get stuck with something, some website, or person at SuSE in Germany could help me out for a small fee
I believe it's in our best intrest to get as many people using linux as possible. The main reason is for Hardware & software vendors to take us more seriously, and offer us more & better drivers & software.
After the release of W2K, Linux has no real stability advantage anymore
Stability ?
Stable like the American Warship that was running W2K during a training exercise and suffered the legendary BSOD?
That damn warship was dead in the water for at least 1/2 an hour...long enough to get sunk in a real emergency.
Remember the Y2K crises never happened, the W2K nightmare is only just starting
I can't imagine admin'ing a farm if I had to use XML for the syntax. It would make life harder, not easier, not because XML syntax is any more or less complex, but simply because it's more verbose. Yuck! Unix has become the flexible tool it is today in part because "everything's a file". IMHO, XML takes simple text files one step closer to the dreaded MS registry.
One of the things I would like to see is not so much what linux turns into. But that companies who make a cute new device from the get go have linux driver support.
So I suppose Linux needs to have a better module support for droping in drivers without having to recompile the kernel.
-- If i knew what i was doing i'd make sure not to do it again --
It doesn't matter if the actual process is just as easy. If the terminology and appearance of the installation program is different from Windows installation, they'll get confused and feel that installing Linux is difficult.
I've used Linux for seven years now. Still, it took a couple of attempts to get my first FreeBSD installation right (dividing the disk into slices and only after that into partitions was very confusing). Figuring out how to compile the kernel was another obstacle. Now in hindsight the FreeBSD installation process isn't any more complex, but because I had to learn it, it felt like one.
My main problems with XFree86 are its printer support and the antiquated font system. Also, the 3D support is suffering both from the bloat and the people who demand open sourced drivers.
Be ot or bot ne ot, taht is the nestquoi.
=)
Be ot or bot ne ot, taht is the nestquoi.
I believe smbd and ftpd can also be configured to give a umask to files created/uploaded into ~/public_html
---
Where can the word be found, where can the word resound? Not here, there is not enough silence.
"Where shall the word be found, where will the word resound? Not here, there is not enough silence." -T.S. Eliot
Things like what? XFree86 DOES have that control panel and res-change capability he thought was missing.
---
Where can the word be found, where can the word resound? Not here, there is not enough silence.
"Where shall the word be found, where will the word resound? Not here, there is not enough silence." -T.S. Eliot
The article is about Linux use as much as it's about the kernel.
---
Where can the word be found, where can the word resound? Not here, there is not enough silence.
"Where shall the word be found, where will the word resound? Not here, there is not enough silence." -T.S. Eliot
AFCArchvile trolls like this a lot, though most of the time I don't think he realizes he's doing it. He simply posts with a partial perception of the subject matter.
:-P
Had he actually looked into it he would have found that XFree86 4.x has pretty decent autodetection, xvidtune is his missing "control panel", and that ctrl alt +/- will change resolutions on the fly (although many window managers don't like sudden res changes at all... but that's a fixable issue they can tackle).
I can't really fault him though if he's coming from a win32 environment. He's spent too much time being spoon fed (or having stuff crammed down his throat, depending on your POV). Have some tolerance.
---
Where can the word be found, where can the word resound? Not here, there is not enough silence.
"Where shall the word be found, where will the word resound? Not here, there is not enough silence." -T.S. Eliot
Way to generalize in a bitter rant. :-P
---
Where can the word be found, where can the word resound? Not here, there is not enough silence.
"Where shall the word be found, where will the word resound? Not here, there is not enough silence." -T.S. Eliot
Permission masks.
Wow... that was a tough one, I should go lie down now.
---
Where can the word be found, where can the word resound? Not here, there is not enough silence.
"Where shall the word be found, where will the word resound? Not here, there is not enough silence." -T.S. Eliot
I know. I keep the misspelling so that I can cite my poor spelling as a personality trait and trademark, rather than an indicator of wasted education and deficient brainpower.
2 1337 4 u!
2 1337 4 u!
No, that's bad thinking if for no other reason that it leads to a slippery slope ("if you can't run your computer by flipping those pdp11 console switches...").
I'm an XML skeptic (it's that damn buzzword allergy), but honestly, the gnu/linux config system is an utter shambles. About the only standard is the # comment. Here's an experiment: Go download sudo (a fine and useful program) and install and configure it. If doing that doesn't make you scream for a gui-based config standard then you have faaaar too much time on your hands or you just get off on being macho-geek.
2 1337 4 u!
Actually, the values aren't calculated. Just for fun, grab a copy of Win9x and look in the WINDOWS\INF directory. Find an INF file for a video card and peek inside. You will find a list of video modes complete with all the numbers that a ModeLine in XF86 has; these are just hidden from the user in Windows.
Linux needs DRIVERS 4 Hardware. I've got a list of new hardware thats NOT supported as long as my arm. I don't want to go for second best because the kernel doesn't contain drivers for a peice of hardware. Plus, we need a organised system for submitting drivers and patches. Contribute to www.linhardware.com too.
Eat right. Stay fit. Die anyway.
Agreed. App installation is probably the biggest hurdle Linux has to overcome. There is simply no beating Windows until this is done, and done well. As of now, if one of my friends installs Linx for the first time, I have to go and teach them how to install software. Even though it's easy for a computer nerd, this is not the goal for Linux now. Linux HAS the computer nerd market. In order for Linux to be easy to use (Netscape should definitely help out in this) I have to be able to go to download.com, click on an app I want and have a window pop up asking me if I want to install the program. Then it should cutely install the thing witha a nice progress bar and put the damn icons on my desktop, my panel, in KDE or Gnome, whichever I happen to run (if I have both installed, cause I had no clue what to click during the Linux installation) then both desktop managers should receive it on their desktops or in their panels). I started using Linux a little under a year ago and I like it, but I was a bit annoyed when running Gnome, an app installation (i.e. StarOffice) would happily tell me that all the icons are installed in my KDE menu... I just wanted to cry. You can't use KDE or Gnome exclusively without giving up ease of use (that should be standard) for some applications. This should not happen. And the user permissions thing.. That needs to be masked with a wizard and an idiot's guide for parents or something. I know how it works, but my grandfather - who is emailing me every once in a while and sending me digital camera pictures from Windows - couldn't learn to use Linux if his life depended on it. MS is deteriorating, but Linux is not a replacement yet, and won't be until all the apps authors come to a concensus about app installation (or are given a standard) and something is done about the inherent complexity of user permissions. Enough said. Feel free to reply, but I have to get my DBMS assignment done and it's late, so I won't read them. Janimal p.s. Yay Linux! But I'm not the average user, and neither are you.
Yep. I don't post often. Insert
's where you think they fit.
Janimal
Newsflash: SAX is an API, not a parser. Parsers than implement it are not universally tested - you can neither garauntee nor define such a term. Nor 'well established' - XML is rapidly evolving, and 'backwards compatibility will always be maintained' is a common lie.
Newsflash: You ignored my point. Systems will be more stable with their parser code compiled in, so there's never a concern with interfacing with other process or the versions thereof. There's a reason system integrations is a 50 billion $USD business.....Whether that parser code is SAX-compliant, or reads rc files, or reads binaries, I don't care. Avoiding the interface to another daemon makes things possibly more stable - the progger can still fuck up his own stuff, but versioning and api incompatibility is the sisyphean rock of sysadmins. No shit, sherlock. Now who defines 'best'? If you were listening to the kernel people, not the app space people like us, you would note that 'best' is subjective to context - most optimized for common case, whatever the common case might be for your market niche. E.g., Linux doesn't perform well on 64 processors not b/c Linus is lazy but b/c Linux is optimized for less than 16 processors and fewer than 1000s of threads.
I can't tell if you talk that way or if you're karma whoring.
But more to the point - this is not a kernel-level problem!!! Go talk to the GNU crew - you need to slide this stuff into every library concievable - and by doing so you'll have the best chance to have it adopted by the other unices (which is really necessary in the long term - the unices won't stay splintered, history has shown). But as a kernel extension, this discussion is over.
I can fault you for stupidity, though.
Nothing to debate? My god, don't you realize that we have to implement these plans? Of course we have voice, and choice, and the ability to debate? What's the matter with you?
Moving on...
Oh, I've never seen this before - "you don't support every hurried implementation of my idea, thus you are an old curmugeon". Right.And just like the guy who posted just before you, you miss my point - I do not like to depend on another daemon, with associated uptime, API, and version conflicts, to load programs; given that you're talking about all the programs I'd be rather concerned. Want XML conf files? Fine - write them, pull some SAX-compliant parser source into your program, compile. Want to add another layer of maintainance to system admins?
OK - Most everything you've said is fair. True, I can't fault Linux for my lack of patience - but Linux can't fault me either; we'll just mutually not get along until one of us changes. All the stuff about linux not being at fault for specless hardware, true true. But the last paragraph I've got to wholeheartedly disagree with - one of the main reasons I wanted linux instead of Windows was so I could tinker with more of the guts. The whole reason lots of Computer Experts don't like Windows is that it's insulting to the intelligence, right? I absolutely don't believe what you're saying about configs being user-unfriendly on purpose, and were it true Id think it was an awful idea.
May be OT but improving [err... VASTLY improving] X would probably be the best thing to do if one hopes to see linuxes on average people's desktops anytime soon. I'd say dump it too but I don't know of anything to replace it with.
I'd kinda like to have it on my average desktop, if I may be allowed. Does this upset you?
Yeah. XF86 4.01 drivers. Which was not included in any of the distros I had access too last time I tried to install. Bad excuse, I know, but the first thing I want to do is NOT try vainly to figure out how to install a gui, without using a gui, right? You can tell I'm a Windows-educated loser. :P to you too. Don't be snide.
The reason it's moot? Ummm. Backward compatibility, maybe? What if RedHat, Mandrake, and Caldera, say, adopted this tomorrow? It would not only break many apps, many of which would silently fail, as another poster pointed out, but it would also cause code forks all over the place, require a cut-over period, no longer be Unix compliant, etc. Code forks and broken software are worse than the retraining of people, in my opinion. (Unix/Linux/BSD people are typically smart, by default.)
I agree it would be GREAT to have a standard, unified SAX (preferred) or DOM XML parser for our .conf files. It *would* eliminate so many problems and it would make admin programs such as Webmin, Comanche, Linuxconf, Yast, DrakConfig, etc. far easier to code, making the user-friendliness of Linux far easier to achieve.
But it would break so much and leave us non-Unix compliant. We simply CANNOT cut-over to XML tomorrow. This MUST be phased in, little by little.
A better approach:
Create a standard XML .conf parser/config tool/lib
Write all *NEW* software to *require* this, esp. for GNOME and KDE apps, but also text-mode apps and daemons
Get all your major software that is not "Unix standard" ported first to XML, such as Apache, Perl, etc.
Get your other apps and daemons converted, but allow them to run in either mode -- old .conf style or new XML .conf style.
Meanwhile you will need to write convertors. HEAVY testing, here!
The cut-overs (plural, very plural) would have to be done on a project-by-project basis.
This HAS to be planned to be done piece-meal and it's far more difficult than it looks at first, but it's worth it! We don't want to break things.
I'd totally agree that a single .conf parser is better than this mess of multiple .conf readers with multiple "standards" using SAX is a no-brainer. However, the old system works, so let's not just rush in. Let's plan it out and be careful to work with all the inidividual GNU (or whatever) projects are out there. There also needs to be one GNU project (not a million projects) out there to standardize and coordinate this for Linux, BSD, X-Open, etc.
Heck, invite X-Open, Sun, IBM, HP, SGI, RedHat/Cygnus, Caldera/SCO, TurboLinux, SuSE, Debian, Slackware, Mandrake, Storm, Torvalds, et al, BSDi, FreeBSD, GNOME, KDE, Apache, Perl, Python, Zend, Sendmail, BIND, Netscape/Mozilla, etc., to the same party and cooperate. It ought to be a POSIX standard!!!
If we don't do this, it will never succeed. We'll just have noble intentions, argue about it, and then fragment.
It seems to me to be a waste of mod points, to bring me down a point instead of bringing someone else up one.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
With XML, the format is standard,...
This argument doesn't hold for two reasons:
It's nice when it's legible as [a text file] though.
This argues against XML, not for it.
Sorry to nitpick, but it's really bugging me.
As you pointed out, X isn't really a part of the OS, so *nix can change resolutions without restarting the OS. Someone else pointed out you can (depending on your config file) change resolutions without restarting X, too.
Oops. I forgot to add the emphasis I allude to. I meant for the last quoted mention of "OS" to be bolded, but forgot. Sorry.
DUN?
Dialup Networking?
Or how about linux NT and RAS?
Silly slashdot, sigs are for kids!
How difficult is printtool??
Microsoft(tm) - a particular virulent virus that has infected most Pc's.
I agree with you, partially. ,JFS's are important. Since I never workked on AIX I can't confirm wether JFS is really that horrible on that plattform.
I'm very aware that JFS's don't make RAID and Backup irrelevant. Still JFS's at least save you time after a crash and I think the still provide higher data Security because you have the Journalling Log, but probably you are more competent on that field
I still think
However, if you look at ReiserFS you will see it is fact very fast and reliable.
However even if some or another JFS becomes the standard with Linux that doesn't mean you have to use it.
And stating you dropped AIX for Linux is quite ridicolous because the two don't really use the same hardware.
"Mommy, mommy! The garbage man is here!" "Well, tell him we don't want any!" -- Groucho Marx
I believe that the future of *nix may just lie in the desktop market, but will always have a nice seat in the server market. Apple has already taken a leap with OS X. One of the problems right now is that linux is not exactly a newbies cup of tea. Another problem is that many people are not well informed of the advantages of *nix to other OSes, allthough *nix still needs a lot of work in the GUI department, hopefully OS X will help that out. But for the most part there is no real advantage for a newbie, or even some "power users" to run linux over win 2k right now, due to the fact that 2k is pretty damn stable (relative to win9x).
--I am the end of all that there is, was, or will be. I am destiny, I am the fate that awaits you all. I am the apocalypse, I am the answer to the final question. I am the last page, I am the author, I am he who will burn the book when its time has come. I am the key to the final door, and I am the void that lies beyond. I am the corner of the sphere, the end of the circle, I am the point where parallel lines will meet. I am your most hideous nightmare, I am your final nightmare. My voice shall echo in the vast emptiness as infinity comes to an end. The streets will flow with the blood of children, and the highest-soaring birds will drown in the burning red river that rises. I am, and shall be when all else is not. so, like, i don't give a shit about prekies.
I thought I read it wrong, but propably this man just isn't one of those....
Earnings, Future Earnings, revenue growth and profit margins. The analysts don't like any of them. But the company is still worth 1.53 Billion - a lot more than VA
I think that the biggest challenges for Linux are 1. Scalability (Linus seems more interested in laptops) 2. Security - there is a percieve lack of security from the corporate world and I realize that most of the security issues are actually from applications 3. Management tools - Management tools for multiple machines are rudementary. A system for management of 1000s of linux machines with one click would be nice instead of everyone writing their own perl scripts
Global Filesystem or some equivalent method for allowing simultaneous access by multiple systems to the same physical filesystems.
Improved traffic management facilities, preferably class based queuing, with some better user space tools for managing it(yes, I know the tools aren't really a part of the kernel)
ACL's ACL's ACL's!!!!!!
Shared memory architecture integrated with stock kernel for clustering. Would aid greatly in HA systems.
Quotas. Improved quotas that happen at the VFS layer, rather than in the actual fs layer would be dandy. Even better would be combining such a system with the Shared Memory architecture mentioned above thereby simplifying clustered solutions.
Hooks allowing online filesystem checks as much as possible.
I'm certain there are more, but those are the ones currently most needed in the enterprise area as I see it.
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.
It's "Bill Gosper" (note spelling)
arnald
This change will not result in having one set of tools too - each config should be edited with its own specialized tool (but there will be single config parser).
I think configs will finally be converted to XML, but you will have to edit them with special tools after that, not by hand.
MSDOS: 20+ years without remote hole in the default install
Yes, everyone should start moving config files to XML just like Jabber! But DO NOT put all configuration in a single file! That's asking for trouble. Its likely that the File Statndard will eventually include keeping config files in the same install directory of the cooresponding app (excluding system configs of course) with only a link existing in the /etc directory. This is how help and executable files are done (or at least supposed to be done). So I expect config files will move in this direction eventually too. The nice thing about this is that we will eventually be able to seperate the OS, Apps and Data on three seperate partitions each independently restorable. Currently the OS and Apps are too intermingled, though Linux is better at it then Windows :)
:T:R:A:N:S:
Linux is a Herculean task taken on by multiple teams to create. Now this is a way to bring it up to par with other OS for easy of configuring. Yes, all will not convert. But the majority will follow the kernel if the kernel goes first. Teams that don't bring their code up to the standard will slowly loss out. The best (or most willing) will win out.
All files are truely "flat" files. That goes for programs, the kernal, and databases. It is a handle to data stream.
What most think of as a flat files is "data" structure (or something on that line depending on OS).
XML is has structure that was imposed over that that flat file structure. That makes it no more a flat file then HTML another example of strucute that was imposed over a flat file structure.
The DHCPCD client is not that good. It does not handle passing host name as configured - hence you immedatily have to fix that so it acts right in a windows network (like most offices). It does not handle at all: domain name changes, ip changes nor fixing samba to be a good M$ citizen.
DHCP is one of those things need to fixed so more offices will feel "safe" bring into the their network.
Just so you know - I am using DHCPCD on 4 different linux boxes with either redhat6.2 or caldera 2.3. I have had to hack the DHCPCD client everytime.
The issue is simple.
/var/run/dhcpcd-cache.${DEVICE}
/var/run/dhcpcd-${DEVICE}.pid
/etc/dhcpc/hostinfo-${DEVICE}
/etc/dhcpc/resolv.conf
/etc/dhcpc/network
/sbin/dhcpcd -h ${MACHNAME} -c /etc/sysconfig/network-scripts/ifdhcpc-done ${DEVICE}
/var/run/dhcp-wait-${DEVICE}.pid; exec sleep 30" | sh
/var/run/dhcp-wait-${DEVICE}.pid ]; then
/var/run/dhcp-wait-${DEVICE}.pid
/etc/dhcpc/hostinfo-${DEVICE}
/domain/b -e d /etc/dhcpc/resolv.conf | sed -e 's/domain\ //')
/etc/hosts
/etc/hosts
/etc/sysconfig/network > /etc/dhcpc/network
/etc/dhcpc/network /etc/sysconfig/network
the 015 structure in DHCP, tells the client the name of the domain that it belongs to. My boxes are portable (client's locations and lug meetings), when I connect into a local network - my box should appear as a member of the network - down to the domain name, which the 015 tells it about. Then entering a "joe" will be expanded to "joe.domain.org" and ping and the rest of tcp/ip tools work right.
006 tells where the dns is. The same goes here the resolve.conf is not being updated.
IP and Netmask do not get updated in the hosts file.
And lastly Samba is a problem, since it correctly connects to wins, if it is on the network the 044 tells the story here.
This all need to work correctly if a linux be givne a full chance to replace large number of boxes in a windows base network.
redhat 6.2 hack: (allowed box to connect any DHCP server and get most right. Still have to do a sed on samba.conf)
OLDHOSTNAME=$(hostname)
OLDDOMAIN=$(domainname)
MACHNAME=$(hostname | sed 's/\..*//')
echo "${MACHNAME}: Removing old DHCP files"
rm -f
rm -f
rm -f
rm -f
rm -f
echo -n "Using DHCP for ${DEVICE}... "
IFNAME=${DEVICE} \
echo "echo \$$ >
if [ -f
echo "failed."
exit 1
else
rm -f
echo "done."
IPSETUP=yes
.
DOMAIN=$(sed -e
HOSTNAME=${MACHNAME}.${DOMAIN}
echo "Old: ${OLDHOSTNAME} ${OLDDOMAIN}"
echo "New: ${HOSTNAME} ${DOMAIN}"
echo "127.0.0.1 localhost" >
echo "${IPADDR} ${MACHNAME} ${HOSTNAME}" >>
sed -e s/DOMAINNAME.*$/DOMAINNAME=${DOMAIN}/g -e s/HOSTNAME.*$/HOSTNAME=${HOSTNAME}/g
cp
IPSETUP=no
fi
It is the heart of kernel.
How is the kernal made?
How are the options stored?
How are run time options passed?
Can you add to the list?
The kernel is a series of routines - sorting, searching, processing data. Like any other program, just happens to "run" the machine.
Why is the kernel exempt from the same standards we would want from the rest of the machine? If the kernel was configured via XML, the rest of linux would follow the lead.
From the tux.org faq What are the plans for future versions of the Linux kernel? (ADB) Linus would be the best person to ask, but I don't know if he would have the time and patience to answer this question. There are some development issues that can be mentioned, though: PnP support in the kernel. Right now one can get PnP support using the isapnptools user space package and manually tuning the I/O, IRQ and DMA channel allocation, but future Linux kernels will do that for you. Improved SMP support. Improved 64 bit code support. Improved POSIX support. Improved APM support. /I
Just so you know--Samba has nothing to do with DHCP. I don't see what you expect dhcpcd to do about that.
Domain names have little, if anything, to do with DHCP. The goal of DHCP is to automatically configure domain resolution (specifying name servers to use), routing (gateways and netmasks), and unique network identification (IP addresses). This does not depend on the domain you belong to. The fact is, Microsoft does not address this problem in their DHCP implementation, either. If you specify a domain you belong to, it is fixed, and you must specify name servers along with it. With dhcpcd, you can communicate with the outside world... That is all DHCP aims to do.
What are you talking about, IP changes? When do you expect your IP address to change? The dhcpcd program updates the IP address whenever it is run, and whenever a lease expires. I think this is the most you can ask for from any DHCP implementation on any platform. IP addresses should not change mid-lease. That's bad network configuration.
dhcpcd implements DHCP, not miracle-networking. It won't configure samba, it won't act as an FTP server, it won't do a lot of things. But as far as I'm concerned, dhcpcd implements DHCP as good as, or better than, any other program. What kind of hacking do you need to do to it?
I do not belong in the spam.redirect.de domain.
I have a similar list of complaints about using Linux "to get the job done." A couple of years ago I tried to setup Redhat 5.2, and I eventually had to stop using it because I had so many little problems I just didn't have the time to solve. (1) Netscape would always print halfway down the page on my printer. I imagine there is some nice fix somewhere, but I couldn't find it. (2) I never got my 3.5 inch floppy to work. For some reason the default install never configured it and I didn't want to play with obscure and poorly documented config files. (3) I tried to install Licq and of course there was some dependency problem that even downloading an updated versions couldn't even cure. In my opinion, Linux needs to work on more documentation that is included within the config files for people who generally know where to look, but don't have to time to play around with settings all day. I'm sure the answers to my problems are nothing more than a few simple changes, but I do not where to make those changes. Linux may be free to download, but it will cost close to windows in terms of the cost of books one needs to properly configure it.
Cool new hardware/product never work with it. I mean it tooks ages before Linux supported USB or Plug'n'play device. People don't want to wait months to get their stuff working.
<usernumber>221</usernumber>
<password</password>
</user>
? or what.
--Giving to trolls for the benefit of us all
Oh, and with meta data being kept in the file system (as of 2.41, I think?) a database would hopefully be made redundant as one could store any field of data as a file.
Ten years ago I would have agreed about text being used for configuration being wasteful (in comparason to binary?), but storage space is nothing these days and the benefits of any plain text editor are excellent. The time spent for most applications parsing text vs binary is neligable and I would much rather face configuring a well commented text file than a binary.
--Giving to trolls for the benefit of us all
What does the XFree86 Project have to do with the Linux kernel?
--
An XML parser exists: libxml. It's technically a GNOME library, but it doesn't depend on any GNOME libs, so it can be used by people without gnome just fine.
The main question, at this point, is converting the myriad types of configuration files over to xml -- and converting the apps to use that new configuration file. If you think about it, almost every app uses a configuration file, and many apps have their own, unique file format. Converting everything over to XML would be a truly Herculean task.
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 because it doen't like one line, it just becomes so exasperating.
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.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
Configuration file formats aren't really a kernel issue though.
rwx is one of the core faults left in Unix derived systems. It's a leftover from Unix's roots as a tty input timeshare system from 30 years ago with the assumption of a limited number of mostly trusted users. Unfortunately, nobody is willing to change it.
- Nobody really wants it
- It is too hard to implement (and even the "flexibility is bad" version!).
- It would introduce some undefined security hole
These work on Pointy Haired Bosses but do you think that really describes this group?Sorry, it really was a bad idea to tell people to goto freshmeat and do a search, heh.
:P.
I uploaded the 'command.txt' file here, so you can go there to read it.
It's prolly pretty slow, but it works... give it a little while.
Sorry about the delays
I have hated graphical user interfaces for a long time.. and then I came across a document that put my reason into a well formatted document..
goto freshmeat, and search for "butt".. its some program that has to do w/ like speech synthesis or some other audio thing, but thats not what I care about it for.
In that download, there is a file called 'command.txt', i believe it is. It discusses, as I said, why command line interfaces will always be better than GUIs.
I think there should be a "thinking in linux" type of documentation thats installed on every distro, modified for each particular distro. just to give newbies enough information to begin to learn for themselves. the best thing about linux is that you become a really good researcher on the web looking for information you need.
-- Cheer, Cheer, The Red and the White.
This reminds me of the venerable battlehorse of the air, the McDonnell-Douglas F-4 "Phantom II". It was designed and built for the single role only of intercepting enemy bombers as far away from their aircraft carrier as possible. Over a timespan of thirty years, there has hardly been a task in the air that Phantoms didn't master. The reason is that the basic airframe seems to have had a lot of reserve capability, and modifications and improvements were easily applied. And they are still in use today... sounds like Unix?
-- H. Wilker
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.
The whole point of using XML would be to have a common config file format. It's on top of a text file, yes, so are most config files. It makes them much easier to edit and use. If you want to be technical, everything is just a glorified text file. It's nice when it's legible as such though.
With XML, the format is standard, which would make it easy for apps to interact with all sorts of different config files, but it's also very extensible, so it could easily be tailored to suit a program's individual needs.
I would like to think that my situation adds some import to the future of linux. I began with linux, as most do, from home. Having a love of computing, linux was the easiest and most enjoyable way to dig deeper. My interest in linux led to a job as a unix adminstrator for systems running HP-UX. Now, I am starting to integrate linux into the company. The main reason is money. I am building linux machines for non-critical necessities on PC-based hardware. This is costing very little to the company, so if there are failures, the loss is small. I'm watching linux grow and grow but will say honestly, that it still isn't up to par with a commercial UNIX system such as HP-UX, nor should one expect it to be! However, it is getting there quickly because it can co-exist with an already established network without denting the budget. As for the desktop (home-use) market, I have no idea. I have no interest in that. But for the server market, I believe that, if not linux, the ideas behind linux, will continue to flourish at the same pace it is now.
The Windows registry has a commercial purpose: It provides copy protection. That's why it is implemented in such a confusing way.
If the config data for each program were stored next to the binary for the program, it would be possible to copy the program merely by copying the program's sub-folder. The registry prevents this.
Corruption in the registry may corrupt the entire operating system. In a commercial OS, in a world in which the OS maker has a monopoly, occasional corruption of the OS is seen as a good thing, because it gives the users a reason to upgrade.
Some commercial users will probably not want to use a UNIX system without journalling, whether it is rational or not. But I hope JFS and the like won't become the standard on Linux: I switched to Linux in part because I found AIX's JFS so intolerable.
I think it might be worth considering switching to XML for many system and config files. That preserves the traditional UNIX approach of having files that are user-readable and can be modified with a text editor or scripts. But it would add the capability of having a single set of tools for dealing with things like network configuration, PnP configuration, firewalls, /proc information files, etc.
... is that you can prove anything at any time.
Imagine the user has no access to a Commodore 64 and that he absolutely needs to access an old copy of The Hobbit, how else are you going to achieve this than by stealing the one or the other wallet?
Which proves the case exhaustively.
Hmmmm, oh I know!!!! Let Linus keep working on the Kernel© The GNU side of Linux is starting to get better as it is© Now, I will stop talking/posting before I get flamed again©©©Besides it hurts© =
From Zero to Hero... Starbuck Zero
Hmmm, I have Mandrake 7©1 and it's easy to use© If you want something easy to use© I would download/buy that© I understand where you are coming from and I feel your pain© Not knowing how to setup my Geforce 2 card that is and I had to look around© I got it setup and the games run like a dream, but I don't want it to be that hard© This is not the place to post something like that© You could go to GNU/Linux people and say something like this© Maybe that could help©©©
From Zero to Hero... Starbuck Zero
but not to all©©© I'm using Windows 2K now and it haven't crash on me and I haven't had any lockups© Now let's take a look at my computer and you'll know why©
Starbuck Zero's Computer:
P2-400Mhz
224MB of Ram
Geforce 2
10 GB hardrive 5 for Windows 2K and 5 for backup©
All my hardware Windows 2k found normally© One thing I will have to say that Windows 2K is a Workstation as in for work! Yeah Windows 2K as for the rest of MS oprating systems will run great now that they patch it up and they are not using 16-bit code© That's the thing tho, by them dropping the 16-bit code makes it so I can't run some programs I would like to run in Windows 95/98/ME and at the sametime I can't run most of the games/programs I want in Windows 2K©
Then again I'm using this for work¥cool project some slashdot folks would like but it will come a time when I will have jump back into Linux to finish this© I know for a fact that a home user don't want to pay over $200 for a clean damn oprating system and at the sametime can't run all there old programs and hardware doesn't match up© That's why most haven't switched at work© If you get Windows 2K like one of my friends you could end up going out and buying new hardware to meet Windows 2K standards© What!?!? Going out and buying new hardware Starbuck!?!? Yeah, and people was thinking Linux was bad© Most of the people at work can't switch because of the projects they are working on and the same thing goes for Office 2k© If you ask me Windows 2K is a great OS and I don't want to down grade myself to Windows ME anyday© I don't want to lose data that's the main thing with it comes to the project that I'm doing now©
I hate to say it I still use Windows for some of the programs they have that are hard to find in Linux and for beta testing projects from work© I figure if I'm going to do it, why not do it in one that don't crash for a change© I still see my friends crash and lockup in Windows ME and with the new Whispers or what every MS is putting out will make it hard on most companies/users when it comes to upgrading and because with that they drop the 16-bit code©©© I don't know what else but it ain't good©
From Zero to Hero... Starbuck Zero
In terms of stability, take a look at Netcraft. The microsoft domains have average uptimes of around 13 days (except Hotmail which is mostly FreeBSD). At the same time SuSE has an average uptime of more than 100 days. One should note that Minux is very big now adays in the ISP and ASP market.
While W2K is called "User Friendly," it hides the processes from the user/administrator like all other Windows systems. I call this "Dummy Friendly, Adminsitrator Hostile." Linux is no less user friendly AND it is far more Admin friendldy, once you get used to it. Case in point: I have set up a Linux system for my parents as their primary workstation and have recieved fewer "How do I?" calls then I have on the Windows 95 box that they have had for years. OF course, I have it set to boot directly into HelixCode Gnome and have the desktop organized so that they do not have to know much. People call be crazy for giving them such a system, but the result is that they like it MUCH better than their Windows 95 machine.
LedgerSMB: Open source Accounting/ERP
Honestly, the conf files can easily be parsed, at least as easily as XML, and it could make the files harder to read. FOr tools that configure such files, look at SWAT (for Samba), LinuxConf (for almost anything else). As far as testing the files, see testparm (for samba). If flat files could not be easily parsed, could they even be easily used for configuration of programs?
LedgerSMB: Open source Accounting/ERP
Who says they have to be? This sort of thing is caused by laziness by people who don't care to carefully adminsitrate Thier machines. It is very possible, albeit a small bit more work, to design a set of Daemons which operate in the rwxs permissions with only the permissions that they need. How? Accounts can be created with special permissions, added into groups which administrate the exact permissions needed (according to various groups).
ACLs are only necessary when two groups require different, mutually exclusive access to the same file. And even there, alternatives exist.
LedgerSMB: Open source Accounting/ERP
What kills most good products is marketing and business practices (remember Commodore?) not a lack of usability. Yes, ACLs will probably soon make their way into Linux because they are useful. But the innovations in Gnome, KDE, BeOS (for that matter AmigaOS) will not become a part of W2k despite their usefulness.
LedgerSMB: Open source Accounting/ERP
What happens if Postgres crashes in your scenario? Are we to reload? No. It is better to keep the configuration files in *human* readable form. Furthermore, how are we to configure postgres?
I argue that the flat file config files are a serious advantage for Linux right now and should not be lost.
LedgerSMB: Open source Accounting/ERP
Which hardware runs AIX and not Linux? Not the RS6000 series. Seriously, one area where Linux is doing well and needs to continue to expand is the bredth of types of devices capable of running it as a full operating system, from PSAs to large Beowulf clusters. Linmodem support is necessary, and USB support will make a great deal of difference. The kernel needs to do what kernels do best-- coordinate hardware.
LedgerSMB: Open source Accounting/ERP
first, the ip address changing to 169.x.x.x isn't something new to win2k. it does it on win9x boxes, too. second, i don't think an extra two megs of kernel memory is too much extra considering everything that win2k does over nt.
-{linux is user friendly, its just pickier about its friends}-
I think the most wanting thing (from a non-hacker user perspective) is an easier way to install new/different 3D drivers for their vid cards. My GeForce DDR is schweeeeeeeet in Linux but it wasn't something I'd expect my Ma to be able to install. Not that it was hard, it's just not standardized.
Most of the people I know who are _not_ trying out Linux right now are not doing so because they can't play games too easily. F..k MS Office, home users want games. And Applixware kicks Office' ass anyway.
Seriously - I build my own kernels but I'm not sure this is a kernel-related suggestion. A more standardized interface for new device drivers ? Big-time requirement for users not interested in unusual 'ln -s ***' gymnastics.
About ACLS - we use AFS here at home and ACL's are nice and cool to work with. I would not, however want them to replace the standard UNIX file permissions system.
Just my 2 cents - this is a great OS and I hope it continues to improve!
The heat from below can burn your eyes out
I don't know why people keep complaining about XFree86. I think it's F'in awesome. It's blazing fast, responsive and stable on my machines here at home (1 @ 3.3.6 and mine @ 4.0.1). The ability to export displays all over evolution's green playground is too cool.
:
:0
Like BeOS - cool - use it.
Until you can come up with an actual, factual, reasonable detraction for XFree86 please don't eat up my bandwidth.
Maybe it's your window manager ? I use blackbox and X/Blackbox use
root 8807 0.9 9.6 276116 12404 ? S 10:05 1:13 X
johnnyb 8809 0.0 1.3 3144 1776 tty1 S 10:05 0:03 blackbox
and that's with 8 desktops filled with applications. This is bloat ??
Oh Martha, buy this young low-watt bulb a clue . . .
:)
The heat from below can burn your eyes out
Agreed - DirectCD is the only thing I miss from Winlimp. Oh, and Brood War too, but thats hardly kernel related :)
The heat from below can burn your eyes out
sorry, no text
The heat from below can burn your eyes out
People keep complaining about X and I don't understand why. Mebbe you should try some different window managers ?
Note that I've built GUI apps in GTK and Qt (preferred) and I think X is fine.
Please advise on exactly what is so bad about X.
The heat from below can burn your eyes out
Just to clear up - my post was not meant to denigrate BeOS - I've used it and it was cool, just not my bag.
I'm interested primarily in what exactly the problems are in X that all these bitchin' Betties are on about.
?
The heat from below can burn your eyes out
when you are running binary drivers, *NO ONE* will support you
NVIDIA was very helpful via email and helped me find some errant Mesa libs that were slowing my performance down.
sell that Nvidia product to a hardcore windows user or better
Not on yer life - this card rages in 3d games in Linux (Quake3, Descent3) and I have had zero problems with it.
I personally send kudos to NVIDIA - they support their product absolutely for Linux and they helped me out a lot. Even offered to call me if need be. I learned a lot about my system working with them and I think they're doing a great job.
I don't mind closed-source products if they work right. I bought the card and it is supported. Indeed, the reason I bought the NVIDIA card was their support and they came through in spades. How can they open-source their drivers when they don't own OpenGL ? Bitch at SGI, not NVIDIA.
I basically agree with you but I tend to shirk my open-source idealism when it comes to something like this. NVIDIA makes a great product, I paid for it, and they supported it.
Hats off to NVIDIA - I wish every other hardware vendor would support the Linux market like they do with their excellent drivers and their excellent support.
The heat from below can burn your eyes out
Note please that my card is actually a Creative Labs product with an NVIDIA chipset. Creative Labs wouldn't give me the time of day - indeed they told me to stick to windows. After I hurled about 30 seconds of profanity at them (which was entertaining, no end) I emailed NVIDIA and they totally, totally came through for me.
I dig the open-source ideal but that doesn't mean all closed-source products are for shit. Especially if the manufacturers support their product.
Just my 2p.
The heat from below can burn your eyes out
Have you ever tried the Debian GNU/Linux?
Look for GNOME-APT. Then you could say something about installing software on GNU/Linux.
"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."
" one of the main reasons I wanted linux instead of Windows was so I could tinker with more of the guts"
I'm still trying to figure out how the person that wrote the first 2 paragraphs also wrote the 3rd.
Knowing where the config files are is getting to know the guts. Learning how to find them is a skill everyone should have. If you don't want this , you probably aren't really that interested.
If you can't answer some of those questions, you probably aren't as knowedgable in General Computer knowledge as you think. Don't mistake Windows Proficiency as being computer literate.
This isn't a knock against you. I'm sure you're pretty good on Windows and at least starting to find the limits of Windows. Your experience is more a reality check. What do want to do, learn more or be able to use without learning anything? If you want to learn more, then you've got to push the limits and do for yourself. If you just want to be a user, stay where you're familliar and comforable.
either way, the doors open when you're ready come on in
You're right, 2.4 isn't ready yet. However, its currently at 2.4-test10, which means it is in the final testing phases, at which time Linus will simply remove the -testXX part. 2.3.99-preXX hasn't been used for some time.
Check http://www.kernel.org/pub/linux/kernel and see for yourself.
"I manage twelve Win2K servers (both Server and Advanced Server) and have only had good exepriences with them. In fact, since their installation this past summer, I have only had to reboot one of them once due to a home-grown application error, not an OS error."
Applications are not supposed to affect the operating system at all. It sounds like Windows 2000 STILL doesn't have protected memory.
i'm not so sure about your port idea. that is ridiculous! so now i as joe-user can start up any server, like a trojaned ftp or telnet or ssh, on those restricted ports and capture passwords and data as it flies by? that doesn't seem very prudent.
And in general linux needs more standards: a single way and place to store the mime settings, a single desktop menu system where programs can install their launch icons. These things (and there are more...) are techically simple but when implemented can have a huge impact on the usability of linux.
In addition the distros could also try to unify some features where there are no technical reasons to differ. (Examples are the Init startup system and the placement and naming of config files).
How about a "Distro Foundation/League" or something where the distros could officially discuss and dicide on these things!
Ideas? Comments?
oops, sorry about the BeOS sig appearing twice... I forgot I was on HTML mode.. :o
---
Can someone come up with the a cleaner/faster/better architecture than this bloat called X? BeOS rules because of its desktop and its responsiveness. If Linux find the backers to completely drop X (and yes, losing backwards compatibility unfortunately) and create a new Windowing System, then, truly, Linux will be ready for the desktop (and of course making easier the compilation of the apps/kernel for the newbies) --- BeOS Quick Intro: http://www.ukbug.org/beos.html
---
"without a corresponding "standard" to describe the structure the file should have. If you want regularity" Actually, if you want regularity, I'd suggest Metamucil - in the orange flavor that is.
Where's the beef?
I think linux is quite done, especially with the 2.4.0 kernel coming out with USB support. Linux has staroffice, real player, etc apps that windows users would want. All linux needs now is some *quality* apps and fix the little details for dirivers for printers etc.
Visit my website xpenguin.com -- A linux penguin website
Very good thought, and LinuxSecurity interviewed Slava Zavadsky who has already implemented them as a project entitled "Linux Trustees Project":
a ture_story-60.html
http://www.linuxsecurity.com/feature_stories/fe
I have not used them, but maybe somebody else has and would like to comment?
Coming from a mainframe environment here, but the lesson is a valid one. Once the operating system (MVS which became OS/390 which is becoming z/OS) implemented the Security Authorization Facility, all sorts of other software used it - and we benefitted from one common interface for controlling access lists. This was done in a non-proprietary way. The OS implements SAF in a way such that any vendor wanting to provide the software behind it, can, while the interfaces for programmers remain the same. We have competition, in security packages, from IBM and Computer Associates mainly; this helps keep things improving. Yet you can switch from one to the other without major impact to your apps - because the API for security is the same, and part of the OS. I think any enterprise-level OS ought to do something similar.
If you think this is meaningless, if you think this is of no use, you are welcome to uninstall libxml from your machine, write a parser for every program you develop, and have it promptly ignored by the general community.
Its your call. Personally, the one thing I enjoy less than UI code is code to translate and interchange data between apps and systems. XML solves that problem and allows me that much more time to be productive or goof off.
--
--
Eat right, exercise regularly, die anyway.
REPEAT: The question is what does the future hold for linux, not Wolenczak's impression of W2K. W2K works very well with or without Wolenczak, thank you very much. Linux doesnt. What are we going to do about it?
At the top of my wish list for Linux is: slaughter all the sheep in the fold and give Linus the proverbial watch.
(Not picking on you specifically, btw, just the knee jerk W2K sux reaction that's typical in the Linux camp.)
--
--
Eat right, exercise regularly, die anyway.
You wont have to edit xml by hand. You can edit it in an xml editor which displays the tree for an xml document - markup, content, and comments. It will be driven by a xml parser and it will be capable of displaying any and every xml file you care to throw at it. Do a search for merlot, swish, XMLEditor. Marvel at the screen shots.
So its not a clear Win-Win, obviously.
It would be if the only objection was the one you raised.
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.
This doesnt make sense. XML is a markup language that facilitates the transfer of information and its presentation. What's being transferred - in the unix world, anyway - will remain out the newbies reach just as it always has.
--
--
Eat right, exercise regularly, die anyway.
--
--
Eat right, exercise regularly, die anyway.
I think Helix's Red Carpet will make installing/removing programs a breeze. Aside from that, you can't beat APT for simplicity and power.
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.
yes i realize this. pardon my shorthand, and I'm certain you got the general idea of what I meant here. I also realize there are a plethora of rtos choices, but those promise dominance and are delivering, at least inasmuch as public opinion and hype...
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.
sorry, the directX and hardware support under w2k mops the nt4 legacy into the floor drain at your local starbucks. but I guess that depends on the workstation needs. personally, I'm thinking of graphic endeavors like 3Dstudio and Maya, + all the groovy usb hids like the new wacoms. suer this stuff largely works under nt4, but that support is often just an spX hack. plus, w2k is soooo much easier to administer.
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.
granted osx is unproven, but a damn, gotta go to brunch now! be back later. besides, I have similar light arguments for the remaining answers. the point is, these things are close enough to be argued in the first place, whereas LINUX doesn't really factor into the discussion at any point, huh?
>oh yeah?
Solidus Fullstop, Esq.
"hey, you stole that sig from me!"
the future of linux is in plastics, son. the kernel is like 'the purr of a cat' whereas w2k is more akin to the firm haunch of your favorite work mule. INTEL IS THE SKELETON of that mule. MCSE's are the blood and corpuscles and select bladders of said mule. linux has no mule yet. only a hairball and WE'VE CAUGHT A MOUSE OR TWO. as you can see, linux will fail until we evolve it to the level of a least a middling-sized dog or goat.
But most of you probably don't like or appreciate non-sensical and groggy morning-time farm-animal analogies and/or house-pet metaphors about OS advocacy. Just keep in mind the principle that oblique strategies uses, wherin a human hears something vague or cryptic and attempts to map meaning to that sentence!!
Otherwise, [li,u]n[i,u]x projects will gradually dissapear now that osx, w2k and the upstart alt-OS's of QNX and BEOS are maturing and we are seeing those OS's implemented throught THE WORLD.
here's a little comparison chart, my friends, of OS uses and the dominant or best choice of OS in each category:
embedded: QNX, Beos
workstation: w2k,
small office server: w2k, novell, osX
web server: *BSD, w2k
realtime: Inferno, QNX
games: w2k (+aka "whistler")
there AREN'T ANY MORE CATEGORIES AND LINUX DIDN"T MAKE THE LIST ONCE. sorry. we'll have to try harder. this is the problem with linux, there is no vision of where to succeed. People all have different opinions of where it should go, there are mobs of developers pushing linux to dominate in EACH OF THOSE CATEGORIES, and meanwhile, offering sub-standard maturity in each rather than displaying a modicum of discipline and really cranking out the useful crap. I hope everyone can see where this mob-managed software project is falling short!
>oh yeah?
Solidus Fullstop, Esq.
"hey, you stole that sig from me!"
Sure, W2k is good. It's nothing but rock solid on my work machine. Of course, all I use it for is web browsing, MS Office, and the occasional tera term pro telnet/ssh connection.
When it works, it works FUCKING GREAT.
But every so often... it won't work. From my point of view (as an admin and pc tech), that W2k behaves alot like a finely tooled car engine... work wonderful, until a small part breaks. Then the cascade comes down, and the whole system goes down.
Although, I have to say the weirdest W2k experience I've had yet is that I got a BSOD on a laptop when i plugged in some RJ-11...
And if someone knows... please for the love of god and girls tell me how to stop W2K from 'hiding' menu options that i "haven't used lately"!!!
(Its this sort of bullshit annoyance that makes me love linux... most distros/GUIs/etc. are more flexible and configurable.)
So in other words, you wouldnt want to wait for the best kernel with no bugs, instead have a new release every x number of weeks? come on, thats the microsoft philosophy!
I ditto this. The idea of making absolutely everything in computing based on text is wasteful. I agree that flat files could be improved, but why does it have to be XML? Why not have some database (term used loosely) which could be queried much faster, and perhaps easier than XML.
I have to agree. I consider Linux a much more stable platform to work on in most cases and it definitely performs better, but I just don't have the time to sit down and learn it well enough to use it. I can't really code, but then for my job I don't have to. In most industries the standard desktop is usually Windows or MacOS, (science is one big exception here) and there is a reason for this. They are very intuitive for most people. You can sit down and use it immediately. If Linux wants to compete on an even platform with the industry leaders, their going to have to make it easier to use. I've tried Redhat and Corel for it's supposedly all encompassing GUI interface, but there all it was was a beefed up x-windows which let you explore like Windows Explorer. Don't get me wrong, I want Linux to keep its smaller size and better performance, but to take a lesson in ease of use from MacOS or Windows. Just my 2 cents
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,
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.
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
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.
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.
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.
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
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.
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?
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.
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 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
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.
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
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.
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
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