<div dir="auto">Liam:<div dir="auto">You talk so well, much better than I ever could, you will be the evangelist. 🎅</div><div dir="auto">Oh and the technical writer that delivers 1st class doku, no matter what 💥.</div><div dir="auto"><br></div><div dir="auto">And System 3 with Gadgets ran very well in Virtual box last time I installed it. Just make some image files of the disks and mount them on a loopback. </div><div dir="auto"><br></div><div dir="auto">Joerg, Bernhard:</div><div dir="auto">I downloaded Vishap this afternoon, which is based on Ofront. It is very x86 centric, and I am not sure about the amount of work to break that out and change it to any architecture, but I fear not little. </div><div dir="auto">While I do have a very good idea of how to set up a bare metal Ada runtime with library both for small Avr 8 bitters and stm32 on a virgin gcc. </div><div dir="auto"><br></div><div dir="auto">Basically the runtime splits in 3. The clib, the controller specific hardware layer and the (Oberon) OS to whatever extend it is needed.</div><div dir="auto"><br></div><div dir="auto">For me the unknown is the front end. Maybe study that Modula2 compiler for a bit as well. </div><div dir="auto"><br></div><div dir="auto">J. </div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 30 Apr 2020, 20:57 Liam Proven, <<a href="mailto:lproven@gmail.com">lproven@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 30 Apr 2020 at 06:17, Joerg <<a href="mailto:joerg.straube@iaeth.ch" target="_blank" rel="noreferrer">joerg.straube@iaeth.ch</a>> wrote:<br>
<br>
> If I think of it, what I personally really like is actually not the Oberon language but the Oberon OS.<br>
<br>
Me too.<br>
<br>
The problem I have found talking about and trying to tell people<br>
about Oberon (language or OS) is that today, for most people, there<br>
are only 2 OSes: Windows NT and Linux. Everything else is niche or an<br>
end-user tool of little interest to anyone except professional<br>
programmers (macOS & iOS).<br>
<br>
People have genuinely, seriously said to me that there's no point in<br>
investigating other languages or OSes, because ultimately they are all<br>
implemented in C anyway.<br>
<br>
If all you know is NT and *nix, this is _obviously_ true: everything,<br>
at the bottom, is written in C. Because everything that is _not_<br>
implemented in C is so obscure most people have never heard of it.<br>
They don't know it even exists.<br>
<br>
This is the "black swan problem":<br>
<a href="https://en.wikipedia.org/wiki/Black_swan_theory" rel="noreferrer noreferrer" target="_blank">https://en.wikipedia.org/wiki/Black_swan_theory</a><br>
<br>
For millennia, it was a given that all swans are white, because in<br>
Europe and Asia and Africa, nobody ever saw a black swan. There are<br>
lots of different species of swans but they are all white. Therefore,<br>
all swans are white, QED.<br>
<br>
Then Europeans got to Australia and found that Australian swans are black.<br>
<br>
Nobody ever questioned that swans are white, because nobody ever even<br>
imagined that they could be any other colour. It was obvious that all<br>
swans are white because they all are.<br>
<br>
In programming languages today, from Perl to Python, to Lisp (on x86<br>
etc), to Pascal (Delphi etc.), .NET, Java, C++, D, C#, Clojure,<br>
whatever: either it's written in C or it's written in something that<br>
was implemented in C. It does not matter where you start, on and Unix<br>
or on any Windows, if you go down enough layers, you will get to C.<br>
<br>
Therefore, everything is implemented in C.<br>
<br>
Even things like Genode (Rust) or HelenOS... still C underneath.<br>
<br>
The modern alternatives to C, e.g. Rust or Go, were implemented in C.<br>
<br>
Apart from a few crazy or ancient systems that were hand-crafted in<br>
assembly, or at least parts of them: AmigaOS, MenuetOS, VisOpSys. They<br>
don't really matter.<br>
<br>
Thus, it is obvious that all swans are white, and all languages are<br>
written in C.<br>
<br>
So to get people interested in the idea that there is a whole other<br>
way to write OSes, and a whole other family of languages alive and<br>
well that _don't_ stem from C or from the Unix/Mac/DOS lineage, it is<br>
necessary to demonstrate to them that this language is real, it<br>
exists, it's not proprietary or commercial, and it doesn't just run on<br>
its own weird OS they've never heard of... it runs on the OSes they<br>
know and they can use it and explore it, and _then_ try the OS.<br>
<br>
> But indeed the crux of the Oberon OS is the not existing driver eco system for HW!<br>
<br>
It would seem to me that there are 2 ways to look at this.<br>
<br>
I regularly see people asking if they can run Classic MacOS, or RISC<br>
OS, or AmigaOS, under VirtualBox, or VMware, or $(insert hypervisor).<br>
<br>
They are not really aware that there are other architectures than x86.<br>
x86 is a given; all personal computers have x86. PC, Mac, Linux, even<br>
weird things like FreeBSD or AROS... all run on x86. So if people<br>
experiment with weird OSes, they run them on a hypervisor.<br>
<br>
The idea that there are OSes that they _can't_ run on a hypervisor is<br>
shocking and new.<br>
<br>
What this means is that perhaps what we need to focus on for Native<br>
Oberon is just making sure that it runs well on the main hypervisors.<br>
* VirtualBox is the main freeware one and runs on Windows, macOS and Linux<br>
* KVM and Xen are the main Linux ones (including KVM behind GNOME Boxes)<br>
* VMware and (very distant 2nd) Microsoft Hyper-V are the main<br>
commercial ones. Hyper-V comes free with modern Windows, though.<br>
<br>
The most important drivers for Native Oberon, then, IMHO, are to make<br>
sure that it works well on hypervisors -- mainly VirtualBox and<br>
VMware, followed by KVM. If it installs easily and runs well, then<br>
we're good.<br>
<br>
The second thing to consider, IMHO, is that it might be "better to be<br>
a big fish in a small pond, than a small fish in a big pond."<br>
<br>
If you're a small fish in the sea, you are in constant danger of being<br>
eaten. If you're a big fish in a little pond, you are safer and being<br>
noticed becomes a good thing.<br>
<br>
So I suggest that it would be better for Oberon if it supported some<br>
more narrow non-x86 hardware, where the number of necessary drivers<br>
would be tiny.<br>
<br>
This means ARM, realistically.<br>
<br>
And the best-selling end-user ARM computer in the world is the<br>
Raspberry Pi, with over 30 million units sold as of the end of last<br>
year: <a href="https://www.zdnet.com/article/raspberry-pi-now-weve-sold-30-million/" rel="noreferrer noreferrer" target="_blank">https://www.zdnet.com/article/raspberry-pi-now-weve-sold-30-million/</a><br>
<br>
There are only a handful of models and fewer if you only look at those<br>
still on sale. The Raspi 2, 3 and 3+ are inter-compatible. The Raspi 1<br>
is discontinued. The Compute Module is not really relevant (and is<br>
compatible anyway.)<br>
<br>
The Raspi Zero and Zero W (with wireless) are only about £5/$5 and are<br>
compatible with the 2/3/3+, but single-core.<br>
<br>
I would say:<br>
 - don't worry about driver support on x86; assume basically nobody<br>
will run it on bare metal. Make sure it works in 2 (maybe 3)<br>
hypervisors, and don't worry.<br>
<br>
- get it running on the Raspi 2/3/zero<br>
- the 4 is newer and optional, for now.<br>
<br>
Linux is very limited on the Raspi 2/3/zero: it's very slow and barely<br>
fits. This would be a _major_ chance for Oberon to shine.<br>
<br>
<br>
-- <br>
Liam Proven – Profile: <a href="https://about.me/liamproven" rel="noreferrer noreferrer" target="_blank">https://about.me/liamproven</a><br>
Email: <a href="mailto:lproven@cix.co.uk" target="_blank" rel="noreferrer">lproven@cix.co.uk</a> – gMail/gTalk/gHangouts: <a href="mailto:lproven@gmail.com" target="_blank" rel="noreferrer">lproven@gmail.com</a><br>
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven<br>
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053<br>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank" rel="noreferrer">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
</blockquote></div>