This dedicates at least as much time to discussing the eccentricities of the underlying Rust implementation (and the Rust language itself) as it does to discussing the underlying low-level hardware/software concepts. Since this is very much still a work-in-progress (only the first three sections have been fully fleshed-out), I have a suggestion to make: please make it more language-agnostic, with a greater focus on the fundamentals versus the implementation.
This is an ambitious project. Might I respectfully suggest that you use your favourite AI (or an English-speaking friend) to fix your many grammatical errors and typos? For example "Note: ALL the syntax highlighting of the Rust code is custom and create by me! If you see and bug, please write in the comments or submit an issue." should be
"Note: ALL the syntax highlighting of the Rust code is custom and was created by me! If you see a bug, please leave a comment or submit an issue."
Also, Rust, not rust. And many more.
After that vibe coeded zig book fiasco a few weeks ago, I'm just glad to see this was written by an actual person. I'm sure the content will be improved on with time.
Why always POSIX compliant? If its going to be a learning exercise or a hobby OS or just an exploration, why not throw POSIX out the window and start from scratch for designing the API?
I think it's really cool that they're using bare-metal Rust for this. It's a lot more accessible than C because the standard distribution (rustup) can work as a cross-compiler to a no-OS target out of the box. Deliberately avoiding dependencies makes me happy too, people really underestimate what you can do with Rust without relying on the whole dependency ecosystem, and this is better pedagogically because you can understand the whole system.
I'm rather amused at how https://www.learnix-os.com/ch01-02-booting-our-binary.html has you creating a 16-bit target that ostensibly uses 32-bit pointers in its data layout… presumably that doesn't actually work to compile normal code to (edit: …or does it?! What on earth does LLVM do with that then…) but I guess it works so long as it's just acting as a scaffold for inline assembly. It's cool they don't need to bring in a secondary toolchain for the 16-bit part of bootstrapping, even if I worry this might break in some future rustc/LLVM revision.
I wanted to share a quick piece of feedback from a potential reader's perspective: There are several small inconsistencies in the intro text (e.g., inconsistent capitalization of 'Rust' vs 'rust', grammar typos).
In a domain like OS development where extreme precision is required, these small errors can subconsciously signal to readers that the technical details might also be imprecise. A quick polish of the documentation would go a long way in establishing authority and trust for the rest of the book.
To anyone wanting to learn about OS development, nothing beats MIT 6.824.
I finished the assignments in that course and that covers all the important aspects like processes, context switching, CPU modes, page tables and virtual memory and many other relevant topics like file systems, device drivers etc. And also it’s free.
From the table of contents this course gets too involved in ancillary matters like bootloaders or the Rust language itself whereas the focus of any OS development tutorial should be on core concepts like how processes are implemented, how context switching works, how paging and consequently multi level page tables (actually, in code) work etc.
Opening with a made-up quote (that is very simple to Google, which quickly confirms its apocryphal nature) doesn't inspire confidence in the factual accuracy of the remainder of the book...
Skipped through the first pages and I really like your approach. Avoiding to use „magic“ libraries which abstract away a lot of the intricacies the lower levels is helping with the understanding.
I started my journey to develop my own little OS (https://github.com/jbreu/jos ) based on phil opperman‘s tutorial but quickly diverged from his exactly due to his use of such libraries.
I wish instead of discussing typos, folks her who surely know better (or author) could shed light on how this project compares to the many other existing projects, like
I always wonder why these guides stick to x86(-64). I get that it's still the most popular processor architecture for desktop computing, but it's got a lot of complex legacy baggage that's an unnecessary cognitive burden for beginners. It's also a relatively uncommon target for real-world bare metal development. Why not target RISC-V? I've done a lot of OSDev in both x86 and RISC-V, and I think RISC-V is much more teachable. You don't want to bog the reader down trying to understand what protected mode, or the A20 line is, when you could just focus on more universal concepts.
Hmm. Although I am not the biggest fan of Rust, I am a huge
fan of LFS/BLFS (https://www.linuxfromscratch.org/), so I am
all in favour of more high quality information here, including
the learnix-os website.
Google search has become so useless in
the last years that we all need to counter this evil force by
improving existing documentation, as well as adding new high
quality information - so from that point of view I am all in
favour of such projects, even if the language is not my favourite
one. Ideally we could have something like learnix for ALL
languages, even the old ones, and even the slow ones. Rust is
at the least fast, so it can be compared to C or C++, but I
think we also need this top-down approach for, let's say
something crazy ... python. (I get the "it is too slow" but
this is more about education; plus, computers will become
faster in the future too anyway.)
The name learnix may not be ideal though if it focuses on just one programming language. It should be a bit more like LFS/BLFS, and even LFS focuses mostly on shell scripts; I'd prefer an agnostic instruction set, but then they can on top of that use shell scripts of course, with additional scripts in other languages (I adapted all of that stuff into ruby, for instance, although not in a high quality way such as LFS/BLFS e. g. some of those scripts and deployments I wrote lack documentation for other people to adjust and adapt, simply due to lack of time - but I try to improve the documentation whenever time permits, it just has a lower priority compared to other obligations or work-related things).
I feel like focusing on BIOS bootloaders and cylinders/heads/sectors that have been a lie for a very long time over UEFI & NVMe is just a weird choice, especially so when the code shown is Rust and not old C folklore.
23 comments
[ 3.4 ms ] story [ 37.3 ms ] threadMaybe the author could add a small note that this is not about that, and refer to something official about NixOS?
Anyway, I like the idea of the project!
To the author, I appreciate your effort here!
But it's nice to have non-LLM written text. Still the many typos are annoying and distracting.
I'm rather amused at how https://www.learnix-os.com/ch01-02-booting-our-binary.html has you creating a 16-bit target that ostensibly uses 32-bit pointers in its data layout… presumably that doesn't actually work to compile normal code to (edit: …or does it?! What on earth does LLVM do with that then…) but I guess it works so long as it's just acting as a scaffold for inline assembly. It's cool they don't need to bring in a secondary toolchain for the 16-bit part of bootstrapping, even if I worry this might break in some future rustc/LLVM revision.
In a domain like OS development where extreme precision is required, these small errors can subconsciously signal to readers that the technical details might also be imprecise. A quick polish of the documentation would go a long way in establishing authority and trust for the rest of the book.
I finished the assignments in that course and that covers all the important aspects like processes, context switching, CPU modes, page tables and virtual memory and many other relevant topics like file systems, device drivers etc. And also it’s free.
From the table of contents this course gets too involved in ancillary matters like bootloaders or the Rust language itself whereas the focus of any OS development tutorial should be on core concepts like how processes are implemented, how context switching works, how paging and consequently multi level page tables (actually, in code) work etc.
I started my journey to develop my own little OS (https://github.com/jbreu/jos ) based on phil opperman‘s tutorial but quickly diverged from his exactly due to his use of such libraries.
https://github.com/cfenollosa/os-tutorial, https://littleosbook.github.io/, https://github.com/tuhdo/os01, https://github.com/prakhar1989/awesome-courses?tab=readme-ov...
or even just "OPERATING SYSTEMS DESIGN AND IMPLEMENTATION" by Tanenbaum
In case anyone is curious, I very recently released a small demo kernel for RISC-V here: https://github.com/ajxs/straylight
Google search has become so useless in the last years that we all need to counter this evil force by improving existing documentation, as well as adding new high quality information - so from that point of view I am all in favour of such projects, even if the language is not my favourite one. Ideally we could have something like learnix for ALL languages, even the old ones, and even the slow ones. Rust is at the least fast, so it can be compared to C or C++, but I think we also need this top-down approach for, let's say something crazy ... python. (I get the "it is too slow" but this is more about education; plus, computers will become faster in the future too anyway.)
The name learnix may not be ideal though if it focuses on just one programming language. It should be a bit more like LFS/BLFS, and even LFS focuses mostly on shell scripts; I'd prefer an agnostic instruction set, but then they can on top of that use shell scripts of course, with additional scripts in other languages (I adapted all of that stuff into ruby, for instance, although not in a high quality way such as LFS/BLFS e. g. some of those scripts and deployments I wrote lack documentation for other people to adjust and adapt, simply due to lack of time - but I try to improve the documentation whenever time permits, it just has a lower priority compared to other obligations or work-related things).