Hacker News Comments on
The Linux Programming Interface: A Linux and UNIX System Programming Handbook
Hacker News Stories and CommentsAll the comments and stories posted to Hacker News that reference this book.
If your goal is to become a "better" coder, doubling down on understanding the fundamentals rather than the specifics of a given language seems like an approach to consider.
That said, others here have recommended C instead or in addition to Rust or Go; this makes sense to me.
C is actively used and remains the lingua franca of low/system level programs (for the time being.) I'd also say that its relatively simple syntax and closeness to the underlying representation have a lot going for it (at least what you'd imagine the underlying assembly representation to be - hardware and clever compilers are doing a lot.)
The C language is simple, more than either Rust or Go, and can be picked up quickly, in my view. But actually understanding and using it competently is an altogether different matter.
Additionally, an absolute wealth of books introducing OS, drivers, and system and network programming topics using C exist. Projects like Xv6, Minix, and even Linux provide for code bases to run through and explore
- Computer Systems: A Programmer's Perspective 
- The Linux Programming Interface 
- Advanced Programming in the UNIX Environment 
- Dive into Systems 
And the list goes on and on.
You'll likely never write production code or push production projects in C (one hopes), but it seems to me that it remains a very useful language to be able to work with and to understand.
I don't have any one complete book that I can recommend, and I don't even really have a great reading list for this. But I'll make an attempt to share what I think is useful as a starting point.
1. Systems Operations is first and foremost about understanding systems, in all of their complexity, which means understanding the internals of your OS primarily.
2. Performance and networking, in particular, are super important areas to focus on understanding when it comes to learning the topic to help with software development.
3. A lot of it is about understanding concepts in abstract and being able to extrapolate to other situations and apply these concepts, so there's actually quite a lot of useful information that can be learned on one OS and still applied to another OS (or on one game engine and applied to another, et al).
Here's a few books I think are worth reading, not in any particular order of prevalence, but loosely categorized
High Performance MySQL: https://www.amazon.com/gp/product/1449314287/
SQL Queries for Mere Mortals: https://www.amazon.com/gp/product/0321992474/
The Art of SQL: https://www.amazon.com/gp/product/0596008945/
TCP/IP Illustrated: https://www.amazon.com/exec/obidos/ISBN=0201633469/wrichards... (updates on author's site at http://www.kohala.com/start/tcpipiv1.html)
The TCP/IP Guide: https://www.amazon.com/TCP-Guide-Comprehensive-Illustrated-P...
UNIX Network Programming: https://www.amazon.com/dp/0131411551
Beej's Guide to Network Programming: http://beej.us/guide/bgnet/
Operating Systems Concepts: https://www.amazon.com/Operating-System-Concepts-Abraham-Sil... (various editions, I have the 7th edition... I recommend you find the latest)
Modern Operating Systems: https://www.amazon.com/Modern-Operating-Systems-Andrew-Tanen... (the "Tanenbaum Book")
Operating Systems Design and Implementation: https://www.amazon.com/Operating-Systems-Design-Implementat-... (the other one, the "MINIX Book")
Part 2: https://www.amazon.com/Windows-Internals-Part-2-7th/dp/01354... (I had the pleasure of being taught from this book by Mark Russinovich and David Solomon at a previous employer, was an amazing class and these books are incredible resources even applied outside of Windows, we used 5th edition, I linked 7th, which has the 2nd part pending publication).
Linux Kernel Programming:
The Linux Programming Interface: https://www.amazon.com/Linux-Programming-Interface-System-Ha...
General Systems Administration:
Essential Systems Administration: https://www.amazon.com/gp/product/0596003439/
UNIX and Linux Systems Administration Handbook: https://www.amazon.com/UNIX-Linux-System-Administration-Hand...
The Linux Command Line and Shell Scripting Bible: https://www.amazon.com/Linux-Command-Shell-Scripting-Bible/d...
UNIX Shell Programming: https://www.amazon.com/Unix-Shell-Programming-Stephen-Kochan...
BASH Hackers Wiki: https://wiki.bash-hackers.org/
TLDP Advanced BASH Scripting Guide: https://tldp.org/LDP/abs/html/
The Debian Administrator's Handbook: https://debian-handbook.info/browse/stable/
TLDP Linux System Administrator's Guide: https://tldp.org/LDP/sag/html/index.html
Performance & Benchmarking:
Systems Performance: https://www.amazon.com/Systems-Performance-Brendan-Gregg-dp-... (this is Brendan Gregg's book where you learn about the magic of dtrace)
BPF Performance Tools: https://www.amazon.com/Performance-Tools-Addison-Wesley-Prof... (the newer Brendan Gregg book about BPF, stellar)
The Art of Computer Systems Performance Analysis: https://www.cse.wustl.edu/~jain/books/perfbook.htm (no longer available from Amazon, but is available direct from publisher. This is basically the one book you should read about creating and structuring benchmarks or performance tests)
I guess that's a "reading list", but this is just a small part of what you need to know to excel in systems operations.
I would say for the typical software developer writing web applications, the most important thing to know is how databases work and how networking works, since these are going to be the primary items affecting your application performance. But there's obviously topics not included in this list that are also worth understanding, such as browser/DOM internals, how caching and CDNs work, and web-specific optimizations that can be achievable with HTTP/2 or QUIC.
For the average software developer writing desktop applications, I'd say make sure you /really/ understand OS internals... at the base everything you do on a computer system is based on what the OS provides to you. Even though you are abstracted (possibly many layers) away from this, being able to peel back the layers and understand what's /really/ happening is essential to writing high-quality application code that is performant and secure, as well as making you a champ at debugging issues.
If you're trying to get into systems operations as a field, this is just a brush over the top surface and there's a lot deeper diving required.
⬐ planet-and-haloAppreciate the recs. Thanks very much for taking the time to write a detailed response.
I highly recommend this book: https://www.amazon.com/Linux-Programming-Interface-System-Ha...
All system call interfaces, as well as how system calls happen are thoroughly documented there. Though, I would just use libc, since all this stuff is a bit messy and have plenty of legacy stuff.
Please check "The C Interfaces and Implementations" book by David Hanson . Someone has implemented the concept using his library that you can check and use .
Another excellent reference is the "The Linux Programming Interface" book by Michael Kerrisk that documents most of the API available under Linux .
Assuming this... https://www.amazon.com/Linux-Programming-Interface-System-Ha...
As another resource, I just finished up the chapters of The Linux Application Programming Interface  that described this.
Highly recommend this book, its filled with fun tidbits of Linux-lore.
Maybe wrong Amazon page (or the store being down made it wonky), I see over 150 reviews. Very stellar response, I'm going to up my backing to get it now:
If you want to become a professional and not just a dabbler I would recommend reading some of the following books I have in my bookshelf:
 RHCSA & RHCE Training and Exam Preparation Guide by Asghar Ghori. This book will help insure you know your stuff as your system engineer/administrator wise.
 A Practical Guide to Linux Commands, Editor and Shell Programming Third Edition. This book will cover the majority of what you would need and want to know when connecting to a remote linux system over ssh.
