Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Bill Bogstad wrote: > I would even argue that we have gone backwards in the Linux world. For > example, it seems like every Linux distribution now hides its boot > time status messages behind a contentless graphical boot image. The > result is that users never have a clue what is going on when their > system is booting. The objective should be to preserve the functionality of the old way, but not necessarily the appearance. The boot progress logs are ugly, not understood by most people being targeted by modern distributions, and only useful in the very rare case of a hardware problem. The important bit of functionality is that there should be a well known way to enable seeing the logs in the event they are needed. (Is hitting the escape key to show the logs universal?) That said, one of the first customizations I make on a new install: RCS file: /etc/default/RCS/grub,v retrieving revision 1.1 retrieving revision 1.2 diff -r1.1 -r1.2 11c11 < GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" --- > GRUB_CMDLINE_LINUX_DEFAULT="" > Put a [GUI] wrapper around the command line tools...and then show the > user of the wrapper exactly what commands/file changes were being > done as a result of their requested configuration change. > > For whatever reason, that idea doesn't seem to have caught on. Linux may fall short of this idea, but it probably comes closer to it than any other popular OS. A high percentage of GUI admin tools on Linux are simply wrappers around command line tools, and the better GUIs even provide log files in documented locations, so you can see what command was executed, and look at the extended error information that the GUI developer didn't have the foresight to capture and present. Modification of config files is definitely a sticky point, and many config file formats don't lend themselves to being modified easily, resulting in GUI tools that simply overwrite whats present. That's bad. This is, in fact, one of the reasons why I stopped using webmin. (That, and it got to be more work to figure out where or how in webmin to do what I wanted than to just read the target program's man page and make direct edits. webmin is like making config changes with mittens on. But I do think it is useful in some circumstances, and I've only briefly encountered it in recent times, and thus can't speak to its current state.) The increased use of config files that are separated out into a collection of files in a directory (i.e. /etc/modprobe.d), where you can put your hand-written customizations in a separate file that won't get clobbered by either GUI tools or the distribution updates, helps. But I'd like to see a defacto standard form around some sort of version control used by wrapper tools when modifying config files. That way you can review what was changed, when, and why. (I use RCS for this on manual changes, and it can come in real handy when I need to merge my customizations into distribution updates, on those programs that still use a single monolithic config file. No reason why this functionality couldn't be integrated into dpkg.) > I understand that we don't want to "scare people > away", but it seems like in the process we are losing out on > educating them as well. If it was truly the case that our computer > system never required human intervention to make them work, then it > wouldn't matter; but it seems unlikely that is going to happen any > time soon. Abstracting away details is inevitable. It's the only way we can deal with ever increasing complexity. A modern computer operator doesn't concern themselves with bits in a register, even though that's still happening dozens of layers below the UI that they are exposed to. I wouldn't put the burden of educating the user on the GUI, but a properly designed GUI should be layered on top of a command line tool or API (Dbus) so that anything the GUI can do can also be done through automation fairly easily, and it should log operations so things the GUI designer didn't anticipate breaking can be resolved. With other OSs you are more likely to encounter GUIs that are complete black boxes - no automation and no insight into what they are doing (or failing to do). -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |