2016-10-27

New Zealand Open Source Awards 2016 Special Prize

This is nice! For my work on the Linux man-pages project over the last 16 years, I was this week awarded the New Zealand Open Source Awards 2016 Special Prize (tweet, announcement on the NZOSA website). A video of the award announcement and my prerecorded acceptance speech is available on YouTube.

2016-10-22

Getting ready to say goodbye to some old friends

Anyone who spent time around me in the 2000s will have an idea of what the picture below is about.

As I wrote newer chapters TLPI, I constantly reread chapters that I'd already written, red pen in hand. For years, I'd always have printed copies of a couple of chapters nearby to review, to fill spare moments while I was commuting, waiting for something, or just sitting in the Biergarten on a sunny weekend afternoon.

Each chapter got printed anything from around 6 to 12 times, and typically I'd read each printed copy twice, so that I could better detect ordering and forward-reference issues in the text. So, by the time the book was published, I'd read drafts of each chapter around  12 to 20 times. After reviewing each printed draft, I'd then integrate changes and improvements (sometimes informed by what I'd learned during the writing of later chapters) into the text.

I kept all those printed copies, in part because I wanted to get an idea of how some chapters progressed over time. All of the printed copies are sitting in the pile in the photo. Well, nearly all; after that photo was taken, I discovered another 15cm pile that was still sitting in my hometown in New Zealand.

Because those printouts were my constant companion for such a long time, and the writing of the book was so central to my life for a long time, I haven't quite been able to bring myself to let them go. So, for the last few years, the chapters have been sitting in three banana cartons. But, they have to go out sometime, and I think I'm nearly ready to let them go, though I'll probably keep drafts of a few chapters just as reminders.

2016-10-09

Seventh print run of TLPI

The files for the seventh print run of The Linux Programming Interface are heading off to the printer about now. The changes since the last print run are few: just 15 fixes (all minor) were required for this print run.

2016-10-06

Traditional Chinese translation of TLPI is published this month

The Traditional Chinese translation of TLPI this month. This brings the number of translations of TLPI to four!

The translation is published in two volumes (1, 2) by Taiwanese publisher, GOTOP. My special thanks to Aaron MingYi Liao (廖明沂), who has worked very diligently and for a long time over the translation.

2015-11-19

Next Linux/UNIX System Programming course in Munich, 15-19 February, 2016

I've scheduled a further 5-day Linux/UNIX System Programming course to take place in Munich, Germany, for the week of 15-19 February 2016.

The course is intended for programmers developing system-level, embedded, or network applications for Linux and UNIX systems, or programmers porting such applications from other operating systems (e.g., Windows) to Linux or UNIX. The course is based on my book, The Linux Programming Interface (TLPI), and covers topics such as low-level file I/O; signals and timers; creating processes and executing programs; POSIX threads programming; interprocess communication (pipes, FIFOs, message queues, semaphores, shared memory), and network programming (sockets).
     
The course has a lecture+lab format, and devotes substantial time to working on some carefully chosen programming exercises that put the "theory" into practice. Students receive printed and electronic copies of TLPI, along with a 600-page course book that includes all slides and exercises presented in the course. A reading knowledge of C is assumed; no previous system programming experience is needed.

Some useful links for anyone interested in the course:
Questions about the course? Email me via training@man7.org.

2015-09-03

Sixth print run of TLPI

The files for the sixth print run of The Linux Programming Interface go off to the printer this week. The stream of error reports seems to have quietened down very much now, so that just 16 fixes (all minor) were required for this print run.

2015-06-16

Next Linux/UNIX System Programming course scheduled, Munich, September 2015

I've scheduled a further 5-day Linux/UNIX System Programming course to take place in Munich, Germany, for the week of 14-18 September 2015.

The course is intended for programmers developing system-level, embedded, or network applications for Linux and UNIX systems, or programmers porting such applications from other operating systems (e.g., Windows) to Linux or UNIX. The course is based on my book, The Linux Programming Interface (TLPI), and covers topics such as low-level file I/O; signals and timers; creating processes and executing programs; POSIX threads programming; interprocess communication (pipes, FIFOs, message queues, semaphores, shared memory), and network programming (sockets).
     
The course has a lecture+lab format, and devotes substantial time to working on some carefully chosen programming exercises that put the "theory" into practice. Students receive printed and electronic copies of TLPI, along with a 600-page course book that includes all slides presented in the course. A reading knowledge of C is assumed; no previous system programming experience is needed.

Some useful links for anyone interested in the course:
Questions about the course? Email me via training@man7.org.

2014-09-30

TLPI fifth print run

The files for the fifth printing of The Linux Programming Interface went to the printer a few weeks ago, and I expect it will soon be available via retailers. Thanks to all those who submitted errata that were incorporated in this print run.

2014-07-23

Linux/UNIX System Programming course scheduled for October

I've scheduled a further 5-day Linux/UNIX System Programming course to take place in Munich, Germany, for the week of 6-10 October 2014.