If you want to get under the hood and become an expert, the following books should help get you started:
 Advanced Programming in the UNIX Environment
 The Linux Programming Interface: A Linux and UNIX System Programming Handbook
 Linux Kernel Development 3rd Edition
To get a nice general overview and get up and going quickly:
 How Linux works: What every superuser should know
 The Linux Command Line
 Python Crash Course
 Automate the boring stuff with Python. This is a great book to help you think about how to automate most of the repetitive things you will end up doing on a regular basis.
⬐ grepthisabThis looks like a gold mine! Thanks so much!⬐ iDemonixThe RHCSA/RHCE stuff is good, I passed the RHCSA a couple years ago and it's a solid set of foundations.
There's a good chat (devopschat.slack.com) that's useful for learning stuff like this.
I've really enjoyed the book The Linux Programming Interface by Kerrisk as a guide for learning some of these types of low level concepts.
Two alternative, and better, choices, if you're willing to spend a few dollars (and hopefully expense it to your manager):
The Linux Programming Interface: http://www.amazon.com/Linux-Programming-Interface-System-Han...
Advanced Programming in the UNIX Environment: http://www.amazon.com/Advanced-Programming-UNIX-Environment-...
A not-too-distant third choice, Linux System Programming: http://www.amazon.com/Linux-System-Programming-Talking-Direc...
⬐ ntumlinHow strongly do you recommend these books? Unfortunately I'm a college student without much cash to toss around, but I can scrape together enough for a book if it'll make me a better programmer in the long run.⬐ ereyes01⬐ ndesaulniersIf you want to learn what's one layer beneath the hood of most higher-level language environments, they are well worth the investment. And IMO this stuff is worth learning. One day, you will be glad to know it when you use strace to successfully debug why your application doesn't work, while the rest of your coworkers tear up more code in befuddlement :-)LPI is the way to go.
I just started doing kernel devlopment professionally, and ironically the content of LPI is relatively higher level.
Glad I read it before starting though.⬐ stplsdIn my opinion these are best two books on the subject. Stevens' book is classic and have been updated quite recently (3rd edition came out 3 years ago), LPI is very extensive and have some specific Linux info not present in Stevens' book and is clearly influenced by Stevens book.⬐ b3h3mothStevens is dead many years ago. The second and the third editions were written by Rago. He is a good author but he is not Stevens.
What really sets this book apart, in my opinion, is just how readable it is. I haven't run across anything with quite the same combination of style and depth for Linux.
You could read through something like The Linux Programming Interface  or Understanding the Linux Kernel  and with effort extract much of the same information, but without the pace/structure/commentary that I think this book does so well.
Thing is, conceptually much of what you'll read in this book will be applicable to Linux just fine and having read it will make it far easier to grok how/where the two differ.
Very nice summary.
I encountered many of these while reading through Understanding The Linux Kernel  and The Linux Programming Interface .
Both are great books which are primarily about the "how" of the kernel, but cover a lot of the "why" of the design and algorithms as well.
⬐ hhennWould you recommend those books to someone who is just familiar with the Linux command line and knows the basics of C? I want to start understanding the system I use everyday, in depth, but am not sure where to start.⬐ omegote⬐ arayI bought "Beginning Linux Programming" and I think it's a great book for beginner and intermediate C programmers looking to get a deeper knowledge of Linux. A bit basic if you've been working with C for some time tho.
After buying it I found The Linux Programming Interface... and I certainly regretted having bought the former rather than the later. But for beginners I recommend the first.I'd also add Love's Linux Kernel Development, published in 2010. Great resource overall for someone wanting to go developing the internals of the kernel.⬐ incisionYes.
I actually have that book as well. I don't know how I forget to mention it. As I recall, it was bit less dense than the other two.
Asking $30 for a book is shocking? I expect to pay at least that for a good technical book. This is a book I paid $60 for: http://www.amazon.com/Linux-Programming-Interface-System-Han... I did so because the information in it is relevant to my job, it's unlikely to change in a significant way over the next decade, and I was tired of not having a single place to look up Linux systems stuff.
If I was a web developer using Meteor, I imagine I would come to a similar conclusion about this book - with the exception that because it's online, the authors can update it over time.
⬐ ruswick"Asking $30 for a book is shocking?"
Where did you get that? He explicitly said that "if the information contained is proven to be valuable and well-expressed than yes, I agree, $39 (or even $99 or whatever) is totally worth it." He literally said the exact opposite of what you are alleging that he said. Literally.
His shock was in regards to the fact that the offer no sample chapter (which they probably should).⬐ publicfigI don't know why you think that they don't offer a sample chapter, as one of the only actions possible above the fold is to download a sample chapter from the book.⬐ laughfactory⬐ scott_sActually, I expressly did mention that they offer a sample chapter. I was suggesting that in addition to the sample chapter they might consider (if they want to keep the overall price where it is) selling the book in segments which cost less allowing those who are especially price-sensitive to test drive the content. E.g. Part 1 costs $10 and then the rest costs $29. Silly idea, but I just like to think about this kind of thing.⬐ publicfigI wasn't responding to you, I was responding to the parent comment above me that says "His shock was in regards to the fact that the offer no sample chapter (which they probably should)."I got it from: "So asking people to pony-up that kind of money is a little shocking."
I was confused by his phrasing. I thought he meant it was an unknown quantity because he had not read it.⬐ laughfactoryNow I'm getting confused. I agree that it was an unknown quantity before I began reading it.
The main point I was attempting to make is that some of those (perhaps a very small minority) interested in learning Meteor operate on very tight budgets. On a good month I get a $50 "allowance." Most months I don't get an allowance. This month my wife agreed to take the cost of the Discover Meteor book out of our grocery budget. So when things are that tight, $30 or $40 is a lot to swing. It's roughly 10% of our grocery budget (for context).
For those who make their living as web developers and have sufficient disposable income, I'm sure the asking price of $39 isn't a problem.
OK, if you don't have any real experience in low-level embedded coding (relevant to device drivers), RTOS or OS design in general, file systems, data structures, algorithms, interfaces, etc. And, if you have "hobby level" experience with Assembler, C and C++. And, if your intent is to write a desktop OS, from the ground up, without making use of existing technologies, drivers, file systems, memory management, POSIX, etc. Here's a list of books that could be considered required reading before you can really start to write specifications and code. Pick twenty of these and that might be a good start.
In no particular order:
54- ...well, I'll stop here.
Of course, the equivalent knowledge can be obtained by trial-and-error, which would take longer and might result in costly errors and imperfect design. The greater danger here is that a sole developer, without the feedback and interaction of even a small group of capable and experienced programmers could simply burn a lot of time repeating the mistakes made by those who have already trenched that territory.
If the goal is to write a small RTOS on a small but nicely-featured microcontroller, then the C books and the uC/OS book might be a good shove in the right direction. Things start getting complicated if you need to write such things as a full USB stack, PCIe subsystem, graphics drivers, etc.
⬐ tagadaThe guy don't want to write a perfectly designed OS, neither he wants to design a RTOS by the way ... He didn't even specify whether his OS would be multitask. If not, no need for any scheduling at all, huh ... he just "writes his own OS". It's a fun experience, very rich and very teaching. But at least now, we all can admire the wideness of all your "unlimited knowledge" especially in terms of titles of books. Afterall, no needs for creating a new OS, if you get all your inspiration from things that already exists. You will end with Yet Another Nix ... Not sure he wants a YanOS, though.
Without talking about filesystems, drivers, memory managment or existing norms and standards (which it seems he wants to avoid ... which is not that stupid ... all having been designed 40 years ago ... who knows maybe he'll have a revolutionary idea, beginning from scratch), going from scratch with no exact idea of where you go could be a good thing. Definitely. You solve the problem only when you face them. Step by step, sequentially. Very virile, man.
I would advice the guy to start obviously with the boot loader. Having a look at the code of GRUB (v1), LILO, or better yet, on graphical ones (BURG, GAG or this good one XOSL which is completely under GUI - mouse pointer, up to 1600x1200 screens, and many supported filesystems, written in ASM ... it could actually be a hacking basis for a basic OS on itself) could be a great source of inspiration, and beginning to play directly with the graphical environment.
You could also have a look on these things http://viralpatel.net/taj/tutorial/hello_world_bootloader.ph... and of course on Kolibri OS http://kolibrios.org/en/?p=Screenshots⬐ tagadaBlah, blah, blah ...
Better advice would be: Try, make mistakes, learn from them, continue.
Way, way, way less discouraging, pessimistic and above all pedantic.⬐ derefr> If the goal is to write a small RTOS on a small but nicely-featured microcontroller, then the C books and the uC/OS book might be a good shove in the right direction. Things start getting complicated if you need to write such things as a full USB stack, PCIe subsystem, graphics drivers, etc.
I've always wondered if there could be created some way to skip this step in [research] OS prototyping, by creating a shared library (exokernel?) of just drivers, while leaving the "design decisions" of the OS (system calls, memory management, scheduling, filesystems, &c.--you know, the things people get into OS development to play with) to the developer.
People already sort of do this by targeting an emulator like VirtualBox to begin with--by doing so, you only (initially) need one driver for each feature you want to add, and the emulator takes care of portability. But this approach can't be scaled up to a hypervisor (Xen) or KVM, because those expect their guest operating systems to also have relevant drivers for (at least some of) the hardware.
I'm wondering at this point if you could, say, fork Linux to strip it down to "just the drivers" to start such a project (possibly even continuing to merge in driver-related commits from upstream) or if this would be a meaningless proposition--how reliant are various drivers of an OS on OS kernel-level daemons that themselves rely on the particular implementation of OS process management, OS IPC, etc.? Could you code for the Linux driver-base without your project growing strongly isomorphic structures such as init, acpid, etc.?
Because, if you could--if the driver-base could just rely on a clean, standardized, exported C API from the rest of the kernel, then perhaps (and this is the starry-eyed dream of mine) we could move "hardware support development" to a separate project from "kernel development", and projects like HURD and Plan9 could "get off the ground" in terms of driver support.⬐ robomartinA lot depends on the platform. If the OS is for a WinTel motherboard it is one thing. If, however, the idea is to bypass driver development for a wide range of platforms it gets complicated.
In my experience one of the most painful aspects of bringing up an OS on a new platform is exactly this issue of drivers as well as file systems. A little google-ing quickly reveals that these are some of the areas where one might have to spend big bucks in the embedded world in order to license such modules as FFS (Flash File System) with wear leveling and other features as well as USB and networking stacks. Rolling your own as a solo developer or even a small team could very well fit into the definition of insanity. I have done a good chunk of a special purpose high-performance FFS. It was an all-absorbing project for months and, realistically, in the end, it did not match all of the capabilities of what could be had commercially.
This is where it is easy to justify moving into a more advanced platform in order to be able to leverage Embedded Linux. Here you get to benefit and leverage the work of tens of thousands of developers devoted to scratching very specific itches.
The down-side, of course, is that if what you need isn't implemented in the boad support package for the processor you happen to be working with, well, you are screwed. The idea that you can just write it yourself because it's Linux is only applicable if you or your team are well-versed in Linux dev at a low enough level. If that is not the case you are back to square one. If you have to go that route you have to hire an additional developer that knows this stuff inside out. That could mean $100K per year. So now your are, once again, back at square one: hiring a dev might actually be more exoensive than licensing a commercial OS with support, drivers, etc.
I was faced with exactly that conundrum a few years ago. We ended-up going with Windows CE (as ugly as that may sound). There are many reasons for that but the most compelling one may have been that we could identify an OEM board with the right I/O, features, form factor, price and full support for all of the drivers and subsystems we needed. In other words, we could focus on developing the actual product rather than having to dig deeper and deeper into low-level issues.
It'd be great if low level drivers could be universal and platform independent to the degree that they could be used as you suggest. Obviously VM-based platforms like Java can offer something like that so long as someone has done the low-level work for you. All that means is that you don't have to deal with the drivers.
To go a little further, part of the problem is that no standard interface exists to talk to chips. In other words, configuring and running a DVI transmitter, a serial port and a Bluetooth I/F are vastly different even when you might be doing some of the same things. Setting up data rates, clocks, etc. can be day and night from chip to chip.
I haven't really given it much thought. My knee-jerk reaction is that it would be very hard to crate a unified, discoverable, platform-independent mechanism to program chips. The closest one could possibly approach this idea would be if chip makers were expected to provide drivers written to a common interface. Well, not likely or practical.
Not an easy problem.⬐ derefr> It'd be great if low level drivers could be universal and platform independent to the degree that they could be used as you suggest. Obviously VM-based platforms like Java can offer something like that so long as someone has done the low-level work for you. All that means is that you don't have to deal with the drivers.
Another thought: if not just a package of drivers, then how stripped down (for the purpose of raw efficiency) could you make an operating system intended only to run an emulator (IA32, JVM, BEAM, whatever) for "your" operating system? Presumably you could strip away scheduling, memory security, etc. since the application VM could be handling those if it wanted to. Is there already a major project to do this for Linux?
The Linux Programming Interface by Kerrisk has pretty thorough coverage of sockets (and everything else).
Isn't Bovet & Cesati a bit out of date now? I used to have a copy, but it was published in 2005, which means it was probably written in 2004.
Also, it's not kernel-specific, but this book covers a lot of system programming concepts (expensive though):
The Linux Programming Interface: A Linux and UNIX System Programming Handbook