As unfortunate as this whole episode has been, it is great to have this clarity from Linus. It feels like quite a straight-forward guideline to apply to future situations. Hopefully it will really cut down on the noise and drama between the pro-Rust and anti-Rust camps in the kernel.

As long as Linus stays consistent with the stance he outlined here, things should go well.

If you are building apps from source, consider creating an actual Chimera Linux apk. It is surprisingly easy. I like keeping everything under the control of the package manager.

That is assuming you are a Chimera Linux user of course.

I also use Chimera!

As everybody else is saying, Distrobox is the way to go and it is already in the repos (using Podman). It works amazingly. I setup an Arch Distrobox so now I have Chimera + the AUR which is just perfection for me. I still use native Chimera when possible and have created quite a few of my own packages. Sometimes I use Distrobox just to check something out and then create a native package later when I have time.

doas apk add distrobox

distrobox create —name arch —image docker.io/library/archlinux:latest

distrobox enter arch

That is all you have to do (though you have to add yay or paru inside Arch to use the AUR). You will be in an Arch console and have access to all Arch software.

Distrobox create seems a bit slow setting up overlayfs for some reason but it runs stellar after the first time.

If you really prefer Void…

dostrobox create —name void —image ghcr.io/void-linux/void-glibc-full:latest

Flatpak works as well if that is your thing (as you say). prefer Distrobox.

I realized just yesterday that Chimera comes with Broadcom WiFi drivers right in the kernel (no DKMS or CKMS required). Just download firmware with b43-cutter (also included). So I have dropped Chimera on a couple older MacBooks. I put it on an old 2009 MacBook Pro yesterday and 100% of the hardware is supported (Ethernet, WiFi, Camera, Audio, brightness and volume controls, sleep, everything ). I did a video meeting on it just for fun and nobody even noticed (the camera sucks in low light but that is hardware). Honestly, I cannot believe how well it runs. For basic office stuff, you would never know (unless you looked at CPU utilization—which will be high!).

Chimera Linux is still in beta but it already feels rock solid. I am so impressed with it as a distro. And the only downside is totally mitigated by Distrobox.

Enjoy!

[edit: I never answers “why” I guess. Distrobox uses Podman so it is amazingly light on resources. The app will run right on the Chimera kernel. What Distrobox adds is persistence and tight integration. By persistence I mean that changes you make in the Distrobox (like installing software) will be there the next time you enter. By integration, I mean that you see your normal /home and have direct access to hardware. It does not even feel like your app is in a container. GUI apps “just work” out-of-the-box. Type the name of a GUI app and it pops up in your native Wayland session. It is even possible to create desktop links so individual apps can be started point and click without having to go into the terminal. It is like magic.]

Pretty sure the mic does not work if you need to have video meetings.

Alpha vs beta is usually about feature completion. I am quite happy they have more ambition in terms of what features they want to ship.

Progress has been steady and each alpha has delivered a solid list of improvements. This looks like a good one, especially the memory usage.

I have been using it for months. Looking forward to this update as it has been a bit memory heavy.

Overall, it has been working great for me. There have been bugs though, especially with multi-monitor. Again, looking forward to trying out this update.

There is still room to go on the polish front I would say. And the built-in apps are still a bit basic. It all depends on your tolerance.

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. Hopefully it will reduce the level of noise going forward.

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