The Current State & Plans For Porting Linux/BSD Software To Redox OS

[phoronix]

Phoronix: The Current State & Plans For Porting Linux/BSD Software To Redox OS

A new blog post was posted by the Redox OS team that is working on their Rust-written micro-kernel designed open-source operating system. Their latest post lays out their porting strategy for getting more Linux and BSD user-space software running on this Rust-based OS...

https://www.phoronix.com/news/Redox-OS-Porting-Plans

[clementhk]

If they could get freedesktop sdk and maybe mesa running on it I would for sure be very interested.

[mirmirmir]

Like what is this? First they said they want to make everything an url, then make devices path like Linux, then sya they don't want programs use translation layers while also porting emolators.

And the conclusion at the end is like *chef's kiss*

[muncrief]

Of course the philosophy of a microkernel has always been appealing, but though numerous projects have tried the problem of context switching induced performance degradation has always prevented them from coming to fruition.

And what concerns me about Redox OS is that even though it's been in development for 9 years the architectural documents, while acknowledging this problem, still state that "Unfortunately, Redox isn't quite there yet. We still have a relatively slow kernel since not much time has been spent on optimizing it." Here's link to the microkernel system design portion of their documentation: https://doc.redox-os.org/book/ch04-01-microkernels.html

This has always surprised me, as solving the context switching overhead problem must be the very first thing a viable microkernel architecture overcomes. And yet it seems that Redox OS has always worked on everything but that, building code for years on top of a microkernel that has not yet solved the critical fundamental problem that doomed all others.

[pabloski]

Of course the philosophy of a microkernel has always been appealing, but though numerous projects have tried the problem of context switching induced performance degradation has always prevented them from coming to fruition.

QNX has been around since the '80s and it is used in critical mission systems. seL4 is probably running happily right now on your smartphone's baseband processor and a bunch of smart cards for every conviceable use.

So the problem isn't with microkernels, but with market dynamics. This is the reason why no BSD, Linux, etc... have been able to dethrone Windows from the PC.

"Unfortunately, Redox isn't quite there yet. We still have a relatively slow kernel since not much time has been spent on optimizing it."

This looks more like a problem with optimizations in general than with its microkernel nature. Linux was unoptimized too, then legions of programmers and companies arrived and optimized it. As long as ReactOS remains a hobbyst project, no one will have the time, expertise and patience to truly optimize it.

This has always surprised me, as overcoming the context switching overhead problem must be the very first thing a viable microkernel architecture overcomes.

If the designers have the expertise and time. Context switching overhead in microkernel systems is a tricky problem and involves the message passing architecture, the granularity of the user-land servers, the policies for handling interrupts and scheduling. The big problem is that if they mess it up from an architectural pov, they will end up like Mach!!

[FedFer]

then sya they don't want programs use translation layers while also porting emolators.

And the conclusion at the end is like *chef's kiss*

They said they are not planning to implement translation layers such as Wine to run programs compiled for other OS (like Linux or Windows), emulators are much different as they're not just translation layers but an emulation of a whole set of hardware.

[ALRBP]

Redox OS is just a hobby, won't be big and professional like Linux.

[andyprough]

And what concerns me about Redox OS is that even though it's been in development for 9 years the architectural documents, while acknowledging this problem, still state that "Unfortunately, Redox isn't quite there yet. We still have a relatively slow kernel since not much time has been spent on optimizing it." Here's link to the microkernel system design portion of their documentation: https://doc.redox-os.org/book/ch04-01-microkernels.html

This has always surprised me, as solving the context switching overhead problem must be the very first thing a viable microkernel architecture overcomes. And yet it seems that Redox OS has always worked on everything but that, building code for years on top of a microkernel that has not yet solved the critical fundamental problem that doomed all others.

Too bad, sounds like it won't ever be a viable Linux or BSD kernel alternative then.

[Quackdoc]

Redox OS is just a hobby, won't be big and professional like Linux.

as far as I know, it's not, while I don't know the point of it, apparently they get some pretty decent funding every now and then to push it along

[Volta]

QNX has been around since the '80s and it is used in critical mission systems. seL4 is probably running happily right now on your smartphone's baseband processor and a bunch of smart cards for every conviceable use.

SeL4 isn't general purpose kernel, but serves as some layer. Qnx is also not comparable to Linux or BSD in any way. Outside of their shallow scope they're just toys.

So the problem isn't with microkernels, but with market dynamics. This is the reason why no BSD, Linux, etc... have been able to dethrone Windows from the PC.

You're mixing different things. Microkernels are the problem. They're unusable in serious and performance related tasks. Don't mention mission critical systems. Their tasks are very simple there. General purpose kernel like Linux being used in mission critical systems means much more.

This looks more like a problem with optimizations in general than with its microkernel nature. Linux was unoptimized too, then legions of programmers and companies arrived and optimized it. As long as ReactOS remains a hobbyst project, no one will have the time, expertise and patience to truly optimize it.

What?!