Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)

github.com

Post reply on HN
Print view View original

41–50 of 122 posts

Re: Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)

#41

Post by fuck_google »

Rochus wrote: post #39
vidarh wrote: post #38

Earlier quoted context omitted.

It might have been Brandis' thesis I was primarily thinking about. Of the PhD theses at EHTz on Oberon, I'm also a big fan of Michael Franz' thesis on Semantic Dictionary Encoding, but that only touched on optimization potential as a sidenote. I'm certain there was at least one other paper on optimization, but it might not have been a PhD thesis... I get the motivation for wanting to use LLVM, but personally I don't…

I don’t like LLVM either, because its size and complexity are simply spiraling out of control, and especially because I consider the IR to be a total design failure. If I use LLVM at all, it would be version 4.0.1 or 3.4 at most. But it is the standard, especially if you want to run tests related to the question the fellow asked above. The alternative would be to build a frontend for GCC, but that is no less complex…

[dead]

Re: Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)

#42

Post by EffCompute »

Rochus wrote: post #17
EffCompute wrote: post #13

Earlier quoted context omitted.

It's refreshing to see Oberon getting some love on the Pi. There’s a certain 'engineering elegance' in the Wirthian school of thought that we’ve largely lost in modern systems. While working on a C++ vector engine optimized for 5M+ documents in very tight RAM (240MB), I often find myself looking back at how Oberon handled resource management. In an era where a 'hello world' app can pull in 100MB of dependencies, the…

I don't know. Unfortunately we don't have an Oberon compiler doing similar optimization as e.g. GCC, so we can only speculate. I did measurements some time ago to compare a typical Oberon compiler on x86 with GCC and the performance was roughly equivalent to that of GCC without optimizations (see https://github.com/rochus-keller/Are-we-fast-yet/tree/main/O... ). The C++ type system is also pretty strict, and on the o…

That benchmark is a great data point, thanks for sharing. The performance parity with unoptimized GCC makes sense, given how much heavy lifting modern LLVM/GCC backends do for C++.

Your approach with Micron and the 'language levels' is particularly interesting. One of the biggest hurdles I face in C++ with these high-density vector tasks is exactly that: balancing the raw 'unsafe' pointer arithmetic needed for SIMD and custom memory layouts with the safety needed for the rest of the application.

Having those features controlled at the module level (like your Micron levels) sounds like a much cleaner architectural 'contract' than the scattered unsafe blocks or reinterpret_cast mess we often deal with in systems programming. I'll definitely keep an eye on the Micron repository—bridging that gap between Wirth-style safety and C-level performance is something the industry is still clearly struggling with (even with Rust's rise).

Re: Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)

#43

Post by cyberax »

Rochus wrote: post #33
cyberax wrote: post #30

Earlier quoted context omitted.

"Traced back" is fine. We can trace back the size of the Shuttle's boosters to the width of the roads in the Roman Empire. Insisting that the problems of 1960 are the only thing that matters, and MUST be solved dogmatically is not.

Well, a lot of ideas (and I mean really a lot) from the sixties are still very relevant today, and indeed, there are also problems discovered in the sixties still waiting for a solution. We don't have to live in the past, but many "new" things aren't actually new, or are not better just because they are new.

Of course. Problems that existed in 60-s were very real. And structured programming was an improvement over messy gotos.

At the same time, software from 1960-s did not have to deal with a lot of error conditions. When all you have is infallible computation code, you tend to overlook handling cleanups and exceptions. It was also single-threaded, so there was no focus on locking/mutability.

And it turns out that dealing with both of these requires stepping away from pure structured programming with one nice happy path and a single return.

Re: Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)

#44

Post by anta40 »

Rochus wrote: post #3
eterps wrote: post #2

This is great! I remember running System 3 on a 386 back when MS-DOS was king.

