Writing a Unix clone in about a month

Original Article ↗ Hacker News Discussion ↗

Overall reaction

  • Many commenters find the project impressive and inspiring, especially given the ~month timescale.
  • Several stress that this kind of “X in N days” feat rests on years of prior low-level experience, not beginner-level work.
  • Some argue that building a minimal Unix-like kernel is a standard advanced–undergrad-level exercise; the standout factor here is completeness and perseverance.

Prior work and experience

  • Commenters note the reuse of code from an earlier kernel project, plus earlier OS work on calculators, as key enablers of speed.
  • This reuse is generally framed as part of the accumulated experience rather than a shortcut that undermines the achievement.

Hare language: philosophy and trade-offs

  • There is interest in Hare as a systems language distinct from C, Zig, Odin, etc.
  • A major debate centers on Hare’s official stance of not supporting Windows or macOS.
    • Critics see it as self-limiting “purity” that will constrain adoption and ecosystem growth.
    • Defenders say the project optimizes for its own goals, not maximal reach, and that others are free to maintain ports.
  • FAQ points draw mixed reactions: no package manager, weaker optimizations vs. LLVM, “probably not” multithreading, and no standard hash map.
    • Some find these principled and simplicity-driven.
    • Others view lack of multithreading and basic data structures as deal-breakers for serious use.

Compiler and performance considerations

  • Avoiding LLVM is seen as reducing dependency and complexity, improving compile times, and enabling self-hosted systems work.
  • Some report that non-optimizing compilers are fine for most apps; performance issues mainly matter for heavy number-crunching.

Unix design, history, and comparisons

  • The project prompts recollections of early Unix and other Unix-like systems written in non-C languages (Pascal, Ada, Concurrent Euclid).
  • Several comments revisit the origin story of Unix, emphasizing it built on extensive prior work (e.g., Multics) and evolved over years.

Signals and OS mechanisms

  • A substantial subthread discusses Unix signals as a weak, historically constrained abstraction:
    • Signals conflate multiple roles: async external events, sync internal faults, and process control.
    • They’re race-prone and interact awkwardly with system calls and reentrancy.
  • Alternatives and improvements mentioned include async-only syscalls, richer IPC primitives, Plan 9–style notes, VMS mailboxes, and Windows structured exceptions.

Learning resources and tangents

  • A classic Unix programming book series and educational OSes are recommended for understanding signals and kernel internals.
  • Side discussions touch on GPUs as first-class OS citizens, difficulties of GPU driver development, and the growing size of system images vs. early kernels.