Petreley On Simplifying Software Installation for Linux

markcappel writes "RAM, bandwidth, and disk space are cheap while system administrator time is expensive. That's the basis for Nicholas Petreley's 3,250-word outline for making Linux software installation painless and cross-distro." The summary paragraph gives some hint as to why this isn't likely to happen anytime soon.

Comments

Word

[Anonymous Coward]

"That's the basis for Nicholas Petreley's 3,250-word outline for making Linux software installation painless and cross-distro."

Was it necessary to include the word count? It's hard enough to get slashdotters to read a small article and post intelligently, this cant help...

Re:Word

[Anonymous Coward]

The article is surprisingly dense for such a word count -- yet is easy to read.

Petreley is undoubtedly getting the grip of this "writing thing"... ;-)

Seriously, though, however smart and logical are his conclusions, one thing bothers me: the installation should be simplified but "right", too.

I mean, there are other objectives besides being easy.

Last week I tried to install Red Hat 8.0 on a Pentium 75Mhz with 32MB RAM (testing an old machine as X-terminals). It didn't work.
The installation froze at the first package -- glibc (it was a network installation) -- probably due to lack of memory (as evidenced by free et al.).

Why? It was a textmode installation. I know from past experience that older versions of Red Hat would install ok (I used to have smaller computers).

My suspect is that Red Hat has become too easy -- and bloated. Mind you, I opted for Red Hat instead of Slack or Debian because of my recent experiences, in which RH showed to recognize hardware better than others.

I hope Petreley's proposed simplification, when implemented, takes size into consideration. The way it is (using static libs, for instance), it seems the other way.

The article as a whole, though, present neat ideas and it's one of the best I've recently read.

Autopackage comes to mind

[Simon (S2)]

Autopackage comes to mind.

from the site:
* Build packages that will install on many different distros
* Packages can be interactive
* Multiple front ends: best is automatically chosen so GUI users get a graphical front end, and command line users get a text based interface
* Multiple language support (both in tools and for your own packages)
* Automatically verifies and resolves dependancies no matter how the software was installed. This means you don't have to use autopackage for all your software, or even any of it, for packages to succesfully install.

Static linking problems

[digitalhermit]

Static linking might be useful as a workaround for the more esoteric distros, but it has its problems. For one, if you statically link your application then anytime there's a security fix or change to the linked library you'll need to recompile the application, not just upgrade the library. This would probably cost more in administration time than upgrading a single library since multiple applications may be dependent on the one library.

Re:Static linking problems

[Ed Avis]

Static linking is a seriously bad idea. Part of the job of a packager is to arrange the app so it doesn't include its own copies of packages but uses the standard ones available on the system (and states these dependencies explicitly, so the installer can resolve them automatically).

Take zlib as an example of a library that is commonly used. When a security hole was found in zlib a few months ago, dynamically linked packages can be fixed by replacing the zlib library. This is as it should be. But those that for some reason disdained to use the standard installed libz.so and insisted on static linking needed to be rebuilt and reinstalled.

(OK I have mostly just restated what the parent post said, so mod him up and not me.)

Quite apart from the stupidity of having ten different copies of the same library loaded into memory rather than sharing it between processes (and RAM may be cheap, but not cheap enough that you want to do this... consider also the CPU cache).

A similar problem applies to an app which includes copies of libraries in its own package. This is a bit like static linking in that it too means more work to update a library and higher disk/RAM usage.

Finally there is a philosophical issue. What right has FooEdit got to say that it needs libfred exactly version 1.823.281a3, and not only that exact version but the exact binary image included in the package? The app should be written to a published interface of the library and then work with whatever version is installed. If the interface provided by libfred changes, the new version should be installed with a different soname, that is libfred.so.2 rather than libfred.so.1. It's true that some libraries make backwards-incompatible changes without updating the sonames, but the answer then is to fix those libraries.

Gentoo

[Tyler Eaves]

emerge

Doesn't get any simpler than that. Come back in a minute to 12 hours (Depending on the package), and *poof* new software. Ditto BSD ports.

Re:Gentoo

[sirius_bbr]

I tried it (gentoo) some time ago. After two weeks of frustration I moved back to debian.

For me it was more like
1. emerge
2 come back in 8 hours and then:
a. see whole bunch of compilation errors,
b. dependencies were not sorted out correct, so nothing works
c. combination of above

I specially liked (still do) the optimization potential (where debian is stuck at i386), but it didn't work for me.

Fallback

[Anonymous Coward]

Place user applications in their own directories

This single rule alone would eliminate most of the problems. It enables fallback to manual package management, it resolves library conflicts, it avoids stale files after uninstallation and it prevents damaging the system which can be caused by overwriting files during installation and subsequently removing files during uninstallation.

General bad attitude towards anything easy

[Microlith]

The first obstacle to overcome is the bad attitude many linux users have that if something is easy to install, or easy to use, it is therefore bad.

As I see it, many would like to keep the learning curve very, very steep and high to maintain their exclusivity and "leetness" if you will.

