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.
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.
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.
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.]
The actual payment system stops payments automatically at age 115 and requires manual verification to restart. The database that is being reported is not even a report of who is getting paid.
This is just dramatic, public evidence of the arrogance and incompetence of DOGE from down to his racist younglings.
For a while, I thought they would at least be good at technology. This episode shows that even that is not true.
How he chose this elite group of chuckleheads is an eyebrow raiser. Other than racism, they seem to have no credentials at all. I mean, on brand for this administration I guess.
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.
Look at the polls. Mark Carney gained almost entirely from the NDP to tie the conservatives. The Conservatives did not lose a vote.
If I was the NDP, that would piss me off. But they need to ask themselves, who do they want to win the election. It is very clearly not going to them. And, if they dunk on Mark Carney too much, it may not be him either.
Would the NDP prefer Mark Carney or Pollivere? They need to decide because, if the libs and NDP are stuck in a zero sum game, it may actually be the NDP that gets to decide the next election. The conservative vote appears locked in. The only question is how the everybody else is going to vote.
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
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.
The US has not really done all that much. That said, as above, others would have to step up.
But the US has mostly been sending old stock and then replenishing their own. All the money they claim to be sending is being spent in the US.
And anything actually new has been very, very slow rolled. Canada made the mistake of piggy-backing purchases on US orders. Air defence systems Canada fully funded (money to the US) in early 2023 are only being delivered now.
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.