Thomas, I'd like to disagree with you on a point-by-point basis: 

> Friendly user interface (not necessary "fancy" GUI) is a 
> measure of all
> good quality software products. Amanda is not beyond the scope of this
> view.

So the Linux Kernel, MVS/OS, Sendmail, and PostgreSQL are not of good
quality? I disagree. AMANDA is written to be as invisible to the user as any
of the above. 

> Amanda is client-server based product. This means, while its client
> might be in "bare" OS, amanda server is not. The server has 
> to be fully
> functioning to provide the data recovering/restoring service. 

Not true. I can restore any of my files given only hardware that can read
the tape and a machine either running Red Hat 6.2 or capable of supporting
it. AMANDA is not needed for the restore, as she is only a backup manager.
The backup utility ( tar/dump/xfsdump, gzip, etc.) with mt and dd is all
that is needed to read the tapes. The possible loss of this functionality
was of great concern when adding the ability to split a disk across tapes
was being discussed on the AMANDA-Hackers mailing list.

> In terms of management of amanda, I appreciate all efforts that have
> been put into the product to make it less demanding for human
> intervention however, it is still a client/server 
> architecture involving
> many resources and objects. Initial configuration, though one time,
> takes some time. The difficulty of getting used to it has 

I think that a GUI for initial configuration will make it easier for new
users to get into trouble faster. The INSTALL file included with the package
is a very good start, with step-by-step instructions. Since AMANDA should be
compiled from scratch at least for each server, the new user isn't going to
avoid the command line during install.

> been reflected
> in this mailing list. For a changing (amount of data, schedule, tape
> devices) environment, managing amanda does not seem to be a piece of
> cake. As far as I am concerned, Bernd's presented a good 

Changes in the amount of data being backed up will usually be handled
correctly by AMANDA. Changing tape devices is also easy once you have the
first one working, and given the cost, unlikely to be a common occurrence.
And why would the schedule need to change frequently? Other than restore
tests and tape changes, there should be a time of day when your users can
tolerate the performance overhead of a backup running, in exchange for
having backups. If you need to run extra backups spontaneously, I don't see
how a GUI can be better than typing `amdump YourConfig &` at the shell
prompt. 

> question if we
> look at it as a bigger picture rather than as a stupid question from a
> lazy and less knowledgeable admin.

It's certainly not a stupid question. There are good places and good reasons
for a GUI. I'm probably going to write one in the next six months or so, as
we deploy AMANDA to client sites. 

As always, it's open source. If the lack of a GUI bothers you enough, you
can write one, or hire someone to write it for you. The software scratches
the collective itch.

That said, here's my case for a GUI: 

At remote sites where the user is unlikely to even log in to the console,
they need some way to interact with AMANDA. They at least need to know what
tape to put in next; need to be able to add new tapes; and mark existing
tapes as NO-REUSE. (In my case, I can count on them calling support for a
restore.) 

Once I have that in place and can release it, other people might want to add
things like a restore interface, or updating the disklist.