[HN Gopher] Project Oberon
___________________________________________________________________
Project Oberon
Author : Koshkin
Score : 253 points
Date : 2022-02-25 13:42 UTC (9 hours ago)
(HTM) web link (www.projectoberon.com)
(TXT) w3m dump (www.projectoberon.com)
| jkonline wrote:
| I find it hard to cpnclude how "useful and usable in a production
| environment" an OS project can be, when the project website still
| isn't using SSL/ HTTPS.
| pjmlp wrote:
| The Oberon channel has several videos of Oberon in action,
|
| https://www.youtube.com/results?search_query=The+Oberon+Chan...
|
| While Oberon was quite cool, people should also learn about its
| Xerox influence,
|
| "Eric Bier Demonstrates Cedar"
|
| https://www.youtube.com/watch?v=z_dt7NG38V4
|
| Also dive into what happened afterwards, Oberon-2, Active Oberon,
| Zonnon,...
|
| Active Oberon could be considered quite modern, also makes the
| distinction between safe and unsafe pointers, which improves the
| experience for low level coding.
|
| https://github.com/metacore/A2OS
|
| One of the best things about these systems is proving what
| systems programming with automatic memory management were capable
| of.
|
| Given Oberon-2's influence on Go, maybe improving Fyne
| (https://fyne.io/fynedesk/) with something like gRPC for the
| dynamic experience, could be a possible sucessor.
| kragen wrote:
| To be entirely meticulous about the genealogy, I think Wirth
| was at PARC in 01976, and what inspired him most there was
| Mesa; Lampson first described (Mesa's successor) Cedar in PARC
| TR CSL-83-15, Xerox Palo Alto Research Center, December 01983,
| and without rereading the report, I think Cedar's development
| began about 01981. So Cedar is Oberon's sibling, not its
| parent.
|
| The connecting link at ETH between Mesa and Oberon was the
| Lilith workstation with its system software written in Wirth's
| Modula-2 (01977-01984).
|
| As for Golang, the relationship is much more direct! The first
| public version of Golang is mostly a slightly modified version
| of Pike's Newsqueak, but at the point Golang became Golang,
| Pike was working with Griesemer and Thompson. IIRC Griesemer
| did his dissertation under Wirth at ETH on extending Oberon to
| parallel computers.
| pjmlp wrote:
| Yes, mostly correct.
| kragen wrote:
| I'd be delighted if you'd correct whatever isn't!
| pjmlp wrote:
| Go is mix of Limbo and Oberon-2.
|
| I also remember reading somewhere that Wirth found Cedar
| too powerful, or complex, so Oberon was designed with the
| goal to be as capable as Cedar environment, while using a
| simpler language.
|
| So not sure which kind of relation I would put them,
| besides being an inspiration.
| _fz_ wrote:
| Here's a Project Oberon emulator in Go:
| https://github.com/fzipp/oberon
|
| And a Go port of the RISC compiler:
| https://github.com/fzipp/oberon-compiler
| badsectoracula wrote:
| While these are called "Oberon", judging from the screenshots
| (i haven't watched the videos), they seem to be way beyond the
| minimalistic nature of the Oberon system shown in Project
| Oberon.
|
| I think the emulator linked at the bottom left side is a better
| way to check out Oberon in action as you can easily (well,
| after you figure out how things get compiled, etc :-P) see it
| in practice and how a few individually simple (if not outright
| primitive) things can be combined to create something nice. For
| example i always found it amusing that the "menu bar" in each
| window is really just a regular text area and the commands
| shown are really methods that are called when you (IIRC) middle
| click them, like any other text in a window (so the main "GUI"
| for a program can really by just a text file with methods to
| click on - and of course since it is editable you can simply
| customize the GUI by editing the text file).
| pjmlp wrote:
| They are Oberon, the system that was described on the first
| edition of Project Oberon was the version 1.
|
| ETHZ researchers and Niklaus Wirth then iterated further on
| the Oberon (the OS) and Oberon (the language).
|
| The definitive Oberon (the OS) version that still uses the
| plain Oberon (the language) from original project was System
| 3, which is what those videos relate to.
|
| In Active Oberon used to write AOS (BlueBottle OS), you can
| still relauch System 3 as a nested OS.
| badsectoracula wrote:
| Yes they are Oberon too but my point is that they've
| evolved and added a ton of stuff that go further than the
| minimalistic nature of the linked site. The "Project
| Oberon" in the site doesn't even have overlapping windows
| or color for example.
| pjmlp wrote:
| That is like evaluating what MS-DOS was capable of by
| looking at MS-DOS 1.0 instead of 6.22.
|
| Oberon 1.0 isn't what was the daily driver at ETHZ,
| beyond its initial introduction.
| wrycoder wrote:
| I consider Active Oberon and AOS to be forks, and I think
| Wirth does, also. I believe that he feels that Project
| Oberon is _his_ final word on the subject.
|
| Wirth created Oberon-7 largely by _removing_ features[0]:
|
| _Revised Oberon (Oberon-07) is a revision of the original
| language Oberon as defined in 1988 /1990. It is accepted by
| the compiler recently completed for the ARM processor. Most
| changes in the language might easily be called features of
| a dialect. However, there are a few that merit a stronger
| distinction, because they should be considered as
| permanent, and as corrections of unsatisfactory properties
| of the original Oberon. These are the elimination of the
| loop statement, function result specification, array
| assignments, constant parameters, and read- only import of
| variables. All changes were made in the interest of
| regularity, simplicity, completeness, and well-
| structuredness._
|
| See also [3] for confirmation that Oberon-7 is the language
| of Project Oberon.
|
| I'd recommend reading the papers on Wirth's personal site
| [2].
|
| [0] https://people.inf.ethz.ch/wirth/Oberon/Oberon07.pdf
| (pdf) (15Jul2011 update)
|
| [1]
| https://people.inf.ethz.ch/wirth/Oberon/OberonAtAGlance.pdf
| (pdf) (20Nov2013)
|
| [2] https://people.inf.ethz.ch/wirth/Oberon/index.html
|
| [3] https://people.inf.ethz.ch/wirth/ProjectOberon/PO.Syste
| m.pdf (pdf) (2013)
| pjmlp wrote:
| Project Oberon cannot be his final word, given that it is
| only the first version, later upgraded up to System 3
| version.
|
| It is hard to consider them forks, when they originated
| on the same department and he also collaborated in some
| form.
|
| Component Pascal and Zonnon, those are proper forks.
|
| While I admire Wirth's work, his goal to pursue a
| minimalist Oberon with Oberon-07 is not so interesting to
| me.
|
| My pocket phone is more powerful than any Xerox
| workstation, why should we keep searching for such
| minimalist endeavours, instead of the rich development
| experience provided by them.
| fouc wrote:
| > the 2013 edition of Project Oberon and its results are intended
| to be presented "as-is", a teaching and learning resource kept
| reasonably static in the spirit in which the original book was
| written.
|
| This is a classic
| lboasso wrote:
| If you want to try out only the Oberon language, you might be
| interested in oberonc [0] an oberon-07 self-hosting compiler for
| the JVM. There are other several Oberon implementations for
| different platforms listed here[1]
|
| [0] https://github.com/lboasso/oberonc
|
| [1] http://oberon07.com/compilers.xhtml
| carapace wrote:
| Project Oberon is awesome!
|
| I found the Project Oberon book in SFSU library and read it cover
| to cover. Such a tight, elegant system. Pretty much complete:
| Oberon OS includes compiler for Oberon language!
|
| Language was self-hosted (compiler written in itself) and Prof.
| Wirth had a heuristic: no feature could be added to the
| lang/compiler if it made compiling the compiler slower.
|
| There are several emulators, in C, JS, Java, and Python, and
| there's Verilog so you can burn to FPGA and make a real
| workstation. People have.
|
| The system has two kinds of OOP. There is the
| C++/Java/Python/etc. kind where you basically add methods to a
| record type, and there is the old school Smalltalk message-
| passing kind, where elements of the OS communicate through an
| extendable message bus.
|
| The GUI system, especially with the "Gadgets" subsystem, is mind-
| blowing. It would take too long to go over it at the moment, but
| there are features there that _still_ haven 't made it into
| mainstream GUI systems. If I get a minute later today I'll come
| back and add a note detailing some of the awesome if someone else
| hasn't already filled in the picture.
| kragen wrote:
| I'm looking forward to reading your note; IIRC "Gadgets"
| postdates the book and so isn't documented in it.
| carapace wrote:
| Yes, Gadgets was written by a student later on. "The GADGETS
| user interface management system" https://www.research-
| collection.ethz.ch/handle/20.500.11850/...
|
| I'm trying to find original sources, as my memory is a little
| foggy. There is some good information here:
| https://en.wikibooks.org/wiki/Oberon/ETH_Oberon/Tutorial
|
| Basically it combined a nice Model-View-Controller widget
| collection with facilities like live introspection and
| editing of widgets, and embedding widgets in (multiple)
| documents (edit a spline widget in one view and it changes in
| all the views/docs in which it's embedded)
|
| It might sound a little plain vanilla now, but this was in
| 1990-1991.
| kragen wrote:
| Thank you!
| marktangotango wrote:
| Some of the gui stuff actually made it into Plan 9, see the
| acme editor for more info.
|
| I love all of Wirths writing, he really does a lot to make
| complex topics approachable.
|
| Note there's a lot more to OOP than adding methods to records,
| on the surface yeah, but "primitive" sub-typing just scratches
| the surface. This isn't a criticism, just a note so anyone
| interested can learn more, Pierce's Types and Programming
| Languages is a good place to start.
| chadcmulligan wrote:
| > The GUI system, especially with the "Gadgets" subsystem, is
| mind-blowing. It would take too long to go over it at the
| moment, but there are features there that still haven't made it
| into mainstream GUI systems.
|
| Have you seen Delphi?
| pjmlp wrote:
| I have a old article with lots of screenshots,
|
| http://progtools.org/article.php?name=oberon§ion=compile...
| 7thaccount wrote:
| Pretty amazing. I wish I could do my work on a truly
| lightweight system like this.
| Rochus wrote:
| See also http://oberon-lang.ch or https://github.com/rochus-
| keller/oberon for a modern version which runs on Windows, Mac and
| Linux including an IDE with source-level debugger.
| johndoe0815 wrote:
| This project is still a great example of a complete computer
| design, starting from Niklaus Wirth's own RISC5 CPU (not a
| RISC-V) and very simple peripherals over the OS, runtime/garbage
| collector, compiler, GUI and simple example applications.
|
| One problem of the original implementation is that it was based
| on an old Xilinx Spartan 3 development board. This is not only no
| longer available, but it is one of the few FPGA boards that used
| 32 bit wide fast (12 ns IIRC) asynchronous SRAM chips. Wirth's
| hardware design relies heavily on this.
|
| Some years ago, there was a compatible board, the OberonStation.
| However, it seems this is no longer manufactured:
| https://pcper.com/2015/12/meet-the-oberonstation-kid-friendl...
|
| However, some modified designs exist that implement a cache in
| FPGA block RAM and an SDRAM controller. These can be used with
| more recent FPGA boards:
|
| - FleaFPGA "Ohm" board with a Lattice ECP5 FPGA and 32 MB RAM
| (https://fleasystems.com/fleaFPGA_Ohm.html) -
| https://github.com/Basman74/Oberon_SDRAM
|
| - Radiona ulx3s, another ECP5 in an open source design
| (https://github.com/emard/oberon) -
| https://github.com/emard/oberon
|
| - PapilioPro using a Xilinx Spartan 6 LX, another open source PCB
| design (https://papilio.cc/index.php?n=Papilio.PapilioPro) -
| https://opencores.org/projects/oberon_sdram
|
| Shameless plug: my student Rikke's port of Project Oberon to
| RV32I (this is a real RISC-V), however, we still need to find
| some time to build an FPGA-based SoC. Currently, it runs in
| emulation: https://github.com/solbjorg/oberon-riscv
| kragen wrote:
| The _original_ implementation of Oberon was based on a Nominal
| Semidestructor 32032. Thanks for linking these more recent
| designs! Especially, I had no idea Oberon had been ported to
| RISC-V, which is very inspiring indeed!
| johndoe0815 wrote:
| Right, Wirth's group used to build their own machines. The
| previous Modula-2 machine (Lilith) was a microcoded 16-bit
| system built from SSI/MSI 74-series TTL components whereas
| the Ceres family of workstations used different CPUs and
| support chips from the NS32k family - the final version
| (Ceres 3) used a low-cost embedded version of the NS32k
| without an MMU (you don't need one for a type-safe language -
| that was at least the motivation for this...). It could run
| diskless and boot over a proprietary network, which used the
| same hardware (Zilog Z8530 SCC) as Apple's Localtalk in Macs
| (but a different protocol, I think).
|
| An FPGA reimplementation of the Ceres would be great to have.
| Someone already did the hard work and implemented a NS32k
| soft core - http://www.cpu-ns32k.net/index.html
|
| The old edition of the Project Oberon book that described the
| NS32k version is a bit hard to find. But it's interesting to
| see how little has changed between the versions.
| johndoe0815 wrote:
| Just noticed "Nominal Semidestructor". Right on point! :)
| rbanffy wrote:
| I wonder if it could be ported to the MiSTer platform. It seems
| to be a very common and friendly device.
| johndoe0815 wrote:
| This should be possible - Hellwig Geisse (forgot to mention
| his project, sorry - https://github.com/hgeisse/THM-Oberon)
| is working on an Oberon port to the Terasic DE2-115 FPGA
| port, which has an Altera FPGA like the MiSTer. The basis of
| the MiSTer is a Terasic DE10 Nano FPGA board, which has a
| more recent Cyclone V FPGA (the DE2-115 has a Cyclone II).
|
| The MiST (MiSTer's predecessor, https://github.com/mist-
| devel) would also be a nice platform.
|
| More Oberon resources and links can be found here if you are
| interested: https://riskfive.com/Web_resources.htm
| visviva wrote:
| Maybe Project Oberon is widely known to others, but if not, I
| suggest the title be changed to something like "Project Oberon is
| a design for a complete desktop computer system from scratch".
| rob74 wrote:
| I was aware of the Oberon programming language, which is the
| successor of Modula-2, which is itself the successor of Pascal
| (all invented by Niklaus Wirth), but it took me a few minutes
| to remember that there was also an OS and computer system
| called Oberon. However in a university setting it makes perfect
| sense to have a complete "package" of hardware, OS and
| programming language which you can design and understand "from
| the ground up".
| ge96 wrote:
| Recently heard about Serenity OS wonder if it's similar or
| different ideals.
| midislack wrote:
| It'd be cool if we all had to use this. But nobody does.
| Koshkin wrote:
| Someone does:
|
| https://visual.sfu-kras.ru
| pjmlp wrote:
| In a very twisted way, .NET on Windows alongside PowerShell,
| and Java/Kotlin on Android take many similar ideas, but granted
| they fail at the full execution.
| Kototama wrote:
| I wish more languages/softwares/projects set this goal of
| simplicity and clarity.
|
| Clarity is easier to measure. Simplicity is harder. Take Golang
| for example, yes you can learn the language in a few days or
| weeks but then some of the external complexity ends up with
| boilerplate. Is that simpler in the end?
|
| Then simplicity has many aspects. Take a software project. Simple
| for who? the users? the original devs? the maintainers?
|
| We have Kolmogorov complexity for algorithms but what is the
| equivalent to measure whole systems?
| JulianWasTaken wrote:
| > We have Kolmogorov complexity for algorithms but what is the
| equivalent to measure whole systems?
|
| Theory is nice, but we don't really spend enough time
| systematically or empirically measure how long it takes people
| to learn various things, or similarly how easy they find making
| a change to an existing (codebase|project|language|etc). Doing
| so and just reporting what we learn as an industry would have a
| ton of value -- arguably a lot more than just coming up with a
| metric or proxy model of what we care about (how long something
| takes to learn or maintain).
| kobieyc wrote:
| jdlyga wrote:
| Is this a fork of Project Ganelon?
___________________________________________________________________
(page generated 2022-02-25 23:00 UTC)