[Digikam-users] Generic Linux question

Jean-Fran├žois Rabasse jean-francois.rabasse at wanadoo.fr
Tue Aug 30 00:22:52 BST 2011

On Mon, 29 Aug 2011, Vlado Plaga wrote:

> Date: Mon, 29 Aug 2011 22:03:16 +0200
> From: Vlado Plaga <rechner at vlado-do.de>
> Reply-To: digiKam - Home Manage your photographs as a professional with the
>     power of open source <digikam-users at kde.org>
> To: digikam-users at kde.org
> Subject: Re: [Digikam-users] Generic Linux question
> On Sat, 27 Aug 2011 23:34:24 -0400
> Paul Verizzo <paulv at paulv.net> wrote:
>> I have spent the last several weeks trying out about ten Linux
>> distros in Virtual Box.
> [...]
>> Closing, the question is about how Linux apps are updated......
> Others have already supplied relatively detailes answers. I just want
> to add: the way software is distributed in Linux simply is quite
> different to the Windows (or Mac OS) way. You may notice that many
> complex applications only require a fraction of the disk space
> comparable applications use on these commercial systems. My e-mail
> program (Claws Mail) for example has an "uncompressed size" of less
> than 4 MBytes, according to the package manager. On Mac OS 10.5 "Mail"
> uses 289 MBytes! One reason free software applications can be so small
> is because they share a lot of "libraries" - but that of course makes
> it difficult to update, because quite often newer versions of
> applications require newer versions of the libraries which are no
> longer compatible to the older versions... thus braking other
> applications that depend on the same library. Of course package
> management software is there to make sure such brakeage does not happen,
> but it's a complex issue nevertheless.

I fully agree.
Shared libraries are an efficient way to optimise system resources and
providing only one copy of code for several applications.
But the price to pay is that all the environment must be consistent.
When someone starts to install several versions of the same library
because several applications require different versions, the interest
of shareable code begins to fell down.
When recompiling an application requires to upgrade tens of librairies
and tens of other applications, it's probably not worth the game, and
in some cases can turn the system into an unstable environment.
And that's why Linux distributions are late to offer the freshly new
versions of hundreds of applications, just because packagers have to
ensure consistency.

Using Virtual boxes may be a turnaround, in some cases. But where is,
then, the interest of using shareable libraries if your computer RAM
hosts several versions of a library, one per running application,
one per box.
The more simple solution would be to compile and link -static,
the binary program will be bigger, but won't interfere anymore with
the O.S. evolutionsi and other applications.

> Also free software more often than commercial software follows a
> "release often, release early" philosophy. This of course means that
> released software is not that stable and can have more bugs. The severe
> bugs in DigiKam 2.0.0 could be one reason it is not yet included in
> Debian "unstable" (a kind of rolling release) which otherwise often is
> quite fast in picking up new versions:

True !
The "release often" philosophy turns end users into beta testers and
make installed systems less and less stable.
It's not anecdotic to see that the two major commercial Linux packagers,
Novell/SuSE and Red-Hat, offers two products lines :
A standard users Linux, targeted at home computers and office desktops,
and a so called "enterprise" distribution (SLES from Novell or RHEL
from Red-Hat). Enterprise distributions are really stable, but you have
to buy them. And they are always "late", compared to personal distros.
With stable enterprise Linux, you won't go on the Internet because you
don't have the latest media player plugin, or the proper Java vm plugin,

There's no ideal solution. Either become an "upgrade addict" and
"recompiler geek", or accept your computer as it is and accept the idea
to use some "old" programs. (Old may be six months :-)
Most "old" programs that were very useful six months ago or one year
ago, may still be useful today.

A good rule could be "When version <N> of your prefered program is
released, it's time for you to install stable version <N-1>".


More information about the Digikam-users mailing list