Thanks. There is actually also an i386 version of the system in the repository, where I modified the kernel so it runs with Multiboot, making installations much easier. An essential achievement for both platforms were the stand-alone tools, i.e. I can compile and link the whole Oberon system on Linux or any other platform (see https://github.com/rochus-keller/op2/ ). I even implemented an IDE which I used for the dev…

Cool. Is macOS (Apple Silicon) also supported?

If not, well there's another reason to have a Linux VM ready :)

Re: Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)

#45

Post by pjmlp »

This is great, especially being System 3, given the nice user experience Oberon eventually morphed into.

In System 3 with the Gadgets system it was already starting to feel like a proper mainstream OS, instead of the plain black and white, without framework like experience from the initial Project Oberon, even thought it was a technological achivement already, with a memory safe systems language.

I prefer the path taken down by Active Oberon, however that doesn't seem to also get that much love nowadays, and is much more complex to explore than System 3.

For those that not know it, it already had something like OLE (inspired by how Xerox PARC did it with Cedar), an AOT/JIT compilation system (with slim binaries for portability), and everything on a memory safe systems language.

Re: Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)

#46

Post by gobdovan »

Rochus wrote: post #39
vidarh wrote: post #38

Earlier quoted context omitted.

It might have been Brandis' thesis I was primarily thinking about. Of the PhD theses at EHTz on Oberon, I'm also a big fan of Michael Franz' thesis on Semantic Dictionary Encoding, but that only touched on optimization potential as a sidenote. I'm certain there was at least one other paper on optimization, but it might not have been a PhD thesis... I get the motivation for wanting to use LLVM, but personally I don't…

I don’t like LLVM either, because its size and complexity are simply spiraling out of control, and especially because I consider the IR to be a total design failure. If I use LLVM at all, it would be version 4.0.1 or 3.4 at most. But it is the standard, especially if you want to run tests related to the question the fellow asked above. The alternative would be to build a frontend for GCC, but that is no less complex…

When you call LLVM IR a design failure, do you mean its semantic model (e.g., memory/UB), or its role as a cross-language contract? Is there a specific IR propert that prevents clean mapping from Oberon?

Re: Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)

#47

Post by pjmlp »

musicale wrote: post #32

Does Oberon still require capitalized keywords? That always seemed to be emphasizing the wrong thing: IF disaster THEN abort;

Yes, like Modula-2 as well.

However, people always forget we don't program in Notepad, rather programmer editors that are able to do automatic capitalisation of keywords.

It is a non problem, like discussion of parentheses or white space in programming languages that require them.

Re: Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)

#48

Post by pjmlp »

cyberax wrote: post #16
alterom wrote: post #12

I still hope to see the world where Oberon is the future (and present) of OS and programming language design, and I know very little about it. Thanks to your work, that's about to change. Thank you times a thousand <3

> I still hope to see the world where Oberon is the future (and present) of OS and programming language design I see you're into horror stories. Oberon is absolutely a horrible language. It's an example of how you can screw up a good language by insisting on things that were important in 1960-s. Like not allowing multiple returns (not multiple return _values_ but multiple returns).

Apparently a school of though widely embraced by Go scholars, nowadays resposible for our cloud infrastructure.

Re: Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)

#49

Post by rbanffy »

cyberax wrote: post #29
jhbadger wrote: post #20

Earlier quoted context omitted.

There's an argument (and I think a good one) that in structured programming there should be only one return per function. It's not that hard -- you just have a variable and you set it to what you want to return and the last line of the function returns that variable. I think that some things Wirth did with Oberon, particularly in the post Oberon-OS versions like Oberon-07, are a bit restrictive, but they are always i…

The problem is that pure structured programming just sucks. It doesn't have a good answers for cleanups or error handling. Structured programming was the answer to the earlier mess with unstructured gotos, but in the process of trying to improve it, structured programming became just as messy when taken dogmatically. In real life, what matters is the mental load. Every ambient condition that you need to track adds me…

> Every ambient condition that you need to track adds mental load

Thus it's wise to limit the complexity of your code. If it starts getting difficult, it might be time to break it down in smaller, more understandable, pieces.

Post reply on HN