The bigger problem appears that CS programs now focus on teaching tools and how to Google as opposed to thinking or problem solving, in order to meet perceived industry demand. In industry, I've had to teach too many youngling graduates about basic data structure and database concepts, memory and hardware addressing, protocol encapsulation, AAA, synchronous vs asynchronous operation, and other fundamentals which would be needed to understand why things such as kernels are implemented as they are. The way in which FOSS support forums and listservs generally respond to noob developer and user questions--some variation of RTFS without providing a way of understanding which documentation to read--does not invite exploration of concepts embedded in the current software architecture, let alone ways to identify entry points into interesting sub-components. This is a barrier since popular CS program tools to which students are exposed, such as RHEL, gcc, etc. are provided as finished products in the same way as Access or BOS.
Separately, I have a dream where all of the Alans Cox get together to write an operating system.
Amen to not teaching problem solving, that is the case I see coming forward in my daughter's education. Training is not concentrated on developing learning and problem solving skills, it is more training on how to use the 'current' tools. Many do not fully comprehend data structures and in the case of C/C++ pointers and how they are perceived at the lowest level in computer memory (for that matter many course instructors I have run across, teach the language, nothing more). Fact is, java, python, PERL, and languages like them, are actually higher level interpreted languages, which some more than others further isolate the new guy/girl from the lower level workings of such languages. The fact is, there has got to be coders that know and understand how to do those things as well, they are the ones that write the software average joe/jill uses. Most (JMO) younger people do not have the skill nor the patience and persistence to learn how these systems actually work. The long list of error messages from a compiler, is intimidating, so the actual knowledge is bypassed in favor of something that is easier to comprehend and understand.
The first rule of intelligent tinkering is to save all the parts. -- Paul Erlich