Comment by Octoth0rpe
10 months ago
Well that's unfortunate.
It seems like there's a balancing act between the benefits of writing drivers in Rust (easier, more maintainable), and getting those drivers mainlined (apparently soul-destroying, morale killing), I wonder if the Asahi team is considering simply abandoning linux in favor of something more rust friendly (redox being an obvious candidate, but maybe one of the BSDs?). Given the narrow set of hardware they're aiming to support and that they're writing many of their own drivers _anyway_ (and so are not relying as much on the large # of existing linux drivers), that approach might be more viable. I'd be surprised if the Asahi GPU work wasn't the largest problem by far that their team faces, and as such it would make sense to choose a kernel that lowers the difficulty on that aspect to the greatest degree possible.
The goal of Asahi Linux is to create a Linux distribution that is compatible with Apple devices. Using Rust is not a goal of the project, it's just something they decided to use due to personal preference, and is making the process of upstreaming anything much harder. If anything, it works against them in achieving their goal. Abandoning Rust is a possibility, abandoning Linux is not.
> Abandoning Rust is a possibility, abandoning Linux is not.
The Asahi developers have repeatedly and publicly asserted that were it not for Rust they would not have been able to achieve the level of quality required for the project, at the speed they did, with as small of a team as they have. From the article:
> Rust is the entire reason our GPU driver was able to succeed in the time it did.
is there any particular reason it couldn't have been done in C? I'm having a little trouble believing these claims
2 replies →
I think neither is a possibilty: there is zero appetite for rewrite what they've written in rust in C, I think the most likely result of it not being upstreamed is it becomes a long-lived fork.
The author addressed that in the article.
Its sad that they chose Apple, instead of like investing time into the upcoming ARM laptops to make the Linux more optimized on them. That talent should not be wasted on tech jewelry.
The MBP is the best laptop hardware that exists on the market, by far. Why wouldn't someone who prefers Linux over macOS want to run Linux on it?
The existence of other ARM laptops is irrelevant; the reason MBPs are so good has little to do with ARM. Yes x86 makes the processor frontend more complicated but this doesn't make a big enough difference to come close to accounting for how much better the MBP is than its competitors. I would guess the biggest factors are Apple's ability to buy the entire run of TSMC's best process node, and the fact that they have a high level of competence at designing CPU cores and other hardware. The instruction set the core uses is just not that important in comparison.
1 reply →
I expect you are rage-baiting, but just in case you are not...
Even if you consider the hardware "tech jewelry", isn't it strictly better to have a way to run Linux on it instead of sending it to landfill? Seems silly to exclude a particular set of hardware from consideration for arbitrary reasons?
1 reply →
> Given the narrow set of hardware they're aiming to support and that they're writing many of their own drivers _anyway_ (and so are not relying as much on the large # of existing linux drivers), that approach might be more viable.
They are relying heavily on mesa. I'd also assume that GNU stuff is also pretty essential.
Perhaps Android would be possible? It has a HAL that might be easier to work with than the raw linux kernel. The android devs have put in a lot of effort to make downstream driver development not painful. With android, they'd also still have GNU stuff available.
The big issue is non-linux will mean every single open source tool may have a compatibility problem. You also end up dumping a huge amount of capabilities (like running docker containers).
Android would still come with the kernel development caveats which is where Asahi is having the most trouble. Android's HALs help abstract the userspace portion of drivers, but if you need to be in kernel space you're still stuck dealing with Linux. You could stick to just doing forks of the LTS releases, but then you're choosing between less-frequent-but-bigger merge conflicts every couple years vs. small-but-constant merge conflicts continuously.
> They are relying heavily on mesa
Isn't mesa portable? Or are there parts that are OS-specific?
> With android, they'd also still have GNU stuff available.
I don't follow; Android is a non-GNU Linux distro. Or do you mean that being on Linux makes GNU stuff easy? (But then, GNU runs happily on BSDs and other unix-likes)
> Isn't mesa portable? Or are there parts that are OS-specific?
Even the OS-specific parts are at least permissively-licensed. OpenBSD is about as religious about "all new code must be under an ISC-compatible license" as it gets, and even they pull in Linux DRM/Mesa code for hardware graphics acceleration: https://man.openbsd.org/drm.7
> Isn't mesa portable? Or are there parts that are OS-specific?
IDK. I'm not familiar with mesa enough to know how portable it is. That said, I do know that it's primarily deployed on linux. An issue with portability is simply that when big projects like mesa are developed, non-linux environments are rarely developed (No clue, for example, if you can build mesa for BSD).
> Or do you mean that being on Linux makes GNU stuff easy?
Mostly this. I don't think, for example, those GNU tools will port over to redox. Building them targeting android is a snap.
1 reply →
> I wonder if the Asahi team is considering simply abandoning linux in favor of something more rust friendly
The entire point of Asahi is to run Linux on macOS (edit: on Mac hardware, not macOS). If they did what you’re suggesting it would be a completely different project.
Well, I wonder if this is a good time for people to reconsider what they actually want out of Asahi. Things that I'm sure are on the list are open source, able to run the tools they want (standard gnu userland?), docker, maybe gnome/kde? I am not convinced that the linux kernel specifically is on that list.
Tons of dev workflows nowadays use docker which in practice means they require Linux.
3 replies →
If you don't use Linux it will end up as a dead project, no one is going to use redox.
Redox would probably be the best option. The BSDs, it would probably be an uphill fight to. I believe it's been floated, but no movement on incorporating Rust in the BSD kernels. So I they would have to start form scratch. The benefit of Linux in this case is, the Asahi team isn't single handily doing all the Rust in the Linux kernel, right. There are other Rust people and Rust for Linux was already getting somewhat bootstrapped before the Asahi project. With the BSDs, you would have to start with bootstrapping Rust in the kernels and build systems.
FreeBSD may be open to it? It's been awhile, and I haven't kept up to date on it for a year or two. But once again, I think you'd have to start from scratch. So everything for R4L that was built before Asahi Linux needs to be done on the FreeBSD side.
NetBSD is probably a no go. NetBSD supports architectures that Rust (due to LLVM) can't support. Which means it is most likely a no go for NetBSD, NetBSD's schtick is that it can run on anything and they will fully do everything in their power to make sure NetBSD can run on any hardware and be maintained. Hardware portability matters for them.
The attitude I've seen from OpenBSD devs is, the answer is to 'git gud' at C and, not replace C code with Rust. Or in other words, they have no interest in Rust in the OpenBSD kernel.
I don't really know where DragonFlyBSD falls in this. Its the BSD I know the least about.
They would need to completely reset to do that. Do BSDs even have rust support for their drivers?
For what it's worth, the Oxide Computing people have written illumos driver(s) in rust: https://github.com/oxidecomputer/opte/tree/master/xde
Illumos is based on Solaris, not BSD.
I believe it's a microkernel, so in the sense that every driver is a separate userspace process, yes.
That’s not true. BSD (including all the existing flavors/descendants AFAIK) has a monolithic kernel.
Perhaps you’re confusing it with XNU? (Which is Mach merged with some BSD stuff).