51–60 of 101 posts
A Plan 9 site that actually talks about Inferno as well, there is some hope after all.
> there is some hope after all Inferno was created as a potential Java competitor. That hope is long gone.
This is worse than retrocomputing; it's necrocomputing, a pathetic attempt to mate with the corpse of a dead concept operating system. Instead of drawing any interesting lessons from Plan 9 for OS and distributed system design, it's an attempt to turn a burned-out wreck into a daily driver, generally by redefining driving as "sitting in a car and making brrr noises". They are remarkably honest about it: "There is no…
Thanks to plan9 we have 9p and UTF-8 today. Also, rant whatever you want, but importing /net it's far better than all of the IPTABLES NAT crap you have to write in order to have an usable system build on top of stacked crap again and again. 9front is the future, and not that turd based on half baked networked file systems from Sun named NFS, or worse, Java as the 'standard' of enterprise 'computing'. Don't let me sta…
Why is the socket interface the way it is? Why isn't it like /dev/tcp in bash?
I tried Plan 9 about 10 years ago. Since then I use VPNs everyday and it can be tricky to setup at times.
The Plan 9 concept of just importing /net from the VPN machine as a union overlay is so elegant.
https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs#Combinin...
Earlier quoted context omitted.
+1 on the browser issue. So much of basic development these days requires a browser (I'm even using one to read this Plan 9 Desktop Guide) that not having one hosted by the OS moves the OS from "Desktop development" to "Embedded system development" for all practical purposes for me.
Browsrs? Just get this and read it with page. https://doc.cat-v.org/plan_9/9.intro.pdf
(... and so on and so on. HTTP, as a protocol, has eaten the world. A "desktop" anything without a native browser in it really sticks out.)
Other OS like Windows, Android or MacOS implement such an API. Therefore it is possible. I think that truly open source drivers should be available for everyone, not only to the users of one specific kernel.
Here is what I thought after reading an article: Linux should provide an API for drivers. So that the drivers can be reused by other OS like FreeBSD or Plan9. If you are making a new OS, it is prohibitively expensive to reinvent the USB stack, write your own ACPI interpreter or port millions of lines of code. There should be an API, otherwise these drivers don't differ much from proprietary drivers. Other OS like Win…
Earlier quoted context omitted.
Welcome to Burroughs (nowadays ClearPath MCP), Xerox PARC workstations, UCSD Pascal, Lilith, Oberon, IBM i and z/OS, and a couple more. J2ME, Windows Phone 7, watchOS and Android are arguably the closest to it in mainstream computing.
> J2ME, Windows Phone 7, watchOS and Android are arguably the closest to it in mainstream computing. From my pointy of view none of these come close. The interesting part of Inferno is that it only runs Dis code. It can not exec native code. All the platforms you listed save for j2me (which is not anything like inferno save for being a vm) are OS's which run native code or exec a vm.
The Xerox PARC machines used a microcoded CPU, where the required interpreter was loaded before Smalltalk, Mesa, Mesa/Cedar, Interlisp-D.
Pascal USCD computers used mostly an interpreter, with exception of Convex Computer, which also had AOT compilation.
IBM i and z/OS have language environments, which has allowed several applications to survive multiple hardware generations without ever being recompiled, besides the AOT done at installation time.
Windows Phone 7, only allowed for Silverlight and XNA based games, native code was reserved to Microsoft.
WatchOS uses Apple's special bitcode flavour.
Inferno also executes native code, kernel and Dis implementation.
EDIT: Inferno's source code, https://bitbucket.org/inferno-os
A Plan 9 site that actually talks about Inferno as well, there is some hope after all.
> there is some hope after all Inferno was created as a potential Java competitor. That hope is long gone.
Here is what I thought after reading an article: Linux should provide an API for drivers. So that the drivers can be reused by other OS like FreeBSD or Plan9. If you are making a new OS, it is prohibitively expensive to reinvent the USB stack, write your own ACPI interpreter or port millions of lines of code. There should be an API, otherwise these drivers don't differ much from proprietary drivers. Other OS like Win…
I also wonder why other OSs don't implement a Linux binary interface for drivers, so they can reuse at least some Linux drivers.
Earlier quoted context omitted.
It's probably unfair to compare Plan9 to "modern" operating systems. Why not talk about everything it got right and smart instead of all the things which behave differently than what our expectations set?
I want to answer trying to interpret the GP. For me, I want to be able to tinker with Plan 9. I love everything I have read about it. But I also need a practical environment where this is possible. I would love to be able to do minimal (frugal?) development work on a pi running Plan 9, but the lack of a browser, an editor that feels familiar (at least for a while, until I learn the ropes) and the languages I want to…
Earlier quoted context omitted.
I also wonder why other OSs don't implement a Linux binary interface for drivers, so they can reuse at least some Linux drivers.
I think the answer to both of these is that the Linux driver interface on Linux changes over time!