Brent Saner on 9 Jan 2008 21:55:12 -0800

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Config Files and Steam Engines

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? 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         --
Announcements -
General Discussion  --