[blfs-support] Knowing when to ditch an old (desktop) system

Ken Moffat zarniwhoop at ntlworld.com
Mon Dec 29 13:40:51 PST 2014


 This mail is particularly aimed at people who are using old
versions of LFS/BLFS as desktop systems.

 Some people here may recall that I like to keep old desktop systems
"usable" (definition in a moment), both so that I can look at them
to see how things have changed (or sometimes, to rule out a change
when debugging a build problem), and to make them available for
rescueing my current system if^Wwhen I trash that.

 My definition of "usable" : recent kernel (something from a series
which is still maintained), current openssl, current firefox, all
vulnerabilities of which I am aware either addressed, or labelled as
"only a DOS, unlikely to harm me" - that latter applies e.g. to the
most recent fix that debian has made to sox, which can apparently
crash on a specially crafted wav file.

 When I started using BLFS, there was not very much in it for
desktop systems and it was not my sole desktop.  When I committed to
using it as my main systems, I noted that some distros made releases
with varieties of long-term support, and that seemed to me to be a
reasonable thing to do : 3 years sounded like a sensible time.

 What I did not appreciate was how much effort is required, and I now
metaphorically take my hat off to people who support old systems.   I
also did not realise quite how much distros sometimes have to upgrade
when avoiding vulnerabilities.

 A few months ago, I stopped maintaining my recent svn builds from
before the last release of the book, they were not providing enough
benefit.  But I was still trying to maintain my 'release' LFS-7.0+
systems.  With firefox, there were some interesting wrinkles (one of
them needed various workarounds on x86_64 for its particular version
of gcc), and eventually I had to give up 7.0).  But I still had hopes
of keeping the systems usable for two years plus.

 So what has prompted me to write this ?  The latest xorg-server
release [ fixes vulnerabilities, some of which are in all previous
versions of X11 ].  Of course, it needs current headers (and
presumably current libraries), so for me it is easiest just to
rebuild most of Xorg - obviously, fonts do not need to be updated.
I'm now nearly done (got two more systems on this slow machine to
do), and I've had to drop both my LFS-7.1 and LFS-7.2 systems.  The
problem was llvm : for me, there is no benefit in trying to either
build current Mesa with an older llvm, or in trying to use a
slightly older Mesa, but other people might wish to try that if
desperate.

 On my 7.2 system, I got repeated ICEs (internal compiler errors)
while trying to build current llvm.  That is on my AMD phenom, which
has had similar problems from time to time, but this time dropping
the caches and using a lower value of '-j' for 'make' did not help.
So, I tried leaving my old Mesa in place, but it was too old for
current xorg-server.

 On my 7.1 system, current llvm refuses to configure, gcc is too
old.  There is a switch to override that, but using it seems like a
silly idea.

 So, my oldest maintained ystem is now LFS/BLFS-7.3.  On the bright
side, that means a bit less to do next time there are
vulnerabilities.  Also, I can drop my workarounds in the firefox
scripts for missing cairo-tee, old gstreamer, and fixing things up
where jpeg-turbo had replaced jpegsrc (I saw no benefit in
rebuilding everything which might have been using jpeg, so I just
had to fix up a library symlink.  The down side, for me, is that my
desktops will probably now only last for 12 to 18 months - I do not
enjoy "planned obsolescence" in any context.

 Summary - it is probably easiest to build a new system rather than
try to keep a desktop running safely for years.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.


More information about the blfs-support mailing list