Posts and replies

@solonovamax Just more of the same.

If you want the literal latest update, just a couple days ago FDo staff deleted/privated Luna's GitLab request to insert her projects into FDo to silence discussion about her abuse and the missteps of FDo leadership that was being brought up in the comments. Not locked, outright hidden from public view like the discussion never existed.

@lina ough, yeah I read through some of it

genuine question, but have you ever considered suing for libel/etc.?
because, something like that could very well shut her up if she learns that spreading lies about you can have greater consequences
though there are ofc reasons to not want to do it, so I get if you considered it but decided against it

@solonovamax I'm in talks with lawyers.

@lina I wish you the best of luck with that, then

@xpayn I haven't seen a Rust kernel project aiming for Linux compatibility both for userspace API/ABI and for a subset of major Linux driver classes (especially USB, PCIe, etc. as an interim solution to lack of native drivers for the wide variety of user-pluggable hardware).

I think those two are practical requirements for such a project to have a chance at being a successor to Linux. Otherwise it will never gain enough momentum to catch up.

@lina @xpayn I had high hopes for https://www.redox-os.org/de/news/revirt-1/#:~:text=Running%20applications%20and%20drivers%20on%20Redox%2C%20that%20are%20supported%20only%20on%20Linux but it seems to be dead and the dev driving it has disappeared :( Using Linux as a 'rump kernel' just for its drivers would be great!

@koakuma @xpayn It becomes a deprecated interim solution when the new kernel actually achieves adoption that surpasses Linux, and starts having more development effort put into it than Linux does.

Until then yeah, it's an interim but permanent solution. The point I'm trying to make is that to have a fighting chance of displacing Linux, you need that (hopefully) interim solution.

@koakuma @xpayn That said, any new project like that would have significant architectural and development model advantages over Linux (because Linux is an aging design written in an aging and no longer appropriate programming language with an aging and ossified community and aging and developer-hostile processes), so a successor doesn't need to actually reach the point of having person-hour parity with Linux to reach the tipping point.

There's a built-in, constant ish factor advantage such a project would have there, because one hour of work put into it would be significantly more productive than one hour of work put into Linux. So it's not as impossible as it may seem.

(The obvious example here would be that just by using a better programming language, I achieved way better development efficiency writing a GPU driver than anyone else ever had in Linux. Even though I had to fight the underlying C codebase.)

But yeah, you need to steal the drivers from Linux to make it useful in the first place without summoning a huge team from thin air, that's what gets people interested enough to form a positive feedback loop.

@lina @koakuma @xpayn That is an interesting point! I think a lot of the alt OS projects try to write all the drivers themselves, which as you point out is a mistake. Better to use Linux drivers initially and rewrite them later if the resources to do so become available.

One big problem with this is going to be keeping up with security updates. Smaller drivers hopefully don’t get very many, but things like Wi-Fi and graphics are going to be annoying. The Asahi driver is probably going to be an exception, because it is written in Rust and so doesn’t have all the memory unsafety vulns the others do!

@alwayscurious @koakuma @xpayn I think the right approach there is to aim for isolation in some form, so for example all Linux drivers are confined to an address space (or multiple) and faults there can't affect the rest of the OS.

Obviously that isn't perfect but it eliminates the SPOF nature of a memory safety vuln there, as the impact becomes less and less the more drivers are ported/rewritten.

@lina @koakuma @xpayn I agree. There are some devices whose drivers must be trusted, because they can have negative system-wide effects. Fortunately, most of these are internal devices and therefore not externally-accessible attack surface.

@koakuma @alwayscurious @xpayn This is how DriverKit works on macOS as far as I understand it. Drivers run in userspace.

@tauon @koakuma @xpayn Oh I'm not talking about micro/monolithic. The real answer to that question is "both/neither" because reality is subtle. And monolithic kernels are actually a better idea these days than in the past, when you consider safe languages like Rust that eliminate UB by default.

I'm just saying Linux has a lot of tech debt.

@lina@vt.social @koakuma@uwu.social @xpayn@mastouille.fr that's also true. especially if you're still trying to be compatible with a system made in the 70s. i'm trying to prevent my conspiracy devil on my shoulder from writing something like "there are people in the free software community trying to prevent progress" but i dunno things line up if you look at them a certain way

@tauon @koakuma @xpayn It's kind of the age old conservatism issue isn't it. People get older and are incapable of letting go of control.

@shironeko @xpayn You don't even need hardware virtualization, UML is a thing. There are various ways to "plug in" Linux drivers into a non-Linux OS.

@shironeko @xpayn UML runs on anything that can provide the Linux system call interface, which need not be Linux. If you are already implementing that interface for compatibility with userspace apps, then UML should run on it.

UML could also be ported to run on other host environments.

The point is you don't actually need/want full fat HW virt for this. Just an environment that can run the code (and you're allowed to change the code).

@Shadow_Glider @huwr I... um...

https://www.osnews.com/story/143060/debian-gnu-hurd-2025-released-with-rust-64bit-support-and-more/

Allow me to be slightly skeptical of a kernel that's as old as Linux and only *just* got 64-bit and CD-ROM support...... and SMP.

Also that's userland Rust, though maybe since it's a microkernel that doesn't matter, but I don't know if they have scaffolding to write drivers in Rust...

(And also, I have little reason to believe GNU is any better than FDo)

@lina Fair, but I think development has picked up recently (though it's hard to really tell)

Don't really know kernels like you so can't say anything meaningful about that

Understandable that you wouldn't join a new project before knowing that it has good policy enforcement given how FDo has gone for you. I know NixOS is quite good with it but that's just a distro and I know that you do more kernel things, I hope at least FDo can fix its issues so that won't happen anymore. EDIT: [There's actually a project to port NixOS to apple silicon, and it uses a lot of things from Asahi Linux, this seems like something right up your alley if you ever feel like working on kernel-y things again with a healthier community](https://github.com/nix-community/nixos-apple-silicon)

@Shadow_Glider It's not practically possible to work on kernel things without interacting with upstream, and I'm too traumatized to ever touch the kernel again...

The NixOS stuff is just a distribution of Asahi Linux like all the others, it doesn't replace the upstream community problems... they don't do any kernel dev, it's just integration.