Redox OS (the Unix-like microkernel OS written in Rust) is working on a native Coreboot payload along with bug fixes and a new release.
Lead Redox OS developer Jeremy Soller tweeted that "it's time for Redox OS to become a Coreboot payload." It looks like Redox OS is working on native Coreboot payload support for this interesting Rust operating system rather than first needing to use one of the bootloaders as a Coreboot payload before hitting Redox OS.
[...] The Redox OS twitter also went on to outline they are working on fixes to their networking stack, fixes to curl / cargo / git, advancing towards the state of being able to self-host itself (build Redox OS on Redox OS), improving the relibc C library implementation, porting more applications to running on Redox OS, and at that point to also prepare a new release. And, yes, exploring Coreboot payload capabilities.
Previously: Microkernel, Rust-Programmed Redox OS's Devs Slam Linux, Unix, GPL
Related Stories
There's a new operating system that wants to do away with the old mistakes and cruft in other operating systems. It's called Redox OS and is available on GitHub. It's aimed at creating an alternative OS that is able to run almost all Linux executables with only minimal modifications. It features a pure ecosystem using the Rust programming language which they hope will improve correctness and security over other OSes. They are not afraid to prioritize correctness over compatibility. The philosophy being that "Redox isn't afraid of dropping the bad parts of POSIX while preserving modest Linux API compatibility."
Redox levels harsh criticisms at other OSes, saying "...we will not replicate the mistakes made by others. This is probably the most important tenet of Redox. In the past, bad design choices were made by Linux, Unix, BSD, HURD, and so on. We all make mistakes, that's no secret, but there is no reason to repeat others' mistakes." Not stopping there, the Redox documentation contains blunt critiques of Plan 9, the GPL, and other mainstays.
Redox OS seems to be supported on the i386 and x86_64 platforms. The aims are microkernel design, implementation in Rust language, optional GUI — Orbital, newlib for C programs, MIT license, drivers in userspace, common Unix commands included, and plans for ZFS.
They want to do away with syscalls that stay around forever and drivers for hardware that, for a long time, simply isn't possible to buy any more. They also provide a codebase that doesn't require you to navigate around 25 million lines of code like Linux.
Perhaps the mathematically proven L4 microkernel is something to consider over the monolithic kernel approach where any single driver can wreck the system? One aspect to look out for is if they map the graphic cards into user space.
Version 0.5 of Redox OS was released yesterday, which includes a new C library written in Rust and images based on new bootloaders for both coreboot and EFI.
It's taken a while since the previous release of Redox OS as they have been focusing their attention on Relibc, a C library implementation written within the Rust programming language. Relibc is now used as the operating system's default C library.
Redox OS 0.5 also includes improvements to its event system, Pthreads support was completed, better support for LLVM and LLVM-using projects like Mesa/LLVMpipe, improvements to EFI, and more.
Some new Rust-written packages for Redox OS include OpenGL wrappers, an audio library, and other additions. Outside of the Rust scope, Redox OS 0.5 adds in SDL2 packages, Cairo, FFmpeg, and many other important software options.
You can find the Redox OS 0.5 release notes here, and can find the 0.5.0 images here.
Previously: Redox OS Exploring Coreboot Payload
Microkernel, Rust-Programmed Redox OS's Devs Slam Linux, Unix, GPL
(Score: 3, Interesting) by MichaelDavidCrawford on Monday February 25 2019, @06:19AM (7 children)
-boot?
If you support Multiboot then GNU grub needs nothing else to boot your OS. I expect there's a UEFI Application that supports any Multiboot kernel.
Yes I Have No Bananas. [gofundme.com]
(Score: 2, Informative) by Anonymous Coward on Monday February 25 2019, @07:21AM
Coreboot is at the lowest level. It loads from the bootblock, finds itself in the ROM, initializes the RAM, and then executes the firmware payload, i.e. the BIOS/UEFI level. It can be set to fire off all sorts of payloads, and it is the payloads responsibility to finish setting up the hardware and then running the next step of the boot process (such as checking the MBR, in the case of a BIOS payload, like SeaBIOS). The most common payload is probably SeaBIOS, but there are UEFI and Open Firmware payloads too. There are also stacked payloads, like the GNU GRUB or iPXE payloads, which are actually those bootloaders booted directly from RAM by the true payload, rather than following the rest of the normal boot process used to normally launch them.
(Score: 3, Interesting) by driverless on Monday February 25 2019, @09:30AM (5 children)
But then it continues:
In other words "we're addressing Linux and the BSD's only, if you're not in that group, fuck you". With language like that directed at them, it pretty much means no-one outside that group will even try and implement it, which in turn kinda limits its applicability as a multi-boot format.
I don't mean that as an attack on the concept, more a resigned sigh at ideologically-motivated stuff doing a good job of shooting itself in the foot again.
(Score: 2, Interesting) by Anonymous Coward on Monday February 25 2019, @03:35PM
I wish I understood what all the differences are. I don't lnow a coreboot payload from a rootkit. Both sound like I don't want it. "Coreboot" even makes me suspicous in the way that non-profits that call themselves 'freedom' or 'liberty' or 'patriot' are usually one-issue groups seeking to erode the rights of other people. Coreboot in the same way feels like it really means pull shit from a cloud and lock the user out of it because safety.
I am probably wrong, but I am familiar with the whole 'fuck you' mentality in the disparate linux cliques. Maybe that is why it makes me think of those non-profits.
(Score: 1, Insightful) by Anonymous Coward on Monday February 25 2019, @04:26PM (1 child)
Today.
They have to start somewhere, and start with something small enough that they can build it successfully. There is nothing preventing them from expanding beyond this feature-set once it's built and running. The attitude that it has to have EVERYTHING all at once is limited and not helpful.
(Score: 3, Informative) by driverless on Tuesday February 26 2019, @12:01AM
Look at the dates on that document. They started somewhere twenty-four years ago. That document has since grown up, enlisted in the military, served its country overseas, returned, gone to college on the GI bill, met and married a cute PDF from freshman year, and is now raising little documents of its own.
I understand the principle of starting slowly, but the next step after that should be "gradually speed up", not "stop" (meaning "not spread beyond it's initial 24-year-old target set, the Linux/BSD/*nix set of OSes". It lives on because it's the format used for Grub, but it's the tail wagging the dog now, Grub is the driver, not the document).
(Score: 0) by Anonymous Coward on Monday February 25 2019, @10:10PM
yes, fuck proprietary OSes. why should anyone give a flying fuck about them?
(Score: 2) by DeVilla on Friday March 01 2019, @07:51PM
I took it to mean they'd submit patches to systems they can. If a project is more caught up in process than patches, then they don't have time for that. And well, there is no patching a proprietary kernel.
(Score: 0, Flamebait) by Anonymous Coward on Monday February 25 2019, @08:37PM
Do you still need skinny jeans, a fedora, facial hair and tattoos to run it?
(Score: 0) by Anonymous Coward on Monday February 25 2019, @11:00PM (1 child)
Count me in.
(Score: 3, Funny) by driverless on Tuesday February 26 2019, @12:12AM
Me too, I'd be happy to see systemd rusting somewhere in a corner.
(Score: 1, Insightful) by Anonymous Coward on Tuesday February 26 2019, @01:44AM
It may have its problems as a language, but the way it handles memory management is intriguing. The important bits like referencing and borrowing can be done with C++ std lib afaik, so it's like a fresh start without the cruft.
(But also without an ecosystem sans C bindings.)