Rust-Written Redox OS Closer To Self-Hosting

[microcode]

It's not special syntax in Ion. Ion supports namespaces, which are denoted with a pair of colons. Currently, there exists two namespaces: color, and env. c is also shorthand for the color namespace, so there's no need to write the full namespace. The value that follows is the variable/constant/function that is being called from that namespace. Due to the nature of how ANSI codes are handled, the color namespace supports commas for specifying multiple values to grab from the inner tables when piecing together the complete ANSI code sequence.

We also support an official git plugin, which when installed, adds a new git namespace, and supports three accessible variables: branch, untracked_count, and modified_count. The command,

echo ${git::branch}

, would simply execute the branch function from within the git library, and get the result of that function back as a string, if possible. I may also be adding some support so that plugins may do similar actions as the color namespace, if their index function specifies a certain keyword.

For functions that can accept arguments, you should look into methods. That is their purpose:

$function(input, arg1 arg2)

The idea is that $function designates to the shell that we are going to execute a string method of that name, where a string method returns a string. The input element can either be a reference to a string variable, or an expression. Methods may treat array expressions differently than string expressions. Finally, the `arg` values will control the behavior of the method. Example:

echo $len(stringvar)
echo $len(@arrayvar)
echo $len($(cmd))
echo $len([one two three])
echo $len("string")

We can tell that an array is being passed into a function if there is an expression that begins with either '@' or '['. Everything else is a string.



If you mean being able to control the values within a braced string expansion, that's not supported at the moment, but it will be soon.

Clever feature, I can see a lot of good use cases for that. Thanks for laying all of that out. :- )

[spike411]

The architecture of the system looks awesome!
I still wish they just went with Wayland for their GUI needs. :/ Maintaing extra platform support in Qt, Gtk and other toolkits doesn't seem very feasible.
(And yeah, the Wayland camp seriously needs to step up their remote display game (define some common protocol), but X11 network transparency is just a myth by modern standards: No way to join a running session? Session and all your work is lost when the network connection is lost? What a joke, even Windows/RDP does this better!)

[wizard69]

Agreed, but that's why we traditionally use microkernels - so modules don't corrupt each others memory, right?

First I honestly believe nothing is crash safe. Rust may be far better at generating programs than some languages but that doesn't mean hackers won't find weaknesses.

As for Micro Kernels you have a number of features they provide.

There sure are other isolation issues, but I'm pretty sure that those can be handled at compile time or other lean language-level mechanics while still maintaining expressive turing-completeness.

As suggest by somebody else above we will see when a stable release is achieved. Otherwise why get too wrapped up in something half done.

[mmstick]

First I honestly believe nothing is crash safe. Rust may be far better at generating programs than some languages but that doesn't mean hackers won't find weaknesses.

The thing about Rust is that it forbids undefined behavior -- it's not 'crash-safe', but 'memory-safe'. That helps out with security quite a lot. For example, out of bounds memory accesses immediately result in a crash. It is perfectly safe to crash a program, but it is entirely insecure to continue execution into undefined behavior. Where in C/C++, an out of bounds memory access would carry on without a concern, potentially corrupting data elsewhere or reading data that may contain sensitive information, Rust will instead immediately panic with a proper backtrace. Makes it much easier to debug and resolve the issue on the programmer's side of things.

[mmstick]

The architecture of the system looks awesome!
I still wish they just went with Wayland for their GUI needs. :/ Maintaing extra platform support in Qt, Gtk and other toolkits doesn't seem very feasible.
(And yeah, the Wayland camp seriously needs to step up their remote display game (define some common protocol), but X11 network transparency is just a myth by modern standards: No way to join a running session? Session and all your work is lost when the network connection is lost? What a joke, even Windows/RDP does this better!)

I'd think it's still possible to go with a Wayland solution. However, it's going to be unavoidable that future GUI toolkits will arise from Rust. GTK has a lot of baggage, and isn't simple at all to port to other platforms. Qt is written in C++, which is a problem in itself. The same concern in every language forum I've frequented has been the need for a better GUI toolkit that's cross-platform, zero dependencies on C++, and isn't GTK. Rust is a good candidate for that, and should we settle upon a GUI TK, it will likely be built to modern architecture standards, which means simplicity in implementation and highly portable. Whether it will be OrbTK or something else, I'm not sure.

[tajjada]

I'd think it's still possible to go with a Wayland solution. However, it's going to be unavoidable that future GUI toolkits will arise from Rust. GTK has a lot of baggage, and isn't simple at all to port to other platforms. Qt is written in C++, which is a problem in itself. The same concern in every language forum I've frequented has been the need for a better GUI toolkit that's cross-platform, zero dependencies on C++, and isn't GTK. Rust is a good candidate for that, and should we settle upon a GUI TK, it will likely be built to modern architecture standards, which means simplicity in implementation and highly portable. Whether it will be OrbTK or something else, I'm not sure.

Yes, but it would still be nice to be able to compile and run the masses of existing software based on GTK and Qt on Redox. If the Redox desktop was based on Wayland protocols, then GTK/Qt software would be easy to use (require minimal porting effort). Of course, any futuristic Rust-based GUI toolkit will need to have support for Wayland, too (to support Linux desktops, for cross-platform compatibility), so naturally it would work well on Redox as well, if Redox was based on Wayland. In any case, reducing the amount of Redox-specific work necessary is a win. The alternative is having to implement Redox support in all toolkits to get them to work, which is much harder, and additional work for any new cross-platform Rust toolkit (as it would probably need to support Wayland anyway).

[mbohun]

RedoxOS and Rust are abominations, the sooner they die the better.

[flubba86]

RedoxOS and Rust are abominations, the sooner they die the better.

Care to elaborate? What makes you say that?

[nomadewolf]

RedoxOS and Rust are abominations, the sooner they die the better.

Why?
A brand new OS (not just another distro which is based on something else and brings only a new package manager).
With a brand new Kernel.
And a brand new Shell.
Running on top of a brand new FS.
All written in a brand new language...

And they are actually making progress. You know, not taking decades to show something, like others...


I take my hat off to these guys!

[starshipeleven]

Windows and MacOS are abominations, the sooner they die the better.

Fixed.