The OS looks highly opinionated and I respect that. Better to have a single overarching vision than try to do too many things poorly.

However I will question some design choices!

- 32-bit only: the writing is on the wall, many vendors (HW&SW) are slowly moving to kill it off. I guess it's fine, but IMHO each ISA (regardless of pointer width) should just be considered a different ISA. Portability is good, it ensures your software doesn't hardcode too many assumptions about the platform - and weeds out bugs. Just treat an int like an int, and a pointer like a pointer. Distinct types.

- Pure co-op multitasking: it will be completely fine, until you try serious in-system development. Hard reboot any time I make a mistake in a for-loop? Mercy, please :,) Implementing a simple watchdog via a timer interrupt will still keep all of the scheduling logic simple and stupid: it's just another case for a yield call, except now involuntary. The runaway process will simply never see completion, but seeing that it would never yield anyway, I don't see a problem just killing it. And most importantly, the sanity shall be preserved.

Creator here!

Yes, the OS is highly opinionated, as just making another linux is incredibly boring for me!

The 32-bit only constraint is mainly due to my focus on smaller architectures, especially microcontrollers.

x86_64 and aarch64 both have much more complex initialiastion schemes, and also use much more complex page table setups.

Thus, i wanted to keep that out of the system, considering i'm targeting systems with a tiny fraction of the 4 GiB memory limit.

The co-op multitasking is a part of the OS, and the OS doesn't give you preemptive multitasking. I never said i won't implement sanity safeguards! Just killing off a hanging process that doesnt yield for more than 1-5 secs is totally i scope and increases user friendlyness. but considering the system reboots in 1.2 s on target hw right now, the user will maybe just have hit reset by then :D