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
