LearnixOS

Project concept and naming

  • Many readers initially assumed “LearnixOS” was about NixOS; several suggest adding a clear disclaimer and/or renaming.
  • Debate over the meaning of “*nix” and whether Nix/NixOS “stepped into” that namespace; long subthread on what counts as “Unix-like” and which Unix/Unix-like systems still exist.
  • Mixed reactions to the name: some find “Learnix” awkward or pretentious, others like it and note the domain is already owned. Some see it as a “learn + Unix” portmanteau and find “OS” in the name clarifying.

Language choice and implementation focus

  • The tutorial is Rust-based and spends substantial time on Rust specifics and toolchain quirks.
  • Some want it more language-agnostic, emphasizing core OS concepts over Rust details; C is suggested as a more “neutral” choice.
  • Others argue the toolchain and language-specific hurdles are a key part of real OS development and thus worth explaining.
  • Several Rust users praise bare‑metal Rust, the avoidance of dependencies, and the accessibility of rustup as a cross‑compiler. There’s curiosity (and slight concern) about the custom 16‑bit Rust target trick.
  • Author defends including Rust deep dives but is open to marking language-heavy sections as skippable.

POSIX, architecture, and technical scope

  • Question raised: why aim for POSIX compliance in a learning/hobby OS instead of designing a fresh API?
  • Answer: POSIX enables reuse of existing software; the author specifically wants to port a POSIX Doom.
  • Some wish it used RISC‑V rather than x86 to avoid legacy complexity; author chose x86 to better understand the Linux system on their own machine, but might add other architectures later.
  • Current content overlaps with standard “bare bones” OSDev material; author plans to go further (disk drivers, AHCI, filesystems, processes, shell, networking).

Documentation quality and authenticity

  • Multiple commenters note numerous typos, inconsistent capitalization (“Rust” vs “rust”), and an apocryphal Einstein quote, suggesting this undermines perceived rigor.
  • Others defend minor errors as adding “human” character and push back against what they see as pedantic or “LLM-polished” standards.
  • Author acknowledges the issues, explains the book is still in development, and promises to polish grammar and style later.

Relation to existing resources and reception

  • Mentioned comparisons: phil‑opp’s Rust OS series, OSDev wiki, various C-based tutorials, MIT 6.828, and LFS/BLFS.
  • One commenter wishes the discussion focused more on how this project differs from those existing resources; others note its main differentiator is using Rust.
  • Overall sentiment is positive toward the ambition and educational value, with multiple readers expressing intent to follow the lessons despite concerns about naming and polish.