Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Monday February 25 2019, @05:34AM   Printer-friendly [Skip to comment(s)]
from the not-redux dept.

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


Original Submission

Related Stories

Microkernel, Rust-Programmed Redox OS's Devs Slam Linux, Unix, GPL 34 comments

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.


Original Submission

Redox OS 0.5 Released 15 comments

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


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 3, Interesting) by MichaelDavidCrawford on Monday February 25 2019, @06:19AM (7 children)

    by MichaelDavidCrawford (2339) Subscriber Badge <mdcrawford@gmail.com> on Monday February 25 2019, @06:19AM (#806227) Homepage Journal

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

    Every operating system ever created tends to have its own boot loader. Installing a new operating system on a machine generally involves installing a whole new set of boot mechanisms, each with completely different install-time and boot-time user interfaces. Getting multiple operating systems to coexist reliably on one machine through typical chaining mechanisms can be a nightmare. There is little or no choice of boot loaders for a particular operating system — if the one that comes with the operating system doesn't do exactly what you want, or doesn't work on your machine, you're screwed.

    While we may not be able to fix this problem in existing proprietary operating systems, it shouldn't be too difficult for a few people in the free operating system communities to put their heads together and solve this problem for the popular free operating systems. That's what this specification aims for. Basically, it specifies an interface between a boot loader and a operating system, such that any complying boot loader should be able to load any complying operating system. This specification does not specify how boot loaders should work — only how they must interface with the operating system being loaded.

    --
    Yes I Have No Bananas. [gofundme.com]
    • (Score: 2, Informative) by Anonymous Coward on Monday February 25 2019, @07:21AM

      by Anonymous Coward on Monday February 25 2019, @07:21AM (#806242)

      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)

      by driverless (4770) on Monday February 25 2019, @09:30AM (#806259)

      But then it continues:

      This specification is targeted toward free 32-bit operating systems that can be fairly easily modified to support the specification without going through lots of bureaucratic rigmarole [...] It would be nice if proprietary operating system vendors eventually adopted this specification as well, but that's probably a pipe dream.

      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

        by Anonymous Coward on Monday February 25 2019, @03:35PM (#806329)

        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)

        by Anonymous Coward on Monday February 25 2019, @04:26PM (#806368)

        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.

        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

          by driverless (4770) on Tuesday February 26 2019, @12:01AM (#806684)

          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.

          Today.

          They have to start somewhere

          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

        by Anonymous Coward on Monday February 25 2019, @10:10PM (#806611)

        yes, fuck proprietary OSes. why should anyone give a flying fuck about them?

      • (Score: 2) by DeVilla on Friday March 01 2019, @07:51PM

        by DeVilla (5354) on Friday March 01 2019, @07:51PM (#808886)

        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

    by Anonymous Coward on Monday February 25 2019, @08:37PM (#806549)

    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)

    by Anonymous Coward on Monday February 25 2019, @11:00PM (#806641)

    Count me in.

    • (Score: 3, Funny) by driverless on Tuesday February 26 2019, @12:12AM

      by driverless (4770) on Tuesday February 26 2019, @12:12AM (#806690)

      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

    by Anonymous Coward on Tuesday February 26 2019, @01:44AM (#806717)

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

(1)