[PLUG] Regression Testing and library versions

Tim tim-pdxlug at sentinelchicken.org
Mon Mar 28 17:39:44 UTC 2011


> That is certainly an issue.  On the other hand:
> 
> free:
>              total       used       free     shared    buffers     cached
> Mem:       3114664     794856    2319808          0      57404     404636
> -/+ buffers/cache:     332816    2781848
> Swap:      4032304          0    4032304
> 
> I've got the RAM (*).  What I don't have time for is dependency
> hell.  Which at best costs me hours at inopportune times, and
> at worst means deleting applications that I've invested data in.
> All my apps should not be so tightly bound together.  That makes
> my system too fragile.


Keith,

Certainly dependency management can be difficult, but consider the
fact that every distribution has to support the libraries they
release.  Each time a vulnerability comes out in libfoo, they'd have
to back patch it in every version of the library.  If they try to
support some old version of libfoo that even the upstream developers
don't support anymore, then that can lead to huge headaches for the
distribution's maintainers.

Instead, users are free to install their own libraries and manage
their own legacy dependencies if they wish.  For instance, with
Debian-based systems (and likely others, which I can't speak to) it is
also relatively easy to build your own backports from the Debian
source packages and host your own apt server that lets you manage
those dependencies yourself in the way you want, overriding the builds
of specified packages in the mainline distribution.

<rant>
And finally on the topic of memory consumption, even though this is a
small piece of the issue, I regularly run up against memory limits on
my 2GB desktop.  Yes, I am planning on buying more RAM, but it seems 
that every application likes to assume they can use as much RAM as 
they want because it is so cheap now.  I run *lots* of apps at once 
and regularly have to fight with those apps that are memory hogs 
simply because the developers are too lazy to think through what 
really needs to be in memory.

Note that using more memory than I have available is bad enough, but
it also leads to computation bottlenecks in modern systems.  The speed
of memory continues to diverge from the speed of CPUs.  The more
useless junk you store in memory, the more you blow your CPU's cache
on pointless garbage and the more time you spend loading and
accessing stuff from RAM.  It still makes sense to design software
around not using too much memory, particularly in an age where
everything is going mobile.
</rant>

Now, with all that I've said in favor of the current model, I do feel
your pain when it comes to using particular groups of software
packages.  Many of the libraries supporting Linux GUIs are incredibly
fragmented with many ugly interdependencies.  I am not a GUI
developer, but I suspect many Gnome and KDE libraries implement
duplicate functionality throughout the code, even within their own
projects, because they don't organize the code well enough to provide
good code reuse.  

Consider the X11 clip board vs the Gnome/GTK/etc clipboards.  I don't
know what all standards and APIs exist for this, but I do know it is
an utter pain in the ass to copy and paste text between different
applications on my system.  My preferred terminal program, urxvt,
supports traditional X copy/paste (select the text to copy, middle
click to paste) which I really like.  Most other applications on my
system also support this style of copy/paste.  However, recently i've
noticed Java GUIs do not support this (anymore?).  I can't copy from
my terminal and paste into Java apps, and since uxrvt doesn't support
Windows-style 'CTRL-V' for paste (as it is a terminal that interprets
this other ways), I can't paste from Java to urxvt.  Apps like
Firefox support both methods of copy paste and OpenOffice.org seems to
change its policies on what kinds of copy/paste it supports with every
minor release (sometimes pasting web page text as simple text, other
times pasting it as formatted text, and this is different between
CTRL-C copies vs X11 copies).  It is just brain-numbing and foolish
that this stuff isn't better standardized.

Surely this clipboard complexity comes along with weird library
dependencies, according to what apps support what methods.  Overall
this is just a sign of bad design though, rather than a fault of the 
distribution's maintainers do keep supporting multiple releases of the
bad designs.

Regards,
tim




More information about the PLUG mailing list