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

Re: RFC: GUI tools for common Debian admin tasks

On Tue, Sep 05, 2000 at 06:24:28PM +0200, Frederic Peters <fpeters@swing.be> was heard to say:

  [anecdote snipped]

> So I drew the conclusion that what Debian needs for those users is simple
> GUI tools. [some will respond here with "we don't want those users" and I
> won't agree. This flamewar already happened. GUI tools doesn't mean you
> have to use them. blah blah blah.]

  I've been thinking along these lines too, but didn't want to mention it as
I'm not likely to be able to help implement it.  I'm thinking in terms of
something slightly simpler, though: just the stuff a "normal" user (whatever
that means) would need to set up and perform simple maintenance of a system.

  That might be as simple as collecting all the useful tools into one
interface, or as complex as writing new tools to do this.  Hardware
autodetection is important, of course, as well as the detection and setup
of new hardware (but that'll help everyone, and I think the boot-floppies
team is working on it now)

  I haven't used linuxconf much; could you extend that for this task, or
is it too much of a pain?

  The specific thing that triggered this thought for me was the realization
that setting up a printer on Debian is still pretty much black magic (even for
a fairly experienced user), especially compared to the tools provided with
other distros (RedHat, for instance, has a pretty nice printer configurator)

> Technically I thought about:
>   - toolkit: GTK+ (I would rather not use Gnome but that could be an
>     option and the tools could be integrated in the Gnome Control Center)
>     ["QT is now free software" messages to /dev/null, please]
>   - language: C/Perl/Python/... (doesn't matter)

  If I were doing it, I'd use Python, but I would definitely recommend against
any compiled language.  (there's no really heavy processing or low-level
operations; it's mostly high-level logic, parsing of data, and storing of
output data, which is where Python (for instance) particularly shines)

> I started coding proof of concepts thingies; they should be in my home
> directory on master (~fpeters/, is this accessible from http ?) soon.
> There is also a screenshot at
> http://gaby.netpedia.net/pics/Screenshot_GUI_tools.jpeg

  That looks pretty nice..haven't looked at the code yet.  I hope you store
this stuff in the "standard" config files instead of hiding it in some obscure
directory somewhere? :)  (yeah, this clobbers comments, but I assume that if
you're using the GUI tools you aren't sticking comments into your
configuration :P ) [1]

> PS: the philosophy behind looks like the one used by HelixCode in their
> future admin tools (to configure SMB shares, resolv.conf, ...) that I
> don't have tested yet. It would be a good idea to avoid duplicated work.

  Being able to have someone else's tools support our system might or might
not be less work..  (linuxconf springs to mind again, is it really that

> PS2: _don't_ send me copies of your mails. I'm subscribed to debian-devel.

  Aren't there headers that you can set to tell mutt not to do that?

  Oh, wait, there are still people who don't use mutt.  Nevermind. :)

    Good luck,

  [1] actually, that's an interesting idea: GUI tools that let people embed
     comments before/after specific blocks of configuration.  (don't worry
     about it now, but maybe eventually..)

/----------------- Daniel Burrows <Daniel_Burrows@brown.edu> -----------------\
|    The sigfile hits!   |    The only thing worse than infinite recursion    |
|   You feel confused.   |    is infinite recursion.                          |
\---- Be like the kid in the movie!  Play chess! -- http://www.uschess.org ---/

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: