From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
Why not make Ubuntu a ~~GNU/~~ Redox distribution at that point?
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/sudoers and 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 still su.
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
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 park~~ kernel with ~~blackjack and hookers~~ memory and thread safety, like Redox.
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.
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.
This will delay Hurd by another 40 years
There's RedoxOS already.
ew MIT license
¯_(ツ)_/¯ 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.
it's also a microkernel, double ew
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.
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.
goddamit 😔
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.