On 10/21/2014 01:34 AM, Martinx - ジェームズ wrote:
I mean, when I read that infamous guy, Poettering, talking about things
like this:
http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
Actually, while the rest of your post isn't helpful (or even an
annoyance), I'm happy that you post such a link in here. It's been a
long time I wanted to express myself about it.
Basically, the idea is that we should allow some kind of
containers/chroot, so that any application is allowed to rely on any
version of any distribution / library that they require.
While I do understand that this solve *some* symptoms of a big issue, it
is my strong opinion that it brings more problems than it solves. I
really hope that my fellow DDs understand the problem and will make sure
that we (and by we, I mean the Unix community at large) don't steer too
much in that direction. Let's enumerate some of them.
- Wrong over-engineered implementation of a simple thing
The author of the lines linked above, with his usual way of doing
things, is over-engineering everything in the implementation. He is
proposing to use BTRFS named volumes, but it's basically the concept of
a chroot that he's explaining. And he's doing so, just as if he was the
first to have the idea, which is kind of fun to read. Fun to read, but
really not fun if that's the kind of joke implementation we'll be forced
into.
- Security update hell
This is the most obvious issue, but I have to write about it. Let's say
we have a new shellshock / heatbleed issue, then instead of a single
operating system, the user is left with a dozen to update... or to
actually *not* update. Because it's too complicated (unless you know how
to update N types of distros, each instantiated with M versions). And
worse: instead of having a single community, it seems that with this
idea, we'd be relying on the APP vendor to update an image. Some of
these images will *not* be updated, that's for sure. Security
maintenance within a single distribution is already very hard, security
with APP-vendor maintained images is simply impossible.
- Duplication of the same things
Do we really need N versions of a shared library? Hell no. That's the
Windows DLL approach, and we of course don't want this to happen.
Basically, we'll run into shared libraries which wont be shared anymore,
which turns out to be extremely stupid. Users will run N versions of the
same shared library, just to run an APP, duplicating HDD space, RAM
usage, and rendering CPU cache useless.
- APP market as a goal
Do we, as a community want to go for something like the Android market
place? I really hope we don't. At least, I'm against doing things with
this type of goal, just to satisfy software merchants. I don't care
about the fact it is difficult to write non-free software that
integrates well in a free software distribution. Yes, integrating with
many distributions is a pain for upstream, but there are other ways to
address this issue.
- Huge download size for no reason
Instead of downloading a package, you'd be downloading also a full
instance of an operating system to run it. Fun! Your $gtk application
will not be a 500KB package anymore, but a huge 500MB. I don't want this...
- Wrong approach to the ABI issue
The issue we have, Linus already expressed it when we had the Q/A
session in Portland. The issue is that library authors are constantly
breaking ABIs. Linus believe that, as distributions, we can push
upstream to stop breaking ABIs, just like the kernel doesn't break the
userland. At first, I thought it was silly, because we, as a
distribution, can only deal with ABI breakages (ask the release team how
painful transitions are...). Well, on a 2nd thought, I think he's right.
So, dear fellow DDs, I'm asking you: each time you see that an upstream
author is breaking an ABI on a package you maintain, write an email to
him/her, and explain how much this is bad and shouldn't happen. If the
Unix community starts to realize how much we're loosing by breaking
ABIs, I'm sure the situation will improve.
I'm sure there's more issues about this poisonous idea that I'm not
listing. I just wrote this from the top of my head.
Let's hope that this isn't the path we're taking, and that
containers/chroot wont be the way upstream authors will ship their
software. Let's hope that distributions like Debian will continue to do
things right, and that upstream authors will stop doing so many ABI/API
breakage giving so much work to the release team.
Cheers,
Thomas Goirand (zigo)
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5446178a.4020...@debian.org
