4 ms·

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 d

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.

cogman10 2y ago
> 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).
- yjftsjthsd-h 2y ago
  > 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)
  - cogman10 2y ago
    > 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.
    - yjftsjthsd-h 2y ago
      Mesa: There are official freebsd packages of mesa: https://ports.freebsd.org/cgi/ports.cgi?query=mesa-&stype=all&sektion=all https://ports.freebsd.org/cgi/ports.cgi?query=mesa-&stype=al... In fact, https://doc.redox-os.org/book/graphics-windowing.html https://doc.redox-os.org/book/graphics-windowing.html seems to imply that redox is or plans to use mesa. Android: Okay, that's fair; termux already proved that GNU on Android is viable.
  - yellowapple 2y ago
    > 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 https://man.openbsd.org/drm.7
- kllrnohj 2y ago
  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.
School-Cotton 2y ago
> 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.
- Octoth0rpe 2y ago
  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.
  - School-Cotton 2y ago
    Tons of dev workflows nowadays use docker which in practice means they require Linux.
    - kayodelycaon 2y ago
      Docker works fine on macOS today. But it was definitely bad before they fixed the host file system integration. And by bad, I mean really bad. At this point, it’s really about what trade-off you’re willing to make. Do you want a better graphical interface or better docker integration?
      - mschuster91 2y ago
        > Docker works fine on macOS today Because it runs a Linux VM at a considerable overhead and serious issues if you want anything more detailed in networking than `-p 8080:8080`.
      - School-Cotton 2y ago
        If you want to run Linux in a VM, you can already do that without needing asahi.
surajrmal 2y ago
They would need to completely reset to do that. Do BSDs even have rust support for their drivers?
- throwway120385 2y ago
  I believe it's a microkernel, so in the sense that every driver is a separate userspace process, yes.
  - School-Cotton 2y ago
    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).
- gpm 2y ago
  For what it's worth, the Oxide Computing people have written illumos driver(s) in rust: https://github.com/oxidecomputer/opte/tree/master/xde https://github.com/oxidecomputer/opte/tree/master/xde
  - School-Cotton 2y ago
    Illumos is based on Solaris, not BSD.
Thaxll 2y ago
If you don't use Linux it will end up as a dead project, no one is going to use redox.
- deleted 2y ago
  [deleted]
margana 2y ago
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.
- richardwhiuk 2y ago
  The author addressed that in the article.
- rcxdude 2y ago
  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.
- ActorNightly 2y ago
  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.
  - School-Cotton 2y ago
    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.
    - ActorNightly 2y ago
tcmart14 2y ago
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.

cogman10 2y ago

> 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).

yjftsjthsd-h 2y ago
> 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)
- cogman10 2y ago
  > 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.
  - yjftsjthsd-h 2y ago
    Mesa: There are official freebsd packages of mesa: https://ports.freebsd.org/cgi/ports.cgi?query=mesa-&stype=all&sektion=all https://ports.freebsd.org/cgi/ports.cgi?query=mesa-&stype=al... In fact, https://doc.redox-os.org/book/graphics-windowing.html https://doc.redox-os.org/book/graphics-windowing.html seems to imply that redox is or plans to use mesa. Android: Okay, that's fair; termux already proved that GNU on Android is viable.
- yellowapple 2y ago
  > 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 https://man.openbsd.org/drm.7
kllrnohj 2y ago
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.

School-Cotton 2y ago

> 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.

Octoth0rpe 2y ago
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.
- School-Cotton 2y ago
  Tons of dev workflows nowadays use docker which in practice means they require Linux.
  - kayodelycaon 2y ago
    Docker works fine on macOS today. But it was definitely bad before they fixed the host file system integration. And by bad, I mean really bad. At this point, it’s really about what trade-off you’re willing to make. Do you want a better graphical interface or better docker integration?
    - mschuster91 2y ago
      > Docker works fine on macOS today Because it runs a Linux VM at a considerable overhead and serious issues if you want anything more detailed in networking than `-p 8080:8080`.
    - School-Cotton 2y ago
      If you want to run Linux in a VM, you can already do that without needing asahi.

surajrmal 2y ago

They would need to completely reset to do that. Do BSDs even have rust support for their drivers?

throwway120385 2y ago
I believe it's a microkernel, so in the sense that every driver is a separate userspace process, yes.
- School-Cotton 2y ago
  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).
gpm 2y ago
For what it's worth, the Oxide Computing people have written illumos driver(s) in rust: https://github.com/oxidecomputer/opte/tree/master/xde https://github.com/oxidecomputer/opte/tree/master/xde
- School-Cotton 2y ago
  Illumos is based on Solaris, not BSD.

Thaxll 2y ago

If you don't use Linux it will end up as a dead project, no one is going to use redox.

deleted 2y ago
[deleted]

margana 2y ago

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.

richardwhiuk 2y ago
The author addressed that in the article.
rcxdude 2y ago
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.
ActorNightly 2y ago
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.
- School-Cotton 2y ago
  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.
  - ActorNightly 2y ago

tcmart14 2y ago

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.