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?"
The XML version is harder to read than the .ini version.
That's a matter of opinion, and can vary greatly depending on what data you want to store.
It's hard to tell at a glance if the config is a valid config.
The same applies to proprietary syntaxes. The only difference is that XML has clear rules for treating syntax errors, and has many tools to automatically check syntax. Some editors even do that for you automatically when you save, or don't let you create syntax errors in the first place.
It is also harder to edit using command-line tools. It is harder to edit with ANY common unix tool, actually. You *must* use editors that understand XML
I'll stop responding here, since it is plainly obvious that you don't even know the first thing about XML. To cut a long comment short - you are clueless and utterly wrong.
[I was going to mod this as funny, but then I realized that at least two people already had, and that you weren't joking. So I'll just write something trite, instead.]
/etc heirarchy into a bunch of XML files which are so not useful by themselves, that they requires even more extra software just to interpret the shit.
Look, kid, nobody likes XML, even if it is buzzword-compliant. XML is so bad that every implementation of anything which uses it is solely focused on translating the XML data into some other form that is actually usable.
Which is exactly what you're proposing: You suggest that the world convert the
Just to make myself abundantly clear right away: I hope that you're trolling, else I implore you to hang yourself before you do any more damage to the world than you already have.
In *nix, any configuration files are generally designed to be readable by humans. This is by design.
XML, meanwhile, is hard to read. It is, to select a singular adjective, "noisey." I don't like listening to radio static, or watching snowy TV signals; why would I want to look at or work with similarly noisey configuration files?
I use a generic tool every day called eyes, which works without installation on every UNIX-like machine that I've ever had to work on, including my Linksys router. Sometimes, my eyes don't work very well, but often contacts or glasses can help with that.
So, I carry a set of eyes and contacts with me wherever I go. Aside from those, all I need are standard UNIX tools to get the job done.
And my set of eyes has a much easier time parsing your first example than the second.
Why do you desire to take away my tools and replace them with the moral, conceptual, and visual equivilent to regedit? Is one coder's time worth the agony of the entire unix-using world?
I've got a Windows box in the next room for when I want to deal with that shit, and it is a loathesome day when I have to edit the registry for, well, anything. And it's not even so much the horrid organization which I dislike, but the visual presentation: Locked down and difficult to navigate, just like XML mandates.
Go fuck yourself. HAND.
Kid-proof tablet..
If everyone is off on some XML tangent, that must mean that everyone hates it.
/etc/shadow file time changes, there is no way to know if the change was related to nobody's or root's record.
/etc/shadow's.
On with Elektra. Here's the problems they state with the Way Things Are Done, along with their requisite Standard Rebuttal:
They don't have a common file format.
So what? They're different programs, written by different people, and doing different things in different ways. Of course they use different file formats for configuration.
Their location in the filesystem may be different from Linux distribution to distribution.
Yes. This is why they're called *different distributions.* If you want sameness, one could always run OSX on unremarkable Apple hardware.
When two different softwares want to integrate themselves, it is programatically very hard to read, understand and correctly change its partner's configuration file. Think about installing a third-party video driver in XFree86, a new Apache plug-in, etc, and letting this new piece of software do the integration automatically, instead of the sysadmin vi the configuration file, understand and change it in the right way. So basic software integration is a pain today for ISVs (Independent Software Vendors).
Would someone PLEASE show me a video driver which requires an Apache plug-in? I want the head of the maintainer.
And ISVs don't want their job made easier, or else they'd find themselves without one. Next.
A software developer must waste a lot of time to write the plumbing code for configuration file parsing etc. It is completelly out of his scope to write code to interoperate with other software's configurations files.
Right. It's right at the beginning, and easy enough to reuse if one is sticking with the GPL. Not Difficult.
Different distributions tend to place different software configuration in different places with different formats. A regular SuSE system administrator, for example, will be lost when asked to work in a Debian or Slackware system. Think about the most primitive example: network configuration parameters. Each distro has its own approach.
Shucks. You mean that HP/UX is different from Solaris? And all this time, I thought they named them differently for marketing purposes.
A system administrator must know all these formats.
That's why they're self-documenting and human-readable.
There is no way to know today what was changed in a specific configuration file. If
Backups, backups, backups. Has nobody yet learned the purpose of a proper fucking backup regime? It's not just to recover from hardware failure, but to provide a window into the past. Snapshots, with FreeBSD and NetApps filers, make this easy. LVM snapshots under Linux are a bit more murky, but that's not LVM's fault, let alone
Storage is cheap, and the components are there. Why hasn't anyone figured this out yet?
High-level system administration GUIs (webmin, redhat-config-*, SuSE's YAST, etc) are just a dream today. They can never track successfully all the changes that happens in the format of the configuration files of such a rich diversity of Open Source software (httpd.conf, smb.conf, modules.conf, fstab, etc, etc, etc). The approach of some of them is to keep the configuration ideas in a private database and regenerate the specific configuration file whenever a change happens in this database. Welcome to the inconsistency nightmare.
Webmin, and all of its evil little friends, consists of a crutch for those who want to operate UNIX machines, but don't want to learn more than Windows 95 taught them. That's not UNIX, and I therefore don't give a shit. Nor will any other administrator who knows the difference between csh, bash, ksh, less, and more.
Kid-proof tablet..