Slashdot Mirror
Solving the /etc Situation?
mrfibbi asks: "/etc is a mess, plain and simple. Each program has its own (incompatible) config file format and the naming scheme/hierarchy is left almost solely to the author. Furthermore, package updates are a mess, either choosing to replace the entire config file, reject any updated versions (which leads to inconsistencies), or, as is the case with etc-update, asking the user to manually merge the files, which takes forever after a big update. We've revamped /dev with udev, but we've still failed to come up with a universal, duct-tape-free solution for the problem. Though solutions exist, there has been little or no adoption, either due to a personal dislike for the idea or API, or just an indifference to the problem. Should we work toward migrating to an Elektra-like system? Something else? Or do most simply find it not worth the trouble?"
to clear /etc/ you would create another one that would need programmers to comply to that?
/etc/ so that they're logically placed and findable?
/etc/blaablaa? no. it's hell a lot better than registry still and at least I got SOME idea where the config file is.
wouldn't it be actually easier to get them to place stuff in
because going over to elektra seems actually more work. even elektra's web page admits.. "It is much more an agreement then a piece of software. Relation is 99% to 1%.".
do I have a problem with
world was created 5 seconds before this post as it is.
OSS is about choises, and /etc really highlights this. People have different ideas on how apps should be configured, and I think putting all configurations in one place was a good compromise.
What's the real problem with /etc anyway? If you said "all the different and wacky file formats" then you're missing the forest for the trees. Those different file formats exist because it is appropriate to have a file format that suits the purpose of the application. /etc/password and /etc/group are designed for exactly the purpose for which they are used, for example. It doesn't make much sense for apache to have a file format similar to, say, exim; they are applications with entirely different purposes.
/etc. Suppose I am administering a Debian machine with CUPS, since I happen to have one handy. Something is wrong with printing. I have to somehow know all of the following:
/etc/init.d/cupsys /etc/cups/printers.conf /etc/cups/cupsd.conf /etc/cups but, rather, connect to http://localhost:631/ with a web browser.
/etc/cups, but I never do. /System/Library/StartupItems/PrintingServices/Prin tingServices, but I never do.
/etc/profile belong in the same place as /etc/inetd.conf? That gets back to the central question, of course, and I think the answer there is that each package should be responsible for managing its own (default and user) configuration and, similarly
The real problem is that the user doesn't automatically know how to correlate a process, configuration file, startup script, etc., and it affects more than just
1) Printing services are managed by CUPS.
2) To start and stop printing services, I need to run
3) If that doesn't work properly, the process to kill is named cupsd.
4) The config file for specific printers for CUPS is
5) The config file for the cups service as a whole is
6) To manage most things about CUPS (though not browsing and sharing), I don't really want to touch the files in
Just for kicks, let's consider the same situation under MacOS X (10.3):
1) I can control pretty much everything about printing services (including browsing and sharing) from the Print & Fax section of the System Preferences
2) If I really need to mess with the config files, they are in
3) If I really need to manually start and stop printing services I use
4) If I really need to use the web interface to CUPS, it is still at http://localhost:631/
The really important thing here is that on a Mac, I don't even need to know that printing is handled by CUPS. The down side is that on any *nix, unlike Windows, I don't have a way of seeing all the services my machine is providing (to itself or the net). Of course, under Windows it's pretty hard to tell what a service is really for, or how to configure it. When you get right down to it, each system has some good ideas, but none of them have it right.
I want a system where I can get a list of running services (not just all processes), the ports on which they are listening (I don't care if they are TCP, UDP, Unix domain, whatever passes for IPC on Windows, or even Mach ports), and be able to trivially turn a service on, or off, or configure it with a simple commandline or a click of the mouse.
Give me the Windows services manager (with a console equivalent) with the ability to see through what interfaces (e.g. ports) that service is provided, the ability to configure when and how it is started (e.g. at which runlevel), the ability to configure it directly from there (e.g. bring up a custom configurator, a web browser with the appropriate URL, or a text editor on the right files with a double-click in the list). I don't care where the configuration is on disk (though this better integrate well with backup software), nor how it's stored (though there had better be a human-readable text format that can be exported and imported, if necessary).
Furthermore, there should be a separation of default configuration of user applications and configuration of services. Why does