Adnan Hodzic
7 HN recommenders · recommended in 19 months, 2014–2021
1:11:44 · 737K views · Aug 31, 2014
A 72-minute Q&A with Linus Torvalds at DebConf 14. Topics include the pain of distributing Linux binaries, distro fragmentation, kernel backwards compatibility, GPLv2 versus GPLv3 and conduct.
HN returns to it as Linus's own explanation of why shipping software on Linux is hard and why he dislikes GPLv3.
20 comments from Hacker News
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
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? =/ )
> 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".