5 ms·

What is interesting about Oberon is that it is a complete (i.e. OS + compiler + HW) usable system that can be understood in its entirety by a single human being

by eterps 6y ago

What is interesting about Oberon is that it is a complete (i.e. OS + compiler + HW) usable system that can be understood in its entirety by a single human being within one lifetime. As far as I know it's also the only system currently in existence that fullfills that promise.

undershirt 6y ago
CollapseOS is trying to meet that promise too. It’s interesting because it does unwittingly follow Wirth’s thinking. Collapse would be a consequence of allowing ourselves to not to understand our systems.
cyberpunk 6y ago
You could have put TempleOS into that bucket too, but unfortunately the author is no longer with us. RIP Terry :(
johndoe0815 6y ago
One interesting point about Modula and Oberon is that these systems were not only the topics of academic research (which are often quickly abandoned when the related project ends). Rather, the systems were used at ETH to educate generations of students over the period of more than a decade, running on custom-designed hardware from day one (the Ceres workstations). We arguably spend too much time teaching our students how to work with complex commercial systems (or nowadays also complex open source systems such as Linux) and should try to rely more on self-developed software which can be understood, adapted and improved in a reasonable amount of time. I'm trying to revive some of that spirit in my courses and projects. Maybe Oberon errs a bit too much on the side of simplicity. I don't think it's very problematic that the compiler doesn't implement sophisticated optimizations, but the OS part of Project Oberon does not implement memory protection (the older Ceres-based system did to some extent) or preemptive multitasking. This is appropriate considering the system's age and the constraints of the FPGA for the original RISC5 system, but due to this the OS part of Oberon is on a similar level as non-NT Windows and classic MacOS. Accordingly, it's not a very useful example design today IMHO. Other systems such as xv6 might be more appropriate here, but xv6 was never designed to be used as a desktop os for real-world use. One problem that also affects other bare-metal systems such as Lukas Hartmann's Interim OS (http://interim-os.com http://interim-os.com) or my Smalltalk-80 port (https://multicores.org/blog/smalltalk-on-a-small-computer.html https://multicores.org/blog/smalltalk-on-a-small-computer.ht...) for the Raspberry Pi, is handling the complexity of modern peripheral and communication protocols. Some of the worst "offenders" here are USB and Bluetooth, both of which require driver and protocol stack code that often has more lines of code and is more complex than the rest of the system. Ethernet and TCP/IP might be a bit more manageable, Adam Dunkels' uIP/lwIP are a good example. So, as always in system design, the art is to find the right tradeoffs. Exploring the design space here is interesting, especially within the constraints of a real-world ISA as a basis. And I think projects involving small operating systems and RISC V are lots of fun (I hope Rikke agrees ;-) - we also have students working on Plan9 and Inferno ports to RISC-V) in addition to be educationally worthwhile - IMHO an important point to keep students motivated. I think we should probably all re-read Prof. Wirths "A Plea for Lean Software" (https://cr.yp.to/bib/1995/wirth.pdf https://cr.yp.to/bib/1995/wirth.pdf) once in a while, but also consider how to apply the principles of this paper carefully instead of going for absolute minimalism. I hope that something along these lines will be a valuable learning outcome for the students working on my projects and attending my courses..
- wrycoder 6y ago
  And yet ETH has virtually abandoned Oberon. The younger people associated with the project had to move elsewhere to continue, it seems. That’s a shame.
  - pjmlp 6y ago
    It is hard to keep the ball rolling when the project drivers are no longer around. I expect the same to happen to Linux when those of us that grew up with it, Linus and his gang are all gone. Whoever comes next will just drive it into something else. You already see this with the uprising of MIT licensed POSIX clones for IoT devices, or most userspace innovations being driven by a single company. Regarding ETHZ, at least Active Oberon seems to still be being worked on https://lists.inf.ethz.ch/pipermail/oberon/2019/013611.html https://lists.inf.ethz.ch/pipermail/oberon/2019/013611.html
    - ducktective 6y ago
      You are talking about likes of Zephyr or NuttX?
      - pjmlp 6y ago
        Among others, those aren't the only contenders.
wrycoder 6y ago
Alan Kay made a really noble and modern effort at VPRI, but his group detonated and disintegrated for reasons never made clear, leaving the project unfinished with no community follow up.

by eterps 6y ago

undershirt 6y ago

CollapseOS is trying to meet that promise too. It’s interesting because it does unwittingly follow Wirth’s thinking. Collapse would be a consequence of allowing ourselves to not to understand our systems.

cyberpunk 6y ago

You could have put TempleOS into that bucket too, but unfortunately the author is no longer with us. RIP Terry :(

johndoe0815 6y ago

One interesting point about Modula and Oberon is that these systems were not only the topics of academic research (which are often quickly abandoned when the related project ends). Rather, the systems were used at ETH to educate generations of students over the period of more than a decade, running on custom-designed hardware from day one (the Ceres workstations). We arguably spend too much time teaching our students how to work with complex commercial systems (or nowadays also complex open source systems such as Linux) and should try to rely more on self-developed software which can be understood, adapted and improved in a reasonable amount of time. I'm trying to revive some of that spirit in my courses and projects. Maybe Oberon errs a bit too much on the side of simplicity. I don't think it's very problematic that the compiler doesn't implement sophisticated optimizations, but the OS part of Project Oberon does not implement memory protection (the older Ceres-based system did to some extent) or preemptive multitasking. This is appropriate considering the system's age and the constraints of the FPGA for the original RISC5 system, but due to this the OS part of Oberon is on a similar level as non-NT Windows and classic MacOS. Accordingly, it's not a very useful example design today IMHO. Other systems such as xv6 might be more appropriate here, but xv6 was never designed to be used as a desktop os for real-world use. One problem that also affects other bare-metal systems such as Lukas Hartmann's Interim OS (http://interim-os.com http://interim-os.com) or my Smalltalk-80 port (https://multicores.org/blog/smalltalk-on-a-small-computer.html https://multicores.org/blog/smalltalk-on-a-small-computer.ht...) for the Raspberry Pi, is handling the complexity of modern peripheral and communication protocols. Some of the worst "offenders" here are USB and Bluetooth, both of which require driver and protocol stack code that often has more lines of code and is more complex than the rest of the system. Ethernet and TCP/IP might be a bit more manageable, Adam Dunkels' uIP/lwIP are a good example. So, as always in system design, the art is to find the right tradeoffs. Exploring the design space here is interesting, especially within the constraints of a real-world ISA as a basis. And I think projects involving small operating systems and RISC V are lots of fun (I hope Rikke agrees ;-) - we also have students working on Plan9 and Inferno ports to RISC-V) in addition to be educationally worthwhile - IMHO an important point to keep students motivated. I think we should probably all re-read Prof. Wirths "A Plea for Lean Software" (https://cr.yp.to/bib/1995/wirth.pdf https://cr.yp.to/bib/1995/wirth.pdf) once in a while, but also consider how to apply the principles of this paper carefully instead of going for absolute minimalism. I hope that something along these lines will be a valuable learning outcome for the students working on my projects and attending my courses..

wrycoder 6y ago
And yet ETH has virtually abandoned Oberon. The younger people associated with the project had to move elsewhere to continue, it seems. That’s a shame.
- pjmlp 6y ago
  It is hard to keep the ball rolling when the project drivers are no longer around. I expect the same to happen to Linux when those of us that grew up with it, Linus and his gang are all gone. Whoever comes next will just drive it into something else. You already see this with the uprising of MIT licensed POSIX clones for IoT devices, or most userspace innovations being driven by a single company. Regarding ETHZ, at least Active Oberon seems to still be being worked on https://lists.inf.ethz.ch/pipermail/oberon/2019/013611.html https://lists.inf.ethz.ch/pipermail/oberon/2019/013611.html
  - ducktective 6y ago
    You are talking about likes of Zephyr or NuttX?
    - pjmlp 6y ago
      Among others, those aren't the only contenders.

wrycoder 6y ago

Alan Kay made a really noble and modern effort at VPRI, but his group detonated and disintegrated for reasons never made clear, leaving the project unfinished with no community follow up.