This looks like an ambitious roadmap and a great learning resource!
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.
“*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.
> 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.
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.
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.
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?
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.
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.
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!
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.
Then people would complain that it sounds too much like “Linux”.
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.
https://trends.google.com/trends/explore?date=today%205-y&q=...
https://trends.google.com/trends/explore?date=all&q=Unix%20l...
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'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.