Hacker News new | past | comments | ask | show | jobs | submit login
Plan 9 from User Space (9fans.github.io)
158 points by abudabi123 on April 28, 2023 | hide | past | favorite | 54 comments



After a brief diversion with the Acme editor (a big part of Plan 9) and some modern Smalltalk environments (Squeak, Cuis, and Pharo), I can't help but feel like we are stuck in a very local optimum as far as UI/UX go.

The insane amount of introspection available to you in a Smalltalk image, and the way every bit of text becomes a potential button or action in Acme just put the lack of creativity in modern interfaces. I say all this as a Haskell and Nix fan as well, so I'm very in-tune to the benefits of functional purity and reproducibility in a computing system. It really makes the silo-ed world of isolated microservices, containers, and walled "garden" ecosystems seem really sad.

I guess this is my way of saying, that we should all try to do things differently. Haskellers, go learn Smalltalk. It's not a big deal that things mutate things when you can literally inspect every object as its running, including the debugger :D. Smalltalkers (or Rubyists or whatever is closest) go learn Haskell. Sometimes boundaries are GOOD. Formality can be very helpful when it comes to organizing, designing, and reasoning about your stuff!

And we should all try to do something weird.


On the idea of being stuck in a local maximum of graphical interfaces, see the concept of “wheel of reincarnation” by Ivan Sutherland. http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland...

Rob Pike’s comment about this is very interesting too:

Through the 1970s and 1980s, there was a continuous invention in how graphics, computing, and software interacted. With the dominance of the PC and the VGA card, we now have a largely fixed architecture for graphics in personal computers. There is some playing around with the software model, but basically we have a powerful, privately managed external "card" that does the graphics, and we talk to it with one particular mechanism. During my work on Plan 9, it got harder over time to try new things because the list of ways to talk to the card was shrinking, and other than the blessed ones, slower and slower.

For example, a shared-memory frame buffer, which I interpret as the mechanism that started this conversation, is now a historical artifact. Back when, it was a thing to play with.

As observed by many others, there is far more grunt today in the graphics card than the CPU, which in Sutherland's timeline would mean it was time to push that power back to the CPU. But no.

Not a value judgement, just an observation. The wheel has stopped turning, mostly.


> With the dominance of the PC and the VGA card, we now have a largely fixed architecture for graphics in personal computers

Unfortunately VGA as we know it is dead and now, to render the blinking cursor, they render the whole screen surface in a compositor.


One could say much the same thing about emacs and vim as well. emacs, in particular, is essentially nothing more than the elisp interpreter, with some good primitives to build a (some say mediocre) text editor inside a pretty cool operating system.

What sort of "weird" do you think would be fun?


Not OP, but what about something like https://en.wikipedia.org/wiki/Metisse ?

( https://www.youtube.com/watch?v=Dt3q7Z7RjIU 4min54sec)

Which begat https://dl.acm.org/doi/10.1145/1166253.1166301 from the same institution. ( https://www.youtube.com/watch?v=kUUtiOWTzz4 7min20sec)

Married with something like https://arcan-fe.com/about/

With some https://en.wikipedia.org/wiki/Zooming_user_interface sprinkled in,

not necessarily in the 'style' of https://eaglemode.sourceforge.net/ but the concept.

Rounded with something like https://en.wikipedia.org/wiki/OpenQwaq , or https://en.wikipedia.org/wiki/Open_Cobalt

OFC fully themable like GTK before they broke it, or something like https://github.com/KDE/qtcurve which is endlessly modifiable.

Nirvana!


I have been using Emacs as my daily driver for about a decade. It's the closest thing we have to a "popular" Smalltalk environment. The desire to bring everything into Emacs is the same desire I felt after experiencing what computing could be in Smalltalk.

One of the really striking things that you're confronted with in a modern Smalltalk is the Morphic UI system. Imagine that, with one click, you could drop into a new window with a live inspector and a (very freeform, repl-ish that's not a repl) REPL loaded into the internal context of any button, window, pane, scrollbar, you name it that you can see right now. (Even my own vocabulary is stifled with the traditional UI/UX we have now!) Now imagine you can do that on any application on your computer. Now imagine you can drag those subcomponents around, rearrange them, drag them onto new windows, modify their code, spawn new ones, and so on all while the thing keeps running and functioning.

If you break something, it's okay. The debugger pops up and allows you to do the same thing that you did when you inspected the widget for any point in the frame in the stack trace. Yes, you can debug, live, multiple levels of your stack trace at the same time, that have live, editable versions of the code as well.

