Boston Linux & Unix (BLU) 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

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] webmin



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
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org