Re: [9fans] The Big Questioning: Plan 9 everywhere?

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 10968 bytes --]

"...(C is faster and more portable than golang)  ..."

It's always best if we can keep these discussions factual or, at least, if
we make a claim, we can back it up.

For example, the u-root version of dd, written in Go, is faster and more
portable than many C and Rust versions. Measured: GNUBIN dd from /dev/zero
to /dev/null tops out at 20 GiB/S on my s76 laptop; the Go version tops out
at 50. The GNUbin dd has no hope of running on Plan 9; the u-root version
compiles with no changes. golang has better speed and portability in this
one example.

If you've got some factual basis for such a broad claim, I'm happy to hear
it.


On Sat, Jun 21, 2025 at 11:00 AM G. David Butler <gdb@dbsystems.com> wrote:

> Brian,
> 
> I am always looking for kindred spirits and your message strikes a cord.
> So I looked you up and read a bit about your ENIAC simulator. Not because
> I’m particularly interested in the ENIAC but your golang simulation of it.
> 
> Where does Plan9 fit? I was a very early adopter of Plan 9. I liked some
> of its concepts and disliked others. (Long story that can be found in this
> list’s history.) The one that really took root was the channel theme of the
> language ALEF (https://en.wikipedia.org/wiki/Alef_(programming_language)) that
> Pike used to create rio and acme. Because of issues maintaining the
> language, the Plan 9 team created a C coroutine library to support the
> needed functionality to re-write the tools in C (
> https://swtch.com/libtask/). ALEF got channels from Pike’s Newsqueak that
> was invoked with the command “squint”. The significance is a paper written
> by M. Douglas McIlroy “Squinting at Power Series” (
> https://swtch.com/~rsc/thread/squint.pdf) and my implementation I used to
> test my C / pthread channel library. One thing difficult with testing a
> highly concurrent / parallel runtime environment is its non-deterministic
> execution. What is great about his paper is after all the huge number of
> threads and channels coming and going, the correct coefficients of the TAN
> function prove it works.
> 
> Back to your ENIAC simulator and its extensive use of threads and
> channels. It looks like another good test of my channel implementation.
> Also, like the Newsqueak implementation of channels, the golang
> implementation of channels has shortcomings that I improved.
> 
> Why am I reaching out? I don’t want to know about the ENIAC or learn
> golang well enough to translate your simulator. But if you are interested
> in an even more portable version of your simulator (C is faster and more
> portable than golang) I propose a collaboration to do it. What do I get out
> of it? Another through test of my channels. And why do I want to do that?
> Read below.
> 
> David
> 
> On Jun 6, 2025, at 6:56 PM, Brian L. Stuart <blstuart@bellsouth.net>
> wrote:
> 
> So I've been seeing big-picture/philosophical discussions arise on 9fans
> for about 25 years.  Usually I just sit back with my bowl of popcorn and
> watch.  Every once in a while I'll jump in and present a painfully long
> dissertation, and that's today.  For those new to my perspective, I've
> been at this stuff for nearly 50 years (I wrote my first code in '76
> or '77), and as time has gone by, I find myself becoming more and more
> the G.H. Hardy of computing.  For those who don't know that reference,
> look up his essay "A Mathematician's Apology."  The semi-serious tl;dr
> is "If anyone ever finds a practical application of my work, I'll
> consider it a failure."
> 
> My launching point today is the statement made in various ways by
> several of the contributors that computers are tools.  Of course, I'm
> aware that's the case for some people, and we've all done applied
> things to put food on the table.  But if that were the whole point
> of computing, I'd be bored out of my skull.  In the same way that
> a study of physics might result in a better widget for the unwashed
> masses but that's not its purpose, so a study of computer science
> might result in a similar better widget but that's not its purpose.
> Physics is the study of phenomena surrounding elementary particles
> and forces.  Computer Science is the study of phenomena surrounding
> the property of universality.  It requires no other justification.
> We made a really big mistake back in the '60s and '70s when we got
> excited about computers and people asked why and what good are they.
> We tried to come up with justifications when we would have been
> better off just saying, "you wouldn't be interested; they're just
> for us nerds."  I continue to be amused that one of our justifications
> was always keeping track of recipes in a kitchen.  If you're not
> familiar with it, check out the infamous "kitchen computer" from
> an old Neiman Marcus catalog.
> 
> You would be correct then to infer that I don't really put any
> weight on how many users we bring into the community.  This is
> the reason why by 2005 to 2010, I had largely turned my back on
> Linux.  It seemed that too many decisions in that community were
> about making things "easy" for those who had no UNIX experience
> at the expense of those who did.  It seems that much of the open
> source world has come to measure success by user adoption and
> number of commits to the source control preference of the decade.
> Neither of those draw my attention.  If there is any correlation
> between quality and popularity, it is negative.  That gets us to
> the general topic of the so-called "user."  The garbage promulgated
> by the self-appointed UI experts is almost always directly opposed
> to what I want.  I have plans in the after-life to use an endless
> can of lighter fluid to stoke the fires burning the morons who
> put huge trackpads where the heels of my hands belong on a laptop.
> What would happen to music if piano and guitar makers applied the
> same stupidity to help prevent beginners from making mistakes.  Maybe
> there is a place for the record player, but if you damage my piano
> to turn it into a record player, you're a force for evil, not good.
> Along similar lines, the justifications that are made for most of
> the UI commandments (including the precious mouse) are prefect
> examples of measuring the wrong thing.  Speed of interface is
> irrelevant.  It doesn't matter whether I use ed and use search
> to find the bit I want to edit, or whether I use acme and let
> the mouse scroll to where I want to edit.  The difference is lost
> in the noise because any programmer or writer worth a damn spends
> far more time thinking and drawing diagrams on paper than in
> typing and clicking.  If you want to respond with "but most
> people don't write software or papers" then see my rant on the
> piano vs the record player.  Because the computer is a finite
> realization of the universal machine Turing identified, it exists
> to be programmed.  To not create with it is to use it not as
> a piano but as a toaster.
> 
> As many of you know, I already have my own private language to
> minimize the spikes in blood pressure every time the C standards
> committee meets.  Although POSIX does still exist when I teach,
> I no longer go anywhere near it when I'm programming.  So it
> shouldn't be surprising to learn that in the last several years,
> my thoughts have moved away from "what can I contribute to the
> Plan 9 world" to "what ideas from Plan 9 would I borrow for
> a private system" or "should I just use the Plan 9 kernel and
> build my own environment around it."  Of course, I also have
> to solve the problem of hardware.  The x86 is a steaming pile
> of garbage and one of my objectives is to become an x86-free
> zone.  I've also come to the conclusion that it is so horrific
> that what sticks to it is only the similarly disgusting stuff
> like ACPI, UEFI, etc.  What scares me to death is that some
> of that same garbage has started to cling to what could
> otherwise be reasonable architectures.  At least the Raspberry
> Pi is mostly its own world, so most of my Plan 9 work these
> days is centered there.  But I am starting to think I might
> have to create my own hardware to truly escape from the
> breathtaking stupidity that has come to dominate the industry.
> Yes, I've even thought about resurrecting a 68000 machine
> I wire-wrapped nearly 40 years ago.
> 
> Much of my aesthetic is described by the quote from
> Saint-Exupery, "Perfection is achieved, not when there is
> nothing more to add, but when there is nothing left to take
> away."  Now I'm not telling people they shouldn't add for
> themselves if they want.  But as I move toward disconnecting
> from the parts of the computing world that give me heartburn
> to stay in the parts that give me intellectual satisfaction
> and fulfillment, I expect to be taking things out, rather
> than adding them.  Everyone can have their own reasons
> for being part of the community and their own objectives
> moving forward.  But for me the reasons I'm here are largely
> dominated by the minimalism of the design where I can feel
> direct connections to the individuals who created it, the
> stability of the code base, and the smallness of the community.
> 
> A little while back I found myself trying to articulate what
> I really saw as programming while I was walking.  By the time
> I got back to the office, I had a phrasing I liked, so I
> typed it up in TeX with \magnification=3584 and put the
> output on my wall.  The other day I was catching up with
> one of our alums who has recently finished her PhD at Penn
> and she saw it, said she liked it, and took a picture of it.
> It reads, "Programming is the process by which we take an
> idea, a concept, existing in nothing but a pattern of firing
> neurons and transform it through pure thought into the
> definition of a machine, a definition that can be interpreted
> and emulated by a universal machine to manipulate the physical
> world.  All else taints and compromises the purity and beauty
> of programming."
> 
> There's your semi-decadal tirade from the old guy to remind
> everyone that computing is not really about the nonsense that
> pervades the general culture.
> 
> BLS
> 
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-Mec5883aa609ac470d8667146>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M2989ae9467b608f69bfb7ef8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 15074 bytes --]

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[G. David Butler]

[-- Attachment #1: Type: text/html, Size: 15741 bytes --]

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[ori]

I don't think language wars are on topic here. Let's try to
keep the discussion focused on Plan 9 and related technologies.

Quoth G. David Butler <gdb@dbsystems.com>:
> Let me stand on the shoulders of giants: https://sqlite.org/whyc.html
> [https://sqlite.org/whyc.html]
> David
> 
> On Jun 22, 2025, at 7:34 AM, ron minnich <rminnich@gmail.com> wrote:
> 
> 
> "...(C is faster and more portable than golang)..."
> It's always best if we can keep these discussions factual or, at
> least, if we make a claim, we can back it up.
> For example, the u-root version of dd, written in Go, is faster and
> more portable than many C and Rust versions. Measured: GNUBIN dd from
> /dev/zero to /dev/null tops out at 20 GiB/S on my s76 laptop; the Go
> version tops out at 50. The GNUbin dd has no hope of running on Plan
> 9; the u-root version compiles with no changes. golang has better
> speed and portability in this one example.
> If you've got some factual basis for such a broad claim, I'm happy to
> hear it.
> 
> On Sat, Jun 21, 2025 at 11:00 AM G. David Butler < gdb@dbsystems.com
> [mailto:gdb@dbsystems.com]> wrote:
> 
> Brian,
> 
> I am always looking for kindred spirits and your message strikes a
> cord. So I looked you up and read a bit about your ENIAC simulator.
> Not because I’m particularly interested in the ENIAC but your golang
> simulation of it.
> Where does Plan9 fit? I was a very early adopter of Plan 9. I liked
> some of its concepts and disliked others. (Long story that can be
> found in this list’s history.) The one that really took root was the
> channel theme of the language ALEF (
> https://en.wikipedia.org/wiki/Alef_(programming_language)
> [https://en.wikipedia.org/wiki/Alef_(programming_language)]) that Pike
> used to create rio and acme. Because of issues maintaining the
> language, the Plan 9 team created a C coroutine library to support the
> needed functionality to re-write the tools in C (
> https://swtch.com/libtask/ [https://swtch.com/libtask/]). ALEF got
> channels from Pike’s Newsqueak that was invoked with the command
> “squint”. The significance is a paper written by M. Douglas McIlroy
> “Squinting at Power Series” ( https://swtch.com/~rsc/thread/squint.pdf
> [https://swtch.com/~rsc/thread/squint.pdf]) and my implementation I
> used to test my C / pthread channel library. One thing difficult with
> testing a highly concurrent / parallel runtime environment is its
> non-deterministic execution. What is great about his paper is after
> all the huge number of threads and channels coming and going, the
> correct coefficients of the TAN function prove it works.
> Back to your ENIAC simulator and its extensive use of threads and
> channels. It looks like another good test of my channel
> implementation. Also, like the Newsqueak implementation of channels,
> the golang implementation of channels has shortcomings that I
> improved.
> Why am I reaching out? I don’t want to know about the ENIAC or learn
> golang well enough to translate your simulator. But if you are
> interested in an even more portable version of your simulator (C is
> faster and more portable than golang) I propose a collaboration to do
> it. What do I get out of it? Another through test of my channels. And
> why do I want to do that? Read below.
> David
> 
> On Jun 6, 2025, at 6:56 PM, Brian L. Stuart < blstuart@bellsouth.net
> [mailto:blstuart@bellsouth.net]> wrote:
> 
>  So I've been seeing big-picture/philosophical discussions arise on
> 9fans
> for about 25 years. Usually I just sit back with my bowl of popcorn
> and
> watch. Every once in a while I'll jump in and present a painfully long
> dissertation, and that's today. For those new to my perspective, I've
> been at this stuff for nearly 50 years (I wrote my first code in'76
> or'77), and as time has gone by, I find myself becoming more and more
> the G.H. Hardy of computing. For those who don't know that reference,
> look up his essay"A Mathematician's Apology." The semi-serious tl;dr
> is"If anyone ever finds a practical application of my work, I'll
> consider it a failure."
> 
> My launching point today is the statement made in various ways by
> several of the contributors that computers are tools. Of course, I'm
> aware that's the case for some people, and we've all done applied
> things to put food on the table. But if that were the whole point
> of computing, I'd be bored out of my skull. In the same way that
> a study of physics might result in a better widget for the unwashed
> masses but that's not its purpose, so a study of computer science
> might result in a similar better widget but that's not its purpose.
> Physics is the study of phenomena surrounding elementary particles
> and forces. Computer Science is the study of phenomena surrounding
> the property of universality. It requires no other justification.
> We made a really big mistake back in the'60s and'70s when we got
> excited about computers and people asked why and what good are they.
> We tried to come up with justifications when we would have been
> better off just saying,"you wouldn't be interested; they're just
> for us nerds." I continue to be amused that one of our justifications
> was always keeping track of recipes in a kitchen. If you're not
> familiar with it, check out the infamous"kitchen computer" from
> an old Neiman Marcus catalog.
> 
> You would be correct then to infer that I don't really put any
> weight on how many users we bring into the community. This is
> the reason why by 2005 to 2010, I had largely turned my back on
> Linux. It seemed that too many decisions in that community were
> about making things"easy" for those who had no UNIX experience
> at the expense of those who did. It seems that much of the open
> source world has come to measure success by user adoption and
> number of commits to the source control preference of the decade.
> Neither of those draw my attention. If there is any correlation
> between quality and popularity, it is negative. That gets us to
> the general topic of the so-called"user." The garbage promulgated
> by the self-appointed UI experts is almost always directly opposed
> to what I want. I have plans in the after-life to use an endless
> can of lighter fluid to stoke the fires burning the morons who
> put huge trackpads where the heels of my hands belong on a laptop.
> What would happen to music if piano and guitar makers applied the
> same stupidity to help prevent beginners from making mistakes. Maybe
> there is a place for the record player, but if you damage my piano
> to turn it into a record player, you're a force for evil, not good.
> Along similar lines, the justifications that are made for most of
> the UI commandments (including the precious mouse) are prefect
> examples of measuring the wrong thing. Speed of interface is
> irrelevant. It doesn't matter whether I use ed and use search
> to find the bit I want to edit, or whether I use acme and let
> the mouse scroll to where I want to edit. The difference is lost
> in the noise because any programmer or writer worth a damn spends
> far more time thinking and drawing diagrams on paper than in
> typing and clicking. If you want to respond with"but most
> people don't write software or papers" then see my rant on the
> piano vs the record player. Because the computer is a finite
> realization of the universal machine Turing identified, it exists
> to be programmed. To not create with it is to use it not as
> a piano but as a toaster.
> 
> As many of you know, I already have my own private language to
> minimize the spikes in blood pressure every time the C standards
> committee meets. Although POSIX does still exist when I teach,
> I no longer go anywhere near it when I'm programming. So it
> shouldn't be surprising to learn that in the last several years,
> my thoughts have moved away from"what can I contribute to the
> Plan 9 world" to"what ideas from Plan 9 would I borrow for
> a private system" or"should I just use the Plan 9 kernel and
> build my own environment around it." Of course, I also have
> to solve the problem of hardware. The x86 is a steaming pile
> of garbage and one of my objectives is to become an x86-free
> zone. I've also come to the conclusion that it is so horrific
> that what sticks to it is only the similarly disgusting stuff
> like ACPI, UEFI, etc. What scares me to death is that some
> of that same garbage has started to cling to what could
> otherwise be reasonable architectures. At least the Raspberry
> Pi is mostly its own world, so most of my Plan 9 work these
> days is centered there. But I am starting to think I might
> have to create my own hardware to truly escape from the
> breathtaking stupidity that has come to dominate the industry.
> Yes, I've even thought about resurrecting a 68000 machine
> I wire-wrapped nearly 40 years ago.
> 
> Much of my aesthetic is described by the quote from
> Saint-Exupery,"Perfection is achieved, not when there is
> nothing more to add, but when there is nothing left to take
> away." Now I'm not telling people they shouldn't add for
> themselves if they want. But as I move toward disconnecting
> from the parts of the computing world that give me heartburn
> to stay in the parts that give me intellectual satisfaction
> and fulfillment, I expect to be taking things out, rather
> than adding them. Everyone can have their own reasons
> for being part of the community and their own objectives
> moving forward. But for me the reasons I'm here are largely
> dominated by the minimalism of the design where I can feel
> direct connections to the individuals who created it, the
> stability of the code base, and the smallness of the community.
> 
> A little while back I found myself trying to articulate what
> I really saw as programming while I was walking. By the time
> I got back to the office, I had a phrasing I liked, so I
> typed it up in TeX with \magnification=3584 and put the
> output on my wall. The other day I was catching up with
> one of our alums who has recently finished her PhD at Penn
> and she saw it, said she liked it, and took a picture of it.
> It reads,"Programming is the process by which we take an
> idea, a concept, existing in nothing but a pattern of firing
> neurons and transform it through pure thought into the
> definition of a machine, a definition that can be interpreted
> and emulated by a universal machine to manipulate the physical
> world. All else taints and compromises the purity and beauty
> of programming."
> 
> There's your semi-decadal tirade from the old guy to remind
> everyone that computing is not really about the nonsense that
> pervades the general culture.
> 
> BLS
> [https://9fans.topicbox.com/groups/9fans/subscription]
> 
> 9fans [https://9fans.topicbox.com/latest] / 9fans / see discussions
> [https://9fans.topicbox.com/groups/9fans] + participants
> [https://9fans.topicbox.com/groups/9fans/members] + delivery
> [https://9fans.topicbox.com/groups/9fans/subscription] options
> Permalink
> [https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-Me575cba8b6ed9367d9c5cbb7]

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-Mee76249bb4b11cc3b6ba3de5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[Clout Tolstoy]

[-- Attachment #1: Type: text/plain, Size: 3694 bytes --]

could elua (embedded lua) potentially be ran in vmx? It would probably take
some porting, but that runs on a handful of bare metal SoC's.  Was thinking
it could be an interesting way to jail it off from the OS. One would have
to figure out how to mount the rootfs via p9fs and it would probably be
golden.

Node9 has always looked cool. (Inferno with lua replacing limbo).

On Fri, Jul 4, 2025, 1:54 PM David Leimbach via 9fans <9fans@9fans.net>
wrote:

> Fennel seems to work well with Lua as well. I started writing a 9P server
> to track players playing different dart games. (Why not?)
>
> And it works. But it’s all hard coded, so I started thinking of encoding
> the rules for each game in fennel.
>
>
> Sent from my iPhone
>
> > On Jul 4, 2025, at 11:55 AM, Ron Minnich <rminnich@p9f.org> wrote:
> >
> > Nice to hear about Lua and StreetLisp. It would probably make sense to
> > have a native languages page or something like it on the foundation
> > web site, so people know about this work!
> >
> >> On Thu, Jul 3, 2025 at 4:05 PM Thaddeus Woskowiak <
> tswoskowiak@gmail.com> wrote:
> >>> On Thu, Jul 3, 2025, 5:02 PM Lyndon Nerenberg (VE7TFX/VE6BBM) <
> lyndon@orthanc.ca> wrote:
> >>>
> >>> Thaddeus Woskowiak writes:
> >>>
> >>>> I'm not a programming wiz but it would be nice to have a well
> supported
> >>>> language on Plan 9 besides c. I prefer that it be small and simple
> enough
> >>>> to git/clone then mk install and jump right in. A great example of the
> >>>> simplicity I'm after is the native port of Lua and the recently
> developed
> >>>> Street Lisp. All I need to do is clone a repo and either run a script
> or mk
> >>>> install and I'm ready to write and run code.
> >>>
> >>> Porting lua wouldn't be that hard.  The lua code base is quite
> >>> portable, and getting it bootstrapped using APE should be very easy.
> >>> Once you have done that, you can start converting it to native Plan
> >>> 9.  I did this (native port, no APE internediary) once, many years
> >>> ago, but then I lost the source tree :-(  Re-porting it has been
> >>> on my todo list for quite a while, but I just haven't found the
> >>> cycles.
> >>>
> >>> As for go, you could go back to the last version that built from
> >>> C and call it a day.  Or even earlier to the last go versions that
> >>> used the 6g compiler, before they introduced the 'go build' bullshit.
> >>> That compiler was ripping fast. And it works with make.  (I am
> >>> utterly fed up with languages that insist you use their bespoke
> >>> build systems.  This is why I will never use rust.  And with
> >>> every new release, I am becoming much less fond of go.)
> >>>
> >>> --lyndon
> >>
> >>
> >> Sorry, I was not clear and carelessly left out the reference to "native
> port of Lua", http://shithub.us/kvik/lu9/HEAD/info.html
> >>
> >> So native Lua on 9 thanks to kvik. No APE. Whole thing takes seconds to
> setup. Git/clone .... Mk pull. Mk install. Done. Imagine if Go was that
> simple.
> >>
> >> StreetLisp is here thanks to sigrid and spew: https://git.sr.ht/~ft/sl
> >>
> >> If anyone ports a language they should strive to match the above
> efforts in terms of making it native using existing tools like mk and git,
> plus being simple to install. The faster you can on-board someone, the
> better.
> >> 9fans / 9fans / see discussions + participants + delivery options
> Permalink

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9224bb9c9c173dec-M1e4079820297d2c63ad717b3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 6036 bytes --]

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[Ron Minnich]

Nice to hear about Lua and StreetLisp. It would probably make sense to
have a native languages page or something like it on the foundation
web site, so people know about this work!

On Thu, Jul 3, 2025 at 4:05 PM Thaddeus Woskowiak <tswoskowiak@gmail.com> wrote:
>
> On Thu, Jul 3, 2025, 5:02 PM Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca> wrote:
>>
>> Thaddeus Woskowiak writes:
>>
>> > I'm not a programming wiz but it would be nice to have a well supported
>> > language on Plan 9 besides c. I prefer that it be small and simple enough
>> > to git/clone then mk install and jump right in. A great example of the
>> > simplicity I'm after is the native port of Lua and the recently developed
>> > Street Lisp. All I need to do is clone a repo and either run a script or mk
>> > install and I'm ready to write and run code.
>> 
>> Porting lua wouldn't be that hard.  The lua code base is quite
>> portable, and getting it bootstrapped using APE should be very easy.
>> Once you have done that, you can start converting it to native Plan
>> 9.  I did this (native port, no APE internediary) once, many years
>> ago, but then I lost the source tree :-(  Re-porting it has been
>> on my todo list for quite a while, but I just haven't found the
>> cycles.
>> 
>> As for go, you could go back to the last version that built from
>> C and call it a day.  Or even earlier to the last go versions that
>> used the 6g compiler, before they introduced the 'go build' bullshit.
>> That compiler was ripping fast. And it works with make.  (I am
>> utterly fed up with languages that insist you use their bespoke
>> build systems.  This is why I will never use rust.  And with
>> every new release, I am becoming much less fond of go.)
>> 
>> --lyndon
>
>
> Sorry, I was not clear and carelessly left out the reference to "native port of Lua", http://shithub.us/kvik/lu9/HEAD/info.html
>
> So native Lua on 9 thanks to kvik. No APE. Whole thing takes seconds to setup. Git/clone .... Mk pull. Mk install. Done. Imagine if Go was that simple.
>
> StreetLisp is here thanks to sigrid and spew: https://git.sr.ht/~ft/sl
>
> If anyone ports a language they should strive to match the above efforts in terms of making it native using existing tools like mk and git, plus being simple to install. The faster you can on-board someone, the better.
> 9fans / 9fans / see discussions + participants + delivery options Permalink

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M82b428fbe3f0596b4cae017d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[Thaddeus Woskowiak]

[-- Attachment #1: Type: text/plain, Size: 2307 bytes --]

On Thu, Jul 3, 2025, 5:02 PM Lyndon Nerenberg (VE7TFX/VE6BBM) <
lyndon@orthanc.ca> wrote:

> Thaddeus Woskowiak writes:
>
> > I'm not a programming wiz but it would be nice to have a well supported
> > language on Plan 9 besides c. I prefer that it be small and simple enough
> > to git/clone then mk install and jump right in. A great example of the
> > simplicity I'm after is the native port of Lua and the recently developed
> > Street Lisp. All I need to do is clone a repo and either run a script or
> mk
> > install and I'm ready to write and run code.
> 
> Porting lua wouldn't be that hard.  The lua code base is quite
> portable, and getting it bootstrapped using APE should be very easy.
> Once you have done that, you can start converting it to native Plan
> 9.  I did this (native port, no APE internediary) once, many years
> ago, but then I lost the source tree :-(  Re-porting it has been
> on my todo list for quite a while, but I just haven't found the
> cycles.
> 
> As for go, you could go back to the last version that built from
> C and call it a day.  Or even earlier to the last go versions that
> used the 6g compiler, before they introduced the 'go build' bullshit.
> That compiler was ripping fast. And it works with make.  (I am
> utterly fed up with languages that insist you use their bespoke
> build systems.  This is why I will never use rust.  And with
> every new release, I am becoming much less fond of go.)
> 
> --lyndon


Sorry, I was not clear and carelessly left out the reference to "native
port of Lua", http://shithub.us/kvik/lu9/HEAD/info.html

So native Lua on 9 thanks to kvik. No APE. Whole thing takes seconds to
setup. Git/clone .... Mk pull. Mk install. Done. Imagine if Go was that
simple.

StreetLisp is here thanks to sigrid and spew: https://git.sr.ht/~ft/sl

If anyone ports a language they should strive to match the above efforts in
terms of making it native using existing tools like mk and git, plus being
simple to install. The faster you can on-board someone, the better.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-Maa7d0c9f7f388797771f414b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4119 bytes --]

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[Dan Cross]

On Tue, Jul 1, 2025 at 6:37 PM Jacob Moody <moody@posixcafe.org> wrote:
> One of the reasons why Plan 9 is nice is that we do not have to copy everyone else's mistakes and assume
> their baggage for supporting X, Y, and Z environments.
>
> [snip]
> If people feel like we need something other than C, I'd prefer to see us write something for ourselves, not import another language
> off the shelf. If you want Node or Rust you know where to find it, I don't think we need them in Plan 9. What is the benefit of Plan 9
> if all it does is run Unix software but (very likely) worse?

I agree with much of what you said, particularly the last sentence,
but want to clarify a point and also sound a note of caution.

I think what you meant, and please correct me if I'm wrong, is that if
one wants something other than C, one should write an implementation
for oneself, instead of trying to import the (large) upstream version.
But I caution against trying to, say, design a new language just for
Plan 9. Language design and language _implementation_ are independent
things, even if they are cousins rather than complete strangers. Do it
for fun or as a research experiment? Sure; have at it. But as a
serious production endeavor specific to plan 9? Perhaps not.

Also, the cautionary note is to not be too reactive against the rest
of the world (which is something I readily admit myself guilty of,
when it comes to Plan 9). I'm not saying that you specifically are
suggesting being so, just that it's something that does happen quite a
bit. Doing something just to be different, when a perfectly adequate
solution exists that would fit within the large system ethos, isn't
terribly useful, either.

Different systems have different design philosophies and goals; plan
9's is interesting, but it's just one of many interesting systems.

> (To be clear I'm not against porting, and have done my own fair share of it. I just want Plan 9 to feel like Plan 9 and not an imitation
> of what you can get elsewhere. People should have the freedom to use whatever software they want, my focus is more on tools for building
> the system itself, which has a lot more constraints and considerations)

+1e6

        - Dan C.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M5fd534bc477099466581c159
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[Shawn Rutledge]

> On Jul 2, 2025, at 00:35, Jacob Moody <moody@posixcafe.org> wrote:
> If people feel like we need something other than C, I'd prefer to see us write something for ourselves, not import another language
> off the shelf. 

So what about Limbo then?  (I have no experience, so maybe I’m missing an obvious reason that it’s not more often used)

Is Limbo still more suitable than Go for this purpose, or did all the good ideas get migrated already?

I’m assuming 64-bit Dis can be implemented… in spite of needing an incompatible binary format.  I think I remember Charles saying there was some progress on that front.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M5dfafbc1faaa4930d9193616
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[Shawn Rutledge]

> On Jul 1, 2025, at 01:40, Ron Minnich <rminnich@p9f.org> wrote:
> 
> I think you may well be. We did try a push for plan 9 support in rust
> in 2019 or so, but found a distinct lack of interest.
> 
> rather than port the rust compiler to plan 9, if support ever got in,
> it might be easier to use the linux appliance approach:
> linux cargo build
> for example.
> 
> but first you'll need to convince those folks to be interested in plan
> 9 support at all.
> 
> https://github.com/rust-lang/rust/pull/74038/files

Well from the comment chain it looks more like they were waiting for "This PR needs rebasing and some contact info in case we need some help around the Harvey architecture” and then work stopped on Harvey, right?  (And I still don’t understand if there was a good technical reason for losing interest in continuing with Harvey, or just a human time limitation / prioritizing other things.)

But I was also thinking that the first step is to get the compiler to generate the Plan 9 binary format, which ought to be an uncontroversial patch.  (Or is it not that simple?)  Then you could bootstrap: the Rust compiler is written in Rust, isn’t it?

Likewise, do we still have the problem that the Go compiler can’t generate the Plan 9 binary format for arm64?  Is that hard to solve?


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-Md6db1b432665e869bbbac8bb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[sirjofri via 9fans]

01.07.2025 02:38:46 Stanley Lieber <sl@stanleylieber.com>:
>> On Jun 30, 2025, at 6:39 PM, Stanley Lieber <sl@stanleylieber.com> wrote:
>>  > markdown
>>
>> this builds and runs on plan 9:
>>
>> https://www.pell.portland.or.us/~orc/Code/discount/

I'll look at that, it looks promising!

> actually, werc even ships an awk implementation:
> https://only9fans.com/sl/werc/63085c71ab79cb4defc3ba64b5285e7db86f0d07/bin/contrib/md2html.awk/f.html

I don't use werc. I also built a converter in awk for my epublish suite, which uses a markdown-inspired language. In this case though, I'd like to have a few more features such as those provided by discount (fenced code block, definitions, styles/classes, to name a few.)

> while i realize markdown was just an example, it’s interesting that a lot of useful tools can be easily implemented with bits and pieces we already have aboard.

One thing I hate is that everything nowadays has to be implemented in Python or C#, while it's often much easier to use languages like awk or sed (in combination with a shell script).

sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-Mbddcf5204ac8f6922c8f1b20
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[Bakul Shah via 9fans]

In spite of early controversies the language seems to have
come along nicely. I'd suggest play with it and find out
for yourself (if interested).

> On Jun 30, 2025, at 8:09 PM, ori@eigenstate.org wrote:
> 
> V is.. controversial. The author has made a huge number of
> questionable claims and promises.
> 
> In terms of new languages, there's some support in Zig for
> Plan 9:
> 
>        https://github.com/ziglang/zig/blob/master/src/link/Plan9.zig
>        https://github.com/ziglang/zig/blob/master/lib/std/os/plan9.zig
> 
> I have no idea of the current state.
> 
> Quoth Bakul Shah via 9fans <9fans@9fans.net>:
>> I like the V language - while much like Go, interoperates
>> with C quite well.  In fact its first compiler was written in
>> Go.  Compiles itself in under a sec on m1 mac & ryzen 2700
>> (v->c which is then compiled with tcc).  The "production"
>> version compiles in about 3s on the mac and 6s on freebsd
>> (splits generated C code in N files and compiles in parallel
>> with the system cc).  Still at version 0.4.11 but already
>> seems useful.
>> 
>> Targetting it to plan9 ?c compilers would be far easier than
>> porting llvm.  Most of the effort will likely be in separating
>> Unix/Linuxisms.
>> 
>> https://vlang.io/
>> 
>> [I want to write something like busybox to gain experience,
>> but no ETA]
>> 
>> [I dislike slow compiles and behemoth compilers so not much
>> interested in anything that requires llvm or gcc]
>> 
>>> On Jun 30, 2025, at 12:40 PM, Paul Lalonde <paul.a.lalonde@gmail.com> wrote:
>>> 
>>> I've thought of bringing Rust along.  It seems to be a thing in the world I'm finding myself in these days.
>>> The shortest path looks like adding the plan9 calling convention (and register convention) to LLVM and seeing if we can cross-compile our way to glory.
>>> But I'm certain I'm missing 100 other related things that will be much harder.
>>> Paul
>>> 
>>> On Mon, Jun 30, 2025 at 9:51 AM Danny Wilkins via 9fans <9fans@9fans.net> wrote:
>>> On Mon, Jun 30, 2025 at 10:31:40AM -0400, ori@eigenstate.org wrote:
>>>> 
>>>> The bigger problem is interest -- I don't have perl code I care
>>>> to run, does anyone else here?
>>>> 
>>> Technically I have a few perl tools that'd be nice to have on 9front, but
>>> not nice enough to go through the trouble of porting when I plan on rewriting
>>> them in C anyway. IMO Perl suffers from the 'problem' that you don't really
>>> write big s Software in it a lot of the time. It's pretty bespoke and that
>>> niche is handled much better by rc and awk on plan9 (I could easily rewrite
>>> those perl tools in rc+awk, but I'm not guaranteed to have rc on my linuxes.)
>>> 
>>> Python would probably be the most practical of the 'missing' languagess, but
>>> python was already in base installs for a long time due to hg, wasn't it?
>>> 
>>> Obviously what needs to push is rust and node so that p9 can be a real
>>> next gen server platform :) Think of all the apps we could run with electron.
>>> 9fans / 9fans / see discussions + participants + delivery options Permalink

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M475c42c87b76565dc8cf5cb3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[ori]

V is.. controversial. The author has made a huge number of
questionable claims and promises.

In terms of new languages, there's some support in Zig for
Plan 9:

        https://github.com/ziglang/zig/blob/master/src/link/Plan9.zig
        https://github.com/ziglang/zig/blob/master/lib/std/os/plan9.zig

I have no idea of the current state.

Quoth Bakul Shah via 9fans <9fans@9fans.net>:
> I like the V language - while much like Go, interoperates
> with C quite well.  In fact its first compiler was written in
> Go.  Compiles itself in under a sec on m1 mac & ryzen 2700
> (v->c which is then compiled with tcc).  The "production"
> version compiles in about 3s on the mac and 6s on freebsd
> (splits generated C code in N files and compiles in parallel
> with the system cc).  Still at version 0.4.11 but already
> seems useful.
> 
> Targetting it to plan9 ?c compilers would be far easier than
> porting llvm.  Most of the effort will likely be in separating
> Unix/Linuxisms.
> 
> https://vlang.io/
> 
> [I want to write something like busybox to gain experience,
>  but no ETA]
> 
> [I dislike slow compiles and behemoth compilers so not much
>  interested in anything that requires llvm or gcc]
> 
> > On Jun 30, 2025, at 12:40 PM, Paul Lalonde <paul.a.lalonde@gmail.com> wrote:
> > 
> > I've thought of bringing Rust along.  It seems to be a thing in the world I'm finding myself in these days.
> > The shortest path looks like adding the plan9 calling convention (and register convention) to LLVM and seeing if we can cross-compile our way to glory.
> > But I'm certain I'm missing 100 other related things that will be much harder.
> > Paul
> > 
> > On Mon, Jun 30, 2025 at 9:51 AM Danny Wilkins via 9fans <9fans@9fans.net> wrote:
> > On Mon, Jun 30, 2025 at 10:31:40AM -0400, ori@eigenstate.org wrote:
> > > 
> > > The bigger problem is interest -- I don't have perl code I care
> > > to run, does anyone else here?
> > > 
> > Technically I have a few perl tools that'd be nice to have on 9front, but
> > not nice enough to go through the trouble of porting when I plan on rewriting
> > them in C anyway. IMO Perl suffers from the 'problem' that you don't really
> > write big s Software in it a lot of the time. It's pretty bespoke and that
> > niche is handled much better by rc and awk on plan9 (I could easily rewrite
> > those perl tools in rc+awk, but I'm not guaranteed to have rc on my linuxes.)
> > 
> > Python would probably be the most practical of the 'missing' languagess, but
> > python was already in base installs for a long time due to hg, wasn't it?
> > 
> > Obviously what needs to push is rust and node so that p9 can be a real
> > next gen server platform :) Think of all the apps we could run with electron.
> > 9fans / 9fans / see discussions + participants + delivery options Permalink

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M7a2632792e6f91b58d1a396c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[Stanley Lieber]

[-- Attachment #1: Type: text/plain, Size: 338 bytes --]

> markdown

this builds and runs on plan 9:

https://www.pell.portland.or.us/~orc/Code/discount/

sl


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M43766e96dee6e13aa5f9923b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1045 bytes --]

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[Jacob Moody]

On 6/30/25 16:40, arnold@skeeve.com wrote:
> "Danny Wilkins via 9fans" <9fans@9fans.net> wrote:
> 
>> Obviously what needs to push is rust and node so that p9 can be a real
>> next gen server platform :) Think of all the apps we could run with electron.
> 
> Adding node is to invite a swarm of security problems.  Definitely
> not the Plan 9 way, IMHO.
> 
> Has anyone tried to build Gnu Awk under APE?  I've always wondered
> if it would work there.
> 

For fun I gave it a go, but we can't get past the configure:

cpu% cd /mnt/term/home/moody/downloads/gawk-5.3.2
cpu% ape/psh
$ ./configure
usage: ls [-ACFHLRUacdflprstu1] [file ...]
%s\n$
$

This is not too unusual, autotools plays very poorly with ape.
In the past for other port work I tend to just start from scratch with a
mkfile and use pcc as the $CC.


Thanks,
Jacob


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M2ac894d9664f618c69be32a7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[arnold]

Paul Lalonde <paul.a.lalonde@gmail.com> wrote:

> I've thought of bringing Rust along.  It seems to be a thing in the world
> I'm finding myself in these days.
> The shortest path looks like adding the plan9 calling convention (and
> register convention) to LLVM and seeing if we can cross-compile our way to
> glory.
> But I'm certain I'm missing 100 other related things that will be much
> harder.
> Paul

That would be really cool though.  It might also enable C++. (Yes, I know
how much this community dislikes C++, and I'm not a big fan either, but
there are undoubtedly things out there in C++ that would be useful
to have on Plan 9.)

Arnold

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M6dc469078d32411e8daaaecf
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[arnold]

"Danny Wilkins via 9fans" <9fans@9fans.net> wrote:

> Obviously what needs to push is rust and node so that p9 can be a real
> next gen server platform :) Think of all the apps we could run with electron.

Adding node is to invite a swarm of security problems.  Definitely
not the Plan 9 way, IMHO.

Has anyone tried to build Gnu Awk under APE?  I've always wondered
if it would work there.

Thanks,

Arnold

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M28b35f6965fa81dd25b4fc9a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[Paul Lalonde]

[-- Attachment #1: Type: text/plain, Size: 2643 bytes --]

Yes, there's absolutely a world of difference between having
rust-the-language available vs rust-the-ecosystem available.
Frankly, this is what amazes me the most about golang's portability.

Paul

On Mon, Jun 30, 2025, 2:31 p.m. <ori@eigenstate.org> wrote:

> I've heard reports of interesting trickery using linker scripts, where
> you just compile to a flat binary and then toss an a.out header on it.
> Then, from there, a few assembly stubs will probably work to make
> running programs.
>
> The rest of the work is just reinventing the world, since so much of
> the code out there is going to depend on libraries that use mmap,
> curses, select/poll/epoll/io_uring/kqueue/..., and you're probably
> not going to get far just naively pulling in deps.
>
> Quoth Paul Lalonde <paul.a.lalonde@gmail.com>:
> > I've thought of bringing Rust along.  It seems to be a thing in the world
> > I'm finding myself in these days.
> > The shortest path looks like adding the plan9 calling convention (and
> > register convention) to LLVM and seeing if we can cross-compile our way
> to
> > glory.
> > But I'm certain I'm missing 100 other related things that will be much
> > harder.
> > Paul
> >
> > On Mon, Jun 30, 2025 at 9:51 AM Danny Wilkins via 9fans <9fans@9fans.net
> >
> > wrote:
> >
> > > On Mon, Jun 30, 2025 at 10:31:40AM -0400, ori@eigenstate.org wrote:
> > > >
> > > > The bigger problem is interest -- I don't have perl code I care
> > > > to run, does anyone else here?
> > > >
> > > Technically I have a few perl tools that'd be nice to have on 9front,
> but
> > > not nice enough to go through the trouble of porting when I plan on
> > > rewriting
> > > them in C anyway. IMO Perl suffers from the 'problem' that you don't
> really
> > > write big s Software in it a lot of the time. It's pretty bespoke and
> that
> > > niche is handled much better by rc and awk on plan9 (I could easily
> rewrite
> > > those perl tools in rc+awk, but I'm not guaranteed to have rc on my
> > > linuxes.)
> > >
> > > Python would probably be the most practical of the 'missing'
> languagess,
> > > but
> > > python was already in base installs for a long time due to hg, wasn't
> it?
> > >
> > > Obviously what needs to push is rust and node so that p9 can be a real
> > > next gen server platform :) Think of all the apps we could run with
> > > electron.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M946d0de4d7ae1744d5c274d1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4578 bytes --]

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[ori]

I've heard reports of interesting trickery using linker scripts, where
you just compile to a flat binary and then toss an a.out header on it.
Then, from there, a few assembly stubs will probably work to make
running programs.

The rest of the work is just reinventing the world, since so much of
the code out there is going to depend on libraries that use mmap,
curses, select/poll/epoll/io_uring/kqueue/..., and you're probably
not going to get far just naively pulling in deps.

Quoth Paul Lalonde <paul.a.lalonde@gmail.com>:
> I've thought of bringing Rust along.  It seems to be a thing in the world
> I'm finding myself in these days.
> The shortest path looks like adding the plan9 calling convention (and
> register convention) to LLVM and seeing if we can cross-compile our way to
> glory.
> But I'm certain I'm missing 100 other related things that will be much
> harder.
> Paul
> 
> On Mon, Jun 30, 2025 at 9:51 AM Danny Wilkins via 9fans <9fans@9fans.net>
> wrote:
> 
> > On Mon, Jun 30, 2025 at 10:31:40AM -0400, ori@eigenstate.org wrote:
> > >
> > > The bigger problem is interest -- I don't have perl code I care
> > > to run, does anyone else here?
> > >
> > Technically I have a few perl tools that'd be nice to have on 9front, but
> > not nice enough to go through the trouble of porting when I plan on
> > rewriting
> > them in C anyway. IMO Perl suffers from the 'problem' that you don't really
> > write big s Software in it a lot of the time. It's pretty bespoke and that
> > niche is handled much better by rc and awk on plan9 (I could easily rewrite
> > those perl tools in rc+awk, but I'm not guaranteed to have rc on my
> > linuxes.)
> > 
> > Python would probably be the most practical of the 'missing' languagess,
> > but
> > python was already in base installs for a long time due to hg, wasn't it?
> > 
> > Obviously what needs to push is rust and node so that p9 can be a real
> > next gen server platform :) Think of all the apps we could run with
> > electron.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M6f8d50fa60cf74a1316742b8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[Paul Lalonde]

[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]

I've thought of bringing Rust along.  It seems to be a thing in the world
I'm finding myself in these days.
The shortest path looks like adding the plan9 calling convention (and
register convention) to LLVM and seeing if we can cross-compile our way to
glory.
But I'm certain I'm missing 100 other related things that will be much
harder.
Paul

On Mon, Jun 30, 2025 at 9:51 AM Danny Wilkins via 9fans <9fans@9fans.net>
wrote:

> On Mon, Jun 30, 2025 at 10:31:40AM -0400, ori@eigenstate.org wrote:
> >
> > The bigger problem is interest -- I don't have perl code I care
> > to run, does anyone else here?
> >
> Technically I have a few perl tools that'd be nice to have on 9front, but
> not nice enough to go through the trouble of porting when I plan on
> rewriting
> them in C anyway. IMO Perl suffers from the 'problem' that you don't really
> write big s Software in it a lot of the time. It's pretty bespoke and that
> niche is handled much better by rc and awk on plan9 (I could easily rewrite
> those perl tools in rc+awk, but I'm not guaranteed to have rc on my
> linuxes.)
> 
> Python would probably be the most practical of the 'missing' languagess,
> but
> python was already in base installs for a long time due to hg, wasn't it?
> 
> Obviously what needs to push is rust and node so that p9 can be a real
> next gen server platform :) Think of all the apps we could run with
> electron.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-Me581d8ebe46b7b6161104abd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 3180 bytes --]

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[ori]

Quoth sirjofri via 9fans <9fans@9fans.net>:
> 
> Actually, I was asked about perl support a while ago. I think the biggest issues with those labguages is that nobody would be willing to maintain the upstream support in a useful way.

Perl has *some* support committed upstream.  The maintainers
pinged me a while ago to figure out if it was still working,
so I took a look and fixed a few preprocessor bugs.

Unobe looked at a couple more issues, and reported that it
worked on 386, but on amd64 it crashed deep in the regex engine.
I fixed a couple of small bugs, but eventually gave up.

If there's actual interest in running perl, I think it's not
so much debugging away from working, and the fixes are probably
very upstreamable.

The bigger problem is interest -- I don't have perl code I care
to run, does anyone else here?


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M9417df84bb09ac1eb3810b62
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[sirjofri via 9fans]

09.06.2025 14:39:50 Lucio De Re <lucio.dere@gmail.com>:
> I'm tempted to close off with something like: "The concept of API is a generalisation, each individual API defines its own boundary" even though it is too concise to convey what I would need to develop much further. Feel free to challenge my presentation, I will be happy to adjust my understanding where it needs it.

Independent of the general Plan 9 design (the "which"), I believe the interfaces on Plan 9 systems (the "how") are mostly the filesystems.

Like, the filesystems and their specific structures are the API implementation. The specification of those interfaces is often enough only vaguely described in the man pages, and most specifically in the source code. If I look at other API documentations, I believe there is still room for improvement.

Regarding everything else you wrote, the idea of Plan 9 is quite simple, I think: every resource can be abstracted as a filesystem, and thus be presented in a namespace. The challenge is to actually do the work of designing that abstraction.

sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M7f9b9ad40965bfcb679a435e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[adventures in9]

Plan 9 isn't restricted to a distributed OS, but it is the standout
feature, and since it is an essential feature, it is going to affect
the user interface.

Like, drag-n-drop is a pretty standard feature in most GUIs, but how
do you manage that in Plan9 when there isn't a monolithic file tree
shared between the windows?

If I open a program, like a browser or a drawing program, but forget
to bind in a network or a drawing tablet, will the user program be
able to do binds, or do I have to exit out, run bind, and rerun the
program?

Would there be visual cues to let a user know what the namespace of a
particular window is?

Most of this can be shaken out from using Plan9 in these situations.
But few people are.

The closest I've seen is the demonstration video of Plan B;
https://youtu.be/aOdaERBkBXw


On Mon, Jun 9, 2025 at 5:39 AM Lucio De Re <lucio.dere@gmail.com> wrote:
>
>
> On 2025/06/07 12:07, sirjofri via 9fans wrote:
> > Hi,
> >
> > Vic, your mail raised many arguments which I didn't agree with. Discussion inline.
> >
> > As the original mail was already quite long, this response is even longer. If you still want to read it, prepare yourself with a cup of tea or something.
>
> May I summarise my own grasp of this discussion? The modern GUI ought to
> be what the browser would have become if allowed to incorporate its own
> local terminal OS. Neither Netscape nor Microsoft wanted that to happen
> and so it didn't.
>
> I think Vester is mistaken to believe that Plan 9 as a product is
> restricted to a distributed OS; its essence is, but its instances could
> be as different as KenFS was from a CPU server (or an AUTH server, which
> may be a more interesting example). It's a maintenance problem that gave
> rise to Fossil (one product, not many), and it's the same maintenance
> problem that's preventing Plan 9 to give birth to a better Netscape that
> can operate without, say, storage management.
>
> I am all in favour of generalisations, but I also believe that sharply
> clear boundaries make for simplifications, so a text terminal, a CPU or
> AUTH server, a file server or a web page renderer are all examples where
> Plan 9 could be the philosophy and individual "features" matching the
> philosophy are built upon it.
>
> I'm tempted to close off with something like: "The concept of API is a
> generalisation, each individual API defines its own boundary" even
> though it is too concise to convey what I would need to develop much
> further. Feel free to challenge my presentation, I will be happy to
> adjust my understanding where it needs it.
>
> Lucio.
>
> > 06.06.2025 00:44:39 vester.thacker@fastmail.fm:
> >> Much of the discussion gives the impression that many
> >> here are seeking something quite different from what
> >> Plan 9 was originally designed to provide.
> >>
> >> What is being described sounds less like an extension
> >> and more like the foundation of a new operating system.
> > I think the first question here would be, what even is an operating system? Is it just the basis of hardware abstraction, a philosophical idea, a strict implementation? Does it involve user interfaces of any kind or is it or technical? I don't think we all agree with every detail about this question, but in this context, it is important to think about that.
> >
> >> Perhaps that is indeed the intended direction.
> >> It gives one pause and invites reflection.
> > Pause and reflection is important. I like that our community is small enough and comes without any strings attached: There's no huge pile of software that the world depends on.
> >
> >> On Departing from the Plan 9 Model
> >>
> >> Let us examine the structural assumptions embedded in Plan 9
> >> and considers the implications of applying it to desktop-focused
> >> or single-user environments. While Plan 9 offers compositional
> >> elegance and architectural clarity, its model is not aligned
> >> with the requirements of modern graphical desktop systems.
> > User interface design and human computer interaction are about learning from the human, and applying human capabilities to that interface is the important step. It starts from physical limitations (humans have two eyes and two hands) and goes into depths of how the human thinks.
> >
> > But even then, most interaction with the computer is just learned behavior. Even using the mouse to move a pointer on the screen is something you need to learn.
> >
> > I believe that our current "modern" UI designs are modernizations of the same principles we used for many years. That is, windows, icons, buttons, text, and so on. It doesn't have to be like that, but that's what people are used to. If we make a new UI design, we can only choose between (1) following that same principles, and (2) expecting people to learn our new principles, or any mix between those two.
> >
> > About your statement: what are the requirements of modern graphical desktop environments? And whatever you name: is it really a requirement?
> >
> > I believe anything there it's a solution to a problem. Many of those problems aren't even problems at all, but evolved from an idea of some developer/designer who thought it would be nice. Other problems aren't problems on a plan 9 system. Both those categories don't need a solution.
> >
> > The third category are the valid problems we should focus about. But instead of copying the solutions of other systems, we have the option to think about them thoroughly and try to find an elegant solution that fits existing plan 9 principles and the existing architecture. I bet that in most cases we can find solutions that are as simple and elegant as the other plan 9 components.
> >
> > "But then, the user has to learn them" you might argue. Sure, but is it a bad thing? Plan 9 is a lot about transparency, so a user is expected to learn many things anyway. I'd prefer to give the user a matching and consistent UI solution to learn, than a copy of everything that already exists, but is a foreign thing that doesn't belong here.
> >
> > And people are able to learn. My mother knows next to nothing about computer, she only uses the programs she needs to fulfill her tasks, both at work and at home. She still had to learn some basic on a c64 back when she became a typewriter teacher. Is argue that anyone who touches a computer has to learn a bit about how to use it. There's no such thing as intuitive design, because every intuition is applied learned behavior. You don't go to a foreign country and just start speaking their language, you have to learn it.
> >
> >> This is not a critique of intent or capability, but a reflection
> >> on architectural fit. Understanding the boundaries of Plan 9's
> >> design helps clarify where adaptation is feasible and where
> >> reconstruction becomes necessary.
> > Sure, let's go into it.
> >
> >> Plan 9 is not a desktop-centric system
> > Before going into this topic let me clarify one thing first. I believe that every system that is desktop centric is a failure from the beginning. User interfaces are about the user, not machines. That's why we're talking about UI, not API.
> >
> > A system that focuses about the desktop/UI instead of the user cannot build good solutions for the user.
> >
> >> Plan 9 was not created for single-machine desktop use.
> >> Its architecture focuses on distributed coordination.
> >> Its goal is to unify machines into one namespace.
> > Sure, that's the underlying components. Plan 9 being about transparency, the user will always be able to see that in their namespace.
> >
> > But nobody talked about a single-machine use. And yet, there are limitations a user just naturally has. I don't know about you, but I have two hands with 5 fingers each. I am able to coordinate my finger to an extent that I can type with 10 fingers, essentially, but I'll never be able to use two keyboards simultaneously. I might be able to use two mice at the same time, but three mice?
> >
> > Humans are limited, and while we find elegant solutions to extend our capabilities (also with the help of computers), we will always hit walls at some point.
> >
> > But even then, who said that we can't build a desktop environment that goes about multiple machines, even a full network of machines? I'd argue that we already have that to some extent. Different namespaces and their view are basically a small form of that. I can have multiple rio windows with their own view on the resources of my network. I can build software that uses these resources, and yes, that also involves so-called "desktop environments", whatever that means. They just don't have to follow current expectations.
> >
> >> User sessions span file, compute, and authentication servers.
> >> The 9P protocol manages communication among those parts.
> >> All user interaction flows through remote interfaces.
> > I sometimes wish plan 9 would be more like that, but that's a different topic.
> >
> >> Each user session connects to remote services explicitly.
> >> These include file service, CPU execution, and authentication.
> >> This reflects a distributed and multi-terminal model.
> >>
> >> Plan 9 does not prioritise graphical interface use.
> >> There is no window compositor or event manager.
> >> There are no UI toolkits or persistent notifications.
> > These are all solutions to problems we don't necessarily have. Why would we need a window compositor? For doing fancy graphics with transparency and effects? Is that important for a desktop environment?
> >
> > UI toolkits is a point that I can almost agree with. Libcontrol was never finished, and draw is just drawing. There are a few others, but there's no single solution that works for everything. Though here's the question: do we need that? Plan 9 can easily work with multiple different toolkit solutions, as it does today. It just needs solid ones that are easy to use and to work with. Funnily enough, we are working on this[1].
> >
> >> The Rio window system presents windows but not a desktop.
> >> It offers no system tray or global graphical shell.
> >> There is no UI state storage between sessions.
> > What is a desktop?
> >
> > Coming from the name, it's a metaphor of the surface of a desk. The common meaning of a desktop also evolved over time. Win3x had a desktop with all the hidden windows only, but no system tray. I also wouldn't count it's graphical shell (the program manager) as "global" in the sense of an omni-present start menu. All that evolved over time as a solution to that problem.
> >
> > The components you mention are either not relevant in a plan 9 system as we don't have these problems, or just aren't invented yet. For those that don't exist yet, they could still be written in a way that fits the plan 9 philosophy and architecture. As a simple example, many months ago I wrote a notification system for plan 9, which uses the plumber[2].
> >
> > Regarding rio, I don't think that rio is what makes the plan 9 UI the plan 9 UI, but the other way around: I believe rio is the way it is _because_ of plan 9.
> >
> > This is important, because if we take away rio, it doesn't take away a core component of plan 9. We can replace it with a different window system that fits equally into plan 9. Rio is just a consequence of plan 9.
> >
> >> Plan 9 simplicity is not user interface simplicity
> >>
> >> Plan 9 is simple in composition and design scope.
> >> Its core idea is orthogonality of interfaces.
> >> Every system object is addressed as a file.
> >>
> >> Namespaces are assembled per session by the user.
> >> Services and devices are bound by mounting actions.
> >> This yields flexibility and minimalism in usage.
> >>
> >> Modern desktops hide these actions behind UI layers.
> >> They abstract system state into persistent sessions.
> >> They expose GUI settings and graphical tools.
> > That's what they do, yes, but that's not what makes them modern. If we want to build a modern system for plan 9, that doesn't mean that we should copy that to _become_ modern.
> >
> >> Systems such as GNOME or i3 use visual conventions.
> >> These include gestures, layouts, and notification events.
> >> These conventions do not exist in Plan 9 by default.
> > Some we do have. We have menus with sweeping actions, swallowing window contents for graphical applications.
> >
> > Others are questionable if they make sense.
> >
> > Most people here agree that the system shouldn't be in the way. The first thing I do on a Windows system is, enable the "do not disturb" mode, as I hate those notifications popping up. They are annoying and are in the way.
> >
> > Why should plan 9 follow bad conventions or conventions that didn't make sense?
> >
> > Just because the others do that? Maybe because that's what defined a "modern desktop environment". If that's the definition, is rather not have it.
> >
> > I think we can do better.
> >
> >> To expect such behaviors from Plan 9 creates mismatch.
> >> Its assumptions are not built around UI design goals.
> > Yeah, and that's good.
> >
> >> Its definition of simplicity is structural, not visual.
> > The visual simplicity follows the structural simplicity. You have a complex structure? Then everything that visualizes is needs to be complex, too, as well as the implementation, specifically _because_ of that complexity.
> >
> > You have a simple structure? Then it's much easier to implement a solution that's simple. A plan 9 desktop will this be much simpler than what we know from other OSes.
> >
> >> Plan 9 assumes trust-separated, multi-user operation
> >>
> >> Each user runs in an isolated namespace context.
> >> Resources are mounted into the session explicitly.
> >> No global environment exists for all users.
> > If we see the computer as an extension of the user, there is a global environment: the user.
> >
> > The user is always the global environment of their own "computing/thinking space". On most systems, the computer itself provides another part of that same global environment in the firm of a single view on the abstractions.
> >
> > A plan 9 system is different, as each window provides a different local view and is this not part of that global environment.
> >
> > However, you can argue that the rio background is part of that global environment. And that same environment is often used for the plumber, webfs, factotum, and so on.
> >
> >> Fonts, window systems, and authentication are per-user.
> >> They are often delivered by different machines.
> >> This model supports separation, not convenience.
> > It still is convenient. In fact, it's so convenient that modern systems use that, too. Password managers are often storing the secrets in the cloud, personal files are often mirrored, user accounts exist on some server, and so on. Because it is convenient.
> >
> >> A tablet or wrist device uses one user by nature.
> >> Plan 9 must be reconfigured to avoid multi-user defaults.
> >> Otherwise, graphical support will remain incomplete.
> > Why?
> >
> > My pixel watch is coupled with my phone, so it would naturally get its user settings via that.
> >
> > Android tablets support multiple users for many years already.
> >
> > And even then: why restrict a feature when you can just decide not to use it?
> >
> > Most OSes support multiple users, but most machines are only used by one person.
> >
> > I don't see why this situation would lead to "incomplete graphical support".
> >
> >> No touch input, accessibility, or decoration exists.
> >> These would need to be implemented as external layers.
> > Sure, these are missing components (besides decoration, which is optional). How they're implemented (external components it not) is a completely different topic. Localization is btw also mostly missing.
> >
> >> To add those layers means departing from Plan 9’s model.
> >> The system is not designed to embed them natively.
> > None of the modern systems supported them massively. The unit systems weren't even designed to support any graphics massively. And windows, originally being an extension to DOS, didn't even have preemptive multitasking!
> >
> > I'd argue that plan 9 has more native support for graphics in general than all those systems had back then.
> >
> > I'd also argue that you wouldn't have to depart from the plan 9 model when implementing solutions for the mentioned problems. In fact, I believe you can find more elegant solutions on a plan 9 system.
> >
> >> Desktop conversion leads to architectural misalignment
> >>
> >> The goals described include tabbed windows and input support.
> >> Also included are gestures, integration, and persistence.
> >> These needs align with GTK, Qt, or similar stacks.
> > Why? Because we want to transform plan 9 into a Linux?
> >
> > If I wanted a Linux, I'd still use it.
> >
> > People wanting tabbing support doesn't equal them wanting the exact same thing i3 provides.
> >
> >> Such systems offer abstracted input models and event loops.
> >> They support theming, drag-drop, and high-DPI layouts.
> >> These are not present in Plan 9’s design constraints.
> > /dev/mouse, (/dev/theme), /dev/..., libevent, just to mention a few. And they just work, unlike any word abstractions they have on other systems, that only work under specific circumstances.
> >
> > And the fact that those systems provide all those features doesn't mean that we want them or have to copy them. I never missed drag and drop, for example, but I miss plumbing and mouse chording on other systems.
> >
> >> Plan 9 is not incompatible with graphics frameworks.
> >> However, these do not exist in its environment today.
> >> Adding them requires constructing new interface layers.
> > Or, following the plan 9 architecture, new /dev devices or other filesystems.
> >
> > Like anything on plan 9 does.
> >
> >> These layers must track state and handle input contexts.
> >> They must coordinate redraw events and window geometry.
> >> No such tools are included in the existing distribution.
> > Yeah, because nobody has done the work yet.
> >
> >> Bringing these features into Plan 9 changes its scope.
> >> It introduces code unrelated to its original structure.
> >> The result will diverge from its operating assumptions.
> > No. Plan 9 is designed for this.
> >
> > Otherwise I could argue that every port would diverge from the original plan 9 assumptions, because they introduce new drivers. Even though the filesystem abstraction is the same and this compatible to that in other ports.
> >
> > Sure, we need to introduce new filesystems with new abstractions that didn't exist yet. But plan 9 is designed for this. I could even say, that is exactly what plan 9 is for!
> >
> >> Architecture defines outcome more than tools
> >>
> >> This is not a question of capability or desire.
> >> This is a question of alignment with core abstractions.
> >> An OS is shaped by its target model and constraints.
> >>
> >> Plan 9 targets distributed, coordinated systems.
> >> It does not assume a local screen and local control.
> >> It assumes named users with private namespaces.
> > That's why we don't have devdraw, devmouse, devcons, ....
> >
> > The mentioned components are explicitly designed for a "local screen" and "local control".
> >
> > "Local" in the sense of astral projection, if you get that reference.
> >
> >> A desktop OS assumes a single, local, GUI-heavy use case.
> > I don't agree. Any desktop OS provides capabilities to allow for multiple use cases. Most use cases nowadays are handled in a browser, which means the task is happening on a server (thus not local).
> >
> > GUI-heaviness is not an argument. Most plan 9 users use rio (or some other window manager) and start graphical applications, btw.
> >
> > Funnily enough, most Linux users that I know start a terminal emulator at some point.
> >
> > Putting more functionality into GUIs is also not necessarily good.
> >
> >> It provides persistence, session memory, and input focus.
> >> It assumes consistent visual interaction patterns.
> > All of this exists on a plan 9 system, just in a different way.
> >
> >> These two models begin with different root structures.
> > They do in some core aspects, but UI-wise, they logically aren't so different.
> >
> >> They diverge at the level of system services.
> > Sure, as that's the point of having a different OS.
> >
> >> They do not share the same goals or interface paths.
> > I partly disagree. Of course, plan 9 as a research OS has a different focus, but that doesn't make it incompatible with a user-friendly desktop environment, whatever that is.
> >
> >> To extend Plan 9 into a desktop OS is to rewrite it.
> >> Most layers would need to be added or redesigned.
> >> This is not a continuation but a redirection.
> > I don't agree here.
> >
> > A desktop OS is about UI, and UI is about the user. Since the user needs to learn any interaction with a computer, we shouldn't copy things, but research how to integrate the user with the core system. The result of that research can be used to design a system that represents plan 9 and is simple enough for the user to learn.
> >
> > A few examples in our community show that it is already possible to use plan 9 as a user, as a desktop, to some extent. Following the described path can extend the functionality of the existing UI and make it more usable for a larger user base.
> >
> > That can involve rewriting a few components, but not in a sense of just copying what exists already. That said, it is fine to copy solutions if they also work for plan 9.
> >
> > Note that I said "desktops are about UI", not "desktops are about GUI". I believe that a user doesn't necessarily want to do everything graphically. The user wants to use a good user interface.
> >
> > An example: Everyone I introduced to git, I started with some git gui. And everyone just used the command line at some point. And I wouldn't even count the git CLI as "good".
> >
> >> Other systems already provide GUI-first design.
> >> Some of them include Plan 9-inspired structure.
> >> Haiku and i3 on Linux are notable examples.
> >>
> >> These systems begin with graphical interaction in mind.
> >> They support single-user tasks and desktop workflows.
> >> They reuse or wrap standard interface abstractions.
> > Desktop doesn't mean GUI-first, in my opinion. And also, plan 9 was more graphical from the beginning, and they considered graphics at the core.
> >
> > Standard interface abstractions might be standard, but they are still learned.
> >
> >> Plan 9 does not.
> >> That distinction defines what can be built on each base.
> > So, let's all just throw away plan 9 as it was clearly never designed to be used by an end user?
> >
> > I don't agree.
> >
> > In fact, I believe that we have to go to the base of UI research and understand what it means. It's not about copying standards, it's about building new standards based on research. Standards that work for a user of a plan 9 system.
> >
> > It's a challenge, but that's just what UI design, human interface design, and HCI is.
> >
> > In that aspect, plan 9 should still be a research OS. And that's a good thing, because we don't have to follow the expectations.
> >
> > sirjofri
> >
> > [1]: people like sigrid, adventuresin9, and myself have worked or are actively working on different toolkit solutions.
> >
> > [2]: https://shithub.us/sirjofri/notif/HEAD/info.html

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M392ad342775e5f35b22f0633
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[Lucio De Re]

On 2025/06/07 12:07, sirjofri via 9fans wrote:
> Hi,
>
> Vic, your mail raised many arguments which I didn't agree with. Discussion inline.
>
> As the original mail was already quite long, this response is even longer. If you still want to read it, prepare yourself with a cup of tea or something.

May I summarise my own grasp of this discussion? The modern GUI ought to 
be what the browser would have become if allowed to incorporate its own 
local terminal OS. Neither Netscape nor Microsoft wanted that to happen 
and so it didn't.

I think Vester is mistaken to believe that Plan 9 as a product is 
restricted to a distributed OS; its essence is, but its instances could 
be as different as KenFS was from a CPU server (or an AUTH server, which 
may be a more interesting example). It's a maintenance problem that gave 
rise to Fossil (one product, not many), and it's the same maintenance 
problem that's preventing Plan 9 to give birth to a better Netscape that 
can operate without, say, storage management.

I am all in favour of generalisations, but I also believe that sharply 
clear boundaries make for simplifications, so a text terminal, a CPU or 
AUTH server, a file server or a web page renderer are all examples where 
Plan 9 could be the philosophy and individual "features" matching the 
philosophy are built upon it.

I'm tempted to close off with something like: "The concept of API is a 
generalisation, each individual API defines its own boundary" even 
though it is too concise to convey what I would need to develop much 
further. Feel free to challenge my presentation, I will be happy to 
adjust my understanding where it needs it.

Lucio.

> 06.06.2025 00:44:39 vester.thacker@fastmail.fm:
>> Much of the discussion gives the impression that many
>> here are seeking something quite different from what
>> Plan 9 was originally designed to provide.
>>
>> What is being described sounds less like an extension
>> and more like the foundation of a new operating system.
> I think the first question here would be, what even is an operating system? Is it just the basis of hardware abstraction, a philosophical idea, a strict implementation? Does it involve user interfaces of any kind or is it or technical? I don't think we all agree with every detail about this question, but in this context, it is important to think about that.
>
>> Perhaps that is indeed the intended direction.
>> It gives one pause and invites reflection.
> Pause and reflection is important. I like that our community is small enough and comes without any strings attached: There's no huge pile of software that the world depends on.
>
>> On Departing from the Plan 9 Model
>>
>> Let us examine the structural assumptions embedded in Plan 9
>> and considers the implications of applying it to desktop-focused
>> or single-user environments. While Plan 9 offers compositional
>> elegance and architectural clarity, its model is not aligned
>> with the requirements of modern graphical desktop systems.
> User interface design and human computer interaction are about learning from the human, and applying human capabilities to that interface is the important step. It starts from physical limitations (humans have two eyes and two hands) and goes into depths of how the human thinks.
>
> But even then, most interaction with the computer is just learned behavior. Even using the mouse to move a pointer on the screen is something you need to learn.
>
> I believe that our current "modern" UI designs are modernizations of the same principles we used for many years. That is, windows, icons, buttons, text, and so on. It doesn't have to be like that, but that's what people are used to. If we make a new UI design, we can only choose between (1) following that same principles, and (2) expecting people to learn our new principles, or any mix between those two.
>
> About your statement: what are the requirements of modern graphical desktop environments? And whatever you name: is it really a requirement?
>
> I believe anything there it's a solution to a problem. Many of those problems aren't even problems at all, but evolved from an idea of some developer/designer who thought it would be nice. Other problems aren't problems on a plan 9 system. Both those categories don't need a solution.
>
> The third category are the valid problems we should focus about. But instead of copying the solutions of other systems, we have the option to think about them thoroughly and try to find an elegant solution that fits existing plan 9 principles and the existing architecture. I bet that in most cases we can find solutions that are as simple and elegant as the other plan 9 components.
>
> "But then, the user has to learn them" you might argue. Sure, but is it a bad thing? Plan 9 is a lot about transparency, so a user is expected to learn many things anyway. I'd prefer to give the user a matching and consistent UI solution to learn, than a copy of everything that already exists, but is a foreign thing that doesn't belong here.
>
> And people are able to learn. My mother knows next to nothing about computer, she only uses the programs she needs to fulfill her tasks, both at work and at home. She still had to learn some basic on a c64 back when she became a typewriter teacher. Is argue that anyone who touches a computer has to learn a bit about how to use it. There's no such thing as intuitive design, because every intuition is applied learned behavior. You don't go to a foreign country and just start speaking their language, you have to learn it.
>
>> This is not a critique of intent or capability, but a reflection
>> on architectural fit. Understanding the boundaries of Plan 9's
>> design helps clarify where adaptation is feasible and where
>> reconstruction becomes necessary.
> Sure, let's go into it.
>
>> Plan 9 is not a desktop-centric system
> Before going into this topic let me clarify one thing first. I believe that every system that is desktop centric is a failure from the beginning. User interfaces are about the user, not machines. That's why we're talking about UI, not API.
>
> A system that focuses about the desktop/UI instead of the user cannot build good solutions for the user.
>
>> Plan 9 was not created for single-machine desktop use.
>> Its architecture focuses on distributed coordination.
>> Its goal is to unify machines into one namespace.
> Sure, that's the underlying components. Plan 9 being about transparency, the user will always be able to see that in their namespace.
>
> But nobody talked about a single-machine use. And yet, there are limitations a user just naturally has. I don't know about you, but I have two hands with 5 fingers each. I am able to coordinate my finger to an extent that I can type with 10 fingers, essentially, but I'll never be able to use two keyboards simultaneously. I might be able to use two mice at the same time, but three mice?
>
> Humans are limited, and while we find elegant solutions to extend our capabilities (also with the help of computers), we will always hit walls at some point.
>
> But even then, who said that we can't build a desktop environment that goes about multiple machines, even a full network of machines? I'd argue that we already have that to some extent. Different namespaces and their view are basically a small form of that. I can have multiple rio windows with their own view on the resources of my network. I can build software that uses these resources, and yes, that also involves so-called "desktop environments", whatever that means. They just don't have to follow current expectations.
>
>> User sessions span file, compute, and authentication servers.
>> The 9P protocol manages communication among those parts.
>> All user interaction flows through remote interfaces.
> I sometimes wish plan 9 would be more like that, but that's a different topic.
>
>> Each user session connects to remote services explicitly.
>> These include file service, CPU execution, and authentication.
>> This reflects a distributed and multi-terminal model.
>>
>> Plan 9 does not prioritise graphical interface use.
>> There is no window compositor or event manager.
>> There are no UI toolkits or persistent notifications.
> These are all solutions to problems we don't necessarily have. Why would we need a window compositor? For doing fancy graphics with transparency and effects? Is that important for a desktop environment?
>
> UI toolkits is a point that I can almost agree with. Libcontrol was never finished, and draw is just drawing. There are a few others, but there's no single solution that works for everything. Though here's the question: do we need that? Plan 9 can easily work with multiple different toolkit solutions, as it does today. It just needs solid ones that are easy to use and to work with. Funnily enough, we are working on this[1].
>
>> The Rio window system presents windows but not a desktop.
>> It offers no system tray or global graphical shell.
>> There is no UI state storage between sessions.
> What is a desktop?
>
> Coming from the name, it's a metaphor of the surface of a desk. The common meaning of a desktop also evolved over time. Win3x had a desktop with all the hidden windows only, but no system tray. I also wouldn't count it's graphical shell (the program manager) as "global" in the sense of an omni-present start menu. All that evolved over time as a solution to that problem.
>
> The components you mention are either not relevant in a plan 9 system as we don't have these problems, or just aren't invented yet. For those that don't exist yet, they could still be written in a way that fits the plan 9 philosophy and architecture. As a simple example, many months ago I wrote a notification system for plan 9, which uses the plumber[2].
>
> Regarding rio, I don't think that rio is what makes the plan 9 UI the plan 9 UI, but the other way around: I believe rio is the way it is _because_ of plan 9.
>
> This is important, because if we take away rio, it doesn't take away a core component of plan 9. We can replace it with a different window system that fits equally into plan 9. Rio is just a consequence of plan 9.
>
>> Plan 9 simplicity is not user interface simplicity
>>
>> Plan 9 is simple in composition and design scope.
>> Its core idea is orthogonality of interfaces.
>> Every system object is addressed as a file.
>>
>> Namespaces are assembled per session by the user.
>> Services and devices are bound by mounting actions.
>> This yields flexibility and minimalism in usage.
>>
>> Modern desktops hide these actions behind UI layers.
>> They abstract system state into persistent sessions.
>> They expose GUI settings and graphical tools.
> That's what they do, yes, but that's not what makes them modern. If we want to build a modern system for plan 9, that doesn't mean that we should copy that to _become_ modern.
>
>> Systems such as GNOME or i3 use visual conventions.
>> These include gestures, layouts, and notification events.
>> These conventions do not exist in Plan 9 by default.
> Some we do have. We have menus with sweeping actions, swallowing window contents for graphical applications.
>
> Others are questionable if they make sense.
>
> Most people here agree that the system shouldn't be in the way. The first thing I do on a Windows system is, enable the "do not disturb" mode, as I hate those notifications popping up. They are annoying and are in the way.
>
> Why should plan 9 follow bad conventions or conventions that didn't make sense?
>
> Just because the others do that? Maybe because that's what defined a "modern desktop environment". If that's the definition, is rather not have it.
>
> I think we can do better.
>
>> To expect such behaviors from Plan 9 creates mismatch.
>> Its assumptions are not built around UI design goals.
> Yeah, and that's good.
>
>> Its definition of simplicity is structural, not visual.
> The visual simplicity follows the structural simplicity. You have a complex structure? Then everything that visualizes is needs to be complex, too, as well as the implementation, specifically _because_ of that complexity.
>
> You have a simple structure? Then it's much easier to implement a solution that's simple. A plan 9 desktop will this be much simpler than what we know from other OSes.
>
>> Plan 9 assumes trust-separated, multi-user operation
>>
>> Each user runs in an isolated namespace context.
>> Resources are mounted into the session explicitly.
>> No global environment exists for all users.
> If we see the computer as an extension of the user, there is a global environment: the user.
>
> The user is always the global environment of their own "computing/thinking space". On most systems, the computer itself provides another part of that same global environment in the firm of a single view on the abstractions.
>
> A plan 9 system is different, as each window provides a different local view and is this not part of that global environment.
>
> However, you can argue that the rio background is part of that global environment. And that same environment is often used for the plumber, webfs, factotum, and so on.
>
>> Fonts, window systems, and authentication are per-user.
>> They are often delivered by different machines.
>> This model supports separation, not convenience.
> It still is convenient. In fact, it's so convenient that modern systems use that, too. Password managers are often storing the secrets in the cloud, personal files are often mirrored, user accounts exist on some server, and so on. Because it is convenient.
>
>> A tablet or wrist device uses one user by nature.
>> Plan 9 must be reconfigured to avoid multi-user defaults.
>> Otherwise, graphical support will remain incomplete.
> Why?
>
> My pixel watch is coupled with my phone, so it would naturally get its user settings via that.
>
> Android tablets support multiple users for many years already.
>
> And even then: why restrict a feature when you can just decide not to use it?
>
> Most OSes support multiple users, but most machines are only used by one person.
>
> I don't see why this situation would lead to "incomplete graphical support".
>
>> No touch input, accessibility, or decoration exists.
>> These would need to be implemented as external layers.
> Sure, these are missing components (besides decoration, which is optional). How they're implemented (external components it not) is a completely different topic. Localization is btw also mostly missing.
>
>> To add those layers means departing from Plan 9’s model.
>> The system is not designed to embed them natively.
> None of the modern systems supported them massively. The unit systems weren't even designed to support any graphics massively. And windows, originally being an extension to DOS, didn't even have preemptive multitasking!
>
> I'd argue that plan 9 has more native support for graphics in general than all those systems had back then.
>
> I'd also argue that you wouldn't have to depart from the plan 9 model when implementing solutions for the mentioned problems. In fact, I believe you can find more elegant solutions on a plan 9 system.
>
>> Desktop conversion leads to architectural misalignment
>>
>> The goals described include tabbed windows and input support.
>> Also included are gestures, integration, and persistence.
>> These needs align with GTK, Qt, or similar stacks.
> Why? Because we want to transform plan 9 into a Linux?
>
> If I wanted a Linux, I'd still use it.
>
> People wanting tabbing support doesn't equal them wanting the exact same thing i3 provides.
>
>> Such systems offer abstracted input models and event loops.
>> They support theming, drag-drop, and high-DPI layouts.
>> These are not present in Plan 9’s design constraints.
> /dev/mouse, (/dev/theme), /dev/..., libevent, just to mention a few. And they just work, unlike any word abstractions they have on other systems, that only work under specific circumstances.
>
> And the fact that those systems provide all those features doesn't mean that we want them or have to copy them. I never missed drag and drop, for example, but I miss plumbing and mouse chording on other systems.
>
>> Plan 9 is not incompatible with graphics frameworks.
>> However, these do not exist in its environment today.
>> Adding them requires constructing new interface layers.
> Or, following the plan 9 architecture, new /dev devices or other filesystems.
>
> Like anything on plan 9 does.
>
>> These layers must track state and handle input contexts.
>> They must coordinate redraw events and window geometry.
>> No such tools are included in the existing distribution.
> Yeah, because nobody has done the work yet.
>
>> Bringing these features into Plan 9 changes its scope.
>> It introduces code unrelated to its original structure.
>> The result will diverge from its operating assumptions.
> No. Plan 9 is designed for this.
>
> Otherwise I could argue that every port would diverge from the original plan 9 assumptions, because they introduce new drivers. Even though the filesystem abstraction is the same and this compatible to that in other ports.
>
> Sure, we need to introduce new filesystems with new abstractions that didn't exist yet. But plan 9 is designed for this. I could even say, that is exactly what plan 9 is for!
>
>> Architecture defines outcome more than tools
>>
>> This is not a question of capability or desire.
>> This is a question of alignment with core abstractions.
>> An OS is shaped by its target model and constraints.
>>
>> Plan 9 targets distributed, coordinated systems.
>> It does not assume a local screen and local control.
>> It assumes named users with private namespaces.
> That's why we don't have devdraw, devmouse, devcons, ....
>
> The mentioned components are explicitly designed for a "local screen" and "local control".
>
> "Local" in the sense of astral projection, if you get that reference.
>
>> A desktop OS assumes a single, local, GUI-heavy use case.
> I don't agree. Any desktop OS provides capabilities to allow for multiple use cases. Most use cases nowadays are handled in a browser, which means the task is happening on a server (thus not local).
>
> GUI-heaviness is not an argument. Most plan 9 users use rio (or some other window manager) and start graphical applications, btw.
>
> Funnily enough, most Linux users that I know start a terminal emulator at some point.
>
> Putting more functionality into GUIs is also not necessarily good.
>
>> It provides persistence, session memory, and input focus.
>> It assumes consistent visual interaction patterns.
> All of this exists on a plan 9 system, just in a different way.
>
>> These two models begin with different root structures.
> They do in some core aspects, but UI-wise, they logically aren't so different.
>
>> They diverge at the level of system services.
> Sure, as that's the point of having a different OS.
>
>> They do not share the same goals or interface paths.
> I partly disagree. Of course, plan 9 as a research OS has a different focus, but that doesn't make it incompatible with a user-friendly desktop environment, whatever that is.
>
>> To extend Plan 9 into a desktop OS is to rewrite it.
>> Most layers would need to be added or redesigned.
>> This is not a continuation but a redirection.
> I don't agree here.
>
> A desktop OS is about UI, and UI is about the user. Since the user needs to learn any interaction with a computer, we shouldn't copy things, but research how to integrate the user with the core system. The result of that research can be used to design a system that represents plan 9 and is simple enough for the user to learn.
>
> A few examples in our community show that it is already possible to use plan 9 as a user, as a desktop, to some extent. Following the described path can extend the functionality of the existing UI and make it more usable for a larger user base.
>
> That can involve rewriting a few components, but not in a sense of just copying what exists already. That said, it is fine to copy solutions if they also work for plan 9.
>
> Note that I said "desktops are about UI", not "desktops are about GUI". I believe that a user doesn't necessarily want to do everything graphically. The user wants to use a good user interface.
>
> An example: Everyone I introduced to git, I started with some git gui. And everyone just used the command line at some point. And I wouldn't even count the git CLI as "good".
>
>> Other systems already provide GUI-first design.
>> Some of them include Plan 9-inspired structure.
>> Haiku and i3 on Linux are notable examples.
>>
>> These systems begin with graphical interaction in mind.
>> They support single-user tasks and desktop workflows.
>> They reuse or wrap standard interface abstractions.
> Desktop doesn't mean GUI-first, in my opinion. And also, plan 9 was more graphical from the beginning, and they considered graphics at the core.
>
> Standard interface abstractions might be standard, but they are still learned.
>
>> Plan 9 does not.
>> That distinction defines what can be built on each base.
> So, let's all just throw away plan 9 as it was clearly never designed to be used by an end user?
> 
> I don't agree.
> 
> In fact, I believe that we have to go to the base of UI research and understand what it means. It's not about copying standards, it's about building new standards based on research. Standards that work for a user of a plan 9 system.
> 
> It's a challenge, but that's just what UI design, human interface design, and HCI is.
> 
> In that aspect, plan 9 should still be a research OS. And that's a good thing, because we don't have to follow the expectations.
> 
> sirjofri
> 
> [1]: people like sigrid, adventuresin9, and myself have worked or are actively working on different toolkit solutions.
> 
> [2]: https://shithub.us/sirjofri/notif/HEAD/info.html

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M80379190c8004ca867bc6726
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[sirjofri via 9fans]

Hi,

Vic, your mail raised many arguments which I didn't agree with. Discussion inline.

As the original mail was already quite long, this response is even longer. If you still want to read it, prepare yourself with a cup of tea or something.

06.06.2025 00:44:39 vester.thacker@fastmail.fm:
> Much of the discussion gives the impression that many
> here are seeking something quite different from what
> Plan 9 was originally designed to provide.
>
> What is being described sounds less like an extension
> and more like the foundation of a new operating system.

I think the first question here would be, what even is an operating system? Is it just the basis of hardware abstraction, a philosophical idea, a strict implementation? Does it involve user interfaces of any kind or is it or technical? I don't think we all agree with every detail about this question, but in this context, it is important to think about that.

> Perhaps that is indeed the intended direction.
> It gives one pause and invites reflection.

Pause and reflection is important. I like that our community is small enough and comes without any strings attached: There's no huge pile of software that the world depends on.

> On Departing from the Plan 9 Model
>
> Let us examine the structural assumptions embedded in Plan 9
> and considers the implications of applying it to desktop-focused
> or single-user environments. While Plan 9 offers compositional
> elegance and architectural clarity, its model is not aligned
> with the requirements of modern graphical desktop systems.

User interface design and human computer interaction are about learning from the human, and applying human capabilities to that interface is the important step. It starts from physical limitations (humans have two eyes and two hands) and goes into depths of how the human thinks.

But even then, most interaction with the computer is just learned behavior. Even using the mouse to move a pointer on the screen is something you need to learn.

I believe that our current "modern" UI designs are modernizations of the same principles we used for many years. That is, windows, icons, buttons, text, and so on. It doesn't have to be like that, but that's what people are used to. If we make a new UI design, we can only choose between (1) following that same principles, and (2) expecting people to learn our new principles, or any mix between those two.

About your statement: what are the requirements of modern graphical desktop environments? And whatever you name: is it really a requirement?

I believe anything there it's a solution to a problem. Many of those problems aren't even problems at all, but evolved from an idea of some developer/designer who thought it would be nice. Other problems aren't problems on a plan 9 system. Both those categories don't need a solution.

The third category are the valid problems we should focus about. But instead of copying the solutions of other systems, we have the option to think about them thoroughly and try to find an elegant solution that fits existing plan 9 principles and the existing architecture. I bet that in most cases we can find solutions that are as simple and elegant as the other plan 9 components.

"But then, the user has to learn them" you might argue. Sure, but is it a bad thing? Plan 9 is a lot about transparency, so a user is expected to learn many things anyway. I'd prefer to give the user a matching and consistent UI solution to learn, than a copy of everything that already exists, but is a foreign thing that doesn't belong here.

And people are able to learn. My mother knows next to nothing about computer, she only uses the programs she needs to fulfill her tasks, both at work and at home. She still had to learn some basic on a c64 back when she became a typewriter teacher. Is argue that anyone who touches a computer has to learn a bit about how to use it. There's no such thing as intuitive design, because every intuition is applied learned behavior. You don't go to a foreign country and just start speaking their language, you have to learn it.

> This is not a critique of intent or capability, but a reflection
> on architectural fit. Understanding the boundaries of Plan 9's
> design helps clarify where adaptation is feasible and where
> reconstruction becomes necessary.

Sure, let's go into it.

> Plan 9 is not a desktop-centric system

Before going into this topic let me clarify one thing first. I believe that every system that is desktop centric is a failure from the beginning. User interfaces are about the user, not machines. That's why we're talking about UI, not API.

A system that focuses about the desktop/UI instead of the user cannot build good solutions for the user.

> Plan 9 was not created for single-machine desktop use.
> Its architecture focuses on distributed coordination.
> Its goal is to unify machines into one namespace.

Sure, that's the underlying components. Plan 9 being about transparency, the user will always be able to see that in their namespace.

But nobody talked about a single-machine use. And yet, there are limitations a user just naturally has. I don't know about you, but I have two hands with 5 fingers each. I am able to coordinate my finger to an extent that I can type with 10 fingers, essentially, but I'll never be able to use two keyboards simultaneously. I might be able to use two mice at the same time, but three mice?

Humans are limited, and while we find elegant solutions to extend our capabilities (also with the help of computers), we will always hit walls at some point.

But even then, who said that we can't build a desktop environment that goes about multiple machines, even a full network of machines? I'd argue that we already have that to some extent. Different namespaces and their view are basically a small form of that. I can have multiple rio windows with their own view on the resources of my network. I can build software that uses these resources, and yes, that also involves so-called "desktop environments", whatever that means. They just don't have to follow current expectations.

> User sessions span file, compute, and authentication servers.
> The 9P protocol manages communication among those parts.
> All user interaction flows through remote interfaces.

I sometimes wish plan 9 would be more like that, but that's a different topic.

> Each user session connects to remote services explicitly.
> These include file service, CPU execution, and authentication.
> This reflects a distributed and multi-terminal model.
>
> Plan 9 does not prioritise graphical interface use.
> There is no window compositor or event manager.
> There are no UI toolkits or persistent notifications.

These are all solutions to problems we don't necessarily have. Why would we need a window compositor? For doing fancy graphics with transparency and effects? Is that important for a desktop environment?

UI toolkits is a point that I can almost agree with. Libcontrol was never finished, and draw is just drawing. There are a few others, but there's no single solution that works for everything. Though here's the question: do we need that? Plan 9 can easily work with multiple different toolkit solutions, as it does today. It just needs solid ones that are easy to use and to work with. Funnily enough, we are working on this[1].

> The Rio window system presents windows but not a desktop.
> It offers no system tray or global graphical shell.
> There is no UI state storage between sessions.

What is a desktop?

Coming from the name, it's a metaphor of the surface of a desk. The common meaning of a desktop also evolved over time. Win3x had a desktop with all the hidden windows only, but no system tray. I also wouldn't count it's graphical shell (the program manager) as "global" in the sense of an omni-present start menu. All that evolved over time as a solution to that problem.

The components you mention are either not relevant in a plan 9 system as we don't have these problems, or just aren't invented yet. For those that don't exist yet, they could still be written in a way that fits the plan 9 philosophy and architecture. As a simple example, many months ago I wrote a notification system for plan 9, which uses the plumber[2].

Regarding rio, I don't think that rio is what makes the plan 9 UI the plan 9 UI, but the other way around: I believe rio is the way it is _because_ of plan 9.

This is important, because if we take away rio, it doesn't take away a core component of plan 9. We can replace it with a different window system that fits equally into plan 9. Rio is just a consequence of plan 9.

> Plan 9 simplicity is not user interface simplicity
>
> Plan 9 is simple in composition and design scope.
> Its core idea is orthogonality of interfaces.
> Every system object is addressed as a file.
>
> Namespaces are assembled per session by the user.
> Services and devices are bound by mounting actions.
> This yields flexibility and minimalism in usage.
>
> Modern desktops hide these actions behind UI layers.
> They abstract system state into persistent sessions.
> They expose GUI settings and graphical tools.

That's what they do, yes, but that's not what makes them modern. If we want to build a modern system for plan 9, that doesn't mean that we should copy that to _become_ modern.

> Systems such as GNOME or i3 use visual conventions.
> These include gestures, layouts, and notification events.
> These conventions do not exist in Plan 9 by default.

Some we do have. We have menus with sweeping actions, swallowing window contents for graphical applications.

Others are questionable if they make sense.

Most people here agree that the system shouldn't be in the way. The first thing I do on a Windows system is, enable the "do not disturb" mode, as I hate those notifications popping up. They are annoying and are in the way.

Why should plan 9 follow bad conventions or conventions that didn't make sense?

Just because the others do that? Maybe because that's what defined a "modern desktop environment". If that's the definition, is rather not have it.

I think we can do better.

> To expect such behaviors from Plan 9 creates mismatch.
> Its assumptions are not built around UI design goals.

Yeah, and that's good.

> Its definition of simplicity is structural, not visual.

The visual simplicity follows the structural simplicity. You have a complex structure? Then everything that visualizes is needs to be complex, too, as well as the implementation, specifically _because_ of that complexity.

You have a simple structure? Then it's much easier to implement a solution that's simple. A plan 9 desktop will this be much simpler than what we know from other OSes.

> Plan 9 assumes trust-separated, multi-user operation
>
> Each user runs in an isolated namespace context.
> Resources are mounted into the session explicitly.
> No global environment exists for all users.

If we see the computer as an extension of the user, there is a global environment: the user.

The user is always the global environment of their own "computing/thinking space". On most systems, the computer itself provides another part of that same global environment in the firm of a single view on the abstractions.

A plan 9 system is different, as each window provides a different local view and is this not part of that global environment.

However, you can argue that the rio background is part of that global environment. And that same environment is often used for the plumber, webfs, factotum, and so on.

> Fonts, window systems, and authentication are per-user.
> They are often delivered by different machines.
> This model supports separation, not convenience.

It still is convenient. In fact, it's so convenient that modern systems use that, too. Password managers are often storing the secrets in the cloud, personal files are often mirrored, user accounts exist on some server, and so on. Because it is convenient.

> A tablet or wrist device uses one user by nature.
> Plan 9 must be reconfigured to avoid multi-user defaults.
> Otherwise, graphical support will remain incomplete.

Why?

My pixel watch is coupled with my phone, so it would naturally get its user settings via that.

Android tablets support multiple users for many years already.

And even then: why restrict a feature when you can just decide not to use it?

Most OSes support multiple users, but most machines are only used by one person.

I don't see why this situation would lead to "incomplete graphical support".

> No touch input, accessibility, or decoration exists.
> These would need to be implemented as external layers.

Sure, these are missing components (besides decoration, which is optional). How they're implemented (external components it not) is a completely different topic. Localization is btw also mostly missing.

> To add those layers means departing from Plan 9’s model.
> The system is not designed to embed them natively.

None of the modern systems supported them massively. The unit systems weren't even designed to support any graphics massively. And windows, originally being an extension to DOS, didn't even have preemptive multitasking!

I'd argue that plan 9 has more native support for graphics in general than all those systems had back then.

I'd also argue that you wouldn't have to depart from the plan 9 model when implementing solutions for the mentioned problems. In fact, I believe you can find more elegant solutions on a plan 9 system.

> Desktop conversion leads to architectural misalignment
>
> The goals described include tabbed windows and input support.
> Also included are gestures, integration, and persistence.
> These needs align with GTK, Qt, or similar stacks.

Why? Because we want to transform plan 9 into a Linux?

If I wanted a Linux, I'd still use it.

People wanting tabbing support doesn't equal them wanting the exact same thing i3 provides.

> Such systems offer abstracted input models and event loops.
> They support theming, drag-drop, and high-DPI layouts.
> These are not present in Plan 9’s design constraints.

/dev/mouse, (/dev/theme), /dev/..., libevent, just to mention a few. And they just work, unlike any word abstractions they have on other systems, that only work under specific circumstances.

And the fact that those systems provide all those features doesn't mean that we want them or have to copy them. I never missed drag and drop, for example, but I miss plumbing and mouse chording on other systems.

> Plan 9 is not incompatible with graphics frameworks.
> However, these do not exist in its environment today.
> Adding them requires constructing new interface layers.

Or, following the plan 9 architecture, new /dev devices or other filesystems.

Like anything on plan 9 does.

> These layers must track state and handle input contexts.
> They must coordinate redraw events and window geometry.
> No such tools are included in the existing distribution.

Yeah, because nobody has done the work yet.

> Bringing these features into Plan 9 changes its scope.
> It introduces code unrelated to its original structure.
> The result will diverge from its operating assumptions.

No. Plan 9 is designed for this.

Otherwise I could argue that every port would diverge from the original plan 9 assumptions, because they introduce new drivers. Even though the filesystem abstraction is the same and this compatible to that in other ports.

Sure, we need to introduce new filesystems with new abstractions that didn't exist yet. But plan 9 is designed for this. I could even say, that is exactly what plan 9 is for!

> Architecture defines outcome more than tools
>
> This is not a question of capability or desire.
> This is a question of alignment with core abstractions.
> An OS is shaped by its target model and constraints.
>
> Plan 9 targets distributed, coordinated systems.
> It does not assume a local screen and local control.
> It assumes named users with private namespaces.

That's why we don't have devdraw, devmouse, devcons, ....

The mentioned components are explicitly designed for a "local screen" and "local control".

"Local" in the sense of astral projection, if you get that reference.

> A desktop OS assumes a single, local, GUI-heavy use case.

I don't agree. Any desktop OS provides capabilities to allow for multiple use cases. Most use cases nowadays are handled in a browser, which means the task is happening on a server (thus not local).

GUI-heaviness is not an argument. Most plan 9 users use rio (or some other window manager) and start graphical applications, btw.

Funnily enough, most Linux users that I know start a terminal emulator at some point.

Putting more functionality into GUIs is also not necessarily good.

> It provides persistence, session memory, and input focus.
> It assumes consistent visual interaction patterns.

All of this exists on a plan 9 system, just in a different way.

> These two models begin with different root structures.

They do in some core aspects, but UI-wise, they logically aren't so different.

> They diverge at the level of system services.

Sure, as that's the point of having a different OS.

> They do not share the same goals or interface paths.

I partly disagree. Of course, plan 9 as a research OS has a different focus, but that doesn't make it incompatible with a user-friendly desktop environment, whatever that is.

> To extend Plan 9 into a desktop OS is to rewrite it.
> Most layers would need to be added or redesigned.
> This is not a continuation but a redirection.

I don't agree here.

A desktop OS is about UI, and UI is about the user. Since the user needs to learn any interaction with a computer, we shouldn't copy things, but research how to integrate the user with the core system. The result of that research can be used to design a system that represents plan 9 and is simple enough for the user to learn.

A few examples in our community show that it is already possible to use plan 9 as a user, as a desktop, to some extent. Following the described path can extend the functionality of the existing UI and make it more usable for a larger user base.

That can involve rewriting a few components, but not in a sense of just copying what exists already. That said, it is fine to copy solutions if they also work for plan 9.

Note that I said "desktops are about UI", not "desktops are about GUI". I believe that a user doesn't necessarily want to do everything graphically. The user wants to use a good user interface.

An example: Everyone I introduced to git, I started with some git gui. And everyone just used the command line at some point. And I wouldn't even count the git CLI as "good".

> Other systems already provide GUI-first design.
> Some of them include Plan 9-inspired structure.
> Haiku and i3 on Linux are notable examples.
>
> These systems begin with graphical interaction in mind.
> They support single-user tasks and desktop workflows.
> They reuse or wrap standard interface abstractions.

Desktop doesn't mean GUI-first, in my opinion. And also, plan 9 was more graphical from the beginning, and they considered graphics at the core.

Standard interface abstractions might be standard, but they are still learned.

> Plan 9 does not.
> That distinction defines what can be built on each base.

So, let's all just throw away plan 9 as it was clearly never designed to be used by an end user?

I don't agree.

In fact, I believe that we have to go to the base of UI research and understand what it means. It's not about copying standards, it's about building new standards based on research. Standards that work for a user of a plan 9 system.

It's a challenge, but that's just what UI design, human interface design, and HCI is.

In that aspect, plan 9 should still be a research OS. And that's a good thing, because we don't have to follow the expectations.

sirjofri

[1]: people like sigrid, adventuresin9, and myself have worked or are actively working on different toolkit solutions.

[2]: https://shithub.us/sirjofri/notif/HEAD/info.html

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-Mecad69b25850ee8f1d79295b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[Daniel Maslowski via 9fans]

[-- Attachment #1: Type: text/plain, Size: 7474 bytes --]

Just to be clear here: I do not mean to move toward GTK or similar, nor to
a complex UI in general. All I'm trying to get toward is adapting to modern
input and output devices. While I'm still working on the setup to make that
happen, I am trying to explain my thoughts and what I'm struggling with. It
is a chicken-and-egg issue. 🙂

Thank you for your elaborate explanation. It confirms a lot of my
understanding. Especially the distributed nature of the OS is what peaked
my interest.

At IWP9 2024, I tried to convey my thoughts around the development of
machines that resulted in each of us having more than one machine, and I
still think the Plan 9 model would fit well into this world and would allow
us to connect them all. Moody is right that putting that into practice
would mean tons of work especially in terms of drivers.

As I wrote, I do that sort of hackery a lot, and so I know that running a
very basic system that only works with a serial suffices to get going.
Adding a single additional channel for communication enables driving
anything remotely then, such as USB via its gadget feature, as Gorda also
suggested at IWP9 2025. And I would like to e.g. drive another machine's
screen remotely. It isn't too hard, I have a PoC for that already.

On Fri, 6 Jun 2025, 00:44 , <vester.thacker@fastmail.fm> wrote:

> Much of the discussion gives the impression that many
> here are seeking something quite different from what
> Plan 9 was originally designed to provide.
> 
> What is being described sounds less like an extension
> and more like the foundation of a new operating system.
> 
> Perhaps that is indeed the intended direction.
> It gives one pause and invites reflection.
> 
> On Departing from the Plan 9 Model
> 
> Let us examine the structural assumptions embedded in Plan 9
> and considers the implications of applying it to desktop-focused
> or single-user environments. While Plan 9 offers compositional
> elegance and architectural clarity, its model is not aligned
> with the requirements of modern graphical desktop systems.
> This is not a critique of intent or capability, but a reflection
> on architectural fit. Understanding the boundaries of Plan 9's
> design helps clarify where adaptation is feasible and where
> reconstruction becomes necessary.
> 
> Plan 9 is not a desktop-centric system
> 
> Plan 9 was not created for single-machine desktop use.
> Its architecture focuses on distributed coordination.
> Its goal is to unify machines into one namespace.
> 
> User sessions span file, compute, and authentication servers.
> The 9P protocol manages communication among those parts.
> All user interaction flows through remote interfaces.
> 
> Each user session connects to remote services explicitly.
> These include file service, CPU execution, and authentication.
> This reflects a distributed and multi-terminal model.
> 
> Plan 9 does not prioritise graphical interface use.
> There is no window compositor or event manager.
> There are no UI toolkits or persistent notifications.
> 
> The Rio window system presents windows but not a desktop.
> It offers no system tray or global graphical shell.
> There is no UI state storage between sessions.
> 
> Plan 9 simplicity is not user interface simplicity
> 
> Plan 9 is simple in composition and design scope.
> Its core idea is orthogonality of interfaces.
> Every system object is addressed as a file.
> 
> Namespaces are assembled per session by the user.
> Services and devices are bound by mounting actions.
> This yields flexibility and minimalism in usage.
> 
> Modern desktops hide these actions behind UI layers.
> They abstract system state into persistent sessions.
> They expose GUI settings and graphical tools.
> 
> Systems such as GNOME or i3 use visual conventions.
> These include gestures, layouts, and notification events.
> These conventions do not exist in Plan 9 by default.
> 
> To expect such behaviors from Plan 9 creates mismatch.
> Its assumptions are not built around UI design goals.
> Its definition of simplicity is structural, not visual.
> 
> Plan 9 assumes trust-separated, multi-user operation
> 
> Each user runs in an isolated namespace context.
> Resources are mounted into the session explicitly.
> No global environment exists for all users.
> 
> Fonts, window systems, and authentication are per-user.
> They are often delivered by different machines.
> This model supports separation, not convenience.
> 
> A tablet or wrist device uses one user by nature.
> Plan 9 must be reconfigured to avoid multi-user defaults.
> Otherwise, graphical support will remain incomplete.
> 
> No touch input, accessibility, or decoration exists.
> These would need to be implemented as external layers.
> 
> To add those layers means departing from Plan 9’s model.
> The system is not designed to embed them natively.
> 
> Desktop conversion leads to architectural misalignment
> 
> The goals described include tabbed windows and input support.
> Also included are gestures, integration, and persistence.
> These needs align with GTK, Qt, or similar stacks.
> 
> Such systems offer abstracted input models and event loops.
> They support theming, drag-drop, and high-DPI layouts.
> These are not present in Plan 9’s design constraints.
> 
> Plan 9 is not incompatible with graphics frameworks.
> However, these do not exist in its environment today.
> Adding them requires constructing new interface layers.
> 
> These layers must track state and handle input contexts.
> They must coordinate redraw events and window geometry.
> No such tools are included in the existing distribution.
> 
> Bringing these features into Plan 9 changes its scope.
> It introduces code unrelated to its original structure.
> The result will diverge from its operating assumptions.
> 
> Architecture defines outcome more than tools
> 
> This is not a question of capability or desire.
> This is a question of alignment with core abstractions.
> An OS is shaped by its target model and constraints.
> 
> Plan 9 targets distributed, coordinated systems.
> It does not assume a local screen and local control.
> It assumes named users with private namespaces.
> 
> A desktop OS assumes a single, local, GUI-heavy use case.
> It provides persistence, session memory, and input focus.
> It assumes consistent visual interaction patterns.
> 
> These two models begin with different root structures.
> They diverge at the level of system services.
> They do not share the same goals or interface paths.
> 
> To extend Plan 9 into a desktop OS is to rewrite it.
> Most layers would need to be added or redesigned.
> This is not a continuation but a redirection.
> 
> Other systems already provide GUI-first design.
> Some of them include Plan 9-inspired structure.
> Haiku and i3 on Linux are notable examples.
> 
> These systems begin with graphical interaction in mind.
> They support single-user tasks and desktop workflows.
> They reuse or wrap standard interface abstractions.
> 
> Plan 9 does not.
> That distinction defines what can be built on each base.
> 
> - vic

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M3979a2a878f875364c18871a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 9396 bytes --]

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[adventures in9]

On Thu, Jun 5, 2025 at 3:44 PM <vester.thacker@fastmail.fm> wrote:

> Plan 9 is not a desktop-centric system
>
> Plan 9 was not created for single-machine desktop use.
> Its architecture focuses on distributed coordination.
> Its goal is to unify machines into one namespace.

If there is a "user interface" for Plan 9, it is the namespace.
Anything after that is just decoration.

All rio does is provide a blue-green border and an rc shell to a namespace.
Lets me move it around the screen with other namespaces.

And everything speaking 9P means nothing is tied to being centric to anything.
I routinely have windows open in rio that incorporate stuff from
devices connected to raspberry pis, or wifi routers, or remote file
systems.

I also have a soft spot for the BeOS/Haiku interface.
A small tab on the windows and a button with a clock in the corner is
about all I would really want.
But I certainly don't want something that limits me to a single user
and the resources of a single computer.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M1e31ccbbe0199bf82693f26d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[Adrian]

[-- Attachment #1: Type: text/plain, Size: 6275 bytes --]


Me,  I don't want Plan9 to work like everything else, because what's the point in that, to have the same stuff on a different OS? What does that get you?
Nothing.

Everybody thought 9p was kooky 25 years ago, but now 9p file systems are everywhere.

Adrian










On June 5, 2025 8:42:12 AM EDT, Daniel Maslowski via 9fans <9fans@9fans.net> wrote:
> Hey fans,
> 
> Here's the voice from the abyss.
> 
> Prelude:
> 
> Let me begin with something I have experienced in this community, and I
> would like to shine some light on the effects of the mentality behind. I'll
> be subtle.
> Please read to the end, and I'm sure it will make you happy.
> 
> This first part mainly goes out to people assuming that I or anyone else
> might be just too much "used to Linux": Nope, you're wrong, plain wrong.
> 
> Part 1: Where I am coming from
> 
> Let me explain. I am using machines to assist me with what I do, and if one
> doesn't fit, I will change it. If the system doesn't offer what I need, I
> will pick a different one. I have worked with all the major ones, be it
> Windows, macOS, Linux or FreeBSD, and they all have their ups and downs. I
> want mostly the ups, and I anticipate everyone does.
> 
> What I want is a decent desktop experience with no shenanigans, easy
> software installation, no animations, no annoying OEM tray icons etc.. That
> is what ruled out Windows and macOS for me. So I had FreeBSD and Linux
> left. Except FreeBSD isn't FreeBSD and Linux isn't Linux, so we're
> comparing pineapples and pomegranates here.
> 
> Now there are multiple graphics systems and desktop stacks to choose from,
> the usual X vs Wayland and KDE vs GNOME vs Xfce vs maybe just i3/Sway
> choice. I pick i3/Sway because it fits my needs, and that is where that
> discussion ends. Coincidentally, they have strong roots in Plan 9, and they
> did this one thing: improve a lot.
> 
> We even see ideas making their way back into Plan 9, e.g., with Lola. Tabs?
> That is how I use i3/Sway! All windows in full size and tabbed, so that I
> can set up a workspace ("desktop") with all I need there. I rarely tile,
> and if I do, it will be something like editor + browser or editor + PDF
> viewer so I see what my code changes.
> So that's the way I roll, and everyone has their own way. And that's okay.
> 
> Now you may know that I've got a decade of experience in web development, a
> field that exploded over the years, and I also acknowledge that many of you
> simply hate it. Why though? Does user experience design discomfort you? I
> do understand that a lot of the development is not perfect, and I also see
> how a lot of the web has turned into ad platforms. We can easily agree that
> those aspects need improving. So back to the OS.
> 
> Operating systems have made their journeys as well. Be it macOS, Windows or
> Ubuntu as they are today having iterated over many concepts in terms of
> widgets and interaction design, and BeOS famously having experimented a lot
> in the realm of multimedia. The respin Haiku is close to a stable version
> 1.0. Let me cite from haiku-os.org:
> "Haiku is an open-source operating system that specifically targets
> personal computing. Inspired by the BeOS, Haiku is fast, simple to use,
> easy to learn and yet very powerful."
> 
> And here goes the idea of "simplicity": It isn't simple nor easy to
> *develop* those things, but the primitives are simple. On the other hand,
> it is the developers' burden to deliver simplicity to the end user. Let's
> keep that in mind: Missing out on a decent user experience creates tons of
> complexity on the side of the user. Like, say, having tons of abbreviations
> and little use of colors and such in 2025, in which we have 8k screens,
> terabytes of storage, gigabytes of RAM, touch input, and tons of gadgets in
> everyone's hands - that can change.
> 
> Part2: Where do I want to go with Plan 9?
> 
> The question now is what I am doing here. It's simple (pun intended).
> I read that Plan 9 ought to be simple, and I want to see that work out. So
> I look at it from a bunch of angles and see that it is quite different from
> my expectation of simplicity. Though there is potential to get somewhere. I
> think that would fit the spirit of the Bell Labs folks who started it all.
> 
> A lightweight system that can run on those many gadgets we now have?
> Awesome, let's do that! I see a ton of potential in being able to, say,
> drawterm / cpu into the tablet I hung up in my kitchen. The stock Android
> is long defunct. Or the wristband I am wearing. Tiny SBCs that I can plug
> into my laptop via USB. The small https://racklet.io/ cluster that I am
> helping to build. Whatever wicked still may come!
> 
> So I have been working on hardware platform initialization firmware, this
> project called oreboot (yes, without C), and boot loaders, that is,
> LinuxBoot, and next, I want to bring up Plan 9. I mainly work on RISC-V
> based platforms, now also a bit of Arm, and little x86.
> 
> With the experience in doing this, I paired up with Shawn to hack on
> Moody's WIP port of 9front for RISC-V in QEMU. And I checked with Ron and
> Ori if we can LinuxBoot into Plan 9 / 9front on x86 (might work again with
> Ron's fix; I gotta retry!).
> 
> Over the last few days, I created a tool to convert Plan 9 a.out files to
> ELF (amd64 so far, RISC-V WIP), and I added Plan 9 a.out support for RISC-V
> to radare2. Those tools should help with the endeavor.
> 
> I would be very happy to see some more support. I can read quite a lot of
> code, and I will have questions. Some I can answer myself with more or less
> effort, and some which I can only work through with a lot of patience and
> help.
> 
> Postlude:
> 
> Anyway, sorry for the very lengthy email. I am not much of an email person
> anyway, so please bear with me should you reply and wait for my response.
> Thank you! 🧡
> 
> With all that, have a good day!

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M8740a0295220c8c83d434c90
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 8224 bytes --]

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[Jacob Moody]

Responses in-line.

On 6/5/25 12:10, Daniel Maslowski via 9fans wrote:
> Moody, first of all, I apologize. To be clear, I would not wamt to claim anyone else's work as mine, especially not right in front of them. Quite the opposite; I credit others on a regular basis. All I'm trying here is to help bring things further.
> I do recall that you had mentioned a patch for something on IRC, but I had forgotten about it and not taken a closer look, focusing on the fiddling we did that evening; sorry if it was exactly this for r2. I have no logs, otherwise I'd check.

Thank you for the apology.
For full transparency, this is the irc log snippet that has the conversation regarding this:

250525:2056 CyReVolt ⇒ Is there a way to get something like an objdump so that we can look at the whole kernel?
250525:2058 CyReVolt ⇒ We cannot even stepi or hit a breakpoint anymore with a static ...
250525:2059 moodman ⇒ radare2 has support for plan 9 binaries
250525:2059 moodman ⇒ and can connect to a remote gdb
250525:2059 moodman ⇒ I have a patch for working riscv support
250525:2059 moodman ⇒ if that helps
250525:2100 CyReVolt ⇒ working riscv support in r2?
250525:2101 moodman ⇒ for specifically plan9 binaries
250525:2103 CyReVolt ⇒ ah so r2 riscv support
250525:2103 CyReVolt ⇒ Where's that patch? =)
250525:2105 moodman ⇒ http://okturing.com/src/25279/body
250525:2113 CyReVolt ⇒ okay we managed to print a static char[] using uartputs for once
250525:2114 CyReVolt ⇒ i.e. static char foo[] = "12345"; uartputs(foo, 5); WORKS
250525:2114 CyReVolt ⇒ BUT uartputs("Plan 9", 6); does NOT work
250525:2115 CyReVolt ⇒ sounds like dinner time

(that okturing link is still live, if anyone wants to see what the original patch was)

> The changes I made were my own, in the context of yesterday's exchange with pancake, https://mastodon.social/@CyReVolt/114625651395826989 <https://mastodon.social/@CyReVolt/114625651395826989> - being trivial enough that you probably did very much the same, though I am not sure whether what I did there was correct or complete. I just took a kernel that Shawn had built and it seemed to work fine. If I had had your changes, I would not have done this.

I told you what the patch was and you explicitly asked for it.

You're right that the code is trivial, I do find it plausible that two people just
wound up with very similar looking code, and there are slight modifications.

I don't want to make a mountain out of a mole hill, so I'm comfortable assuming
good faith on your part. I still wanted to provide the log of the conversation
I recall the two of us having because I had made a serious allegation and wanted
to explain why I had reached my initial thoughts on the matter.

Thank you for your explanation, and I hope you can see why my thoughts were what they were.

> And I wouldn't have spent a whole week creating another tool, which is obviously 100x the effort. I didn't even know what ELF really looks like until now.
> While it's not ideal either, it makes it possible to see the symbols in gdb now, at least.
> I started with x86 because I had a kernel from Ron in both a.out and ELF that I took as a fixture, and just added 64-bit RISC-V ELF support today, which should get some cleanups because it got pretty ugly.
> 
> Regarding LinuxBoot, stories like yours on the Talos system are what I see as input for improvement. Yes, I agree, the current state is not great, and a lot of work is necessary to make it smooth.

Work that has to happen outside of our ecosystem. There's not much for us to do to make
the linuxboot situation less bad.




------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-Mb1ec41504f2ab5ebd84b8b2f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] The Big Questioning: Plan 9 everywhere?

[Jacob Moody]

Responses in-line.

On 6/5/25 07:42, Daniel Maslowski via 9fans wrote:
> 
> Operating systems have made their journeys as well. Be it macOS, Windows or Ubuntu as they are today having iterated over many concepts in terms of widgets and interaction design, and BeOS famously having experimented a lot in the realm of multimedia. The respin Haiku is close to a stable version 1.0. Let me cite from haiku-os.org <http://haiku-os.org>:
> "Haiku is an open-source operating system that specifically targets personal computing. Inspired by the BeOS, Haiku is fast, simple to use, easy to learn and yet very powerful."
> 
> And here goes the idea of "simplicity": It isn't simple nor easy to *develop* those things, but the primitives are simple. On the other hand, it is the developers' burden to deliver simplicity to the end user. Let's keep that in mind: Missing out on a decent user experience creates tons of complexity on the side of the user. Like, say, having tons of abbreviations and little use of colors and such in 2025, in which we have 8k screens, terabytes of storage, gigabytes of RAM, touch input, and tons
> of gadgets in everyone's hands - that can change.

I personally like that while Plan 9 presents a very cohesive environment,
it never really papers over technical issues. Plan 9 often chooses simpler
implementations and exposing the reality to the user instead of attempting to
hide the real world complexities of the problem.

Plan 9 is a system that invites you to understand your computer.
In doing so, a lot of code can be straight forward.
Plan 9 is "simple" in the sense that most implementations are simple.

If people want a hand-holding user experience I suggest sticking to a mac.

> 
> Part2: Where do I want to go with Plan 9?
> 
> The question now is what I am doing here. It's simple (pun intended).
> I read that Plan 9 ought to be simple, and I want to see that work out. So I look at it from a bunch of angles and see that it is quite different from my expectation of simplicity. Though there is potential to get somewhere. I think that would fit the spirit of the Bell Labs folks who started it all.
> 
> A lightweight system that can run on those many gadgets we now have? Awesome, let's do that! I see a ton of potential in being able to, say, drawterm / cpu into the tablet I hung up in my kitchen. The stock Android is long defunct. Or the wristband I am wearing. Tiny SBCs that I can plug into my laptop via USB. The small https://racklet.io/ <https://racklet.io/> cluster that I am helping to build. Whatever wicked still may come!

9front is less of a "let's do X or Y" and a "this bothers me so I'll put in the work".
If people want change they send the patches. I dislike this "this work should be done"
talk instead of a "How do I start doing this work? Here I have a sketch of this idea but
I'm having issues".

The biggest issue with supporting whatever tablet or whatever you have hanging in your
kitchen is the lack of documentation and the crazy interfaces that are required to make
it work sensibly. Nice to have? Sure why not. Easy to do? Likely no.

> 
> So I have been working on hardware platform initialization firmware, this project called oreboot (yes, without C), and boot loaders, that is, LinuxBoot, and next, I want to bring up Plan 9. I mainly work on RISC-V based platforms, now also a bit of Arm, and little x86.
> 
> With the experience in doing this, I paired up with Shawn to hack on Moody's WIP port of 9front for RISC-V in QEMU. And I checked with Ron and Ori if we can LinuxBoot into Plan 9 / 9front on x86 (might work again with Ron's fix; I gotta retry!).

What do you mean get "LinuxBoot into plan 9 / 9front",
if you mean getting a linux kernel in as a bootloader that won't happen.

If you mean to add support for booting 9front kernel using linuxboot,
our amd64 kernel already supports multiboot.

I did this dance of getting a 9front kernel booting with kexec (ala linuxboot),
for the power64 talos and the interface sucked. I'd rather not propagate this to other
systems. If I recall correctly I had to make up some bullshit addresses in the ELF
header because the linux kernel had a validity check for a value it never used.
LinuxBoot is designed to do just that, boot linux.

> 
> Over the last few days, I created a tool to convert Plan 9 a.out files to ELF (amd64 so far, RISC-V WIP), and I added Plan 9 a.out support for RISC-V to radare2. Those tools should help with the endeavor.

Converting Plan 9 a.outs to ELFs is going to be bound with issues if you're doing
it after the fact. Plan 9 code is not position independent and we do not provide
the structure required for relocation.

Now for the real reason I sent this email, you didn't add RISC-V plan 9 a.out support to radare2.
You took someone else's patch that I had generously shared with you while you were poking at the RISC-V kernel
and upstreamed it behind our backs claiming it as your own.

Your PR(https://github.com/radareorg/radare2/pull/24261) mentions nowhere that this was someone else's code.

To be entirely honest I find this behavior shocking and troubling, and now I feel responsible for being the
one to send it over to you. I'm sorry but I will not be interested in continuing to share the ongoing work
of the RISC-V port if this is the respect we have for each others work.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M150bbbe09802d0172c82dcdd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription