Western Sanctions Regime Reaches the Linux Kernel
Western Sanctions Regime Reaches the Linux Kernel
Perhaps one of the more surprising changes in the 6.12-rc4 development kernel was the removal of several entries from the kernel's MAINTAINERS file. The patch performing the removal was sent (by Greg Kroah-Hartman) only to the patches@lists.linux.dev mailing list; the change was included in a char-misc drivers pull request with no particular mention.
The explanation for the removal is simply ""various compliance requirements"". Given that the developers involved all appear to be of Russian origin, it is not too hard to imagine what sort of compliance is involved here. There has, however, been no public posting of the policy that required the removal of these entries.
An early comment likely pins down the prevailing institutional pressures leading to this decision
What's the deal with an international project adhering to what is obviously a decision of the US government?
Hint: The Linux Foundation (which notably employs Greg KH and Torvalds, and provides a lot of the legal and other infrastructure for this "international project") is based in the US, and therefore has to follow US laws.
This is pretty fucked up. Like, we might see the kernel forked in the coming months/years.
See also: Phoronix: Linus Torvalds Comments On The Russian Linux Maintainers Being Delisted
You're viewing a single thread.
The kernel has already been forked. The Linux-libre project maintains a completely-blob free kernel and people gave them shit over it. Why develop more kernels? why not centralize development? Now we have a clear example of why not to do that.
This seems to be an attempt to stifle Russian hardware development from occurring in upstream. This means nothing to the actual downstream developers who will have their own kernel tree for their users in Russia.
Love to see all the "POLITICS IN MY LINUX???" losers start flame wars over being proven wrong.
Inb4 Chinese devs get removed for "compliance", maybe they'll just go mask off next time and say the real reason.
Honestly nobody should ever really be shaming for forking. It is the basis of all open software and all successful software development in history. Linux itself is obviously just a fork of Minix with GNU. And it is the traditional means of open-source and forking with which communities can and should quickly move away from bullshit like this to prevent corporate/government monopolization of it.
Agreed on not shaming forking, but creating a serious fork for anything substantial takes a fuckton of effort and many times you wind up with multiple mutually-incompatible source trees. In libre, community-run software, it's almost always advantageous to settle your differences and centralize efforts than to fork and split the efforts.
Most forks die because its hard to get people to jump ship. Think about how much lemmitors cry about Lemmy, the devs, and lemmy.ml, yet they cannot muster the effort to keep kbin alive or get sublinks off the ground. OG Hexbear was eventually rebased back to upstream too.
When forking, there are a few paths, all having some serious disadvantage:
-
Soft fork and remain at the mercy of the decisions of the project you forked from unless your fork becomes the de facto default. This is usually only really beneficial if you want to rectify disagreements on a handful of small features. (e.g. Ungoogled-Chromium / Brave vs. Chromium, various Linux kernel forks)
-
Hard fork and lose compatibility of upstream patches, making keeping feature parity difficult. This is only really beneficial if your fork gets a critical mass of users/devs and can outpace upstream at features users want. (e.g. Forgejo vs. Gitea, Lemmy vs. OG Hexbear)
-
Rewrite from the ground up, building the same or a similar API but upon a better architecture. This is the most effort, but keeps compatibility with the ecosystem, and potentially has a massive payoff once fully implemented (e.g. like Tvix vs. Nix, OpenHarmony vs. Android)
-
Write an alternative from scratch, focusing on implementing the most important features and not caring about feature parity. This is the best balance for small utils, but you lose the ability to be used as a drop-in replacement. (e.g. lsd / eza vs. GNU, ripgrep vs. grep)
Getting a critical mass of devs onboard is key to success, but also difficult. Outside of some open core software making some shitty money-grabbing decision and sparking community outrage, that's not very probable.
IMO there are many alternative kernels than Linux. It's a good kernel, but it's also written in C, is monolithic to a fault, and has a lot of legacy debt.
I don't think a new kernel will take over from tomorrow, but this will give projects like Redox a boost (hopefully) and slowly encourage enterprises to consider other systems for their software.
Linux was already showing its age with the reluctance of the incumbent maintainers to support new technologies and ideas because it threatened their superiority complexes, and this is yet another sign that maybe reform isn't the solution.
I feel like Linux may be going the way of UNIX. Not in some pessimistic "it's joever" way, but in the way that it eventually will be superseded by an improved project with better leadership, better technologies, and better principles.
I feel like Linux may be going the way of UNIX. Not in some pessimistic "it's joever" way, but in the way that it eventually will be superseded by an improved project with better leadership, better technologies, and better principles.
I remember having this shower thought, "it's weird to imagine people still using Linux in 2050." Of the three main OS, Linux is the oldest one. Windows NT is slightly newer than Linux and macOS is only around 2 decades old. Even the various BSDs are slightly newer than Linux.
-
Is it really a fork if all you do is take upstream and remove the blobs?
What code has this fork created that makes it novel? Have they tried to replace those blobs with open source drivers?
Is it really a fork if all you do is take upstream and remove the blobs?
Yes that's what a fork is, a disagreement with upstream's direction and taking your own measures. Git is a decentralized version control system that allows for this.
What code has this fork created that makes it novel?
Deblob scripts and regularly checking the source code for complying licenses. They regularly follow upstream kernel releases and are the first ones to signal license issues and inconsistencies.
Have they tried to replace those blobs with open source drivers?
I should have been more specific. Virtually all drivers in the upstream Linux kernel are licensed under a libre license. However, manufacturer firmware (small amounts of code designed to "unlock" the device's capabilities) are distributed as a binary blob that gets loaded into your computer (you're allowed to redistribute the firmware in binary form, but not anything else). The Linux kernel's upstream (aka Torvalds and other high level maintainer's own trees) allows the use of nonfree firmware for device support (AKA getting your foot into the door). In short, no modern computer device that people use regularly is free from private tampering. Who are these "private" tamperers? The US-led digital empire.
If you have a machine (or more likely, a virtual machine) that doesn't require device firmware, then linux-libre is the superior kernel as it subtracts the space and attack vector costs of nonfree firmware. We aren't at that point yet as CPU microcode is far too important to give up on physical hardware, but for nations in the Global South with the engineering capacity, linux-libre does all the work of de-westernizing the kernel.
Git is a decentralized version control system that allows for this.
You don't need a decentralized version control system to fork, you can do it in Perforce or SVN or whatever too.
That's all, just wanted to pedantically correct this thing.
Ok but again if all they are doing is removing the proprietary blobs, and not replacing them with firmware or drivers that are open source, they're not adding anything of value. They're just deleting code and patting themselves on the back.
Compare this to OpenBSD's stance where they refuse binary blobs and only support drivers where they've written the code for it.
What's your point here? That volunteers not financially backed by the US regime don't magically have the capacity to reverse engineer the dozens upon dozens of blobs that get added to the kernel every release cycle? Or that they're even trying at all? Both aren't a good look for whatever you're trying to say
they're not adding anything of value.
Now you're just being vindictive towards others and I really don't like that. It doesn't cost anything to not be unkind towards people's contributions. You're free to criticize the approach but I draw the line at the idea that it is worthless because none of this work is.
Comrade, I'm merely pointing out that binary blobs have been the bane of open source for decades and my ass is old enough to remember when the original debate about accepting them or rejecting them originally happened. Some, like mainline Linux accepted then, while more hardcore folks like Theo de Raat from OpenBSD refused to accept them, and wireless drivers for a decade were absolutely shit until everyone reverse engineered the broadcom drivers.
I'm merely stating that a fork needs to be more substantial than just deleting a bunch of binary drivers and saying boom I now have my own fork of the Linux kernel.
I mean I could delete all the Linux fiber channel drivers and claim that I have a fork of Linux but that's not notable
it's still a useful thing to have exist even if it doesn't meet your arbitrary standard of a "real" fork
for people that aren't severe linux-heads, recreating what they've done and producing a working kernel without blobs and such would be non-trivial to impossible.