3 ms·

A. How do you contribute to the kernel in a way that only benefits the contributing organization? That's quite literally impossible in this kind of project. Eve

A. How do you contribute to the kernel in a way that only benefits the contributing organization? That's quite literally impossible in this kind of project. Even the more niche stuff like virtualization support is used by homelab enthusiasts. It's also not like Linux has 100,000 APIs for every customer under the sun. B. Most of the effort goes into hardware enablement; CPUs, GPUs, power management, etc. Without corporate interests, try running Linux 2.2 from 1999 on a modern PC (which came out just before the $1B IBM investment). See how well it works. Fork modern 2025 Linux, and try running it on a computer that comes out in 2028. See if it even boots. If Intel's only done a minor refresh, it might work; if it's something bigger like the split to P cores and E cores, expect a brick. Even if it does boot, don't be surprised if it crashes, acts unstable, has borked performance, broken sleep/wake, broken audio, broken USB, you name it, it's probably broken. C. A forked Linux would not have the same level of security research behind it. For example, the Linux 4 era was marked by the introduction of fuzzers and the fixing of countless bugs. A C codebase with handwritten Assembly is rather unlikely to ever become bug-free. How well would your forked non-corporate codebase handle Spectre and Meltdown, just an example, with Google's experts contributing the technique for fixing these problems efficiently (Retpoline)? D. Added to the above, this isn't a hypothetical: The FSF didn't like the practice of proprietary firmware blobs being in the kernel; so they made their own commercial-interest-free version of Linux called Trisquel. It still uses commercially written code if it's open source; so even it can't be called completely free of commercial influence. The kicker: It runs on almost nothing, and people were complaining about how it works on nothing 13 years ago. TL;DR: A forked Linux, is a broken Linux, that will never run well on newer hardware, and will quickly become insecure.

rstuart4133 2y ago
> Most of the effort goes into hardware enablement; Which is why Linux is primarily corporate funded. The corporates want to sell their hardware. To sell their hardware they need to get it running on Linux, so they fund that. As hardware support constitutes most of the code contributions, most of the code that goes into Linux was because corporate actors made a decision to pay for it's development - purely in their own interests. That's nice - this symbiosis between FOSS and corporates works well for both sides. But it's a stretch to say Linux would not exist today without it. The most you can say for certain is Linux would not have it's great hardware support without it. The BSD's don't get anything like the amount of corporate funding Linux does. They are doing fine, and notably work on common modern hardware. So could Linux even without corporate funding. In particular, most of the interesting stuff that happens in the kernel, the stuff that determines what the kernel will look like in 10 years time, stuff like adopting Rust, is driven by people scratching itches in the FOSS tradition. Not all of it - pKVM is Google initiative. But eBPF was scratching an itch. Jens Axboe developed io_uring probably as a consequence of wanting storage to run faster at Meta - but it was definitely an itch of his. It's nice that Meta to paid him while he developed it, but saying its creation was "driven by corporate interests at Meta" is a bit of a stretch.

rstuart4133 2y ago

> Most of the effort goes into hardware enablement; Which is why Linux is primarily corporate funded. The corporates want to sell their hardware. To sell their hardware they need to get it running on Linux, so they fund that. As hardware support constitutes most of the code contributions, most of the code that goes into Linux was because corporate actors made a decision to pay for it's development - purely in their own interests. That's nice - this symbiosis between FOSS and corporates works well for both sides. But it's a stretch to say Linux would not exist today without it. The most you can say for certain is Linux would not have it's great hardware support without it. The BSD's don't get anything like the amount of corporate funding Linux does. They are doing fine, and notably work on common modern hardware. So could Linux even without corporate funding. In particular, most of the interesting stuff that happens in the kernel, the stuff that determines what the kernel will look like in 10 years time, stuff like adopting Rust, is driven by people scratching itches in the FOSS tradition. Not all of it - pKVM is Google initiative. But eBPF was scratching an itch. Jens Axboe developed io_uring probably as a consequence of wanting storage to run faster at Meta - but it was definitely an itch of his. It's nice that Meta to paid him while he developed it, but saying its creation was "driven by corporate interests at Meta" is a bit of a stretch.