Re: Proposed: gnome-system-tools

[William Jon McCann <mccannwj pha jhu edu>]

On Tue, 2004-07-20 at 10:01 -0400, Havoc Pennington wrote:
> On Tue, 2004-07-20 at 01:30, Jeff Waugh wrote:
> > <quote who="Havoc Pennington">
> > 
> > > Reiterate 
> > > http://mail.gnome.org/archives/desktop-devel-list/2004-June/msg00161.html
> > 
> > Is that "should not go in until these issues are resolved", or a reminder
> > that we really desperately need to resolve these issues? :-)

Hi,

This looks nice.  I think the Desktop Preferences list is a good one.
It is very useful to study what the user needs to do.

> Two points:
> 
> 1. Anything end-user oriented should be sucked into control center and
> designed top-down as part of control center, not kept separate.
> 
> If there are tools targeted toward *admins* we should consider those as
> a separate module and the interaction design should be done with admin
> as audience.
> 
> So "date and time" should probably be in the control center. "Boot
> loader" is an admin thing, or just "geek power tools"; same for
> "runlevel."

How are you defining the targets: administrator, user?  The distinction
seems critical to understanding this proposal.  In the old days this
distinction was clear.  However, it seems less so now.

Given the distinctions you make, how do you justify date and time
settings going into the control center?  They are not per-user (ie. they
affect everyone on the system) and they affect the hardware.  However, I
agree they should be there.

The idea that admin functionality should be kept in a separate
module/tool is interesting.  That makes it very important to know what
admin functionality really is.  The problem is: it varies - a lot.

> "Network" is more ambiguous, though the way we're approaching it at Red
> Hat (see Dan's NetManager thing in CVS among other pieces) is to "just
> work" with no config in the dhcp case, you would still need a control
> panel for static IP and so forth. The control panel should be clearly
> specified as admin-targeted or end-user-targeted and maintained with a
> hard line on that.

I love when things "just work".  Except when they don't.  Even when the
day comes that networking just works (everywhere) it won't "always
work".  There is now and, in my view, will continue to be a need for
diagnostic functions to be available to the user.  And when sufficiently
privileged, manual configuration functions.

The way I view this problem is that GNOME should provide user-targeted
tools for everything (reasonably) required to operate the system and
allow the system administrator/configurator/deployer to restrict access
to them as necessary.  [Or perhaps more securely - to provide them but
restrict access to them by default.]  Ideally, this is done on a per-
function basis and not a per-tool basis.

> For network profiles, probably you want to associate a profile with some
> kind of "signature" (heuristic way to identify a network) and switch the
> profiles automatically when those networks are joined (and then when no
> network is joined switch to Offline mode).
> 
> 2. The second point is the specific proposed top-down design, which does
> not include all the stuff that's in g-s-t, but does include some of it.
> 
> Basically the proposed list of preferences is a roadmap for what prefs
> we want to have (for users, it ignores admins), so the way to eval g-s-t
> is to include the parts that get us further along the roadmap
> (optionally arguing with the roadmap first, but the roadmap argument
> should be done holistically/top-down by presenting an entire alternate
> roadmap, not piecemeal). We could also add a separate roadmap for admin
> functionality.
>
> There has to be an overall design for *all* the user's preferences,
> which of them are in control panels, which are elsewhere, and so forth.
> The argument on what to have should be done looking at the whole list
> and whole plan, and then the implementation should iteratively move
> toward the result.

So, I think I'm really agreeing with you.  Just advancing the idea that
defining an admin user is highly problematic.

Small example,

Most desktop workstations here in my department have the network
configuration locked down.  However, laptops roam far into the wild.
Into strange lands that have never before seen GNOME men and women or
heard of the great DHCP.  There they must fend for themselves.  And
configure their system with the tools they have available.  That day
they will be Admin.  Let us prepare them well.


This is not an endorsement of any particular implementation of this
functionality. ;)

Jon