Re: containers/chroot to allow ABI breakage is the wrong approach
On 10/21/2014 05:12 PM, Thorsten Glaser wrote: > On Tue, 21 Oct 2014, Thomas Goirand wrote: > >> 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. > > Why? I explained extensively why in my post. Re-read it, and let me know which part you didn't understand... :) > OpenBSD’s libc.so major number is 50 or something like that right now, > because they – correctly – increment it on every incompatible change. The correct thing to do is to not do incompatible change. > This is not a problem because, you know, we have Open Source, so we > can always just recompile everything against the new libraries. Wouldn't it be better to "just" upgrade to the new lib? Recompiling is a major pain and a loss of time/resources which could be avoided. Thomas -- 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/544a17ee.5040...@debian.org
Re: containers/chroot to allow ABI breakage is the wrong approach
Gregory Smith dixit: >They say you're a hard nose, skeptical, untrusting, old unix admin and >programmer from the old days and you do not take one ounce of My old days were on DOS¹. I am a relative newcomer to the Unix world, starting about 1999. But I grew up with the “old values”, including their reasons. >bullshit. Not one fucking ounce. You value the BSDs and use them. You >existed in the freesoftware world before linux came around and will Hm, if you can count whatever BASIC and asm stuff I did between 1998 and 1991 – which I did not publish, due to age, and lack of computer network… >still exist there when linux goes away, and before that you existed in >the pure unix realm of the 60s and 70s. Pure realm maybe, but neither earthy nor unix. >Will you be going with the debian fork? I will absolutely not be going with a Debian fork. However, I invite the “progressive” party within Debian to create a derivate, not fork but maybe even a pure blend, in which they can integrate systemd, GNOME, etc. “better”, and only x86/ARM with the accelerated 3D graphics, while continuing to support the “Universal OS” Debian to some amount. Basically a different installer, defaults or configs, if needs be, and possibly different packages, if at all. bye, //mirabilos ① still have real DOS dual boot around… and floppies… -- 15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha 15:48⎜ also warum machen die xorg Jungs eigentlich alles kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den gebauten Turm selber umschmeissen durften? -- ~/.Xmodmap wonders… -- 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/pine.bsm.4.64l.1410232108070.8...@herc.mirbsd.org
Re: containers/chroot to allow ABI breakage is the wrong approach (was: Remember when men were men and wrote their own init scripts? =))
Hi, Thorsten Glaser: > OpenBSD’s libc.so major number is 50 or something like that right now, > because they – correctly – increment it on every incompatible change. > Glibc has versioned symbols instead … > This is not a problem because, you know, we have Open Source, so we > can always just recompile everything against the new libraries. > I'd be ecstatic if the whole world was Open Source, but it is not. It probably never will be. And even if/when I have source, I'd like to continue to use my locally-built programs. Instead of being forced to rebuild each and every one of them, every time I do an OS upgrade. :-/ -- -- Matthias Urlichs -- 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/20141021124249.gc24...@smurf.noris.de
Re: containers/chroot to allow ABI breakage is the wrong approach
Konstantin Khomoutov dixit: >Sometimes we have to run software which is neither Open Source nor Free >on our systems which are (luckily) Open Source and Free. Things like f-prot are shipped statically linked, when in their binary form for OpenBSD. And binary compatibility only goes so far either in GNU/Linux… (luckily, we have VMs now). This is especially true for Debian: try to install binary *.deb from various people, or to build AOSP (Android) on Debian… Multi-Arch also introduced lots of fun… bye, //mirabilos -- 16:47⎜«mika:#grml» .oO(mira ist einfach gut) 23:22⎜«mikap:#grml» mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann gleich mal auf usb-stick installieren -- Michael Prokop über MirOS bsd4grml -- 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/pine.bsm.4.64l.1410211043050.7...@herc.mirbsd.org
Re: containers/chroot to allow ABI breakage is the wrong approach (was: Remember when men were men and wrote their own init scripts? =))
On Tue, 21 Oct 2014 11:12:20 +0200 Thorsten Glaser wrote: > > 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. > > Why? [...] > This is not a problem because, you know, we have Open Source, so we > can always just recompile everything against the new libraries. Sometimes we have to run software which is neither Open Source nor Free on our systems which are (luckily) Open Source and Free. I don't want to sound pompous or something but it's real life which has its constraints, however inconvenient. -- 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/20141021132851.e722bf3486824b9c36959...@domain007.com
Re: containers/chroot to allow ABI breakage is the wrong approach (was: Remember when men were men and wrote their own init scripts? =))
On Tue, 21 Oct 2014, Thomas Goirand wrote: > 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. Why? OpenBSD’s libc.so major number is 50 or something like that right now, because they – correctly – increment it on every incompatible change. This is not a problem because, you know, we have Open Source, so we can always just recompile everything against the new libraries. So I am *honestly* puzzled why you would want to avoid lib major bumps. Thanks, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in "Notes on Programming in C" -- 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/alpine.deb.2.11.141020580.10...@tglase.lan.tarent.de
Re: containers/chroot to allow ABI breakage is the wrong approach (was: Remember when men were men and wrote their own init scripts? =))
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
