[packetlost]

I unironically wish there was an enterprise version of Plan 9. I've been writing most of my scripts in `rc` (something my coworkers put up with because we use nix and I can pull it in automatically with dirnev) and it has been great.

[yjftsjthsd-h]

I would worry less about other people being able to run rc scripts and more about them being able to read/edit them.

[packetlost]

they're routinely very short, and the only non-obvious syntax for someone familiar with a C-like language is the ~ command and redirecting to stderr. They're pretty much always easier to read (and write) than bash scripts in general because of how little weird/surprising syntax there is. Not being a derivative of ALGOL has its perks.

Most scripts are write-once:read-never, especially if you actually implement -h/--help

[eddythompson80]

> Most scripts are write-once:read-never, especially if you actually implement -h/--help

I guess the answer is always “it depends”, but that generally has never been my experience with most things. Are you over-engineering the shit out of every script to the degree the script itself is a Turing complete machine and with enough —-help flags anything is possible? Most 40+ year old Unix tools with a thousand flags have their limits and you have to script around them to achieve things you want.

In my experience, eventually a business need will arise that require you to change a script. Are your coworkers comfortable changing these scripts or are you in the mind set of “that’s a simple enough change, I’ll do it”

[packetlost]

> Are you over-engineering the shit out of every script to the degree the script itself is a Turing complete machine and with enough —-help flags anything is possible?

No. They're 30 line scripts with 0-5 or so flags. They mostly exist to remove choices from other utilities. Put another way: create named (and namespaced) abstractions by making choices and slapping a name on it. They're functions.

> In my experience, eventually a business need will arise that require you to change a script. Are your coworkers comfortable changing these scripts or are you in the mind set of “that’s a simple enough change, I’ll do it”

They're small enough that they can be ignored if they don't do exactly what you want. I'm fine changing them, but it's most likely they'd just get rewritten or bitrot after I'm gone.

[packetlost]

Not work related, but here's some examples of what these scripts look like (this is how I mirror public repos locally using cron/timers): https://paste.sr.ht/~chiefnoah/3b8990fc0b8eb3f50e511d5d4051a...

Even if you aren't super familiar with rc, it's not that weird to look at. I find it way more readable than (ba)sh syntax.

[kristianp]

One benefit of rc is this[1]:

> The most important principle in rc’s design is that it’s not a macro processor. Input is never scanned more than once by the lexical and syntactic analysis code

I worked at a unix shop that deleted most of a working drive because a shell script was modified while it was running. Luckily they kept daily backups on tape. This was about 17 years ago.

[1] https://www.scs.stanford.edu/nyu/04fa/sched/readings/rc.pdf

[LukeShu]

Scanning input just is unrelated to the "modified while running" problem. The "modified while running" problem is a read-buffering problem.

For example, consider the following change:

    -echo $x; rm -rf /n/foobar/
    +rm -rf /n/foobar/
     ^^^^^^^^^^^^^^^^

If the shell's first read() reads 16 bytes (indicated above with "^"), then the file is changed, then the shell reads the rest; then the shell will see "echo $x; rm -rf /" regardless of whether or not it scans the input multiple times.

I am unfamiliar with the read-buffering done by either of the 2 main implementations of rc, and so am unable to comment on whether it does things to avoid this problem. But if it does do things to avoid it, those things are orthogonal to the "not a macro processor / input is never scanned more than once" thing.

[moody__]

Could you expand more on what you would like out of an "enterprise Plan 9"?

[packetlost]

