Comment by renehsz

Comment by renehsz 2 days ago

34 replies

View on Hacker News

The Plan 9 operating system.

It's the closest thing to a Unix successor we ever got, taking the "everything is a file" philosophy to another level and allowing to easily share those files over the network to build distributed systems. Accessing any remote resources is easy and robust on Plan9, meanwhile on other systems we need to install specialized software with bad interoperability for each individual use case.

Plan9 also had some innovative UI features, such as mouse chording to edit text, nested window managers, the Plumber to run user-configurable commands on known text patterns system-wide, etc.

Its distributed nature should have meant it's perfect for today's world with mobile, desktop, cloud, and IoT devices all connected to each other. Instead, we're stuck with operating systems that were never designed for that.

There are still active forks of Plan9 such as 9front, but the original from Bell Labs is dead. The reasons it died are likely:

- Legal challenges (Plan9 license, pointless lawsuits, etc.) meant it wssn't adopted by major players in the industry.

- Plan9 was a distributed OS during a time when having a local computer became popular and affordable, while using a terminal to access a centrally managed computer fell out of fashion (though the latter sort of came back in a worse fashion with cloud computing).

- Bad marketing and posing itself as merely a research OS meant they couldn't capitalize on the .com boom.

- AT&T lost its near endless source of telephone revenue. Bell Labs was sold multiple times over the coming years, a lot of the Unix/Plan9 guys went to other companies like Google.

teddyh 2 days ago

> The reasons it died are likely:

The reason Plan 9 died a swift death was that, unlike Unix – which hardware manufacturers could license for a song and adapt to their own hardware (and be guaranteed compatibility with lots of Unix software) – Bell Labs tried to sell Plan 9, as commercial software, for $350 a box.

