Some random jottings - best to ignore.
Managing a computer is hard. By 'managing', i don't mean anything complicated, just things like getting your PC and your Mac to share files. Now, this particular task is complicated partly because these two machines were built by organisations which hate each other, but partly it's because there are lots of things you need to change in lots of places (to be fair, not that many places - on the Mac, there are a couple of things to do in the System Preferences and one thing to do in the Directory Utility). This applies a fortiori to UNIX machines (including OS X to some extent), as management and configuration information is spread out all over the place - files, sysctl on BSD, /proc, etc. Not that PCs handle it much better: the PC solution to this problem is, roughly, "i know, i'll use the registry"; now, they have two problems. I'm not going to go into the problems of the registry here, since they've been dissected at great length elsewhere; suffice to say that it was a brave effort. The Mac, back in the days of OS N, did rather better: it had control panels, which were basically bundles of application- or subsystem-specific state with a UI on the front. Control panels were extensible - the panel itself was just a file, so an application could install a control panel for itself. This idea is so good, Windows copied it pretty quickly, as have various UNIX window environments. The problem is that Windows still has the registry as a separate thing, plus bonus configuration files all over the place; UNIX suffers from fairly patchy implementation of its control panels (since they're written by the window environment guys, not the application/subsystem guys, an old-school recipe for disaster). To be fair, the Mac also has separate configuration files, but at least there's a standard place to put them (/System Folder/Preferences). Not all apps stick to the rules, but it's generally pretty good. OS X, on the other hand, loses hard here - control panels become items in System Preferences, which is pretty good, but there's also configuration in other places, like the Directory whatnot, plus random files and stuff, and then the whole BSD sysctl thing under the hood as well.
So, how can it get better? I think control panels were on the right track, but they made one big mistake. A control panel is a bridge, which connects some random bit of application or subsystem on the back side with a standard interface - a control panel - on the front side; the problem with this is the front side: it shouldn't be a GUI panel, which is useful only to humans, it should be a programmatic interface, so that not only can a GUI control panel operate on it, other programs can as well. It should of course be a self-describing interface (in buzzword terms, it should have embedded metadata), so that generic tools can operate on it - you could imagine the GUI being generated dynamically, for instance.
This idea already exists - this is what SNMP calls an agent, or JMX calls an MBean (or maybe it also calls it an agent, i'm not sure; the JMX docs are a nightmare - have i mentioned recently that the guys who designed JMX were fucking retards?). It's pretty similar to what operating systems the world over call a driver. It's a bit of software which has a standard interface on the front and random whatever on the back. Now, the standard interface on the front has obviously got to be flexible - not all things support the same set of properties and operations; that means it either has a variable interface, or it has a constant literal interface which hides a variable dynamic interface (for example, it might just have the operations 'list properties', 'get property' and 'set property', but the set of properties will differ between objects).
The reason this would be good is that you could do things to managed apps and subsystems without going through the control panel GUI; from the command line, or programatically from another component, for example. It would also be good because it would (or should) make writing the management driver easier - GUI code is a pain. It could also be portable.
A driver could even just be a text or XML file, which listed the available properties and operations, along with shell commands which would get, set or invoke them. Maybe like this ([] instead of <>):
[driver id="sys.sound"] [title]Sound[/title] [property id="volume"] [title]Volume[/title] [type]percentage[/type] [get][cmd]/bin/soundctl volume %i[/cmd][/get] [set] [cmd]/bin/statsound[/cmd] [re]Volume: (\d+)%[/re] [!-- apply to output --] [/set] [/property] [operation id="beep"] [!-- you might use this to test the sound system --] [title]Beep[/title] [params/] [!-- would list params here if it took any --] [cmd]/bin/soundctl do beep[/cmd] [/operation] [/driver]
You can cook up ways to specify system calls to make, libary routines to call, properties to sysctl, files to edit, etc, or you could just wrap those operations in commands that could be called from here.
This approach doesn't handle complicated configuration operations (like formatting a disk) terribly well. These could either be handled by having an operation that just spawned an external program to do it (so the driver acts as an introduction agent for the relevant program, meaning the user doesn't have to dig around in /Applications/Utilities/Random Scary Shit), or the language could be made more powerful (usually a bad idea!).
Drivers could also define a GUI using XUL or some other GUI description language. With the amount of metadata given above, though, you could pretty easily construct an (ugly) interface at runtime.