Hacker News Reader

Comment by mtgx | Hacker News Reader

Short review: Another OS written in C/C++ that will have a million and one bugs over the next 3 decades.

Just want to point out that not that long ago redox-os (the microkernel OS in Rust) asked people to test it.

People were able to kernel panic it, get privilege escalations, and DDoS it. In short, it had the same same issues a C based kernel would get.

It's true that it's still heavily in development and doesn't offer any guarantees whatsoever, but I think that it should be pointed out that just because your language is good, doesn't mean that your end result will be good (and vice-versa, C based kernels like l4 and C based projects like SQLite have been formally verified (at least SQLite was verified after compilation, so they check for undefined language constructs.))

Well, I mean, one of the issues listed is "getting a lockup with ls * on the default directory". Sure, Rust (or any other language, even something like Idris) is not a magic pill, but at that stage of development, you can't expect much. I would still say that it is, on average, a lot easier to shoot yourself in the foot in C than in Rust.

Can you link to that? I'd be curious to see how they did those things. I guess Redox has a lot of unsafe Rust code?

Here is the "Redox Crash Challenge":

https://github.com/redox-os/redox/issues/1136

According to the Redox book, at last count they had 70 cases of unsafe across 4500 total lines of kernel code.

https://doc.redox-os.org/book/introduction/unsafes.html

Safe rust doesn’t mean “no bugs”, these kinds of issues aren’t inherently memory safety issues, they can also be the product of logic bugs.

Why focus on the language and the possibility of a million and one bugs but not the architecture and design choices?

Because it's an easy indicator of someone who has no idea what they're doing in OS development. Choosing the wrong tool for the job is meaningful. Have you ever looked through Chromium's C++ codebase? The same people are working on this and it tells us that they haven't learned their lesson (or they want to tightly integrate Chrome with Fuschia, which is also a foreboding sign).

Edit: I should clarify that I think C is the only rational choice and that Rust is ill suited to osdev as well. I'm only talking about C++ here.

> Because it's an easy indicator of someone who has no idea what they're doing in OS development.

From appearances, the lead "someone" on at least the kernel appears to be Travis Geiselbrecht, who worked at the OS and/or kernel level on BeOS, the Danger Hiptop (Sidekick) OS, his own NewOS (now the basis for HaikuOS), and an embedded OS at Jawbone before joining Google and starting work on LK, which is being used as the basis for Zircon and the Android bootloader.

So I think maybe you mean

> Because it's an easy indicator of someone who does not have the same opinions about OS development than I do.

...because, y'know, that's fine! But "this guy obviously has no idea what he's doing?" Gonna agree to disagree there.

>Because it's an easy indicator of someone who has no idea what they're doing in OS development.

Actually suggesting Rust as some kind of magic bullet over C/C++ is a huge indicator "of someone who has no idea what they're doing in OS development".

It's similar to when first year CS students learn that assembly is "faster" (a hazy notion itself), and then want everything to be written in assembly.

>It's similar to when first year CS students learn that assembly is "faster" (a hazy notion itself), and then want everything to be written in assembly.

That's an interesting kind of first year students... The kind I know flee before anything lower than C++.

Added to my comment:

>Edit: I should clarify that I think C is the only rational choice and that Rust is ill suited to osdev as well. I'm only talking about C++ here.

Nah, writing a kernel in modern C++ or Rust is pretty rad. Higher level abstractions can be designed to avoid bugs (As evidenced by the explosion of macros in the Linux code base). Check out L4Ka::Pistachio https://github.com/l4ka/pistachio

>Because it's an easy indicator of someone who has no idea what they're doing in OS development. Choosing the wrong tool for the job is meaningful. Have you ever looked through Chromium's C++ codebase? The same people are working on this and it tells us that they haven't learned their lesson.

Have you looked into the backgrounds of the main developers working on Fuchsia OS? Because if you had you would have discovered that that they have a rather impressive resume who actually know what they're doing.

Travis Geiselbrecht - BeOS, iOS, Hiptop OS, Little Kernel

