OberonEmulator VS plan9port

Compare OberonEmulator vs plan9port and see what are their differences.


Project Oberon emulator in JavaScript and Java (by schierlm)


Plan 9 from User Space (by 9fans)
Our great sponsors
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
OberonEmulator plan9port
1 27
119 1,555
- 0.7%
6.2 6.7
8 days ago about 2 months ago
Java C
ISC License GNU General Public License v3.0 or later
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.


Posts with mentions or reviews of OberonEmulator. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2023-04-28.
  • Plan 9 from User Space
    5 projects | news.ycombinator.com | 28 Apr 2023
    You would love Oberon, and its derived OSes, Acme UI is based on it.

    In Oberon, you can select any piece of text and apply a command on it.

    Commands are public procedures in dynamic modules, so Module.Command will load it if not already loaded, and then execute command.

    There are a couple of ways to write commands, depending if the act on selected widgets, selected text, selected windows, or if they ask for additional input.


    For trying out it emulated on the browser,


    And how the latest iteration of it, Bluebottle (AOS) with Active Oberon, looks like


    One of the great things about PowerShell and Windows, is that despite all the warts it has, it allows exactly a similar kind of workflow, with .NET, DLLs and COM replacing that Module.Command experience.

    GNOME and KDE can offer similar workflows, alongside DBUS, and fish shell, however people seem more keen in keeping the UNIX experience of yore instead of going down that route.


Posts with mentions or reviews of plan9port. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2023-12-25.
  • Show HN: Towards Oberon+ concurrency; request for comments
    6 projects | news.ycombinator.com | 25 Dec 2023
    [2] https://9fans.github.io/plan9port/
    6 projects | news.ycombinator.com | 25 Dec 2023
  • A pure C89 implementation of Go channels, including blocking and non-blocking selects
    4 projects | /r/golang | 11 Dec 2023
    If you find it too complicated and closely tied to Go internals, you can also check out Plan 9 from User Space's version, which is itself based on libthread from Plan 9 starting from 3rd edition, which is itself based on Alef's implementation of channels (Alef is Go's grandfather).
  • A tutorial for the Sam command language (1986) [pdf]
    5 projects | news.ycombinator.com | 20 Oct 2023
  • Makefile Tutorial
    5 projects | news.ycombinator.com | 22 Sep 2023
  • Mk: A Successor to Make [pdf]
    5 projects | news.ycombinator.com | 16 Jul 2023
    For those curious, Mk is available in Plan 9 from User Space


    5 projects | news.ycombinator.com | 16 Jul 2023
    I tried plan9port's mk for a moment out of curiosity. I quickly ran into an annoying usability problem: it compares file mtimes with second accuracy.


    With sub-second build times for individual targets, this causes mk to needlessly recompile files because the target may have the same mtime as the prerequisites.

  • Plan 9 from User Space
    5 projects | news.ycombinator.com | 28 Apr 2023
  • Telegraph and the Unix Shell
    8 projects | /r/commandline | 31 Dec 2022
    Folks here might be interested in the Plan 9 user interface and how its terminal and shell interacted. The rio terminal window is lacking control codes, but then allows the user to select back history and edit it for resubmission to the shell. A port of it is available under X via the Plan 9 from User Space port project (https://9fans.github.io/plan9port/).
  • Golang is evil on shitty networks
    21 projects | news.ycombinator.com | 29 Dec 2022
    That code was in turn a loose port of the dial function from Plan 9 from User Space, where I added TCP_NODELAY to new connections by default in 2004 [1], with the unhelpful commit message "various tweaks". If I had known this code would eventually be of interest to so many people maybe I would have written a better commit message!

    I do remember why, though. At the time, I was working on a variety of RPC-based systems that ran over TCP, and I couldn't understand why they were so incredibly slow. The answer turned out to be TCP_NODELAY not being set. As John Nagle points out [2], the issue is really a bad interaction between delayed acks and Nagle's algorithm, but the only option on the FreeBSD system I was using was TCP_NODELAY, so that was the answer. In another system I built around that time I ran an RPC protocol over ssh, and I had to patch ssh to set TCP_NODELAY, because at the time ssh only set it for sessions with ptys [3]. It was a terrible default for trying to do anything that cared about latency.

    When I wrote the Go implementation of net.Dial, which I expected to be used for RPC-based systems, it seemed like a no-brainer to set TCP_NODELAY by default. I have a vague memory of discussing it with Dave Presotto (our local networking expert, my officemate at the time, and the listed reviewer of that commit) which is why we ended up with SetNoDelay as an override from the very beginning. If it had been up to me, I probably would have left SetNoDelay out entirely.

    As others have pointed out at length elsewhere in these comments, it's a completely reasonable default.

    I will just add that it makes no sense at all that git-lfs (lf = large file!) should be sending large files 50 bytes at a time. That's a huge number of system calls that could be avoided by doing larger writes. And then the larger writes would work better for the TCP stack anyway.

    And to answer the question in the article:

    > Much (all?) of Kubernetes is written Go, and how has this default affected that?

    I'm quite confident that this default has greatly improved the default server latency in all the various kinds of servers Kubernetes has. It was the right choice for Go, and it still is.

    [1] https://github.com/9fans/plan9port/commit/d51419bf4397cf13d0...

    [2] https://news.ycombinator.com/item?id=34180239

    [3] http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TM-65...

What are some alternatives?

When comparing OberonEmulator and plan9port you can also consider the following projects:

sam - An updated version of the sam text editor.

plan9-1e - Mirror of Plan 9 1st Edition from p9f

Fontpkg-PxPlus_IBM_VGA8 - A monospace system font in the styles of regular, italic and underline.

Shrine - A TempleOS distro for heretics

mk - make remade

fsv - fsv is a file system visualizer in cyberspace. It lays out files and directories in three dimensions, geometrically representing the file system hierarchy to allow visual overview and analysis.

nushell - A new type of shell

xplr - A hackable, minimal, fast TUI file explorer

qtcurve - Style engine for Qt and other toolkits

hn-search - Hacker News Search


go - The Go programming language