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

  • hello_hello [comrade/them]
    ·
    edit-2
    2 months ago

    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.

    • Owl [he/him]
      ·
      2 months ago

      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.

    • footfaults
      ·
      edit-2
      1 month ago

      deleted by creator

      • hello_hello [comrade/them]
        ·
        edit-2
        2 months ago

        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.

        • footfaults
          ·
          edit-2
          1 month ago

          deleted by creator

          • Chronicon [they/them]
            ·
            2 months ago

            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.