You don't have to imagine it. You can see it here [1] or just download a Smalltalk system yourself.

If the Smalltalk community focused on building some tooling to allow you do develop other languages inside a Smalltalk image based editor, I don't think even Emacs could compete.

---------------------------------------------------------------------

As far as what kinds of weird would be fun, I always find new interaction paradigms fun. That's one of the things I loved the most about Acme. It's kind of crazy how versatile and adaptable "execute the highlighted text in the shell" is as a core interaction loop. If you want to search files for something, just type `grep` in front of the word, select them all, and then you get a new buffer with the results. Which are, of course, editable and executable in the same way.

The two most common places I see experimentation in this are in Linux window managers and programming languages. I've tried StumpWM, i3, and AwesomeWM before. I wish there were more people experimenting with non-tiling things. The person behind this project is doing some very cool stuff [2].

There are tons of people making cool, small (and large) new programming languages like Idris, Janet, Lean, and Pony and lots of people still using really cool old programming languages like APL (or J or K or BQN), Forth, and Scheme (Racket is great, Gerbil built on Gambit is insanely good for a one person project). I see some insanely cool stuff about prototype languages doing staged metaprogramming (lookup Collapsing Towers of Interpreters if you want to read about something really cool, i.e. compiling out the costly abstractions in infinite towers of reflective interpreters), dependently typed experiments, and other wild shit.

Surprisingly, there seems to be a lot (sadly meaning only 2-3 actually separate movements) going on in the "OS space" too with immutable/declarative system specification. I'm referring of course to Nix and Guix and things like Fedora Silverblue and OpenSUSE MicroOS. That's gaining steam quickly. I personally find the Nix language rather fun and interesting in its own right, but I think I'm on the minority side of that.

Broadening out past that, hell I don't know. That's why I put the call out to everyone else :D

[1] https://youtu.be/QTJRwKOFddc [2] https://codeberg.org/mmontone/mold-desktop


You can inspect, alter and debug any website too. (Minification makes this annoying but there are ways around this) The refresh button does delete all your modifications though.


I know. There's a big difference between peeking into something you're not supposed to, and interacting with a system designed to used interactively like that though.


Java and .NET are much closer to Smalltalk than Emacs.


Not sure I'd call Acme a big part of Plan 9, though it does follow the philosophy somewhat. I know folks who use 9front who would rather spend time in the Sam editor than use Acme, and they use 9front as their daily driver system.

But I totally agree with you on the "do something weird" approach to learning and gaining inspiration. Some problems that are hard in some spaces are extremely easy to deal with in others.

