I think the article is super good and it demostrate with first person quotes.
Actually hyerpbola linux came to the same conclusion and the team will change linux for bsd.
The “Create your own Distribution” model in Linux-land doesn’t quite work the same in BSD-land. Sure there are always people who try and there are some good ones for the average Joe, likeTrueOS formerly PC-BSD, GhostBSD…
But sticking to “Vanilla” *BSD and helping with ports, and bug reports, and patches is much appreciated.
That said, as long as bugfixes are reported upstream, go for it.
At a high level, a lot of this started when the first spectre bugs hit and performance got slashed. We had a hell week at work until we all just accepted that this was the new normal. This pissed me off enough to start looking into the root causes of why it hurt us so bad at the institutional level. Our industry is largely a monoculture around one kind of processor created by 2 companies, one of whom has a bad reputation at cutting corners in the name of speed. A lot of why this happened is because people chain themselves to their processors with binaries. (yes i’m aware of the exceptions, but) AMD64 binaries normally only run on AMD64 processors. Compilers target AMD64 processors. They emit AMD64 bytecode. That bytecode is treated as the word of God and sometimes is kept even long after the author of it has left the company or even died.
This started me down a rabbit hole of researching virtual machine formats and WebAssembly kept coming up. I would be able to run the same code on other processor kinds via WebAssembly. All that was missing was the way for it to interact with the outside world. Thus a lot of my research that’s resulted in wasmcloud.
The main goal of wasmcloud is to solve two problems that I’ve been considering some of the hardest in my career:
making code reliably run on multiple computer architectures
making code reliably handle messages from work queues
When I get to that stage, wasmcloud will have a few arm instances in its production fleet. It will get work via nats and the messages will be durably stored using something like Kafka. I’m still at a bootstrapping phase or I would give you a much more detailed example, but here’s an execution log of one of Olin’s hello world programs running on wasmcloud: https://gateway.ipfs.io/ipfs/QmeW8XpmQzEQouKAQWVtE4JkrrcTiA7rYGncFTPfWJrQz3
One of the first things I plan to port to wasmcloud is a Discord bot of mine.
Plan 9 is already more or less done. 9front just keeps up with the maintenance and provides a place for you to send your driver patch. You shouldn’t expect it to change in fundamental ways.
If someone wants to make it, we’ll make it. I recently implemented git, although it’s not part of the base system right now.
A browser is unlikely: Modern ones are giant. Minimal ones are incomplete. We’ve got 2 crappy ones already, and I’m not aware of anyone willing to sign up to write third, let alone chase the ever-shifting web standards to a degree that will make it more useful than mothra or abaco. My personal opinion is that we’d be better off improving and extending vmx to make running a web browser under an emulated Linux work better.
but what do you expect? something like systemd, office or an ide like visual code?
well plan9’s creators comes from the same team of unix so there inst a “large application” every pieces of software inside plan9 (and now 9front) fits together.
That’s the thing, since I never used Plan 9 or related applications for extended periods, I wasn’t sure what to expect. Of course the examples you list aren’t probable, but Plan 9 users aren’t aliens – they still have the same problems they wish to solve as regular users.
As for this, I am wondering, does the Plan9 folks feel that modern touch interfaces are inferior to mice? That is are such interfaces in the horizon at some point, or are they relegated as not useful at all?
given a choice i prefer mice. while the form factor of the desktop computer is no longer universal, the main reasons 9front lacks complex touch support are: the devs hate touchpads; touchscreen devices are multivariate, complex, and less open than their pc-like counterparts; and, most importantly, nobody has yet contributed any code.
for example, many years ago plan 9 was ported to the ipaq. the base system still ships with an onscreen keyboard designed for use with the ipaq’s stylus.
in 9front there is also support for serial wacom devices. i drew this in paint(1) on a thinkpad x61 tablet:
I think the article is super good and it demostrate with first person quotes. Actually hyerpbola linux came to the same conclusion and the team will change linux for bsd.
yes, but a) I don’t think hyperbola is really in widespread use and b) their total pivot is still kind of vaporware.
The “Create your own Distribution” model in Linux-land doesn’t quite work the same in BSD-land. Sure there are always people who try and there are some good ones for the average Joe, likeTrueOS formerly PC-BSD, GhostBSD…
But sticking to “Vanilla” *BSD and helping with ports, and bug reports, and patches is much appreciated.
That said, as long as bugfixes are reported upstream, go for it.
Sounds interesting. But i can’t see the use case of this yet. Could you give me some example of it? Thanks.
At a high level, a lot of this started when the first spectre bugs hit and performance got slashed. We had a hell week at work until we all just accepted that this was the new normal. This pissed me off enough to start looking into the root causes of why it hurt us so bad at the institutional level. Our industry is largely a monoculture around one kind of processor created by 2 companies, one of whom has a bad reputation at cutting corners in the name of speed. A lot of why this happened is because people chain themselves to their processors with binaries. (yes i’m aware of the exceptions, but) AMD64 binaries normally only run on AMD64 processors. Compilers target AMD64 processors. They emit AMD64 bytecode. That bytecode is treated as the word of God and sometimes is kept even long after the author of it has left the company or even died.
This started me down a rabbit hole of researching virtual machine formats and WebAssembly kept coming up. I would be able to run the same code on other processor kinds via WebAssembly. All that was missing was the way for it to interact with the outside world. Thus a lot of my research that’s resulted in wasmcloud.
The main goal of wasmcloud is to solve two problems that I’ve been considering some of the hardest in my career:
When I get to that stage, wasmcloud will have a few arm instances in its production fleet. It will get work via nats and the messages will be durably stored using something like Kafka. I’m still at a bootstrapping phase or I would give you a much more detailed example, but here’s an execution log of one of Olin’s hello world programs running on wasmcloud: https://gateway.ipfs.io/ipfs/QmeW8XpmQzEQouKAQWVtE4JkrrcTiA7rYGncFTPfWJrQz3
One of the first things I plan to port to wasmcloud is a Discord bot of mine.
I’ve never quite understood, but aren’t 9front releases mostly just bug-fixes? Or when was the last time a larger new feature was added.
There are a whole bunch of larger features. The last release added support for the raspberry pi 4, which involved adding support for the arm64 architecture. Recently enough, there was hardware virtualization (http://man.cat-v.org/9front/1/vmx), a new VPN (http://man.cat-v.org/9front/8/tinc), transparent SSH networking (http://man.cat-v.org/9front/4/sshnet), new TTF renderer (http://man.cat-v.org/9front/2/ttf), a clone of dtrace (http://man.cat-v.org/9front/1/dtracy), and much more.
Plan 9 is already more or less done. 9front just keeps up with the maintenance and provides a place for you to send your driver patch. You shouldn’t expect it to change in fundamental ways.
So one shouldn’t expect them on creating a new browser or some larger application like that?
If someone wants to make it, we’ll make it. I recently implemented git, although it’s not part of the base system right now.
A browser is unlikely: Modern ones are giant. Minimal ones are incomplete. We’ve got 2 crappy ones already, and I’m not aware of anyone willing to sign up to write third, let alone chase the ever-shifting web standards to a degree that will make it more useful than mothra or abaco. My personal opinion is that we’d be better off improving and extending vmx to make running a web browser under an emulated Linux work better.
but what do you expect? something like systemd, office or an ide like visual code? well plan9’s creators comes from the same team of unix so there inst a “large application” every pieces of software inside plan9 (and now 9front) fits together.
That’s the thing, since I never used Plan 9 or related applications for extended periods, I wasn’t sure what to expect. Of course the examples you list aren’t probable, but Plan 9 users aren’t aliens – they still have the same problems they wish to solve as regular users.
this might give you some idea of where things stand, re: applications, and getting work done:
http://fqa.9front.org/fqa8.html
I think you need to give a shot to know what we are talking about
http://fqa.9front.org/fqa1.html#1.3.1
As for this, I am wondering, does the Plan9 folks feel that modern touch interfaces are inferior to mice? That is are such interfaces in the horizon at some point, or are they relegated as not useful at all?
given a choice i prefer mice. while the form factor of the desktop computer is no longer universal, the main reasons 9front lacks complex touch support are: the devs hate touchpads; touchscreen devices are multivariate, complex, and less open than their pc-like counterparts; and, most importantly, nobody has yet contributed any code.
for example, many years ago plan 9 was ported to the ipaq. the base system still ships with an onscreen keyboard designed for use with the ipaq’s stylus.
in 9front there is also support for serial wacom devices. i drew this in paint(1) on a thinkpad x61 tablet:
http://plan9.stanleylieber.com/paint/img/nooo.png