> Dave Airlie just announced in the Maintainers Summit that the DRM subsystem is only ""about a year away"" from disallowing new drivers written in C and requiring the use of Rust.
When the C absolutist maintainers fought for control over the ability to keep Rust out of their ballpark, I didn't expect the reverse to happen.
Still, I think it makes a lot of sense. Completely new GPU drivers are quite rare and the macOS drivers from Asahi are a showcase proving that Rust and GPU drivers work together well. If there's any subcomponent switching to Rust-first for new contributions, it makes sense for it to be the one that had already been proven to be Rust-compatible.
The Rust crustaceans should apply their knowledge to Redox OS and top sending Rust crapware (which it might be fine for security, but Cargo it's a nightmware to maintain) and stop messing with GNU/Linux and, by proxy, the rest of the BSD's.
As tons of distros adopted LibreSSL, it might happen the same with KMS/DRM+MESA as it happened with Xenocara for X.org under OpenBSD and the special X server under NetBSD for legacy machines with really weird adapters leaving out the modular X.org -mainstream- to ports. They might call it VEGA (for MESA) and Iridium (for Gallium middleware).
Asahi project looks barely alive, almost abandoned. I know that their explanation of low activity is that they are being active elsewhere, supposedly pushing all their work upstream, but this has been happening for months and they don't give any reports about their progress, so I'm worried it will all die soon. And given that the project barely brought some Linux compatibility for m1 and m2 hardware and no prospects for bringing similar compatibility for newer generations - I fear it all will be kinda useless in the end.
They inarguably have slowed down, but this should be expected as the project matures. It has also inevitably now faced the time when new generations of contributors are needed as existing ones retire/ move to other projects.
How can it be mature if it can't even boot on newer MacBooks. The slowness does not seem to be due to running out of impactful work that needs to be done.
The new leadership team blogged last year that their priority would be on upstreaming their existing work.
> Our priority is kernel upstreaming. Our downstream Linux tree contains over 1000 patches required for Apple Silicon that are not yet in upstream Linux. The upstream kernel moves fast, requiring us to constantly rebase our changes on top of upstream while battling merge conflicts and regressions. Janne, Neal, and marcan have rebased our tree for years, but it is laborious with so many patches. Before adding more, we need to reduce our patch stack to remain sustainable long-term...
Where do the M3 and M4 fit in? Until upstreaming and CI progress, the core team cannot prioritize new hardware.
I think the majority of that upstreaming work (that isn't on hold until the kernal is ready for the Rust graphics driver to land) has happened and additional features like DP alt mode for USB C have been demoed.
The next update from the team should land on their blog after 6.19 ships
Activity has died down as a result of general Linux kernel developer drama, petty in-fighting, and other factors, but that doesn't change the results they did produce during their most prolific phase so far.
Without proper support from upstream like AMD, Intel, and Qualcomm (to some extent) are doing, Linux will never work as well on Apple's hardware as it does on normal hardware.
Looks believable that they are indeed the devs behind the project, but it's weird to post stuff like that to... reddit? They have a site for the project, why not post there?
Please, stop pluralizing "BSD's", every BSD it's different and OpenBSD only reuses Linux drivers for KMS/DRM; FreeBSD has special layers and tons of drivers ported and NetBSD it's closer to philosophy in design.
So GNU/Linux now it's in the same group as FreeBSD as it has ZFS? Because neither NetBSD nor OpenBSD have it.
OpenBSD doesn't 'rely' on Linux drivers, thanks. Just a shim against KMS/DRM, everything else it's either homegroup or sometimes adapted (back and forth) from NetBSD but OFC patched for correctness and security. There's no ALSA. Pulse it's totally optional. There's no wpa_supplicant except for Eduroam or simlar niche crap under OpenBSD.
OpenBSD has OSS and sndiod. There's Xenocara, an X11 fork.
Again, not Linux, X11, MESA and Gallium are damn generic. Show me the rest of ported Linux drivers into OpenBSD, please.
> That's been made clear pretty much from the very beginning, that nobody is forced to suddenly have to learn a new language, and that people who want to work purely on the C side can very much continue to do so.
If any C developer developed drivers in C previously for the DRM subsystem, they might in the future be forced to learn Rust.
You're confusing the audience here. That's directed at subsystem maintainers, not just 'anyone who wants to submit a patch'. If a subsystem doesn't want to deal with Rust code, they won't be forced to. But there's no restriction on the inverse.
Whether that's true or false depends on what your hypothetical developer wants to do in the future. When an all-new driver is written in Rust, then working on that driver will require knowing Rust. But nobody's talking about trying to re-write all the existing drivers in Rust, so there will still be plenty of C code to work on even in the DRM subsystem.
That means that, even if a C developer used or added C bindings to DRM when wanting to write a new driver, they would be forced to write their new driver in Rust regardless. That seems to run counter to the promises made by Linus.
> In persons with low small intestinal lactase activity, colonic bacterial flora can adapt to persistent lactose ingestion and thereby contribute to a reduction in the incidence and severity of symptoms following a lactose load.
I'd have Secure Boot, and then one root for an user-modifiable regular Linux installation, and another root that is read-only, signed, custom kernel etc.
I pointed to this BMJ reference because in the article there is the following: "To help drive down our ApoB, we have statins which do miracles for lipid management. Some people believe that everyone should be on a statin so long as they don’t have adverse side effects."
Most statins prescribed today are not for secondary prevention.
A lot of doctors prescribe a statin immediately on seeing just one measure of "high" LDL without looking at any other parameter or context.
Yeah, for each level of cardiovascular risk (in America, probably calculated with PREVENT) there is a target LDL which should guide whether you should start or not a statin.
I got to know UNIX (or rather Linux) about 12 years later. And TBH, I wasn't very impressed. I was like "oh, you have to do all that on the console". That's how green I was :D But then it caught me, and about a month later it was more "WOW, you can really do everything on the conole!"
What eventually helped me to really get into things was Linux From Scratch. If anyone wants to learn how a modern system works under the hood, and like those guys in the article know the very basic, minimal things that keep a system running, I can recommend it very much: https://linuxfromscratch.org/
Even if you dislike the REX prefixes of AMD64, you've got to think about the 66/F2/F3 prefixes used for older SIMD instructions. They were introduced by Intel and basically contribute to more opcode bits. There's also the 2E/3E prefixes used for static branch prediction hints in some Pentium 4's (and also in new/upcoming Intel CPUs). VEX is from Intel, EVEX is from Intel, and the upcoming REX2 is also from Intel.
REX is horrible because they occupy two full rows of what were otherwise very useful instructions (inc/dec), and there were other gaps and less-useful instructions (segment override prefixes? If segmentation doesn't work in AMD64 mode, what's the point?) in the opcode map they could've used instead.
I'd use Abbas' Immunology as a standard textbook and Sompayrac's How The Immune System Works as a more straightforward, lean book on the immune system.
wow