First, I think this is a great idea, and I second your idea!
But, there's sort of a larger problem at stake here with operating systems, and that is the "archaeological WHY".
You see, the way Operating Systems classes are typically taught at university is that you are given an already working, already functional Operating System, which might be as "simple" (a term I use loosely, because it's relative) as Minix. (Minix is not simple compared to DOS, DOS is not simple compared to CP/M, etc.)
But the thing is, while you learn about the different parts of an already functional (multi-functional, because it has many functions) Operating System, you never really learn about the WHY, the reason why, the problem why all of that functionality, all of those systems and subsystems, were established in the first place.
In other words, let's say I have a computer with no OS. Bare metal. And I want the simplest piece of functionality to make my life a little bit easier, like let's say, a simple file system, the ability to run a C compiler, and the ability to use simple commands like "ls", "dir", etc.
Now, that ignores all sorts of other functionality, such as threads, multitasking, locks, IPC, sockets, memory management, GUI, etc., etc.
But, it would allow a greater understanding of the "archaeological WHY".
Once that understanding is firmly solidified, we could explore the next problem on our road to creating a modern, more complex OS. The WHY of that next problem, and the solution to it (increasing in complexity, but building commensurate understanding!) at every step.
>You never really learn about the WHY, the reason why,
This isn't just in Operating System, or Programming but Computer Technology in general. Unlike other Engineering courses from AeroSpace to Mechanical Engineering, which explains everything from basic theory to practice and how we evolve to current design and current ( likely slightly outdated ) industry practice.
But, there's sort of a larger problem at stake here with operating systems, and that is the "archaeological WHY".
You see, the way Operating Systems classes are typically taught at university is that you are given an already working, already functional Operating System, which might be as "simple" (a term I use loosely, because it's relative) as Minix. (Minix is not simple compared to DOS, DOS is not simple compared to CP/M, etc.)
But the thing is, while you learn about the different parts of an already functional (multi-functional, because it has many functions) Operating System, you never really learn about the WHY, the reason why, the problem why all of that functionality, all of those systems and subsystems, were established in the first place.
In other words, let's say I have a computer with no OS. Bare metal. And I want the simplest piece of functionality to make my life a little bit easier, like let's say, a simple file system, the ability to run a C compiler, and the ability to use simple commands like "ls", "dir", etc.
Now, that ignores all sorts of other functionality, such as threads, multitasking, locks, IPC, sockets, memory management, GUI, etc., etc.
But, it would allow a greater understanding of the "archaeological WHY".
Once that understanding is firmly solidified, we could explore the next problem on our road to creating a modern, more complex OS. The WHY of that next problem, and the solution to it (increasing in complexity, but building commensurate understanding!) at every step.
OK, I'm rambling!
But I like your idea and greatly endorse it!