DebConf 14: QA with Linus Torvalds

It is best practice and I wish it was common practice, but there's a lot of friction in the way and some people will actively work against you. Static linking glibc is painful because the former maintainer has some strong opinions: link Most distros force you to dynamically link every dependency if you want them to package it. So the default build for most projects is dynamic You've stumbled on a holy war between distros and guys like you, me, and Linus Torvalds[1] that want to deploy a binary and just have it work everywhere. 1: ▶ this video (Highly recommend watching Linus's answer ~6 minutes in)

Just listen to this. I bet you will recognize the speaker. ▶ this video It is 100% to the point and nothing has changed in 6 years since (and not only on debian), except that the mess is being solved by docker. Which is crazy. And windows is heading into same direction (when I have seen the manifests the first thing I have said was... omg... .dll.1.4.3) Just additional info, to help you get into my mindset - system level developer for linux AND windows for 25 years. (anyway, I have thrown tomatoes into directions of two largest fanboy camps, guess what will happen? =/ )

And to really drive the problem home, distributing binary packages for Linux is a complete nightmare. Linus Torvalds just laid out a whole bunch of the problems at DebConf14. ▶ this video Go watch it. But some of the highlights: - .deb vs .rpm misses the whole point. The problem is application writers just want to ship an application binary for "Linux", but it is a nightmare. - Except for the kernel which strives for ABI stability, everything else in the Linux distros constantly break binary compatibility, including the most important library, glibc. - Package maintainers are forced to use shared libraries for everything, even packages that are unstable and not well used which means apps will break - You can't install packages under these systems as non-root - He ships binaries for his SCUBA diving app for Windows and OS X. He only ships source for Linux. That's sad. As somebody who has to ship binaries for multiple platforms, including Linux, I agree it is sad, and I often have to do the rough equivalent of static linking. (I dynamically link and ship copies of the libraries.) This also allows my users to install without root access. But whenever I'm asked to look at using a native packager, I made to cry trying to figure out all the idiosyncrasies of each packaging system, and then all the variations between each distro release. (Fedora vs Debian vs Ubuntu, and 12.04 LTS is different than 13.10 and 14.04.) As far as Apple development tools go. Heard of clang and llvm? A lot of L

> your compiler Compilers of languages like C, C++, Rust, Go etc go above and beyond to maintain backwards compatibility. It is extremely likely that you will still be able to compile old code with a modern compiler. > your processor Hardware is common enough that people go out of their way to make backwards compatibility shims. Things like rosetta, qemu, all the various emulators for various old gaming systems, etc. > your hardware Apart from your CPU (see above) your hardware goes through abstraction layers designed to maintain long term backwards compatibility. Things like opengl, vulkan, metal, etc. The abstraction layers are in widespread enough use that as older ones stop being outdated people start implementing them on top of the newer layers. E.g. here is OpenGL on top of Vulkan: link > [Your kernel] Ok, you didn't say this part, but it's the other big unpinned dependency. And it too goes above and beyond to maintain backwards compatibility. In fact Linus has a good rant on nearly this exact topic that I'd recommend watching: ▶ this video > Pinning a dependency only _guarantees you rot the same or even faster_ because now it's less likely that you can use an updated version of the dependency that supports more recent hardware. Dependencies are far more likely to rot because they change in incompatible ways than the underlying hardware does, even before considering emulators. It's hard to take this suggestion seriously at all.

▶ this video What he's talking about is on the video above and it's a very reasonable point. I just released a game with Linux support and most of the bug reports I got were from people running the game on different distributions and random libraries not being the version you would expect it to be. This is not to mention that I got way more bug reports from Linux users than Windows users, despite Linux users making up 2%-3% of the playerbase. His point is absolutely valid and not at all a "serious idiocy".

Linus Torvalds addresses some core issues in his "DebConf 14: QA with Linus Torvalds" talk starting around 5:40 ▶ this video

Because he doesn't like the anti-tivoization clause for his own code. I suggest watching ▶ this video as it gives a up-to-date view which all the necessary qualifiers in one single talk. I especially like the (paraphrasing quite a bit) "GPLv3 is a fine license, GPLv3 is a horrible license, and I like to overstate things if you haven't noticed. For my own code I just want changes back. GPLv2 is a license that does this and nothing else, which is why I use it for my own projects.".

You are right that he can't unilaterally relicense the kernel and that it will likely never happen, but Linus is in fact against the GPLv3, see debconf 14 Q&A: ▶ this video

You're talking about a completely different thing here though than the article is about, and obviously we can only speculate. Linus' opinion always was: "I give you source code, you give me your changes back, we're even."[1] That's his summary of GPLv2 and I think such an attitude is reasonable, and it might have certainly aided the Linux kernel development over time (almost sure of it). He disliked the GPLv3 exactly because of that. Because in his opinion it's (paraphrased) "I give you the source code, and now I dictate to you how you are allowed to use it." (see same link). Whether a BSD/MIT license hurts or helps a project is pure speculation. More permissive licenses might make code reuse more attractive, and be considered "more free" regarding code reuse. As to what code contributions you miss out on? Hard to judge. There definitely are companies building products utilizing FreeBSD / OpenBSD without committing all their changes back (or none to begin with). Pick the right license for your project. You don't care and are happy if someone uses it? Use a permissive license (MIT/ISC). You want to develop the product, improve on it, and want the changes back? Use something like GPLv2. You deeply care about your code running on open devices? Use GPLv3. There's no "one obvious right way" as far as I am concerned. [1] ▶ this video (from there to 56:51 it's about open source licenses)

> It's actually pretty great. Subjective, but needless to say I disagree. I disagree with all of your reasoning too. Inserting a middleman into the software distribution process is needless friction and adds another point of failure. Even Linus has spoken on how much of a pain in the ass it has made it to distribute software: ▶ this video But hey, you guys keep doing what you're doing and ignoring what potential users want. I'm sure the Year of The Linux Desktop is just around the corner. P.S. Yes, I know, it's been your Year of the Linux Desktop since 2001 or whatever. We both know that's moving the goalposts. So is saying "but Android" since it replaced everything above the kernel with a completely new userspace stack and, oh yeah, it doesn't really run on the desktop anyway.

Linus shat on the FSF and GPLv3 at a 2014 Q&A. The word bigot was thrown around by LT when characterizing the FSF. During the Q&A he also carted out the same tired "you have to earn respect" rag that volatile people use. He was invited to take part by the Debian folks. ▶ this video After the event, there were complaints about him. What "leaked" is ~250 private messages from the Debian team members deciding if they should tell LT he is no longer welcome at Debian events. Side A: He was prick, he broke the rules and hoped to skirt responsibility by virtue of his celebrity. We can't give him a pass. Favoritism bad. Side B: We invited him to an fully open Q&A knowing that he would speak his mind. Are we really going censure him for doing what we asked him to do?

My first thought seeing this title: "Why, no. Next!" My second thought: the voice of Linus Torvalds at DebConf 14 saying "Hum… No! Hum… that was quick." [1] Though this is only speaking about a recursively defined regular expression language which is infinite, which strictly handles regular languages, as defined in computer science lessons in university. And then, "Why not just try and see if it breaks the provided regex parser since you have one?", and it's actually one of the answers in the link… awesome. I wonder it is has security implications though (are forged regexes exploiting flawed regex parsers a thing?) [1] ▶ this video