[Leaplist] FSM Essay on Linux Software Installation

Wed Jun 24 11:00:07 EDT 2009

I think its really a "Linux should be like MacOSX" sort of rant, since 
MacOSX is the only mainstream OS that actually does the self-contained 
bundle thing.

However, there is one F/OSS system that actually is making a valiant 
effort in the same sort of direction.  I speak of PC-BSD, and its PBI 
format:
http://www.pcbsd.org/content/view/20/26/

-Derek

On Wed, 24 Jun 2009, Richard F. Ostrow Jr. wrote:

> Obviously a rant from someone who simply hasn't read his man pages.
>
> Any user can install anything he/she wants without root priveleges, as
> long as he/she has executable access to any folder (including his home
> directory, for example). For example, a simple './configure
> --prefix=$HOME/local && make install' on any GNU autoconf sources should
> do the trick nicely. This negates 99.95% of what he's talking about.
>
> Also, simply defining a local library path before system-wide ones is just
> asking for trouble. What if you install a library that doesn't work for
> system binaries, but works just fine for your stuff? Suddenly, ls doesn't
> work any more. No, the proper way to do that is to simply use the
> LD_LIBRARY_PATH environment variable to define the library path ONLY WHEN
> YOU NEED IT. Alternatively, compile your stuff with -rpath to tell the
> binary where it can find its libs.
>
> On Tue, June 23, 2009 6:31 pm, Bruce Metcalf wrote:
>> Gang,
>>
>> Copied below is an essay from this week's "FSM Newsletter" about
>> software installation in GNU/Linux. To this neophyte, non-programmer,
>> non-expert, he asks some reasonable questions, and outlines a few
>> possible answers.
>>
>> I'd like to hear comments from those with more experience than I before
>> I go say something stupid based on it.
>>
>> Bruce
>>
>>
>>
>> -------- Original Message --------
>> Subject: FSM newsletter - 2009: software installation in GNU/Linux is
>> still broken
>> Date: Tue, 23 Jun 2009 05:09:14 -0700
>> From: chief at freesoftwaremagazine.com
>>
>> 2009: software installation in GNU/Linux is still broken -- and a path
>> to fixing it
>>
>> GNU/Linux is slowly invading everybody's everyday life. I won't say "The
>> year of the GNU/Linux desktop is here". Been there, done that. But,
>> GNU/Linux is definitely imposing its presence -- think about Android, or
>> the number of people who are currently using GNU/Linux as their main
>> desktop.
>>
>> And yet, software installation in GNU/Linux is broken. No, not broken...
>> it's _terribly_ broken. Why is that, and what can be done to fix it?
>>
>> # The current story
>>
>> Most distributions today (including the great Ubuntu) are based on
>> _package managers_. If you want to install a piece of software, you grab
>> it from one of the official repositories, and your package manager will
>> "explode it" onto your computer's file system. A program will place bits
>> and pieces in `/usr/bin`, `/usr/lib`, `/etc`, and so on. This is
>> normally done through a package manager. In Ubuntu, for example, you
>> would probably use Synaptic. A package manager will normally solve all
>> the "dependency problems" for you. Ah, dependencies... basically, an
>> image viewing program might need, for example, `libjpeg` to function
>> (`libjpeg` being a library of functions to open, save, and generally
>> deal with JPEG files).
>> This is a very Unix-ish approach. It works perfectly well for servers,
>> but fails on several levels for clients. Why?
>>
>> There are several _drastic_ problems with this approach. Here is a
>> comprehensive but by no means exhaustive list (which will probably grow
>> as people e-mail me):
>>
>> * Users need to have root access in order to install a piece of
>> software; no per-user installation is allowed
>> * It's very tricky to install several versions of the same piece of
>> software. Just think of the poor graphic designer who needs to install
>> several versions of Opera and Firefox;
>> * Users are stuck with the piece of software installed system-wide;
>> * The software needs to be downloaded from the official repositories.
>> Well, it doesn't _need_ to, but an average user wants to stay well away
>> from unofficial repositories for technical reasons;
>> * In some cases (especially when the user adds repositories or installs
>> packages directly), the dependency-checking mechanism often _fails_ and
>> users end up with _circular dependencies_. They are nasty;
>> * A piece of software is bound to a specific distribution, and -- what's
>> worse -- to a specific version of that distribution too. It's not
>> trivial to install Openoffice 3.1 on Ubuntu 8.10. You can argue that you
>> can install the bunch of .deb packages from OpenOffice's web site. Tell
>> that to your grandmother or your average inexperienced computer user.
>> * It's not trivial to "give" a program to a friend. To the end user,
>> giving a program to a friend should be as simple as dragging an icon
>> onto a memory stick; instead, files are scattered all over the system.
>>
>> It's 2009, and GNU/Linux is still plagued by all of these problems. Even
>> Ubuntu, a distribution I love, is plagued by all of these issues -- and
>> we are talking about a distribution aimed at end users!
>>
>> # What the story should be
>>
>> The story should be very simple:
>>
>> * Users should be able to install software even without being root
>> * Users should be able to install different versions of the same
>> software immensely easily
>> * Users should be able to run either their own version of the software,
>> or the one installed on the system (if any)
>> * It should be possible to download and install software even though it
>> doesn't come from an official repository
>> * Software just needs to work -- unchanged -- even if it's a bit old and
>> it's run on a newer distribution
>> * It should be possible to "give" a piece of software to a friend by
>> simply dragging an icon onto a memory stick
>>
>> All this is true with Apple's OS X. They got software installation just
>> right -- although a few programs, lately, seem to come with an ugly
>> installation process.
>>
>> # Where does the problem come from?
>>
>> Don't get me wrong: I think Ubuntu is a fantastic system, and gets a lot
>> of things right. It think the problem stems from an issue that is more
>> philosophical than anything else.
>>
>> The issue is at the heart of this article, and deserves to be put in bold.
>>
>>> **Every GNU/Linux distribution at the moment (including Ubuntu)
>>> confuses system software with end user software, whereas they are two
>>> very different beasts which should be treated very, very
>>> differently.**
>>
>> I think using dpkg/apt-get or rpm/yum for system-wide software,
>> libraries and so on is _the_ way to go. GNU/Linux's success in the
>> server arena is not a coincidence: a distribution is made up of several
>> independent "bricks" which create a majestic building.
>>
>> However, using the same philosophy -- and therefore architecture -- for
>> end-user software is just too limiting. My point list above is not "a
>> list of unfortunate drawbacks". It's one of the major reasons why
>> GNU/Linux hasn't achieved mass penetration in the desktop arena.
>>
>> What bothers me is that while all of the other problems are being solved
>> (vendor support amongst the others), this one is a persistent thorn in
>> every GNU/Linux user's side. A painful one.
>>
>> # Existing material about this problem
>>
>> A lot of debate-- as well as software -- exist about this issue. In
>> terms of software, you can get a whole distribution -- GoboLinux --
>> which follows exactly this priority: one directory per program. There is
>> a problem with GoboLinux's approach: it applies the "one directory per
>> thing" approach to _everything_ -- including system libraries and
>> server-side programs. GoboLinux also goes one step further by changing
>> completely the file system -- an idea I am strongly against.
>>
>> In terms of what's been said, there are several discussions about this
>> in Ubuntu and Debian. A good start is the [Rename Top Directory
>> Names][http://brainstorm.ubuntu.com/idea/6243/) in Ubuntu. This link has
>> a _long_ list of duplicates.
>> There are also many, many "blueprint" drafts in Ubuntu's launchpad.
>> There are so many in fact that you will get lost reading them. A lot of
>> them talk about a simplified directory structure for the system, which
>> as a _consequence_ would imply simplified software installation.
>>
>> =TEXTBOX_START=What's wrong with GoboLinux?=
>> I don't think GoboLinux's approach is a winner for two reasons:
>>
>> * The Unix file system has been around for a long time -- for good
>> reason. It does work _extremely_ well to keep a system sane and working.
>>
>> * It would meet too much resistance in the GNU/Linux community -- for
>> good reason.
>>
>> However, GoboLinux gave us a practical example that this change _can_ be
>> made. It's actually _possible_.
>> =TEXTBOX_END=
>>
>> # Four steps to fix the problem
>>
>> I can't really fix this problem. It will take a lot of effort, and a lot
>> of courage from major players to even start heading in the right
>> direction.
>>
>> The first step, is to face the truth and admit that there is a problem.
>> This is the aim of this article, which -- I hope -- will resonate within
>> the GNU/Linux community.
>>
>> The second step is to set out a path which might eventually lead to a
>> solution. This is what I will attempt to do in this article. The
>> solution will be generic and I will try to borrow from as much existing
>> software as possible.
>>
>> The third step is to improve on the proposed solution; this is tricky,
>> because there needs to be the right balance between too little and too
>> much planning. It also requires somebody to coordinate the discussion,
>> able to lead everybody towards a _full_ solution. My secret dream is
>> that somebody from Canonical, or from Red Hat, would do this.
>>
>> The fourth step is implementation. This is the hard part. I am sure that
>> implementing it will reveal problems, limitations --and more.
>>
>> # My own semi-technical take
>>
>> Here is my idea. I haven't programmed in C in _years_; this means that I
>> might make some silly mistakes. However, I am confident I can provide a
>> good starting point.
>>
>> Here we go.
>>
>> * There should be a comprehensive list of libraries, and versions,
>> expected to be available with the operating system. Today, GNU/Linux has
>> quite a number of desktop installations and we have a pretty strong idea
>> of what a desktop system seems to expect. This list should include both
>> Gnome and KDE. This should be a cross-distribution list. To do this,
>> maybe a distribution (Ubuntu?) might write a list, and then others might
>> follow. Every two years or so a new "version" of the super-system might
>> come out with an updated list of libraries and versions. Note that
>> applications should do their best to work on current systems, _and_ on
>> the previous one. This would mean that newer applications would have the
>> potential to work on four year-old systems.
>>
>> * There should be a well defined directory tree that contains a whole
>> application. It should include 1) the executable 2) the icon 3) the
>> "lib" directory with extra libraries not listed in the point above and
>> 4) anything else. This directory should be expected to be read-only. The
>> directory could have the extension `.apx` and have a file called
>> `application.xml` in it.
>>
>> * In case libraries are provided, the system should add them to the
>> library path _before_ the system ones. So, if a program needs a specific
>> library that is not listed in the first point, or if for some reason
>> needs a different version of the "stock" libraries then:
>>
>> * GNU/Linux file managers should show those directories and their icons
>>
>> * You should have different directories for the different versions of
>> executables and libraries according to the processor.
>>
>> * The operating system should keep track of the applications available
>> (each folder with extension `.apx` and with a `application.xml` file in
>> it could be expected to be an application) and their locations. This can
>> be done *easily* with triggers in the kernel when a file is moved or
>> copied etc. The system should allow two different copies of the same
>> application in two different directories.
>>
>> * The operating system should offer a way to upgrade all the existing
>> applications (since it knows what's on the disk and what version it is).
>>
>> * There should be a security system where whoever distributes the
>> application is able to "sign it" -- users should be able to view the
>> signature before running it. This can be extended as far as we want to
>> take it.
>>
>> * The distribution should have the option to hide completely, in its
>> package manager, any end user applications. Yum/apt-get/synaptic and
>> such like should still be used to keep the system up to date -- and not
>> just for end-user programs.
>>
>> * There should be a "recipe system" like the one available in GoboLinux,
>> where a piece of software is compiled making sure that it works in its
>> own directory. Here, looking at GoboLinux did would be immensely
>> beneficial. Note that providing a working recipe for each piece of
>> software would be a big task, but it would be limited to end-user
>> software.
>>
>> Whoever manages this system should look closely at what OS X does,
>> because OS X's engineers had the exact same problems to solve -- and
>> solved them successfully.
>>
>> # Conclusions
>>
>> This article might start a revolution -- or it might just be yet another
>> article complaining about installing software in GNU/Linux.
>>
>> I have a dream. A dream of a world where people distribute applications
>> as bundled directories, and these bundles work in Ubuntu, Fedora, etc --
>> and they _keep on working_ when a new version of the operating system is
>> installed. A world where software installation in GNU/Linux is _easy_
>> and applications can be swapped by simply copying them onto a memory
>> stick.
>>
>> I wonder if I will ever see this in GNU/Linux?.
>>
>> _P.S._
>> _Some will say, "if you like the way OS X does things, use OS X". My
>> answer to that is, "I like the way OS X does things, it works, it solves
>> problems, but let's rather be inspired by it and improve it"_
>> _______________________________________________
>> Fsm_com_nl mailing list
>> Fsm_com_nl at freesoftwaremagazine.com
>> http://centos555208.aspadmin.net/mailman/listinfo/fsm_com_nl
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>> _______________________________________________
>> Leaplist mailing list
>> Leaplist at leap-cf.org
>> http://lists.leap-cf.org/mailman/listinfo/leaplist
>>
>
>
> -- 
> Life without passion is death in disguise
>
>
> -----------------------------------------
> This email was sent using SquirrelMail.
>   "Webmail for nuts!"
> http://squirrelmail.org/
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> Leaplist mailing list
> Leaplist at leap-cf.org
> http://lists.leap-cf.org/mailman/listinfo/leaplist
>

----------------------------
   Derek Konigsberg
   dkonigsberg at logicprobe.org
----------------------------

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.