I actually do use acme on 9front for a lot of coding tasks in conjunction with sshnet (imagine importing a remote system's network accessibility over ssh - like a lightweight VPN-almost sorta) and sshfs through that sshnet "tunnel".

This gives me a nice code, compile, test cycle that has some "editing" commands that let me jump straight to where failures occur with a single click.

And Acme knows nothing about what it's doing... it simply follows its own basic rules, and the file system underneath is arranged to enable my workflow.


Yea, I was really just trying to say, Acme is part of the Plan 9 ecosystem for people that have never heard of either. For me at least, Acme is the quintessential P9 application, but I concede that it's Sam for most P9ers in history. It's probably more apt to say Acme is an excellent exemplar of the Plan 9 way. The file-based socket-y proto-RPC "plugin" way of doing things is intimately tied to Plan 9's design.

And yea, Acme is different, but Sam is weird. In a good way though. I never really tried to get the hang of it, but Sam does live on in some ways (Vim Ex commands and such).

I'm also not surprised that a 9front user thinks it's a good idea to be weird. Just look at your webpage and this very bizarre thing that is for some reason linked one click away on the side menu: http://9front.org/movies/


I think the chain of influence flows from ex/vi to sam, not the other way around?


ed -> jim -> sam(antha)

from: https://9p.io/sys/doc/sam/sam.html


My biggest problem with acme is that it's so mouse-oriented.

As a big fan of keyboard-only use of vim and emacs, this made acme a complete non-starter for me.


Your problem with Acme is you don’t grok Plan 9. [1] In Plan 9, everything’s a file. Acme in particular represents open buffers and windows as files on disk too. I don’t mean as copies of the text necessarily, but as sockets basically where you can send and receive data about a particular thing inside Acme. It’s kind of wild just how exposed it is. It’s not like you’re sending info to a single process server like an LSP server of today, no, you’re literally getting a file ID to go back to and write to when you finish doing what you’re doing.

Writing a plug-in is actually completely language agnostic. It’s just standard file IO.

Any time you middle click the name of a script, it executes that file by looking it up in a PATH equivalent (pretty sure it’s also project local as well, but I don’t remember).

This is really powerful for two reasons: everything’s an editable text field from your menu bar, your window bar, and the buttons on them; and chorded selections, basically you can send a selection to a command by selecting and then clicking on another piece of text to determine the command.

This allows you to create a UI tailored to whatever you’re doing as you’re doing it. If you watch someone program with Acme, they’re writing little snippets in their status bar to do common tasks, or for more involved things, they’re just creating a new buffer and typing or cut and pasting some relevant code they need to search different parts of (because searching is just one mouse click away). The best part is, you can just save and load that buffer for later. It’s just a plain text file.

It’s definitely a change up from the keyboard-driven focus we’ve come to see, but again, I think we gave up on the mouse way too quickly. If you’re really honest with yourself, I think you’ll find you aren’t constantly clipping around at 1,000 key presses per minute in Vim. You’re spurty, you sit and think, and then you type. Once I started thinking about hands on mouse time as thinking time, then it wasn’t nearly so unacceptable. I even came to prefer it (gasp).

[1] Sorry I couldn’t resist referencing the classic Vim/Vi write up.


...no, I'm pretty sure my problem with acme - and plan 9, actually - is that it's so mouse oriented. Clickable text and mouse chords are not by any means a bad system, but what I really want to do is never have to take my fingers off the keyboard


What I don't get is why any of that should require a mouse.


I used to think that way but modern mice and touchpads along with the relevant literature have convinced me that keyboard paired with mouse is more productive.


Keyboard with some mouse sprinkled in, sure. But Acme is very mouse heavy.


I guess I’m challenging the assertion that mostly keyboard with mouse sprinkled in is more efficient than more heavily mouse oriented UIs. There is literature that suggests otherwise and that literature was not based off state of the art mouse and touch pad technologies.


> (a big part of Plan 9)

It's the first thing many plan 9 users run after they experience their first grey Rio screen and figure out how to draw a window. It also demonstrates the power of the file system based interface and how a program can expose its internal functionality via files to external programs to build a symbiotic environment. But most will find it cumbersome or obtuse to use after a while. Another major gripe is that it cant do graphics in its windows which is kid of seen as a break in the design from being a graphics first OS.

Personally I always felt it's the equivalent of the Explorer shell for Plan 9. My gripe with it is it becomes obtuse to use after you start to open a lot of windows and everything is boxed into corners and centering the window is frustrating. So most plan 9 users who actually write code use Sam. Another trick is windows in Rio are just text buffers so people open windows to use as scratch pads and then copy/paste between them and Sam.

Then there's hold mode, the ultimate text editor. You hit escape while in a window and it turns blue indicating hold mode. While in hold mode rc or whatever is running will not receive anything you type into the window buffer via stdin as it's being held back in the buffer. So type as many lines of rc script or w/e, edit, then to run just hit escape and the text is processed. I do this all the time writing simple rc scripts. Then just echo 'blah...' >$home/bin/rc/bla and chmod +x bla when done.


Are you familiar with Oberon? ACME is really closer to that than Smalltalk. It’s funny you mentioned both though because I’ve toyed with the idea of making an Oberon/Acme environment in Squeak. I’m quite certain it’s doable with Morphic.


I have heard of it. I wasn’t really trying to draw specific parallels between Acme and Smalltalk as similar editing environments. I was just lamenting that two of the most interesting pieces of software I’ve used recently are both older than me, and very little except for efforts to recreate those systems exactly on modern hardware has quite the same feeling of freedom and creativity. They really feel like they are there for you to mold into what you need a computer to be, not tell you how to use a computer.

It’s probably not fair to say that we’ve lost a capacity or appreciation for creativity and novel ideas. In sheer volume, there are probably more people doing XeroxPARC level crazy stuff now than then. It just feels like way more investments are made to copy the thing someone else is doing but tweak it slightly than on truly large moonshots.

Part of this is probably the homogenization cause by mass, instant communication, and not forcing you to wonder, how did they do that, and how would I do it differently. It’s a double edged sword though. Hell, I feel like part of the reason some of this stuff didn’t catch fire and spread was because of the limited ability to share and talk with people too.

I don’t know what the right answer is. I just want more cool shit.


> In sheer volume, there are probably more people doing XeroxPARC level crazy stuff now than then.

I'm not sure about that. From the Computer History Museum's 50th anniversary event of the Alto two days ago, each Alto cost about 18k in early 1970s dollars (about 100k today). And they built hundreds of them. Not sure anyone has the budget to do the level of crazy work that would require the equivalent amount of future computer power today.


I think the point that you don't need that level of money anymore. You could do the same level of exotic software on a Raspberry Pi for 50 bucks.


That's because you are thinking equivalent in terms of results. I'm thinking equivalent in terms of ambition.

The point I was making is that doing the equivalent level of 'crazy' work (for it was crazy, the idea of giving everyone the equivalent of a personal pdp-11 in those days) requires equivalent levels of funding. It's just that most people can't imagine what could be computed on a $100k equivalent of computing today.

For all of us who grew up in the days of personal computing, it's hard to imagine that what they accomplished as being crazy.


You would love Oberon, and its derived OSes, Acme UI is based on it.

In Oberon, you can select any piece of text and apply a command on it.

Commands are public procedures in dynamic modules, so Module.Command will load it if not already loaded, and then execute command.

There are a couple of ways to write commands, depending if the act on selected widgets, selected text, selected windows, or if they ask for additional input.

http://www.projectoberon.net/

For trying out it emulated on the browser,

https://github.com/schierlm/OberonEmulator

And how the latest iteration of it, Bluebottle (AOS) with Active Oberon, looks like

http://www.progtools.org/article.php?name=oberon&section=com...

One of the great things about PowerShell and Windows, is that despite all the warts it has, it allows exactly a similar kind of workflow, with .NET, DLLs and COM replacing that Module.Command experience.

GNOME and KDE can offer similar workflows, alongside DBUS, and fish shell, however people seem more keen in keeping the UNIX experience of yore instead of going down that route.


> And we should all try to do something weird.

YES

It's a big world out there and there's so many cool techniques we know are helpful but aren't widespread and really should be, and so much more to be discovered still!


I'm kicking around some editor ideas at the emacs/ST/plan9 intersection and I'd like to discuss them with you if you're amenable. My email is in my bio.


Obligatory Bret Victor mention.


For those who are unfamiliar, Plan 9 from User Space a pun on Plan 9 from Outer Space, an infamously "so bad it's good" movie from the 1950s. It has this ridiculous bimodal distribution of review scores as a result:

https://www.rottentomatoes.com/m/plan-9-from-outer-space

https://www.imdb.com/title/tt0052077/ratings/

https://www.mentalfloss.com/article/78785/10-out-world-facts...

https://www.bbc.com/culture/article/20220107-is-this-the-wor...

https://en.wikipedia.org/wiki/Plan_9_from_Outer_Space


The more proximal referent is Plan 9 from Bell Labs:

https://9p.io/plan9/

> Plan 9 from Bell Labs is a research system developed at Bell Labs starting in the late 1980s. Its original designers and authors were Ken Thompson, Rob Pike, Dave Presotto, and Phil Winterbottom. They were joined by many others as development continued throughout the 1990s to the present.


I've suspected; have no evidence to back this up, that "plan9" is a play on the roman numerals IX (9) at the end of "UN IX" and also that "research unix" never had a 9th or 10th version fully developed and released. And, TIL there's another thing called "IX"[1]

[1]https://www.cs.dartmouth.edu/~doug/IX/


Here's a funny thing I just found out: in chasing the reference cited by Wikipedia regarding the naming, I learned that UTF-8 was invented for Plan 9.

http://catb.org/~esr/writings/taoup/html/plan9.html


My understanding was it was a work in progress and they showed it to one of the plan 9 guys who pointed out a way to make it better and then implemented it into plan 9, not that it was particularly originally for plan 9.


There is a pretty complete description of the origination of UTF-8 here:

https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt

Rob Pike opens with:

> Looking around at some UTF-8 background, I see the same incorrect story being repeated over and over. The incorrect version is: 1. IBM designed UTF-8. 2. Plan 9 implemented it.

> That's not true. UTF-8 was designed, in front of my eyes, on a placemat in a New Jersey diner one night in September or so 1992.


ah, thanks for the source!


True, but that in turn was named after Ed Wood's Plan 9 from Outer Space. And its mascot "Glenda" is a reference to another of Wood's movies, Glen or Glenda.


That's not funny though, and it's an obvious reference to the movie.

> The name Plan 9 from Bell Labs is a reference to the Ed Wood 1957 cult science fiction Z-movie Plan 9 from Outer Space.[17] The system continues to be used and developed by operating system researchers and hobbyists.[18][19]

https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs


yes, but since you haven't nailed the humor yet, the original pointer-outer should have pointed out, "Plan 9 from Userspace is a follow-on to the Plan 9 operating system from Bell Labs, which was whimsically named after the film Plan 9 From Outer Space. Since the unix operating system is built on a simple security model of kernel-space and userspace, this clever word play is also informative about the architecture"


Having just watched it, I'll agree with the "so bad" part, but definitely not the "it's good" one.

Apparently plan 9 is specifically the space people's plan to resurrect the recently dead humans on Earth by shocking their pituitary glands.


There's a reason it was called "Grave Robbers From Outer Space" for a while, which is the title The Amazing Criswell uses in the intro.


Related:

Plan 9 from User Space (aka plan9port) - https://news.ycombinator.com/item?id=3064180 - Oct 2011 (2 comments)

Plan 9 from User Space - https://news.ycombinator.com/item?id=2125731 - Jan 2011 (6 comments)

Plan 9 from User Space - https://news.ycombinator.com/item?id=1266168 - April 2010 (6 comments)


Acme is an interesting text editor for development. I've used it for React.js development before. Because of how you can script it, I could run Prettier on save and a few other things you'd normally expect in the JS world.


I used it for about a year, once you have everything scripted and setup just how you like it it's.. Meh. Ok? I eventually got tired of only really being able to work at my desktop though (I still couldn't work out how to chord properly when using the trackpad on my laptop).