For instance, the post above mine displays the ignorant attitude that "easy to install" by definition equals "unstable software" and has only a jab at MS to cite as a reference.

That's truly sad (though that may just be a symptom of being a slashdot reader.)

As I see it, not everyone finds: ./configure
make
make install

to be intuitive, much less easy, never mind what happens if you get compiler errors, or your build environment isn't the one the package wants *cough*mplayer*cough*, or if you even have said development environment.

Nor does it mean the software is any more stable. Could be just as shitty. _That_ is a matter of the developer of the program, not the install process.

No, please

[Yag]

Thats the reason windows servers are more vulnerable to attacks, because they give you the idea that its easy to mantain them... Its the same thing saying that you dont need any pilot on an airplane (and that you can put there anyone) if you make a good autopilot engine... We need more knowledge in system administration, not more automatisms.

Matrix Reloaded spoiler in parent

[jeroenvw]

WARNING: Stupid Matrix reloaded spoiler in parent, in the middle of the 4th paragraph

OpenStep / OS X frameworks

[pldms]

Did some of the suggestions remind anyone of the OpenStep frameworks idea?

Frameworks (very roughly) are self contained libraries containing different versions, headers, and documentation. Java jar libraries are somewhat similar.

The problem is that using frameworks requires major changes to the tool chain - autoconf et al, cc, ld etc.

Apple shipped zlib as a framework in OS X 10.0 (IIRC) but getting unix apps to use it was very difficult. Apple now only seem to use frameworks for things above the unix layer.

I suspect there are lessons to be learned from this. As another poster said, evolution rather than revolution is more likely to succeed.

emerge maybe easy.

[Anonymous Coward]

But installing gentoo is still hard.

Insert cd.
login in from the command line
net-setup ethx
cfdisk
mkrieserfs
wget ftp.gentoo-mirror.net/pub/gentoo/stage1.tar
tar xzjdocmnaf stage1.tar
mkdir /mnt/gentoo/
chroot /mnt/gentoo
scripts/bootstrap.sh
(10 hours later)
emerge ufed
edit use flags
emerge system
emerge gentoo-sources
configure kernel, having do lspci and googling obscure serial numbers to find out what modules to compile
install kernel
muck around with it's non standard bootloader
install cron and sysloggers
umount
reboot
spend two days sorting out the kernel panics
wait all week for kde to emerge.
processor dies of over work
huge nasty electricty bill arrives after running emerge for over a week 24/7

in other words, no

No no no!

[FooBarWidget]

First of all, RAM and disk space are NOT cheap. I spent 60 euros for 256 MB RAM, that's is not cheap (it's more than 120 Dutch guilders for goodness's sake!). A 60 GB harddisk still costs more than 200 euros. Again: not cheap. Until I can buy 256 MB RAM for 10 euros or less, and 60 GB harddisks for less than 90 euros, I call them everything but cheap.

What's even less cheap is bandwidth. Not everybody has broadband. Heck, many people can't get broadband. I have many friends who are still using 56k. It's just wrong to alienate them under the philosophy "bandwidth is cheap".
And just look at how expensive broadband is (at least here): 1 mbit downstream and 128 kbit upstream (cable), for 52 euros per month (more than 110 Dutch guilders!), that's just insane. And I even have a data limit.

There is no excuse for wasting resources. Resources are NOT cheap dispite what everbody claims.

It is not just the ease but the language...

[terraformer]

It is not just the ease of installation but also the language used during that installation that is foreign to many users. Having a nice point and click interface on linux installs is a major leap forward but these still reference things like firewalls, kernels, services, protocols etc. Most people, when faced with new terms become disoriented and their frustration level rises. These setup routines have to ask users what they are looking to accomplish with their brand spanking new linux install.

• Would you like to serve web pages? (Yes or No where the answer installs and configures Apache)
• Would you like to share files with other users in your home/office/school? (Yes or No where the answer installs and configures Samba)

Etc...

Apple has it right

[wowbagger]

From what I am given to understand of the way the Mac OS 10.* handles such things, Apple got it more closely to right.

As I see it, the following things need to happen to really make application installation be very clean under any Unix like operating system:

1. All apps install in their own directory under /usr/[vender name]/[app name] - the reason for including the vender name is so that when two venders release different apps with the same name (Phoenix comes to mind) you can still dis-ambiguate it. Also allow apps to install into ~/apps/[vender name]/[app name] to allow for non-root installation.
2. Under an app's directory, create the following subdirs:
   • [arch]/bin - any binaries that are OS/CPU dependent.
   • bin - shell scripts to correctly pick the right [arch]/bin file.
   • man - man pages for the app
   • html - help files in HTML, suitable for browsing
   • [arch]/lib - any shared libraries specific to the app.
   • system - desktop icons and description files, perferably in a WM-agnostic format, MIME type files, magic files (for the file command, and a description of each program in the app, giving the type(s) of application for each binary (e.g. Application/Mapping; Application/Route Planning).
   
   
3. Shells and WMs are extended to search under /usr/*/*/bin for programs, /usr/*/*/man for man pages, etc.
4. Programs shall look for ~/.{vender]/[appname] for their per-user storage area, and will create this as needed.
5. The system must provide an API for asking if a given library/application/whatever is installed.
6. The system must provide an API for installing a missing component - this API should be able to *somehow* locate an appropriate package. The requesting app will provide a list of acceptable items (e.g. need libfoo.so.0.1.6,libfoo.so.0.1,libfoo.so.0)
7. This is the biggest item, so I'm really going to stress it:
   

   PACKAGE CREATORS MUST BE HELD ACCOUNTABLE FOR BEING OVERLY ANAL-RETENTIVE ABOUT WHAT PACKAGES THEY REQUIRE

   
   Too damn many times I've tried to install FOO, only to be told by the packaging system "FOO needs BAR". But FOO doesn't *need* BAR, it just works "better" if BAR is present (e.g. the XFree packages from RedHat requiring kernel-drm to install, but working just fine (minus accelerated OpenGL) without it).

Were venders to do this, then a program install could be handled by a simple shell script - untar to /tmp, run script to install needed pre-reqs, move files to final location.

The system could provide a means to access the HTML (a simple, stupid server bound to a local port, maybe?) so that you could browse all installed apps' help files online.

As a final fanciness, you could have an automatic process to symlink apps into a /usr/apps/[application class] directory, so that if you wanted to find all word processing apps you could
ls /usr/apps/WordProcessors
and see them.

Not always a problem

[Simon]

Just want point out that problems with shared libraries aren't universal. Years ago AmigaOS had shared libraries that basically worked without significant administration problems, or a 'dll hell'.

Important features of the way AmigaOS libraries worked:

* All libraries were versioned, but not on the file system level. Each library contained a version number in it's header.

* Versions of the same library were always backwards compatible. This was Law. Software using an old version of a library must continue to work on future versions. This also meant that developers had to think out thier library API beforehand (because you would have to maintain that API). Libraries could be extended though with extra functions.

* Application programs had to 'open' libraries before using them. When opening a library an application would specify the minimum version that it required of the library. (If no matching or later version was found then the program would have to exit gracefully).

* There tended to be few (compared to Linux anyway) libraries. Libraries tended to be biggish. A few big libraries instead of many tiny libraries. This made them manageable.

* The backwards compatibility rule/law for libraries meant that software could bring it's own version of a library and update the existing version of that library, but *only* if it was a more up-to-date version.

As a previous poster pointed out, a lot of the problem would disappear if people (library writers) maintained compatible interfaces for the same library soname. I'm pretty sure that this is the way it was designed to work.

anyway, a FYI.

--
Simon

static linking not a good idea, here's why

[dh003i]

I posted this elsewhere, but it is worth posting again. There are at least 6 reasons why shared libraries are still better than every app having it's own library:

1. Bandwidth. No-one wants to have to take 2-4x as long to download programs.
   
   
2. Hard-drive space. Even if we all had 40GB hard-drives, no-one wants to waste it reproducing the same information a hundred times. People buy hard-drives to store data, not twenty copies of the same library.
   
   
3. RAM.Loading two copies of the same library wastes RAM.
   
   
4. Load-time.Having to load all of the libraries will increase load-time compared to cases where some were already opened (by other apps) and you don't have to load them.
   
   
5. Consistency.Part of the benefit of having shared libraries is shared behavior. Destroyed if app X uses Qt 2.0 and app Y uses Qt 3.0.
   
   
6. The Big 3S: Security, Stability, and Speed.Who knwos what insecure, unstable, and poorly performing version of a library each app comes with. And who knows what crappy options it was compiled with. Resolving these issues at one central point can be counted out. You want to deal with any of these issues, you'd have to do it for every application's version of a library. That means doing it many times separately.

The solution to dependency-hell is to design better dependency management. Reverse-dependency management -- so as to remove useless libraries when no-longern needed and avoid bloat -- would also be good. Gentoo is doing pretty well in these categories.

On making install process' simple. I think that a graphical installation does not necessarily make things any easier. Anyone here played Descent 2? That installed by a good old-fashioned DOS-installation. And it was not particularly hard to install, even though it was not a GUI-install.

It is also not necessarily a good idea to abstract into oblivion the technical details behind an install. Part of the philosophy behind Gentoo, for example, is to take newbies and turn them into advanced users. I think that a clear well thought-out install guide is a useful thing. Gentoo's install guide is thorough and has virtually no noise. Compare that to the install-guides for Debian, which are affirmative nightmares, filled with irrelevant stuff. Furthermore, a helpful and friendly user-community is always a good way to help new users orient themselves. New users are going to ask questions on forums that advanced users find obvious. That should not be an invitation to say, "RTFM bitch" at the top of your lungs. All of us were newbies at one point, and just because we may have had to learn things the hard way doesn't mean that others should too.