So much of practical CS is abiding by standards created by solo programmers in the past.
My university frowned on any industry-related classes (i.e. teaching software engineering tools vs. theoretical CS), but I was fortunate enough to know a passionate grad student who created a 1-credit seminar course on this exact topic.
This course covered CLIs/git/Unix/shell/IDEs/vim/emacs/regex/etc. and, although I had experience with Linux/git already, was invaluable to my early education (and adoption of Vim!).
It makes sense that this isn't a core topic, as a CS education should be as pure as possible, but when you're learning/building, you're forced to live within an operating system and architecture that are built on decades of trade-offs and technical debt.
Universities produce research, and students; Students produce industry, and the body politic; Industry and polity produce university funding.
A cycle I like to call, the "ring-bugger."
I'm not saying it's right, or acceptable, or particularly moral… But I agree that by obscuring the facts, we only serve to confound the decent and good-willed of our students.
If you've made it that far in life without learning how to use a screwdriver, engineering would be a bad choice of major. And paying insane amounts of money for someone to explain how to use one would be an even poorer choice.
Same reason I always wonder whether I should go for an electrician/mechanic/avion mechanic education if I'm laid off (and cannot find a job).
I'm really not a handyman -- quite the opposite -- it took me and my father 30 minutes to change the car battery last time -- and most of the time was spent on pushing a component dropped to the bottom out of the car. I used to think that more practices bring some sort of linear growth of the skill in the beginning, but now I tend to believe that for certain people (who are not suitable for the trade), the beginning is totally random -- I could practice 100 times and fail 100 tiles randomly, without really learning anything -- because there are an unlimited number of ways to do one thing, theoretically.
Software suits me way more. Soldering is also OK albeit more confusing. Unfortunately there is no trade that primarily deals with microcontrollers, except in military/defense.
I use TLPI as an optional text for my CS Operating Systems course! It's honestly the best resource for a comprehensive look at the innards of Linux. I actually even snip select pages for lectures.
People should do a foundation course to figure out which deprecated parts of the kernel source to avoid. It is nontrivial, but talking with the active developers will save a lot of guess work. =3
One of the greatest texts ever written. Ok maybe just one of my favorites. I wouldn't mind a 2nd edition though... surely the system call interface has changed a bit since 2010.
My favorite book about systems programming on UNIX systems is the book by the late Stevens, but this book more detailed, Linux-specific and if updated (after 16 years, in which Linux did not stand still), could steal the crown from Stevens.
I guess it is more appealing to current university students, than reading about UNIX Lion's commentary, Minix, BSD design, and other academix books with UNIX like implementations.
What a horrible selection for a university textbook! It doesn't get trivially updated every year to prevent reuse and reselling, so how is this supposed to generate more profit for the booksellers? /s
Seriously though, this book is fantastic, and far better than typical course textbooks. I'm honestly a little surprised that universities would select it.
My university frowned on any industry-related classes (i.e. teaching software engineering tools vs. theoretical CS), but I was fortunate enough to know a passionate grad student who created a 1-credit seminar course on this exact topic.
This course covered CLIs/git/Unix/shell/IDEs/vim/emacs/regex/etc. and, although I had experience with Linux/git already, was invaluable to my early education (and adoption of Vim!).
It makes sense that this isn't a core topic, as a CS education should be as pure as possible, but when you're learning/building, you're forced to live within an operating system and architecture that are built on decades of trade-offs and technical debt.
Industry demands specifically university degrees to gatekeep positions.
And then we leave teenagers to figure out the puzzle by themselves. I think it's a disservice to the youth.
A cycle I like to call, the "ring-bugger."
I'm not saying it's right, or acceptable, or particularly moral… But I agree that by obscuring the facts, we only serve to confound the decent and good-willed of our students.
Edit: derp.
I'm really not a handyman -- quite the opposite -- it took me and my father 30 minutes to change the car battery last time -- and most of the time was spent on pushing a component dropped to the bottom out of the car. I used to think that more practices bring some sort of linear growth of the skill in the beginning, but now I tend to believe that for certain people (who are not suitable for the trade), the beginning is totally random -- I could practice 100 times and fail 100 tiles randomly, without really learning anything -- because there are an unlimited number of ways to do one thing, theoretically.
Software suits me way more. Soldering is also OK albeit more confusing. Unfortunately there is no trade that primarily deals with microcontrollers, except in military/defense.
I don't think that's a good goal. Otherwise, why let you near a computer at all, and not restrict you to chalk and blackboards?
Introductory LFD103 is a free course:
https://training.linuxfoundation.org/training/a-beginners-gu...
Some channels to get some experience handling the modern kernel source:
https://www.youtube.com/@johannes4gnu_linux96/videos
https://www.youtube.com/@nirlichtman/videos
The syscall ABI itself is remarkably stable, backward compact is practically Linux's religion, but the conceptual model has shifted substantially.
Namespaces and cgroups went from obscure subsystems to the foundational abstraction containers run on.
io_uring rewrote the async I/O model.
eBPF changed how you think about observability and policy enforcement.
Seriously though, this book is fantastic, and far better than typical course textbooks. I'm honestly a little surprised that universities would select it.