（评论）

（评论）
(comments)

原始链接: https://news.ycombinator.com/item?id=41540362

读者称赞《学习操作系统》一书清晰地解释了操作系统开发概念，特别是 Rust 编程语言习惯用法，以及 Rust 中 async-await 的实现细节。他们还对 Rust 对 future 的详细解释表示赞赏。读者希望作者能够恢复计划中的第三版的工作，因为根据该项目 GitHub 存储库上的提交活动，开发似乎已陷入停滞。读者注意到缺乏多处理器支持和调度功能，并提到了将内核内存映射到更高内存的持续问题。读者在创建基于 Plan9 的设备文件以与内核通信时感到很高兴，并认识到将操作系统成熟为综合教育工具所需的努力。读者分享他们的目标是将整个操作系统（包括用户空间程序）安装到一个人的心理模型中，旨在平衡低复杂性与合理的性能。尽管没有传输层安全 (TLS) 支持，但读者可以通过纯 HTTP 连接访问在线文档。读者钦佩该项目同时提供对操作系统历史和 Rust 编程语言细节的见解的能力。然而，他们认为当前版本在引导阶段提供了过多的指导，更喜欢一种跳过引导复杂性的更简单的方法。最后，读者表达了对实时操作系统（RTOS）未来发展的兴趣。

I completed the second edition years ago and found it illuminating. It's very well done! The explanations pertaining to OS dev are nice but it was also a useful artifact for learning more Rust after having gone through the Rust book. The author had a good grasp of the idiom of the language, so seeing how he expressed certain things in code vis a vis how I would have done was educational. The blog's explanation of how futures are implemented in Rust was especially a highlight[0], and I think it's the best I've seen on that topic anywhere.

I hope Phil will find the inspiration to come back and work on the EFI-based third edition again. AFAICT, (based on commits to the git branches) that has stalled. I was a GitHub sponsor for about a year until my CC expired and was always bummed to see it left out of the "This Month In Rust OSDev" posts.

Anyway, the second edition is still a great way to spend a weekend's dev time and I appreciate all the hard work that clearly went into it. Thanks Phil!

[0]: https://os.phil-opp.com/async-await/#async-await-in-rust

Whoa, looks very cool. So far, my favourite project is xv6, because:

- codebase is reasonably compact, can be understood in a few weeks

- can be built with standard GCC provided by package manager, no need to built a custom GCC from source

- has user space, too

Seems like your project also have those points checked. Bookmarked!

Thanks! Compared to xv6, you will find some important pieces missing. For example, there's no multiprocessor support and no scheduler, only one process can run at any time.

I should also note that user space programs can do memory allocation via syscall, but I currently have an issue with the kernel memory that I probably need to remap higher in memory. So, most commands inside the OS are still executed from kernel space, although they use syscalls and everything as if they were user space programs. I'm having a lot of fun creating device files inspired by Plan9 to communicate with the kernel.

There's a lot of work yet to arrive at something that feels truly complete as an educational OS, but I'm hoping to get there eventually. I really like this project because I'm learning along the way all the time!

Your first point is one of my main goals: I want the whole OS, including user space programs, to fit inside one brain. I'm always trying to find ways to keep complexity low without compromising too much on performance.

Good question, there's no TLS support inside MOROS so its website must be available over HTTP, especially when I self-host it. That's not the case currently so I could also have HTTPS but I'm using Dokku and last time I tried the Let's Encrypt plugin would redirect HTTP to HTTPS automatically, which is annoying.

Edit: I set up CloudFlare in front of the server and there's now a working HTTPS version along with the HTTP version accessible from inside MOROS. This should also work when I'll use again the web server inside the OS. Thanks for prompting me to look into it!

No! Stop! Why won’t this one die! MITMing is a two way street. I could intercept sensitive data, or I could shove something in that tricks the user (phishing, etc), exploits the user agent, and more!.

“You only need encryption for the sensitive stuff” is what we did, poorly, in the late ‘00s / early ‘10s, and it was rightfully proven to be a bad idea. There’s a reason why browsers treat HTTP the way they currently do, and it isn’t because they’ve been co-opted by Big Certificate Authority.

EDIT: and as the other commenter says, there are download links.

No but we have no "httpv" protocol scheme to require signatures but not encryption

Which IMO has been a huge mistake since breaking caching proxies for networks because we want to prove authenticity and have to do secrecy as well has been quite silly.

im subscribed to your RSS feed since a while back, MOROS seems like a really cool project! sadly haven’t been able to try it since it wouldn’t start on QEMU for some reason, though i think that’s an issue on my side rather than the OS itself.

Funny, I found this today after doing a deep dive on Rust and OS development. I was in awe at the quality of this content. You come out of it not only learning so much about the history and design of operating systems, but you start to pick up elements of Rust as well. Phil did an incredible job on this.

I especially recommend the original edition of these posts. For me the current edition does way too much hand holding, taking care of the entire bootloading process with a specialized crate.

I like that there’s a way to skip all that boot loading stuff, your comment made me want to actually try this. I want to build a fun little OS for myself but I hate the part where you have to do magical incantations to get to a decent machine state to do stuff in. Not that it’s a bad thing, everybody likes different stuff. Thanks for mentioning this!

I just came back from Rustconf and it seems there’s about five or so major OS releases, particularly focused around real time. Not all are open source though.

Tock-OS, Oxid-OS (the safety version of Tock-OS, like freertos/safertos), and Hubris (from Oxide Computers) are the main three RTOSs, Embassy and RTIC are common frameworks (but not classic RTOSs) used for scheduling and resource management on bare metal systems. There are some more niche or non-public ones as well.

For more classic OSs (not real time), Redox is the main one, as well as a lot of research/experimental/teaching ones, including the Blog OS from this guide/submission.

Working on one over at github.com/oro-os but haven't proven efficacy of the design yet, so haven't announced it. Just if you want something to follow.

We shouldn't write an OS in rust. We should create a data platform on which we can run DML/DDL with an SSMS++ automatic frontend.

We really should, if for no other reason than to silence those who think that every Linux/BSD box connected to a network is being rooted every 5 mins because they are written in C.

That's if they ever get around to bringing such a Rust-based OS up to enterprise level rather than spouting off about this belief on HN all day every day.

Makes sense but what if there are bugs in llvm? U r still exposed. So need a rust version of llvm and then rust can be self hosted

It doesn't really matter whether the compiler is memory safe. What you run is the result of the compiler. A perfectly memory safe compiler can have a correctness bug that generates unsafe assembly from a safe rust program.

The pool of operating system penetration testers will be absolutely devastated if a rust OS becomes mainstream.

Most, if not all, vulnerabilities are related to lack of memory safety.

Well, guess there’s always the application/user space.

Definitely not all. Our current best estimates put the figure of (amount of security vulnerabilities due to memory safety errors) / (total amount of security vulnerabilities) at 50-70%.

People will still be making logic errors & authentication errors (e.g. insecure direct object reference) in Rust code for decades to come, to name just a few. Why? Because people make mistakes.

Regarding your last sentence, if they move on to AI imposed security vulnerabilities there is probably a lot of bread and butter to be made there.

（评论） (comments)

（评论）
(comments)