Re: new modules consensus

[Carlos Garnacho <carlosg gnome org>]

On Fri, 2004-08-13 at 15:23 -0400, Havoc Pennington wrote: 
> On Fri, 2004-08-13 at 04:08, Murray Cumming wrote:
> > Of course a focus on multiple machines will not make much sense for the
> > home user or laptop user with just one machine and one user.
> 
> Sure, but said user should have *end user* tools, not admin tools.
> Multiple machines is for admins.
> 
> > Is there anything about g-s-t that makes you think that it would be
> > impossible in future to allow
> > 1. A sysadmin to configure multiple computers/users.
> > 2. A sysadmin to prevent users from overriding his work, or even being
> > aware that they could try. (After all, those users will not have the root
> > password).
> > 
> > Personally, I don't see a conflict.
> 
> That isn't the point at all. It's not that there's a conflict. The
> question is: what is gnome-system-tools *for*.
> 
> In your mail you imply both that it's for admins and that it's for home
> users. Which is it? What I'm really looking for to support g-s-t is a
> definition of what it *is* in terms of target audience and long term
> direction.
> 
> If you look at the end user prefs list Seth did, what should be added;
> and which items in the list does g-s-t provide.
> 
> > > End users having to change systemwide settings in /etc for _desktops_ is
> > > a bug, and building UI for doing so is not the right fix.

Those desktops are on top of an unix based system, there are settings in
the users' interest that are only available for root user.

> > 
> > How will I setup my dial-up or DSL without this?
> 
> In FC3 networking will basically be configured by the logged in user (or
> simply automatically), at least in part. FC4 will move closer to that
> model. This is for desktops, the systemwide setup is still there for
> servers, etc.
> 
> >  How will I add a user so
> > that my friend can use the same computer.
> 
> This is an exception, yes. In a deployment of >1 machine you would have
> a sysadmin tool that modified LDAP/NIS type of thing. For a home user,
> you want a *simple* dialog that changes /etc/passwd.

Not all networks with >1 computer have ldap/nis working.

> 
> > > the end goal should be that
> > > nothing in the "end user setting" category should require the root
> > > password, it's a bug if anything does. That means that end user settings
> > > can just be in control center or the panel.
> > 
> > Some end-user settings affect more than one user.
> 
> There's date and time, and /etc/passwd. There isn't a lot else. All the
> hardware config sort of stuff can be either automatic or per-user.

Let's put an example, network config: static IPs in a network is not an
isolated case, WEP key in a wi-fi network is not an isolated case, PPP
configuration is not an isolated case. 

Trusting in the distributions for doing this automatically and not
providing any GUI for doing this is IMO an error

> 
> You have to go top-down to figure this all out, e.g. the list of end
> user prefs I posted. Which of them affect all users at once? Of those,
> where should they live in the UI? And how close is g-s-t to providing
> them?
> 
> Let's look at this concretely; based on g-s-t screenshots page, the
> items are:
> 
>  - users and groups
>  - date and time
>  - network
>  - bootloaders
>  - runlevel
> 
> I would say: 
>  - users add/remove, date and time should be in gnome

Ok, I'm even trying to avoid group names knowledge when adding
privileges to an user. For date/time no comments :)

>  - groups is an admin feature
>  - the network tool is basically wrong in concept; the config should be 
>    automatic and/or per-user for the most part

Can't agree. It's too much idyllic to assume automatic configuration for
everything

>    (yes, small environments with static IPs can use a tool like this; 
>     but end users shouldn't need the tool, and large deployments will 
>     use something scalable such as LDAP or at least scripts)
>  - bootloaders is a geek feature
>  - runlevel/services is a server feature, it makes no sense for desktop

Maybe, but still can be useful for some users, as is the system monitor,
which is already part of the desktop.

Regarding the current tools, I can't see that cristal clear split
between admin and single user needs, and I really think that providing a
(still somewhat) desktop integrated GUI for these tasks is much more
user friendly than assuming that a user doesn't need this kind of
things, and thus, not providing anything at all :)

> 
> What I would do, if I were deciding, would be:
>  - add user (but not groups) and date/time to control-center and iterate
>    them forward as part of the overall desktop design
>  - convert the rest of g-s-t to gnome-admin-tools and focus on
>    the SMB/small-deployment system administrator, and perhaps 
>    also the technically advanced user; maybe gnome-nettool 
>    is in this category too
> 
> Anyway, I'm giving specifics but the specifics are just meant as
> examples. The real point is, I haven't seen anyone define the overall
> plan, or the target audience, or what end user benefit/experience we're
> aiming for.

Gnome desperately needs a plan regarding desktop/system preferences,
sadly the current control center situation is not helping at all when
trying to integrate g-s-t, and adding anything else is just contributing
to the clutter (and this is also relevant to g-v-m as well)

	Carlos

> 
> Havoc
> 
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list