How to Fix the Unix Configuration Nightmare

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."

Comments

Thoughts from someone who adminsters both

[weave]

Having had to administer both windows and multiple unix server, some thoughts (and since I'll be negative to both platforms, it guarantees zealots from both sides will flame me, bwahahahaha)

• The registry in Windows seems to be a logical choice. There are standard tools to use it, it can be manipulated remotely, and except for those horrible clid crap. It is, however, difficult to understand for a human except for those common areas like HKLM\Software\Microsoft\Windows\Run.
• The Windows registry implementation is horribly flawed. It's too likely to get corrupted. A lot of this is from being part of a roaming profile. Losing your registry is like losing all of your application's and user preferences. It really sucks.
• *NIX is a mess when it comes to location of config files, as stated in the article. Even various Linux distros. We have Redhat boxen doing a lot of work now, having switched from a proprietary UNIX (dg/ux) a while back. Some of my techs think we should switch to Debian. I installed it on my workstation in vmware. It's nice, but it'll just require re-learning where the hell everything is. Maybe no big deal but I've got too much to remember already.
• Windows registry trees are not commented. You need to know how to find various reg hack sites and own a ton of resource kits, just to keep a leg up on the crap. Even then everything is not revealed. "You should configure it through the GUI." Yeah, right, on 2,000 machines?
• UNIX config files generally only have one per app. Configuring an app is simply a matter of loading the config file into an editor, reading the including commentary, and adjusting to taste. The exception here is the redhat /etc/sysconfig tree where everything is basically just loading of env vars for other scripts. Not commented, minimal defaults, if you need to figure out something it's dig through docs or read the rc scripts yourself to figure out what to set in it. Yack...
• Windows configs are often done through a maze of menu entries, dialog boxes, tabs, "advanced" buttons, etc... It always leaves you wondering if you've convered everything...
• UNIX config files are easily replicated to another box for a poor man's backup/failover situation. I had a 2000 server in a SAN go down and while I could easily mount that boxes disks into another 2000 server, moving the printer and file shares over was a problem because that shit is all stored in the registry. Instead of a simply copy command, I'd either need to write some sort of program to extract and merge into the backup's registry or figure out another way to replicate the shares. Keeping config crap out of a common database means the service isn't tied to a box so much. Need to move it to another box? Install, copy config files, change a virtual DNS name to point to new location.
• Windows registry is horribly insecure, not by design, but implementation. Loads of apps insist on writing per-user stuff to HKLM during runtime. I should be able to make HKLM r/o for all users but if I do that, shit breaks horribly. Damn it, HKLM should only be scribbled into by an application during its install process.

Which BSD?

[jdavidb]

Folks, NetBSD advocate that I am, I must point out that Apple used FreeBSD. Or am I wrong about that? I always heard it was FreeBSD.

Actually it was a FreeBSD userland built on top of a Mach kernel. Somewhat similar to what GNU is attempting to do with Hurd. (In fact, there's been work to make the Mach kernels underlying both systems interchangeable. Hurd may run on PowerPC hardware sooner than you think.)

Not NetBSD

[mosch]

Since when was OS X based on NetBSD? It's based on FreeBSD. I know that NetBSD can run on table lamps, but that doesn't automatically mean it's the OS used on the new iMac.