
Revisiting How We Put Together Linux Systems - kiriakasis
http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
======
Arizhel
I think a lot of things he listed in how things currently are (under "Upstream
Projects") are either wrong or overblown.

For instance, the claim that the Linux packaging scheme doesn't work for
proprietary, closed-source software. That's just plain wrong. No, proprietary
software makers can't rely on distribution maintainers to package their stuff,
however there is nothing preventing them from packaging it themselves, and
making it available in a 3rd-party repository. Both deb/apt and rpm/yum have
had this facility for ages, and it's how a lot of Linux users get either
software not supported by the distro (like media stuff that Fedora refuses to
include), or software that the distro drags its feet on updating. Proprietary
vendors can easily use the same system to make their software available to
users, and to allow the software to be easily kept up-to-date using the
existing system instead of running a separate "update checker" constantly in
the background like is common on Windows systems. The main problem is that
there's more than one Linux distro out there, and they're not compatible with
each other. But as Google does already with Google Earth and Chrome, for
instance, it's not that hard to just target RH/Fedora and Debian/Ubuntu/Mint.

Another important point is libraries. They complain about the library
dependencies all being different on different distros. But there's nothing
stopping proprietary vendors from statically-linking everything, which is how
they usually do it anyway, both on Linux and on Windows. Sure, it bloats up
the binary, but it avoids a lot of library version and dependency problems,
and with modern HD and RAM sizes, it's not that much of an issue.

It seems to me that they're proposing an enormously complicated and bloated
system here in an effort to increase usage of desktop Linux, but this isn't
going to help.

~~~
oconnor663
Running 3rd party packaging repos does work, and we do it at Keybase, but it's
surprisingly annoying. Distro upgrades disable your repo by default, and your
packages need to install a cronjob to detect when it happens and fix it. And
because that scenario is difficult to test, you inevitably get bugs like this
one:
[https://bugs.chromium.org/p/chromium/issues/detail?id=660145](https://bugs.chromium.org/p/chromium/issues/detail?id=660145)

So it works, but I really wish we didn't have to maintain it.

~~~
Arizhel
This definitely sounds like a bug to me. Assuming your company is maintaining
3rd-party repos for both the older and newer versions of the distro, doing a
distro upgrade should, logically, switch to your repo for the newer OS version
automatically, so it's completely seamless to the user. If the distro isn't
doing that, that seems like an oversight.

------
rdtsc
> The scheme we propose is built around the variety of concepts of btrfs and
> Linux file system name-spacing

How many here use Btrfs in production. Facebook does I think. Who else?

Tying something to the filesystem seems a good way to optimize and get a lot
of benefit without too much work. But only if that file system is already
prevalent.

But I am a bit worried about Btrfs. Is there even a consensus on Btrfs being
"the future". There was at some point I think. I've seen
[https://bcache.evilpiepirate.org/Bcachefs/](https://bcache.evilpiepirate.org/Bcachefs/)
touted as the "future" of FS on Linux.

EDIT: Oh 2014. Well it's already 2017 so the question is even more relevant
regarding where do we see Btrfs heading?

~~~
johnny22
Don't the opensuse folks still ship it by default?

~~~
OD_
The suse folks adopting btrfs says more about suse than it says about btrfs. I
still remember in the past how I got tricked into believing ReiserFS (3, not
the 4 that never made it into the kernel) was a good filesystem despite the
broken fsck, the lack of defragmenting tools and many other issues listed
there :
[https://en.wikipedia.org/wiki/ReiserFS#Criticism](https://en.wikipedia.org/wiki/ReiserFS#Criticism)
It was also the only time I've had a FS really eat my data after forced
shutdowns (cutting off power). They kept pushing ReiserFS as the default until
2006, 5 years after the release of ext3 which added journaling to the ext
family of filesystems. Ext3 was a much better filesystem all around. Suse only
switched to ext3 because of the controversy with ReiserFS's author and the
uncertain future of Reiser4, not because they admitted that ReiserFS was bad.

I will not make the mistake of putting any worth to suse's words again. Doing
it again with btrfs shows they really have a knack for going edgy with
filesystems while absolutely no other linux distribution is willing to
recommend btrfs.

I trust the Red Hat guys to show more care and this is what they had to say
only a year ago about btrfs:

[https://www.reddit.com/r/linux/comments/37l2mf/i_am_matthew_...](https://www.reddit.com/r/linux/comments/37l2mf/i_am_matthew_miller_fedora_project_leader_ask_me/crntc87/)

"The btrfs developers keep telling us that it's not ready, so we're following
that. (From one of our storage exports: "Btrfs will be ready in two years. The
problem is, that's also going to be true next year, and in two years....") We
try to be first where we can, but not at the cost of data loss for users.

\-- Matthew Miller, Fedora Project Lead"

Doesn't look good to me.

As long as RH or Debian do not start recommending btrfs one cannot give it
consideration in good conscience.

~~~
cmurf
One way to look at this is in what technologies each company has spent
resources. Suse has more Btrfs developers than I can count on one hand. Red
Hat has zero these days. Red Hat might have more LVM and XFS developers than I
can count on one hand. So it stands to reason each company's output will be
biased, they're going to support (development, QA, and tech support) the
things they're spending resources on.

Considering a big chunk, possibly the single largest chunk, of upstream is
Suse, and they use it by default for several years on both the opensuse and
enterprise offerings, it doesn't really make sense at all that 'btrfs
developers say it's not ready'. This just doesn't square. What's going on in
my opinion is, neither Red Hat nor Fedora have the resources, nor are they
willing to add resources, to triage Btrfs related bugs and therefore Fedora
isn't ready for Btrfs, not the other way around.

Even Suse goes very light on what is supported with Btrfs multiple device
stuff, by the way. Single device volumes, I've reported bunch of minor bugs,
no data loss ever. Multiple device stuff is difficult to qualify: if you're
familiar with the warts you're at a net advantage over mdadm and LVM RAID. If
you're not and run into trouble, there are traps and Btrfs's claims of
focusing on fault tolerance and ease of use can betray the user.

~~~
rdtsc
> it doesn't really make sense at all that 'btrfs developers say it's not
> ready'. This just doesn't square.

Just looked at this page:
[https://btrfs.wiki.kernel.org/index.php/Status](https://btrfs.wiki.kernel.org/index.php/Status)
and I can see how they would interpret that as "not ready". There a good
number of "mostly OK" ones, one is unstable. With comments like "write hole
still exists, parity not checksummed", "auto-repair and compression may crash
", and others.

It might be good enough for some but I can see many customers of Redhat would
not want to trust their crown jewels to anything that stays "mostly OK".

~~~
newman314
"mostly OK" and storage should not ever mix.

That's like the ¯\\_(ツ)_/¯ of storing things. Scary.

~~~
rdtsc
Exactly! You phrased it better than me. Storage of customers' data and "mostly
ok" should be very far from each other.

------
random28345
You know, I think it would be a shorter list if the systemd guys were to
enumerate the things they _didn 't_ want to control on a Linux system.

------
AdieuToLogic
From TFA:

    
    
      The systemd cabal (Kay Sievers, Harald Hoyer,
      Daniel Mack, Tom Gundersen, David Herrmann,
      and yours truly) recently met ...
    

If this isn't an insight into the mindset of a person, nothing is.

~~~
SFJulie
It made me think of the fortune:

    
    
         Wouldn't you be paranoid if every one was against you?
    

Except this time, it is much more

    
    
         Wouldn't you believe systemd is Cabal when the authors say so?

~~~
icebraining
Should we be judging Elon Musk as a mafioso[1] too? It's called self-
deprecating humor.

[1]
[https://en.wikipedia.org/wiki/PayPal_Mafia](https://en.wikipedia.org/wiki/PayPal_Mafia)

------
webaholic
Not the first time that a systemd talk proposal by Poettering got rejected
from LPC. I wonder why his proposals keep getting rejected when they are so
tied to the plumbing layer?

------
no_protocol
(2014)

~~~
LeoPanthera
Thank you - I didn't realize this was so old. So knowing that - what happened
to this idea? I've never heard of it, so I'm assuming it didn't catch on.

~~~
wmf
I don't think much development was done on this specific plan but some of the
same ideas (minus the btrfs dependency) can be found in OSTree and Flatpak.

~~~
vomitcuddle
I feel that Nix solves a lot of the same problems in a better way. The ideas
implemented in that project have a lot of potential and I wish that the
community focused more on user experience for new users. Since I've started
using Nix, I had so many cool ideas about what it could be used for.

It's a shame that it has such a steep learning curve.

~~~
johnny22
I'm interested in nix too, but lots of folks still wanna keep their .deb and
..rpm based systems just the way they are, but enhance them.

Lots of folks are against a fundamental rethink. It'll have to be introduced a
piece at a time (like with snaps and flatpak).

Hopefully we'll end up with something like nix in the end.

------
znpy
I have mixed feelings about posts like this.

On one hand I am excited by all these amazing things GNU/Linux will be able to
do.

On the other hand, I often miss those simpler times in which you could install
Slackware, boot it and now pretty much exactly what was running, where, how
and why.

I'm not telling I want to go back though... Nowadays I can buy a not-so-old
laptop, burn an Xubuntu usb stick and pretty much assume everything is going
to work. I guess we will have to accept a tradeoff like this.

------
jwatte
Why a new partition type and reliance on btrfs? I've had real problems with
btrfs fairly recently. Can't all this be achieved with containers and file
system overlays already?

------
nwmcsween
1\. Fix FHS:

* abi/$triplet/{bin,sub,lib,int} __Respectively binaries, private binaries, libraries, interfaces (headers)

2\. Create a constraint based language to express package dependencies and
make the deps fine grain (as in separate runtime from buildtime, etc).

3\. Either make union mounts a first class citizen or restrict what an
application can see via containers and part-out a complete system via
containers instead of creating a complete system piecemeal.

~~~
majewsky
Isn't 2. solved already? One of the main reasons for packages is fine-grained
package dependencies.

~~~
nwmcsween
No, you cannot say for example when resolving $pkg try to satisfy with
smallest size or with least cve's, etc.

------
throw7
btrfs is a non-starter. i stopped reading there.

~~~
znpy
> btrfs is a non-starter. i stopped reading there.

Pottering is one of those "works for me" guys.