These days I use goland and vim, and I feel much more productive.. I still write crazy amounts of small tools and scripts to solve little problems though, and my .profile has like 200 alias's, so I guess some of it bled over..


It has the smoothest cut/copy/paste routine once you get it down. Moving text around is just buttery.

I personally find the lack of highlighting and auto-delimiters is a PITA for HTML/LaTeX though.


you could I suppose write a program that continuously scans the buffer and replaces things with unicode, but converts back to ascii on save.

𝕚𝕟𝕥 𝗺𝗮𝗶𝗻⦅𝑣𝑜𝑖𝑑⦆ ⦃ ⦄


> I personally find the lack of highlighting and auto-delimiters is a PITA for HTML/LaTeX though.

Sadly, I have not used acme. Wouldn't this deficiency be simple to overcome with scripting? I guess that's one particular area where emacs, being essentially a specialized LISP interpreter, encourages you to think about these things by default.


Perhaps you could script auto-delimiters. But it has no ability to format the text; you couldn't add syntax highlighting with scripting.


If only it had keybindings.


That would be missing the point. It does have limited keybindings ctrl-a = go to beginning of line ctrl-e = go to end of line ctrl-u = cut from point to beginning of line esc = select the last "stuff" just typed

The fact you can create your own "buttons" that do basically anything is pretty nice, but you REALLY want a 3 button pointing device to use it. It also doesn't care about the programming language you use to create such a button, but you will work with the filesystem metaphor provided by Acme itself to get things done.

