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.
Hi!
I am the developer of this, and I really appreciate the feedback!!
The book is still on development and this is why I didn't even publish it here, I just recently finished the highlighter which was a lot of work, and I probably will require more.
Currently I am trying to make book and OS unique by developing and creating an explanation on AHCI, which I didn't see much on the internet. And then I try to handle all of the grammar, and typos
I couldn’t care less. It always pisses me off when a reviewer of my PR just flags the entire thing because of inconsistent capitalization. It’s the right correction and I always follow through but it’s also pedantic.
It’s technically more correct. But it’s also not a very big deal. Actually it matters more in code for search-ability but for documentation and comments? Give me a fucking break.
Attention to detail is important for many and is often a first touch with an end user. I agree with OP, if documentation is sloppy or inconsistent (I'm not saying the doc in question is because I haven't read it) it definitely reduces the impression that it's correct or reliable.
I've skipped even trying software because of poor documentation and so the response of:
“*nix” means a Unix-like OS just generally (http://en.wikipedia.org/wiki/%2Anix), like for example in “Minix” and “Xenix”. Sticking “OS” to the end of an OS name is also commonplace. However, the title on the page is “The Learnix Operating System”, so the actual name seems to be just “Learnix”.
It’s arguably Nix and NixOS who have unnecessarily stepped into the “*nix” namespace without adding a distinguishing prefix.
Illumos is still actively developed, open source, and can trace its lineage back to actual unix.
For that matter, we've had new members joining the family over the years; https://www.redox-os.org/ is, in their own words, "a complete Unix-like microkernel-based operating system written in Rust, with a focus on security, reliability and safety."
For that matter, if we're including the proprietary OSs, HP-UX is still kinda a thing and AIX is going strong. Of course, IIRC those are actual certified UNIX™ instead of unix-like... though I'd call that a subset, so still in scope IMO.
> Others think someone from the Rust (programming language, not video game) development community was responsible due to how critical René has been of that project, but those claims are entirely unsubstantiated.
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...
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
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.
When I started writing this OS, Rust was a pain, and I needed to understand a lot of things that I didn't know about the language, I can flag on some sections that people can skip because they are more language related, but I think that it is very important, and can be beneficial to people that come from other languages, or to people that want to understand rust more deeply.
In every chapter I try to initially explain the topic and then implement, or something in between. but I think the implementation is important because it completes the picture.
One of the hardest parts of writing an os is learning and understanding how to make the toolchain work the way you need it to. I wouldn't consider that a negative to spend time discussing it in such detail. Otherwise you have no idea how to even apply the high level concepts.
> greater focus on the fundamentals versus the implementation
I am seeing this too. Folks are suddenly saying - lets implement this in Rust (or insert any other language here) without thinking about what this does to the fundamentals. A bandwagon effect which developers are swept by. And for managers it is a great way to show how innovative your team is. This applies not just to languages but entire development stacks almost like fashions in clothing.
Eh... all the major OSs use C, anyways. For starters, (almost?) everyone is using a decent bit of assembly at the bottom. Then Linux is slowly adding Rust, and I was under the impression that NT spanned C, C++, and maybe some Rust now? And the moment we speak of the whole operating system and not just the kernel I think your claim collapses completely in the face of Darwin's Objective C and Windows doing... everything Microsoft feels like including.
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?
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.
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.
Bleh, I think a typo here and there is fine, you can grasp the meaning, and gives the writing style "character". Yes, it's dire but I'd take that over the soul-less LLM writing style.
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 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.
No word on whether it's finished or will ever be but already looks complete enough to me? I mean, the subject is endless and there are so many ways to do things. But as primer, it's pretty good as it is.
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.
The book is still on development and this is why I didn't even publish it here, I just recently finished the highlighter which was a lot of work, and I probably will require more.
Currently I am trying to make book and OS unique by developing and creating an explanation on AHCI, which I didn't see much on the internet. And then I try to handle all of the grammar, and typos
It’s technically more correct. But it’s also not a very big deal. Actually it matters more in code for search-ability but for documentation and comments? Give me a fucking break.
I've skipped even trying software because of poor documentation and so the response of:
> Give me a fucking break.
...seems shallow / callous.
Maybe 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!
It’s arguably Nix and NixOS who have unnecessarily stepped into the “*nix” namespace without adding a distinguishing prefix.
"Unix-like OS" isn't a thing that has existed for two decades. Only Linux and Darwin survived, so don't do the "*nix" thing, please.
For that matter, we've had new members joining the family over the years; https://www.redox-os.org/ is, in their own words, "a complete Unix-like microkernel-based operating system written in Rust, with a focus on security, reliability and safety."
https://community.ibm.com/community/user/blogs/sanket-rathi1...
https://trends.google.com/trends/explore?date=today%205-y&q=...
https://trends.google.com/trends/explore?date=all&q=Unix%20l...
I would suggest the name "Leanix" if the author is willing to rename.
It rhymes with Minix which is the OG curriculum for a POSIX kernel, and is "lean" in many senses of the word.
In any case an excellent writeup. It's detailed enough to implement in any programming language.
I think the name is fine as is.
Then people would complain that it sounds too much like “Linux”.
This level of nit-picking is disheartening...
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 every chapter I try to initially explain the topic and then implement, or something in between. but I think the implementation is important because it completes the picture.
I am seeing this too. Folks are suddenly saying - lets implement this in Rust (or insert any other language here) without thinking about what this does to the fundamentals. A bandwagon effect which developers are swept by. And for managers it is a great way to show how innovative your team is. This applies not just to languages but entire development stacks almost like fashions in clothing.
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.
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.
But it's nice to have non-LLM written text. Still the many typos are annoying and distracting.