Oh, this is something I'm going to have to try. Excellent work!
I have to ask, since people who'd know will probably be here, what's the "ten thousand foot view" of Oberon today? I'm aware of the lineage from Pascal/Modula, and that it was a full OS written entirely in Oberon, sort of akin to a Smalltalk or Lisp machine image. What confuses me is the later work on Oberon seems to be something of a cross between a managed runtime like Java or dot net, and the Inferno OS, where it can both run hosted or "natively". Whenever I've skimmed the wikipedia or web pages I've been a bit confused.
Thanks. In contrast to Smalltalk or Lisp, Oberon is originally a native language, and the Oberon System originally was conceived as the native operating system of the Ceres computer used for teaching in the nineties at ETH Zurich. So there is no image as in Lisp or Smalltalk. Oberon lives on today in the form of various dialects and derivatives (such as my Oberon+ or Micron languages, see https://github.com/rochus-keller/oberon and https://github.com/rochus-keller/micron). There are indeed Oberon implementations which run on Java or ECMA 335 runtimes, which is possible due to the very restricted pointer handling and memory management of Oberon.
The "OS" (or rather "kernel") was actually the VM which was implemented in microcode and BCPL. The Smalltalk code within the image was completely abstracted away from the physical machine. In today's terms it was rather the "userland", not a full OS.
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 idea of a full OS that is both human-readable and fits into a few megabytes is more relevant than ever.
Rochus, since you’ve worked on the IDE and the kernel: do you think the strictness of Oberon’s type system and its lean philosophy still offers a performance advantage for modern high-density data tasks, or is it primarily an educational 'ideal' at this point?
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 other hand it's possible and even unavoidable in the Oberon system 3 to do pointer arithmetics and other things common in C behind the compiler's back (via the SYSTEM module features which are not even type safe). So the original Oberon syntax and semantics is likely not on the sweet spot of systems programming. With my Micron (i.e. Micro Oberon, see https://github.com/rochus-keller/micron/) language currently in development I try for one part to get closer to C in terms of features and performance, but with stricter type safety, and on the other hand it also supports high-level applications e.g. with a garbage collector; the availabiltiy of features is controlled via language levels which are selected on module level. This design can be regarded as a consequence of many years of studying/working with Wirth languages and the Oberon system.
There was a couple of PhD theses at ETH Zurich in the 90s on optimizations for Oberon, as well as SSA support. I haven't looked at your language yet, but depending on how advanced your compiler is, and how similar to Oberon, they might be worth looking up.
I'm only aware of Brandis’s thesis who did optimizations on a subset of Oberon for the PPC architecture. There was also a JIT compiler, but not particularly optimized. OP2 was the prevalent compiler and continued to be extended and used for AOS, and it wasn't optimizing. To really assess whether a given language can achieve higher performance than other languages due to its special design features, we should actually implement it on the same optimizing infrastructure as the other languages (e.g. LLVM) so that both implementations have the same chance to get out the maximum possible benefit. Otherwise there are always alternative explanations for performance differences.
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 like it (and have the luxury of ignoring it since I only do compilers as a hobby...) and prefer to aim for self-hosting whenever I work on a language. But LLVM is of course a perfectly fine choice if your goal doesn't include self-hosting - you get a lot for free.
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 or time-consuming (and ultimately, you’re still dependent on binutils). However, C on LLVM or GCC should probably be considered the “upper bound” when it comes to how well a program can be optimized, and thus the benchmark for any performance measurement.
Threre are at least two projects I'm aware of, but I don't think they are ready yet to make serious measurements or to make optimal use of LLVM (just too big and complex for most people).
IOKit was actually built from the ground up for OS X! NeXT had a different driver model called DriverKit. I've never coded against either, but my understanding was they're pretty different beasts. (I could be wrong)
That said, indeed, the abstraction layer here is delightful! I know that some NetBSD devs managed to get PPC Darwin running under a Mach/IOKit compatibility layer back in the day, up to running Xquartz on NetBSD! With NetBSD translating IOKit calls. :-)
There’s a great video of a NeXT-era Steve Jobs keynote floating around—I think the one where he announces the x86 port as NeXT was transitioning to a software-only company—where he specifically calls out DriverKit and how great it is.
Steve was not a developer but he made it his business to care about what they cared about.
Yeah - even from the start, I remember NeXT marketing was spending a disproportionate amount of their time selling NeXT’s “object technology”, AppKit and Interface Builder, DPS as an advanced graphics model. It was good hunch from Steve, given how how modern NeXTSTEP feels in retrospect.
For some reason, though, it means that people overlook how NeXT’s hardware was _very_ far from fast. You weren’t going to get SGI level oomph from m68k and MO disks.
Yes, you're right! I'm just dolt who's never checked what a .kext on OS X actually is.
I had been under the impression that DriverKit drivers were quite a different beast, but they're really not. Here's the layout of a NS ".config" bundle:
The driver itself is a Mach-O MH_OBJECT image, flagged with MH_NOUNDEFS. (except for the _reloc images, which are MH_PRELOAD. No clue how these two files relate/interact!)
OS X added a dedicated image type (MH_KEXT_BUNDLE) and they cleaned up a bit, standardized on plists instead of the "INI-esque" .table files, but yeah, basically the same.
IOKit was almost done in Java; C++ was the engineering plan to stop that from happening.
Remember: there was a short window of time where everyone thought Java was the future and Java support was featured heavily in some of the early OS X announcements.
Also DriverKit's Objective-C model was not the same as userspace. As I recall the compiler resolved all message sends at compile time. It was much less dynamic.
Mostly because they thought Objective-C wasn't going to land well with the Object Pascal / C++ communities, given those were the languages on Mac OS previously.
To note that Android Things did indeed use Java for writing drivers, and on Android since Project Treble, and the new userspace driver model since Android 8, that drivers are a mix of C++, Rust and some Java, all talking via Android IPC with the kernel.
Yes, also the same reason why Java was originally introduced, Apple was afraid that the developer community educated in Object Pascal / C++, wasn't keen into learning Objective-C.
When those fears proved not true, and devs were actually welcoming Objective-C, it was when they dropped Java and the whole Java/Objective-C runtime interop.
It's worth mentioning that "Gemini Nano 4" is going to be Gemma 4, and presumably when it becomes the default Nano model, it should improve performance quite a bit.
(It's currently available for testing in Android's AICore under a developer preview)
In my experience, though, it's necessary to do anything security related. Interestingly, the big models have fewer refusals for me when I ask e.g. "in <X> situation, how do you exploit <Y>?", but local models will frequently flat out refuse, unless the model has been abliterated.
It’s so dispiriting to me that we’ve achieved those closest thing yet to an “objective truth” machine (with the caveat of garbage in, garbage out, etc.) and these big companies are either afraid to actually let it exist, want to push their own politics, or a combination of the two.
"closest thing yet" is still a long way from close; as you say, gin=gout, and the internet without an attempt to be our best selves is instead our loudest propagandists and all our cultural stereotypes.
Of course, humans are also impacted by these things, at best we can be a little deliberate about rejecting a few of the more on-the-nose examples.
No? Isn't the article about Codex, which is roughly equivalent to "Gemini CLI" and Google's Antigravity? Google's subscriptions include quotas for both of those, albeit the $20 monthly "Pro" plan has had its "Pro" model quota slashed in the last few weeks. You still get a large number of "Gemini 3 Flash" queries, which has been good enough for the projects I've toyed with in Antigravity.
I guess that's true but I find Google's models better than their public tooling. The Pro subscription includes "Gemini Code Assist and Gemini CLI" but the Gemini Code Assist plugin for IntelliJ which is my daily driver is broken most of the time to the degree that it's completely unusable. Sometimes you can't even type in the input box.
The only way I can do serious development with Gemini models is with other tooling (Cline, etc) that requires API based access which isn't available as part of the subscription.
I agree. Gemini models are held back by their segmentation of usage between multiple products, combined with their awful harnesses and tooling. Gemini cli, antigravity, Gemini code assist, Jules.... The list goes on. Each of these products has only a small limit and they must share usage.
It gets worse than that though. Most harnesses that are made to handle codex and Claude cannot handle Gemini 3.1 correctly. Google has trained Gemini 3.1 to return different json keys than most harnesses expect resulting in awful results and failure. (Based on me perusing multiple harness GitHub issues after Gemini 3.1 came out)
If you aggressively use all buckets Google is incredibly generous. In theory for one AI pro subscription you can get what is a ridiculous return in investment in a family plan.
You could probably be charging google literally thousands if all 6 members were spamming video and image generation and antigravity.
Bad generalization. I'm sure policy about this differs a lot, but my consumer ISP definitely reassigns my home's v4 address periodically. I don't track it closely, but it seems that when my ONT power cycles more often than not it pulls a new v4 address.
Now, basing my privacy/security on this would be bad, but to GP's point, if I was using a static v6 block, not only would this address never change, each device in my LAN would have an extra identifier attached to it. External hosts wouldn't merely be able to identify "my house", but traffic from "my phone", "my kid's switch", and "my spouse's phone" would all have distinct addresses.
Of course, my ISP doesn't do v6 at all, so there's no dilemma :')
That's why I specified if one was using a static v6 network. There are several reasons why this might not be true, from ipv6 CGNAT like what cell providers do, to ISP rotation, to randomization in your own network, to NATing from the private network if you wanted.
But it does seem like it would be far more likely de facto for an ISP to not randomly rotate v6 networks, except maybe to discourage hosting on consumer connections?
> using a static v6 block, not only would this address never change, each device in my LAN would have an extra identifier attached to it.
This is not true.
IPv6 stack allocates at least 3 addresses:
- Link-local
- "Permanent" Address derived from the subnet and MAC
- Temporary address that changes several times per day
The default address for new connections is always the temporary address. So IP-based tracking from outside your network will be no better than it was before from one day to the next—the /64 will be the only constant here, just as your router's WAN IPv4 is for v4 connections.
Ah, handy! Though it can't always be true, at least for manual configuration ;-) I have two VPSes with v6 addresses (the others don't have it configured...), and both only have LL and their permanent Internet addresses.
My understanding is v6 has two different autoconf schemes, DHCPv6 and a more "native" solution. Do these both always result in interfaces having multiple (routable) addresses?
Most of my IPv6 experience has been setting it up on aforementioned VPS, and being rewarded with slow OS updates, since NetBSD's default CDN, Fastly, blackholes PMTUD, so I had to drop the MTU on the interface just to get v6 TCP connections to work at all[0]. And for point-to-point networking in an overlay VPN, where I just discovered that Chromium has an 11-year outstanding "bug" where it refuses to perform AAAA lookups if you don't have public IPv6 routing.
[0] I could switch mirrors, but the bandwidth drop isn't quite bad enough for me to bother...
Man... I typed that reply on my phone and dropped the ball formatting it lol.
> My understanding is v6 has two different autoconf schemes, DHCPv6 and a more "native" solution. Do these both always result in interfaces having multiple (routable) addresses?
The answer to that is "yes," but only insofar as DHCP is _not_ the norm for IPv6 networks. If you're planning to use DHCP to assign network addresses in an IPv6 range, you would run it in addition to using automatic configuration, and DHCPv6 would be responsible only for the "permanent" IPv6 address. Automatically-configured addresses (via RA with SLAAC or whatever) would still create the temporary address that you'd use for outbound internet connectivity, and the DHCP address hangs around for your use in DNS and for hosting "permanent" services like a webserver or whatever.
You've hit on one of the subtler problems of IPv6 being that it requires more things being let through the edge firewall[0], but given a stateful IPv6 firewall on the client side, the onus is on the hosting service's admin to ensure that works correctly (AFAIK).
If you had v6, they'd probably also reassign your IPv6 prefix delegation, too.
Also, v6 supports "privacy extensions", essentially randomizing the host portion of the address and periodically rotating it, so it is not accurate to say your address would never change.
I'm sure this is true, and that there will always be a (likely disproportionately) loud group of complainers, many of whom will forget about their complaints. I haven't really publicly complained about Tahoe before, and I don't intend on whining about it again. But...
It's fine. I'm not going to rail about how it's unusable, or say that it makes me want to gouge out my eyes, or whatever. But it's enough to dissuade me from ever wanting to buy another Mac, if I have the option of using a desktop Linux system.
That's a pretty big caveat. But those curved window borders and the rounded widgets in e.g. the settings menu are kind of awful. Not unusable. But every time I open a terminal and I deal with the choice of either having obscene padding around my content or seeing a few pixels of my prompt's corners shaved off, I get just a little more irritated, and a little less likely to pick up my Macbook the next time I'm deciding which device to use.
Good UI for tools, physical or digitial, should reduce the friction between picking it up and using it for something, that's the problem at the core of design. With the small caveat that sometimes technically good but perhaps unethical design solves stupid business problems well, like deliberately making chairs uncomfortable to keep traffic moving through a busy cafe, or making anti-homeless benches, design should not dissuade you from using something you purchased to solve other problems; it's unprincipled.
When I was 20, I preordered a pixel 2 after watching the launch presentation from my university library. One of the "bonuses" for doing so was Google's new headset you put your phone in for a VR experience, along with a new controller.
This "Daydream" only lasted a few years (in software support), but it was a pretty good physical implementation of the "strap your phone to your face for budget VR" concept. I used it more than I'd care to admit for watching movies on a virtual big screen. It'd always give me a big headache between the eyes after an hour and a half, but it was fun every now and again.
A day at the fair.
It even convinced me to buy an Oculus CV1 when those were being heavily discounted!
I never ended up using the CV1 as much as my Daydream, which is saying something. The appeal of VR just isn't that great to me. It's something I find myself wanting to do maybe once or twice a year. Now, never, since the CV1 only ever worked well with Windows, and I can't be bothered to keep a Windows install exclusively for VR (I've tried and failed multiple times with the Linux runtimes).
Not nearly enough drive to deal with base stations, wires, or controllers. And even with the newest headsets that do away with all those, not worth the cash or effort to put on, or the space the headset takes up. Not for "once a month" trips to the fair.
It's insane to me that Meta dumped so much cash into VR. Their fever dream of working in VR gives me a sense of dread and migraine just thinking about it...
What this doesn't really address to me is why DR-DOS. That documentation uses a lot of flowery language to say nothing or close to nothing.
I'm too young to have used DR-DOS in anger (so I may be missing some key feature), but it seems like the entire point of DR-DOS would have been its source code legacy and accumulated feature set.
Here, my immediate question is why not FreeDOS? I'd guess it was system requirements, but according to the documentation DR-DOS 9 requires 2 MB of RAM minimum and a 386!!
I have used a DR-DOS 7 that was set up with a nice task switcher, between terminate-and-stay-resident programs ( not true concurrent processing ).
This setup started WP5.1, a spread sheet -- I think Lotus123, and a graphics editing program. I think it switches using cntrl and the F keys, similar in feel to how a linux machine switches consoles.
I think at the time this was set up, only DR-DOS could do the task switching. I don't know if that is still true.
I have to ask, since people who'd know will probably be here, what's the "ten thousand foot view" of Oberon today? I'm aware of the lineage from Pascal/Modula, and that it was a full OS written entirely in Oberon, sort of akin to a Smalltalk or Lisp machine image. What confuses me is the later work on Oberon seems to be something of a cross between a managed runtime like Java or dot net, and the Inferno OS, where it can both run hosted or "natively". Whenever I've skimmed the wikipedia or web pages I've been a bit confused.
reply