Re: using the panel to uninstall packages.

[Loban Rahman <loban enigma caltech edu>]

I think the reason a lot of people (including me) are disagreeing with you,
is that most linux users don't want ease of use by sacrificing security
and stability. Windows went along that path, especially the stability part.
It's just way to easy to mess things up, and more often than not, Windows
doesn't complain until it is too late.

I think it is inaccurate to say that "to make a system bullet proof the
user has to spend a lot of time to learn how to do so". In fact, I would
say that statement applies to Windows. Because Windows give you so much
freedom, one must be very wary if one wants his system to stay very stable.
On the other hand, using Linux and Gnome (or whatever DE), because
restrictions are placed on adding programs and interacting with files,
one has a much stabler system without knowing as much!

I've copied below the list you gave, and answered how each functionality
can be achieved using mostly existing technology, and yet be as easy
to use as Windows but much stabler.

> 	Install programs

Programs/Applications should be distributed in RPM, DEB, or whatever is
the mainstream package format for the time. When one wants to install
and RPM, one will just double click the RPM in the file manager. (Right
now, GMC just browses the contents. I think the default option for it
should be launching the GUI rpm installer with that particular RPM)
The GUI RPM installer (GnoRPM is a good one) can take care of installing
the rpm very nicely.

Now to make this as easy to as InstallShield in Windows. InstallShield
does a few major things:
	(a) Asks where to install the application.
	(b) Sometimes requests info on the person installing it to
		personalize the application.
	(c) Installs the application, and does checks like disk
		space and whether all files were installed correctly.
	(d) Stores a file that has information on what was installed.
		Thi file is used during the uninstall process.
Generally, in windows, the application being distributed has a file 
called setup.exe that starts everything.

Okay, both RPM and DEB (these are the only package formats I'm familiar
with) take care of (c) very well. RPM stores how much disk space it
will use up installing, and checks for enough space. It also guarantees
that the files installed correctly or else it barfs an error. It also
takes care of (d), in a much better way too. Instead of storing each
application's info in a seperate file it does it using a central database.
More often then not I've deleted the "Uninstall file" in Windows and
hence couldn't cleanly uninstalled the app in question. Of course,
since a gui frontend is being used, the user can see nice progress bars
of how the intallation is going, and if something goes wrong, and error
message. RPM is even better because it does dependency checks and so
if something might break, it'll warn the user.

RPM handles relocatable programs, but very few rpm's do that. This is one
area where ease of use falls a bit short. Because the linux (or whatever)
directory structure is quite strictly defined, it's a bit more difficult
to, say, install a new hard drive and start using that to install and
use applications right way.

Part (b) should be taken care of by a program in the application itself.
I know RPM has an option of specifying commands to run immediately after
installing. One such command could be a gui that does this personalization
and perhaps displays the README file, or whatever. This is intirely up
to the application, as it should be.

Just a couple more points. Firstly, sometimes an application uses libraries
or utilities found in other RPM packages. These ought to be distributed
as well, unless they are defacto packages included in every distribution.
It will be, however, a pain in the ass to double click each RPM to install
it. One could select all the RPM's with the mouse, right click and choose
select all. But that's a pain and also, if suppose one RPM was older than
an already installed package, the command would fail and the user would
have to manually unselect that. What would be nice is if RPM's could embed
OTHER RPM's inside of them. Then, the default option would be to install
the "main rpm" and any embedded rpms as needed. When uninstalling, only
the main rpm and those embedded rpms that weren't already on the system
would be removed. (Hence the user won't lose an already installed package
that benefited with an upgrade).

The last "ease of use feature" is auto-installing CD's and stuff. I guess
there could be a "setup.sh" script included just like in Windows that
does nothing more than "$(RPM_INSTALLER) application.rpm" where RPM_INSTALLER
is an environment variable defined by GNOME (using a gui of course).

> 	Run programs

Done from the menu of course. If the app doesn't install a desktop entry,
it's README (displayed on installing) should at least provide the names
of the executable(s) so that the user can do it from a terminal or make
a shortcut/desktop entry himself.

