|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|
Re: [PLUG] Config Files (Was: Sharing an Internet Connection)
|
> Date: Tue, 8 Jan 2008 21:28:43 -0500
> From: Matthew Rosewarne <mrosewarne@inoutbox.com>
>
> I'm sure I won't get any friends for saying it, but config files are
> a terrible interface (the important word!) to configuring systems in
> many common situations.
OK, I'll take the bait.
> From the point of view of a developer or someone administering
> multiple systems, configuration files provide a largely
> insurmountable challenge.
I don't care about the PoV of the developer. It's his *job* to make the
stuff work the way the audience expects/requires it to. Read _Why
Software Sucks_ for the book-length discussion of this, but the main
point, however, is "know your audience for they are not you."
The sysadmin, by definition, should be a sys admin, not a "power user"
or admin assistant with a server under the desk (thanks Windows). They
need an interface that works under a wide variety of circumstances, such
as: headless, non-GUI, multiple machines, crashed disks, corrupted
files/disks. Fancy binary-only DB's that require a GUI fail all of
those criteria. Config files meet all of them.
> 1. Configuration files are extremely difficult to edit
> programmatically.
Huh? No they aren't. ed, or sed can do it trivially and that's one of
the whole reasons why Perl even exists! (So yeah, maybe before Perl it
was harder, but still way easier than the only serious competitor, the
dread Registry.) You can argue that a sys admin shouldn't need to know
Perl, but I'd disagree and argue that a "sysadmin" lacking shell & Perl
skills is like a doctor lacking basic anatomy and first aid skills.
> Many applications get around this by simply writing
> "DO NOT EDIT!" somewhere in the file or having an extremely limited
> syntax. Placing such restrictions on config files negates any benefit
> from being able to edit them manually.
OK, I agree here, but this is the fault of bad programmers, not the
config file.
> 2. Configuration files are not very granular. This makes it extremely
> difficult to propagate changes to parts of a configuration without
> overwriting the whole thing, which is an enormous obstacle to managing
> multiple machines or editing a configuration programmatically.
Huh? See #1. I'd rather update a config file on 1,000 Linux machines
be forced to use GUI tools to update 10 Windows machines.
> 3. When a user modifies a configuration file, the program is
> typically not aware of the changes. While this may be useful in some
> situations, most of the time this would involve restarting the
> program and hoping the changes don't cause it to barf. In a
> high-uptime environment, this is problematic. It also makes it far
> more difficult to have hooks run when certain values are changed.
Bad programmer again. Best case, I've seen apps that check their config
file and reload if it has changed. Mid case, send the app a -HUP. Bad
case, the programmer screwed up and didn't write the program correctly.
(See virtually any Windows apps for this, though Firefox is actually a
pet peeve of mine for this issue (e.g. addins).)
> 4. Text files are slow and unwieldy for applications to read or
> write. A configuration file must often be parsed in its entirety in
> order for any of its information to be extracted. Similarly, they
> usually must be written out fully for any changes to be saved.
True, I guess. But reading and writing of config files happens pretty
rarely (or something is seriously wrong). And if you can't trust the OS
to correctly write files, well then, you might was well be using Windows
Home "Server"
(http://hardware.slashdot.org/article.pl?sid=07/12/27/1457240).
> While
> it might be possible to get around this with regex magic, it still
> requires parsing the entire file and is likely to break.
I dunno about that. It's worked pretty well for nearly 40 years...
> 5. Just about every configuration file has a different syntax. Not
> only does this mean that users must learn all sorts of different
> syntaxes to manage their systems, but that a different parser
> program must be written for every individual file.
Well, you've got me there. Unless you consider XML... Yuck.
> Often this
> results in a scenario like that of TeX, where there is only one
> parser implementation capable of fully understanding the contents
> of a file.
Not sure where you're going with that part. A single, reference parser
is a Bad Thing?
> There are other issues, but those are the most important ones I can
> think of off the top of my mind. I'm certainly not going to claim
> that an approach like the accursed Windows Registry is superior,
> it's terrible. The best option I can think of would be a flexible
> configuration _interface_ (by "interface" think "API" rather than
> "GUI") that could be viewed/edited as a text file, or maybe an XML
> file, or even an LDAP tree, with the actual storage being handled
> out of sight.
Humm, kinda sounds like sysctl to me. Or, sort-of, like Firefox
about.config and its settings files, though I'm not a big fan of the
syntax for those. But things like it exist. And you had me until "the
actual storage being handled out of sight" part. That's one of the
biggest problems with the Registry--*when* things go wrong, you can't
get at it. The most complicated I'm willing to go with is XML and
that's still pretty bad.
> I would hope that something such as the Elektra
> Initiative would come into fruition and gain more widespread use,
> giving us Free software users the best of all possible options.
I was not familiar with that.
http://en.wikipedia.org/wiki/Elektra_Initiative does not inspire
confidence because it mentions a "key-value pair mechanism inspired by
the Windows Registry" and berkeleyDB. I won't belabor the first point
and the second one is probably me just having had to deal with a few too
many wedged berkeleyDB SVN repos.
I agree in principle that a config mechanism is such a fundamental part
of all modem application programming that it should just be built into
the OS and consistent across all apps. That's what they tried to do
with the Registry, and even GConf (yuck). But thus far, IMO, the
implementation efforts have been--less than ideal.
What about a simple, standardized, flat file that could be indexed by
the parser in such a way that a single entity could be edited without a
file re-write? Like:
setting = value;
name.space.setting = "Other value";
Sure there are problems, such as when a new setting needs to be added or
an existing setting's new value is larger. So re-write the file in
those cases as needed.
OK, shutting up now, :-)
JP
----------------------------|:::======|-------------------------------
JP Vossen, CISSP |:::======| jp{at}jpsdomain{dot}org
My Account, My Opinions |=========| http://www.jpsdomain.org/
----------------------------|=========|-------------------------------
Microsoft has single-handedly nullified Moore's Law.
Innate design flaws of Windows make a personal firewall, anti-virus
and anti-malware software mandatory. The resulting software arms race
has effectively flattened Moore's Law on hardware running Windows.
___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
|
|