Now we just need to rewrite the Linux kernel in Rust
Does it have to be Linux? Some greybeards are pretty opposed to it. I wonder if it would be easier to make our own
theme parkkernel withblackjack and hookersmemory and thread safety, like Redox.This will delay Hurd by another 40 years
Does it have to be Linux?
In order to be a viable general use OS, probably yes. It would be an enormous amount of effort to reach a decent range of hardware compatibility without reusing the work that has already been done. Maybe someone will try something more ambitious, like writing a rust kernel with C interoperability and a linux-like API so we can at least port linux drivers to it as a “temporary” solution.
I remember there being a bit of talk around a Linux driver compatibility layer for Redox in the future, but I can’t find anything about it, so I could be misremembering.
What do you mean by “C interoperability and a linux-like API”, exactly?
- C is pretty much the standard for FFI, you can use C libraries with Rust and Redox even has their own C standard library implementation.
- Linux does not have a stable kernel API as far as I know, only userspace API & ABI compatibility is guaranteed.
C is pretty much the standard for FFI, you can use C libraries with Rust and Redox even has their own C standard library implementation.
Right, but I’m talking specifically about a kernel which supports building parts of it in C. Rust as a language supports this but you also have to set up all your processes (building, testing, doc generation) to work with a mixed code base. To be clear, I don’t image that this part is that hard. When I called this a “more ambitious” approach, I was mostly referring to the effort of maintaining forks of linux drivers and API compatibility.
Linux does not have a stable kernel API as far as I know, only userspace API & ABI compatibility is guaranteed.
Ugh, I forgot about that. I wonder how much effort it would be to keep up with the linux API changes. I guess it depends on how many linux drivers you would use, since you don’t need 100% API compatibility. You only need whatever is used by the drivers you care about.
There’s RedoxOS already.
ew MIT license
it’s also a microkernel, double ew
¯_(ツ)_/¯ GPL of Linux didn’t help Android being more open either. And the driver being implemented in the kernel actually is an obstacle to it, @bunitor.
we’re also sponsoring the uutils project to ensure that some key gaps are closed before we ship 25.10. The sponsorship will primarily cover the development of SELinux support for common commands such as mv, ls, cp, etc.
I didn’t think Ubuntu used SELinux.
Not by default, but you can optionally enable it.
Wrong move. To make sudo more secure, you should instead ditch 90% of the features intended for server which nobody on desktop uses. 150 lines of C code is enough to provide sudo-like functionality on desktop, probably similiar in Rust.
except ubuntu isn’t a desktop-only distro
you might also not be considering corporate workstation in an intranet
They are open to drop some features apparently, but maybe not “90%”
The developers are taking a “less is more” approach. This means that some features of the original sudo may not be reimplemented if they serve only niche, or more recently considered “outdated” practices.
A way smaller alternative therefore less prompt to vulnerabilities is OpenDoas found on Arch/Artix/… and other distros. From the GH project:
doas is a minimal replacement for the venerable sudo. It was initially written by Ted Unangst of the OpenBSD project to provide 95% of the features of sudo with a fraction of the codebase.
Tried it but it is not a 100% compatible as sudo replacment as it lacks some of the args. This means that some programs fail as they attempt to use incorrect args.
I’m curious about which programs if you can share. I write few bash scripts which used to call sudo, and I replace sudo with doas in those. And in case of muscular memory I also added a bash alias so that if by mistake calling sudo in reality I’d be calling doas. So far no issues. O course I don’t use fancy args, and what I really needed from sudo I used to include it in
/etc/sudoersand now on/etc/doas.conf, and I believe I couldn’t include a couple of options but they were not critical since I’ve lived without them so far. And it’s weird to find actual software that requires sudo, perhaps proprietary software. One can actually live without sudo and without doas, as long as there’s stillsu.Not judging, rather curious, actually I’ve met several guys who write scripts which would benefit from using sudo/doas, but they claim better call the scripts through sudo/doas rather than adding them as dependencies.
I don’t remember what it was exactly, I encountered two times where doas failed as a sudo replacement. After that I went back to sudo
what’s the license on sudo-rs, is it MIT like uutils?
Seems like it’s Apache-2.0, but original sudo is under ISC license, which is more permissive as far as I’m aware. Although Apache-2.0 is very much still considered “permissive”, too.
deleted by creator
Why not make Ubuntu a
GNU/Redox distribution at that point?Take all the power away from the end user and give it all to Poettering, NO FUCKING THANKS.
chill
