kchuid is an experimental Linux kernel module that allows you to change the UID/GID/CAPS of a running process (by PID). Think of it as providing a setuid() system call that also has a pid_t argument. It's the first step in a full authentication system, and further, a full Unixish system devoid of setuid binaries/scripts.
i personally like djb's approach; programs don't seem to rely much on environment variables, and everyone seems to like to write parsers.
Well, this isn't really a problem with configuration consistancy- because we actually need multiple interfaces for configuration (graphical, commandline, network, etc). Some interfaces are non-interactive, and these can survive with offline documentation and/or scriptability. Others rely on interactive, and require much online interaction with the user. More importantly, a bridge needs to be made that allows the configuration to "describe" the interface in this respect.
Obviously, XML is a grand choice for this- because it's designed (more or less) for exactly this purpose. Of course, we could roll-our-own (like the linux kernel people did) and we might be able to simplify parsing, but the truth is that the hardest part about building a unified configuration front is not in the design, but in the integration.
Whatever it is, it must stand alone, and be lightweight (at least on the client end) - otherwise it will never be used in embedded targets, or in secure applications (where complete control over all ends must be exercised).
This ficticious configuration engine must also be flexible -- some programmers write out a single binary, others write programs that work together to provide an application.
So let's divide it here: pass ALL CONFIGURATION over environment variables, plain text files (lists of strings, or single-line private stuff like passwords), and encourage this behavior by chrooting everything. This way, nobody needs to write a client at all!
But to solve the interface problems, simply front-end it so that we would have our "config loading program" run the actual application, and we can then switch out our configuration loading programs (and the suite it comes with) as we choose. I can put all my stuff in LDAP, or just some of it, and the rest in SQL.
Infact, I find it interesting that this article puts down this approach; saying that this is what makes "linuxconf" suck. No, linuxconf sucks because it tries to be something nobody wants: Service administration and System administration are TWO COMPLETELY DIFFERENT THINGS. I want to delegate System administration (setting up network interfaces, configuring printer drivers, formatting disks, etc) tasks, and keep my Service administration (configuration of the mail server) to my self. Or other other way around. You combine the two, and you get something everyone is skeptical of. I mean, nobody likes the MMC tool on windows systems because it clumps everything together and all the little applets don't behave like eachother.
Delegation is a word i used above. A big word for some, but it shouldn't reflect anything about the design decisions regarding our reinvented configuration system. Those could be handled by the same frontend (only grabbing data allowed, etc). And because the interface is simple enough, most people can put together the autonomous interfaces themselves, and others can still use the interactive ones.... if the configuration tool ever existed that is.
Of course, Linuxconf also sucked because it didn't give the admins the ability to poke inside, and automate anything. Maybe that's what the author meant.
In any event, and in short: I suppose the goal is to avoid using configuration files at all, but instead to rely on configuration being supplied at run-time. And there's a bonus: If more applications are built this way (and more every day are), then we'll see trends towards making applications smaller, and thereby more manageable (from the source level), and thereby making them potentially more secure.
It's a nice pipe dream, isn't it?
what's this "we" shit?
I'm sorry, but netscape never did anything for the "linux desktop". Linux isn't a desktop, it's an operating system kernel. And while we still do things the "UNIX way" (as opposed to the POSIX way; read on), it can never be a desktop.
The UNIX way isn't really that good. It doesn't have much consistancy (the concept of devices being one of them), and setuid really does have to be the worst-abused idea ever.
Most importantly, UNIX still requires fast fingers. With paths getting longer (how many times a day do you type: vi /usr/local/apache/conf/httpd.conf ?) it's getting Linux further and further away from the desktop market.
What Netscape did was show many linuxish users know that someone was watching them. Someone was using their goods, and that someone was someone that manyones :D happened to root for; go netscape!
Of course, Netscape was still garbage, and MSIE still far superior. But nobody seems to remember that. I still know many people that try and tell me that they think Netscape is still better. These people are called liars. They rationalize Microsofts Evil as an incapacity to write good software- or as some would suggest- steal it.
Opera put out a world-class browser. It's fantastic. Although I think they should make the windows versions for-charge and the uber Opera's for free, but that's just me. I like opera; I'll never pay for it (nor use it until it is free), but I still like the way it works.
Konq and Express and all those other silly guys. I admire it, but you guys are falling in the trap: writing a web browser isn't difficult; Designing one is. Mozilla proves this: Mozilla is garbage. It's not designed well in the slightest. But changes occur quickly- as do fixes...
Now, Be really did a good job (I'm not so sure about this newfangled BeIA, but...) with giving us the structure of a POSIXish system, but keeping it away from the desktop. Don't think I'm suggesting a look-and-feel, or a new Beish window manager, or even the GNU Bedesktop (hahah). I'm saying that the more we make our Linux look like windows, or Be, or Macintosh, we actually distance ourselves further.
X environments are getting slower and bulkier (how many enlightenment screens have you seen with crazy shaped windows?), and nobody seems to be asking why?
I can guarantee that the makers of enlightenment aren't to blame; nor are the guys beheind Sawfish or Blackbox our saviors! Nor do I suggest a happy medium.
What I suggest is a new way of thinking (feel free to add that silent G sound at the beginning...)
This falls on those Linux packagers (sometimes called distributers, but this is confusing). They need to step forward and make their own "Linux-based" systems instead of "UNIX based, Linux systems".
Beginning to understand?
UNIX works really well in the server room, and I appreciate the authors mention of servers being distinctly uncomparable to desktop environments. But I disagree on one very important issue: UNIX will never take over the desktop. Never. So long as Linux is unixish, it will continue to fail here again and again.
GNOME and KDE both look and feel very much like complete systems, but the more you use them, the more you find yourself with a dozen (or three) terminals, a netscape window (or twelve :) and your favorite mail client. How is this a desktop?
We need LESS graphical apps. Less modules (so to speak), and someone to step up and say "this is how it's going to be done!"
And this is how it's going to be done:
Macs do the desktop rather well. Drag the program off the website or CD-ROM onto your harddisk and run. Done playing? drop the whole folder in the trash.
Yes, I propose it really be that simple. And I think it can be when we have file-attributes (in the OS/2 sense, not in the Windows sense), resources, etc; things that can be associated with what the user actually has to deal with, but completely independent of their experience.
How many Be users have tried putting font and style formatting into their source code? Ain't that spiffy? Now why is it that to do this under most Linuxish systems (and windows included) we would have to modify our compiler?
As it stands right now, the author of the compiler would need to be involved in such a motion for the desktop, and I assure you these wizards have no interest in such silly concepts such as drag-and-drop.
The kernel-folk will tell you one of three things (depending on who you ask): Wait for Linux 3; that shouldn't be in the kernel; and i don't have anything to do with that.
On to other things; why does X *still* perform no desktop maintanence? It should have the window manager coupled with it. I hear screams that resemble "No! That's what makes X good!" but it's a lie! X does good things, and I still believe it to be a better remote desktop than anything else out there, but X still doesn't make for a local desktop. And unless anyone else has a better idea...
I can appreciate being ignored, but "we" still have a long way to go. And I fear that unless enough people realize how far we've drifted off course, we'll never pick this one up.