The candidate titles were:
1. Linux System and Network ProgrammingThis is what happened.
2. Linux/UNIX System and Network Programming
3. Linux and UNIX System Programming
4. The Craft of Linux Programming
5. Advanced Programming in the Linux Environment
6. Something else?
1. Linux System and Network Programming
This was my original working title, conceived in a time when I planned to write a smaller book in which the network programming component would be a substantial portion of the book.
This title got almost no votes, and a number of negative responses from my tech reviewers. Those responses were generally along the lines: "networking is an important part of the book, but just a small part of a book that covers many APIs". This was exactly the reason why I had already decided that I didn't much like this title, and the feedback was enough to confirm to me that this was not the right title.
2. Linux/UNIX System and Network Programming
This scored only negative votes, which was no surprise to me (I only included it for the purposes of shoehorning "UNIX" into the previous title, to see if that got any positive response).
Two down.
3. Linux and UNIX System Programming
This title got several solid votes from a few people, including a few of my key reviewers, and no one had strong reservations.
The virtue of this title is its simplicity, and that it captures key points: Linux, UNIX (and thus portability), and system programming.
Some people agreed with me that this title is solid.
And some agreed that it's a little bland; the title lacks distinction. As Bill O. Gallmeister wrote:
And you could substitute the word "UNIX" for "Linux" in the above paragraph, and the argument would also hold. (There already exist several books that use "UNIX System Programming" in their titles.)The problem with many of the Linux programming book titles, in my opinion, is they run together. I guess that's just because there are a lot of them. Some combination of the words Linux, System, Programming, Network, Kernel, Advanced...
The conservative in me said: solid is good; bland is not fatal. However, when I factored in the crowded namespace, I was left with the feeling that while I could live with this title, I was not really convinced by it.
Two down, one left standing (just).
4. The Craft of Linux Programming
Titles 4 and 5 got the most votes. Among other things, this said to me that many people are interested primarily in Linux, and don't need to see UNIX in the title.
I concluded that one reason why people like title 4 is that it is distinctive. (This was one reason that title 4 was for a long time my favorite.) Title 4 also got several responses along the lines that the title was "soft" and "vague" ("I'm not quite sure from this title what your book is about"). I take their point. This is a significant weakness of the title. And in the end, I decided the weakness was fatal.
Three down, one left standing (just).
5. Advanced Programming in the Linux Environment
This title kept surprising me with its level of positive response. It got about as many positive votes as title 4.
I take the strong positive vote for this title as meaning this:
- From my tech reviewers: a strong vote of confidence in the quality of what they have read.
- From others (and perhaps some technical reviewers as well): a desire to see a book that is near the quality of Advanced Programming in the UNIX Environment (a quality sustained by Steve Rago in the second edition), but focused on Linux.
- The titles APLE and APUE would just be too close. Some people will get confused by the closeness. (One person noted that this might be to my benefit!)
- The title suggests my book is a clone of APUE, which isn't accurate. I cover many subjects that aren't in APUE and give special focus to a particular UNIX implementation.
- While I like the notion of acknowledging the brilliance of Rich Stevens book(s) with a play on his title, in the end, the closeness of the titles was just too great for me to feel comfortable.
6. Something else?
This is the virtue of the FOSS approach: use other people's good ideas.
In among several lengthy mails I got, there was one from a friend and former colleague, Alejandro Forero Cuervo. Alejo offered some short and incisive criticisms of my five candidate titles, and then did a nice analysis to come up with an alternative:
It took me a day or so of reflection, but then I decided that I really liked The Linux Programming Interface as a title:You want to convey very briefly what your book is about. In a few words I would say the book is about the abstractions provided in Linux, and to some extent other UNIX systems, that one needs to know to effectively develop applications (daemons, command line tools, networking clients, etc.). I think the word "Programming" very appropriately conveys part of that (rather than things like "Software development" or such). Also, something remarkable about your book is, I think, that it provides very complete coverage of the topics it touches on. That is, your book isn't just a short leaflet on where to look for what, but rather provides *everything* one should need to know.
Programming in Linux. Is this title taken? I quite like it. It emphasizes the scope of your book: you're publishing the best book for how to program in Linux so far. The title has the beauty of being simple and acknowledges that your book will be, probably for a long time (if not ever) the best book about how to program in Linux. A variation of this could be Linux Programming.
The Linux Programming Interface. This very precisely matches the topic of the book, right? I think it very briefly conveys entirely what the book is about. Of all the titles, this would probably be the one I'd choose.
- It's short and elegant.
- It's distinctive.
- As Alejo noted, it succinctly captures the essence of the book.
But, there seemed to be some downsides to this title:
- It doesn't mention UNIX.
- It doesn't mention System Programming, which is a term some people might search on.
There is for me a positive aspect in focusing on just Linux in the title: it is because of Linux (a free UNIX) that I am writing this book, and indeed it may even be because of Linux that I'm still in computing. And then, Linux is becoming by a margin the most popular UNIX. Focusing on Linux in the title is an acknowledgement of these facts.
On the other hand, UNIX is what got us here (and where I started learning), and I do like history and acknowledging origins. And of course, my book devotes quite a lot of space to portability across contemporary UNIX implementations.
I decided that UNIX must be kept somehow, but the way to do this was is in a subtitle.
The lack of the word System in the title also bothered me, since the term System Programming is commonly applied to programming with the interfaces that this book is about. So, I leaned toward an alternative title: The Linux System Programming Interface. I reasoned that this was nearly as short and elegant as the other title, was still somewhat distinctive, and was a helpful indicator for those people who might not be sure which interface was being referred to.
I asked a few people who had sent more detailed responses on the other titles for their thoughts about these two new titles. The response was generally very positive, but there was no clear winner between the two versions.
As I reflected on this further, I began to wonder whether adding System to the title did indeed detract too much from its simplicity and elegance. (Alejo was quite certain that the word System was not needed.) And so I began to lean back towards Alejo's initial proposal, and consider whether we could preserve the words System Programming in the subtitle. What finally confirmed things for me was the belief of my publisher, Bill Pollock, that the shorter title is better.
So there we have it: The Linux Programming Interface, with a subtitle that will include the terms UNIX and System Programming.
Updated, 2009-10-08: fixed an incorrect hyperlink
It's an excellent title--short, sweet, and to the point. Linux at this point in time is a tremendous superset of Unix. I can't wait to see the book!
ReplyDeleteNice title. So, when can we buy the thing :-) ?
ReplyDeleteI like the title. I hope to see the book soon. Cheers.
ReplyDeleteThe Linux Programming Interface is brilliant as a title. I can't wait to buy the book either.
ReplyDeleteI do have one concern after reading the TOC -- each interface may be discussed in depth but the fact that some interfaces are commonly used together to solve a problem may not be apparent.
For example, the Why Userspace Sucks talk from OLS 2006 complained about applications opening and stating a lot of files. mmap(2) may be discussed in depth in the book but novices probably would not come up with using a mmap'ed cache to avoid touching the small files.
Another example, if you're using realtime scheduling you likely want atomic operations for implementing lock-less data structures and other facilities mentioned in the What YOU need to know about Practical Real-Time Programming talk from openBossa 2009 so mentioning GCC's __sync_ atomic builtins somewhere close to scheduling priorities may help.
@Scott Tsai: Thanks! Regarding stat: the problem here is that there are very many silly things one *can* do in userspace. It's impossible to cover them all. Regarding RT: my coverage of the topic is fairly brief. There is really very much that could be said. Maybe in a future edition...
ReplyDeleteIndeed, nice title. I like it! Keep up with the good work!
ReplyDeleteI need this book now. (I am working on a grad poject due by May.) I was gonna buy it at O'Reilly until I saw it wasn't avail, and no advance e-book like I have done before.
ReplyDeleteAny work-around? "Understanding the Linux Kernel" is just too outdated for my file systems project.
Maybe you could recommend something more recent?
@Jeff: The comparison with ULK is a little surprising. My book and ULK cover topics that have little overlap. Briefly, ULK describes what goes on inside the kernel, while my book describes the interface that the kernel presents to the outside world. In looking for a recommendation, it would help if you could explain in more detail what information you are looking for.
ReplyDeleteI have sent details in an email, from an address off of the man pages site as it is a little long winded for a blog post. But it looks like I will be needing both books, I am still sorting out what goes where in this project.
ReplyDeleteBTW, Thanks for all your work on man pages. Invaluable and often so taken for granted in this gui addicted generation