Here's a summary of the key themes emerging from the Hacker News discussion, with supporting quotes:
Interest in Amoeba and its Historical Context
The discussion starts with a general interest in the Amoeba OS project.
- "Thanks for sharing! Never heard about it but seems like an interesting project." - haunter
The conversation mentions the readily available archived code and the ability to resurrect it for exploration in VMs.
- "Seems to be the source code was archived, I wonder if it's bootable in a VM. Well I know what'll do this weekend!" - haunter
Connection to the Tanenbaum-Torvalds Debate and Hardware Requirements
Participants link Amoeba to Andrew S. Tanenbaum and the famous "LINUX is obsolete" debate, highlighting the hardware requirements of Amoeba at the time.
- "This is what prof Andrew S. Tanenbaum was working on when he made the famous "LINUX is obsolete" post in 1992." - sampo
- ""A bunch of high spec 386s with specific network cards" was pretty unaffordable for (especially young, and most were at the time) hobbyists in '92. We know how it went with that and Linux (which ran on most cheap 386s)." - ahartmetz
The "Worse is Better" Philosophy
The discussion delves into the "worse is better" philosophy, examining how less technically elegant but more accessible solutions often gain wider adoption. This expands to include the trade-offs of choosing approaches for their ease of access versus long-term maintainability.
- "My take on 'worse is better' is that 'worse is cheap / free / low friction.'" - api
- "Better -- meaning polished, thoroughly engineered, correct, etc. -- is often heavier in terms of hardware requirements. It's also often a lot of work by serious career devs or big companies and costs money and has a non-OSS license." - api
- "All that increases not only cost but more importantly friction. So the "worse" cheap/free unencumbered thing goes viral and takes over instead." - api
- "I should add the caveat though -- it's cheap/free up front but you pay later in bugs and ugly hacks to make it work at larger scale. But up front friction matters more than friction later. If it's cheap/free in terms of cost or friction now, you'll already have sunk cost by the time the real cost becomes apparent." - api
- "I 100% agree. In fact, even in the original C/Unix versus Lisp/Lisp machines that were mentioned in Richard's Gabriel "The Rise of Worse is Better" article, C and Unix were inexpensive compared to Lisp implementations and Lisp machines." - linguae
Smalltalk and Alternative Development Options
The conversation branches slightly to compare to smalltalk, and reasons for alternatives succeeding more in the market.
- "Another example is how C++ and Java, but not Smalltalk, became the dominant object-oriented programming languages in the 1990s, despite Smalltalk being older and (debatably) being closer to Richard Gabriel's "right thing". There were affordable C++ implementations from Borland and Microsoft, and Sun released the Java Development Kit for free. However, the leading Smalltalk implementations of the 1990s were much more expensive." - linguae
Hardware Affordability and Early Linux Experiences
Several users share their personal experiences with early Linux adoption, focusing on the cost of hardware (RAM in particular) and the limitations of running it on lower-end machines.
- "Coming from Commodore Amiga, my first PC was a 486dx with 4MB to run Linux. I did set it up the same day I bought it - noticed 4MB was not enough to run XFree86 on top of Linux 0.99.6 or whatever, so I grumbled, checked my wallet and bank account, went back to the dealer and asked him to take back the 4MB memory and sell me 16MB of RAM." - froh42
- "I ran Linux on a 486SX with 4MB RAM in early 1994. Prior to that (1993?) I had been running 386BSD. Both OSes ran quite well on that hardware: certainly sh, vi, gcc, and make ran well, and what else do you really need?" - mediumdave
- "4MB wasn't good enough for X Windows, but I had a VT102 connected to a serial port so that I could have two terminal sessions going at the same time." - mediumdave
Distributed Systems and the Path Not Taken
A significant portion of the discussion centers around the abandoned research into distributed operating systems like Amoeba and the potential benefits and challenges of that approach. There's a sense that this area of research was promising but ultimately overtaken by different architectural trends.
- "There was so much interesting research on distributed systems back then that was wholly abandoned." - api
- "Had we taken this path, you might be able to create a distributed instance of an OS and just throw hardware at it -- boxes or VMs -- and tasks would run on it like a single OS with little or no modification. It'd be like having an infinite giant box." - api
- "Under the hood these distributed OSes were orchestrators like K8S, just hidden from you for the most part behind a Posix emulation layer that made it look like one box." - api
Modern Serverless Architectures as an Alternative Vision
The conversation pivots towards modern "serverless" architectures as a potentially superior alternative to the distributed OS model, emphasizing the benefits of stateless functions and shared global databases.
- "Ultimately I think the type of architecture you see with "serverless" where everything is a "function" with no side effects that can talk to one or more shared global databases is the better architecture. Do away with the entire concept of a "box" in favor of a sea of functions that call each other, event queues, schedulers, etc. We do kind of have that, but only in the form of proprietary serverless platforms." - api
- "The amount of complexity we inflict on ourselves by dragging along the concept of unmanaged / unbounded global state, static state, and side effects is mind boggling. A function should only operate on what you give it." - api
Reflection on Academia vs. Industry Needs
Some participants reflect on the gap between academic research (like Amoeba) and the practical needs of the industry at the time, suggesting that stability and clustering were more pressing concerns than the theoretical benefits of a distributed OS.
- "I guess academia was too far from what industry needed. They where thinking about the future, and we needed more stable boxes and sometimes a cluster for critical loads." - eb0la
Possibility of a Distributed OS Research Rebirth
The discussion concludes with a suggestion that the time might be right for a renewed focus on distributed OS research, given advancements in infrastructure and the potential for Kubernetes to benefit from fresh ideas.
- "I wonder if the time is right for a distributed OS research rebirth, now that we have many layers of infra advancement to develop and host it on. Kubernetes needs some fresh ideas." - imglorp