I have a book of the same name. I, reluctantly, recommend it.
Why recommend?: lots of great content surrounding networking and file access, most of which will improve your programs a lot, if you code the things I do.
Why reluctantly?: it is heavily dependent on libc. It may ruin you for other languages than C.
The posix programming interface happens to be the C library, so I'd be curious how a book on advanced unix system programming could not heavily depend on libc?
> The term "libc" is commonly used as a shorthand for the "standard C library", a library of standard functions that can be used by all C programs (and sometimes by programs in other languages).
I'd appreciate "even more so" over of "not exactly", as this confirms the point: Unix programming means to use the C library, even plus a bit (superset).
> I'd appreciate "even more so" over of "not exactly", as this confirms the point: Unix programming means to use the C library, even plus a bit (superset).
Your claim is wrong, on a factual level. "The posix programming interface" is not "the C library". So no, not "even more so".
> Unix programming means to use the C library, even plus a bit
This was not what you claimed, and it is entirely possible to write a C program that only uses the POSIX specific functions and avoids any of the functions in the C standard library. It won't do much, but it will run to completion.
I've used this book to prove to my kids that, at one time, I may have done something useful because: it has my name in it (by sheer dumb luck I might add).
I was going to say I don't remember, but thanks to the longevity of RFC822 email, the thread to do with this is still in my mailbox. It looks like I reviewed the chapter on dbm. I also found, in searching for these emails, that an editor at PH reached out to me in 2008 asking for review help with the 3rd edition. As far as I can tell I never saw that email and didn't reply <doh!>.
It's down right now, but I guess it is related to Stevens's APUE? A masterful book. I'd love to see it updated for newer kernel interfaces, seccomp etc.
I wasn't excluding the BSDs there, Stevens would definitely have covered dtrace, ZFS, Capsicum etc. But I hope that the Solaris/SysV specific stuff could be put in a forbidden appendix. No more ipcs please!
Care to give a link or context for "no more ipcs"? SysV shared mem is IMO a straightforward, robust low-level (MMU-level) IPC mechanism for CPU-bound tasks compared to memory-mapped I/O and the PITA that are threads, but admittedly I'm not up to date on this topic.
Mainly the cleanup problem. Determining if something is a live resource is tedious. Numeric IDs are inferior to paths IME, especially from a kernel ABI filtering perspective.
>"robust low-level (MMU-level) IPC mechanism for CPU-bound tasks compared to memory-mapped I/O ..."
Could you elaborate on what makes IPCS more suited to CPU-bound tasks vs mmap? Sys V ipcs has always kind of eluded me. I think my exposure to it was mostly via Oracle Databases way back when. Cheers.
Explicit shared read + exclusive write locks without resorting to atomic primitives (though that could also be seen as a disadvantage depending on your task).
This is based on the book by the same name, but has lectures to go along with it. Looks nice. I wish there were lectures to go along with Michael Kerrisk's book The Linux Programming Interface.
I subscribe to O'Reilly's video course program, and I've recently been watching Kirk McKusick's course on the design of FreeBSD which is one of the best OS courses I've ever come across.
He has one on his website that costs a lot, but the one on O'Reilly only costs as much as a subscription to their service. It's a less in-depth version of the one on his site.
Did not take that particular class, but loved taking the equivalent at my university when I was a student. I highly recommend taking this type of class to anyone who wants to understand what happens on a low level, but not down to the OS internals level. Systems programming.
The list goes on, but at the end of the day, basically all higher level constructs boil down to these system primitives. Understand these, and you have a much better foundation to understand high level concepts built on top of them.
Did not expect to see this on the front page of HN - I'm nearly finished my MS at Stevens and have this class planned for next fall - really looking forward to it.
I took this class! It was very fun and Jan's a great instructor. Writing an HTTP server in C was probably the most illuminating project I did during my undergrad.
jschauma's been doing this for a while: I took this course about 15 years ago! It was one of the two most challenging, rewarding courses in my undergrad degree. I still apply things I learned from it daily.
Highly, highly recommended if you want to work in SRE or system-focused programming.
Dan Duchamp's CS 521 TCP/IP Networking -- he had us implement low-level protocols like DNS and TCP/IP from scratch, in C. Brutal, but exceptionally rewarding.
44 comments
[ 3.5 ms ] story [ 89.2 ms ] threadWhy recommend?: lots of great content surrounding networking and file access, most of which will improve your programs a lot, if you code the things I do.
Why reluctantly?: it is heavily dependent on libc. It may ruin you for other languages than C.
Most of the libc shims suck.
/old man yelling at cloud mode on: do kids these days really need to look up who wrote Advanced Programming in the Unix Environment??
PS — I also use it on Linux via GNUstep. I like it that much. :)
musl is an implementation of libc. So if you are using libc, then yeah sure why not.
I was wondering whether there was something different than the standard library which made C a joy.
Things that people mention as being faster are non-null terminated string libraries. Not sure if such would also make a more expressive API
Not exactly, the POSIX API is a superset of the C standard library.
https://man7.org/linux/man-pages/man7/libc.7.html
> The term "libc" is commonly used as a shorthand for the "standard C library", a library of standard functions that can be used by all C programs (and sometimes by programs in other languages).
https://en.wikipedia.org/wiki/C_standard_library
> Starting from the original ANSI C standard, it was developed at the same time as the C library POSIX specification, which is a superset of it.
Thanks for adding nuance and dental.
Your claim is wrong, on a factual level. "The posix programming interface" is not "the C library". So no, not "even more so".
> Unix programming means to use the C library, even plus a bit
This was not what you claimed, and it is entirely possible to write a C program that only uses the POSIX specific functions and avoids any of the functions in the C standard library. It won't do much, but it will run to completion.
What did you do, if I may ask?
https://webcache.googleusercontent.com/search?q=cache:Y56fxQ...
I wasn't excluding the BSDs there, Stevens would definitely have covered dtrace, ZFS, Capsicum etc. But I hope that the Solaris/SysV specific stuff could be put in a forbidden appendix. No more ipcs please!
Could you elaborate on what makes IPCS more suited to CPU-bound tasks vs mmap? Sys V ipcs has always kind of eluded me. I think my exposure to it was mostly via Oracle Databases way back when. Cheers.
I subscribe to O'Reilly's video course program, and I've recently been watching Kirk McKusick's course on the design of FreeBSD which is one of the best OS courses I've ever come across.
Wow, that is one pricey course. Are you watching it out of personal interest or because you need it for something in particular?
https://learning.oreilly.com/videos/introduction-to-the/9780...
[1] https://news.ycombinator.com/item?id=22799753
Threads, processes, shared memory, synchronized access, pipes, file descriptors, ...
The list goes on, but at the end of the day, basically all higher level constructs boil down to these system primitives. Understand these, and you have a much better foundation to understand high level concepts built on top of them.
The best references to learn Unix (and TCP/IP and networking) are still William Rich Stevens books.
Other courses/sources that I found very useful:
http://www.cs.cornell.edu/courses/cs114/2003fa/
http://www.cs.cornell.edu/courses/cs214/2004sp/
http://boris.lk.net/unix/
https://www.cl.cam.ac.uk/teaching/1011/UnixTools/notes.pdf
https://dasher.wustl.edu/chem430/readings/unix-tutorial.pdf
Highly, highly recommended if you want to work in SRE or system-focused programming.
which was the other?
https://www.youtube.com/watch?v=3H7SQWTR6Dw
cough cough
And the answer is... both!