Re: [PLUG] Config Files and Steam Engines

["Brian Stempin" <brian.stempin@gmail.com>]

I have to step in and support Matthew on this one.

> to be honest, i feel like this is just Not A Good Idea (TM) that you're
> proposing, matthew. the phrase "If It Ain't Broke, Don't Fix It" is every
> sysadmin's motto. there's a reason there's still plenty of servers out
> there still running 2.4 kernel.

I disagree with this.  I, too, am a sysadmin.  I feel that part of my job involves (a) automating as much of my own job as possible (so that I can move on to new, larger projects or onto higher level tasks) and (b) to make everything as uniform as humanly possible in order to aide point a.  I feel that the current state of config files in Linux makes both of these goals difficult to achieve.  

I feel that (at least?) 2 things should be made standard: syntax and location.  

Syntax:
Matthew pretty much nailed this one already.  There is no good reason that anyone (programmer OR sysadmin) should have to implement or memorize several different config file formats.  It should be standard and easy to implement via shared libraries located on the OS.  Every major OS that has some sort of Group Policy feature has this.  OSX has pList (I'm guessing this is "property list"), and Windows has the registry.  I've done a lot of sysadmin with with both of these systems and was able to do a lot of automation with a small effort.  If I were to attempt some of the same feats in Linux, I'd have to do more work due to the fact that nothing is abstracted for me.  With Windows and OSX, I didn't have to worry about the location of the config file(s) or whether I used the correct config file type:  This was already figured out, documented, and implemented.  Why can't Linux have that same ease-of-administration?  Making Linux easier to administer is not a silly notion or "jumping off a cliff"; it's progress.

Location:
I feel that all config files should have a standard location.  The reason I feel this was is because I feel that I should be able to programatically find any config file on my system.  Perhaps all config files should live in /etc/<app name>/config or something of the sort.  This would make it much easier for a programmer OR a sysadmin to locate a config file and to begin their work. For those people who believe in centralized config dbs, perhaps it should be kept in /var/config (or something of the sort).  Really, all I care about is being able to use simple logic to find a config file.  I don't want to have to read /etc/init.d/wsftpd to find out that the location of the config file was changed by the previous sysadmin or user.  I shouldn't have to do a file search.  I should be able to figure it out using a very simple and quick piece of logic.

On Jan 10, 2008 12:55 AM, Brent Saner <brent.saner@gmail.com> wrote:

okay, let's just move away from the whole steam engine metaphor for now.

the main point here is that *from a sysadmin perspective* config files are beautiful wonderful things.

for *embedded developers* plaintext files are godsends (remember? one of the most important things in embedded devices is footprint, not "user compatibility")

i'm guessing you're a programmer. hell, i can respect that. i can't code to save my life. but i'm a sysadmin. i like my systems lean, i like them easily maintained, and i like them with config files. you're also forgetting: config files are much more easily integrated and manipulated with shells. and like it's been mentioned, you code for the majority. if the majority really wanted something like this, we'd see something in much heavier development. it's too restrictive to really be adopted. everytime you increase compatibility, you decrease flexibility. you can't have your cake and eat it too. but hey, if you find a way to do this, let us know. it'd be interested in system-wide intercompatibility that places no restrictions on the individual softwares.

i feel that extra stuff on top is just fluff, even bloat. i wouldn't even use that for my home systems because i LIKE having my system clean and transparent. i don't want to have to go through messy consoles to configure, or point-and-click, or what have you. i don't even want that option on my systems because i wouldn't use it, i think it's a waste of time, and it has plenty of increased security risks (you ARE aware that one of the things that makes virii for windows so easy is that the huge majority of windows systems out there are basically configured the same way? there are plenty of holes with the idea).


there's a reason gconf sucks- they're trying to do what you're detailing. have you looked into it at all? http://en.wikipedia.org/wiki/Gconf it's main key points are exactly what you're describing. user abstraction layer, an autowatch daemon that applies changes as soon as they're made, database-centered... and it sucks. it's a model that is not going to play well with linux (or any nix).

but i mean, look. literally, you are the only one in support of this that's been posting to this thread. you've managed to convince nobody else in this list of the value to this system (none that have responded, anyways) and there have been a good number of responses. and there are a lot of smart cookies that have posted in this thread, both sysadmins AND devs.

sure, steam engines are one thing. but you're talking about something that cannot exist because of the nature of software development. hell, like i said, i'm a sysadmin and even i understand that much about the dev world.

progress is good. i'm not debating that.
but i'd hardly classify jumping off a cliff and expecting to fly by flapping your wings simply because you don't like airplanes as "progress"...

as i mentioned, at this point it's just beating a dead horse, and i'm really getting sick of repeating myself, and reading the same responses over and over.
done with this thread. mail me off-list if you feel as if you still need to understand why from an administration perspective why this would bring forth the Four Horsemen.

___________________________________________________________________________
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

___________________________________________________________________________
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