On Wed, 2015-12-30 at 20:48 +0000, Sam Thursfield wrote:
If I understand correctly, part of the reason for starting work on
Baserock was to research fixing various problems in existing desktop
The Baserock project is 4 years old now, and I thought maybe it's
to look at that aim again.
I had a go at listing everything that is wrong with the current set
free software operating systems that I could theoretically run as a
desktop OS. Please let me know if you disagree with any of it or if
can think of other things to add.
First I should confess that I find Baserock to be much more interesting
for embedded than for the Desktop, although that should be orthogonal
to the analysis of what problems exist in modern GNU/Linux desktop
I have a few comments, one is that I think that when considering the
perceived problems with GNU/Linux desktop distributions, we should be
taking into consideration other (non-Linux) desktop distributions for
comparison, and then seeing how existing GNU/Linux distributions
measure up to those.
o Microsoft Windows
- Historically great ABI compatibility, one can usually run a
binary for an old version of windows on a new windows system
- Relatively reproducible, two systems with the same version and
service pack levels applied are fairly similar.
- Historically unstable, partly the downside of trying to support
the combinatorial explosion of every possible hardware
configuration of a PC or laptop
- Relatively good ABI compatibility, frameworks and bundles allow
applications to carry ABI incompatible third party baggage with
them, effectively allowing the same application bundle to run on
a variety of OSX versions without issue.
- Great reproducibility for a desktop OS, two installations of the
same version and same patch level on the same Apple product
should arguably behave exactly the same.
- Great system stability, the benefit of limiting your target
platform to only a few well known hardware configurations,
and paying attention to only those.
How do current GNU/Linux distributions measure up to these ?
Some first impressions:
o Most (if not all) GNU/Linux distributions are making things more
difficult for themselves by assuming the responsibility for
packaging and distributing everything which is going to possibly
run on a user's desktop. I.e. there is no line drawn in the sand
where the OS stops and applications begin, everything is downloaded
and installed via the same package management system.
o Most (if not all) GNU/Linux desktop solutions take the windows
route and attempt to support every possible hardware configuration
known to man kind. Worse, we do this without any dedicated
engineering staff or QA department and expect that when users
encounter problems; solutions for those problems will eventually
Things are getting better: in the last couple of years my
installations have come with working networking interfaces out of
the box :)
o Not a great ABI compatibility story, most distributions require a
recompile of any application in order to run on the next major
release of the same OS/distribution.
I think this line of questioning is required if we're going to start
improving Linux on the Desktop in meaningful ways.
That aside, I think we also have to take a step back and recognize that
GNU/Linux desktop distributions are largely community maintained. Which
means that what might be perceived as a problem may in fact be an
advantage in this context.
Taking atomic upgrades as an example, atomic system upgrades are
important from a product standpoint. You need to have perfect
reproducibility of all systems in the field in order to reproduce and
fix issues in a sure and meaningful way. But can this strategy really
apply to a community run distribution ?
If you cannot define what exactly is the core system you are
distributing, and you are distributing everything from the linux
kernel, 2 alternative init systems, 2 windowing systems, 3 or more
alternative desktop environments and also every application that
someone may choose to have installed; you will already be hard pressed
to find any 2 installations of the same distribution which are alike.
Maybe in this case it makes more sense to just distribute verified bug
fixes as fast as possible and not pay too much attention to how similar
one installation is to another ?
Just some food for thought :)