Rust-Written Redox OS 0.8 Released With i686 Support, Audio & Multi-Display Working

[Vistaus]

What i want to ask is does it run crysis?

No realy whats the goal? Porting Gimp, Blender, Wine? One allready made a sarcastic Steam remark, in the end thats what it boils down to, where is my Chrome browser to Google the Amazon Black Friday Sale highlights ?

It´s all nice and fun that it´s proof of concept for Rust, but when does it benefit the masses? Like Facebock or PayGal ~~ where they used some crap code to make billions of $$$$$

A Wine port could realistically happen. Haiku has an unofficial Wine port now too, so there's no reason it can't be ported to Redox OS.

[mmstick]

A Wine port could realistically happen. Haiku has an unofficial Wine port now too, so there's no reason it can't be ported to Redox OS.

Check this out: https://twitter.com/jeremy_soller/st...05002677215232

Redox OS utilizes relibc for platform support so there's virtually unlimited open source software that can be ported.

[mmstick]

It´s all nice and fun that it´s proof of concept for Rust, but when does it benefit the masses?

The same way that NASA investing a lot of money into space telescopes and exploration has led to major advancements in the everyday life of all of us on the planet. While you set a goal to achieve X, over time you end up researching and developing solutions for A, B, C, and D that were necessary steps towards that goal. Then others see usefulness in utilizing A, B, C, and D in other projects outside of goal X. So whether you are using Redox OS or not, all developments have potential to leak into other spaces over time. This should be common sense to those in open source software communities.

Case in point, some may not even realize it, but the firmware in all open firmware System76 laptops is using Redox-developed libraries. Or say that in the future you're interacting with a GUI application written by a software developer in a Rust toolkit, and as you delve deeper you realize a number of components were developed within the Redox project. Maybe you're using some CLI applications on Linux that happened to be using some Redox-maintained crates. You're seriously underestimating just how much code sharing is happening in the Rust space because of how easy Rust makes it to share open source software.

[Anux]

Funny that you call it hobby project.

Linux started out as a hobby project and no one knows the future till it's present.

[Waethorn]

Yeah, does it run Crysis or not?

If it isn't supposed to run Crysis, then what's the point?

I'm still waiting on an ARM64 build of a Linux distro that has full GPU acceleration of the common GNOME 4x desktop as well as full video acceleration of all web video enabled out-of-the-box without janky browser plugins.

You know - the kind of stuff you could get since Windows Vista.

[Waethorn]

They could go the hybrid route, like Haiku with its FreeBSD driver support.

And Haiku still hasn't been able to get most of those drivers to work yet.

Why not just port out the entire driver tree from the kernel repos then?

[erniv2]

The same way that NASA investing a lot of money into space telescopes and exploration has led to major advancements in the everyday life of all of us on the planet. While you set a goal to achieve X, over time you end up researching and developing solutions for A, B, C, and D that were necessary steps towards that goal. Then others see usefulness in utilizing A, B, C, and D in other projects outside of goal X. So whether you are using Redox OS or not, all developments have potential to leak into other spaces over time. This should be common sense to those in open source software communities.

Case in point, some may not even realize it, but the firmware in all open firmware System76 laptops is using Redox-developed libraries. Or say that in the future you're interacting with a GUI application written by a software developer in a Rust toolkit, and as you delve deeper you realize a number of components were developed within the Redox project. Maybe you're using some CLI applications on Linux that happened to be using some Redox-maintained crates. You're seriously underestimating just how much code sharing is happening in the Rust space because of how easy Rust makes it to share open source software.

This is actually the 1st good post in the hole thread thank you. And i hope that the knowledge will then flow into the Linux kernel with the Rust subsystem

[mangeek]

I think projects like Redox, React, Dahlia, Haiku, Dragonfly, etc. provide a lot of value, regardless of whether they have potential of mass market share. Smaller projects can offer insight and inspiration for mainstream systems. Who knows, maybe RedoxOS will get to a place where they want to start porting lots of drivers over, and then all of the sudden we have all this great memory-safe code to do device driver frameworks that ends up being adopted by Linux. Maybe one of the microkernel-based projects ends up with a Linux compatibility layer that gets us out of a huge security or scalability pickle in the future.

[oleid]

2. Performance, Rust is slow as a snail in real programs compared to C: https://ehnree.github.io/documents/papers/rustvsc.pdf

Really? That source code is a joke. No wonder benchmarks are slow. If they had read any introduction tutorial they would know that indexing an array that way would test for out-of bounds.

Check out these benchmarks, they are more sane. Most of the time C and rust performance is close enough, in others rust wins by a large margin https://benchmarksgame-team.pages.de...ust-clang.html

[erniv2]

Maybe one of the microkernel-based projects ends up with a Linux compatibility layer that gets us out of a huge security or scalability pickle in the future.

Why code a compatibily layer to an existing kernel, instead of coding inside the kernel itself, thats what is waste of time, ah my cpu is buggy, lets code some microcode patches, ah my microcode is buggy, lets code some kernel patches, ah my kernel is buggy lets code some userspace workarounds.

The thing would be get the things right at the 1st place and a microkernel won´t stop bugs from happening i posted this before even with a microkernel if an error happens at a lower layer like caching then all the modules that run on top of it need to be reset and in the worst case the error persist and you need to bluescreen and reboot.

The more layers the more errors, who tells you that a wrapper between cpu microcode and the excution layer can catch the bugs ? It´s more possible to cause a fatal error, or be exploited even more.