20 Hacker News comments link this video. Each one links back to its thread.
NavinFApr 2021Strongly recommends
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)
in “Tiny Container Challenge: Building a 6kB Containerized HTTP Server” · View on HN
stirayMay 2020Strongly recommends
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? =/ )
in “How to disable the built-in Windows 10 ads” · View on HN
dottrapSep 2014Strongly recommends
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
in “Why osx sucks and you should use ubuntu instead” · View on HN
gpmFeb 2021Recommends
> 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.
in “The modern packager’s security nightmare” · View on HN
Show 14 more comments
belornFeb 2015Recommends
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.".
in “GCC, LLVM, Copyleft, Companies, and Non-Profits (2014)” · View on HN
mmlbOct 2021Cites it
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
in “Software Freedom Conservancy files GPL lawsuit against Vizio” · View on HN
Wxc2jjJmST9XWWLJun 2021Cites it
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)
in “GCC drops its copyright-assignment requirement” · View on HN
AnIdiotOnTheNetMay 2021Cites it
> 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.
in “Improving Firefox stability on Linux” · View on HN
RaleyFieldNov 2018Cites it
How about unstable apis to anything outside the kernel[1]. Or, more personal, on this laptop I get shorter battery life (I have it plugged in most of the time so it's tolerable), sometimes it doesn't wake up so I have to always shut it down (tolerable) and bluetooth headset doesn't work (I use wired ones, so tolerable again). [1] ▶ this video
in “German federal office publishes Windows 10 telemetry analysis” · View on HN
topspinJun 2018Cites it
> Has anyone ever publicly explained him that while being a sociopathic nerd he still must comply to some basic rules of conduct like we all do[?] Yes. Back in 2014 several DebConf attendees publicly confronted Torvalds, quoting some of the outrageous things he's written to/at people and making him explain himself. It makes for some rather cringy moments and there is no evidence it had any meaningful impact on him. You may watch it all here: ▶ this video
in “Linus Torvalds on aliasing” · View on HN
augustlNov 2017Cites it
I should add that I also want to use the most standardized desktop environment I can find. Which these days seems to be Win10, macOS, Ubuntu, and maybe a KDE based one? My argument is the same as what Linus points out in this rant (5:33): ▶ this video I want life to be easy for app developers, having to target a gazillion different Linux based platforms kind of sucks.
in “Ubuntu 17.10: Return of the Gnome” · View on HN
thibranOct 2017Cites it
Publishing software – especially close source software – for Linux has always been, and still is, a huge pain. Beside all the nightmarish things you have to do to package something. ▶ this video
in “Microsoft gives up on Windows 10 Mobile” · View on HN
ivancaMar 2016Cites it
Except the alternative, developing binaries for Linux is not a viable option as Linus itself explains very well: ▶ this video
in “Tim Sweeney: Microsoft wants to monopolise games development on PC” · View on HN
znfiSep 2015Cites it
Here is Linus discussing GPLv3 and tivoization etc at DebConf 14 in quite some depth ▶ this video (Basicly he doesn't consider tivoization to be that much of an issue, and doesn't consider it to be something he wanted when he selected the GPLv2)
in “D-Link publishes code-signing private keys by mistake” · View on HN
jgrowlFeb 2015Cites it
Seems like Linus agrees with you to an extent. He thinks it is sad to have to statically link libraries and create huge binaries but it is what you currently have to do to ensure things don't break. Be aware of typical Linus swearing: ▶ this video
in “First fully sandboxed Linux desktop app” · View on HN
michaelmcmillanNov 2014Cites it
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] ▶ this video [2] [link] [3] [link]
in “Mean People Fail” · View on HN
soganessSep 2020Critical
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?
in “‘Linusgate’ over 250 Messages Leaked Code of Conduct Linus Torvalds” · View on HN
jraphSep 2019Joke
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
in “Is there a regular expression to detect a valid regular expression?” · View on HN