[HN Gopher] Oberon, Plan 9 and Inferno (2021)
       ___________________________________________________________________
        
       Oberon, Plan 9 and Inferno (2021)
        
       Author : eterps
       Score  : 119 points
       Date   : 2022-09-04 08:57 UTC (14 hours ago)
        
 (HTM) web link (blog.tsr-podcast.com)
 (TXT) w3m dump (blog.tsr-podcast.com)
        
       | eterps wrote:
       | The article mentions:
       | 
       |  _> 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
        
         | Torwald wrote:
         | There was also Oberon for the Amiga.
        
         | eterps wrote:
         | Some additional info+links can be found here:
         | 
         | https://wiki.tcl-lang.org/page/Slim+Binaries
        
         | pjmlp wrote:
         | By Oberon System 3 timeframe we had both distribution formats,
         | either fully AOT compiled, or slim binaries.
        
           | rbanffy wrote:
           | IIRC, it's similar to how AS/400 binaries were distributed.
           | Not sure they were compiled to native code on install or on
           | first run.
        
             | pjmlp wrote:
             | 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)....
             | 
             | WebAssembly is also adopting both approaches.
        
           | kragen wrote:
           | 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.
        
             | eterps wrote:
             | If I remember correctly this article describes some
             | considerations and metrics: https://citeseerx.ist.psu.edu/v
             | iewdoc/download?doi=10.1.1.10... (it has been a while since
             | I read it though)
        
             | pjmlp wrote:
             | Not really sure, you can read the PhD thesis about it,
             | 
             | https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.8
             | 7...
             | 
             | 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
        
       | eterps wrote:
       | I am surprised that Oberon is relatively popular on HN:
       | 
       | https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
        
         | pjmlp wrote:
         | Because all of them represent what-ifs of how the computing
         | industry could look today if their ideas would have been
         | adopted in mainstream computing.
         | 
         | Some of them actually were, however without the full package,
         | they are a shadow of themselves.
        
           | rbanffy wrote:
           | Indeed. They suffered, however, from being perhaps too
           | revolutionary.
           | 
           | There was no need for vi to be a virtualisation tool instead
           | of a text editor.
        
       | pbohun wrote:
       | I've done a little bit of C programming with the c libraries
       | supplied by plan9port. It takes a bit of learning, but it's a
       | very pleasant experience.
       | 
       | [1] https://github.com/9fans/plan9port
        
       | linguae wrote:
       | 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).
        
         | butterisgood wrote:
         | Not the same I know but there's a few scheme implementations
         | that work. One of them is fennel if you use the plan 9 lua port
         | available for 9front.
        
       | haolez wrote:
       | 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.
       | 
       | Can anyone chime in on this topic?
        
         | smazga wrote:
         | 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.
        
           | haolez wrote:
           | Awesome! Do you use 9front?
        
             | smazga wrote:
             | 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.
        
           | ori_b wrote:
           | 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)
        
           | zozbot234 wrote:
           | 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.
        
         | yjftsjthsd-h wrote:
         | 9front is fine, it's just actively maintained
        
         | pjmlp wrote:
         | 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,
         | 
         | 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.
        
       ___________________________________________________________________
       (page generated 2022-09-04 23:01 UTC)