[a-dub]

toy operating systems allow for more depth in the assignments, where working with real-world software systems with real world complexity requires ramping up.

when i took operating systems, we extended linux with an eye to building reliable systems (we built stuff like fault injectors for syscalls) as that was where the professor's graduate work had been and made various toy modifications to actual linux subsystems.

maybe folks working with nachos or one of these other toy operating systems get more topical depth (implement a scheduler or vm subsystem from scratch or such), but i personally found the experience of making real modifications to linux to be both more interesting and rewarding. (although many in the course struggled)

[nyanpasu64]

No, I meant is it better to teach or learn an OS, than a single-ring platform (about as minimal as a toy OS compared to Linux) where all code runs in the same address space, and scheduling is written by the user if present at all?

[a-dub]

personally i'd probably prefer an os unless i was trying to learn device programming specifically. if you're playing with things like scheduler policies, vm strategies or networking, you probably want the all of the tooling that is available on full blown multiprocessing operating systems to generate/simulate workloads and test your strategies under real world conditions.

if you're aiming to be an embedded person someday on things like scada and such, or are interested in reverse engineering old hardware and systems and care a lot about device interfaces, them maybe one of these operating system as library frameworks would be a better choice.

depends what your goals are i guess.