{"slug": "unix", "name": "Unix", "category": "os", "category_name": "Operating systems and desktop", "description": "", "recommenders": 5, "commenters": 11, "warners": 3, "score": 2.33, "rising": -0.31, "first": "2025-11-25", "latest": "2026-10-16", "why": "Unix and Linux would be your quintessential examples.", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 5, "neutral": 2, "compare": 1, "warn": 4}, "spark": [1, 1, 0, 0, 0, 2, 0, 0, 0, 0, 1, 0], "listed": true, "loved": [], "caveat": "", "short_quote": "Unix and Linux would be your quintessential examples.", "kind": "", "icon": false, "domain": null, "github_repo": null, "official_url": "", "pricing": "", "aliases": ["Unix", "UNIX"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 798015602, "item_id": 49875975, "url": "https://news.ycombinator.com/item?id=49875975", "by": "trashb", "date": "2026-09-28", "version": null, "stance": "recommend", "quote": "the idea of malleable software is at the core of unix everything is a file", "excerpt": "I agree that the current state of software is quite rigid. There is no room for imperfection and often one opinion is seen as fixed the best. I think the essence of the GPL is trying to solve this issue, the freedoms of that license is focused on keeping software as editable as possible. The idea of malleable software is not new but most \"business/industry\" software is still very rigid. One of the more interesting re", "context": "", "use_case": "", "switched_from": "", "story": "Malleable software: Restoring user agency in a world of locked-down apps (2025)"}, {"id": 765214369, "item_id": 47825898, "url": "https://news.ycombinator.com/item?id=47825898", "by": "pjmlp", "date": "2026-04-19", "version": null, "stance": "recommend", "quote": "the beloved UNIX and C are from 1971 - 73", "excerpt": "Both languages have their standards updated still, latest year in both cases was 2023. Fortran is one of the reasons OpenCL lost to CUDA, and now even AMD and Intel have finally Fortran support on their own stacks, not Khronos based. https://developer.nvidia.com/cuda-fortran Whereas Cobol, even has cloud and microservices. https://www.rocketsoftware.com/en-us/products/cobol/visual-cobol https://aws.amazon.com/mainfra", "context": "", "use_case": "", "switched_from": "", "story": "The seven programming ur-languages"}, {"id": 763801920, "item_id": 47737620, "url": "https://news.ycombinator.com/item?id=47737620", "by": "d0mine", "date": "2026-04-12", "version": null, "stance": "recommend", "quote": "To get perspective(we know what worked)", "excerpt": "To get perspective(we know what worked), here\u2019s some 50+ years abstractions: A file is a simple stream of bytes in Unix. (If you think what else it might be then compare to Multics\u2019 segments). Separate processes that may be connected using simple standard I/O streams [pipe] (vs everything is DLL in Multics) \u2014 the concept of shell itself (policy vs. mechanism separation http://www.catb.org/esr/writings/taoup/html/ch01", "context": "", "use_case": "", "switched_from": "", "story": "How Complex is my Code?"}, {"id": 738559840, "item_id": 46159990, "url": "https://news.ycombinator.com/item?id=46159990", "by": "1718627440", "date": "2025-12-05", "version": null, "stance": "recommend", "quote": "A common namespace composed as a tree makes sense to me.", "excerpt": "I don't know about you. A common namespace composed as a tree makes sense to me. Splitting of user data makes sense to me. Splitting data from code executable code make sense to me. Splitting configuration from other data does. So does splitting code into executables and libraries, splitting into per machine/shared, and splitting into core OS and other (now reversed). The actual names don't matter all that much, but ", "context": "", "use_case": "", "switched_from": "", "story": "Windows drive letters are not limited to A-Z"}, {"id": 736770752, "item_id": 46048172, "url": "https://news.ycombinator.com/item?id=46048172", "by": "BenoitEssiambre", "date": "2025-11-25", "version": null, "stance": "recommend", "quote": "Unix and Linux would be your quintessential examples.", "excerpt": "Unix and Linux would be your quintessential examples. Unix was an effort to take Multics, an operating system that had gotten too modular, and integrate the good parts into a more unified whole (book recommendation: https://www.amazon.com/UNIX-History-Memoir-Brian-Kernighan/dp/1695978552/). Even though there were some benefits to the modularity of Multics (apparently you could unload and replace hardware in Multics s", "context": "", "use_case": "", "switched_from": "Multics", "story": "Trillions spent and big software projects are still failing"}]}], "caveats": [{"label": "", "summary": "", "quotes": [{"id": 796023504, "item_id": 49751469, "url": "https://news.ycombinator.com/item?id=49751469", "by": "leoc", "date": "2026-09-18", "version": null, "stance": "warn", "quote": "that's not Unix's only design shortcoming", "excerpt": "Old comment https://news.ycombinator.com/item?id=10774245 repaste: > People seem to have forgotten that when Perl evolved from being a better AWK to the paradigm example of the modern \"scripting language\", Larry Wall explicitly described this as a rejection of the Unix small-tools philosophy. https://web.archive.org/web/20070204053516/http://www.linux-mag.com/id/322/ (\"But Perl was actually much more countercultural ", "context": "", "use_case": "", "switched_from": "", "story": "Unix Was Right. We Made Linux Too Complicated [video]"}, {"id": 774624480, "item_id": 48414030, "url": "https://news.ycombinator.com/item?id=48414030", "by": "foobar1274278", "date": "2026-06-05", "version": null, "stance": "warn", "quote": "whose shitty Multics ripoff directly inspired", "excerpt": "Hilarious coming from the guy whose shitty Multics ripoff directly inspired \"Worse is Better\" From the essay: \"Unix and C are the ultimate computer viruses. A further benefit of the worse-is-better philosophy is that the programmer is conditioned to sacrifice some safety, convenience, and hassle to get good performance and modest resource use. Programs written using the New Jersey approach will work well both in smal", "context": "", "use_case": "", "switched_from": "", "story": "C++: The Documentary Released Today"}, {"id": 759539120, "item_id": 47471195, "url": "https://news.ycombinator.com/item?id=47471195", "by": "jonjacky", "date": "2026-03-21", "version": null, "stance": "warn", "quote": "Maybe Unix got it wrong.", "excerpt": "Rob Pike, one of the Unix developers, observed people turning away from their philosophy back in 2001: The Good, the Bad, and the Ugly: The Unix Legacy http://herpolhode.com/rob/ugly.pdf \"What Unix does well isn\u2019t what people want. ... People prefer integrated environments and browsers. ... Perhaps people don\u2019t want to think about problem solving this way. Maybe Unix got it wrong. (Even within Unix, the tool approach", "context": "", "use_case": "", "switched_from": "", "story": "Unix philosophy is dead Long live something else?"}, {"id": 749876944, "item_id": 46867309, "url": "https://news.ycombinator.com/item?id=46867309", "by": "pjmlp", "date": "2026-02-02", "version": null, "stance": "warn", "quote": "UNIX design was so great that its authors did two other operating systems", "excerpt": "I love how people worship UNIX design in Linux circles, especially when complaining about decisions where Linux is catching up with commercial UNIXes, as in the init systems replacements. UNIX design was so great that its authors did two other operating systems trying to make UNIX done right. One of the few times I agree with Rob Pike, > We really are using a 1970s era operating system well past its sell-by date. We ", "context": "", "use_case": "", "switched_from": "", "story": "Linux from Scratch Ends SysVinit Support"}]}], "who": [], "tags": [], "use_cases": ["original unix on emulator"], "compared": [{"slug": "microsoft-windows", "name": "Microsoft Windows", "co": 2, "switched_from": 0, "switched_to": 0}, {"slug": "plan-9", "name": "Plan 9", "co": 2, "switched_from": 0, "switched_to": 0}], "makers": [], "threads": [{"url": "https://news.ycombinator.com/item?id=50118311", "title": "I'm Fucking Done with Slop", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49869755", "title": "Malleable software: Restoring user agency in a world of locked-down apps (2025)", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49749231", "title": "Unix Was Right. We Made Linux Too Complicated [video]", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=48408016", "title": "C++: The Documentary Released Today", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=47822486", "title": "The seven programming ur-languages", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=47673171", "title": "How Complex is my Code?", "mentions": 1}], "sentiment_by_month": {"2025-11": {"recommend": 1}, "2025-12": {"recommend": 1, "compare": 1}, "2026-01": {}, "2026-02": {"warn": 1}, "2026-03": {"neutral": 1, "warn": 1}, "2026-04": {"recommend": 2}, "2026-05": {}, "2026-06": {"warn": 1}, "2026-07": {}, "2026-08": {}, "2026-09": {"warn": 1, "recommend": 1}, "2026-10": {"neutral": 1}}, "versions": [], "version_unnamed": 0, "family_ref": null, "runs_on": null, "lines": [], "quotes": [{"id": 801976226, "item_id": 50123514, "url": "https://news.ycombinator.com/item?id=50123514", "by": "DonHopkins", "date": "2026-10-16", "version": null, "stance": "neutral", "quote": "the PDP-7 emulator also runs the original version of Unix flawlessly", "excerpt": "The PDP-7 Forth that Mitch Bradley and Claude just wrote in one day is high quality, efficient, beautiful, well commented, and uniquely designed. The PDP-7 is the 18-bit machine the first version of Unix was written on. It turns out that the PDP-7 instruction set is perfect for Forth, and the \"next\" inner interpreter is only three instructions, the first being the \"xct\" execute indirect instruction. It's one of the m", "context": "", "use_case": "Original Unix on emulator", "switched_from": "", "story": "I'm Fucking Done with Slop"}, {"id": 798015602, "item_id": 49875975, "url": "https://news.ycombinator.com/item?id=49875975", "by": "trashb", "date": "2026-09-28", "version": null, "stance": "recommend", "quote": "the idea of malleable software is at the core of unix everything is a file", "excerpt": "I agree that the current state of software is quite rigid. There is no room for imperfection and often one opinion is seen as fixed the best. I think the essence of the GPL is trying to solve this issue, the freedoms of that license is focused on keeping software as editable as possible. The idea of malleable software is not new but most \"business/industry\" software is still very rigid. One of the more interesting re", "context": "", "use_case": "", "switched_from": "", "story": "Malleable software: Restoring user agency in a world of locked-down apps (2025)"}, {"id": 796023504, "item_id": 49751469, "url": "https://news.ycombinator.com/item?id=49751469", "by": "leoc", "date": "2026-09-18", "version": null, "stance": "warn", "quote": "that's not Unix's only design shortcoming", "excerpt": "Old comment https://news.ycombinator.com/item?id=10774245 repaste: > People seem to have forgotten that when Perl evolved from being a better AWK to the paradigm example of the modern \"scripting language\", Larry Wall explicitly described this as a rejection of the Unix small-tools philosophy. https://web.archive.org/web/20070204053516/http://www.linux-mag.com/id/322/ (\"But Perl was actually much more countercultural ", "context": "", "use_case": "", "switched_from": "", "story": "Unix Was Right. We Made Linux Too Complicated [video]"}, {"id": 774624480, "item_id": 48414030, "url": "https://news.ycombinator.com/item?id=48414030", "by": "foobar1274278", "date": "2026-06-05", "version": null, "stance": "warn", "quote": "whose shitty Multics ripoff directly inspired", "excerpt": "Hilarious coming from the guy whose shitty Multics ripoff directly inspired \"Worse is Better\" From the essay: \"Unix and C are the ultimate computer viruses. A further benefit of the worse-is-better philosophy is that the programmer is conditioned to sacrifice some safety, convenience, and hassle to get good performance and modest resource use. Programs written using the New Jersey approach will work well both in smal", "context": "", "use_case": "", "switched_from": "", "story": "C++: The Documentary Released Today"}, {"id": 765214369, "item_id": 47825898, "url": "https://news.ycombinator.com/item?id=47825898", "by": "pjmlp", "date": "2026-04-19", "version": null, "stance": "recommend", "quote": "the beloved UNIX and C are from 1971 - 73", "excerpt": "Both languages have their standards updated still, latest year in both cases was 2023. Fortran is one of the reasons OpenCL lost to CUDA, and now even AMD and Intel have finally Fortran support on their own stacks, not Khronos based. https://developer.nvidia.com/cuda-fortran Whereas Cobol, even has cloud and microservices. https://www.rocketsoftware.com/en-us/products/cobol/visual-cobol https://aws.amazon.com/mainfra", "context": "", "use_case": "", "switched_from": "", "story": "The seven programming ur-languages"}, {"id": 763801920, "item_id": 47737620, "url": "https://news.ycombinator.com/item?id=47737620", "by": "d0mine", "date": "2026-04-12", "version": null, "stance": "recommend", "quote": "To get perspective(we know what worked)", "excerpt": "To get perspective(we know what worked), here\u2019s some 50+ years abstractions: A file is a simple stream of bytes in Unix. (If you think what else it might be then compare to Multics\u2019 segments). Separate processes that may be connected using simple standard I/O streams [pipe] (vs everything is DLL in Multics) \u2014 the concept of shell itself (policy vs. mechanism separation http://www.catb.org/esr/writings/taoup/html/ch01", "context": "", "use_case": "", "switched_from": "", "story": "How Complex is my Code?"}, {"id": 759539120, "item_id": 47471195, "url": "https://news.ycombinator.com/item?id=47471195", "by": "jonjacky", "date": "2026-03-21", "version": null, "stance": "warn", "quote": "Maybe Unix got it wrong.", "excerpt": "Rob Pike, one of the Unix developers, observed people turning away from their philosophy back in 2001: The Good, the Bad, and the Ugly: The Unix Legacy http://herpolhode.com/rob/ugly.pdf \"What Unix does well isn\u2019t what people want. ... People prefer integrated environments and browsers. ... Perhaps people don\u2019t want to think about problem solving this way. Maybe Unix got it wrong. (Even within Unix, the tool approach", "context": "", "use_case": "", "switched_from": "", "story": "Unix philosophy is dead Long live something else?"}, {"id": 759134034, "item_id": 47445877, "url": "https://news.ycombinator.com/item?id=47445877", "by": "hilliardfarmer", "date": "2026-03-19", "version": null, "stance": "neutral", "quote": "Unix is a great operating system", "excerpt": "We used to live in that world! Until the 1970s in the US, you actually couldn't take on debt or get a credit card if you had no way to repay it. But liberals pushed for a new law that made it so anybody could access credit and when you open up systems to everyone then the quality goes down dramatically. We basically do this with everything. Unix is a great operating system, but the Mac version, made for morons, is pr", "context": "", "use_case": "", "switched_from": "", "story": "Android: Balancing Openness and Choice with Safety"}, {"id": 749876944, "item_id": 46867309, "url": "https://news.ycombinator.com/item?id=46867309", "by": "pjmlp", "date": "2026-02-02", "version": null, "stance": "warn", "quote": "UNIX design was so great that its authors did two other operating systems", "excerpt": "I love how people worship UNIX design in Linux circles, especially when complaining about decisions where Linux is catching up with commercial UNIXes, as in the init systems replacements. UNIX design was so great that its authors did two other operating systems trying to make UNIX done right. One of the few times I agree with Rob Pike, > We really are using a 1970s era operating system well past its sell-by date. We ", "context": "", "use_case": "", "switched_from": "", "story": "Linux from Scratch Ends SysVinit Support"}, {"id": 740337681, "item_id": 46271105, "url": "https://news.ycombinator.com/item?id=46271105", "by": "retrac", "date": "2025-12-14", "version": null, "stance": "compare", "quote": "simpler than the Unix process model", "excerpt": "I've written a little bit before about KeyKOS/GNOSIS, which is the capability operating system used by Tymshare to host their timesharing language services on IBM mainframes, in the 70s and 80s. From a comment 3 years ago I'll just repost the relevant part: > KeyKOS (developed by Tymshare for their commercial computing services in the 1970s) - A capability operating system. If everything in UNIX was a file, then ever", "context": "", "use_case": "", "switched_from": "", "story": "CapROS: Capability-Based Reliable Operating System"}, {"id": 738559840, "item_id": 46159990, "url": "https://news.ycombinator.com/item?id=46159990", "by": "1718627440", "date": "2025-12-05", "version": null, "stance": "recommend", "quote": "A common namespace composed as a tree makes sense to me.", "excerpt": "I don't know about you. A common namespace composed as a tree makes sense to me. Splitting of user data makes sense to me. Splitting data from code executable code make sense to me. Splitting configuration from other data does. So does splitting code into executables and libraries, splitting into per machine/shared, and splitting into core OS and other (now reversed). The actual names don't matter all that much, but ", "context": "", "use_case": "", "switched_from": "", "story": "Windows drive letters are not limited to A-Z"}, {"id": 736770752, "item_id": 46048172, "url": "https://news.ycombinator.com/item?id=46048172", "by": "BenoitEssiambre", "date": "2025-11-25", "version": null, "stance": "recommend", "quote": "Unix and Linux would be your quintessential examples.", "excerpt": "Unix and Linux would be your quintessential examples. Unix was an effort to take Multics, an operating system that had gotten too modular, and integrate the good parts into a more unified whole (book recommendation: https://www.amazon.com/UNIX-History-Memoir-Brian-Kernighan/dp/1695978552/). Even though there were some benefits to the modularity of Multics (apparently you could unload and replace hardware in Multics s", "context": "", "use_case": "", "switched_from": "Multics", "story": "Trillions spent and big software projects are still failing"}]}