How to Fix the Unix Configuration Nightmare 482
jacoplane writes: "There's an interesting article on freshmeat talking how sorting out some kind of standard for configuration could really help Unix systems could be more user friendly. The article points out that since Apple has managed to build a quite usable system on top of NetBSD, it should be doable to do the same for open-source interfaces."
There are valid reason (Score:4, Informative)
i.e. instead of changing one thing, you have to make the change for every interface/terminal/etc it is running on. Just an example mind you.
Re:There are valid reason (Score:2)
The cool part is that one tool would be able to configure new things that didn't exist when the configuration tool was designed as long as the tool was well thought out and feature complete. Since the current crop of configuration tasks is quite diverse already, I see no reason why this wouldn't be doable.
With this system, you would also never have to write your own GUI config tool for each app ever again. KDE, Gnome, Samba, Apache, Mozilla, Galeon, etc. could all dump their custom X / web-based tools if they desired (you could even have a web-based version of the tool.) Hell, you could even use this to configure the kernel.
For migration, separate utilities could import / export from the new XML based files while all the software that uses config files get's updated.
Some software such as Apache is already close as it is already somewhat xml like.
The one thing I ask that of ANY config tool is that it NOT be like the Windows Registry, Don't put everything in one big-ass binary database. That's the most hostile, fragile pile of crap on the planet.
Isn't Linux getting there ? (Score:2, Insightful)
Install/configure (Score:5, Insightful)
Like getting sendmail to rout and forward mail, apache to serve up web pages you want, BIND to bind names to IP address, etc.
These tasks arn't "hard" or anything, but they do require a lot of reading on the part of a Newbie. In the windows world (don't know much about OSX) Most of that stuff can be done via am intuitive GUI.
Flame me if you want, but I'd greatly prefer a system that didn't require me to learn diffrent config file formats for each service I want to have running... or deal with a hodgepoge of 'easy config' program hacks.
A simple, standard configuration system is definetly the way to go.
Re:Install/configure (Score:2, Insightful)
Now, using a standard syntax may hold some promise of making configuration a little easier, but the hard things will always be hard. No GUI will ever change that.
Also, text files are easier to manage remotely. Just give be ssh and vi and get out of my way
Re:Install/configure (Score:4, Interesting)
Now a GUI won't make people understand what they are doing or do the work for them (ever configure MS Exchange? That's a bitch....) but what it DOES do is make the configuration easier to navigate.
By using an XML based file format (as I proposed in a previous comment) you get the best of both worlds. The Apache config file is a close example of what I was thinking (it's not XML, but it is XML "like".)
An application would actually have 2 configuration files: one that actually contains the configuration data (like httpd.conf for apache) and the other to describe the options, help for the options, defaults, etc. to the configurator GUI. Both would be XML, would be extensible as hell, and provide a single tool for configuring any application, current or future.
As I mention in a previous post, a set of importers / exporters would provide a way to migrate until the various applications were updated to use the new format (sendmail may NEVER change...)
So you get what you want. Hell it would probably be better as you would no longer need to memorize all the differet quirks / rules for different applications's configuration language.
Re:Install/configure (Score:3, Insightful)
Think about it--with this method, you only need to write ONE gui configuration tool, for everything!
E smith is your answer. (Score:3, Informative)
It's the esmith configuration schema.
They have already solved this problem in a neat way.
Re:Install/configure (Score:3, Insightful)
You don't need regedit to do configure this unless you are REALLY into self-inflicted pain, and decide not to use the other tools. Regedit would be the same as vi in my example. It's a way to manually edit data. I am NOT describing regedit. You are thinking that my tool would be an XML browser that would basically manualy edit the first file I described. The second file is the key. It's the one that gives you all the smarts in the config tool such as whether to do radio buttons, check boxes, tabs, text entry, value validation, online help, etc. This is alot of the stuff that's hard-coded into so many different tools.
It's also the one that would define where in the scope of configuration of everything a particular task belongs. Obviously the schema, taxonomy, etc. need to be thought out, but this is a VERY doable project.
Maybe the author should try webmin (Score:4, Informative)
It seems you're missing the point (Score:5, Informative)
Re:It seems you're missing the point (Score:2)
Even if these changes were added in right now, it would still take a few years for them to be so common that they could be relied upon.
Re:It seems you're missing the point (Score:3, Insightful)
What we need is exactly what the author is proposing. A generalized configuration system that works off meta data that the software developers supply.
- All the possible configuration options in logical groupings
- descriptions of each option
- default values
- validations on input values
- being able to label options as 'experimental', etc...
- and of course option dependencies - that is if this option is turned on, then enable these 5 other options.
To do it right you'd ultimately you'd probably need to have a very light scripting language with flow control and variables.But the important thing is to get a workable standard in place, one that the majority of developers can rally around and will be happy to develop configuration scripts for their applications. Most developers wouldn't even have to change the way their application reads the config files - documenting everything in a form that this 'configuration manager' can use would be enough. It's already been too long - we shouldn't wait any longer to get this process moving forward.
Re:It seems you're missing the point (Score:3, Interesting)
Probably because a lot of the configuration files which are editied by m4 aren't considered human readable.
Don't confuse Syntax and Standards (Score:5, Insightful)
The part that makes such a system really useful however, is a standard agreement of which information is stored and what it means. This is where the Windows Registry falls down. And Unix is even worse, because all it has is some common soft-of-agreed-upon shell variables, like $EDITOR etc.
Apple is able to do this better because they set the standards for the OS (even more than MS). The can have one central "registry" for something like default associations of MIME-types with particular applications and define an API so every application can use it and a user doesn't have to change his settings in his browser AND his mail client AND his ftp client, etc.
Given the diversity of the unix crowd, the latter seems difficult to me. Maybe they can include it as part of LSB for a start?
Re:Don't confuse Syntax and Standards (Score:5, Interesting)
No no no. XML is not the magic solution to all problems in communication, data storage and usability. Using XML does have many advantages for some applications, like communicating over the internet, but I don't see how
<DocumentRoot> /some/path
</DocumentRoot>
is so much more usable than
DocumentRoot /some/path
The only thing XML will do if widely used for configuration files is make maintaining them harder for those who'd like to do that by using shell scripts or simple text editors. As a very basic example, using XML makes configuration files harder to grep. The above example might also be written like this:
<DocumentRoot>
/some/path
</DocumentRoot>
This is completely legal XML, but if you grep DocumentRoot this file, you'll get the following result:
<DocumentRoot>
</DocumentRoot>
which is probably not what you wanted.
Re:Don't confuse Syntax and Standards (Score:2)
For example:
ACL James \
Bob \
Mary \
Lauren
Most UNIX programs will even ignore whitespace in the config file. I would say that your problem with XML is not related at all to XML, but that you have a problem with a specific style.
IMHO, a standardized way of writing config files is definitely needed. XML would fit the bill, especially since it's so popular. Writing a new configuration language might be fun (and even a seemingly better solution), but every single person running Linux would have to learn that configuration language. Not everyone needs to learn XML.
Re:Don't confuse Syntax and Standards (Score:2)
<DocumentRoot>
is so much more usable than
DocumentRoot
Try to nest several DocumentRoots which have different properties. If we ignore those possibilities: XML is a standardized format. There are several usable parsers for almost every platform out there. Having an Apache-style file follows no specific standards. Parsing will also be a bit more difficult.
The grepping problem that you mentioned is really a non-problem: use xmlgrep, xmltree or similar utilities to find the data note that you are looking for.
It's not more HUMAN readable... (Score:2)
You can hack out a CSS file that would describe to any XML enabled web browser how to display your file in a much more readable format and XPath lets you slice and dice an XML file however you want to. I've run across an XML enabled grep-like program too, though I've never actually had much need for it.
Re:Don't confuse Syntax and Standards (Score:3, Insightful)
Other variations:
<DocumentRoot>
<setting name="someSetting">SettingValue</setting>
<someSetting>SettingValue</someSetting>
<someSection value="SettingName">settingValue</someSettin g>
<someSection>
<settings>
<settingGroupName>Test</settingGroupName& gt;
<setting name="SettingName" value="settingValue"
</settings>
</someSection>
</DocumentRoot>
Etc. The variations on hierarchies and values are endless and is my main beef with XML. It sometimes can be too flexible and people who are using XML (especially newbies) make it overly complex or not suffieciently complex enough for expansion. In other words, this needs to be thought out.
But again, XML is a good idea. I hope it gets adopted as a general mechanism in *nix, but not in some random way...
-Russ
XML as a starting point perhaps? (Score:5, Interesting)
In the writer's outline section he has a few bullet-points that scream "XML!" (I'm paraphrasing here):
1. A core system to handle parsing, verification, etc. -- If app configs were based around XML, you could use any of a dozen XML parsers out there.
2. A configuration format description file. -- Hmmm, sounds like a DTD...
3. OS-neutral. -- XML was meant to be portable from the get-go.
The other items lined up pretty well with what XML is all about as well. Anyway, that said, I'm not so sure this'll ever happen since, from a developer's point of view, it's a lot simpler to slurp in a bunch of lines from a text file with fgets and chop it up into words than to have to somehow link in a third-party XML parser.
Re:XML as a starting point perhaps? (Score:2, Informative)
* A key element would be the configuration format description file. This would list the configuration options for a given piece of software, giving for each one the name, type (boolean, list, string, etc.), options, category (for subsections within the config), and help text (short and long).
This looks very much like XML Schema [w3.org] to me - it can specify all these data types, including enumerations, and a schema-aware XML editor (eg XML Spy [xmlspy.com] in the Wondows world - anyone know the best Linux option?) will prompt you with help-lists of valid elements and attributes, or list of enumerated values. Doesn't do help text by default, but has an expansion mechanism (xsd:appinfo) for adding application-specific to be added to a schema.
* It all needs to be language, distribution, and operating system neutral, so as to avoid turning off any potential software developers who might find it useful.
I don't know of any programming language or O/S that doesn't have an XML Parser (many don't yet have XML Schema support, but if you stay off specifying default values you don't need that at run time). And XML is good for natural languages - UTF 8 or UTF 16 from start.
There aren't many formats that are equally machine and human readable, even fewer that allow document struture and data typing, and still fewer that have open or free implementations [oasis-open.org] on practically all platforms.
Re:XML as a starting point perhaps? (Score:3, Informative)
First, XML is not a silver bullet. The thing this article screamed was not "XML" but "API". Define the application programming interface for a library, and stop thinking that each application must directly access the native data.
Second, XML Schema is a definition for an XML language, not a document described in a particular XML language. XML is a meta-language, you have to MAKE a dialect using a schema or DTD first. XML Schema could not, for example, include primitive types for IP addresses (very common in config files), or validation constraints for integer values.
Third, XML parsers are no-where near as ubiquotous as you would like to believe. To date there are no (zero, zip, nada, nothing) fully compliant XML parsers. Read the XML spec. carefully and understand just how many IFs and BUTs there are to creating a parser. Xerces and MS's parsers are the closest, but still have a number of problems. Expat-derived parsers happily handle a large subset of XML, but not everything. A vast number of parsers out there ignore the DTD, which means they cannot handle entities (which is a big issue).
Finally, there is nothing intrinsically human-readable about XML. This is common bullshit sprouted by those who haven't actually considered the requirements for human understanding. A simple .ini-style line delimited key=value is the most readable and understandable (from a psychological viewpoint) configuration format.
Wrong wrong wrong (Score:3, Insightful)
Yes, and the discussion went to the next step and started talking about possible APIs. The parsing of XML (DOM and SAX -- DOM for in-memory data structure and SAX for streaming access) are well understood and, most important, already done with innumerable tools already written.
Wrong! Wrong! Wrong! You haven't read the spec and are obviously making assumptions based on what you've heard from others who haven't read the spec either. XML Schema allows not only the specification of integer, string, float, date, etc. values, but integer subsets (greater than and less than) and string patterns (through regular expressions). And RELAX-NG can use XML Schema's datatype support as well.
Do you have something that does validate IP addresses for example or were you just complaining about how one thing doesn't (even though it does) without showing anything that will solve the problem. If you say regular expressions, I must remind you that XML Schema supports regex matching of attributes and element data.
Could you please enumerate these non-compliance issues? An encoding issue? Bugs in DOM or SAX support? What? I wonder about the vitrol of your argument without any specifics. Especially since I been using both parser that you mention (and a few others) without any noticeable issues associated with the standard. Any problem were usual to do with parser extensions to the standard which are fairly simple to avoid.
You're right! That is a big issue. Unfortunately for your argument, it is not an issue with the leading parsers that you mentioned yourself: Xerces and MSXML. The default parser for Java (Crimson through JAXP), the default parser for Windows (MSXML), the default parser for Perl (XML::Parser I think...haven't used it yet) to name a few ALL handle entities. This is like saying that there are many web servers out there that don't support CGIs with the obvious intent of dissuading use of web servers.
I agree, but you're missing an important aspect here. INI files are usually one and at most two levels deep. They do not handle hierchical structures well at all! Let's look at a snippet from a default Apache configuration file.
What do we see? Hmmm... Because the key/value pair format doesn't allow hierarchy, they fell back to something that looks a bit...er...XML-like. And it isn't key=value, it's key[whitespace]value. Yet another issue: one file has the equal sign and others don't. I thought we were aiming for consistency? And what if the parameter is a message and that message has a newline character? A '\' at the end of each line? A '\n' where appropriate? These are problems that XML has solved.
And let's not forget Unicode support. We English speakers may have a hard-on for English, but can't you imagine a case where a program intended for a non-English speaking audience would want -- if not the names of the parameters themselves -- parameter values in alternate character sets than ISO-8859-1 (Latin1)? And before you rebut with UTF-8, do you want to write the UTF-8 translator? What about the other codesets? Are you strictly limiting to UTF-8? This is another area of XML parser that keep it simpler for the programmer. Transcoding is done for you and is most likely better implemented and supported than what you or I would come up with.
And when you have multiple "Files" definitions? Well, multiple blocks right? The "Order," "Deny," and "Satisfy" parameters are associated with the "Files" definition, yes? So why aren't you associating a group of "Files" definitions together? Because that would require further hierarchy? Would you end up with something like this?
Set up a relatively complex configuration where you have virtual hosts and those virtual hosts have behavior different from the default. What's that? You include them in tags by host? Tags that look somewhat like XML anyway you say? Imagine that!
And what about the comments? For some formats, the comment is the ';' character. For others it is the '#'. And none of which I am aware differentiate between implementation comments and actual directive comments. For example. the comment above describes the configuration directive so that any configuration editor could conceivably read in that info and display as help to the user (assuming that all comments were kept correctly before the directive and not after or on the same line). But what if you wanted to make comments about your specific installation. You are making comments so that others in your working group can see why you made certain changes to the config file, right? So how are they differentiated from the primary directive comments. This is the type of problem that XML namespaces are intended to solve -- a way of giving demarcation points to distinct pieces of (sometimes) unrelated data or simply the clean combination of multiple schemas so that your schema definition doe not bloat to immeasurable levels and different schemas can easily share with one another.
Something keeping back Linux/BSD/UNIX is the stubborn, 1337 coders who spent all day figuring out a config file that some joker on the net thought would be a keen config format but forgot to comment it. Let's face it, Apache is not the norm. Config parsers are a known problem with known solutions. Writing a config file parser is not the primary focus for most programmers out there. The config file is a necessary evil to them. Let's make it easier and just say, here's your DOM interface. It's well documented, works well for the limited dataset with which you a working (config files are usually less than 50K), will handle any configuration organizational type you want (hierarchical, flat, etc.) and will save you the time of writing a parser yourself.
Have a nice day.
Re:XML as a starting point perhaps? (Score:2)
XML is great as a data interchange format, but it's a pain for humans. Compare
Really, there's no reason why the config library can't handle multiple file schemas according to developer or user preference.
Re:XML as a starting point perhaps? (Score:5, Insightful)
I'd agree that XML is a good basis, but "XML" really doesn't provide much by itself. It's just a file format that is human readable. If you just use XML with a bunch of proprietary tags, your own XML language so to speak, you really don't gain much over the existing different syntax config files.
An automated tool has no clue what your ipaddress (or whatever) tag means at all. You need to provide additional context for tools to understand the semantics of the configuration data. To make configuration files understandable in a more intelligent sense, you need to either restrict the tags you use to your own configuration language, or you need to provide metadata of some sort.
Why is this intelligence necessary? Well there are all sorts of dependencies and relationships in configuration files. You might want a GUI to let you know if you change something that may break another setting, and so on. Plus ideally you would only allow legal values to be set. Data typing could be done with W3C XML Schema Definition Language, or RELAX NG schemas.
Which brings me to RDF, which I think would be better suited to this task than XML alone. If you use RDF (see http://www.w3.org/RDF/ [w3.org] ) you make it much easier to have a self-describing format that tools can do more intelligent things with than raw XML. While I don't think RDF, DAML+OIL, et al is enough to create a Semantic Web as Tim Berners-Lee is hoping, it _is_ a step in a higher-level direction that will support more intelligence in processing data.
Mozilla already uses RDF for various configuration files and I'm sure there are other applications that do too. Mozilla has a whole bunch of stuff about their RDF here [mozilla.org].
XML is just a tree of "stuff" in human-readable format. RDF lets you set up properties and relationships in the data in a standardized way. I don't have a brilliant example to prove this to skeptics, but really it is a better way to represent a lot of types of data you want to be able to query. There are many knowledge bases, expert systems and other query engines already out there using RDF and even higher-level languages like DAML+OIL.
-Kevin
Re:XML as a starting point perhaps? (Score:2)
Mac OS X PLists (Score:3, Informative)
Quick example taken from the above docs:
<?xml version="1.0" encoding="UTF-8"?>t .dtd"><dict>
<!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyLis
<key>Year Of Birth</key>
<integer>1965</integer>
<key>Pets Names</key>
<array/>
<key>Picture</key>
<data>
PEKBpYGlmYFCPA==
</data>
<key>City of Birth</key>
<string>Springfield</string>
<key>Name</key>
<string>John Doe</string>
<key>Kids Names</key>
<array>
<string>John</string>
<string>Kyra</string>
</array>
</dict>
</plist>
Note: The <array/> tag is specifying an empty array.
Re:XML as a starting point perhaps? (Score:2)
- Create a parallel configuration system depository somewhere outside of
/etc, like /conf. That depository should only contain system and meta-system level stuff.
- Keep application-specific configurations in the application directory.
- Get rid of the ages old
/usr, /bin, etc, etc. Blatantly copy OS X. OS X has solved most of the metadata management issues already.
- Maintain a separate, read-only hierarchy where programs can still get their config files (/etc), libraries (/usr/lib, etc), etc.
- Have a system deamon that reads the new metadata repositories and creates the legacy ones for the legacy parts of the sytem.
XML is not that bad if you are not creating it or reading by hand (but the cool part is that you can fix it by hand as a last resort). And it's scriptable as hell. Check out the Gnosis XML utilities [gnosis.cx] in Python (disclaimer: I did contribute to this project). XML_Objectify for example allows you to build a full object tree of the XML repository, complete with attached methods (on a per *tag* basis) and everything. Creating aGanymede? (Score:2)
Is Ganymede [utexas.edu] a starting point for a complete centralized configuration tool?
I'm not an OS X user but... (Score:2)
Re:I'm not an OS X user but... (Score:2, Interesting)
OS X is based on FreeBSD, albeit an older version. It's pretty damned nice for an older kernel.
Re:I'm not an OS X user but... (Score:2, Informative)
OS X is also one of the very, very few *nix systems that is CASE-INSENSITIVE.
Re:I'm not an OS X user but... (Score:2)
Oh, yeah. From the Darwin FAQ (OS X's core)
http://www.opensource.apple.com/projects/darwin
"Q. How does Apple intend to work with other BSD groups?
A. [...] We already synchronize our code periodically with NetBSD for most of our user commands
No connection, sure...
JavaBeans solves all these problems (Score:2, Informative)
HAH!! (Score:2)
Ok, so that's not entirely true. Some OSS people like java (Freenet, Apache Jakarta). But I seriously doubt that anything Java based would ever make much inroads in the free Unix world. (Maybe Solaris could make some headway, though
And there's a few good reasons why it shouldn't. Java is a little top-heavy, and it's not platform-neutral, it's its own platform... and connecting it to other technology via the JNI is a pain in the ass. I tried JavaBeans once, on a windows box at work. It was a nightmare. I ended up using TCP/IP for interprocess communications. (then again, TCP/IP might not be a bad choice for a central config server, you could do things like remote config. hrm)
Anyway, I think XML plus some schemas might go a long way to doing what we want, without requiring everyone to link in a JVM.
GConf (Score:2, Informative)
it has the ability of configuring apps and has the option of using a DB or XML as a backend.
Start porting!
Other side to this (Score:4, Insightful)
I was thinking this morning how I hadn't udpated my Apache server in a while, and wondering whether I should apt-get the latest version (Apache is kind of important for security, as it's the only open port on my system from the internet). However, I've done various tweaks to config files which would get overwritten if I accepted the Debian standard file, but I don't want to miss out on any new settings that could be important. I know I can do a diff, but that's effort I'd rather not have to go through.
This kind of situation is where a registry-like interface is useful; the install program just has to do a quick 'if-not-exist then add' to any new settings and leave the rest alone (or ask if you want an overwrite of all settings, with appropriate disclaimers).
This kind of thing is difficult to do in a flat file split into different sections (if there isn't a concept of sections, you can just tag the setting on), but trivial in a registry structure, especially when the tool (dpkg-upgrade/apt/rpm) has to handle all the different file formats. However, linux/Unix users would rebel en masse if the registry got inflicted on them (with damn good reason! I like being able to fix problems from single user mode using vi!), but some form of layer between the text file and settings may provide the best of both worlds (programmatic ease and editability). apt/dpkg/rpm could use the interface to add/modify settings without splatting your custom tweaks while still adding the new required settings.
Unfortunately, we're starting from a difficult point, with thousands of applications with many different requirements for their settings. Hopefully we can get some covergence over time.
Re:Other side to this (Score:2)
Apple fixed it... (Score:5, Insightful)
-adnans
WebMin...not the Right Thing but damn good (Score:4, Informative)
The complaints about Webmin is that it isn't perfect. It doesn't solve the desire for a universal config mechanism or encourage the editing of files directly. OK. It doesn't. Yet, it exists now and is a lifesaver when using multiple UNIXs. Anyone who wants to know what any Webmin module is doing probably also knows how to use find -cmin, ls -lart, or read the module itself since they tend to be in Perl.
When a universal config comes along, I'll use it and guess what -- it'll work with WebMin.
Webmin might not be the right thing, but it is good enough for a vast number of uses [thirdpartymodules.com].
Could you be more specific? (Score:2)
;^)
(I just counted the word 'Webmin' like 17 times in your post...)
Actually, I couldn't agree more.
A couple of weeks ago, my boss called me 2 hours before I was supposed to be at work to tell me that something needed to be fixed on the server. I literally rolled over, grabbed my laptop, logged in using the ssl option, fixed it and went back to sleep.
Now you might say that all I really needed was SSH and VI, but I hadn't had any coffee yet and Webmin just required a bit of clicking. It rarely screws up and doesn't mess with your config files.
I wrote a bit more on it on my web site [mmdc.net] a while back - scroll down about half way.
Cheers,
Jim in Tokyo
Re:Could you be more specific? (Score:3, Funny)
Well, I went to both the Creation Science and L.Ron Hubbard schools of logic -- both known for scientifically proving a point by repeating it as many times as possible no matter how correct. Unfortunately, I feel as if I've shamed them since I did include some information that could be verified. Facts are such pesky things. :)
Re:WebMin...not the Right Thing but damn good (Score:2)
Also, ease of use often equals lack of knowledge. I am sure somebody is gonna mod me down for being a troll or flamebait, whatever. I learn the apache conf syntax, I only have to learn it once. That knowledge is portable across any systems I would be installing apache on. I would bet someone who can do it by hand can do a better job then someone who can only do it if they have webmin installed.
I also hope no one is implying that a generic gui based configurator can handle anything but the most basic and common configurations. If I (using the apache example) install and implement a little known module, mod_witch or mod_log_multicast, are you saying that webmin can handle that? Well, go in and configure it by hand you say? Well, I can't because webmin has mangled the config and if it hasn't, it still is not going to be aware of the changes.
Rant on: what is wrong with vi? Seriously? Or pico or whatever editor you want to use? What is wrong with taking 5 minutes out of your day and actually reading the sample.conf that comes with almost all software? Not only can you then go in and actually have the power to do what you want, with confidence and not having to rely on another piece of software or hope that a module exists for you to do what you want, you actually will have increased the amount of knowledge that you have and make yourself that much more valuable.
I would love to meet an administrator who could configure everything and get it working...oh sorry, cavent, said admin can only do it with webmin or something simular. Right, I can see that being a showstopper in a job interview.
SealBeater
Re:WebMin...not the Right Thing but damn good (Score:2)
True: things like package management can be a problem -- any automated tool can be. It's not the same as a bare-metal hands-on I-wrote-the-code installation. Never will be.
Yet, there are people who can't or won't learn every nuance of every system file. There are people who know and like one OS or distribution or server application and hate everything else. Those people are called your co-workers. I know, I have the same co-workers.
There are other groups, call them managers, who want to know that when you get hit by a bus they are capable of finding someone who can figure out what the hell you were doing just before you got your Greyhound tatoo.
If Webmin causes you security problems, be that person who can check for those problems before deployment. Most modules are in Perl, and the permissions can be checked system-wide on any static files easily enough. Hell, create a crontab to check if you don't trust others, or even write a Webmin module to do a basic check when you're not around!
[Full-Rant Mode]
...If we want a chance of getting Unix to the unwashed masses -- to enlighten them a bit, maybe to get them to do the right thing.
...If we want to break out of the present canabilism between different Unix systems.
...IF IF IF...we _NEED_ something that works like a camel's nose.
We _need_ to get in more tents before we get any figs. Right now, most non-Unix folks don't give a fig about Unix. :)
Re:WebMin...not the Right Thing but damn good (Score:2)
While there is no excuse of course for needlessly hard or complex configuration files and such, when simplification comprimises usability, security and capability it has gone too far. Rather than dumb-down the software, let's encourage people to actually learn about the tool they're using. Perhaps once people understand what security is and why it's important, they might finally start adopting security-aware proceedures.
To summarise: smarter people, not dumber tools.
Re:WebMin...not the Right Thing but damn good (Score:2)
...If we want a chance of getting Unix to the unwashed masses -- to enlighten them a bit, maybe to get them to do the right thing.
You think you can bring enlightenment by encouraging ignorance? By not encouraging learning and the proper methodalogy to not have to rely on yet another tool to get the same job done? That you can get anyone to do the "right" thing by encouraging them to not read and learn, just to find the "easy" way out?
Re:WebMin...not the Right Thing but damn good (Score:2)
Absolutely not. Right now -- by encouraging only one way of managing Unix systems -- we're not enligtening anyone except ourselves.
Simplify them, and then we can coax the Unix ignorant into learning a wee-bit more...a universe more then what they have now.
What you suggest is preaching to the chior. I'd like to see a larger chior, even if they can't cary a note. Later on, we can teach them how to sing. Right now, they aren't.
Re:WebMin...not the Right Thing but damn good (Score:2)
Yet, there are people who can't or won't learn every nuance of every system file.
Then they should not be in charge of administering a box. "Can't" implies an inherent lack of ability. Good enough reason not to be an admin. "Won't" implies an inherent lack of motivation. Good enough reason not to be an admin. Both are reasonable assurances that a machine placed under their control will suffer.
There are other groups, call them managers, who want to know that when you get hit by a bus they are capable of finding someone who can figure out what the hell you were doing just before you got your Greyhound tatoo.
They can, it's called hiring someone who knows what they are doing, as opposed to hiring someone who knows how to install webmin. By your logic, it sounds like you are advocating that they should be able to hire someone who doesn't know what they are doing. Doesn't work in the real world and places that do that inevidably fail.
If Webmin causes you security problems, be that person who can check for those problems before deployment.
Right, fix the known problems, ie, make more work for yourself cleaning up after a known insecure app that is supposed to reduce your workload and make your job easier. Without even touching the problems of new hereinto, unknown security issues that you have introduced in the name of ease of use, you just added an additional layer of complexity in an effort to make things less complex. See the flaw in logic?
SealBeater
Re:WebMin...not the Right Thing but damn good (Score:2)
Where we differ is that I desperately want more Unix-friendly work environments, and Webmin is one way to increase Unix adoptation instead of giving in to the flood of Windows systems. If you have this goal also, then tell me how you would address it. So far, I've heard lots of complaints about Webmin but no solutions beyond work harder + be smarter. OK, done. :)
There are problems with anything, Webmin included. With about 200 plugins, I'd be stunned if there weren't any security issues. A security audit, though, occurs per-app on installation and on a regular basis network wide. Those can't be avoided regaurdless of what you do. But, under most Unix systems, you have a chance to fix security issues.
Since it will not be possible to fix problems with Windows or any closed source environment/server, why not fix the problems where we can?
If it takes 2, 3, 5 years to get a unified configuration system why not start with what we can use and fix right now?
Re:WebMin...not the Right Thing but damn good (Score:2)
Where we differ is that I desperately want more Unix-friendly work environments
I am actually not sure where I stand on that. I would like a more unix friendly work environment in which I can either use *nix myself or have a *nix infrastucture in place. I have been lucky in that that has not been too uncommon, but from a user standpoint, I don't know. I came from an enviromnent were if someone asked if they should use *nix, the answer was no. I thought at the time that that was elitest and repungnant, but after having tried twice to teach people, I can understand. If you're interested, you'll get it, if not, you won't.
My main objection to making things easy is that often, the student, for lack of a better word, doesn't ever feel the need to progress. It works well enough so why should I learn more, is the previlant attitude. Argh, what's the use?
My main thing is, a unified configuration system is not a *nix thing, for lack of a better word. Every app out there would have to adopt it, it would be an additional overhead, and what would happen in terms of security holes, updates, etc?
If I updated the xml lib, would that render my config unusable? World-readable? What about some hard-core customization? A one-off, if you will. What about a brand new module or app? Will I have to wait for the "configurator" app to catch up? What if I update an app and not the config, and the app parses configs differently? I just think it would create more problems then it solves.
SealBeater
Re:WebMin...not the Right Thing but damn good (Score:2)
I hacked together revision control hooks once upon a time for some webmin features, but it was frustrating because there was no common saveConfigFile() function or anything.. each module did it individually in their own way, which meant I had to modify each module to execute cvs after it's save functions. I didn't get as far as having webmin prompt for a change description, however.
So, as webmin started progressing through versions, while we began rolling out our cvs-based revision control wrappers for
Yes, I've got the source code to change it.. do I plan on it? Not especially. Not worth my time right now.
c'est la vie.
gconf, LDAP anyone? (Score:3, Insightful)
LDAP is nice on its own, too, with configuration being stored platform- and host-independently, as well as global, group-specific and user-specific settings. Netscape Roaming works this way.
Duh (Score:2)
As for hard to do? I don't see why that would be the case. Just a little bit of XML and viola.
There are a lot of things in the Unix world that are hard or time consuming to do just because they can be. sendmail.cf. hello!?
I hope this goes somewhere (Score:5, Informative)
A brilliant article, and a subject which I have tried before (with little success) to broach with various OpenSource developers. Unfortunately the comments demonstrate the lack of understanding that is all too common in the free software world: an inability to distinguish between apis/formats and software implementations; and an unwillingness to move to a more user friendly system.
GConf and Webmin, for example, are not solutions that address the problem posed by the article. Other comments completely lose the plot: this is about a common configuration format which can use metadata to provide for configuring just about any application, it is not about creating an all-encompassing configuration that will give settings to all applications everywhere for all time.
Gconf is half of the solution at best. It provides a library (common abstraction) for accessing the data. But an application still has to have explicit knowledge of the data in order to act on it. A configuration framework describes this knowledge to allow any compliant application to act on it.
Sometimes an example is worth 1000 pictures (and hence about 1000000 words), so consider a simple packet filtering application with an ACCEPT list and a DENY list, which can listen on several interfaces.
Such an application would have a meta-data configuration file (say /etc/conf/meta/filter.cfg) which specifies:
section name=interface count=multiple type=ipv4 ; section name=accept count=multiple type=cidr ; section name=dent count=multiple type=cidr. Now any application can access the packet filter's meta-data file, and the real configuration file (say /etc/conf/filter.cfg), and understand the meaning, to a degree, of the configuration. The types "ipv4" and "cidr" will have to be primitives for the configuration framework.
Thus a general configuration application could present a tree which has three branches (interface, accept, deny), each of which displays a screen with a list. Appropriate entries can then be added, modified or removed, reconfiguring the packet filter without the configuration application having any prior knowledge of the filter's configuration or requirements.
With adequate forethough (for the categorisation and types required) such a system can be extremely powerful. A single configuration library can be used by the application, as well as GUI and CLI configuration clients. You could easily have a command in a script: config pktfltr add -section interfaces -value 1.2.3.4 .
A common library like this can also provide powerful features that a lot of applications lack, like local (user) settings which override global defaults. The library can maintain global, group and user configurations for each application, and getting/setting preferences will take the overlays into account.
Implementing such a system would also provide an ideal opportunity to introduce configuration versioning. CVS (for example, or arch, which includes directory versioning) could be used to maintain various versions of the configuration files in /etc/conf.
Arguments about diversity are largely moot. The data format is independant of the data in any well-written program. .INI files, Bind-style files, XML files and SAMBA files can all represent the same information, but they look different. Some are arguably more efficient in some situations. Even the feared Windows registry has the same functionality ... it just makes the (fatal) error of storing everything in a mostly inseparable datastore (sortof like an /etc/conf directory in which you can't treat the various files separately).
This is a suggestion which needs to be followed through, and supported by the community.
Re:I hope this goes somewhere (Score:2)
I would deviate slightly. folks should stop thinking of "the solution" as being "a solution" or "it" or some new unified thing. Instead, think of it as "what incremental things can we do that would make the mess less of a mess". If we then implement a few of those things, the world will be a better place, even if we do no more than that. If we keep getting incrementally better, someday we'll arrive at a unified world.
so, for instance: we need a little API that allows reading and writing of hierarchical data, and an implementation of it that supports one file format. Use it in a project. Implement a second file format and now that project could write its data in either format. Approach other projects that use the same file formats and offer to switch them.
Note that the two different file formats represent polymorphism: but this should not dictate C++ (or whatever). Rather, there should be implementations of this small "project" in every common language, at least perl, C, C++ and "shell" if anybody has the 'nads.
I hope I made my point? each little step of this is one incremental thing and is good on its own.
I've got some other issues, but I don't want a long muddy post. But, f'rinstance, the .* files do not belong in my login directory, or I shouldn't log into that directory, and .* files that I hand edit should not be interspersed with .* files that are filled with computer gen'ed stuff. the ~ (home) directory is a huge stinky mess quite apart from the different file formats. Copying your .dot files to a new login dir is a nightmare. However, notice that with a new API being used to read and write them, the new API could silently move them whenever you're ready.
Problems (Score:2, Interesting)
Standard way of services. (Score:2)
/etc/sysconfig is great. Everything got it's own place. Setting up a new network interface is easy. I don't give much for rc.local.
/etc/rc.d/init.d is also very easy. No need to figure out what should be run to start bind or restarting qmail. It's all there.
This is what I would like to see in all dists and all Unixes. Other Unixes possibly has there way of doing things easy but then it isn't a standard anymore.
You could possibly stick a GUI over
Re:Standard way of services. (Score:2)
/etc/rc.d/rc.inet1 is great. Setting up a new network interface is easy.
/etc/rc.d/rc.inet2 is also very easy. No need to figure out what should be run to start bind or
And that's the whole point. I don't have to like SysV, cause its *nix. I can do it anyway I like. Let's make sure we don't forget that. What's next, different GUIs for different unices? So much for standardization.
SealBeater
Ximian Setup Tools (Score:3, Interesting)
The Ximian Setup Tools [ximian.com] do basically what's needed here. Sure, the GUIs themselves are tied to GNOME, but the backends are pure Perl with no other dependencies, and they convert the local configuration format for a number of platforms to and from generic descriptive XML. So whatever frontend could be built on top of this without worrying about the details of the platform.
There are already tools for setting the system time, network configuration (with dialup), X configuration, fonts, DHCP, internet connection sharing, shares (Samba and NFS) and boot configuration, and they work on several versions of Red Hat, Mandrake, SuSE, and Debian, with some tools tentatively ported to FreeBSD, if I remember correctly.
Last I heard, the KDE people were going to use the same backends for their config tool suite, but I'm not sure what happened to that. Creating a web frontend along the lines of Webmin would also be trivial.
Now, of course, since the XST XML format already exists, it would be pretty trivial for most programs XST can configure to just gradually migrate to this XML format as their native configuration format. It's even very easy to support both at the same time (just use whatever is newest, and generate one from the other).
In a perfect world, this would happen. In this world, however, I'm not so sure. In the meantime, XST offers very nice GUI tools for doing common GNU/Linux system configuration.
Re:Ximian Setup Tools (Score:2)
Wow, this sounds like a good idea.
Taking this idea and getting rid of the GNOME and Perl dependencies (i.e. rewriting the system :-) could make it more generally useful. GNOME has
its good ideas, but I've found it to be too flaky
in the past. (I use KDE.) I prefer not to have hacked out perl scripts on my system either. I'd
much prefer Python for scripting XML manipulation.
I suppose one could compromise and allow multiple scripting languages, if the basis is XML. I'm assuming you want to provide some higher-level configuration access libraries for each scripting language.
For the XML, it would be better to use RDF which would hopefully allow the data to be more easily queried/interpreted by tools. The XML in the XST whitepaper is pretty useless, other than being human readable.
-Kevin
I /like/ the Unix Configuration Nightmare (Score:2, Insightful)
I
Don't fix it. It's not broken. Things work great as they are now. It's not difficult if you want to learn how to do it. Your "Unix Configuration Nightmare" is actually an elegant symphony of applications, clients, daemons, sockets, and streams that is UNIX. Take it or leave it.
:)
And you know, when I was your age... wait, you get my point.
Re:I /like/ the Unix Configuration Nightmare (Score:3, Interesting)
ls -a $HOME
.Xdefaults .Xmodmap .Xresources .addressbook .addressbook.lu .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xserverrc.secure .xsession .xtalkrc
You get the idea...
Sure, wget has a command line option for my http proxy. But why isn't there a system-wide default that it uses?
Wait there is! But is it $HTTP-PROXY? Or $HTTPPROXY? Or $PROXY?
What's my default printers name? Yeah right it's probably $PRINTER, but then again, maybe not.
Sorry man, but I don't call that good. I call it ugly. Using an Apple, now that is pretty, and for a reason. Thinking about merging pretty (Apple) and powerful (Unix) sounds truly appealing to me.
The article was talking about user configuration as much as server configuration. I could live with seperate conf files for servers, but for user conf files it's just plain ugly.
Re:I /like/ the Unix Configuration Nightmare (Score:2)
Sure, wget has a command line option for my http proxy. But why isn't there a system-wide default that it uses?
Wait there is! But is it $HTTP-PROXY? Or $HTTPPROXY? Or $PROXY?
Actually it's $HTTP_PROXY. Its called reading the documentation, which is why its there.
As for things like
its called multi-user enviroment. Keeping individual settings, information and the like in $HOME is actually pretty elegant. How do you propose keeping seperate users settings intact? If its one system-wide configuration, obviously everyone is stuck with root's preferences, a bad idea I am sure everyone can agree.
SealBeater
Re:I /like/ the Unix Configuration Nightmare (Score:2)
This is not about a system wide conf file for all users. It may be about a single conf file for each user (in their respective $HOME). Of course that would make perfect sense.
And it's not about how the environment variable is called either. Of course I can look that up in the program manual. It's about the fact that the variable is not standardized across different programs (which I was trying to illustrate by giving it different names). So one program may call it $HTTP_PROXY, while another may call it something else. And one program may expect it's value to be a URL, while another may want to cover more info, e.g. avoid the proxy for certain domains.
The point is that such config info is not standardized across several different apps, so you may end up changing several different config files for one setting. That's the problem.
Re:I /like/ the Unix Configuration Nightmare (Score:4, Informative)
I agree. I'm reading all this wondering why people are complaining so much. How much time do people spend in
I need to get something set up, I go to
When Win95 went to a single, non-text config file (registry), I instantly thought this was going to be a really bad move. And it proved to be. Registry rot is incredible. Anyone ever notice that if you reinstall Windows about once every year or so, you get a massive boost in performance? I installed 98 the other day (just for D2:LOD, Starcraft and RainbowSix), it boots (PII-300, 512MB) in about 30 seconds and shuts down in 1-2 seconds. Prior to this, 98 was taking an age, *if* it would shut down at all, and I had all sorts of stability problems. BTW, I put the C: on a 700MB partition and used a D: of 2.5GB for the games. I burn the C: to a CDR and when things get bad, just dd it straight back to hda1.
My point is (back to the OSes that are more fun than a Frost Nova up Andariels arse), *I* want to mess with those config files, rather than have some app(s) messing with one really important file.
I like it too.
Re:I /like/ the Unix Configuration Nightmare (Score:3, Insightful)
You're right about the registry, but a better designed system can give you the best of both worlds. Mac OS X's plist files are human readable and writable, easily accessible via a standard API (1 line of code to get or set any property), and do not involve a single point of failure.
Needs Meta configuration file and config server (Score:2, Insightful)
1) The concept of local and group configuration. There needs to be a Meta config file that specifies what individual users can and can't configure. So for instance, if a company wanted to allow users to configure their word processors however they wanted, exect that they couldn't make any changes to the dropdown menu of corporate document templates, that would be specified in the Meta file.
2) A configuration server. I see no reason why this couldn't work with http to deliver XML config files to individual workstations. The Meta files could reside on the server, the local files on the hard disc. You could imagine in this senario that in order to configure your machine all you would have to do is enter the appropriate URL and press go:
http://intranet.company.com/configs/standard.xm
Then you could have different configs for different types of staff, and supported and unsupported configs (from the point of view of IT support).
You could also perhaps have 'approved' config files for supported hardware.
Having this type of Meta config file also allow IT support to have a clear idea of all the hardware used.
I know that probably lots of people on Slashdot don't like the idea of IT support having control over the config of their machines, but big companies like it and if Linux is going to conquer the desktop then this is the type of tool that will help get it there.
Psychological, not technical holdup ! (Score:2, Interesting)
In an interview of an IBM director, I asked why their then current OS had no GUI (when Windows was chipping at the userbase). Reply:
Mindsets change - at the speed at which glass flows
Some Stupid Questions (Score:5, Interesting)
On that thread what the hell is /usr/etc used for, or /usr/local/etc? won't it make more sense to move /etc here instead?
Do we really need a central registry type file like the article proposes, surly isn't a front end enough, I can't understand what difference this would make. Having a central file which contain's everything like System.dat seem's to be a major security floor in windows since if you can crack that file you pretty much have root on the machine. Not being able to set different permissions for something like fstab or shadow would be pain. Although to be fair the article proposes it as a backup. If it ain't broke don't fix it.
Apart from these questions I think that this was a pretty good/fair article, although I thought that it was a bit unfair to compare linux to windows/OSX since they are completely different OS and something like creating a central config app might work to make linux less customisable IMHO. Most distro's tend to have app's along these lines anyway, what the hells wrong with DrakConf?.
Re:Some Stupid Questions (Score:3, Informative)
These is no technical requirement for dot files. If the entire community decided to standardise on ~/etc, it would happen.
The general theory of /etc, /usr/etc and /usr/local/etc is quite simple. System configuration goes into all of these directories (no user config). Configuration needed at bootup goes into /etc. Configuration needed for OS-default applications goes in /usr/etc, which is available once /usr (containing the OS-default applications) is mounted. Configuration for application you have installed specific to your system (stuff that should be in /usr/local) goes into /usr/local/etc.
The article is not proposing a central configuration file, but a standard for configuration. That would be like saying all application MUST store their configurations in a specific directory, and they must all use the same file format (say XML). Storing all configuration files in the same directory is not the same as storing all configuration in one file.
The benefit of a common location and format is that every app or admin knows where to look for files, and how to interpret them. The structure of each file is identical, so you don't need to know if you use #, //, ' or $ for comments, and whether each line must start with a TAB or end with a ; . What each file says is still different, its just how it says it. Currently trying to work with config files on Linux is like being in a building and trying to talk to people, but everyone is in a different room and talking a different language. Standardize the language and the location, and you only have to content with understanding what is being said.
Incidently, system.dat is not a security problem. In Unix terms that file is r/w by root only, and access only occurs through a kernel-level API. So "cracking" system.dat is no more or less hard than "cracking" shadow.passwd .
Re:Some Stupid Questions (Score:2, Funny)
Some similar thoughts (Score:3, Insightful)
There's lots of cool stuff you can do with standardized configuration files, and dynamically generated GUIs are only one part of it. But developers are not going to change their file formats unless there's a real push for a specific format. Thus, to establish any format, you first have to develop lots of filters to support legacy software. As the FM author correctly points out, such a system would make software configuration under *x potentially much easier than under Windows.
Finally, to all the hackers who fear that this will take away their file-meddling options: If properly implemented, it won't -- and if it does, it will not get accepted as a standard, exactly because of stubborn people like you :-)
human interface guidelines (Score:2, Interesting)
i think it would be a good addition to the linux standard base
What configuration nightmare? (Score:3, Insightful)
The real issue is finding the configuration file; if you're using a distro you're not used to, then one often has to resort to using find. This is exactly what the Linux Standards Base [linuxbase.org] was designed to avoid, and if all distros were to follow this model then I can't see that there is any real problem.
At the end of the day, we're not talking about things like setting background pictures in the window manager, we're talking about setting up mailservers, webservers and the like. If you're not cluefull enough to edit a text file then you're not cluefull enough to be put in charge of setting one of these servers up either.
Some *correct* information about MacOS X config (Score:5, Informative)
---
MacOS X's solution to this problem is a couple levels
deep. There are three (?!) systems for configuration:
(1)
It's still there, used for a few things. But not much.
More or less just stuff that runs before everything else,
or stuff that apple doesn't have much control over, like
Apache.
(2) Netinfo database:
basically takes a lot of stuff out of
"registry", this registry is accessible over a network
connection for remote administration and such. You
can also do some funky server/client stuff with this too.
There's a command line interface to it that lets you
read/change 'keys' and also dump out certain keys in
well known
(3) Property Lists (.plist):
This is the way that just about all configurable
information in MacOS X is stored. There are a couple
different kinds of plists that the Core Foundation
libraries understand, but the most prevalent of which is
the XMLified version, the others are either vestigal or
are used primarily for localization of strings. Every
application (well, bundled app) on the system has an
info.plist file that has application settings that the OS
reads from on app startup, but you can also put your
own tags in there. Applications also have the option of
putting their own tags in the Resources subdirectory in
their bundle, which is the preferred way. OS specific
preferences (requires admin privs) go in
Library/Preferences, System-wide app preferences go
in
applicable if you have OS X Server on the network) are
in
in ~/Library/Preferences.
The Core Foundation framework manages more or less
all of the work. They'll find the plist for you, let you
work with the data structures, and serialize/deserialize
it to plist format. It's really quite nice to use. Just
about all of the data structures in Core Foundation are
serializable, even the property list data structures, so
sometimes you'll see property lists with serialized
property lists inside them.
As far as unified configuration interfaces go, there
really isn't a need for any in Mac OS X.
You're on your own with
to be novice-tweaked anyways (In OS X).
There is a GUI NetInfo Manager and command line tools
to configure the stuff in that database (nothing a
novice needs to touch).
Configuring the plists is primarily done inside the
applications that you use (since it's so easy for the
developer to use Core Foundation to read/write
property lists), there are no separate configuration
programs, but there are command line tools for working
with plists. If you're using the developers kit, you get a
little (not very poweful and pretty inefficient) program
to edit plist files graphically, but otherwise you either
do it by hand with a text editor or the command line
tools and risk breaking things or let the apps take care
of it themself.
BTW, all of the Core Foundation stuff is available in two
flavors: C, and Objective C. The C libraries are pretty
straightforward and work in all situations, but if you're
writing an app using the Cocoa framework in Obj C, it's
way easier.. though there are a few little peculiarities
about the Obj C implementations. The bonus is that
you can use both at the same time, and Core
Foundation types / Cocoa instances are interchangable
by some voodoo that Apple did. If the Cocoa
implementation doesn't work right (As with serializing a
plist that has NSNumber Boolean types), you just use
the Core Foundation implementation and a typecast..
voila, one line of code changed and everything is
happy.
Re:Some *correct* information about MacOS X config (Score:5, Informative)
NetInfo is actually Open Source [freshmeat.net]. Though I'm not sure how up-to-date it is.
As for
Thoughts from someone who adminsters both (Score:3, Redundant)
A modest configuration proposal (Score:3, Interesting)
Likewise, changes to the config could be passed through the library functions, get validated for correctness and then written to disk in whatever format you want. The level of functionality would be such that you could generate white space delimited files, xml configs, or whatever you want and because the template is descriptive enough, comments could be inserted/preserved for those editing with vi.
Now that I think about it, this really wouldn't a rewrite of existing applications, they could simply keep their existing formats and build the template file for other config utilities. Then, if at a later date they decide to drop their own config processing, they use the template driven library to do the processing work. That way backward compatibility could be maintained.
This does nothing to reduce the myriad different configs that you deal with when editing by hand, but it would give the authors a chance to move a more common format later on down the road. And I think it is more useful than trying to get everyone to switch to some unified format that appeases new users.
I have half a mind to try a limited version of this out for handling Apache virtual domains. And it's a lot more fun than hard-coding a parser into your frontend.
A few things (Score:4, Interesting)
The current system for starters isn't too bad - the configuration files for important system tools are typically well documented (in man pages if nowhere else), and aren't too hard to edit in a text editor. Certainly there is a problem with the use of automated GUI tools for system configuration, but I can't really see why GUI tools are so important.
Consistency though would be a nice thing, if only so that as more programs are used and require configuration, we don't all have to learn more and more ad hoc configuration schemes. There is the potential for the current system to get well out of hand. Consistency is nice from an aesthetic point of view - ad hocery is rarely pretty.
Tools such as linuxconf or webmin don't help the problem, they just obscure it. Often badly! (Don't get me started on linuxconf, ugh!)
The earlier suggestions of XML, or a recognised subset of XML, together with XML schema to describe the formats, seem ideal as far as file formats go:
- It's standard and well-documented.
- There are a large number of parsers that work with a useful large subset of XML, for many platforms and languages.
- In a pinch, it's not hard to write a quick and dirty and correct-enough parser from scratch on an ad hoc basis, to parse your own particular XML-based configuration files.
- It's human editable (or should be, if used wisely).
- It is rich enough to encompass all the text-format configuration files currently in common use (under the Linux-based operating systems I know of at least).
The big problem of course is inertia: changing configuration files is a big change! Personally, I think the cost though would be worth it in the long term.The important thing to me is that there is no API specified as mandatory. While a standard API for accessing and manipulating configuration data would be nice, requiring it to be used will not only make adoption of a standard config format slower and harder, but will also limit software developers to the tools for which the API has an implementation. I'd go for:
I also agree with the earlier comment promoting the use of ~/etc over dot-files. Makes good sense! Again, it's only inertia that will make such a change difficult. Though if other changes are going through ... in for a penny, in for a pound!
Lastly, whatever scheme is adopted, it seems to me essential that there be some flexibility in where the configuration files are located. Standard places are important, but there must also be some way to say to an application that their config data is in /usr/local/etc, or in /opt/package-name/etc, or wherever. This is necessary for sane package isolation and management, especially if not all software on a system is maintained by someone with superuser priveleges.
It took this long? (Score:5, Insightful)
The reason UNIX and UNIX applications are hard to configure, in most cases, is because Open Source programmers are lazy.
This is obviously a blatent generalization so I will explain.
The old adage is that an Open Source program gets written when a programmer has an "itch" they decide to scratch. The problem is that very few people are itched by configuration. You may write the best web server in the world (Apache!) but by time it comes to writing the configuration manager for it the volunteers start falling away.
It isn't very fun writing a bunch of dialogs, windows, buttons and such to make a nice configuration for a program. It's kinda like documentation (and we all know the state of docs for many UNIX programs).
I see examples of this every day. I have a Mac OS X using friend who sends me the URL of every new program he decides to use. It's incredible how many of them are UNIX ports with a beautiful configuration manager stuck on. Mac programmers hold themselves to a higher level of user experience and UNIX people need to get on the boat.
What's needed isn't a global, all dancing, all singing configuration system. What is needed is responsibility in programming.
P.S. Everyone always whines about the Windows registry because it's binary, you can't edit it blah, blah, blah... But the fact is: It works. The average user never cares to edit it because they config their programs from WITHIN their programs. If something is truly needed, do the Windows registry in text file format. Make it
NO ! From an elitist point of view..... (Score:2)
Alright so im joking...big suprise...
I think this would be a good thing all in all, IF they DONT MUCK with my existing configurations. There are many things that can be tweaked far beyond the iditot proof gui configuration tools on other OS, In windows you can resort to registry tweaking for some items, others you just cant do a damm thing about, its those thing Im afraid will be removed from my control.
Dummning down on the surface is fine, as long as they dont do it to the underlying configurations. I still cant figure out how the hell to edit (or find) the samba configuration file on OSX, Now granted its not my machine, and I dont really use BSD, so im not suprised. But does it even exist ??? A I am used to it on Solaris and Linux ?
NOT XML (Score:2)
Instead we just need a simple text-only configuration file format which has support for a hierarchy of values (this gets you pretty much what XML would give you). It would also be nice if the format was position-independent, so it could be streamable. A proposal was posted somewhere, but now I cannot find the link. The format could be as simple as:
toplevelkey=value
[tab]branchname1
[tab]branch-key1=value
[tab]branch-key2=value
[tab][tab]branchname2
[tab][tab]branch-key3=value
you get the idea. Please don't throw XML into the mix, it will not simplify things.
Every journey begins with a first step (Score:2)
A solution would be to first implement a generic "configuration" library. A small, efficient library with various language bindings. It should provide the coder simple functions to manipulate the conf file, sortof like "getopts".
Once the above library is implemented, encourage people to use it in any new projects that they are starting. At the same time, volunteers (ie you) can work on "porting" the existing packages over to using this new fangled library.
Over time, this approach should work.
Screw XML, use Python code (Score:4, Insightful)
Avoiding configuration (Score:3, Insightful)
We will now hear from all the people who insist that "they have to do wierd thing X because it's (traditional) (k00l) (needed to support their 386 machine)". They're wrong. Someone needs to be a hardass and fix this thing.
Re:If I remember correctly (Score:3, Funny)
Says something about everyone's favourite fruit company when they can manage what has previously been impossible
-- james
Re:Apple + NetBSD? (Score:3, Informative)
Re:Apple + NetBSD? (Score:2, Informative)
and yes OS X is freakin' nice. leave it to Apple to do what no one else has/can.
flames? who cares? look at my email addy.
no, and furthermore... (Score:2, Informative)
http://www.osopinion.com/perl/story/16382.html
Re:Apple + NetBSD? (Score:2, Interesting)
NeXT, FreeBSD, Apple (Score:2)
People keep trying to make out that Apple ripped the entire OS off one of the open source BSDs. Can't people accept that a lot of it is either NeXT derived or from Apple? A lot of it isn't, of course, but the other BSDs copy each other's code all the time. I'm sure the others will start copying Darwin as soon as Apple lifts its non-BSD license (if ever).
If you want more info check out the Darwin project page [apple.com] and the developer site [apple.com].
Re:Apple + NetBSD? (Score:3, Informative)
OS X is based on Darwin and Darwin takes bits and pieces from all three *BSD, Mach, GNU (compiler) and a lot of other projects. E.g. most of the userland stuff is taken from NetBSD, you can read it up in the Darwin FAQ [apple.com]. Or look at the Darwin-contributors page [apple.com] which lists them all in alphabetical order.
So saying "It's based on FreeBSD" is as wrong/as correct as saying "It's based on NetBSD".
But since FreeBSD's J. Hubbard now works for Apple and FreeBSD doesn't run on the range of machines Mac OS X supports yet (but NetBSD does) expect OS X's roots to FreeBSD to be promoted more than its roots to NetBSD... (sigh).
Re:No (Score:4, Interesting)
Mac OS X is based on OpenStep 4.2, which, itself, was based on NEXTSTEP 3.3. NEXTSTEP is a BSD operating system running on a modified version of the Mach microkernel. OpenStep is a API specification and a set of libraries that conforms to that API. OpenStep 4.2 (the operating system) is an implementation of those libraries on top of NEXTSTEP.
When Apple bought NeXT, they planned to build on top of OpenStep. They first produced Rhapsody for PPC and Rhapsody for Intel. They were the same OS running on two hardware platforms. On top of Rhapsody, Apple put the Blue Box, which was a Macintosh compatibility environment. At no time was there any need for a "BSD compatibility layer." It was all software running on top of BSD. Apple then killed Rhapsody for Intel (and the Yellow Box, but that's tangential.)
What was left was released as Mac OS Server.
Mac OS X 10.0 and Mac OS Server 10.0 (and further versions) are also BSD operating systems. They have the Cocoa (OpenStep) and Carbon libraries available, and the imaging system is called Aqua (replacement for Display PostScript.) At no point in any of this is there a need for any UNIX compatibility layer, as it is all real UNIX. The only compatibility environment necessary is for Mac OS 9 (Classic.) Only certain older applications (Carbon) can run natively on OS X, so for running non-Carbon apps, Mac OS 9 is run in a compatibility environment (similar, but not the same as VMWare.)
I hope that clarifies things.
Uh... (Score:2)
Perhaps you could give me a more precice link.
The only thing I could find was: But good looks are only the beginning. At the foundation of Mac OS X lies an industrial-strength, UNIX-based core operating system--called Darwin--that delivers unprecedented stability and performance. Darwin provides Mac OS X with powerful, advanced features such as protected memory, preemptive multitasking, advanced memory management, and...
Etc. Didn't say anything about what it was 'based' on.
Re:Apple + NetBSD? (Score:2)
I'm always impressed at the GNU folk's clamor to make everything appear to exist at the grace of Stallman. What he did is good for the world, but he isn't the second coming that he so often portrayed to be.
Also, all versions of Darwin (incl. Mac OS X) have apt available to them through the fink system.
hardware != software. (Score:2)
The problem is software config once you've already got the machine setup. Programs generaly have diffrent formats for their configuration. even windows 3.1 was better then this with their
Classic Excuse (Score:2, Interesting)
Name a piece of current (not ISA etc), statndard (not some home built/unknown vendor PCI card) PC harware, other than the motherboard or the processor and it will most likely work on Mac OS X. It may fall back on a generic type (missing some features) but it will most likely work. Macs support: PC133 RAM, ATA hard disks, PCI cards, AGP cards, VGA monitors, USB, IEEE 1394 (FireWire), etc. I think that would be more than 50 types of hardware. Don't confuse the fact that the iMacs are closed with other Mac hardware. The G4 Towers won awards for how easy they are to open up and upgrade. There's a large handle on the side of the case that you pull and that side of the computer lowers down with the motherboard attached to it, giving easy access to all components.
Could it be that Macs are easy to configure because Apple engineers are clever?
Note: I'm ignoring the fact that this article is about software not hardware configuration.
Check out some more myth debunking [osopinion.com].
Re:linuxconf (Score:2, Insightful)
Re:It's FreeBSD... (Score:2)