[HN Gopher] The Plan-9 Effect or why you should not fix it if it...
___________________________________________________________________
The Plan-9 Effect or why you should not fix it if it ain't broken
(2016)
Author : Lwrless
Score : 57 points
Date : 2022-12-10 13:05 UTC (9 hours ago)
(HTM) web link (groups.di.unipi.it)
(TXT) w3m dump (groups.di.unipi.it)
| IshKebab wrote:
| Mmm not written very well but there are some things that are
| true. I just take objection to "don't fit it if isn't broken".
| Plan 9 fixed a ton of things that were broken. Everything-is-a-
| file isn't one of them but that's not the only thing they
| changed.
|
| I think a better conclusion is that Plan 9 blew their "weirdness
| budget". I can't remember where I read it (either here or Reddit)
| but someone stated the idea of a weirdness budget.
|
| If you're making a new thing it can only be a _bit_ weird and
| different. If it 's too weird people will just stick with what
| they know and you'll be relegated to a research project that
| nobody uses.
| thom wrote:
| Things being files was never the interesting thing about Unix or
| Linux. Don't make me tap the sign:
|
| https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
| keiyakins wrote:
| This article is kinda garbage, it gets simple facts wrong in the
| first sentence of the abstract (and again in the second sentence
| of the article): Plan 9 is not Unix. At all. It shares some ideas
| with it sure, but if that's enough to make something Unix so is
| Windows NT. It's also rather debatable that it "failed" - a lot
| of good research happened there and those ideas have gone on to
| influence production environments the world over.
| RcouF1uZ4gsC wrote:
| I think the other lesson to learn is that "everything is a ..."
| abstractions don't work as well in practice as in theory.
|
| All abstractions leak. The more surface area an abstraction
| covers, the more leaky it is likely to be.
| jacquesm wrote:
| It actually works like a charm. The lack of adoption certainly
| isn't due to the 'everything is a file' abstraction layer, more
| because by the time it had been released to the masses the
| momentum in Unix / Linux was absolutely massive and super hard
| to overcome. And they in turn were under fire from Windows and
| Mac on the desktop, which left only an extremely small niche,
| one that was too small to be viable.
|
| But if you've ever worked with it then you will be longing for
| exactly those features forever and wondering why we did not
| manage to take more of its deep insights forward.
|
| A lot of really good ideas have been slaughtered on the altars
| of commerce and perceived performance improvements. As a result
| we are still developing software roughly the same way that we
| did 50 years ago, a model that wasn't ideal but that was good
| enough.
| NohatCoder wrote:
| The API/ABI structure of every modern OS is a hot mess, that
| has nothing to do with syscalls not being files, and
| everything to do with the way the systems have been extended
| over and over again for decades.
|
| Making a simpler API is a great idea, and from you comment I
| guess they mostly succeeded, but they did not have to go down
| the everything-is-a-file path to do that.
|
| What role this played in lack of adoption depends on what
| alternate course of action you compare it to. A non-file-
| based rewrite of the API would likely have had approximately
| the same result, in any case a good compatibility layer might
| have made a big difference.
| pjmlp wrote:
| There is a reason why high performance graphics and real time
| audio don't make use of file handles, rather shared memory
| (with different MMU configurations) between GPU, kernel code,
| drivers and userspace.
|
| Everything is a file is even slower than micro-kernels IPC.
| [deleted]
| foobarbecue wrote:
| First sentence made it clear I'm not the intended audience so I
| didn't read any further.
| cortesoft wrote:
| Right? I have had so many discussions about plan-9 over the
| years.
|
| A pet peeve of mine is statements like that... just because you
| just learned about something doesn't mean other people didn't
| know about it before. Even if you ask all your friends and they
| don't know, that doesn't mean different circles don't know
| about it.
| Gordonjcp wrote:
| It's okay, the second sentence was so incredibly wrong I began
| to wonder if it was a parody site.
| lokar wrote:
| Same here. Author comes off as a bit of a jerk. Stopped
| reading.
| linksnapzz wrote:
| He comes off as Italian & opinionated, and writing informally
| about a topic. He probably doesn't feel the need to be
| circumspect about his observations on his own blog. Even
| though I think he's (mostly wrong) about his conclusions, I
| wouldn't ascribe jerkishness to what is probably an
| unintended cultural impedence mismatch.
| asveikau wrote:
| > I am quite sure that you do not know what Plan-9 is and that,
| probably, you never have heard of it too.
|
| First sentence is false. Confidently, arrogantly false. I'm
| hesitant to continue reading. Assuming too much of your audience
| like that can really detract from what you have to say.
| bakul wrote:
| Even Minix, which was (IMHO) worse than Unix Version 7, was
| popular at one point! What Torvalds started from. With the advent
| of i386, many people definitely wanted something better than
| MSDOS or early Windows. If plan9 had been released as open source
| by 1992 things might've been very different.
| rjsw wrote:
| You could buy commercial UNIX for the i386 in 1985, worked
| well, I ran one version on my home PC before switching to
| 386BSD 0.1 in 1992.
| bakul wrote:
| No access to the sources was the difference.
| rjsw wrote:
| Sources were not available for MSDOS and Windows.
| CogitoCogito wrote:
| Minix is arguably more popular than its ever been given its use
| in Intel chips' management engine.
| unsafecast wrote:
| That's unrelated. It's about what people use, not what a
| company decided is a good fit for an extremely domain-
| specific part of a system. Most people have no idea what
| MINIX is.
| CogitoCogito wrote:
| That's one way of looking at it. I guess by that line of
| reasoning Minix and Linux/BSD/etc. are also unpopular since
| they are effectively only used because companies decide
| it's a good fit for their system (relatively speaking there
| are very few such as myself that run Linux on their main
| system).
| dn3500 wrote:
| I don't think this guy understands what research is and what it's
| good for. He even says that the AT&T Research Group "were not
| used to create commercial software and AT&T has never been in the
| software business" as if that's a bad thing.
| pjmlp wrote:
| Well, that is how UNIX got its free beer adoption, which
| workstation startups like Sun took to their advantage.
|
| Plan 9 and Inferno failed at that, because AT&T had already
| changed by then, and there was no more free beer.
| jamal-kumar wrote:
| Yeah it always sounds like such a bad take when people use
| research operating systems as some kind of failure case against
| giant commercial behemoths which have a totally different model
| of operation and goals.
|
| Key word: RESEARCH.
|
| OpenBSD gets a lot of flak for this, which is funny because
| outside of its performance issues which are somewhat the result
| of all the mitigations, people sure love taking things that
| were first implemented there and using it in stuff like
| Windows, or using software which is an integral part of that
| project like OpenSSH and tmux. I don't think some people
| realize that it's largely a research project led by professors
| out of universities in Alberta when they're really quick to
| heap criticism on it.
| jleyank wrote:
| Problem is, it's quite difficult to know in advance what will be
| the win. Things that help the development _and maintenance_
| processes are good, even if they don't map 1-1 to a problem.
| Projects are always short of resources and code is hard to
| maintain. Perhaps Linux might have come from plan 9 rather than
| minix if there was a better internet when it appeared. Perhaps
| we'd have plan gnine from rms.
|
| I see a value in being to abstract away hardware issues as it
| lets me reduce the complexity of what I'm working on. Operation
| within an abstraction can be improved or changed without changing
| what uses it - and the changes are made in a single place,
| simplifying maintenance. There can always be performance issues,
| but one should not set out to tune things without a reason to.
| jhbadger wrote:
| Exactly, and each system doing something different from
| standard AT&T V7 Unix did so because they thought something
| _was_ broken. And they weren 't entirely wrong. Yes, most
| people don't use Plan 9, or Hurd, or Minix, today, but we don't
| use V7 Unix either. Unix/Linux evolved, and it it didn't do so
| in a vacuum isolated from these other systems but took things
| from them that turned out to be improvements.
| pjmlp wrote:
| I wouldn't tell, looking at how some keep using text based
| workflows, TUI, and multiple TTYs as if their last Linux
| distribution has hardly changed since AT&T V7 UNIX.
| t-3 wrote:
| What do you have against text? I can't cope with GUIs
| hiding everything while wasting half the screen on
| decorations. Text is simple, doesn't change, is easy to
| remember. I started with GUIs too, used Windows, Mac OS 9
| and OS X before discovering the CLI, so this isn't
| nostalgia, I really prefer text. It's incredibly empowering
| to interact with the computer through a simple and
| comprehensible text interface.
| shadowofneptune wrote:
| If we're being nitpicky, did TUIs even exist on V7? IIRC,
| support for terminals that did more than scroll downwards
| was lacking in Unix at the time, only really starting on
| BSD.
| pjmlp wrote:
| "A few years later, Mary Ann Horton, who had maintained
| the vi and termcap sources at Berkeley, went to AT&T
| Corporation and made a different version using terminfo,
| which became part of UNIX System III and UNIX System V."
|
| https://en.m.wikipedia.org/wiki/Curses_(programming_libra
| ry)
| einpoklum wrote:
| > No one, in the Unix world, ever complained about the Unix's
| missed promise about file abstraction.
|
| I was complaining about the missed promise of file abstractions
| since the first time I was exposed to their potential: "Oh,
| that's great - but then, why isn't XYZ accessible as a file? And
| why can't we have the kernel offload interpretation of path
| suffixes to userspace code? And why isn't `/proc` richer? And why
| do I need to mess around with BSD sockets if we can just go
| through files? etc. etc."
|
| Now, sure, I'm just a nobody (and was a complete nobody 25 years
| ago when I noticed this) - but the author's claim is just false.
| uhura wrote:
| This kind of article develops a dangerous line of reasoning.
|
| The failure of Plan9 is not about what went wrong or right. It is
| about how the market evolved and made decisions, which goes
| beyond the scope of this comment.
|
| The first conclusion "...is not to try to fix things that are not
| broken..." is dangerous because what someone identifies as broken
| is not the same as someone else. As a Plan9 user you may identify
| Unix deficiencies as problems and a Unix user might disagree.
|
| The second conclusion "...is to try to identify if there is a
| market..." and there are many things in life that contradicts
| this (maths, basic science, maybe the beginning of Unix
| itself...).
|
| And the final conclusion is about backwards compatibility. This
| is sound in the authors perspective because of the first
| conclusion but does not hold against good reasoning. Plan9 broke
| some compatibility because it needed and kept others because they
| were already good in the POV of the developers/researchers.
|
| The Plan9 effects to me is far different. It is about the fact
| that Plan9 is unable to die against all expectations. 9P is there
| to stay, 9front gets releases every year, /proc is everywhere,
| same for UTF-8, and so on.
|
| Good ideas stick, they are hard to let go and even harder to
| ignore. Plan9 failed in the commercial OS sense, just as many
| others failed. "You may never know it's broken until you fix it"
| (I'm sure heard it somewhere).
| matheusmoreira wrote:
| > Good ideas stick, they are hard to let go and even harder to
| ignore.
|
| Horrible ideas are even stickier unfortunately. Like Unix, Plan
| 9 is also designed around forking processes and even has
| asynchronous signals.
| unwind wrote:
| Can you please elaborate on why those two ideas are
| "horrible"? Forking processes seems like a rather elegant
| concept, to me.
|
| Granted, it's sometimes weird that in order to have a process
| running image A create a process running image B, it must
| first have a mirror image of itself for a while, then replace
| it. But the symmetry and simplicity at the conceptual level
| is nice, and the ability to have code for both parent and
| child in the same image is neat.
| jolmg wrote:
| It's called trolling. They're using the word "horrible" to
| bait a response on something that can be easily argued on.
| matheusmoreira wrote:
| It's called having an opinion and expressing it. You can
| accept my opinion, ask me to elaborate or convince me
| it's wrong. What you can't do is accuse me of trolling
| just because you disagree.
| jolmg wrote:
| No, I thought you were being hyperbolic, but after you've
| explained your problems with signaling, I agree with it.
| Kind of depressed at the state of that, now...
| matheusmoreira wrote:
| You and me both. I've wasted way too many neurons trying
| to understand this legacy brain damage. Hyperbole doesn't
| quite do it justice, it's a design that deserves an epic
| rant like mpv's locale commit:
|
| https://github.com/mpv-
| player/mpv/commit/1e70e82baa9193f6f02...
| kelnos wrote:
| Forking is one of those things that is a super elegant
| solution when things are simple, but breaks down when
| things become complicated.
|
| Multithreaded app? Fork is now a liability, and is only
| useful if the only (more or less) thing you do in the child
| is exec. Might as well only have Windows-style
| CreateProcess at that point.
|
| For single-threaded programs, sure, fork is fine and gives
| you more flexibility than a CreateProcess-type API.
|
| Asynchronous signals have a lot of the same problems, but
| those problems are _also_ present in single-threaded
| programs. Quite a few APIs have been added over time to try
| to make working with async signals easier and safer, but
| all of them add their own new gotchas.
| jolmg wrote:
| > Asynchronous signals have a lot of the same problems,
| but those problems are also present in single-threaded
| programs. Quite a few APIs have been added over time to
| try to make working with async signals easier and safer,
| but all of them add their own new gotchas.
|
| Isn't this referring to uses beyond what async signals
| are good for, or are you saying that async signals should
| just not exist in favor of something else? It's not like
| they're meant to be the only IPC mechanism, but they're
| good as a standard way to inform a process of certain
| things while having default handlers.
|
| EDIT: Nevermind.
| matheusmoreira wrote:
| > Can you please elaborate on why those two ideas are
| "horrible"?
|
| The problems with fork are thoroughly explained by this
| Microsoft paper:
|
| https://www.microsoft.com/en-
| us/research/uploads/prod/2019/0...
|
| As for asynchronous signals, they are a completely broken
| concept and implementation.
|
| It's not safe to do pretty much anything in a signal
| handler other than setting a flag and returning. You cannot
| use any non-reentrant function which eliminates pretty much
| everything useful, including the vast majority of standard
| library functions.
|
| The system drops events. Signals are essentially a pending
| delivery flag in the kernel, signaling a process just sets
| the flag to 1 so there's no difference between doing it
| once and 10000 times.
|
| Was in a system call when your process was signaled? It
| will be interrupted or cancelled. It returns EINTR and your
| code needs robust retrying logic to handle such a case.
| I've seen code that couldn't handle it and crashed.
|
| There's race conditions everywhere. Signals can arrive
| while you're handling other signals, you need to block
| block them if you don't want that. Every thread has its own
| signal handling behavior. Signals sent to a process are
| handled by "any" thread. I remember reading in some
| standard that using signals in multithreaded programs was
| undefined behavior. Who even knows what's going to happen?
|
| The only borderline sane way to handle signals is with file
| descriptors: you block traditional signal handling on all
| threads and set up a signalfd that you can epoll along with
| everything else on a thread dedicated to the event loop.
| Even this is pretty bad:
|
| https://ldpreload.com/blog/signalfd-is-useless
|
| https://news.ycombinator.com/item?id=9564975
| jolmg wrote:
| You got me. That is quite horrible.
| mananaysiempre wrote:
| > Forking processes seems like a rather elegant concept, to
| me.
|
| Forking is good because it saves you a rich process
| manipulation API, and because generally speaking doing
| things _to_ an execution environment always ends up more
| clunky than doing things _in_ one. (Cleaning up after doing
| them is another matter.)
|
| Forking is bad[1] because it (essentially if not literally)
| forces memory overcommit on you, at which point resource
| accounting becomes hopeless.
|
| [1] https://lwn.net/Articles/785430/
| jolmg wrote:
| A more agreeable example would be Windows forbidding specific
| file and folder names to reserve for device names, something
| it apparently inherited from CP/M.
| dopidopHN wrote:
| Thanks you to express in English my inconfort growing while
| reading this ( otherwise nice ) article.
|
| Market fit is insight 20/20 IMO, but you phrased it better.
|
| Overall, my discomfort is that it's the type of reasoning that
| keep you with your two feets in the mud. Stuck.
|
| I'm stealing "you don't know it's broken until your fix it"
| B1FF_PSUVM wrote:
| > Good ideas stick, they are hard to let go and even harder to
| ignore.
|
| That's a noble wish, but that doesn't make it true.
| pjmlp wrote:
| Procfs appeared originally on UNIX, see USENIX paper.
| yakubin wrote:
| And BSDs removed it, deeming it a security risk.
|
| Personally, I don't like that it's more of parsing text files
| to get a number, when you could have functions returning
| structs (of variable length, to get extensibility, while
| preserving backwards compatibility).
| somat wrote:
| A fair assessment, but at the end of the day it is all just
| a stream of bits, bits packed into a into a structure, how
| do you know the structure?, how do you know how wide each
| part is? or bits packed into an array of encoded bytes.
| what is the encoding? how do you parse it?
|
| The array of encoded bytes despite it's complexity overhead
| has an advantage in that is lays on the human visible side
| of computing, that part of computers designed for the human
| to use. I have to admit more often than not I prefer to eat
| the overhead and have an interface that I can see.
| trasz2 wrote:
| Not just BSDs; no major operating system other than Linux
| uses procfs anymore.
| kelnos wrote:
| Sure, but Linux is also on more devices than any other OS
| in the world.
|
| Your statement would be more damning it Linux was a
| minority player or on the decline, but that's not the
| case.
|
| Procfs seems... fine, really.
| linksnapzz wrote:
| Solaris has had procfs for years.
| trasz2 wrote:
| Solaris is a history at this point.
| nix23 wrote:
| Really? Tell that oxide computers...well it's not Solaris
| but Illumos.
| linksnapzz wrote:
| Oracle and Fujitsu still sell and support it.
| marcus0x62 wrote:
| The BSD approach at the time was to require setuid access
| for programs like ps _to be able to read the kernel memory
| space via /dev/kmem_ to produce a running process list.
|
| That is infinitely more stupid than procfs.
| linksnapzz wrote:
| By some standards, the Velvet Underground were an unsuccessful
| band; never having much radio airplay, and no high-charting hits.
|
| But...the were hugely influential. Someone once said that they
| may have only sold 500 albums, but each an every one of those
| purchasers started a band.
|
| Success needs to be carefully defined in advance of declaring
| failure.
| dopidopHN wrote:
| They sold 500 albums ?
|
| Crazy to think they are an absolute must listen to high school
| kids ( at least in rural France of the 90s... )
| AdmiralAsshat wrote:
| The quote in question was from Lou Reed and was about the
| _first pressing_ of their debut album, IIRC.
| teddyh wrote:
| It's absolutely mind-boggling to me that everybody is ignoring
| the relevant difference between Unix(tm) and Plan 9: Unix source
| code was _given away_ (or cheaply licensed) to hardware companies
| which all wrote their own operating systems on top (SunOS,
| Ultrix, HP-UX, etc. etc.). This made Unix the common factor of
| very many commercial workstation environments. Plan 9? It was
| sold directly as a commercial product, for no hardware platform
| in particular. Nobody wanted to buy it.
|
| People liked Unix because it was _free_ - either really free, via
| BSD, or as a Unix derivative provided at no cost when people
| bought their workstations. A new revolutionary operating system
| had absolutely no reason for anybody to buy it: No commercial
| developers wanted to develop to a platform without users, and no
| users wanted a platform without software.
| teddyh wrote:
| I'm reminded of a similar blunder made by IBM with their PS/2
| series of computers. The initial IBM PC, PC XT and PC AT models
| were very popular, because they could be cloned by third-party
| manufacturers, which in turn created an enormous market for
| third-party software and hardware accessories and peripherals.
| But IBM wanted a bigger piece of that pie than just the few
| sales of genuine (and very expensive) IBM hardware, so they
| created the IBM PS/2 line: Heavily locked down, with its own
| new proprietary bus (MCA), connectors and peripherals; all
| heavily patented, so only IBM could produce them. It was a
| disaster. The only thing which endured was the PS/2 style
| connectors for mouse and keyboards, and those were made
| obsolete with USB. Nothing beside remains.
| jsiepkes wrote:
| Certainly not the last time a company failed because they
| thought they could make big bucks by creating a vendor lock-
| in. Just look at Intel with Optane.
| simne wrote:
| PS/2 series closeness, was not a problem.
|
| Real problem where other vendors, which offered new hardware
| (with for example, new CPUs), before IBM.
|
| First case was Compaq-386, which considered by wide public as
| brand, and appear on market, before 386 machine from IBM.
|
| As I know, Compaq-386, was not much commercial success, but
| it shown people, they could buy excellent hardware from other
| brands, not only from IBM.
|
| And after this happen, it made PS/2 series not so interest,
| as before.
| nix23 wrote:
| >Unix source code was given away (or cheaply licensed)
|
| Yeah that's not true, at the beginning it was ~10k per
| processor. But you can thank BSD for rewriting Unix and replace
| all the AT&T parts. And yes SunOS was from the BSD lineage.
|
| https://www.quora.com/How-much-did-Unix-cost-during-the-70s-...
| teddyh wrote:
| > _at the beginning it was ~10k per processor._
|
| Was Unix popular at that time?
| simne wrote:
| That was golden time for developers. Their public status
| was like movie stars.
|
| And for West it was normal price, because even considering
| wide usage of also cheap CP/M, on some level of
| organization size, was unavoidable to switch to Unixes or
| to mainframe - CP/M just was too limited, was not capable
| to handle big business load.
|
| When BSD first appear, Unix machines also where too small
| and slow for big business, but very soon appear client-
| server architecture, and later clouds (Beowulf, I think,
| oldest wide used private cloud soft), Unixes become
| unlimited.
| nix23 wrote:
| Well maybe not as much as VMS but it started to gain
| traction.
| simne wrote:
| "People liked Unix because it was free"
|
| Good point, but have You hear abot,
| https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good
|
| That is the point, that better things must be hugely better,
| than ordinary, to win.
|
| For example, my friend worked in startup, based on Erlang. Once
| at public talk one guy asked "have you hear about Erjang, a
| virtual machine for Erlang, which runs on JVM, it is up to 5
| times faster than Beam?". Answer was "5 times faster is not
| enough, to consider switch of platform, in my case, need 10
| times faster".
| simne wrote:
| I'll risque got many minuses, this is right of all. But read
| whole comment, and if you could, write counter arguments.
|
| I must admit, this is good article, because it illustrating
| different styles of thinking, and using excellent example of
| really great fail, but absolutely avoidable.
|
| Unfortunately, it is written considered tech people, in language
| of tech people, on resource intended for tech people, but it is
| much closer for entrepreneurs, business owners, investors,
| freelancers.
|
| I could not add much to what already mentioned, except, that
| exists huge number of examples, when big corporations used best
| scientific research and fail.
|
| This is because scientific is right in only some dimensions of
| space-time and https://en.wikipedia.org/wiki/Noosphere, which are
| accessible for current science (and not right in huge non-
| digitized areas.
|
| And usually, researched really past, but product is made for
| future, and future is mostly unpredictable for current science.
|
| As summary of my comment, when use research data for work, you
| risque, to make product for some abstract market, existed in
| past, but will not exist in future.
| LoganDark wrote:
| Plan-9 isn't Unix
| bediger4000 wrote:
| I've always wondered about the hidden convergence of the "9" in
| Plan 9, and the "IX" in Unix. IX, after all, is how Romans and
| Western Civilization wrote numbers until say 1200CE.
|
| Given how smart Pike, Thompson, Ritchie etc are and we're, I
| doubt this is a coincidence!
| keiyakins wrote:
| It probably was, seeing as Plan 9 was named after a movie.
| chubot wrote:
| This is a very shallow, incorrect analysis. The author needs to
| learn about composition to understand both Unix and Plan 9.
|
| As others mentioned, the author also needs to consider what
| research is.
| dang wrote:
| Discussed at the time:
|
| _The Plan 9 Effect or why you should not fix it if it isn 't
| broken_ - https://news.ycombinator.com/item?id=11791980 - May
| 2016 (107 comments)
| smitty1e wrote:
| Even when the fixes are arguably improvements, it's still tough
| sledding.
|
| Ask Guido van Rossum re: Python 2=>3.
| bediger4000 wrote:
| This strikes me as revisionist. Research Unix v8-20 had quietly
| trended towards more things-as-files. The hardware environment
| that Plan 9 assumed was very different - separate file servers,
| compute servers and graphic workstations, plus it came out when
| Microsoft and Windows were at their maximum power.
|
| Beyond all that, today's leading OS, Linux, has incorporated many
| of Plan 9's ideas. /proc filesystem, the signalfd system call,
| and UTF-8 are all examples.
|
| I think it's dangerous to assume what this article advocates. You
| risk trying to make a faster horse, or maybe the Uber of $X
| zokier wrote:
| > Research Unix v8-20 had quietly trended towards more things-
| as-files
|
| That brings up another point; UNIXes v8-v10 are even more
| irrelevant and forgotten than plan9, despite presumably being
| more compatible with the venerable v7 UNIX. So pinning plan9s
| failures on it being different seems to me very misguided
| zozbot234 wrote:
| Linux is _still_ incorporating ideas from Plan 9 in a haphazard
| and unplanned way. "Containerization" (kernel-level
| namespaces, really) was a big one; user-space block devices was
| one of the latest.
|
| I do think that Plan9's de facto requirement for graphics-
| capable hardware is a bit weird in retrospect. It really was
| made to be a research OS for networked workstations (and the
| default UI basically clones Oberon) even though the design
| concepts it ultimately leverages are far more applicable.
| pjmlp wrote:
| IBM mainframes got there first.
___________________________________________________________________
(page generated 2022-12-10 23:01 UTC)