A Gnome 3 shell extensions failure
I really wish that the people who had written the Gnome 3 shell's extension system had studied something with a good one, such as Firefox. Here is the problem: as far as I can tell, the Gnome 3 shell has no way to disable or enable extensions. Instead, all you can do install or remove extensions; all installed extensions are automatically enabled and the only simple way to disable an extension is to remove it. This includes system-installed extensions.
(It's possible that editing an extension's metadata file could be used to disable it without removing it. I haven't looked and such a mechanism doesn't count as 'simple'.)
Right away I can tell that the Gnome 3 people simply don't care about shared computers, or at least not about system packages for shell extensions on such computers (eg the 'gnome-shell-extensions-*' packages in Fedora 15). If you and your friend use the same machine but want different sets of shell extensions, you both get to install extensions by hand instead of using the system packages. Applications to multi-user computers are left as an exercise for the reader.
But let's ignore that. Even on a single-user machine there are still any number of situations where you might want to temporarily disable some extension (or only temporarily enable one), including but not limited to troubleshooting. Removing extensions is a heavyweight operation that's not trivially reversible, since it requires removing files or moving them around. Firefox used to work just the same way as Gnome 3's shell (all installed extensions were automatically enabled); it changed for good reasons.
The more I look at Gnome 3 shell extensions, the more they look like a dangerously half-baked feature that the Gnome 3 shell developers do not really like and thus do not really support. Maybe this will change in time, but given the general Gnome developer attitude towards features, I'm not really optimistic.
(Another alarming lack is that as far as I can see, there is no way to start the Gnome 3 environment in a 'safe mode' that turns off all shell extensions. Also, it doesn't help that there's no GUI for installing and removing extensions, yet another thing that the Gnome 3 shell people could have learned from, well, almost anything with an extension system.)
One reason we install machines from checklists instead of via automation
I've been revising our install instructions for some OpenBSD servers recently, giving me an opportunity to reflect on how we set up machines here. Our general approach is to use a checklist of essentially cut and paste commands; I often go through a test run directly cutting and pasting back and forth. Given that we have the literal commands to run in the instructions, why not automate the install process by putting them all in a script?
Well, turn this question around. What would I have to do in order to transform the commands into an install script? At one level, basically nothing; I'd turn all of the commentary in the install instructions into script comments and we'd be pretty much done. And then one day something would go wrong during the install process and the script would explode spectacularly.
The drawback of automation is that there is nothing that's really checking for things going wrong. Oh, you can check for obvious errors (sometimes), like commands exiting with a failed status, but not all problems cause such obvious failures. Any number of failure modes will cause your commands to exit with a success status but either do nothing useful or badly mangle the system state.
(For instance, a
./configure 'succeeds' but fails to find all of the
dependencies you expected so it builds a version of the program without
features that you need.)
You can make automation more robust, of course. But it takes both work and anticipating how things may fail; a reliable, cautious automated install process is much more work than simply sticking all of the commands from the checklist in a shell script (and it's very hard to really be completely safe against problems). If we stay with a checklist that's performed by humans, we get much of the benefits of automation without having to do that work. Rather than try to code error checks, we can count on people to use their brains to notice when something's wrong.
(In our environment checklists are guides and aids for sysadmins, not things to be carried out by mindless rote.)
PS: there are of course situations where automation still makes sense even despite this. But that's something for another entry.