[plug] Easy Installation: Linux Desktop Market

[Craig Ringer]

On Tue, Oct 25, 2005 at 10:03:16PM +0800, Kev wrote:
> James L. Clarke wrote:

> This is the ONE area where Linux gives the non-geek desktop user little 
> to no choice.  In my old OS/2, which I used for nearly 11 years, I had 
> complete choice about where I installed the application, what defaults 
> etc I wanted set for that app and whether or not I want system config 
> changes made for me automagically.  As a non-geek Linux user I just tick 
> a box and the rest is white man's magic.  It still concerns me what's 
> actually happening in secret behind there.

It's not secret. You can see where files are installed with:

dpkg -L $PACKAGENAME
rpm -ql $PACKAGENAME

and you can also extract the pre- and post-install scripts from the
package if desired. In the case of Debian packages I think they're
stored somewhere in /var/lib/dpkg anyway.

That said, I wish dpkg had a detailed "--print-what-the-heck-I'm-doing"
mode that could do things like run pre- and post- install scripts with
`sh -x' (actually, perhaps --debug does this - I need to check).
Your average user will NEVER want to see that though, it's of more
interest when debugging weird problems.

I do agree that the user gets little or no choice with regards to where
to install the files. I do think it'd be nice to offer some choice - at
least retargeting a package to an alternate root, eg
/home/myuser/packages (installation for a non-priveleged user) or
/myseconddisk/packages . The latter case isn't so much of a problem
with modern disks - is your OS _really_ going to be big enough not to
fit on one disk? (If so, you can always move, eg, /usr to the other
disk). The former is IMO a bit of a problem - it's nigh impossible for
an unpriveleged user to install packaged apps, or to test new packages
in without making a full chroot / virtual machine. I understand why this
is the case (dependency management; central database; UNIX apps relying
on fixed paths) and don't necessarily think it's practical to change,
but it'd be nice.

Overall, though, I just don't see the problem.

> I used to have all my stuff 
> set out neatly, logically and cleanly, but now I just close my eyes and 
> hope for the best.  And while Linux might be solid, there are still less 
> than solid apps out there (I've found a couple) which require a 
> combination of white man's magic and good luck to clean up.

Interesting. In most/all cases the package manager should be able to
take care of what's required, eg with `dpkg --purge remove packagename`.

I do agree that sometimes it's necessary to do things like track down
dotfiles or things that've been created by naughty post-install scripts,
but I don't think any system can fully protect against badly behaved
apps, packages, or installers. Not, at least, without restricting apps
to working entirely within a framework that tracks what files are
associated with which apps, etc - and even then, an app can misbehave by
(eg) reporting its config files as user documents.

> I stress, 
> NON-GEEK!!!  (Did I shout that loud enough??).  Even your typical 
> Windoze user can go into "Windoze Exploder" and remove dead apps and 
> clean up some of the mess left behind by rogue apps.

Really? Can they clean up all the garbage in the registry, the DLLs
installed into system directories, the files in the user's Application
Data directory, and so on? Similarly, on Mac OS X, can they remove the
kext the app installed that's making their mac kernel panic, find the
broken shared library it put in /System/Libraries even though it's not
supposed to, or find the plist file that it mangled when your mac
crashed due to the bad kext?

I've never met a "non-geek" with a hope of doing this sort of thing
without help. The vast majority of geeks would have a hard time with
some of it - myself certainly included. I've certainly met lots of users
who remove an app and either find they can't reinstall it because it
thinks it's installed, or find that reinstalling it doesn't actually
help - the damaged registry entries / settings are all still there.

On windows, it seems one must rely on add/remove programs. If the
package is well written that's no problem. If it uses some hideous
broken installer/uninstaller, you're SOL. Similarly, deleting the folder
from Applcations won't help a Mac user if the real problem is a file the
app or its installer has squrreled away elsewhere. I know about .dmg
installs; they don't stop the app doing the "install" behind the scenes,
nor do they stop it from putting settings in stupid places.

> The ability to have some kind of control where you put stuff, so that 
> you can find it again later is essential in my opinion.

I guess I just don't understand that. On a UNIX system, apps are just
there on the PATH. In a desktop environment, they'll be in the menus
too. Since it's generally not a good plan to go fiddling with the files
installed by a package (unless they're config files, of course, which
should always be in /etc) there's rarely any need to go poking through
what it's installed. Your "non-geek" user should never need to worry
about it.

When you do need to go digging through the package contents, you can
find where it's put things using the commands I mentioned above. Package
installation GUIs can get the same info, though I don't know how many
provide a UI for the user to get to it.

> Linux would be better if there was some kind of standard, but there's
> not.  Each distro does its own thing, and some even hedge their bets
> by doing eveyone's thing - all at once.

Honestly, despite the issue with different package formats, I think
there's a *much* stronger standard on Linux for where to put things and
how to manage them than on basically any OS out there. Check out the
filesystem heirachy standard, for example.

On a Mac or a Windows box, files may be scattered throughout the system
by an installer, with little or no way of finding out where they went -
especially drivers / kexts and libraries.  You can sometimes find out
from the inf file of a Windows driver, but only sometimes.

> No, the Windows or OS/2 way is definitely a better way for end users. 
> Newbies are flabbergasted just at the maze of different packages there 
> are for the one app.  It's a mine field just learning which package you 
> require

Now that I can agree with. A common problem for users seems to be
discovering the name of the package they need to install to get what
they want. Then again, there are package descriptions, and package
management GUIs usually provide a way to search them, so I'm not sure
how serious the issue really is.

> ps  I have perservered for a year now, and will continue to do so.  But 
> that won't fix the parts of Linux which really are stoneage.

Heh. When it comes to stone age, you haven't seen the half of it...

-- 
Craig Ringer