“*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.
I feel like if I saw something just called "learn unix", I'd expect it to be teaching me how to use it generically, not implement it. Adding "OS" makes it clear to me that it's a dedicated OS for the purpose of learning (although it still wasn't clear to me that the goal was implement it so if anything I'd argue that the title is missing context, but the name of the OS isn't redundant).
So your argument is the first usage of a word gets exclusive rights to it? Firstly, that's not how human languages work. Secondly, this would invalidate the Unix claim to "nix" as it's been a word for hundreds of years prior to Unix being invented.
It is, but in IT context the association was strong, while Unixes decline and most of the systems with derived naming are historic. But anybody with a background in sysadmin for more than 10 years probably would still have the association. In ten years Linux will probably the only one remaining with the ux-naming (and MacOS X with the single X, which also serves as ten, following MacOS 9)
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.
The linked trends suggest a revival of the term though.
> The people who do the "*nix" cargo cult thing have never seen a SunOS machine and don't even know what a HPUX is.
The meaning of words evolve over time though. Text is still broken into lines by "carriage return/line feeds" and is written on "hard disk" split up in "sectors".,. Over time people using these would not have seen a typewriter or even know what a platter is but may still use it to communicate effectively.
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."
> 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.
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
Well for a start C grew up next to the OS it was being used to build, so it was really intended for kernel/systems programming from the very get-go. Rust has taken a lot longer to get there. That's all.
> What does that matter for learning how operating systems work?
my rust is stronger than my c. been wanting to learn OS development and this being in somethign I already know lets me focus specifically on the os specific stuff rather than also needing to deepdive into c. a language I haven't so much as glanced at in almost 10 years
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.
No. Why would it be? I hate it when people come up with defense based off of linguistics. Your defense is essentially "technically correct" sounds like "technical documentation" therefore one applies to the other because of the word "technical". That's an incidence of language and NOT of reality. Let me frame if from a rational and logical perspective:
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.
Sure you do, you see a crime where no crime happened. Read my post carefully. I imposed nothing. A standard was imposed onto me. I didn't in turn impose anything on anyone else.
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.
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:
I highly disagree. You are judging a book by it's cover. Capitalization is no different from handwriting. Substance matters, capitalization and grammar are superficial. If meaning is captured then capitalization does not intrinsically matter.
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.
Not to make a point of it either way, but judging a book by its cover can be useful if the credibility of the book's content alone is difficult to evaluate. That's why people care about degrees and other qualifications.
There are plenty of other ways. Book reviews for example. If the cover is the only way than so be it, but this is rarely case. Additionally the cover of a book, like capitalization is one of the most inaccurate metrics to judge a book by.
It doesn’t. I don’t know how something so simple can’t be understood. Does capitalization matter in math or algebra or logic? No. It doesn’t. Why? Because capitalization is a concept exclusive to language, and not just any language, but an arbitrary family of languages similar to English. The concept for example does not exist in Chinese.
Sure, but we program using programming languages, mostly using the Latin alphabet you are referring to. And yes the syntax for many of those programming languages is in fact case sensitive.
Obviously. The topic is about whether case sensitivity + capitalization matters not whether it exists. My claim is it doesn’t matter much. Whether you use I or i in your for loop as an index doesn’t matter.
And it’s completely irrelevant to logic or math. So whether or not you choose to make capitalization matter in your program is a completely arbitrary choice. It’s like snake case and cane case. You choose one style for consistency but in the end even if you use both styles in your program there is zero practical downside. The only downside is people with ocd get all worked up and don’t have the capacity to understand that it doesn’t matter.
All this for writing Rust as rust! Wow!
Tell me you have ADHD without telling me you have ADHD, just get on with the work and let others do their work. Don't flag their entire work. Linguistics is very inclusive. I took a course on it. No need to be a grammar nazi
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...
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.
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.
For what it's worth, I've found the Rust-y explanations well worth the read! Please keep them in, it's really interesting to read about the technicalities.
> 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?
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).
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.
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.
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 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.
This project started because I wanted to understand the linux that sits on my computer, which is x86. There is a possibility that on the future it will have multiple architectures supported, probably starting with arm, but I can't promise that
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.
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.
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.
From the name I thought this was about learning NixOS, and they found a very clever name
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!
“*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.
Then I guess the OS part is redundant, since thr nix already implies an OS.
I feel like if I saw something just called "learn unix", I'd expect it to be teaching me how to use it generically, not implement it. Adding "OS" makes it clear to me that it's a dedicated OS for the purpose of learning (although it still wasn't clear to me that the goal was implement it so if anything I'd argue that the title is missing context, but the name of the OS isn't redundant).
No, actually Nix is a package manager/system configuration tool. NixOS uses Nix as part of its image.
No, nix clearly means a Unix-like OS and any other interpretation is wrong, as the context of this thread would suggest.
So your argument is the first usage of a word gets exclusive rights to it? Firstly, that's not how human languages work. Secondly, this would invalidate the Unix claim to "nix" as it's been a word for hundreds of years prior to Unix being invented.
It is, but in IT context the association was strong, while Unixes decline and most of the systems with derived naming are historic. But anybody with a background in sysadmin for more than 10 years probably would still have the association. In ten years Linux will probably the only one remaining with the ux-naming (and MacOS X with the single X, which also serves as ten, following MacOS 9)
My guy, most people don't even know what nix (the package manager) is.
https://www.merriam-webster.com/dictionary/homonym
LearnixOS doesn't seem to have anything to do with NixOS, afaict?
> “*nix” means a Unix-like OS just generally
"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.
BSD would like a word.
They can't be heard over the faint booing from the Solaris crowd.
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.
TIL AIX is still in development and they had a release this month
https://community.ibm.com/community/user/blogs/sanket-rathi1...
We don't talk about BSD here.
Before clicking the links.. How confident do you feel about your assertion?
https://trends.google.com/trends/explore?date=today%205-y&q=...
https://trends.google.com/trends/explore?date=all&q=Unix%20l...
Very confident.
The people who do the "*nix" cargo cult thing have never seen a SunOS machine and don't even know what a HPUX is.
The linked trends suggest a revival of the term though.
> The people who do the "*nix" cargo cult thing have never seen a SunOS machine and don't even know what a HPUX is.
The meaning of words evolve over time though. Text is still broken into lines by "carriage return/line feeds" and is written on "hard disk" split up in "sectors".,. Over time people using these would not have seen a typewriter or even know what a platter is but may still use it to communicate effectively.
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 anyone wondering, OpenSolaris -> illumos (e.g. OpenIndiana). Good times!
Not to mention that Version 4 UNIX source code was just released!
Well, yes, but that's not exactly a modern OS, just historically interesting.
Darwin is not UNIX (nor is XNU). But macOS technically is certified UNIX.
XNU literally stands for “X is Not Unix”
I had the same confusion. Even without considering NixOS, "learnix" is awkward to pronounce and somewhat pretentious.
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 would suggest the name "Leanix"
Then people would complain that it sounds too much like “Linux”.
Particularly if you have learned to pronounce Linus’s name correctly.
What's pretentious about learnix?
I like the current name and already have the domain :|
I think that it's supposed to be a portmanteau of Unix and Learn.
I don't find it awkward to pronounce in the least, and not in any way pretentious.
I think the name is fine as is.
I mean, it is about learning. It threw me for a loop too but I think it's actually reasonably appropriate.
Thought the same! Was a bit interested in learning Nix for a moment.
Will do!
[flagged]
> 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.
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
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
Well from what I can see all the examples you've linked are in C, and this one is Rust? That counts for something I guess?
What does that matter for learning how operating systems work?
But even then, SAYING that this is an how-to-build-an-OS project similar to those others, but focused on Rust, would be quite helpful.
Well for a start C grew up next to the OS it was being used to build, so it was really intended for kernel/systems programming from the very get-go. Rust has taken a lot longer to get there. That's all.
> What does that matter for learning how operating systems work?
my rust is stronger than my c. been wanting to learn OS development and this being in somethign I already know lets me focus specifically on the os specific stuff rather than also needing to deepdive into c. a language I haven't so much as glanced at in almost 10 years
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.
Isn’t being technically correct an important thing for technical documentation that aims to be technically correct?
No. Why would it be? I hate it when people come up with defense based off of linguistics. Your defense is essentially "technically correct" sounds like "technical documentation" therefore one applies to the other because of the word "technical". That's an incidence of language and NOT of reality. Let me frame if from a rational and logical perspective:
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.
The fact that you hate something doesn’t make it valid.
No. A logical and rational explanation makes something valid.
I see nothing pedantic in flagging capitalisation errors, but I see loads wrong with imposing one’s sloppiness on others.
Sure you do, you see a crime where no crime happened. Read my post carefully. I imposed nothing. A standard was imposed onto me. I didn't in turn impose anything on anyone else.
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.
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:
> Give me a fucking break.
...seems shallow / callous.
I highly disagree. You are judging a book by it's cover. Capitalization is no different from handwriting. Substance matters, capitalization and grammar are superficial. If meaning is captured then capitalization does not intrinsically matter.
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.
Not to make a point of it either way, but judging a book by its cover can be useful if the credibility of the book's content alone is difficult to evaluate. That's why people care about degrees and other qualifications.
There are plenty of other ways. Book reviews for example. If the cover is the only way than so be it, but this is rarely case. Additionally the cover of a book, like capitalization is one of the most inaccurate metrics to judge a book by.
My point is that a questionable cover can indicate problems. I agree that one should be as holistic as possible.
In programming, capitalization does matter. Sorry.
It doesn’t. I don’t know how something so simple can’t be understood. Does capitalization matter in math or algebra or logic? No. It doesn’t. Why? Because capitalization is a concept exclusive to language, and not just any language, but an arbitrary family of languages similar to English. The concept for example does not exist in Chinese.
But you know this. Are you trolling?
Sure, but we program using programming languages, mostly using the Latin alphabet you are referring to. And yes the syntax for many of those programming languages is in fact case sensitive.
Obviously. The topic is about whether case sensitivity + capitalization matters not whether it exists. My claim is it doesn’t matter much. Whether you use I or i in your for loop as an index doesn’t matter.
And it’s completely irrelevant to logic or math. So whether or not you choose to make capitalization matter in your program is a completely arbitrary choice. It’s like snake case and cane case. You choose one style for consistency but in the end even if you use both styles in your program there is zero practical downside. The only downside is people with ocd get all worked up and don’t have the capacity to understand that it doesn’t matter.
You are correct, and it will be fixed!
All this for writing Rust as rust! Wow! Tell me you have ADHD without telling me you have ADHD, just get on with the work and let others do their work. Don't flag their entire work. Linguistics is very inclusive. I took a course on it. No need to be a grammar nazi
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...
What do you mean by "made-up quote"? The author didn't make it up, see https://en.wikipedia.org/wiki/A_journey_of_a_thousand_miles_...
This level of nit-picking is disheartening...
I think they meant:
> "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
The reference is most likely to:
> "If you can't explain it simply, you don't understand it well enough."
Which TFA (and others) misattribute to Einstein
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.
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.
For what it's worth, I've found the Rust-y explanations well worth the read! Please keep them in, it's really interesting to read about the technicalities.
> 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.
They might be focused on programmers, not users. Programmers come first because otherwise users don't come at all.
C would have been a more natural/neutral choice to be honest for a project like this, since every OS actually used is written in C.
This is a bad thing we should try to change
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?
Source of ready-to-go software for use/testing?
That's actually an interesting idea, the main reason is that I wanted to take a doom port that is posix compliant and see if I can make it run
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).
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.
Any chance you meant MIT 6.828? The course you mention (6.824) seems to be Distributed Systems.
My mistake, yes indeed it’s 6.828. On a side note, for distributed systems 6.824 is on my list after I finish 15-445 from cmu :)
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.
That's a good suggestion to OP but as a user, I find it adds character and makes it feel human in an increasingly LLM-polished internet.
That's how I used to feel about spelling and grammar checkers. I was wrong. Maybe you are, too.
Because I didn't really publish it, I didn't check all the grammar and type errors
This is something I will improve when the initial release will come
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.
To the author, I appreciate your effort here!
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.
And* many more ;)
Thanks ....
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.
In case anyone is curious, I very recently released a small demo kernel for RISC-V here: https://github.com/ajxs/straylight
This project started because I wanted to understand the linux that sits on my computer, which is x86. There is a possibility that on the future it will have multiple architectures supported, probably starting with arm, but I can't promise that
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.
This only covers what's in https://wiki.osdev.org/Bare_Bones, but in Rust, right?
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 hope this builds on phil-opp's previous work which is IMO stellar.
I plan to cover more, like disk drivers, file systems, processes, shell, user space, processes, until we can run a working program!
Hopefully, also networking
What's the status on that? Did the series ever get finished?
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.
Title should be LearnixOS : POSIX compliant OS implemented in Rust.
I should do the same book in Swift; it would be a very interesting project! I wish I had that kind of time…
I spotted at least 3 typos in the first minute. Typos are really easily detected and fixed with LLMs (one really good usage of them).
But it's nice to have non-LLM written text. Still the many typos are annoying and distracting.
Looking forward to going through the lessons
FLY
what's FLY?
pretty sure it means cool like 'thats so fly'
If you are interested in Nix but dont want to abandon MacOS you should check out Nix Darwin.