I will be running another iteration of my Linux/UNIX System Programming course in Munich, Germany, during the week of 21-25 October 2013. 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. Among the topics covered in the course are low-level file I/O, signals, timers, creating processes and executing programs, programming with POSIX threads, interprocess communication (pipes, FIFOs, message queues,
semaphores, shared memory), and network programming using sockets. You can expect to work fairly hard (and also learn a lot)
during the week
For detailed information about the content of the course, prerequisites, and other details, see http://man7.org/training/.
In addition to course materials, all participants will receive a copy of my book, The Linux Programming Interface.
The course will be priced (lower than usual) at 2000 euro plus VAT, and the class size will be kept quite small (I've yet to determine if the maximum will be 6 or 8). If you are interested in the course, please email me at training@man7.org and I'll send you information for course registration. Questions regarding the course can be sent to the same address.
2013-07-17
Fourth print run (and request for bug reports)
The publisher will shortly be preparing a fourth print run of The Linux Programming Interface. That print run will incorporate all of the outstanding errata.
If you've been reading TLPI and noticed any errors or typos, now would be a good time to report them, so that fixes can be included in the fourth printing.
If you've been reading TLPI and noticed any errors or typos, now would be a good time to report them, so that fixes can be included in the fourth printing.
2013-05-14
Adding further man pages to the HTML renderings on man7.org
As noted in my last post, I've expanded the set of HTML man page renderings at man7.org/linux/man-pages/ to include some projects other than man-pages. Currently, man pages from 37 projects are now rendered, with about 1750 pages in all. The projects that I have so far included have a bias that matches my interests: man-pages, projects related to low-level C and system programming (e.g., the ACL and extended attribute libraries), toolchain projects (e.g., gcc, gdb, Git, coreutils, binutils, util-linux), and other relevant tools (kmod, strace, ltrace, procps, expect) and tools relevant to manual pages (e.g., groff, man-db).
Although there are some other sites around that have renderings of a much larger set of pages, I am (so far) resisting the temptation to take a kitchen-sink approach on man7.org. Nevertheless, I'm open to adding further projects to the set, if they seem relevant. If you think there is a project that should be added to the rendered set, drop a note to man-pages@man7.org with the following information:
Although there are some other sites around that have renderings of a much larger set of pages, I am (so far) resisting the temptation to take a kitchen-sink approach on man7.org. Nevertheless, I'm open to adding further projects to the set, if they seem relevant. If you think there is a project that should be added to the rendered set, drop a note to man-pages@man7.org with the following information:
- Name of the project.
- Project description.
- URL for the web site the project.
- (If you know it:) URL of a web page that provides information on how to report bugs in the man pages (or email list address).
- Source URL for the man pages of the project. The project should provide pages by one of the following means one of the following:
- Ideally: the URL of a Git repository for the project.
- The URL of a Bazaar or Mercurial repository.
- An HTTP or FTP address for the location that is updated with the latest release tarball on each release of the project.
- If nothing else: the URL of a CVS or Subversion repository. Note: if there is a Git read-only mirror of the CVS or Subversion repository, that is preferred.
- Instructions on how to build the man pages for the project. These instructions should be minimal, in the sense that they require the minimum CPU effort to build just the man pages. In other words, if possible, I'd like to avoid building the entire project just to obtain the manual pages.
- Approximate number of manual pages in the project (actual pages, excluding links).
More man pages now rendered on man7.org
There are several web sites that provide renderings of a comprehensive set of Linux man pages.
However, those sites typically have a number of faults.
For example, the renderings are either for out-of-date versions of the man pages (on one site, the rendered pages are close to ten years old) or the pages provide no timestamp information indicating the age of the pages. In many other cases, sites provide no information about the origin of the rendered pages, give no information about the extraction date or the project version from which the manual pages were taken, and provide no information on how to report manual page bugs to the corresponding upstream projects. Providing that information was the main goal when I started adding the COLOPHON sections to the man-pages pages in December 2007 (man-pages-2.69).
Furthermore, the renderings on many sites are either unattractive (obviously, a subjective judgement) or simply broken (for example, it looks like none of the groff tables in the pages at http://linux.die.net/man/ are rendered, so that, for example, the table of systems calls in the syscalls(2) man page does not appear, making the page essentially useless). Finally, most of the sites provide no obvious information on how to report bugs in the man page renderings.
One of the few sites that does a reasonable job on the above criteria is the http://manpages.courier-mta.org/ site maintained by Sam Varshavchik. It is probably no coincidence that Sam has also provided numerous bug reports on formatting issues in the man-pages page set over the last several years. However, Sam provides a rather less comprehensive set of pages than on the other sites, taking pages from just seven projects.
So, it seems there's room out there for a web site that does a better job on many of the above criteria by providing a comprehensive set of page renderings that: (a) are up to date; (b) carefully document the origin of the rendered pages; (c) describe where to report bugs in the man pages; and (d) explain where to report bugs in the renderings.
With those goals in mind, I've extended the set of pages that are rendered at http://man7.org/linux/man-pages/ to include pages in addition to those provided by the man-pages project. Each page includes a COLOPHON section that shows the name and URL of the project from which the page comes, the URL of the tarball or source code repository from which the page was extracted, the date when the page was extracted, and (where I know it) information on where to report bugs in the manual page. So far, I've added about 35 projects to the set, with the pages for each project being taken either from the latest release tarball or directly from the project's source code repository. This raises the number of rendered pages at man7.org from the around 950 pages in man-pages to around 1750 with the addition of the other projects. (More projects may be added in the future; I'll say more on that later.) A full list of the projects and pages that are rendered can be found in the project page directory.
Sometimes different projects provide the same manual page. On all sites that I know of, where such conflicts occur, just one version of the page is rendered. I've dealt with such conflicts in a different way. One of the versions is treated as canonical (here, I've currently followed the lead of Fedora by choosing the page that it treats as canonical, though I may adjust that approach in the future), but I provide renderings of the other versions at different URLs, with cross page links between the various versions. Thus, for example, three of the projects that I handle provide versions of the kill(1) man page, and the three version are rendered at the following URLs:
For example, the renderings are either for out-of-date versions of the man pages (on one site, the rendered pages are close to ten years old) or the pages provide no timestamp information indicating the age of the pages. In many other cases, sites provide no information about the origin of the rendered pages, give no information about the extraction date or the project version from which the manual pages were taken, and provide no information on how to report manual page bugs to the corresponding upstream projects. Providing that information was the main goal when I started adding the COLOPHON sections to the man-pages pages in December 2007 (man-pages-2.69).
Furthermore, the renderings on many sites are either unattractive (obviously, a subjective judgement) or simply broken (for example, it looks like none of the groff tables in the pages at http://linux.die.net/man/ are rendered, so that, for example, the table of systems calls in the syscalls(2) man page does not appear, making the page essentially useless). Finally, most of the sites provide no obvious information on how to report bugs in the man page renderings.
One of the few sites that does a reasonable job on the above criteria is the http://manpages.courier-mta.org/ site maintained by Sam Varshavchik. It is probably no coincidence that Sam has also provided numerous bug reports on formatting issues in the man-pages page set over the last several years. However, Sam provides a rather less comprehensive set of pages than on the other sites, taking pages from just seven projects.
So, it seems there's room out there for a web site that does a better job on many of the above criteria by providing a comprehensive set of page renderings that: (a) are up to date; (b) carefully document the origin of the rendered pages; (c) describe where to report bugs in the man pages; and (d) explain where to report bugs in the renderings.
With those goals in mind, I've extended the set of pages that are rendered at http://man7.org/linux/man-pages/ to include pages in addition to those provided by the man-pages project. Each page includes a COLOPHON section that shows the name and URL of the project from which the page comes, the URL of the tarball or source code repository from which the page was extracted, the date when the page was extracted, and (where I know it) information on where to report bugs in the manual page. So far, I've added about 35 projects to the set, with the pages for each project being taken either from the latest release tarball or directly from the project's source code repository. This raises the number of rendered pages at man7.org from the around 950 pages in man-pages to around 1750 with the addition of the other projects. (More projects may be added in the future; I'll say more on that later.) A full list of the projects and pages that are rendered can be found in the project page directory.
Sometimes different projects provide the same manual page. On all sites that I know of, where such conflicts occur, just one version of the page is rendered. I've dealt with such conflicts in a different way. One of the versions is treated as canonical (here, I've currently followed the lead of Fedora by choosing the page that it treats as canonical, though I may adjust that approach in the future), but I provide renderings of the other versions at different URLs, with cross page links between the various versions. Thus, for example, three of the projects that I handle provide versions of the kill(1) man page, and the three version are rendered at the following URLs:
- http://man7.org/linux/man-pages/man1/kill.1.html: the "canonical" version of the page, from the util-linux project.
- http://man7.org/linux/man-pages/man1/kill.1@coreutils.html: the version from the coreutils project.
- http://man7.org/linux/man-pages/man1/kill.1@procps.html: the version of the page from the procps project.
2013-03-12
Revisiting kernel capability usage statistics
Revisiting my earlier statistics on capability use in the Linux 3.2 kernel source, things are not getting better for CAP_SYS_ADMIN. The statistics below are for Linux 3.9-rc2. By comparison with Linux 3.2, total uses of CAP_* constants in the kernel sources have risen by 10.6% (1242 versus 1167) and total uses of CAP_SYS_ADMIN have risen by slightly more: 11.1% (502 versus 451). This article remains relevant, and digging a bit deeper, overly broad range seems to be a problem that afflicts not just CAP_SYS_ADMIN and CAP_NET_ADMIN about also (at least) CAP_SYS_RAWIO, as the discussion in this thread on the proposed CAP_COMPROMISE_KERNEL capability shows.
| Capability | #uses | #files |
| CAP_AUDIT_CONTROL | 2 | 2 |
| CAP_AUDIT_WRITE | 1 | 1 |
| CAP_BLOCK_SUSPEND | 3 | 2 |
| CAP_CHOWN | 4 | 2 |
| CAP_DAC_OVERRIDE | 2 | 1 |
| CAP_DAC_READ_SEARCH | 5 | 3 |
| CAP_FOWNER | 11 | 8 |
| CAP_FSETID | 9 | 7 |
| CAP_IPC_LOCK | 14 | 9 |
| CAP_IPC_OWNER | 1 | 1 |
| CAP_KILL | 2 | 2 |
| CAP_LEASE | 1 | 1 |
| CAP_LINUX_IMMUTABLE | 14 | 14 |
| CAP_MAC_ADMIN | 28 | 5 |
| CAP_MAC_OVERRIDE | 5 | 2 |
| CAP_MKNOD | 3 | 3 |
| CAP_NET_ADMIN | 399 | 188 |
| CAP_NET_BIND_SERVICE | 15 | 12 |
| CAP_NET_BROADCAST | 0 | 0 |
| CAP_NET_RAW | 20 | 12 |
| CAP_SETFCAP | 3 | 2 |
| CAP_SETGID | 11 | 6 |
| CAP_SETPCAP | 2 | 2 |
| CAP_SETUID | 9 | 4 |
| CAP_SYS_ADMIN | 502 | 257 |
| CAP_SYS_BOOT | 2 | 2 |
| CAP_SYS_CHROOT | 2 | 2 |
| CAP_SYSLOG | 2 | 2 |
| CAP_SYS_MODULE | 5 | 3 |
| CAP_SYS_NICE | 14 | 8 |
| CAP_SYS_PACCT | 1 | 1 |
| CAP_SYS_PTRACE | 11 | 5 |
| CAP_SYS_RAWIO | 69 | 43 |
| CAP_SYS_RESOURCE | 38 | 25 |
| CAP_SYS_TIME | 19 | 11 |
| CAP_SYS_TTY_CONFIG | 11 | 5 |
| CAP_WAKE_ALARM | 2 | 1 |
| Total | 1242 | 654 |
Subscribe to:
Posts (Atom)
