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

[Jacob Moody <moody@posixcafe.org>]

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