Earlier quoted context omitted.
The manpage ("bugs") suggests that I shouldn't do that. But thank you a lot - I had, indeed, entirely missed that!
Naaah it just works fine
Just ask aux/icanhasvmx :)
Manuals:
31–40 of 102 posts
Earlier quoted context omitted.
The manpage ("bugs") suggests that I shouldn't do that. But thank you a lot - I had, indeed, entirely missed that!
Naaah it just works fine
Just ask aux/icanhasvmx :)
Manuals:
In reality, this was an attempt to turn Plan 9 into a commercial product. Plan 9 despite it's crazy UI (the shell and editor have been ported to Linux so some people must have liked it) brought a lot of new ideas which eventually found their way into other projects such as Linux containers and Go (for obvious reasons). One really good idea that died with Plan 9 was transparent distribution of CPUs across the network.…
Linux lacks a lot of core abstraction properties that would make containers elegant to implement under something like the Plan9 model, at least.
Cool project inspired partially by Linux containers: https://doc.9gridchan.org/guides/spawngrid
There are times when I wish Plan9 and/or Inferno took off and won some respectable market share. Having a laptop, smartphone, tablet, Synology storage at home, servers on DO, and remnant external HDD from prior era becomes frustrating because my files end up being everywhere and nowhere. There were times when I want to be able to start working on some code on my laptop, pause, then continue work on my tablet later on…
> There were times when I want to be able to start working on some code on my laptop, pause, then continue work on my tablet later on In order to do these things 'cleanly' (with a truly unified view of the entire "system"), you need some sort of process migration infrastructure that even Plan9 and Inferno don't really give you, AFAICT. Projects like OpenMosix and OpenSSI attempted to provide this, but I'm not sure to…
Would Plan9 fit in with applications like robotics? I feel like such an operating system would do well with the need to interoperate between a bunch of different types of sensors and hardware, and the need for sensor fusion. I’m not sure if Linux and device drivers are the right foundation for that kind of stuff.
http://doc.cat-v.org/inferno/4th_edition/styx-on-a-brick/
The ev3dev project is partially inspired by everything is a file and I've used it in the past for educational purposes by making the business of controlling/using motors/sensors as trivial as read/write.
In reality, this was an attempt to turn Plan 9 into a commercial product. Plan 9 despite it's crazy UI (the shell and editor have been ported to Linux so some people must have liked it) brought a lot of new ideas which eventually found their way into other projects such as Linux containers and Go (for obvious reasons). One really good idea that died with Plan 9 was transparent distribution of CPUs across the network.…
MOSIX is the only system from that era that I know is still around. It had a fork by the name of OpenMosix for some time, but according to Wikipedia ( https://en.wikipedia.org/wiki/MOSIX#openMosix ): "On July 15, 2007, Bar decided to end the openMosix project effective March 1, 2008, claiming that "the increasing power and availability of low cost multi-core processors is rapidly making single-system image (SSI) clustering less of a factor in computing"
(I admire the downvote, but please realize this is not a question of one's opinion!)
IMHO, having read the spec, I think the VM had a great design for the nineties but was not future-proof enough. It's like it was designed with some specific CPUs of the time in mind, and that biased the design. Also, I find it too tied to the language used in the canonical implementation (obviously C).
In contrast, I find the JVM (contemporary to Dis) more generic and more easy to implement using other languajes than C.
BTW, a few years ago I wrote a (incomplete) Dis VM in C# [0] that I hope to finish^H^H^H^H^H^H rewrite some day...
[0] https://bitbucket.org/luismedel/sixthcircle/src/default/
In reality, this was an attempt to turn Plan 9 into a commercial product. Plan 9 despite it's crazy UI (the shell and editor have been ported to Linux so some people must have liked it) brought a lot of new ideas which eventually found their way into other projects such as Linux containers and Go (for obvious reasons). One really good idea that died with Plan 9 was transparent distribution of CPUs across the network.…
Transparently gluing boxes together over a low bandwidth fabric died as an active research area right around the time Plan9 was seeing its first development. By the late 80s shared bus SMP had demonstrated its practicality and quickly became the predominant architecture. Today we don't spawn processes on remote CPUs because the whole act of scheduling on multiple CPUs is entirely transparent to us, that's a competing…