Linux and the Freedom Paradox
Linus is losing control of Linux. "Rust People" do their own thing. And of course, as usual, they are deeply connected to Microsoft (using Microsoft's tools and only Microsoft's social control media platforms [1, 2])
The "Rust People" (led by Miguel Ojeda in this case) are vexing and upsetting Torvalds, as we predicted way back in 2022:
Subject: Re: [git pull] drm for 6.18-rc1
To: Dave Airlie <airlied@gmail.com>, Miguel Ojeda <ojeda@kernel.org>
Cc: Sima Vetter <sima@ffwll.ch>, dri-devel <dri-devel@lists.freedesktop.org>,
LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
[ Miguel: Rust conflict resolution question at the end ]
On Tue, 30 Sept 2025 at 21:06, Dave Airlie <airlied@gmail.com> wrote:
>
> As usual, let me know if there are any problems.
You are still corrupting indentation in your explanations.
I don't know *what* you are doing wrong, but it's wrong. You seem to
have lost all indentation.
Look here as an example:
> rust:
> - drop Opaque<> from ioctl args
> - Alloc:
> - BorrowedPage type and AsPageIter traits
> - Implement Vmalloc::to_page() and VmallocPageIter
> - DMA/Scatterlist:
> - Add dma::DataDirection and type alias for dma_addr_t
> - Abstraction for struct scatterlist and sg_table
> - DRM:
> - simplify use of generics
> - add DriverFile type alias
> - drop Object::SIZE
> - Rust:
> - pin-init tree merge
> - Various methods for AsBytes and FromBytes traits
Notice how there are multiple sub-areas: Alloc, DMA/Scatterlist, DRM and Rust.
But it's all just a random jumble, because you have apparently pasted
it into your editor or MUA or whatever and dropped the indentation in
the process.
Or something.
What kind of *broken* editor are you using? I'm not trying to start an
emacs or vi war here, but you seem to be using something truly broken.
EDLIN?
And similar thing here:
> msm:
> - GPU and Core:
> - in DT bindings describe clocks per GPU type
> - GMU bandwidth voting for x1-85
> - a623/a663 speedbins
> - cleanup some remaining no-iommu leftovers after VM_BIND conversion
> - fix GEM obj 32b size truncation
> - add missing VM_BIND param validation
> - IFPC for x1-85 and a750
> - register xml and gen_header.py sync from mesa
> - Display:
> - add missing bindings for display on SC8180X
> - added DisplayPort MST bindings
> - conversion from round_rate() to determine_rate()
Look, again, no logic and you've completely corrupted any multi-level
indentation that presumably existed at some point judging by the
organization.
WTH?
I try to make this all legible as I walk through it myself.
So I regularly fix up peoples language skills etc, because I
understand that English isn't always the native language (and that
even if it is, some people just aren't very good at writing
explanations).
But these kinds of "I'm pretty sure you've just corrupted the
formatting that was there in some original message" is just
_annoying_.
Please make the explanations *readable*, not just a random jumble of words.
And on a more technical side: I absolutely detest the mindless and
completely crazy Rust format checking.
I noticed that people added multiple
use crate::xyz;
next to each other, so I turned them into
use crate::{
xyz,
abc,
};
instead to make it easy to just add another crate without messing crap
up. The use statements around it had that format too, so it all seemed
sensible and visually consistent.
But then I run rustfmtcheck, and that thing is all bass-ackwards
garbage. Instead of making it clean and clear to add new rules, it
suggests
use crate::{xyz, abc};
but I have no idea what the heuristics for when to use multiple lines
and when to use that compressed format are.
This is just ANNOYING. It's automated tooling that is literally making
bad decisions for the maintainability. This is the kind of thing that
makes future conflicts harder for me to deal with.
Miguel, I know you asked me to run rustfmtcheck, but that thing is
just WRONG. It may be right "in the moment", but it is
(a) really annoying when merging and not knowing what the heck the rules are
(b) it's bad long term when you don't have clean lists of "add one
line for a new use"
Is there some *sane* solution to this? Because I left my resolution
alone and ignored the horrible rustfmtcheck results.
I tried to google the rust format rules, and apparently it's this:
https://doc.rust-lang.org/style-guide/index.html#small-items
can we please fix up whatever random heuristics? That small items
thing may make sense when we're talking things that really are one
common data structure, but the "use" directive is literally about
*independent* things that get used, and smushing them all together
seems entirely wrong.
I realize that a number of users seem to just leave the repeated
use kernel::xyz;
use kernel::abc;
as separate lines, possibly *becasue* of this horrendous rustfmt
random heuristic behavior.
Linus
Recent: Tux Machines Loves Software Freedom
Linux is going off the rails in the sense that its founder and main leader, the release manager and so on, is no longer in control. He does not understand the code that goes into Linux, and it's not just due to a lack of time.
He has just said, "on a more technical side: I absolutely detest the mindless and completely crazy Rust format checking."
A project whose head is not in control is out of control and a project whose developers cannot comprehend the code (most Linux developers cannot read/write Rust) misses out the most essential prerequisite for freedom.
Linux is losing freedom if some external actors who only use Microsoft tools for development wrest control.
Many, but not all, of those actors are Microsoft staff.
When Torvalds rants about Edlin he's referring to MS-DOS et al. This is the mindset of "Rust People". They already do the same thing to Git (another Torvalds projects) on Microsoft's payroll. █