Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)

196

RRochus about 21 hours ago 48 commentsRead Article on github.com

HI version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

76% Positive

Analyzed from 1249 words in the discussion.

Discussion (48 Comments)Read Original on HackerNews

pjmlp•about 3 hours ago

This is great, especially being System 3, given the nice user experience Oberon eventually morphed into.

In System 3 with the Gadgets system it was already starting to feel like a proper mainstream OS, instead of the plain black and white, without framework like experience from the initial Project Oberon, even thought it was a technological achivement already, with a memory safe systems language.

I prefer the path taken down by Active Oberon, however that doesn't seem to also get that much love nowadays, and is much more complex to explore than System 3.

For those that not know it, it already had something like OLE (inspired by how Xerox PARC did it with Cedar), an AOT/JIT compilation system (with slim binaries for portability), and everything on a memory safe systems language.

spijdar•about 18 hours ago

Oh, this is something I'm going to have to try. Excellent work!

I have to ask, since people who'd know will probably be here, what's the "ten thousand foot view" of Oberon today? I'm aware of the lineage from Pascal/Modula, and that it was a full OS written entirely in Oberon, sort of akin to a Smalltalk or Lisp machine image. What confuses me is the later work on Oberon seems to be something of a cross between a managed runtime like Java or dot net, and the Inferno OS, where it can both run hosted or "natively". Whenever I've skimmed the wikipedia or web pages I've been a bit confused.

Rochus•about 18 hours ago

