Hacker News Reader

Comment by kbr | Hacker News Reader

I've been seeing Redox develop for a while now, and I've got to say—it's really amazing what such a small group of people can accomplish. They have innovative tools in all sorts of areas of computer science. Including coreutils, binutils, a shell (along with a custom shell scripting language), common GUI applications, a hash function, a file system, etc.

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.

View on HN

I’ve always found it weird that things like file systems in the Linux kernel are so tightly coupled. Why isn’t, say, Ext4 written like a library? (Or is it? I don’t think it is?)

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.

This already done. FUSE

This is the recurring argument about "monolithic kernels" vs "microkernels". In the latter different user-space processes can be used to implement filesystems, networking, etc.

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.

Notably, NetBSD has recently undergone a successful effort to implement such a decoupling of subsystems, while still remaining a monolithic kernel. Lo and behold, it immediately boosted the ecosystem of hobbyist FOSS OSes, by letting them easily reuse chosen subsystems (see e.g. Haiku, GenodeOS). It also certainly helped that NetBSD is BSD-licensed. If you want to learn more about the effort, search about "rump kernel".

It's also not just about monolithic Vs microkernel: Linux could decouple filesystem drivers without becoming a unikernel e.g. by specifying a fixed driver API - you could just load FSs as kernel modules. The reason for tight coupling is just that devs don't want to commit to a stable API. If you are only talking about a single kernel version, FS drivers actually _are_ decoupled this way (can be loaded as modules) and distributors do this.

Decoupling is not the strongest suit for Linux developers however as somebody pointed out there is already other projects to enable user land FS.

I feel this statement is a bit unfair. Much of the tight coupling has been a design decission. There has been a lot of public discussion about it.

This is fine until optimisations are needed. Most meaningful performance work requires changing data structures which impacts the shape of the interface.

One reason is that it helps keep Linux free by making it harder to pull code out of the tree or maintain out-of-tree drivers, which encourages people to contribute their changes upstream.

Doesn't the GPL ensure this?

You can write kernel drivers that are not GPL, which is difficult with the continuously changing internal kernel API.

I agree -- I've been somewhat negative about Rust, but it looks like Redox is one of the projects doing "real work" with it. It's an impressive vote of confidence for the language.

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/

Beautiful project- and home page!

What does "word splitting" mean in this context?

Word splitting is the difference between

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

and

    $ python "$var"

You need double quotes to protect against word splitting. Almost all shell tutorials guides hammer this point home repeatedly, because if you omit double quotes, it works most of the time, and then blows up with incomprehensible error messages when you have spaces.

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

Curious, what makes you think Rust isn't be used for "real work"? So far there's a high performance browser (servo + servo components in FF), kernel (Redox), parallelism library (Rayon), grep replacement (ripgrep), all written in Rust, that are somewhere near best-in-class (Redox is debatable but that's mostly due to the fact that the success of an OS requires many non-technical factors).

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

Webrender, the next gen rendering/compositing engine for Servo, will become the default renderer for Firefox Nightly at the end of this year and several components like CSS and URL parsing have been in Firefox stable for a while now. That alone puts Rust in the multi-million end user club for some complicated software

Reply on news.ycombinator.com