I find the mouse interface is extremely fast, and when you couple it with the power of the plumber in Plan 9, it's a reasonably good way to navigate around a complex workflow.

It's also a reasonably small environment in terms of lines of code. The Go version (Edwood) is pretty good too! https://github.com/rjkroege/edwood


To sacrifice keyboard chording because mouse chording exists is... baffling.

You only have 4 bindings, You have at least 50 keys in your keyboard with 3 modkeys, That's a lot of combinations to do anything you wish for. Sure, use the mouse more, but to expect to not use standard keybindngs or adding any? It has to be a joke.

You can't even press the down key to go to the line below!


Acme has a handful of keybindings, like the usual ^A, ^E for navigation, ^Z for undo, etc. Plugging in new ones is a few lines of code, for example my ^S for Putall (saving all windows):

https://github.com/dexen/plan9port/commit/78324a4666c4b5e0bd...

Most of keybindings you might want to add are handled by Acme's "commands" - like Edit. If you repeat them any often, it's easy and straightforward to connect the keybinding to the command in code. Alternatively, to avoid going into C, write a shell script with ready-made command; Acme is well prepared to be managed through shell scripts. The shell scripts have full access to Acme's Windows (open files, directories, scratchpads etc), including ability to edit content, open new ones, interpret right-clicks in new ways, etc.


acme is the best unix editor period.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: