He understands Rust and claims to like it. He simply disagrees with the decision to have a mixed language kernel and is trying to unilaterally stop it from happening.

This is such a red herring.

The Rust side we are talking about here have been involved for years. They have written amazing code (eg. Apple Silicon GPU drivers). There is an official Fedora spin based on their work.

What makes you think any of that is going to go away?

In fact, this whole incident shows their depth as the project lead quit Linux in disgust and was quickly replaced with another talented, dedicated, and proven developer.

There is a lot more drive-by C code you should worry about.

Instead of thinking about the bindings as part of the sub-system, think of them as part of the driver. That is what Linus is saying here.

The Rust code will be maintained, by those writing Rust code. By those writing the drivers. These are not junior people.

Except the bindings are written so that they can be used not just by this driver but others as well.

If companies write crappy code that calls into these bindings, that is nothing new. They do that today with C. Like C, the code will not be accepted if crappy and / or there is nobody credible to maintain it.

None of this is a good argument for not letting these bindings in.

That is not how it will happen, if it ever fully converts at all.

Rust will first be added in a way that allows it to run on top of existing C code. That is what we are seeing here with Rust being used to write drivers.

As sub-systems get overhauled and replaced, sometimes Rust will be chosen as the language to do that. In these cases, a sub-system or module will be written in Rust and both C code and Rust code will use it (call into it).

The above is how the Linux kernel may migrate to Rust (or mostly Rust) over time.

As devs get more comfortable, there may be some areas of the kernel that mix C and Rust. This is likely to be less common and is probably the most difficult to maintain.

Nobody wants to rewrite working, solid kernel modules in Rust though. So, it seems very likely that the kernel will remain mostly C for a long, long time. There are no doubt a few areas though where Rust will really shine

No need for a fork or a rewrite.

Agreeing

He is totally correct and it is great to see him finally step in to settle this drama.

I do not know why you say it is easy to break.

The Rust team are maintaining their side. I do not expect it to break. And the C code that the Rust code depends on is used by lots of other code. It should be a stable interface. Changing the C code just to break the Rust code would break a lot of C code too and upset a lot of folks.

And the who point is to create a more idiomatic interface on the Rust side. So, even if the c interface does change, it may only be a small amount of Rust code that needs to change in response.

Anything sold after 2008 will do that. Before that too but you probably want 64 bit.

Old MacBook Airs have fans but they rarely come on. I got a 2013 for $70 last summer and use it everyday.

If I understand, this is less a complaint about how UNIX works and more a story about the consequences of careless mistakes.

This is why we have KVMs I guess. Though not every server has one of those.

I had my first ever “breakage” on Arch recently. Actually two just recently (both on an old Mac):

• the driver for my Broadcom hardware was broken for a day
• with the upgrade to kernel 6.13, the FaceTimeHD camera is not working

Neither issue seems to be present in the LTS kernel (which is 6.12). I have both a current and an LTS kernel installed. So rebooting to LTS had me up and running. If I did not have that, no WiFi would have been a bigger issue os the MacBook Air has not Ethernet. The lack of a camera would be no video meetings without the LTS kernel as well. The problem has existed for a few days.

So, I can no longer say that I have never had an issue on Arch. I can say they have been rare. I can say I had more issues with Ubuntu or Fedora in the past.

I can also say that the only breakage I have had was mitigated by having an LTS kernel to reboot into.

Sorry for the multiple answers. I just saw this as well…

https://dev.mysql.com/downloads/workbench/

I do not recommend Arch to new users but I really wish people would have a point supported by evidence when they post.

There is no 50 page manual to install EndeeavourOS or CachyOS, the two distros mentioned in the graphic. Both are as easy to point and click install as Fedora and maybe easier than Debian. The better hardware support makes the install much more likely to succeed. They both have graphical installers and lead you by the hand. In fact, when it comes to EOS, its entire identify is making Arch easy to install and to provide sensible defaults so that everything works out of the box. And of the 80,000 packages in Arch/AUR, less than 20 of them are unique to EOS (mostly theming).

There are lots of things to complain about regarding Arch related distros. Or maybe there isn’t if we have to lie about them.

Use the RPM instructions here:

https://dev.mysql.com/doc/workbench/en/wb-installing-linux.html

I was going to recommend Flatpak but it does not seem to be on Flathub. Maybe consider one of the other SQL front-ends:

https://flathub.org/apps/collection/tag/mysql/1

It is just a desktop app, not server software.

Unless you mean Distrobox.

Really seems like we are agreeing. I get that the limited package set is a feature. I also get that it is both too small and too enterprise to satisfy most people you would describe as a “SO” precisely because they are probably normal people.

You gave the excellent example of Spotify and suggested a Flatpak for that. Honestly, I am not sure where we are in disagreement. Especially since I started by “mostly agreeing” myself. We even agree on that. :)

In the era of Flatpak, I kind of agree with you.

The primary drawback is the complete lack of packages. A home user is going to want something not included and then things fall apart. Flatpaks and Distrobox have made that a lot better.

If you could get away with a RHEL core and Flatpak for apps, you would have a pretty solid setup for a “normal” person.

I doubt you care but others may want to know that you just hit the nail on the head. Just not the way you think.

All the Rust folks want is for “technically superior” solutions to be accepted on their merits. The exact problem is that some influential Linux folks have decided that “technically superior” is not the benchmark.

Take the exact case that has led to the current debate. The maintainer said explicitly that he will NEVER accept Rust. It was NOT a technical argument. It was a purely political one.

In the Ted Tso debacle. a high profile Rust contributor quite Linux with the explicit explanation that the best technical solutions were being rejected and that the C folks were only interested in political arguments instead of technical ones.

If it was true that “technically superior” solutions were being accepted, the R4L team would be busy building those instead of arguing.

If we are going to be honest, let’s not be misleading.

Nobody is looking to replace C in the kernel just to switch out the language. This is not a “rewrite it in Rust” initiative.

What the R4L folks want is to be able to write “new” code in Rust and for that code to call into the C parts of the kernel in an idiomatic way (idiomatic for Rust). So they need to create Rust interfaces (which they, the R4L side, are doing). This whole controversy is over such an example.

At this point, we are talking about platform specific drivers.

Now, new kernel code is written all the time. Sometimes newer designs replace older code that did something similar. So yes, in the future, that new code may be written in Rust and replace older code that was written in C. This will be a better design replacing an inferior one, not a language rewrite for its own sake.

Core kernel code is not getting written in Rust for a while though I do not think. For one thing, Rust does not have broad enough architecture support (platforms). Perhaps if a Rust compiler as part of GCC reaches maturity, we could start to see Rust in the core.

That is not what is being talked about right now though. So, it is not a reasonable objection to current activity.