Live data from Hacker News

Redox – A Unix-Like Operating System Written in Rust

redox-os.org

131–140 of 215 posts

Re: Redox – A Unix-Like Operating System Written in Rust

#131

Earlier quoted context omitted.

I think what you're trying to say is that architecture-specific code will be isolated in unsafe blocks. That's not necessarily true, as a lot of safe code can definitely benefit from knowledge of the underlying metal. I'm thinking of scheduling in particular.

Ok, seems I have yet a misconception about Rust's "unsafe".

"unsafe" is a superset of "safe" Rust. There are exactly 3 things you can do in unsafe code that you can't do in safe code: access/modify a global mutable variable, dereference a raw pointer and call other unsafe functions. That's it.

See: http://doc.rust-lang.org/book/unsafe.html#unsafe-superpowers

Re: Redox – A Unix-Like Operating System Written in Rust

#132
I've been looking through some of the kernel code [1] out of curiosity, and I'm very surprised to see that most components have almost no internal documentation — minimal file and class comments, and even fewer inline comments. Is this typical of code for something as complex and central as an OS kernel? Are the developers planning to go back later and add documentation, or is the expectation that anyone who might need to work with this code will find its structure and details intuitive?

[1] https://github.com/redox-os/redox/tree/master/kernel/

Re: Redox – A Unix-Like Operating System Written in Rust

#133

Earlier quoted context omitted.

A web server gets big, complicated, has lots of add-on parts, and has performance constraints. Small routers, DNS servers, and BGP servers are small, closed systems that should Just Work. You want to get them working, lock the code into read-only memory, and forget them.

Just keep it simple and do HTTP/1.0, that's not all that complex.

That's what I was thinking. Simple, barely enough for a router or somthing. Not Cloud Infrastructure 3.0 haha.

Re: Redox – A Unix-Like Operating System Written in Rust

#134

Earlier quoted context omitted.

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.…

Your website is interesting but a tad hard to follow due to the "organization" scheme. ;) So, what OS project did you work on in that first sentence and do you have a link to it?

Sadly, I don't have any link -- it was a commercial and proprietary soft real-time system, mainly for embedded use (we made it as portable as we could, but never ported it to something truly general-purpose like x86). It was functional and reliable more than it was fancy. Certainly nowhere near the scope of Redox. But it had preemptive multi-tasking, a driver model somewhat akin to Linux's (but without loadable modules) and some networking support, which we managed to fit in a few KB of RAM.

I'm saying all this in the past tense because the company was sold off a few years ago and I have no idea what happened to the IP, if anyone is still developing it and so on.

I only wanted to mention it because operating systems have this intimidating reputation, which is not only a little unfair, but seems to hold people back. I've seen a lot of very good programmers thinking they couldn't be part of a team that develops one, when it was in fact well within their possibilities.

And, historically, this has been true for a very long time. Many applications that run on operating systems are far, far more difficult to program than the system they're running on, or at least require vastly more knowledge in order to get right than writing the OS.

> Your website is interesting but a tad hard to follow due to the "organization" scheme. ;)

The joy I get out of doing it again vastly outweighs the pain of writing HTML by hand, but barely :-).

Re: Redox – A Unix-Like Operating System Written in Rust

#135
post #128

Earlier quoted context omitted.

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. Alre…

In other words, like GNU HURD. That design is very very hard to make correct and fast. Correctness suffers because the UNIX API has all sorts of interactions between different parts. This includes atomicity. It's a bear to get this right with IPC. Performance suffers because you are unable to effectively share data structures. This too relates to the interactions between different parts of the UNIX API. Look, there i…

> In other words, like GNU HURD. That design is very very hard to make correct and fast.

There are plenty of counterexamples to slow microkernels nowadays.

In addition, we trade speed for things like garbage collection. I'd happily trade some speed for increased security.

Re: Redox – A Unix-Like Operating System Written in Rust

#136
post #132

I've been looking through some of the kernel code [1] out of curiosity, and I'm very surprised to see that most components have almost no internal documentation — minimal file and class comments, and even fewer inline comments. Is this typical of code for something as complex and central as an OS kernel? Are the developers planning to go back later and add documentation, or is the expectation that anyone who might ne…

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/

Re: Redox – A Unix-Like Operating System Written in Rust

#137
post #128

Earlier quoted context omitted.

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. Alre…

In other words, like GNU HURD. That design is very very hard to make correct and fast. Correctness suffers because the UNIX API has all sorts of interactions between different parts. This includes atomicity. It's a bear to get this right with IPC. Performance suffers because you are unable to effectively share data structures. This too relates to the interactions between different parts of the UNIX API. Look, there i…

I was talking about systems like KeyKOS and GEMSOS fielded in production before Hurd was a thing. Then, systems like QNX, OKL4, BeOS, Minix 3, and others that largely removed performance issues often with self-healing and legacy app support. Actually, BeOS and QNX in Blackberry Playbook outperformed monolithic competitors. These altogether long proved our approach builds reliable, fast-enough systems with more security.

GNU Hurd is some crap along lines of Mach that tried to mix too many models while not leveraging lessons learned by others far as I can tell. It's something I hear about every year without any real field use or evaluation results. It's not representative of anything in microkernels except a bad approach.

GenodeOS is a better example where they apply many lessons from old school with modern components and virtualization. Already proven for embedded with desktops in alpha stage.

Re: Redox – A Unix-Like Operating System Written in Rust

#138
post #9

I'm pretty impressed that 37 people are capable of writing an entire OS with a gui in under a year. Looks really cool.

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

Re: Redox – A Unix-Like Operating System Written in Rust

#139
post #132

I've been looking through some of the kernel code [1] out of curiosity, and I'm very surprised to see that most components have almost no internal documentation — minimal file and class comments, and even fewer inline comments. Is this typical of code for something as complex and central as an OS kernel? Are the developers planning to go back later and add documentation, or is the expectation that anyone who might ne…

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.

Re: Redox – A Unix-Like Operating System Written in Rust

#140
post #132

I've been looking through some of the kernel code [1] out of curiosity, and I'm very surprised to see that most components have almost no internal documentation — minimal file and class comments, and even fewer inline comments. Is this typical of code for something as complex and central as an OS kernel? Are the developers planning to go back later and add documentation, or is the expectation that anyone who might ne…

[deleted]
Post reply on HN