Brian Swetland - BeOS, Hiptop OS

Chris McKillop - a member of the original iPhone team, WebOS, QNX OS, Hiptop OS

Someone said something similar earlier, but I chose not to respond to avoid getting deeper into an unrelated argument. The short of it is that I don't find BeOS (and Haiku) particularly impressive. WebOS is all userspace and I don't really care how Fuschia's userspace looks, and I have to admit I don't know much about QNX or Hiptop.

I know you're a prolific commentator here, so if you don't mind me asking ... Which operating systems have you designed (or worked on) to say that writing a microkernel in C is a symptom that they don't know anything about OS development?

Writing a microkernel in C is fine. I said _C++_. But for the record, I built this:

https://github.com/KnightOS/kernel

And I've worked on toy kernels here and there and studied more serious kernels in depth.

You're probably missing their tradeoffs. Google has deep expertise in C++ within the company and integration with existing libraries / tools is a huge bonus. So if the goal is a market-ready product and velocity matters, then it makes sense not to adopt a new language that is still changing a lot. It's only your opinion that they've chosen the wrong tool. There isn't one right answer to nuanced product decisions.

>then it makes sense not to adopt a new language that is still changing a lot

I should clarify that I agree with eddieh and think C is the only rational choice.

I'd say the same thing without narrowing the statement to C/C++. ;-)

I believe the kernel is based on L4, which has at least one bug-free implementation[1].

1: http://sel4.systems/

The Ziron microkernel is based on Little Kernel[1]. One of the main authors of Fuchsia was the developer of LK.

[1]https://github.com/littlekernel/lk/wiki/Introduction

Thanks for the correction

you're right. it should be written in typescript. or maybe the java prerelease from 1995.

Urg...

https://externos.io/

Edit:

>eXperience the future.

I don't know what gets me more, the idea of a js os, the bad capitalization, the period at the end of a non sentence, the cliché expression...

Whoever's behind it seems to be stuck at the "gaussian blur compensates for all forms of design inexperience!!1" stage too.

Get with the times. Clearly Rust is the answer!

Did someone say pascal?

As someone who has dabbled in OS development over the years, you'd be a fool to use anything other than C (I suppose you could use a restricted subset of C++ if you really don't want to write anything but a toy OS) or assembly if you have something to prove.

What about Rust disqualifies it? Let's say besides ecosystem immaturity (lack of libraries). As a non-systems programmer, I'm curious.

One drawback about Rust OSes right now is that they must use nightly Rust, and therefore, don't gain our stability guarantees. This is another form of immaturity.

I still wish they would have done it anyway, but oh well :)

On a technical level, there's nothing stopping you: we already have one serious project (Redox) and many, many hobby projects that exist.

They do have some rust showing up in their repos. It looks like its mostly bindings needed to run rust on the OS. I don't know what their long term goals with it are. I'm guessing they want it for writing high performance user space daemons or whatever the fuchsia equivalent is.

https://github.com/fuchsia-mirror?utf8=%E2%9C%93&q=&type=&la...

Not OP but the reason I dislike Rust for OS/kernel development is that it's just too damn complicated. Kernels should be written in more conservative languages.

C just pushes the complexity onto the programmer without help.

Random subjective opinion presented as objective truth!

because > Not OP but the reason I dislike Rust for OS/kernel development is that it's just too damn complicated

isn't?

I'm also not sure why stating my opinion is a problem. If you can't handle someone not bother to pussyfoot around and preface any statement with an "IMO" disclaimer, that seems like your problem.

Dude lighten up it was a joke :)

oh alright then.

I haven't personally looked into the Rust based OS (I know it exists), but I can guarantee that they're using inline assembly, fighting with language features, working around limitations, and forgoing safety.

I'd be shocked if that isn't the case. I'm not saying that you can't build an OS in Rust or other languages, just that OS development is complicated enough without having to fight your language.

You just provided at least two good reasons. Add the ABI instability as a third and rust has struck out.

Reply on news.ycombinator.com