Re: using the panel to uninstall packages.

[Miles Lane <miles amazon com>]

Thanks for the very thoughtful reply.  I'll look it over when I can
give it the attention it deserves.  Your points are well taken.

	Miles

Loban Rahman wrote:
> 
> 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     |
> \-------------------------------------------------------------------/