
Oberon Operating System - JNRowe
https://en.wikipedia.org/wiki/Oberon_(operating_system)
======
Athas
When people ask "how would you write an operating system without C?", Oberon
is what I point them to. It's a very different style than Unix, in that the
Oberon language is a relatively integrated part of the operating system,
rather than communication being through a machine-level ABI. There were some
spiritual predecessors where the compiler _itself_ was part of the OS, and
there was no other way to communicate with it than through the language
semantics. I'm not completely sure whether Oberon works like that, but some
Concurrent Pascal systems did. It's a very different view of what an
"operating system" means.

Anyway, Oberon is a memory-safe and garbage-collected language without the
pointer trickery that makes C so dangerous. So how does Oberon implement the
necessary low-level parts? Fortunately, some version of the source is easily
browsable online:
[https://people.inf.ethz.ch/wirth/ProjectOberon/index.html](https://people.inf.ethz.ch/wirth/ProjectOberon/index.html)

Here is for example Kernel.Mod:
[https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne...](https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kernel.Mod.txt)

Low-level operations are done with magical functions that simply perform an
operation on a memory address identified with an integer, e.g.
`SYSTEM.PUT(q0+8, q1)`. These are then presumably handled directly by the
compiler (the System.Mod file does not define any PUT function). This is
syntactically more awkward than the equivalent in C (`q0[2] = q1`, assuming
this is an `int` pointer), but perhaps things that are unchecked and
potentially dangerous _should_ be syntactically awkward. It's not like a lot
of code will be written using these facilities.

~~~
fouc
>in that the Oberon language is a relatively integrated part of the operating
system

>There were some spiritual predecessors where the compiler itself was part of
the OS

Sounds very much like forth or lisp to me, (and perhaps even erlang etc). Any
language that's implemented like a virtual machine internally is suited to
being an "integrated" operating system.

I think there's a tremendous amount of advantages to doing this as well, it
reduces the levels of abstractions between the hardware and the user
applications. Reduced level of abstractions means a snappier experience for
the users, and also makes it easier for the developer to integrate things
vertically.

[http://tunes.org](http://tunes.org) touches on this type of thing as well

~~~
Athas
Lisp machines, definitely. With respect to Forth, I'm not sure. Has there ever
been a Forth operating system that provides the facilities we would expect of
a modern operating system (and using Forth as the interface)? There are lots
of Forth applications on bare hardware, and I see no reason why it should not
be possible (except that you'd need some kind of extension for concurrency), I
just don't know whether it has been done.

I wonder if there is a lesson in the fact that all of the tightly language-
integrated operating systems are dead. While Unix is clearly tied to C at an
API level, the actual ABI is entirely based on machine code, and can be
accessed through any language that can produce a binary. The downside may be
that tight integration hinders language innovation, in that new languages have
to target the "native language", which is awkward if it is high-level. Genera
(the Symbolics Lisp OS) did host some C and FORTRAN compilers ("Zeta-C", you
can get it online[0]), but I am not sure how fast it ran. Unix is often
disparaged for providing "mechanism" instead of "policy", but maybe that has
serious evolutionary advantages.

[0]:
[http://www.bitsavers.org/bits/TI/Explorer/zeta-c/](http://www.bitsavers.org/bits/TI/Explorer/zeta-c/)

~~~
eterps
> While Unix is clearly tied to C at an API level, the actual ABI is entirely
> based on machine code, and can be accessed through any language that can
> produce a binary.

I see your point, but the Oberon system does have an ABI, it's not necessarily
coupled to the Oberon language but it is coupled to the linker of the system.
I have created binaries for Oberon in a rudimentary assembler, it's not hard
to have them work together with the native libraries (modules). In fact it's
less convoluted than ELF for example.

~~~
eterps
What I like about Oberon's module system is that there is no distinction
between a library and an app or command.

In Oberon an 'executable' has 1 or more commands, somewhat similar to how git
has more commands like pull, push & commit.

But everything is reusable you don't need a libgit at some point if you need
support for it in another application. Neither do you need to invoke a command
in a process and capture its output.

In Oberon git and libgit would be the same thing. Everything you execute as a
command is directly reusable as native functional calls from other apps.

~~~
zozbot234
One can do this quite easily in Windows as well, via RUNDLL32. Not sure if
Linux has a direct equivalent, however.

~~~
pjmlp
Not as Oberon.

In Oberon not only is every module an application, the exported procedures are
available as commands on the REPL and callable via mouse actions as well.

However in modern Windows you try to achieve a similar experience via what
PowerShell allows for (.NET, COM and DLL entry points) and OLE Automation.

Still is isn't as easy and painless as the whole Oberon OS allowed to.

------
koonsolo
At the university of Antwerp they gave Oberon as the first programming
language for Computer Science (back in 1997). The reasoning of the professor
was so that everyone started from scratch, because nobody would know it
already.

It was indeed an eye opener on how many different things there can still be.
Especially the mouse key combinations that you had to press were pretty
unique.

Never used it ever since that first year, but it's hard to forget because it
was so different.

~~~
Joeri
I was in that same class. I recall that same professor also used smurf
analogies to explain programming concepts. A peculiar man.

I have fond memories of learning oberon. It gave me a deeper understanding not
just of programming but the almost arbitrary conventions of popular OS’s, in
where to draw the line between code, documents and applications (in oberon
they were all the same thing), and how to use keyboard and mouse to manipulate
items on a screen.

------
augustk
The Oberon programming language is also a very nice alternative to C -
smaller, safer and easier to learn. It can be used without the Oberon
operating system.

~~~
sacado2
Go is Oberon's and C's secret child. They met thanks to Robert Griesemer, who
worked under Wirth's supervision, AFAIK, during his PhD.

I like how go gives access to the cool parts of Oberon within a relatively
popular language.

~~~
cxr
This is true, but Rob Pike has his own independent connections to Oberon. Acme
and other parts of Plan 9's mouse-driven UI were greatly "inspired" by the
Oberon system.

Go is the secret child of Oberon-the-language and C. Before Go, Plan 9 was
conceived as the secret child of Oberon-the-system and Unix.

~~~
pjmlp
That is more true of Inferno and Limbo than Plan 9.

------
Rochus
Oberon is very well suited for experiments; the language is so minimal that it
is quite easy to write a compiler. Here is e.g. a front end for LuaJIT:
[https://github.com/rochus-keller/Oberon](https://github.com/rochus-
keller/Oberon) (i.e. Oberon is used as an alternative to Lua with LuaJIT as a
backend; here is more information about the project:
[https://medium.com/@rochus.keller/implementing-call-by-
refer...](https://medium.com/@rochus.keller/implementing-call-by-reference-
and-call-by-name-in-lua-47b9d1003cc2)).

------
MisterTea
Another interesting Oberon project I found a while ago: XOberon, an RTOS for
robotics
[http://www.ifr.mavt.ethz.ch/research/xoberon/](http://www.ifr.mavt.ethz.ch/research/xoberon/)

No longer maintained or developed but an interesting piece of history
nonetheless.

~~~
jeffreygoesto
Oh man, blast from the past! Sjur the spin doctor and Roberto the master
mind... We had a collaboration where their robot was used as platform for a
mid-size league robocup participant (wannabe :-})... That realtime Oberon on
PowerPC was really cool!

------
carapace
To data, IMO, _nothing_ has beaten OberonOS TUI+Gadgets for UI smoothness.
(See Jef Raskin's "The Humane Interface")

Also, the Project Oberon book is a magnificent tome detailing a complete,
self-contained system that was used "in production" at the University. Highly
entertaining and educational.

Click here to run it in your browser on emulated hardware (no Gadgets though,
too bad.):
[https://schierlm.github.io/OberonEmulator/emu.html?image=Ful...](https://schierlm.github.io/OberonEmulator/emu.html?image=FullDiskImageWithSource&width=1024&height=576)

[https://schierlm.github.io/OberonEmulator/](https://schierlm.github.io/OberonEmulator/)

~~~
davidgould
Oberon+Gadgets was a glimpse into a different better world. I'm glad I got to
use it enough to realize that the UI's we have are not the UI's we could have
had.

The book Project Oberon is a masterpiece as are the language and system it
describes.

------
saagarjha
> No questions are asked: this is a deliberate design decision, which needs
> getting used to. Most editors ask the user when closing a modified text:
> this is not the case in the Oberon System.

I wonder how the system deals with user errors…

~~~
mannschott
For the case of accidentally closing a Viewer: The command System.Recall
restores the most recently closed Viewer. Just find or type that command
anywhere on the screen and then execute it by clicking it with the middle
mouse button.

------
robobro
I prefer Inferno but Oberon is interesting. The papers aren't a bad read
either.

~~~
pjmlp
I finds sad that many people focus too much on Plan9 and overlook Inferno,
which was actually his last stop, where Plan 9 designers actually implemented
some of the ideas they had originally for Plan9, like a memory safe GC
userspace (e.g. Alef).

~~~
zozbot234
It would indeed be nice to see a comparison between Inferno and Oberon. From a
distance, Alef and Limbo (the system languages used in Inferno) look like
obvious predecessors to Go.

~~~
pjmlp
A big difference is that Oberon OS is fully implemented Oberon, compiled to
native code, with some variants doing JIT on module load.

Whereas Inferno's kernel is implemented in Plan9's C variant, and Limbo uses
the DisVM.

------
gtirloni
Unrelated but related, I had a lot of fun programming in Modula-3 but it seems
getting the toolchain working in 2019 is more of a DIY project?

EDIT: I can't believe I said anything that warrants downvoting. Can't we share
experiences?

~~~
eterps
Mentioning Modula-3 and how to get the toolchain working isn't even remotely
related to the subject. Of course we can share experiences, but it would be
probably at the bottom of this thread, because it's off topic.

~~~
tralarpa
> isn't even remotely related to the subject

That's quite a statement, knowing the history of those languages.

~~~
eterps
I am happy to be proven wrong. What does Modula-3 have to do with the subject:

Oberon (Operating System)

~~~
tralarpa
The languages Oberon and Oberon-2 were explicitly designed for the task of
creating the operating system Oberon. When Wirth started working on the OS he
realized that it would be too hard to write a nice OS with just Modula-2 (at
least that's what I understood from the interviews he gave with various
journals). Modula-3 was an evolution of Modula-2 by DEC (not by Wirth), but it
was influenced by Oberon and they all belong to the same "Pascal language
family" in terms of design philosophy.

I think it's very natural to mention Modula-3 in the context of Oberon.

~~~
eterps
I guess it's onfortunate that Oberon the OS and the Oberon the language share
the same name.

To me it read like someone posting about Xv6 (Operating System) and a comment
mentioning Objective-C and how to get its toolchain working ;-)

------
lboasso
If you want to try out the Oberon language, there are several Oberon
implementations for different platforms, including embedded systems, native
windows executables, and the Java virtual machine:
[http://oberon07.com/compilers.xhtml](http://oberon07.com/compilers.xhtml)

~~~
pjmlp
I feel not having anything on a runnable state from System 3 or AOS doesn't do
proper justice to Oberon.

Those versions were already quite close to something like NeXT, but with
Oberon variants.

Nowadays what is left are random ISOs that don't always boot properly on VMs
and it isn't easy to compile the those OSes, even with some source still
floating around on Github.

EDIT: Some System 3 and AOS links from here might still be useable,
[https://en.wikibooks.org/wiki/Oberon#System_Variants](https://en.wikibooks.org/wiki/Oberon#System_Variants)

------
lacampbell
I love the idea of smaller more logical operating systems. I am surprised that
in the era of giant tech companies with top programmers and a lot of resources
the most commercially viable strategy is still "try and paper over the
complexities of linux" instead of starting something smaller and more modern.

~~~
majewsky
> starting something smaller and more modern

Where do you draw the line? Do you throw away Linux and write your own OS,
which is bound to grow to the same level of complexity because it needs to
deal with hardware complexity? Or do you throw away the existing hardware as
well and start from silicon? Maybe even reboot the computing stack on an
entirely different type of hardware?

~~~
moron4hire
Why not? Apple runs their own chips in the iPad and iPhone, with their own OS.
Seems to be working out for them.

~~~
owl57
And they have a somewhat continuous team working on that OS since before Linux
was a word. Same with Microsoft. Is it really relevant to any other company?

~~~
pushpop
Apple haven’t been working on iOS longer than Linux has been around. It’s true
that iOS is based on macOS which is based on NEXT (of various
capitalisations), FreeBSD and a few other platforms. But Apples direct
involvement starts at macOS and there’s very little FreeBSD/NEXT/etc in iOS
compared to original code. Likewise you could argue that “Linux” predates
Linux if you include the GNU user land and start tracing things backwards that
way (I’m assuming “Linux” in the context of this discussion is GNU/Linux
because it wouldn’t be fair to compare a kernel to a full desktop or mobile
OS).

Ultimately I don’t think either arguments are particularly useful as all they
demonstrate is that good technology is an evolutionary process of stands on
the shoulders of other pieces of good technology.

~~~
owl57
Sure, I didn't mean Linux isn't standing on the (partially the same)
shoulders. What I meant is macOS/iOS and Windows teams are unique in shipping
general-purpose OSs AND doing so and accreting code and expertise tied to that
code since ancient times when "try and paper over the complexities of linux"
wasn't an option at all.

~~~
pushpop
Whether it’s 10 years, 20 years or 30. I don’t think it makes much difference
after 10 in terms of the level of relevant expertise you’d expect.
Particularly when you factor in staff leaving, getting promoted, etc and new
engineers joining. Where Linux differs isn’t it’s age but rather it’s
development model being decentralised. FreeBSD might be a more comparable
example given the context you’re describing.

------
fortran77
Oberon! The king of the faeries!

[https://en.wikipedia.org/wiki/Oberon](https://en.wikipedia.org/wiki/Oberon)

~~~
tralarpa
If I remember correctly, Wirth mentioned the moon Oberon and the fact that the
name starts with an "O" (like "object oriented") as the source for the name of
his programming language.

------
vermilingua
Somewhat off topic: this wikipedia page reads like a sales pitch. Does anyone
know how to flag such pages for attention?

~~~
bennofs
Comment on the associated talk page, or edit it yourself to make it better?

[https://en.m.wikipedia.org/wiki/Wikipedia:NPOV_dispute](https://en.m.wikipedia.org/wiki/Wikipedia:NPOV_dispute)
may be relevant as well.

