I bet we're going to see a lot more of this. UNIX kernels have dominated computing use cases outside of desktops for a long time more because they conveniently come with free source code than because they are a great design. Now AI makes it so easy to experiment, I hope we'll see a new era of exploration in OS and framework design. We're already seeing the start of this with Omarchy but it's baby steps and not focused on the lowest levels. The stark differences between NT, XNU, SeL4 and Linux show there's plenty of room for differentiation at the bottom, and (other than SeL4) those are all still very similar due to commercial pressures.
> We're already seeing the start of this with Omarchy
This is where you lost me.
Omarchy is stock Linux with vibe coded config files.
If we were seeing experimental kernel designs, new memory management, abstraction layers over GPUs and TPUs baked in as OS primitives than as device drivers, and so on, I'd get excited.
But AI slop propagated by a fascist with an obvious and stupid agenda? No. That's not an example of something interesting.
Omarchy? the arch-deviated, vibe-coded, dark-money, techno-fascist wet-dream famous for pushing unstable updates that break the system - is that really what you want to use as an example for actual thoughtful work that a reliable kernel needs ? Common now, dude.
Eh, most device interactions are mostly "build a command list and shared memory buffers" rather than the classic touch a a bunch of registers to perform the data plane work. UARTs are one of the last bastion of the old style, mostly because of how you want them so early in the boot process for debug out, it's nice to not have a shared memory/command list access pattern.
That being said, I've even seen it for UARTs on microcontrollers where they're hoping to not have FIFO block RAMs taking up area dedicated to UARTs that might not even be enabled. There you have a absoute minimal staging buffers in the UART, and a fairly reconfigurable DMA controller to allow you to use sharable main RAM instead.
Embedded Swift is honestly very cool. I never really used Swift itself before, but I think it's a good niche since embedded dev could stand for another tool and the language is pretty nice. It also doesn't really suffer from most of the issues people have historically brought up with Swift (cross platform, slow compiles) etc as it is so small, at least to me. :)
If you're starting from scratch I've found you can actually write ~everything in Swift quite easily (reset vectors, compiler emitted intrinsics, etc). But beyond that I think the best feature is that the C/C++ interop works really well and comes out of the box. Makes two-way adoption easy. I wrote a small boot firmware for a simulator and for fun decided to add signatures to the boot process (mldsa44+jq255). You can just copy the .c and .h files and import them into a modulemap file and you're off to the races. You can just get simple .o files and pass them to the linker. There are only 4-5 "freestanding" functions you have to implement. You can turn off heap allocation. Etc.
It would probably be pretty cool and quite easy for instance to write Zephyr or U-Boot drivers, etc in Swift using these techniques.
This is where you lost me.
Omarchy is stock Linux with vibe coded config files.
If we were seeing experimental kernel designs, new memory management, abstraction layers over GPUs and TPUs baked in as OS primitives than as device drivers, and so on, I'd get excited.
But AI slop propagated by a fascist with an obvious and stupid agenda? No. That's not an example of something interesting.
In fact, that's how i/o worked before DMA on many systems. Good times!
That being said, I've even seen it for UARTs on microcontrollers where they're hoping to not have FIFO block RAMs taking up area dedicated to UARTs that might not even be enabled. There you have a absoute minimal staging buffers in the UART, and a fairly reconfigurable DMA controller to allow you to use sharable main RAM instead.
If you're starting from scratch I've found you can actually write ~everything in Swift quite easily (reset vectors, compiler emitted intrinsics, etc). But beyond that I think the best feature is that the C/C++ interop works really well and comes out of the box. Makes two-way adoption easy. I wrote a small boot firmware for a simulator and for fun decided to add signatures to the boot process (mldsa44+jq255). You can just copy the .c and .h files and import them into a modulemap file and you're off to the races. You can just get simple .o files and pass them to the linker. There are only 4-5 "freestanding" functions you have to implement. You can turn off heap allocation. Etc.
It would probably be pretty cool and quite easy for instance to write Zephyr or U-Boot drivers, etc in Swift using these techniques.
if you want a serious challenge, try making some drivers
“Hack the Planet!”? “Mess with the best die like the rest”? WTF?