Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Ubuntu alternatives and upgrading distributions



On Sat, Dec 10, 2011 at 02:46:06PM -0500, Tom Metro wrote:
> Elsewhere Alex Handy in an SDTimes blog posting looks at the problem of
> Linux OS upgrades from a server/application developer-perspective:
> http://www.sdtimes.com/blog/post/2011/09/16/Youre-doin-it-wrong.aspx
> 
>   ...there really isn't a 10-year Linux. ...when it comes to long term
>   support...you're looking at 2 to 5 years of support, max.

For what it's worth, 5 years seems about right to me.  There are
continual advances in computer science, even in what's available in
the commodity personal computer market, that IMO necessitate that the
OS keep up.  10 years on the same OS has always seemed too long.  At
work Windows installs are still XP, and it seems pretty tired.

> While this is talking about web apps running on servers, you should be
> able to extrapolate the same ideas to the desktop...yet you can't.
> Surprisingly the core of the OS - the kernel - is actually relatively
> easy to upgrade without upgrading the full OS. Instead the linchpin for
> any desktop OS version seems to be the libc version and secondly the GUI
> environment version.

I mostly agree, except as per my comments above.  Do we really need
the latest features of the ls command?  I still pretty much use the
same ones I leared 20 years ago.  I'd like to see some sort of a
hybrid of the debian stable model and the fedora core model, with the
base OS being mostly stable, and the user apps being more flexible.  I
view what we now call "the OS" as a 4-tiered operating environment,
each with differing requirements.  

The kernel should require the fewest updates, mainly for security and
bug fixes.  The second tier includes the core system libraries (i.e.
libc), and core system utilities.  These should change on a similar
schedule to the kernel, but as these really are end-user tools, I
think updates could infrequently include relatively small amounts of
*new* functionality, so long as no existing functionality is changed,
thereby introducing incompatibilities.  In general, both of these
tiers should change substantially only when significant technological
advances in either hardware or operating system design warrant change.

The third tier includes things like the desktop environment.  Gnome
and KDE (and others!) ship huge amounts of libraries and user tools
which provide a consistent interface for the user.  I consider this to be
not at all part of the operating system, and it should be possible,
even easy, to switch this tier out, provided that the thing being
switched in does not depend on newer versions of the underlying system
libraries.  Ideally (from the user's perspective), some efforts should
be made to avoid such dependencies, though obviously its own libs must
be free to change as necessary.  In general, users would prefer
that updates be made available, but should not be *required* to
upgrade this massive layer of their operating envrionment until they
are ready.

The last tier includes things that *should be* obviously user apps.  I
emphasize *should be* because the browser, while clearly falling into
that category in my mind, has itself become a platform for providing
applications to users, somewhat blurring the line.  Regardless, this is
the area where you most want to see frequent updates.  Users should
have access to advances in end-user technologies as soon as possible.
Ideally, application developers should target versions of libraries
that are currently deployed, or imminently will be deployed only when
the former is impractical.

Why does this not happen?  In my mind, one reason is because all of
this is developed by many disparate groups with different, sometimes
even competing goals.  Another is that open-source developers
generally work on what's cool or fun, not necessarily what's needed.  
I believe this is also why the Linux desktop is where it is.  It's
clear to me that the desktop has improved in the last 15 years or so,
but frankly the improvements since then have only been marginal, and
on the whole I believe I was more satisfied with my simple FVWM
configuration.  The one thing I give the Gnome people is that it is
much less work for me to get an environment that satisfies my basic
need, and this is the only reason I have not gone back to FVWM.  

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org