The course is intended for programmers developing system-level, embedded, or network applications for Linux and UNIX systems, or programmers porting such applications from other operating systems (e.g., Windows) to Linux or UNIX. The course is based on my book, The Linux Programming Interface (TLPI), and covers topics such as low-level file I/O; signals and timers; creating processes and executing programs; POSIX threads programming; interprocess communication (pipes, FIFOs, message queues, semaphores, shared memory),  network programming (sockets), and server design.
     
The course has a lecture+lab format, and devotes substantial time to working on some carefully chosen programming exercises that put the "theory" into practice. Students receive a copy of TLPI, along with a 600-page course book containing the more than 1000 slides that are used in the course. A reading knowledge of C is assumed; no previous system programming experience is needed.

Some useful links for anyone interested in the course:
Questions about the course? Email me via training@man7.org.

2014-06-05

Linux/UNIX System Programming course in July

I've scheduled a further 5-day Linux/UNIX System Programming course to take place in Munich, Germany, for the week of 21-25 July 2014.

The course is intended for programmers developing system-level, embedded, or network applications for Linux and UNIX systems, or programmers porting such applications from other operating systems (e.g., Windows) to Linux or UNIX. The course is based on my book, The Linux Programming Interface (TLPI), and covers topics such as low-level file I/O; signals and timers; creating processes and executing programs; POSIX threads programming; interprocess communication (pipes, FIFOs, message queues, semaphores, shared memory),  network programming (sockets), and server design.
     
The course has a lecture+lab format, and devotes substantial time to working on some carefully chosen programming exercises that put the "theory" into practice. Students receive a copy of TLPI, along with a 600-page course book containing the more than 1000 slides that are used in the course. A reading knowledge of C is assumed; no previous system programming experience is needed.

Some useful links for anyone interested in the course:
Questions about the course? Email me via training@man7.org.

2014-02-19

Further Linux/UNIX System Programming courses scheduled

I've scheduled two further public iterations of my Linux/UNIX System Programming course in Munich, Germany, in April and June, and I hope to announce a San Francisco date soon as well. (I'm also available to give on-demand tailored versions of the course onsite at customer premises, in Europe, the US, and further afield.)
          
The 5-day course is intended for programmers developing system-level, embedded, or network applications for Linux and UNIX systems, or programmers porting such applications from other operating systems (e.g., Windows) to Linux or UNIX. The course is based on my book, The Linux Programming Interface (TLPI), and covers topics such as low-level file I/O; signals and timers; creating processes and executing programs; POSIX threads programming; interprocess communication (pipes, FIFOs, message queues, semaphores, shared memory),  network programming (sockets), and server design.
     
The course has a lecture+lab format, and devotes substantial time to working on some carefully chosen programming exercises that put the "theory" into practice. Students receive a copy of TLPI, along with a 600-page course book containing the more than 1000 slides that are used in the course. A reading knowledge of C is assumed; no previous system programming experience is needed.

Some useful links for anyone interested in the course:
Questions about the course? Email me via training@man7.org.

2014-02-14

System call naming and numbering

Various commentators have remarked that the name of the proposed new renameat2() system call seems inconsistent; see, for example, these comments in an LWN.net article that discusses renameat2(). The idea is that when system calls are numbered in this fashion, the number should reflect the number of arguments, rather than the being a "version" number. Thus, with five arguments, the new system call should be called renameat5(), in the fashion of other system calls such as accept4() and signalfd4().

The truth is that there has been little consistency in the numbering conventions used for new system calls. In a few cases, such numbering has represented successive "versions" of a system call (for example, mmap2() and sync_file_range2()).  In several other cases, the numbering has reflected the argument count.  And in at least one fortuitous case, the numbering has reflected the argument count and the "version" (dup(), dup2(), and dup3()).

The use of "version numbers" in the names of new system calls doesn't have have any strong arguments in its favor. However, the convention of
naming system calls according to the number of arguments seems even worse, for a number of reasons.  Among these are the following:
  • The number of arguments exposed by a system call may differ from the number of arguments exposed by the corresponding wrapper function. For example, the pselect6() system call has six arguments, while the C library pselect() wrapper function has just 5 arguments.
  • A new "version" of a system call might have the same number of arguments as the numbered system call it replaces. That precise situation hasn't occurred so far, but there has been at least one case where a system call named according to its number of arguments has had the same number of arguments as the call it supersedes: epoll_create() and epoll_create1() both have the same number of arguments.
  • Finally, if a system call supports a flags argument, then it is possible that a subsequent enhancement to the system call may allow additional arguments to be specified, depending on the use of special bit values in the flags argument (clone(), fcntl(), mremap(), and open() are existing examples of such variadic system calls). In that case, the naming system no longer bears any relation to the number of arguments in the system call.
The ideal solution, of course, is to avoid the naming problem altogether,
by avoiding the need to create new versions of systems calls, which was the main point of my recent LWN.net article, Flags as a system call API design pattern.