>you have got yourself a complete course in C/Unix programming which is the bedrock for everything else; C is the "lingua franca" and Unix (via its variants) the "standard" OS.

Somewhat over the top comment.

I may be an even stronger proponent of C and Unix than you, partly because I grew up on them, and partly because I like them, although they have their share of issues.

Still, calling them the bedrock and standard is too much. There are other alternatives. Until Android and IOS based systems boomed, Windows outnumbered Unix and Linux systems by a huge factor, which I cannot even estimate.

> Somewhat over the top comment. ... Still, calling them the bedrock and standard is too much.

Nope, i meant exactly what i said. The point is not popularity/commodity but understanding a domain from the foundations.

I am one of the oldies who started with (in chronological order) MS-DOS, a brief foray into Mainframe COBOL, 16-bit Windows (Windows 3.1) to 32-bit Windows (Windows NT 3.51 & 4), then to Solaris/Linux and all using C/C++. So i had actually programmed in Windows before Unix. There was only Dave Cutler's book on the Windows NT kernel then with everything else being only on programming the GUI subsystem (Charles Petzold and Jeffrey Richter were the notable ones) whereas in the Unix world you had Maurice Bach/Marshall Mckusick/etc. books explaining the kernel and Marc Rochkind/Richard Stevens/etc. explaining how to program it. I still remember reading the 1st edition of Rochkind's book (there were only around a dozen system calls then and the book was less than 200 pages i think) and understanding everything (Unix was a simple monolith then) while Windows was made up of a kernel+various subsystems and it was rather hard to understand what was what. And through it all C was the common "glue" lingua franca which allowed one to program all of them.

The above situation persists to this day in spite of the explosion of languages/OS/Architectures. A knowledge of C/Unix will allow you to understand and program any system be it bare-metal/kernel-level/app-level/system utilities. You may not need it at your job but a knowledge of C/Unix (you don't have to become an expert) will give you a solid bedrock to hang your higher level understanding on. It will also make your transition to other languages/OSes easier since you will have a good understanding of what is going on underneath.

Corrigendum: Consulting Rochkind's 2nd edition of AUP book it says; the 1st edition included about 70 system calls while the 2nd edition includes about 300 gleaned from SUS (https://en.wikipedia.org/wiki/Single_UNIX_Specification).

the first paragraph of your comment is in contradiction to the third.

so, i am not interested in discussing things further.

> the first paragraph of your comment is in contradiction to the third.

No.

I am not interested in explaining obvious facts either.

I bought the Stevens’ book sometime in the 90’s. I believe I still have it, but I haven’t opened it up in years or maybe even decades at this point, so my recollections might be a bit off.

The book predates important developments like epoll/kqueue, so is it really a good recommendation today? Are there more modern alternatives?

There is a 3rd edition of Steven's APUE published in 2013 but i am not sure whether it covers epoll/kqueue specifically (i don't have this edition). Most probably not since these are specific to Linux/BSD. Stevens/Rochkind only cover the base Unix apis for I/O multiplexing/Asynchronous I/O (select/poll/signals/aio apis) gleaned from SUS (See https://en.wikipedia.org/wiki/Single_UNIX_Specification). You would be better off consulting the specific documentation for these system calls in its OS reference and the various articles describing/comparing them online.

For a Linux specific alternative Michael Kerrisk's The Linux Programming Interface seems pretty good.