Hi Sam
On 2015-12-30 20:48, 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
Linux distributions.
IIRC, originally the aim was to address embedded development issues,
not desktop, but lots has happened in the interim.
The Baserock project is 4 years old now, and I thought maybe
it's
time to look at that aim again.
By all means :)
I had a go at listing everything that is wrong with the current set
of 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
you can think of other things to add.
I think this may be worth reading...
http://linuxfonts.narod.ru/why.linux.is.not.ready.for.the.desktop.current...
I can't comment on what follows, since the only Linux os I have
in-depth experience with is Baserock. I'd be interested in understanding
the landscape better, though...
Here's the list.
Arch Linux:
- infinite number of possible variants that cannot all be tested
- upgrades are not atomic
- cannot rollback after upgrade
Baserock reference systems:
- lack of packages
- lack of easy runtime configurability
- lack of momentum
- lack of good documentation
- no serious handling of security updates
- security fix in a single component may require rebuilding 1000s
of other components
Debian/Ubuntu:
- very complex, lots of moving parts, many of which overlap
- sources spread across many repos of different types
-> dgit mitigates this problem: it makes all Debian source
packages
available through consistant Git interface
- infinite number of possible variants that cannot all be tested
- upgrades are not atomic
- cannot rollback after upgrade
- packages lag behind upstream versions at times
- packages sometimes have a big delta compared to upstream
Fedora:
- very complex, lots of moving parts, many of which overlap
- infinite number of possible variants that cannot all be tested
-> rpm-ostree project will help with this: you can create a
manifest
that is a specific set of tested packages, and provide the
resulting rootfs as a single OSTree commit. Users can then
layer
changes on top of the well-tested base image, and those
changes
could be reapplied on each upgrade of the base OS.
- upgrades are not atomic
-> rpm-ostree project will help with this: a rootfs managed with
`ostree` can be upgraded atomically
- cannot rollback after upgrade
-> rpm-ostree project will help with this: a rootfs managed with
`ostree`can be rolled back to an old version
Gentoo:
- no way to share prebuilt artifacts
- infinite number of possible configurations that cannot all be
tested
- upgrades are not atomic
- cannot rollback after upgrade
GNU Guix Software Distribution:
- lack of packages
- nonstandard filesystem layout makes packaging some software very
difficult
- security fix in a single component may require rebuilding 1000s
of other components
-> experimental 'grafts' feature solves this:
https://www.gnu.org/software/guix/manual/html_node/Security-Updates.html
- no serious handling of security updates
NixOS:
- lack of packages
- nonstandard filesystem layout makes packaging some software very
difficult
- security fix in a single component may require rebuilding 1000s
of other components
- I'm not sure how quickly NixOS handle security updates currently
I'm doing a talk in the distros devroom in FOSDEM 2016 which will
relate to all this a bit...
I'm looking forward to it :)
Happy Christmas & New Year
Sam