DebConf 14: QA with Linus Torvalds

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. [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

Just listen to this. I bet you will recognize the speaker. [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? =/ )

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: [VIDEO] (Highly recommend watching Linus's answer ~6 minutes in)

Because he doesn't like the anti-tivoization clause for his own code. I suggest watching [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.".

Linus Torvalds addresses some core issues in his "DebConf 14: QA with Linus Torvalds" talk starting around 5:40 [VIDEO]

[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".

> 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: [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.

I always find these essays interesting, not necessarily because I agree with them, but rather because Paul has a very special way of looking at things. [...] being mean makes you stupid. Linus Torvalds is definitely not stupid, but I would not hesitate to call him mean [1]. But you can't deny that he's successful and certainly he's not stupid [2]. Business and open source seem to both center around the same things: creating something people want [3] and surrounding yourself with other smart people. I would imagine that the latter is hard if you're mean - but not impossible. Take Linus or Steve Jobs, none of whom are very nice. [1] [VIDEO] [2] [LINK] [3] [LINK]