So I had to tinker with Debian administration a bit... I can't help but philosophize about how some fairly abstract CS theory can apply to pragmatic admin stuff - packages, admin shell-scripts, etc.
Debian's dpkg already allows treating software in a fairly declarative OOP fashion. You have concrete "implementation" packages providing functionality guaranteed by special virtual packages, generic system-wide scripts for things like startup/shutdown sequence management, conf.d approach (one of my favourites) for modular "plug-in" configuration, etc. It is all very much interfaces vs classes and design-by-contract.
So I wonder if there is room to go a step further. Make packages declare their functionality in an abstract IDL/CORBA-like interface language. For example, a /usr/share file is kind of like a read-only property getter. An executable is a method (obviously). A config file is a special variation of user input (where the user is the admin). And so on and so forth.
Then, packages can declare their prerequisites in a much more granular and consistent way - by indicating individual files and utils that they use. There could be even tools that would automate half the work of a package maintainer. For example, compile the program directly from a SourceForge tarball, run it and sniff out its runtime library dependencies, system file access on the fly. In fact, existing debs and rpms could be scanned and adapted appropriately without a recompile.
What does that do? The package manager can be much smarter in detecting broken dependencies and software management issues. There is also room to get closer to a nice unified configuration system (not that everyone really cares too much about that). This would also help a lot to make Linux consumer-friendly (although that is still mostly about desktop app usability). It just seems so much... cleaner.
There is more to this - current Linux kernel allows so much cool admin trickery (such as LUFS) I am surprised core OS maintainers are not using it for more.
