I also disliked brutalist from spending too much time in Ontario University campuses which just did a boring job of brutalist. Then i visited the barbican in London and fell in love. There are very good examples of brutalist out there

Sounds a lot like SPIN OS https://en.wikipedia.org/wiki/SPIN_(operating_system) They have to make do without type safety (in SPIN's case provided by modula-3), but it's really cool to see it tried. For those interested: SPIN and other hybrid kernels (like Exo) were created in the fall-out of "microkernels are bad" by attempting to allow a hybrid approach. Linux was created around the same time staying straight in the monolithic category (but since moving to be more hybrid).

Out of the loop, why is Linux now "more hybrid"?

It provides some of the capabilities previously limited to microkernels in the past around the ability of an application domain to customize the kernel to fit its needs. You can see it in loadable kernel modules, user-space drivers which allow applications to control how they access hardware directly, and now loadable application code too which can run directly in the kernel. Hybrid hasn't been used to denote something that has a address space layout similar to a mkernel so much as it's being used to denote a monolithic operating system that has some capabilities previously only available in a mkernel.

Because it has a crap ton of drivers and shit in the kernel, which is the opposite of unikernel/microkernel approach where most of this functionality is implemented in userspace. See eg Minix

I think the question was how is it a microkernel at all

Many of the benefits of microkernels have been implemented in Linux over the past 25 years. Modules, FUSE, and live patching for example.

I don't understand kernel modules, dynamic-loaded or otherwise, to be any more or less monolithic (in the sense of monolithic versus micro kernels). Do they have their own address space or something?

kernel modules and BPF ....

arch linux ARM over yocto? come on.

I have never heard of yocto. Could you quickly explain why you prefer it to Arch ARM?

Arch ARM is basically a ready-to-go distro. Choose your board (if it's supported, download images, and burn them). Which sounds great, but in the embedded world, that gets kinda limiting very quickly. Using binaries on boards can suck. Pulling down random bootloaders off the internet and hoping one works isn't fun, and god forbid you need to debug the bootloader, now you need a compatible toolchain which you don't have.

In contrast to something like Buildroot, which is a set of config files and dependency matching scripts that allows you to compile your own tool chain, and build your custom software with the same tooling you compiled your target uboot/rootfs/kernel on. Buildroot was great for being able to compile your boot loaders, kernels, rootfs, apps... and it was simple to use. But supporting multiple boards deploying the same programs was difficult, and moving up versions of the kernel and things like that was also difficult.

Enter yocto. The sweet sweet glory of yocto. Yocto defines a common base layer of configuration scripts and uses a system called bitbake to build your recipes. (bitbake emerged from portage). On top of that base layer you add layers you need. A lot of arm manufacturers are in the openembedded alliance (which yocto is built on top of) so you'll find git repos from them supported just about every chip and SoC they make. so you pull that layer in. Then you browse the yocto repos for other layers you need to pull in, as well as develop your own layers containing your code. Cross-compilation is a snap, and most interestingly: their developer mode which puts you in a shell with a correctly configured environment so you can debug build breaks while cross compiling is amazing (and git aware)). So it's pluses are -tremendous board support -easy ability to migrate to boards that aren't supported (as easy as it can be anyhow) - ability to put your product code in one layer and just drag it into multiple yocto projects utilizing different board support layers allowing you to easily maintain your product on different processors. - It's the cleanest system I've seen that does what it does. And by cleanest, I mean a pretty big jump over it's predecessors into something unlike anything I'd ever seen in the embedded world. - It does have a harder learning curve than something like buildroot, which has a harder learning curve over something like Arch ARM (where Arch ARM supports your exact SoC)