SoylentNews is people
SoylentNews
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
(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.