On Sat, Aug 09, 2025 at 03:08:21PM -0700, ron minnich wrote:
> Just a reminder, if you get too stuck in an emacs frame of mind, you're
> really going to miss the full power of acme specifically, and plan 9 in
> general.
>
>[...]
> It's not that acme does less. It does things on an orthogonal axis to
> emacs. In emacs, to get more capabilities, people tend to resort to lisp.
> In acme, to get more capabilities, people resort to building tool pipelines
> that *they can also use outside acme*. To me, that's very important. Emacs
> solutions typically only work in emacs (true for vim and zed and on and on
> ...) whereas acme can be a way to prototype things that can be used outside
> acme.
>
> That's kind of plan 9 (to me) in a nutshell: not special purpose solutions
> for single tools, but solutions that work across a wide range of tools.
This is exactly my inclination (mathematical "partition") [Note: I'm
not an emacs user.]
But I made an interesting exercise this week-end. I was on the train,
again, and brought with me Vita Nuova printed volume of "Plan9 3rd
Edition, Programmer's Manual [Documents]" to re-read "Plan 9 from Bell
Labs" by Rob Pike and al.
And I asked myself: if I was to "edit" or "update" the document,
considering Nix primilarily but not only:
a) Would Nix mandates so huge modifications that it would be
regarding Plan9 as a big departure that Plan9 is regarding Unix?
b) Would a policy of allocation of resources, taking into
account building a special environment and tying some programs to some
kernel-cores fit in the plan 9 namespace scheme?
c) Is there specific points that I would date to judge having
not hit on the nail?
The answer for a) is No: Nix fits quite well in the whole scheme, it
is a mandatory refinement, it imposes only to add something to the
scheme, not to modify things---The key point being that a "system" has
to be regarded as whatever processors tightly tied and sharing memory
with a MMU, and that inside such a system one will have to refine more
the species, because, for example, "riscv" doesn't mean a lot by
itself: the ISA is modular so not every riscv processor can interprete
every instruction.
The answer for b) is Yes: the way Plan9 builds namespace can be
extended, in this case once more by adding possibilities, not by
modifying the scheme. The questions that arise (expressed in another
thread) concerning setuid and setting an environment have all to do
with "what has to be definitively attached to a file?": the rwx
permissions? Is is a way of modifying the namespace, so it is not
"definitively attached". The user having authority (to modify it and
to propose it)? This one yes. The true nature of the file? This one
yes, it should: in plan9 this nature is given by the file hierarchy
(compatible binary under amd64/; scripts under rc/ etc.); should it be
explicitely set on the file level? Are the binaries so encoded that
the ISA (including for riscv the optional) can be retrieved from some
defined place in the file?
=> ACS and variants are, for me, a nightmare. And they are
generally attached to file systems. Tying some programs to some cores
in the namespace seems more simple, because "The file system model is
well-understood, both by system builders and general users, so
services that present file-like interfaces are easy to build, easy to
understand, and easy to use." I would not change one word to this...
The answer for c) is Yes: the part that I would alter the most are
"The Command-Level View". The so-called GUI and the "windows" are
red-herrings. The difference is that you have whether a 1D interface
(you can interact and see only a line) or a 2D interface (you can see
simultaneously several different rows).
With 1D, you have no choice: you are echoing what you enters at the
very same place where what the program generates is displayed
intermixed with what the program spits about errors.
If you have the opportunity to display simultaneously different rows,
you will echo your input in one place, the output in another one, and
the errors still elsewhere.
The "window" is not key: it is an implementation detail (a subset of
rows). The important thing is 2D versus 1D.
Once this is understood, you realize that even with 1D, you could use
ed(1) to write and edit your commands before sending them (w!rc), giving
you edition, history and scripting! Trying, at least, to use the one
line of display you have at disposal to at least separate in a timely
manner when it is used for stdin, when it is used for stdout, and when
it is used for stderr (I personnally think there should be a stdstat
to send messages about progression of processing or help messages,
that are not errors).
To come back to the beginning: I do suggest to you guys to take "Plan
9 from Bell Labs" and to "edit" it, to think about what to change,
what to add, what to remove. The main structure holds; this doesn't
mean that everything has to stay the same. It can be even more Plan9ish ;-)
--
Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
http://www.kergis.com/
http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T9209adeaba1b3a8a-M4a6f727e8245add071eca1d7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
