One of the coolest aspects of all of these tools are that they aren't exclusive to Redox. In fact, they are rather portable. For example, the new file system (tfs) can run on operating systems other than Redox. One of the team members wrote an "atomic hash table" for it, and it was open sourced as well. It even uses an open source hash function by the same author.

Congrats to the team. Writing an operating system is incredibly hard, and it's great to see something like this written in Rust. I'm a big fan of all of the core contributors, and can't wait to see where Redox goes.

Stub out the interface that the kernel needs, and provide an interface for the bits (reading disk blocks and so on) that the file system needs from the kernel. This way, you can decouple it completely from the kernel, test it independently, port it without forking the code, and then it can easily be used in userland, too.

There are a lot of small operating systems that take the decoupled route - but you'll almost certainly never see them because they're either research-based, or suffer from the problem of most hobbyist operating systems which is "lack of hardware support". Doesn't matter how modern/sexy an O/S is if you cant run it upon your hardware. (Relatedly once you can run it you need software on it too..)

That said there are some compromises available, even with Linux. If you use something like FUSE you can write your own filesystem in 100% user-space - something I've done for a couple of niche applications.

Also, I'll pat myself on the back and say the Ion shell looks nice, because it borrowed some ideas from the Oil shell [1] :) In particular, we talked a fair bit about the array syntax and semantics, and lack of word splitting.

[1] http://www.oilshell.org/

All this in a language that's ~2 years old is pretty impressive.

    $ var='my program.py'
    $ python $var

    $ python "$var"

If you have a filename with spaces, like "my program.py", then python would be invoked with TWO arguments in the first case ["my", "program.py"].

But it will be invoked with single argument in the second case ["my program.py"], which is the correct thing.

I talk about how word splitting is really a hack around the historical lack of arrays in bash here:

"Thirteen Incorrect Ways and Two Awkward Ways to Use Arrays"

http://www.oilshell.org/blog/2016/11/06.html

Please ask any questions or make any comments you have about Redox!

EDIT: I am going to sleep soon. I will be up in 8 hours, 7 A.M. Mountain Time.

1. Could you say your opinion about future of Rust. Will it become mainstream?

2. Pros/cons between Rust and C for system programming?

3. I heard many times that implementation of standart data structures like RBTree, Graphs without recursion traversal in Rust it's very difficult and painful tasks with unsafe hack code. So if i am Rust beginner i should avoid learn this language through implementations my own data structures(BST, AVL, LL, ...)?

*sorry for my English. It is not my native language.

1. I can definitely see its future in drivers, filesystems, codecs (areas where both performance and correctness is required).

2.

+ Rust has fantastic error handling. No null pointers. Mandatory error checking, but with very light syntax.

+ Dependencies and modularization in Rust are soooo much easier than in C.

+ You never have to write `free()` again.

+ Thread-safety can be guaranteed at compile time.

- Significant learning curve. You need to "get" Rust's ownership approach before you even manage to compile a non-trivial program.

- It's still "new", so it may be hard to convince people to use it. C is 45 years old, so it seems like a safe bet (it has flaws, but the flaws are well-known).

3. What Rust calls "unsafe" is what all of C is, so it's never worse than C. The idea is that you carefully implement these structures using raw ("unsafe") pointers, and wrap them in a safe Rust API. This way you need get it right once, and rest of the code doesn't have to worry about breaking things.

I'm not entirely certain that's true. I wrote a useful (to me) cli script and only have the vaguest understanding of how the ownership model works. I think for text processing sorts of tasks, it's not too difficult to use.

The ownership model isn't too bad for strings, but those are easily the most simple way to start using the ownership model. At least for me, getting into the more advanced ownership stuff is a whole different beast entirely.

The only way to change this at the moment is to edit `/etc/passwd`, where they are stored after being encrypted using argon2.

Nitpick: s/encrypted/hashed/

I then rewrote it in 64-bit assembler, for fun.

After learning about Rust, I immediately went to work on Redox. The bootloader and framebuffer initialization code were lifted from the old toy OS's.

What are the potential areas where Redox could be beneficial ? I would love to run on Raspberry pi, older Androids or Routers etc. Is it doable?

I'm also curious about the benefits that redox offers vis-a-vis bare metal Linux (Alpine/Void etc)?

Security (Redox' stems form the language, Linux' stems from being widely used). Hackability (smaller, more modern, more hackable language). Simplicity.

> What are the potential areas where Redox could be beneficial ?

To put apps on VMs with a very tight and secure OS underneath.

Hmm. Have you bounced off ideas with the Qubes OS team yet? It could be an option for the core OS/microkernel of Qubes OS.

We still need to do more work on it though.

- 256 MB - Live filesystem

- The rest - Running applications

Also, I ran the ISO in Virtual Box and it's far more than I thought it would be. It's not just a barebones kernel and shell, you actually included a simple window manager and some GUI applications! It booted nice and fast, too.

Great work.

Especially since multiple successors to Unix already exist -- notably, Plan 9 and Inferno.

I encourage the use of checked subtraction and addition to prevent these from becoming issues.

Rust has not impacted development in any negative way. On the contrary, it has been incredibly helpful and has boosted development.

The only thread that I saw was someone decrying that Zircon was written in C++ rather than C, which later turned into a discussion on Rust. I haven't seen any Zircon committers comment on Rust; can you find the link you're thinking of?