Redox OS Porting More Linux Software Over, Including COSMIC Apps

[skeevy420]

I see. But it's not really right to lump it all in with the concept of Linux compatibility IMO. You are talking about the whole stack a program uses, which of course is harder to support easily. A program can also be written directly for Linux.

They're lumped together because very few programs run with JUST the kernel. Most things expect there to be a C library, something equivalent to the GNU tools, and a shell. While those kinds of kernel-only programs do exist, they're more the exception than the rule and rather moot in regards to this discussion since the article is about them porting things like the COSMIC desktop and GUI text editors which expect the whole stack of libraries and supporting software to be there.

It's how the supporting libraries and software are there and accessed that matters here.

It seems like what they're doing is closer to the OpenZFS Linux compatibility layer or what Haiku does than what FreeBSD does. The Redox C library has already been adapted to work with how Redox and Linux access stuff. It looks like their window manager already has X11 and Wayland backends. It seems like they gotta do the nitty-gritty things like per-program fixes, better Redox support with compilers, and things of that nature.

Vistaus The Haiku stuff works through X11 and Wayland compat layers that translate it over to how the Haiku WM does it. In regards to KDE programs, it's because there's an unofficial port of QT to Haiku so QT stuff doesn't have to use those layers. If GTK2-5 had an unofficial port to Haiku, GTK programs wouldn't have to use the X11 or Wayland compat layers, either. WINE originally ran through the X11 layer but now has had enough upstream commits that it supports Haiku's native windowing system.

[skierpage]

they have changed their resource path format to be more Linux-compatible with a file-like scheme

Just rewrite linux in rust then...

No, every file path still includes or implies the scheme (the https thing in front of the colon in a URL/URI). Developers just changed the syntax so that they don't have to spend a lot of time patching assumptions in programs and libraries, for example that "http://foo.com/the/path" is a relative file location.

From the Redox post

In order to simplify our efforts to port Linux software to Redox, we have decided to change our resource path format to the Linux-compatible /scheme/scheme_name/path/to/resource. Paths that do not begin with /scheme will be assumed to refer to the file scheme, so /path/to/my_file is treated by the system as /scheme/file/path/to/my_file, but the application will only see the /path/to/my_file portion. Using this format, normal paths now look just like Linux paths, while drivers and other resources can still be addressed without breaking software.

[CochainComplex]

Considering how well AI is progressing it might be just a matter of time telling it hey please translate it to rust. there is more or less not much creativity involved. the scope must be big enough to grasp the caveats of both languages thats it. since the linux kernel is quite modular starting with the basics will also reduce the loc a lot.

[rmfx]

It's a bit sad that they drop their original url concept by pragmatism.
I think Linux is becoming bloated and too complex, and light and modern projects such as a rust microkernel OS are the way to explore.
Unfortunately, compatibility always goes in the way of real drastic improvements, and is needed for the first steps of expansion.
And that's why in the end we still rely on dinosaurs such a C and x86 when obvious better solutions exist.

What's not sad is to see Cosmic DE taking shape on top of Redox though.

[oleid]

It's a bit sad that they drop their original url concept by pragmatism.

Technically, it is still there. Just the URL is encoded in the path.