the distributed computing model is pretty nice in theory (maybe not in practice) and the uniform system APIs are also nice. The userspace tools in particular are just plain better (structured regex commands are quite a bit better than ed-style and I find myself using them far more frequently in vis than I do in vim, they're far more composable and intuitive).

The biggest thing is the heavy reliance on union file systems (and file systems in general) and an extremely simple syscall API. It's a heterogeneous-networked-node OS so it handles realistic workloads natively with primitives designed for it instead of piling complexity on top of Unix-like APIs (ie. Linux). I dunno, I just think a lot of the modern "cloud native" stack is unnecessary if you had an OS actually built for the workloads we have.

[moody__]

There aren't really union filesystems per se, the plan 9 kernel provides unions through its namespace model. In my opinion part of the reason why the userspace tools can be as nice as they are, are due to the use of file system interfaces and the simplistic syscall API. Could you elaborate more on the issues you see with the use of these?

In regards to using it for a "cloud native" stack, the issue is that people want to run code that isn't designed for Plan 9. You could build whatever backplane type thing you want out of plan 9 but the end goal is still likely to be to run some web app or REST api server. Unless someone does a great deal of effort to port all of those environments that people want (nodejs, modern python, etc) you're going to be stuck using a VM and losing a lot of the benefit.

This feels similar to what Joyent did with lxzones in SmartOS, where the backplane was solaris based but the apps they were running for clients were using Linux. It's hard to make the plan 9 backplane better enough to warrant dealing with integrating the guest and host environment.

[zozbot234]

> Unless someone does a great deal of effort to port all of those environments that people want (nodejs, modern python, etc) you're going to be stuck using a VM and losing a lot of the benefit.

It should not be a huge deal of effort since as you mention the plan9 syscall API is simpler than on Linux. The added plan9 support could then also serve as a kind of "toy" backend that could make the rest of the code more understandable in other ways.

I'd even argue that OP's early experiment with such a port of tailscale shows precisely such an outcome.

[adriangrigore]

The problem is porting the compilers! There is no C++ compiler on Plan 9.

[packetlost]

Yeah, but also the type of person who is going to use Plan 9 isn't going to want to write C++, of all languages.

The general problem stands though, almost no languages support Plan 9

[packetlost]

> There aren't really union filesystems per se, the plan 9 kernel provides unions through its namespace model.

Yes, this is what I'm referring to. It's really many filesystems unioned into one namespace that is controllable per-process.

> In my opinion part of the reason why the userspace tools can be as nice as they are, are due to the use of file system interfaces and the simplistic syscall API. Could you elaborate more on the issues you see with the use of these?

I didn't say I had any issues, I said I preferred them! Aside from a lack of familiarity and needing to install plan9ports on other systems, I haven't had issues.

> In regards to using it for a "cloud native" stack, the issue is that people want to run code that isn't designed for Plan 9. You could build whatever backplane type thing you want out of plan 9 but the end goal is still likely to be to run some web app or REST api server.

Right, language support is the biggest issue with running on Plan 9 from that perspective, at least for "server" workloads. Excluding graphical APIs, the basic stuff (file IO, networking, etc.) isn't all that hard to add to a language (it of course depends). The real trouble is things that have no equivalent in Plan 9, such as mmap and shm.

> This feels similar to what Joyent did with lxzones in SmartOS, where the backplane was solaris based but the apps they were running for clients were using Linux.

This is also what Oxide is doing. Their rack's OS is IllumOS but their customers are expected to only interface with the OS via their tooling and instead provision VMs.

> It's hard to make the plan 9 backplane better enough to warrant dealing with integrating the guest and host environment

If I were doing it, I would do it the other way! Run Plan 9 in a backplane/hypervisor and target it from the language level. The nice part is the systems programming model!

[zozbot234]

> Excluding graphical APIs, the basic stuff (file IO, networking, etc.) isn't all that hard to add to a language (it of course depends).

You could implement a modern graphical API on top of virtio-gpu, which would give you low-level access to accelerated graphics.

> The real trouble is things that have no equivalent in Plan 9, such as mmap and shm.

Some uses of mmap and shm actually seem to have a near-equivalent already in plan9's segattach. Other uses would require some implementation of distributed shared memory (i.e. implementing the usual CPU concurrency model over the network) to be made feasible while keeping to the usual networked-OS focus of plan9.

[packetlost]

Right, you could do it... maybe. Some languages/libraries/runtimes could have specific expectations around the specifics of mmap that can't easily be papered over, but I suspect it would be a minority of cases

[zozbot234]

It could be used to replace k8s-based deployments (also Docker Swarms, etc.) since system interfaces on Plan 9 are namespaced and containerized "out-of-the-box" as part of its basic design (and this is one of the most prominent additions compared to *NIX). It's not a hacked-on feature as with Linux.