Thanks. In contrast to Smalltalk or Lisp, Oberon is originally a native language, and the Oberon System originally was conceived as the native operating system of the Ceres computer used for teaching in the nineties at ETH Zurich. So there is no image as in Lisp or Smalltalk. Oberon lives on today in the form of various dialects and derivatives (such as my Oberon+ or Micron languages, see https://github.com/rochus-keller/oberon and https://github.com/rochus-keller/micron). There are indeed Oberon implementations which run on Java or ECMA 335 runtimes, which is possible due to the very restricted pointer handling and memory management of Oberon.

foruhar•about 17 hours ago

Smalltalk too was originally a full OS running on bare metal back in the Xerox Alto days (1972-ish).

Rochus•about 17 hours ago

The "OS" (or rather "kernel") was actually the VM which was implemented in microcode and BCPL. The Smalltalk code within the image was completely abstracted away from the physical machine. In today's terms it was rather the "userland", not a full OS.

EffCompute•about 16 hours ago

It's refreshing to see Oberon getting some love on the Pi. There’s a certain 'engineering elegance' in the Wirthian school of thought that we’ve largely lost in modern systems.

While working on a C++ vector engine optimized for 5M+ documents in very tight RAM (240MB), I often find myself looking back at how Oberon handled resource management. In an era where a 'hello world' app can pull in 100MB of dependencies, the idea of a full OS that is both human-readable and fits into a few megabytes is more relevant than ever.

Rochus, since you’ve worked on the IDE and the kernel: do you think the strictness of Oberon’s type system and its lean philosophy still offers a performance advantage for modern high-density data tasks, or is it primarily an educational 'ideal' at this point?

swiftcoder•about 2 hours ago

I was about 5 links deep before I figured out what Oberon actually was. A high-level explainer at the top of the readme would be really nice for folks who aren't already familiar with the Oberon ecosystem

dharmatech•about 16 hours ago

The Oberon user interface inspired Acme on Plan 9.

Oberon is a very nice, fun and cozy system and environment for programming. I lived in it for a few months back around 2010 and it was a joy.

cmrdporcupine•about 12 hours ago

I often think this style of UI -- tiled text windows but with mouse and graphics interaction (similar to emacs actually) -- is what we should be using for the coding agents we're all using now.

I'd like to be able to dock panels of information, live-edit pieces of code instead of just "accept? Y/N", have side interactions, have real scroll bars and proper clipboards, even a live REPL alongside.

Instead we get Claude Code's janky "60fps TUI" full of bugs and barely interactive.

musicale•about 12 hours ago

Does Oberon still require capitalized keywords? That always seemed to be emphasizing the wrong thing:

    IF disaster THEN abort;

Rochus•about 12 hours ago

Yes, the original Oberon (which the system is based on) has upper-case keywords (and some other orthodoxies). If you are looking for something more modern, go to https://github.com/rochus-keller/oberon, https://github.com/rochus-keller/luon or https://github.com/rochus-keller/micron.

pjmlp•about 3 hours ago

Yes, like Modula-2 as well.

However, people always forget we don't program in Notepad, rather programmer editors that are able to do automatic capitalisation of keywords.

It is a non problem, like discussion of parentheses or white space in programming languages that require them.

eterps•about 20 hours ago

This is great! I remember running System 3 on a 386 back when MS-DOS was king.

Rochus•about 19 hours ago

Thanks. There is actually also an i386 version of the system in the repository, where I modified the kernel so it runs with Multiboot, making installations much easier. An essential achievement for both platforms were the stand-alone tools, i.e. I can compile and link the whole Oberon system on Linux or any other platform (see https://github.com/rochus-keller/op2/). I even implemented an IDE which I used for the development (see https://github.com/rochus-keller/activeoberon/).

anta40•about 4 hours ago

Cool. Is macOS (Apple Silicon) also supported?

If not, well there's another reason to have a Linux VM ready :)

Rochus•44 minutes ago

Technically yes, but since Apple locked down their OS completely, you might have to compile the tools yourself on your machine so the OS allows them to start at all.

butterisgood•about 12 hours ago

Have always been fond of Oberon! I would love to have A2/ActiveOberon/BlueBottle or whatever the name of the day is on a small native machine as well.

Great Stuff!

Rochus•about 12 hours ago

Thanks. The A2 Fox compiler actually has an ARM backend, so I would be surprised if nobody has migrated it to the Raspi yet. The 2003 version of AOS/Bluebottle (not A2) is on my list of interesting sytems, particularly because it supports multicore hardware.

chinabot•about 13 hours ago

I'm going to try and give it a go on a zero2 I have lying around. Thanks, this is exactly what I come to hacker news for.

Rochus•about 12 hours ago

Cool, tell me whether it worked. Unfortunately my mini HDMI adapter is broken and I have to wait for the new to arrive. But I already soldered the headers to the UART pins and observed the system start which looked as it should.

rcarmo•about 14 hours ago

This is lovely. And I bet it is very fast on that hardware, all things considered.

Rochus•about 12 hours ago

The system is up extremenly fast (compared to Linux), but then it takes pretty long to find the USB hub and the keyboard/mouse. Maybe I can still speed this up.

ike____________•about 18 hours ago

Thank you, I've never heard of the Oberon os before.

Rochus•about 17 hours ago

Oberon is both a programming language and an operating system used mostly for teaching, much like e.g. xv6 or xinu. Similar to the latter, Wirth has written text books about the system, some of which can be downloaded for free (see https://projectoberon.net/ for the PDF links).

tomcam•about 18 hours ago

So good to see Oberon this accessible! Mad props!

alterom•about 17 hours ago

I still hope to see the world where Oberon is the future (and present) of OS and programming language design, and I know very little about it.

Thanks to your work, that's about to change.

Thank you times a thousand <3

cyberax•about 16 hours ago

> I still hope to see the world where Oberon is the future (and present) of OS and programming language design

I see you're into horror stories.

Oberon is absolutely a horrible language. It's an example of how you can screw up a good language by insisting on things that were important in 1960-s.

Like not allowing multiple returns (not multiple return _values_ but multiple returns).

jhbadger•about 14 hours ago

There's an argument (and I think a good one) that in structured programming there should be only one return per function. It's not that hard -- you just have a variable and you set it to what you want to return and the last line of the function returns that variable. I think that some things Wirth did with Oberon, particularly in the post Oberon-OS versions like Oberon-07, are a bit restrictive, but they are always in the service of making code easier to read, even if it makes it slightly harder to write.

cyberax•about 12 hours ago

The problem is that pure structured programming just sucks. It doesn't have a good answers for cleanups or error handling.

Structured programming was the answer to the earlier mess with unstructured gotos, but in the process of trying to improve it, structured programming became just as messy when taken dogmatically.

In real life, what matters is the mental load. Every ambient condition that you need to track adds mental load. Early returns/breaks/continues reduce it while in a "structured program" you have to keep track of them until the end of the function.

> It's not that hard -- you just have a variable and you set it to what you want to return and the last line of the function returns that variable.

And also have a flag "skip to return" to skip all the conditions. Or you end up mutating arguments of the function. I know, I suffered through programming on Standard Pascal.

pjmlp•about 3 hours ago

Apparently a school of though widely embraced by Go scholars, nowadays resposible for our cloud infrastructure.

Rochus•about 15 hours ago

Show me significant concepts implemented in today's languages which cannot directly be traced back to "things that were important in 1960-s" or seventies ;-)

cyberax•about 12 hours ago

"Traced back" is fine. We can trace back the size of the Shuttle's boosters to the width of the roads in the Roman Empire.

Insisting that the problems of 1960 are the only thing that matters, and MUST be solved dogmatically is not.