I was worried a whole UNIX might be too big a project so I gave him old school recommendations before. Essentially told him to make a split system that lets you run on tiny kernel bare metal, run UNIXy apps with different API, and let them communicate through some IPC mechanism. That way, like security & MILS kernels, people can write security critical components in isolated partitions with checks at interfaces. Already done with Ada and embedded Java. Rust is best one to try it with now.

Far as your recommendations, I like those. I'll add a web server, Redox or UNIX compatible, that's efficient enough to be deployed in all these web-enabled embedded devices. The dynamic part can just be Rust plugins or something. However, just a robust Ethernet stack, networking stack, time API, and simple filesystem could be used to implement all of yours, the web server, and more. So, I encourage people building these OS projects to stay on 80/20 rule hitting features almost all critical things use. Others can jump in at application layer from there.

This may be helpful for the DNS server https://github.com/gtadam/rust-dns

Operating systems aren't that big, and if you know your stuff, I'm sure it's not too hard to pull off. Here's an example I borrowed from StackExchange:

According to cloc run against 3.13, Linux is about 12 million lines of code. 7 million LOC in drivers/, 2 million LOC in arch/, and only 139 thousand LOC in kernel/. (http://unix.stackexchange.com/a/223753)

Edit: Would be nice to have the numbers for the latest Minix release for comparison. Does anybody know how big their core team is? (The kernel is something like 15k LOC IIRC.)

Ours didn't have a GUI. It took us less than a year to write and the team was never larger than 6 people. It's less complicated than it seems at first sight.

There are a lot of things about machines that you need to understand, but the technology itself is relatively well-understood and sane practices are encouraged.

It blows my mind that less than twenty people can string up something non-trivial with Node.js et co.. Operating systems are trivial in comparison.

Wirth and a few others went to Xerox to see their personal computer with GUI that Steve Jobs also envied. They were told they couldn't buy it. "So, I built one..." (Wirth)

http://www.cfbsoftware.com/modula2/Lilith.pdf

Lilith was a custom computer with all kinds of hardware. The mouse eventually inspired Logitech. The software included a safe language (Modula-2), its compiler, an OS (Medos-2), a relational DB, and some other stuff. The trick was safe language, modularity, and simplicity in implementation details. Two or 3 people over a few years.

Later, that turned into the Oberon series of languages, compilers, and OS's. The extensions or ports usually took 1 or 2 students months to a year or two to pull off. Last one they released IIRC was A2 Bluebottle OS. Primitive, but usable. I keep telling people to rewrite it in other safe, C alternatives to save them work. Students got it done fast so I'm sure hobbyists could too.

https://github.com/Ignat99/a2

it's actually a pretty common task in undergrad CS programs for an individual or a small group (3-4 students) to write an *nix-like OS from the ground up, including most of the core utils, scheduler, process management, etc.

This is obviously much more full featured (includes a GUI), so this is actually a very nicely sized team for the task.

You'd be surprised. There are lots of people writing operating systems as hobbies.

There's a wiki to get you started if you're interested: http://wiki.osdev.org/Main_Page

Have you heard of Oberon? That's like three people in a year. Including building the computer. ;)

And rust only hit 1.0 on May 15, 2015 (I looked it up https://en.wikipedia.org/wiki/Rust_%28programming_language%2... )

Its actually much easier then it sounds, we had an undergrad write an entire windowing system on-top of implementing the rest of the OS for undergraduate operating systems at UW in a single quarter (2.5 months~).

Yes, I like to read sources of big projects as a relaxing activity and almost never is documentation written in a way that a newbie can immediately catch up. The best projects will have a README.md in every directory that explains what a component or namespace is about, or nice big documentation headers. In my experience though if you really want to contribute the lack of documentation is only a small hurdle. If the code is well written then just following the code from the entrypoint on will give you a very good idea about what's going on. All the files and their names should make sense in under an hour or two.

In my opinion documentation is most important for external consumers of APIs who don't want to spend time grokking the code, and for explaining design decisions. For contributors it would be code quality.

There is this comment :) ..

    /// Into a cow
    pub fn into_cow<'a>(self) -> CowUrl<'a> {
        /*
             ______________
            < Mooooooooooo >
             --------------
                    \   ^__^
                     \  (oo)\_______
                        (__)\       )\/\
                            ||----w |
                            ||     ||
         */
        CowUrl::Owned(self)
    }

I only took a brief look over the code to try to find what documentation is actually there, but I managed to find this

https://github.com/redox-os/redox/blob/master/kernel/fs/url....

On your question of how typical a lack of system-internal documentation is in systems projects, the answer from my experience is unfortunately more common than it should be. There are a bunch of usage and design patterns that cannot be expressed regardless of the language you are using. I know very little about Rust, but I work mostly in Java, which is safer than many other languages (less flexible than interpreted or dynamic languages, less dangerous than C/C++). Even java, which has interfaces and strict typing can save you some of the more mundane unit tests and input validation code, has a bunch of design patterns on top of the core language. Projects could serve themselves well to document their code well to allow new contributors to look at any of the code and reasonably modify it to fix a bug or add a feature.

There appears to be a book that serves as documentation, though I don't know how complete it is: http://www.redox-os.org/book/book/

That project is attempting to re-create GNU-style coreutils, they wanted a slimmer, BSD style one, from what I understand.

Thanks for the recommendations!

First I have to install the current Rust version. Are there any MD5/SHA256/GPG to verify the integrity? Rust's download page doesn't provide anything like that.

https://www.rust-lang.org/downloads.html

qemu is recommended but Virtualbox is supported. Try running grabbing the latest source and running make virtualbox.

The book has steps, but I think it runs through qemu

The installer worked under VirtualBox for me.

There's a bit more info here: https://github.com/redox-os/redox/wiki/URL

That's pretty neat. You could kind of fake it on other OSes using something like Fuse with mount points like "/http" or "/tcp".

I don't know about Redox, but Phil's Rust OS (http://os.phil-opp.com/) seems to manage to minimize unsafe Rust and only use it to create some low level OS abstractions that can be safely used. It's pretty neat.

From the book[1]: A quick grep gives us some stats: The kernel has 16.52% unsafe code, a 50% improvement in the last three weeks. Userspace has roughly ~0.2%.

1: http://www.redox-os.org/book/book/introduction/unsafes.html

I guess not very much if Redox will support open hardware.

http://www.xda-developers.com/risc-v-cores-and-why-they-matt...

http://hackaday.com/2014/08/19/open-source-gpu-released/

http://www.openfpga.org

http://hackaday.com/2014/08/19/open-source-gpu-released/

http://open-ethernet.com

Some compelling projects (GPU) failed for lack of interest. The concepts behind those projects did not fail because most of the projects were isolated. The best time for open hardware is yet to come. Redox could accelerate that.