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”.
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).
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.
Technical documentation is not a math proof. Its purpose is to transfer a working mental model to a human reader so they can make correct decisions. A document can be locally, pedantically correct and still be globally misleading if it emphasizes edge cases, omits constraints, or frames abstractions in a way that causes readers to generalize incorrectly.
In practice, what matters is not whether every sentence can be defended in isolation, but whether the document reliably produces correct outcomes in the hands of its intended audience. A simplification that is technically incomplete but operationally accurate is often better documentation than a perfectly correct description that obscures the dominant behavior of the system.
Engineers learn this the hard way. If you have ever followed documentation that was “technically correct” yet caused you to design the wrong thing, you already know this distinction matters. Correctness is necessary to an extent (and not to an excessive extent), but it is not sufficient. The goal is truthfulness at the level of use, not just sentence level defensibility.
People may agree with you but don't imply something was done when nothing of the sort was even attempted. I did not impose my sloppiness onto others, what happened was someone tried to impose their pedantic-ness onto me and then you falsely accused me of imposing onto others. Please don't make up shit.
I've skipped even trying software because of poor documentation and so the response of:
> Give me a fucking break.
...seems shallow / callous.
You are correct that people judge documentation off of grammar and punctuation. But this is not a rational or logical thing people do. But I can't blame you or others, I mean after all the world believes in religion, myths and other fantasmic spiritual things with no solid evidence as backing. It's normal. I just felt HN was above that. Guess I'm wrong.
>...seems shallow / callous.
Seems that way only because you're not thinking deep enough. Think carefully whether it is rational or logical to judge the works of say Einstein because he had a grammar error or bad handwriting. The two are completely orthogonal and that is the rational perspective.
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
This level of nit-picking is disheartening...
> "If you can't explain it simply, you don't understand it well enough." - Albert Einstein
Which is listed at https://en.wikiquote.org/wiki/Albert_Einstein#Misattributed
> "If you can't explain it simply, you don't understand it well enough."
Which TFA (and others) misattribute to Einstein
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.
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.
In case anyone is curious, I very recently released a small demo kernel for RISC-V here: https://github.com/ajxs/straylight
This is something I will improve when the initial release will come
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.