Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)
github.com
github.com
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.
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?
I get the motivation for wanting to use LLVM, but personally I don't like it (and have the luxury of ignoring it since I only do compilers as a hobby...) and prefer to aim for self-hosting whenever I work on a language. But LLVM is of course a perfectly fine choice if your goal doesn't include self-hosting - you get a lot for free.
Is it? Isn't it rather the case that C is too low level to express intent and (hence) offer room to optimize? I would expect that a language in which, e.g. matrix multiplication can be natively expressed, could be compiled to more efficient code for such.
I would rather expect, that for compilers which don't optimize well, C is the easiest to produce fairly efficient code for (well, perhaps BCPL would be even easier, but nobody wants to use that these days).
That's exactly the question we would hope to answer with such an experiment. Given that your language received sufficient investments to implement an optimal LLVM adaptation (as C did), we would then expect your language to be significantly faster on a benchmark heavily depending on matrix multiplication. If not, this would mean that the optimizer can get away with any language and the specific language design features have little impact on performance (and we can use them without performance worries).
I agree with guenthert that higher-level intent should theoretically allow for better optimization, but as you said, without the decades of investment that went into the C backends, it's a David vs. Goliath situation.
The 'spiraling complexity' of LLVM you mentioned is exactly why some of us are looking back at leaner designs. For high-density data tasks (like the 5.2M documents in 240MB I'm handling), I'd almost prefer a language that gives me more predictable, transparent control over the machine than one that relies on a million-line optimizer to 'guess' what I'm trying to do. It feels like we are at a crossroads between 'massive compilers' and 'predictable languages' again.
> Our results have shown that–because of the profiling feedback loop–object code produced by continuous optimizations is often of a higher quality than can be achieved using static "off-line" compilation. Optimization at runtime, if performed judiciously, can often surpass optimizations performed at compile-time, independent of whether the latter are guided by profiling information or not. Our results have also given evidence that reoptimizing an already running program in response to changes in user behavior can give rise to real performance improvements.
Kistler, Thomas, and Michael Franz. "Continuous program optimization: Design and evaluation." IEEE Transactions on Computers 50, no. 6 (2002). <https://doi.org/10.1109/12.931893>
Your approach with Micron and the 'language levels' is particularly interesting. One of the biggest hurdles I face in C++ with these high-density vector tasks is exactly that: balancing the raw 'unsafe' pointer arithmetic needed for SIMD and custom memory layouts with the safety needed for the rest of the application.
Having those features controlled at the module level (like your Micron levels) sounds like a much cleaner architectural 'contract' than the scattered unsafe blocks or reinterpret_cast mess we often deal with in systems programming. I'll definitely keep an eye on the Micron repository—bridging that gap between Wirth-style safety and C-level performance is something the industry is still clearly struggling with (even with Rust's rise).
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.
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.
Of course it's normal for there to be a disconnect between your assumptions about your target audience and reality. In a real conversation this happens all the time and it's no big deal. When something's written and especially when it's printed it can be a bit more of a problem, so maybe better to err on the side of over-explaining. Also a good reason to have editors and proofreaders. But I'm rambling a bit.
In this case, the link was posted to HN by the author, so the author might have had "average HN reader" in mind. Oberon never really achieved success outside of a particular niche in academia, so unless they went to ETH Zurich I personally wouldn't expect someone - even someone in tech - to know about it.
What I mean is that having so much info at the toe of our tips, comments like "you should put a link about what this thing is" are needless.
I'm plenty familiar with the whole Modula 3 -> NextSTEP branch of this little tree, but the Oberon branch isn't something I've run into before.
Yes, I think that's a mistake. Lisp and Forth saw widespread commercial use, were hugely influential, and directly begat many other languages. While I'd expect most folks on here to be familiar with Pascal - you could say those same things about it - and maybe even know who Wirth is, Oberon basically saw no commercial use whatsoever and even in academia was basically only used at the school it came from. There's no real comparison.
see timeline on https://ethereum.org/ethereum-forks/
ETH Zurich is one of the most well-regarded technical schools in the world, and arguably the most well-regarded technical school in Europe. It has many famous alumni, including Albert Einstein. I think it's fair to expect most people in tech to be familiar with the big schools in the field, even the ones in Europe, though maybe that's giving too much credit to Americans.
But maybe it's also worth pointing out some other principles of communication: ETH Zurich wasn't really the main topic of my comment, and it's OK if readers don't catch every reference; communication is invariably lossy, and as long as general meaning is conveyed that's OK! Also, given the context (the sentence "Oberon never really achieved success outside of a particular niche in academia, so unless they went to ETH Zurich...") even if the reader hadn't heard of ETH Zurich it could be reasonably inferred that ETH Zurich is an academic institution, probably in Zurich, where Oberon was successful. Part of writing is trusting that the reader is a rational person who understands how (the) language and the world work, otherwise communication becomes impossible.
Some associated ideas in the philosophy of language might be the "cooperative principle", the "principle of humanity", and the "principle of charity". I'll frankly make a muddle of trying to explain them in detail, and this reply is already too long and too snarky, so in this case I'd ask the interested reader to consult Wikipedia, the Stanford Encyclopedia of Philosophy, etc.
One of the basic principles of communication is that you have a mental model of the person you're communicating with and are phrasing what you want them to understand in terms that you think they'll understand. So whenever you're writing something - anything - you should be writing with a target audience in mind, and stop explaining right around the point where you believe that your target audience doesn't need further explanation. Not everybody lives in Europe or has knowledge of what the top technical schools are (which is a bit classist to assume tbh), and this type of Euro-centric thinking doesn’t work very well when communicating with people from other backgrounds.
The first sentence of the README says, "This project modernizes the Kernel of Oberon System 3 (version 2.3.7) by migrating it from the original Oberon Boot Loader (OBL, written in assembler) to the Multiboot specification (handled in Oberon directly in the Kernel)."
Armed with that and the headline "Oberon System 3 runs natively on Raspberry Pi 3", it can be reasonably inferred that "Oberon System 3" is an operating system (shown here of being capable of running on a Raspberry Pi). It doesn't require prior familiarity with Oberon, despite what the previous commenter said.
Neither you nor the original questioner are being particularly rational about this.
"Oberon is an operating system" was indeed evident, but it's also not particularly illuminating. There are dozens of niche operating systems, why do we care about this one in particular? What does it do that other operating systems don't?
No, it is not evident: this is not correct.
Oberon is bare-metal self-hosted programming system. It is both a language and an OS.
> why do we care about this one in particular?
1. It is the final development in the career of Niklaus Wirth, the creator of Pascal. Pascal is the Wirthian language that had considerable commercial success.
(A dialect called the USCD p-System was one of the original 3 OSes that IBM offered for the PC, for instance. Apple created Object Pascal, and implemented parts of the Lisa and original Mac OSes in it. In the early days of DOS, Borland TurboPascal was one of the leading IDEs, and then when 16-bit Windows achieved commercial success, Borland's Delphi led the way as the most sophisticated Windows IDE.)
2. It's the end of his life's work. Wirth did not stop with Pascal.
The next generation was Modula. It was a bit of a flop, but the successor, Modula-2, was a hugely influential language too. Topspeed Modula-2 was at one time the fastest compiler of all kinds for the PC.
Development did not end there.
Others did Modula-3, not Wirth. He moved on to create Oberon.
3. This is the end of the line of the single most widespread and influential family of programming languages outside of the C world.
> What does it do that other operating systems don't?
Wirth was a keen advocate of small size and simplicity.
https://cr.yp.to/bib/1995/wirth.pdf
Oberon is one of the smallest simplest compiled languages of all time. It is also an OS, and an ID, and a tiled mouse-controlled windowing system. The core is about 4000 lines of code.
4k LOC.
The entire core OS is smaller than the tiniest trivial shell tool on any FOSS Unix.
It is almost unbelievably tiny, it is fast, and it is self-hosting. It can run bare-metal, on multiple platforms, or as a conventional language under another OS. It has its own GUI. It can interop with other languages. You can, and people do, build complete GUI apps in Oberon.
https://blackboxframework.org/
It may be less well-known than its own ancestors but this is an important, significant language, and the final generation of a very important and very much alive dynasty.
It is evident. It is correct.
You aren't making this any better.
Comparison: you are angrily maintaining "Orange is a colour! It is right there in the rainbow! Red, orange, yellow, green, blue, indigo, violet! It's a colour! That is the set to which it belongs!"
It is true. But it is incomplete.
It is also a fruit. It belongs equally in "apple, orange, banana, pear, quince."
Also a valid set; no parallel.
It is in other sets too. The set of citrus fruits. "Lemon, orange, lime, pomelo, grapefruit."
Oberon is a programming language.
It is also a set of frameworks. They are integral.
It is also an editor.
It is also a UI design.
It is also an OS.
Any one is true but is incomplete.
There are other views but yours and none is privileged; yours does not invalidate the others, nor they yours. You only see one but your view is too narrow.
Oberon is an operating system, and "Oberon is an operating system" is a fair and accurate statement.
I don't expect you to relent on this—I'm too well acquainted. You're still wrong.
And it is also a programming language, which can run on other OSes as well as on its own native one.
Here's a Windows version:
https://blackboxframework.org/
Here's a Linux version too:
https://blackbox.oberon.org/download
Renamed, but "Component Pascal" is Oberon.
Wirth's Oberon is a compiler, but Oberon can also be compiled with other compilers.
Vishaps interpiles Oberon via C using GCC, Clang etc.
So does OBNC:
Astrobe is another alternative compiler:
OberonC compiles it to the JVM:
https://github.com/lboasso/oberonc
Here is a list of others:
https://oberon07.com/compilers.xhtml
You are keen to rebut me, but you have not refuted me. Provide evidence for your case. Don't tell me I am wrong, because I've had decades of that and I don't care. Show me I am wrong and I will listen.
> "Oberon is an operating system"
<https://news.ycombinator.com/item?id=47762184>
Claim #1:
> this is not correct
<https://news.ycombinator.com/item?id=47763595>
Claim #2:
> It is an OS.
<https://news.ycombinator.com/item?id=47790959>
QED.
* * * *
> You are keen to rebut me
No, I'm really, really not. It would be great if you'd stick to wasting your own time in the future—or, better (esp. if you insist on involving others): only wasting the time of other people like you who would otherwise be doing harm elsewhere.
Perhaps more surprisingly, Turbo Modula 2 for CP/M (which was certainly surpassed by Topspeed Modula 2) was developed by Martin Odersky, who created Scala.
Throw in Robert Griesemer and his co-creation of Go, and the Wirth family tree is as influential in modern programming as it possibly could be.
> I was about 5 links deep before I figured out what Oberon actually was
You aren't being consistent.
On the screen is (readable to me at least) the first page of the paper "Oberon Language Report" showing N. Wirth as the author.
In the Introduction to the on-screen document it says, "Oberon is a general-purpose programming language that evolved from Modula-2."
https://ignorethecode.net/blog/2009/04/22/oberon/
A more in-depth look for folks with some comp-sci knowledge:
https://www.scribd.com/document/377504715/Oberon-the-Overloo...
The Oberon language and the Oberon System were featured in Byte Magazine several times, most notably in Dick Pountain's articles:
https://vintageapple.org/byte/pdf/199103_Byte_Magazine_Vol_1... https://vintageapple.org/byte/pdf/199305_Byte_Magazine_Vol_1... https://vintageapple.org/byte/pdf/199501_Byte_Magazine_Vol_2...
Spotting similarities betwen the appearance of the Oberon System and Plan 9, or Oberon syntax bits that were used in later languages, is left as an exercise for the reader.
IF disaster THEN abort;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.
I have to say that when I used Modula-2, editors were very simple and banging away on the shift key or caps lock was a real irritation.
Windows IDE tooling for Modula-2, or using something like XEmacs/Emacs or Brief.
I would call that an extra compiler pass to fix the SHOUTING syntax.
For that matter, how do syntax-aware editors solve the problem of finding significant spaces (Python) or parentheses (Lisp) unintuitive, confusing, or simply unpleasant?
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.
Alternative being Assembly written primitives, like in Smalltalk originally. Blue book description.
However this doesn't seem to be a solution that many are keen on going through.
How is Micro doing it?
Micron is doing well; the language definition has matured; it now even supports Go interfaces from level 2 onwards (i.e. even for plain records before level 3 adds dynamic memory). The primary goal of Micron is not safety, but to make a better C, Pascal and Oberon, adding some features which turned out to be very useful in C++, but without the complexity. The compiler now has an x86 and ARMv7 backend with debug support. RV32 support is on the horizon. And there is a C99 transpiler if need be.
If not, well there's another reason to have a Linux VM ready :)
Great Stuff!
Thanks to your work, that's about to change.
Thank you times a thousand <3
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).
Insisting that the problems of 1960 are the only thing that matters, and MUST be solved dogmatically is not.
At the same time, software from 1960-s did not have to deal with a lot of error conditions. When all you have is infallible computation code, you tend to overlook handling cleanups and exceptions. It was also single-threaded, so there was no focus on locking/mutability.
And it turns out that dealing with both of these requires stepping away from pure structured programming with one nice happy path and a single return.
It's the lack of something significantly larger that matters for this myth.
> Hence the long distance railways often use exactly the same gauge - but the exact measurement was a matter of Parliament deciding on what compromise to draw based on early railway lines, bearing in mind that it was a lot easier to reduce gauge rather than increase it.
The Russian railway was specifically designed to be incompatible with others (it's slightly larger) to make it harder for invading forces to use it. But even then it was not that much different from others.
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.
Thus it's wise to limit the complexity of your code. If it starts getting difficult, it might be time to break it down in smaller, more understandable, pieces.
E.g. a USB driver.
In comparison, Oberon has... nothing. If you check the source code of Oberon OS for something like USB, a lot of code is either YOLO or a mess of nested blocks.
Unfortunately just like the authors did in 1972, they are keen ignoring other languages learnings.
> Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own
https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist...
And thus systems programming without bounds checking was eventually made mainstream