> 	Remove programs

Most windows programs have an "Uninstall so and so App" right in the start
menu. This is again another case of "Very easy to use but also easy to
screw up". If one want's to remove an application, it takes little effort
to start the gui package manager and remove the application. That way
one doesn't accidentally choose to uninstall it. Once again, the main problem
is that the package manager doesn't remember the "helper" rpm's one had
to install. This again, can be rectified if, as I said before, RPM's can
have embedded rpm's in them and the database keeps track of them, as detailed
above.

Of course, I for one still think that only root should be able to uninstall
and install apps. Keeps the system secure and stable. And yes it is a pain
to log out and log in as root (or su to root) anytime one want's to do this.
I think this List has already had some discussion of ways to make a program
which would normally require root access pop up a dialog requesting the
root password when it is launched as a non-root user. (It could either be
in the Gnome-Lib API or handled by a seperate app that reads desktop entries
or whatever).

> 	Interact with files (put them on floppies, etc.)

Well, GMC sort of works, but has a lot of deficiencies. I'm sure Nautilas
will take care of that. The main thing I'm waiting for is threaded file
manipulation. The pain of mounting floppies and cd rom's is almost gone,
with Gnome's magicdev and what not. I think the kernel will also soon
support automounting and then it will not be an issue any more. For now,
in gnome, if you double click the floppy or CD icon, it automatically
mounts it if it isn't already, which works swell for me.

> 	Install hardware and drivers
> 	Remove hardware and drivers

I don't have too much knowledge about these areas. But I think this is more
of an issue for the kernel than for gnome. Although I can see how people
will benefit from easy installation of drivers for hardware (as root) of
course.

> 	Connect to the internet and other setup stuff

Once again, these are all seperate utilities. Most distributions come
included with them. Most however, are text based. And although it is true
that a unified Gnome Version of such utilities would be nice, it would be
difficult to do because the implementation would differ from distribution
to distribution. 

Phew. That's enough from me.

	= L

On Tue, Feb 15, 2000 at 10:06:44AM -0800, Miles Lane wrote:
> Daniel Veillard wrote:
> > 
> > On Tue, Feb 15, 2000 at 09:45:29AM -0800, Miles Lane wrote:
> > > I wonder about that permissions thing.  For Linux to penetrate the
> > > home market with naive users, there'll need to be a configuration option
> > > that makes it easy for users to easily do all the things needed to do
> > > what they want to do.  This includes adding and removing programs.
> > 
> >   This need root access. I have the feeling taht you need to study
> > more the state of the art before suggesting to apply the "well-known
> > but doesn't work right" mechanism found on Windows.
> >   Before designing a solution for "home market with naive users" one
> > really need to understand the potential problems very well, as well
> > as be fully knowledgeable in the state of the art,
> 
> I'm talking about a migration path for folks who have already learned
> a different way of doing things.  It's fine to have a system that can
> be made bullet-proof for the users who want to spend the time to learn
> how to do so.  Having an option that basically allows a naive user to
> install and remove programs easily basically is just enabling them to
> do what they'll do anyway if you give them the root password.  Where's
> the benefit, then?
> 
> The people I am talking about want to do the following:
> 
> 	Install programs
> 	Run programs
> 	Remove programs
> 	Interact with files (put them on floppies, etc.)
> 	Install hardware and drivers
> 	Remove hardware and drivers
> 	Connect to the internet
> 	Use e-mail
> 	Browse the web
> 
> That's about it.  System administration is not what these people
> want to do.  If you want to cause a Windoze user's eyes to glaze
> over, just say "system adminitration."  These are users not admins.


/-------------------------------------------------------------------\
|   LOBAN AMAAN RAHMAN  <-- anagram of -->  AHA! AN ABNORMAL MAN!   |
|  MSC #763, Caltech, Pasadena, CA 91126, USA. Tel: 1-626-395-1407  |
|     loban@earthling.net, loban@caltech.edu, http://i.am/loban     |
\-------------------------------------------------------------------/