Re: [tlug] disk configuration: drive mounting

[Frank Bennett <bennett@example.com>]

Before going away for awhile, I'll pile on here if I may.

On Mon, Apr 08, 2002 at 06:46:20PM +0900, Stephen J. Turnbull wrote:
> >>>>> "Marlo" == Marlo Rocci <comslave@example.com> writes:

>     Marlo> What I am seeking is to what extent has linux progressed in
>     Marlo> that direction.
> 
> Not very far.  Most of the projects I'm aware of are interested in
> interoperability, not in making Linux a "native emulation" of Windows.

(i.e. re the development of GUI configuration tools)

Chris mentioned the versioning problem with GUI tools, which is a good reason
to be intensely skeptical about GUI configurators.  Another, related issue is
flexibility.

<NOTE "GUI interfaces vs the command line">

Here's an exercise. Read the man pages for tar sometime, and then try to
design a menu hierarchy for it (no need to write any code -- just jot down
some pictures of what you think the user ought to see). You'll end up with
__hundreds__ of menu items, several of which need to be selected
simultaneously in order for "tar" to do anything useful.  The options cannot
be much simplified without losing flexibility.  And this is just one command
among hundreds.

Unix and Unix-like systems are so flexible, they have a chameleon-like
quality that takes a little getting used to at first.  This kit can be
stitched into virtually any network environment with a little work, and made
to do "Damn Near Anything" there.  Flexibility is what makes Unix and its
near-sisters useful.

If all of that flexibility were distilled into a menuing system (it could be
done, although it would take an AWFUL lot of work), it would be a nightmare to
use.  There are just too many possibilities.  And this is one of several
reasons to be skeptical about the utility of GUI configuration tools.

Recently (2002) I have been working on a menu-driven interface for a backup
system.  It is similar to a GUI, in that the user navigates with arrow keys,
and does not actually type anything at the keyboard to perform operations.
My aim is to create a tool that requires very little study or training to use,
and that will work for a reasonably wide variety of computers and backup
devices.  I have put a huge amount of time into designing and implementing the
user interface, and I'm pretty happy with the way it's going.

I don't think that anyone on this list would criticize the development of a
menued interface for a backup system, so long as it works reliably to do the
job it claims to do.  But to MAKE it reliable, I have ended up making some
pretty drastic design choices:

  o I have embedded the application in its own operating system. In the
    current version, you get Linux kernel 2.4.16.  There are no kernel version
    quirks because there are no kernel versions.

  o I have also abandoned networking support.  Completely.  Networking is too
    complex to set up automatically, and any network connection is a
    security risk too large for a small automated program to successfully
    address.

  o I plan to offer only two backup methods, one for fundamental backups, and
    another for incrementals.  People who want other options have access to
    the command line.

The moral of the story, to me, at least, has been that you can't make things
easy and offer massive deep flexibility at the same time.  In SOME situations,
ease of use is more important than flexibility.  Maybe the backup of laptops
and small workstations is one of these.

But life is easier in the long run if you have lots of options; and in
command-line Unix, you can keep them open.  It really is a good way to go.

</NOTE>

Bye for now.

Cheers,
Frank