Re: new modules consensus
- From: Havoc Pennington <hp redhat com>
- To: Murray Cumming <murrayc murrayc com>
- Cc: Mark McLoughlin <markmc redhat com>, Desktop Devel <desktop-devel-list gnome org>
- Subject: Re: new modules consensus
- Date: Fri, 13 Aug 2004 15:23:31 -0400
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.
>
> 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.
> > 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.
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
- 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
(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
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.
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]