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
The most important piece of software in the world is being made worse on purpose so that Putin has a 0.4% higher incentive to stop a war he’s winning by a wide margin.
This makes Russia incentived to double down on on the war, though, as there is less and less room for normalization of relations.
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.
This may legitimately be one of the most damaging moments in western hegemony moving forward. The one area where BRICS and other non-westerm blocs have not made major strides to dissociate from the west is Linux; even North Korea uses its own Linux distro domestically. A large part of the reason for that is that it’s traditionally been seen as such a stable and generally apolitical kernel that the usual worries about spyware in your firmware isn’t as big of a concern, so China and Russia don’t have major concerns about leveraging the kernel for their domestic industries. Hell, Russian programmers have been massive players in open source development traditionally.
This is fire across the bow for Russia, and you can be sure some bureaucrat in Beijing is taking notes right now.
Is the open source movement even viable without highly skilled but underemployed Russian technical labor?
For real, even in game communities we’ve had several Russian contributors reverse engineer entire game engines.
The West seems to be doing whatever it can to accelerate its decline.
American hard power is about to be hard countered, so America’s massive amount of soft power could provide a nice floor to keep a comfortable position on the world stage after its coercion mechanisms are thwarted. But they keep trying to weaponize their best means of post-multipolar relevancy.
Using the Linux kernel to push their short term geopolitical objectives is about as large of an unforced error as can be made.
Having the most developed open source ecosystem gives the US & EU disproportionate influence over the direction of the technology sphere; an advantage adversaries are incentivized to avoid trying to circumvent because no one wants to waste time reinventing the wheel.
Yeah, it’ll probably slow Russian technological development a little for awhile until non-Western ecosystems mature, but this will hurt the West far more in the long run than the relative edge they get over Russia.
Any countries not explicitly Western-aligned will see the writing on the wall and take steps to build homegrown alternatives that can’t be used for leverage over them…and they can start just by forking the Western projects.
Russia, China, India, Brasil, Iran, Saudi Arabia, Vietnam, Africa, Latin America, and Southeast Asia will comprise a vast majority of software developers, and their projects will inevitably outpace their Western counterparts as more countries develop, especially if this trend of wielding FOSS as a geopolitical coercion tool continues.
What happens when China has a runaway technological edge and decides to take giant strides to build and migrate their products/systems to a homegrown kernel?..now 30%+ of global manufacturing is built without consideration for Linux compatibility and interop. Soon any software wishing to take advantage of top hardware begins to target this new kernel and Linux kernel support becomes an afterthought. Shortly after, new APIs and programming languages are built to target these platforms, with bad/no localization to Latin & Germanic languages, possibly even using hanzi or cyrillic instead of latin characters. Then you wind up a tech ecosystem where cultural factors disadvantage Westerners instead of the opposite in the current status quo.
Throwing away global leadership to take cheap shots at Russia.
Meanwhile, Russian devs & Russian companies will make sockpuppet personas and accounts, fork the kernel, and ignore licensing since they’re gonna be blocked from Western markets regardless.
Like with every failed colonial war, the losing side gets more and more desperate for a “final victory” in some grand counter offensive or wonder weapon or other bold strategy.
Every time, it is a massive gamble that has a massive cost at the slim chance of a reward. At some point, sunk cost fallacy kicks in and everything becomes potential ammunition to throw at the enemy.
even North Korea uses its own Linux distro domestically
Russia also uses one in some portions of its state.
It’s interesting reading. Seems a lot of sole maintainers have been removed, so lots of important parts will start breaking. There’s also a lot of acknowledgement in the comments that chinese developers are an essential part of Linux development nowadays. And the US just gave China a very good reason to not collaborate on their projects, and there’ll be plenty rightly pissed off Russian developers who’ll be looking for something else to work on…
Just as the US is losing economic dominance, I wonder if this is the beginning of similarly losing its dominance in software development.
If the Russian and/or Chinese kernel maintainers decide to work on a sovereign kernel project, I’m definitely cloning their repo and will hopefully help with the project as long as the US Empire doesn’t stop me. Because the US keeps ruining my career and technical libre hobbies, I hope to move to China at this point.
Ya rab I pray
Other than Linus’ evident chauvinism and the conflicts created by firms like Amazon/Microsoft buying into Linux over the last decade, there’s no reason the maintenance of a shared global kernel can’t include contributions from multiple “Linux Foundations” globally.
Wow Torvalds is a jackass
Do you actually know who he is? I’m not even being funny with the
.He’s always been like that
There won’t be any forking, come on.
The problem is the brainworms that live in the most prominent and knowledgeable Linux kernel maintainers. There’s no winning here.
Now that I’ve pondered this a little bit more. I think the shocking thing won’t be forks. There really are thousands of forks. But people will likely begin to coalesce around different upstreams in higher numbers than we’ve ever seen before.
I just don’t see that though. The Linux kernel is a hierarchy, with Linus at the top and a ton of incredibly skilled lieutenants (Greg K.H, Ted T’so, countless others) going down. It’s an incredibly complex system and there’s too much momentum.
What happens when we reach the point where it is practically impossible for companies like Yandex or Huawei to upstream patches? They are going to maintain their own trees, and those kernels will ship on millions of consumer devices.
That’s what happens already with things like Android. The difference is that those companies are just tacking on their additional bits to make their stuff work, but they’re not actually driving the architecture and design of the overall system.
Like if tomorrow the Linux kernel all decided to make a radical change to a major subsystem, they’d have to cope with it, or go it alone. Realistically everyone is going to adapt. They’re never going to be the ones able to dictate how a system is designed, because they’re downstream of where all the development actually happens. If that makes sense. My point is that an actual fork is when they diverge radically and start building things themselves that make significant changes to the architecture that are distinct and different from upstream
hard and soft forks are both forks. tradeoff of effort vs. autonomy.
There’s also the possibility of a complete rewrite. You can either keep the same syscall API and ABI or have your own with a translation layer for compatibility. I think OpenHarmony does something like this, having a base microkernel and compat layers for Linux and Android.
I suspect China is going to see this and dump a shitton of money into accelerating OpenHarmony or projects like it.
Oh shit will be 2025 be the year of the HURD desktop?
Russia is a big country and if Russian devs are generally unhappy with this, they could likely maintain a Linux fork. Especially if devs from other big countries in geopolitical tension with NATO, namely China, also coalesce around this fork.
Finally, BSD’s time to shine
By shine, you mean spend all the time kernel panicking and rebooting in drm-kmod bugs that try to emulate Linux syscalls incorrectly and fail
Their lack of GPL is not good. Non copyleft licenses have continuously been taken advantage of by capitalists
https://hexbear.net/comment/5541326
I learned Hyperbola is moving to its BSD derivative kernel, HyperBK, on this thread, and it will be GPL.
Interesting. Thanks for the link!
My question is, why do this only 3 years into the war? This would’ve gotten far more support from libs right after the war started.
feds are incompetent of course
the main issue is that their recruits either have to be VERY dumb (to think that they are the good guys) or comically evilbecause the Biden admin can get the walls closing in from Trump and is crying out for a win
Maybe took 3 years for yankfeds to push through
Mirror of the commit on GitHub with lots of comments: https://github.com/torvalds/linux/commit/6e90b675cf942e50c70e8394dfb5862975c3b3b2
seems bad
the feds are probably behind this
Before I heard this yesterday, the same day I was thinking I would like to make my own operating system that was kernel-agnostic, (Free/Open/etc.)BSD and Linux (and maybe Hurd) as supported kernels, combined Gentoo and Guix’s features, removed Python has a hard dependency (which includes glibc, for example, as it needs Python to compile), and prioritized being built with only fast languages, probably with a focus on Zig, Rust, C, and Racket/Chez Scheme, enabling a very minimal distro. It would eventually allow packages like Python to be supported, but the idea was to make a distro that could be stripped down further than even Gentoo and have a package manager built in a fast language. I would probably need to support musl (which on Gentoo has a crypt use flag for libxcrypt, which depends on Python, though I believe it’s for running tests), µClibc, Cosmopolitan Libc, or work on my own fork of some libc instead of glibc.
With this news, this hobby project that I hoped to make a living from donations seems important now in regards to supporting BSD.
Linux is canceled time to go openbsd
Can someone make a video on what this means in practice?
In practice it means that some maintainers to the Linux kernel have been removed. It’s a fucked up thing to do but in and of itself would likely not achieve any particular effect either way. Just a worrying direction for the official kernel to go down.
What is a maintaner?
They’re the people who take the code from thousands of developers, check it for errors, make sure there are no regressions, coordinate the code with the patches from other maintainers from further up and down the tree, and finally herd the patches toward the mainline, as well as manage backports.
It’s essentially another term for developer, but a developer which maintains/administrates a project and analyzes, coordinates, and governs the patches (changes to code) that are applied to a project, especially a large one like Linux, Rust, Git, etc. where multiple maintainers are needed.
https://docs.kernel.org/maintainer/feature-and-driver-maintainers.html
So, banning maintainers who are russian means what in the long term? What were they contributing before?
It sets a precedent of banning maintainers and other contributors from nations in the Global South and nations declared enemies of NATO. This goes against open source philosophy, and this will lead to China and other nations needing to develop their own sovereign forks or kernels from scratch.
It’s similar to the US working to ban RISC-V to stop China from using an open source instruction set to become more technologically sovereign. Restricting open source software from NATO’s enemies is essentially NATO shooting themselves in the foot in the long term. NATO is sanctioning an enemy, so the enemy is incentivized to build alternatives to tech they lost (which can be forked easily), and then the alternatives become popular and challenge NATO’s tech, which is not competing where over 30% of manufacturing industry exists, which leads to NATO’s tech and industry crumbling as it cannot dominate the market like it was able to before and further accelerates the Empire’s decline.
This is a good comment on this thread that explains the long term consequences more comprehensively than what I did: https://hexbear.net/comment/5541448
Thank you I’ll check that out.
