> Slim binaries were invented by Michael Franz in the early 1990s. They were motivated and opposed to the fat binaries invented by Apple during the transition from 68k to PowerPC architectures. OMI provided portable code based on a compressed version of the abstract syntax tree.
TIMI isn't exactly like Oberon, because with Oberon you could chose, either fully native code, or in this source coded form, that is JITed at load time.
So you can have modules fully native without any kind of intermediate representation, for IBM i you would need the cleverly named Metal C compiler for proper native code.
Actually there are plenty of systems that offer AOT/JIT workloads, Android, Java, .NET, Common Lisp, Visual Basic (classical)....
What was the runtime performance cost of load-time JIT for slim binaries? What fraction of inner-loop bounds checks could be hoisted? What was the cost of dynamic dispatch?
I'm trying to navigate similar tradeoffs for a system I'm prototyping now, but motivated by code footprint and safety rather than portability.
Notice that on Oberon System 3 you could decide what kind of optimizations would take place, section 7 on the PhD refers to it as further work (System 3 came later).
Also a good production ready example of AOT + JIT to dive into as inspiration, are the latest version of Android. Since version 7 they rebooted the whole AOT concept, back to a mix of interpreter written in Assembly, JIT compiler with PGO, generating AOT code when the device is idle with help from PGO data, sharing PGO metadata with similar devices via Play Story.
I had the sense that Dalvik is a much more complex design, far too complex for a single hacker, additionally handicapped by backward compatibility with earlier Dalvik versions.
The only thing that ART has left from Dalvik are the DEX bytecodes, but from complexity level it is yet another JVM implementation (whithout being technically one).
I've been getting into Plan 9 this year; I love the simplicity of the design, such as the fact that nearly all system services are accessible through the file system. I'm running 9legacy on a spare Intel Core i3 mini-PC; my ThinkPad USB keyboard works very well with the rio and acme interfaces, which need a three-button mouse.
Admittedly I'm also using Plan 9 as a platform for my own OS project; I feel I can express my ideas easier using Plan 9's infrastructure compared to using Linux or one of the BSDs as a foundation, though this comes at the cost of extensive driver and software support (for example, there are no Common Lisp implementations for Plan 9 that I'm aware of, and porting an existing implementation such as SBCL will be a lot of work).
I have a spare mini-PC laying around and I was wondering if any of these OSes might be fun to play with.
I'm leaning towards plan9 and 9front. Plan9 seems like an engineering marvel, while still very simple (I've checked the source code before). I don't know much about 9front, but I fear that I might give up the simplicity of Plan9 for some level of convenience.
On a spare pc I would absolutely recommend it. I have it on a raspberry pi and I love it. It's hard to explain, but it takes me back to the days when I was a kid discovering computing for the first time. It's just...fun.
Everything feels so simple and well-designed. Once you sort of wrap you head around the core concepts (namespaces, what 9p really gives you, etc) you suddenly start seeing how crummy posix based systems really are.
You can enable a shocking amount of functionality with little scripts.
At my last job, I worked on a mobile banking app (mostly c++/java) and I developed almost exclusively in acme on my raspberry pi with some little scripts to use my apple laptop for compiling.
Yeah, you'll miss out on some things (mostly web and gaming related) but if you're like me, your real pc will become your spare because you'll look for every excuse you can to do it in plan9 first and only use your expensive rig as a fall back.
Yes! The 9front crew is really good at adding stuff to keep the OS useful. Crypto is up-to-date, ssh plays well, ori_b (who also commented here) wrote a plan9 git client that 9front uses. 9front is the best way to go, in my opinion.
It's also what sdf uses too, for what it's worth.
There's a very friendly discord, but most of the old guard is on irc. It's...less friendly there.
Plan9-derived OS's are at their best when used on multiple systems connected as a network or cluster, not just on a single "spare" box. What the Linux ecosystem calls "containerization" is part of the basic workings of the system, and you can use the "cpu" facility to execute processes remotely (perhaps via a "cloud" service) whilst giving them access to local resources and doing I/O on your local system. It's essentially aiming to create a completely transparent replacement for 'ssh' and its derivatives, including orchestration, containerization etc. frameworks.
This is roughly how I work too; I develop Go, glue in some Linux for doing builds. The biggest weakness is web browsing, and there's a lot that could be done to glue in the hardware virtualization support better into the system, in the style of WSL, so we can run an instance of Chrome/Linux. (I would like to interject for a moment...). The VMX layer needs performance work, SVM support, and window and system integration out of the box.
(This was posted using netsurf on 9front in a coffee shop)
Oberon was quite interesting for its time, but you will get a hard time running it in modern hardware, even with the latest iteraction of it, Blue Bottle/AOS/Active Oberon, you will get a hard time getting ISOs.
The best to look at it, partially working, are browser emulations,
Descends from Plan 9, shows how the UNIX experience could be like when whole userspace is written in a memory safe language with dynamic loading and also you get to learn about Limbo influences Go's design.
Inferno is stuck in 32 bit land but there is a fork that works as 64 bit. I got it going on Mac OS as a 64 bit application (but only for Intel). Need to learn some ARM assembly I suppose.
MIT license really opened things up.
I also run aos/A2 Oberon systems. And I think it’d be awesome to port that to devdraw from plan9port for graphics on Unix systems. I just have not had the time.
That version of Oberon gets updates frequently also, and the Fox compiler system is really neat to play around with.
Async/await style concurrency was there before in .NET I think and Active Objects remind me of what Alan Kay really wanted from OOP (in a similar way that Erlang processes work)
I get the feeling that when Felix Friedrich is no longer active at ETHZ, AOS won't be having much further work.
I mentioned it is hard to get, because keeping up with it requires having some background on AOS history, and even then newer ISO might only work on a VM, depending on which hardware one owns.
In anycase, here are some current links for others,
32 comments
[ 0.18 ms ] story [ 109 ms ] thread> Slim binaries were invented by Michael Franz in the early 1990s. They were motivated and opposed to the fat binaries invented by Apple during the transition from 68k to PowerPC architectures. OMI provided portable code based on a compressed version of the abstract syntax tree.
If you are interested in pursuing that topic, Vidar Hokstad wrote a nice blog post about it a couple of years back: https://hokstad.com/semantic-dictionary-encoding
So you can have modules fully native without any kind of intermediate representation, for IBM i you would need the cleverly named Metal C compiler for proper native code.
Actually there are plenty of systems that offer AOT/JIT workloads, Android, Java, .NET, Common Lisp, Visual Basic (classical)....
WebAssembly is also adopting both approaches.
I'm trying to navigate similar tradeoffs for a system I'm prototyping now, but motivated by code footprint and safety rather than portability.
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.87...
Notice that on Oberon System 3 you could decide what kind of optimizations would take place, section 7 on the PhD refers to it as further work (System 3 came later).
Also a good production ready example of AOT + JIT to dive into as inspiration, are the latest version of Android. Since version 7 they rebooted the whole AOT concept, back to a mix of interpreter written in Assembly, JIT compiler with PGO, generating AOT code when the device is idle with help from PGO data, sharing PGO metadata with similar devices via Play Story.
https://source.android.com/docs/core/dalvik/jit-compiler
I had the sense that Dalvik is a much more complex design, far too complex for a single hacker, additionally handicapped by backward compatibility with earlier Dalvik versions.
https://wiki.tcl-lang.org/page/Slim+Binaries
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
Some of them actually were, however without the full package, they are a shadow of themselves.
There was no need for vi to be a virtualisation tool instead of a text editor.
Admittedly I'm also using Plan 9 as a platform for my own OS project; I feel I can express my ideas easier using Plan 9's infrastructure compared to using Linux or one of the BSDs as a foundation, though this comes at the cost of extensive driver and software support (for example, there are no Common Lisp implementations for Plan 9 that I'm aware of, and porting an existing implementation such as SBCL will be a lot of work).
[1] https://github.com/9fans/plan9port
Can anyone chime in on this topic?
Everything feels so simple and well-designed. Once you sort of wrap you head around the core concepts (namespaces, what 9p really gives you, etc) you suddenly start seeing how crummy posix based systems really are.
You can enable a shocking amount of functionality with little scripts.
At my last job, I worked on a mobile banking app (mostly c++/java) and I developed almost exclusively in acme on my raspberry pi with some little scripts to use my apple laptop for compiling.
Yeah, you'll miss out on some things (mostly web and gaming related) but if you're like me, your real pc will become your spare because you'll look for every excuse you can to do it in plan9 first and only use your expensive rig as a fall back.
It's also what sdf uses too, for what it's worth.
There's a very friendly discord, but most of the old guard is on irc. It's...less friendly there.
http://fqa.9front.org/fqa1.html#1.1
(This was posted using netsurf on 9front in a coffee shop)
The best to look at it, partially working, are browser emulations,
https://schierlm.github.io/OberonEmulator/
Between Plan 9 and Inferno, I suggest Inferno.
Descends from Plan 9, shows how the UNIX experience could be like when whole userspace is written in a memory safe language with dynamic loading and also you get to learn about Limbo influences Go's design.
MIT license really opened things up.
I also run aos/A2 Oberon systems. And I think it’d be awesome to port that to devdraw from plan9port for graphics on Unix systems. I just have not had the time.
That version of Oberon gets updates frequently also, and the Fox compiler system is really neat to play around with.
Async/await style concurrency was there before in .NET I think and Active Objects remind me of what Alan Kay really wanted from OOP (in a similar way that Erlang processes work)
Anyway it’s a language/OS nerd’s dream.
I mentioned it is hard to get, because keeping up with it requires having some background on AOS history, and even then newer ISO might only work on a VM, depending on which hardware one owns.
In anycase, here are some current links for others,
http://cas.inf.ethz.ch/projects/a2/activity
https://github.com/btreut/a2