[nyanpasu64]

Does studying toy operating systems teach strictly more, or just different skills, than studying bare-metal embedded frameworks like https://github.com/rsta2/circle (which powers https://github.com/dwhinham/mt32-pi, unlike Zynthian which is Linux-based (https://zynthian.org/#software))? I dropped out of uni before completing my OS course, and I planned to look into mt32-pi, but sadly struggled with hardware and software setup (game MIDIs wouldn't play right, and in terms of sound design, all the good MT-32 patch editors are for obsolete platforms and many are gone from the Internet).

[animal_spirits]

I took an operating systems course at Purdue in which we built the Xinu OS from (almost) scratch [1]. Almost all of us had no real experience with a _big_ project like this before, and the most important thing thing that I learned was how to be comfortable with a large system of different moving parts that all need to interop together. I learned a lot about how processes work, C memory management, and shells, but I don't ever use that in my day to day. It is fun to know kind of what is going on way behind the scenes when I'm using my computer, but knowing the low level datastructures really hasn't been practical for me while the big picture of the project impacted me greatly.

[1] https://xinu.cs.purdue.edu/

[saagarjha]

Though implementations differ, for any nontrivial task the problem of scheduling and resource allocation is a recurring theme and an important part of what an OS class “teaches”. But for many undergraduates an OS is also their first large project, perhaps one written in C. Really, there’s no “one” skill that a toy OS can offer, but anything in the area will give you a greater appreciation for how OSes in general might work and the problems they need to solve.

[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.