(As I have written many times in the past: <https://news.ycombinator.com/item?id=22412539>, <https://news.ycombinator.com/item?id=33937087>, and <https://news.ycombinator.com/item?id=43641480>)

Reply View 3 replies
  • EdiX 2 days ago

    Version 1 was never licensed to anyone. Version 2 was only licensed to universities for an undiscolsed price. Version 3 was sold as a book, I think this is the version you are referring to. However note that this version contained a license that only allowed non commercial uses of the source code. It also came with no support, no community and no planned updates (the project was shelved half a year later in favor of inferno)

    More than the price tag the problem is that plan 9 wasn't really released until 2004.

    Reply View 0 replies
  • Shugyousha a day ago

    Strictly speaking, it's not dead. The code is now open source and all the rights are with the Plan 9 foundation: https://p9f.org/

    It's just unlikely that it will get as big of a following as Linux has.

    Reply View 0 replies
  • pjmlp a day ago

    Had UNIX also been something like other OSes price points, instead of a song as you say, it would never even taken off, it was more about the openess and being crazy cheap than the alternatives, than anything else.

    Reply View 0 replies
pjmlp a day ago

The team moved on to work on Inferno, which Plan 9 afficionados tend to forget about, which was also a much better idea as UNIX evolution, Plan 9 combined with a managed userspace, which also didn't went down well.

Reply View 0 replies
mycall 2 days ago

Plan 9 Filesystem Protocol lives on inside WSL2.

Reply View 2 replies
  • ajross 2 days ago

    9P is used everywhere in the VM ecosystem. It's clean and simple and well supported by almost all guests.

    Reply View 0 replies
tjchear 2 days ago

What’s stopping other Unix-like systems from adopting the everything is a file philosophy?

Reply View 20 replies
  • c0balt 2 days ago

    Probably that not everything can be cleanly abstracted as a file.

    One might want to, e. G., have fine control over a how a network connection is handled. You can abstract that as a file but it becomes increasingly complicated and can make API design painful.

    Reply View 3 replies
    • Someone 2 days ago

      > Probably that not everything can be cleanly abstracted as a file.

      I would say almost nothing can be cleanly abstracted as a file. That’s why we got ioctl (https://en.wikipedia.org/wiki/Ioctl), which is a bad API (calls mean “do something with this file descriptor” with only conventions introducing some consistency)

      Reply View 2 replies
      • naasking a day ago

        Everything can be abstracted as a file, it just may not be most efficient interface.

        Reply View 1 reply
        • vacuity a day ago

          If everything can be represented as a Foo or as a Bar, then this actually clears up the discussion, allowing the relative merits of each representation to be discussed. If something is a universal paradigm, all the better to compare it to alternatives, because one will likely be settled on (and then mottled with hacks over time; organic abstraction sprawl FTW).

          Reply View 0 replies
  • WD-42 2 days ago

    They have to an extent. The /proc file system on Linux is directly inspired by plan 9 IIRC. Other things like network sockets never got that far and are more related to their BSD kin.

    Reply View 6 replies
    • pjmlp a day ago

      Not at all, /proc comes from Solaris.

      Reply View 1 reply
      • WD-42 6 hours ago

        Looking into it we are both wrong. Plan 9 implemented /proc after 8th edition Unix. Solaris and Linux both implemented it at the same time in 1992.

        Reply View 0 replies
    • cratermoon 2 days ago

      There's also /dev/tcp in Linux

          exec 5<>/dev/tcp/www.google.com/80
    echo -e "GET / HTTP/1.1\r\nhost: www.google.com\r\nConnection: close\r\n\r\n" >&5
    cat <&5
      Reply View 3 replies
      • Zambyte 2 days ago

        /dev/tcp does not exist in Linux.

            ls /dev/tcp
        It is an abstraction in GNU Bash.
        Reply View 2 replies
  • mike_hearn a day ago

    The fact that everything is not a file. No OS actually implements that idea including Plan9. For example, directories are not files. Plan9 re-uses a few of the APIs for them, but you can't use write() on a directory, you can only read them.

    Pretending everything is a file was never a good idea and is based on an untrue understanding of computing. The everything-is-an-object phase the industry went through was much closer to reality.

    Consider how you represent a GUI window as a file. A file is just a flat byte array at heart, so:

    1. What's the data format inside the file? Is it a raw bitmap? Series of rendering instructions? How do you communicate that to the window server, or vice-versa? What about ancillary data like window border styles?

    2. Is the file a real file on a real filesystem, or is it an entry in a virtual file system? If the latter then you often lose a lot of the basic features that makes "everything is a file" attractive, like the ability to move files around or arrange them in a user controlled directory hierarchy. VFS like procfs are pretty limited. You can't even add your own entries like adding symlinks to procfs directories.

    3. How do you receive callbacks about your window? At this point you start to conclude that you can't use one file to represent a useful object like a window, you'd need at least a data and a control file where the latter is some sort of socket speaking some sort of RPC protocol. But now you have an atomicity problem.

    4. What exactly is the benefit again? You won't be able to use the shell to do much with these window files.

    And so on. For this reason Plan9's GUI API looked similar to that of any other OS: a C library that wrapped the underlying file "protocol". Developers didn't interact with the system using the file metaphor, because it didn't deliver value.

    All the post-UNIX operating system designs ignored this idea because it was just a bad one. Microsoft invested heavily in COM and NeXT invested in the idea of typed, IDL-defined Mach ports.

    Reply View 5 replies
    • pjmlp a day ago

      Unfortunely Microsoft didn't invest heavily enough on COM tooling, it sucks in 2025 as much as in the 1990's.

      Reply View 4 replies
      • mike_hearn a day ago

        Sure, why would they? COM was rendered irrelevant by the move to the web. Microsoft lost out on the app serving side, and when they dropped the ball on ActiveX by not having proper UI design or sandboxing they lost out on the client too. Probably the primary use case outside of legacy OPC is IT departments writing PowerShell scripts or Office plugins (though those are JS based now too).

        COM has been legacy tech for decades now. Even Microsoft's own security teams publish blog posts enthusiastically explaining how they found this strange ancient tech from some Windows archaeological dig site, lol. Maybe one day I'll be able to mint money by doing maintenance consulting for some old DCOM based systems, the sort of thing where knowing what an OXID resolver is can help and AI can't do it well because there's not enough example code on GitHub.

        Reply View 3 replies
  • IshKebab 2 days ago

    Probably the fact that it's a pretty terrible idea. It means you take a normal properly typed API and smush it down into some poorly specified text format that you now have to write probably-broken parsers for. I often find bugs in programs that interact with `/proc` on Linux because they don't expect some output (e.g. spaces in paths, or optional entries).

    The only reasons people think it's a good idea in the first place is a) every programming language can read files so it sort of gives you an API that works with any language (but a really bad one), and b) it's easy to poke around in from the command line.

    Essentially it's a hacky cop-out for a proper language-neutral API system. In fairness it's not like Linux actually came up with a better alternative. I think the closest is probably DBus which isn't exactly the same.

    Maybe something like FIDL is a proper solution but I have only read a little about it: https://fuchsia.dev/fuchsia-src/get-started/learn/fidl/fidl

    Reply View 2 replies
    • vacuity a day ago

      I think you have to standardize a basic object system and then allow people to build opt-in interfaces on top, because any single-level abstraction will quickly be pulled in countless directions for as many users.

      Reply View 1 reply
AfterHIA a day ago

UNIX is for dorks. We needed a Smalltalk style, "everything is an object and you can talk to all objects" but thankfully we got Java and, "object oriented" C++. The Alto operating system was leaps and bounds ahead of the Mac and Windows 3.1 system and it took Steve Jobs a decade to realize, "oh shit we could have just made everything an object." Then we get WebObjects and the lousy IPod and everything is fascist history.

#next #never #forget #thieves

Reply View 3 replies
  • pjmlp a day ago

    I had a UNIX zealot phase back in the 1990's, until the university library opened my eyes to Xerox PARC world, tucked away at the back there were all the manuals and books about Smalltalk from Xerox, eventually I also did some assigments with Smalltalk/V, and found a way to learn about Interlisp and Mesa/Cedar as well.

    My graduation project was porting a visualisation framework from Objective-C/NeXTSTEP to Windows.

    At the time, my X setup was a mix of AfterStep or windowmaker, depending on the system I was at.

    Reply View 0 replies
  • fud101 a day ago

    Plan9 fanboys are some of the dumbest well meaning idiots you'll find. It's kind of adorable.

    Reply View 0 replies