[Oberon] Interfacing with Foreign Systems (was: Negative integer literals in Oberon)

[Liam Proven]

On Thu, 30 Apr 2020 at 06:17, Joerg <joerg.straube at iaeth.ch> wrote:

> If I think of it, what I personally really like is actually not the Oberon language but the Oberon OS.

Me too.

The problem  I have found talking about and trying to tell people
about Oberon (language or OS) is that today, for most people, there
are only 2 OSes: Windows NT and Linux. Everything else is niche or an
end-user tool of little interest to anyone except professional
programmers (macOS & iOS).

People have genuinely, seriously said to me that there's no point in
investigating other languages or OSes, because ultimately they are all
implemented in C anyway.

If all you know is NT and *nix, this is _obviously_ true: everything,
at the bottom, is written in C. Because everything that is _not_
implemented in C is so obscure most people have never heard of it.
They don't know it even exists.

This is the "black swan problem":
https://en.wikipedia.org/wiki/Black_swan_theory

For millennia, it was a given that all swans are white, because in
Europe and Asia and Africa, nobody ever saw a black swan. There are
lots of different species of swans but they are all white. Therefore,
all swans are white, QED.

Then Europeans got to Australia and found that Australian swans are black.

Nobody ever questioned that swans are white, because nobody ever even
imagined that they could be any other colour. It was obvious that all
swans are white because they all are.

In programming languages today, from Perl to Python, to Lisp (on x86
etc), to Pascal (Delphi etc.), .NET, Java, C++, D, C#, Clojure,
whatever: either it's written in C or it's written in something that
was implemented in C. It does not matter where you start, on and Unix
or on any Windows, if you go down enough layers, you will get to C.

Therefore, everything is implemented in C.

Even things like Genode (Rust) or HelenOS... still C underneath.

The modern alternatives to C, e.g. Rust or Go,  were implemented in C.

Apart from a few crazy or ancient systems that were hand-crafted in
assembly, or at least parts of them: AmigaOS, MenuetOS, VisOpSys. They
don't really matter.

Thus, it is obvious that all swans are white, and all languages are
written in C.

So to get people interested in the idea that there is a whole other
way to write OSes, and a whole other family of languages alive and
well that _don't_ stem from C or from the Unix/Mac/DOS lineage, it is
necessary to demonstrate to them that this language is real, it
exists, it's not proprietary or commercial, and it doesn't just run on
its own weird OS they've never heard of... it runs on the OSes they
know and they can use it and explore it, and _then_ try the OS.

> But indeed the crux of the Oberon OS is the not existing driver eco system for HW!

It would seem to me that there are 2 ways to look at this.

I regularly see people asking if they can run Classic MacOS, or RISC
OS, or AmigaOS, under VirtualBox, or VMware, or $(insert hypervisor).

They are not really aware that there are other architectures than x86.
x86 is a given; all personal computers have x86. PC, Mac, Linux, even
weird things like FreeBSD or AROS... all run on x86. So if people
experiment with weird OSes, they run them on a hypervisor.

The idea that there are OSes that they _can't_ run on a hypervisor is
shocking and new.

What this means is that perhaps what we need to focus on for Native
Oberon is just making sure that it runs well on the main hypervisors.
* VirtualBox is the main freeware one and runs on Windows, macOS and Linux
* KVM and Xen are the main Linux ones (including KVM behind GNOME Boxes)
* VMware and (very distant 2nd) Microsoft Hyper-V are the main
commercial ones. Hyper-V comes free with modern Windows, though.

The most important drivers for Native Oberon, then, IMHO, are to make
sure that it works well on hypervisors -- mainly VirtualBox and
VMware, followed by KVM. If it installs easily and runs well, then
we're good.

The second thing to consider, IMHO, is that it might be "better to be
a big fish in a small pond, than a small fish in a big pond."

If you're a small fish in the sea, you are in constant danger of being
eaten. If you're a big fish in a little pond, you are safer and being
noticed becomes a good thing.

So I suggest that it would be better for Oberon if it supported some
more narrow non-x86 hardware, where the number of necessary drivers
would be tiny.

This means ARM, realistically.

And the best-selling end-user ARM computer in the world is the
Raspberry Pi, with over 30 million units sold as of the end of last
year: https://www.zdnet.com/article/raspberry-pi-now-weve-sold-30-million/

There are only a handful of models and fewer if you only look at those
still on sale. The Raspi 2, 3 and 3+ are inter-compatible. The Raspi 1
is discontinued. The Compute Module is not really relevant (and is
compatible anyway.)

The Raspi Zero and Zero W (with wireless) are only about £5/$5 and are
compatible with the 2/3/3+, but single-core.

I would say:
 - don't worry about driver support on x86; assume basically nobody
will run it on bare metal. Make sure it works in 2 (maybe 3)
hypervisors, and don't worry.

- get it running on the Raspi 2/3/zero
- the 4 is newer and optional, for now.

Linux is very limited on the Raspi 2/3/zero: it's very slow and barely
fits. This would be a _major_ chance for Oberon to shine.


-- 
Liam Proven – Profile: https://about.me/liamproven
Email: lproven at cix.co.uk – gMail/gTalk/gHangouts: lproven at gmail.com
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053