Writing a Unix clone in about a month

Original Article ↗ Hacker News Discussion ↗

A new Unix-like operating system built in about a month impresses many, but prompts reminders that such speed rests on years of prior low-level experience and extensive code reuse from an earlier kernel project. Commenters explore the project’s use of the Hare programming language, debating its deliberate constraints—no official Windows/macOS support, weaker optimization, limited multithreading, no standard hash table—as a trade-off between ideological purity, simplicity, and real-world adoption. The thread also branches into broader reflections on OS history, Unix signals and IPC design, and how modern software complexity contrasts with the relatively small, focused systems of earlier eras.

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.