NetPBM (formerly PBMplus) is a package of over 220 programs that convert from one graphics format to another and do simple editing and analysis of images. There are no interactive tools in this package, and nothing that displays graphics of any kind. It is like a non-GUI equivalent of ImageMagick, GIMP, and Adobe Photoshop, etc. Over 100 graphics formats are handled, including JPEG, MPEG, PNG, GIF, TIFF, BMP, XWD, XBM, G3 fax, and special formats used by digital cameras and handheld computers. Over 40 editing functions include scaling, cropping, quantization and dithering, colorizing and uncolorizing, blurring, and dimming. Netpbm programs are often invoked by other programs, for example in CGI scripts that manage web site graphics. It also includes a C function library which helps you write programs to process graphics at a lower level than the Netpbm utilities.
xmlrpc-c is a programming library for writing an XML-RPC server or client in C or C++. XML-RPC is a standard network protocol to allow a client program to make a simple remote procedure call (RPC) type request of a server. It's like SOAP or CORBA, but much simpler. This library speaks the same XML-RPC as similar libraries for lots of other programming languages, with most of the popular extensions. The client library uses either w3c libwww or Curl for HTTP. The server library contains a complete lightweight HTTP (Web) server and also facilities for running with CGI under any Web server.
glogin is a program that can be used to cause a terminal (usually a virtual console) to be logged in automatically, without having to type a userid and password. Stick it in place of getty in /etc/inittab to have terminals come up logged in and at a shell prompt at every boot. Same purpose as 'alogin', but you use it a little differently, and it does a little more of the usual login stuff. It is a simple Perl program, and can be easily customized.
smtpsend is a simple SMTP client to transmit an email message to an SMTP server. It is designed for use by programs that need a simple, flexible way to send email, or for experimenting with SMTP. In many cases, sendmail can do what this program does, but it is much more complex, harder to set up and use, and doesn't give you as much lower level control. This program is written in Perl and is based on Perl's Net::SMTP module. It makes a great starting point for writing SMTP client functions into your own Perl program.
Gircap is a set of tools to help you use the widely unknown "capabilities" that Linux has in place of conventional Unix superuser privilege. That means you can give programs and processes only as much privilege as they need and greatly limit your security exposure due to system bugs. A Linux kernel patch fixes some basically broken aspects of capabilities. setcap and getcap let you set and show capabilities of a running process. capexec runs a program with certain capabilities, UID, GID, and supplemental GIDs. It can be used to have init start a daemon with only a subset of init's privileges. binfmt_capx is an executable interpreter in the form of a loadable kernel module. It lets you do a setuid kind of thing for files, only with fine grained capabilities. This is a cheap substitute for real "file capabilities."
Slink-e tools is a package of programs and libraries to drive the Slink-e infrared remote control via its serial port from a Linux system. It features an interactive program to talk to the Slink-e and exercise its functions, an editor and learner for the IR code database, a readline-based command interface, a daemon that controls a Slink-e so that multiple other programs can interact with it, and Perl libraries for talking to the Slink-e at various levels. The package also contains complete documentation of the Slink-e device itself.
diffbin is a utility that does for binary files what the classic 'diff' does for text files. The output is in hexadecimal text and shows bytes added, removed, and replaced. Findings are displayed on standard output and are intended for human analysis. An ASCII decoding of the bytes can optionally be shown.
Quotactl is a package of simple tools for controlling the Linux kernel disk quota system, the kernel facility for limiting users and groups to a certain amount of disk space. The tools are simple and independent so that you can build your own disk quota administration system out of them. The "quotactl" program is simply a command line interface to the Linux quotactl() system call. "mkquota" creates an empty quota file. "quotarept" dumps the contents of a quota file. This is not an integrated quota administration system like quota-tools.
sda12 is a package of software for working with the B&B Electronics 485SDA12 RS-485 analog and digital data acquisition device. It includes a command line program, an XML-RPC server program, and a C++ programming library to provide access to the module's analog inputs, digital inputs, and outputs. You can read the analog input voltages, set the digital output lines, set the module address, and do anything else the device's programming interface allows.
Systime tells you how much CPU time running a program uses. It is like the classic "time" command, except that "time" only tells the CPU time used by the immediate process, whereas "systime" includes other processes that serve the main process, such as the X server and kernel memory management processes. Systime reports all the CPU time used on the entire system while the subject program was running. It uses Linux's /proc filesystem.
This program sets up a socket, then execs a program that inherits that socket on an open file descriptor. You can set up just about any kind of socket. It is like socat, but for programs that know what a socket is. For example, you could have socketexec listen on a TCP port and when a client connects to that port, exec a server program that expects a connected socket as its standard input.
This is a package of programs for analyzing Linux memory usage. It is meant to replace the old "memstat", among other things. The program "vmarea" lists all the virtual memory in the system, showing you which processes and mmapped file caches are using it. "slabcache" summarizes Linux kernel working memory. The data comes from /proc.
grubinstall is a simple program with clear documentation to take the mystery out of the GRUB boot loader. It installs GRUB in an especially simple, robust, hard-to-screw-up form: in a dedicated contiguous boot area at the beginning of the boot disk. This is in contrast to the tools in the GRUB package, which get filesystems involved.
rlimitexec is a tool that lets you run a program with limits on the system resources it can use. The resources that can be restricted include amount of memory, file space, CPU time, etc. If the program tries to use more, the kernel terminates the process. It does this by using the setrlimit() and exec() system calls, which do the same thing as the shell commands "ulimit" and "exec".
Yes, car crashes are the car's fault
> Of course, I'd agree that many projects
> using auto* are hell to set up. This is
> because developers are lazy and don't
> bother to read the docs. Cars get into
> accidents all the time: is this the
> car's fault, or the driver's?
This is dangerous attitude. Accidents are both the car's and the driver's fault, at least insofar as they can be prevented either by fixing the driver or fixing the car. Many, many fixes have been made to cars since they were invented that makes them less likely to get into accidents when driven poorly.
In Software, this is the attitude that says, "I'm not going to change my program because it's the user that's broken, not the program."
A configurator that requires a developer not to be lazy is deficient. It is a worthy goal to fix the configurator so that even a lazy developer can use it.
Maybe developers are setting up Autoconf wrong because it is poorly documented, or unnatural to use, or hard to learn. There's plenty of blame to go around.
Why binary distribution isn't the answer
> There is an even better solution for the
> majority of users:
> don't fix the make system, fix the way
> of distribution. A
> regular user should never be required to
> compile the
Unfortunately, the only technology we have today for distributing binaries that work everywhere is Microsoft Windows. I.e. make everyone run exactly the same thing (via whatever devious means necessary, including withholding source code and forcing computer manufacturers to use a standard configuration). Then you know you can distribute a binary and it will just work.
As we know, that technology has severe drawbacks, so we've settled on a compromise wherein things have to be distributed as source code and configuration programs have to be distributed with them.
Someday, technology may advance to the point that you can click on a button on a web page and have software installed exactly the way you want it, regardless of how specifically tailored to your own tastes and needs your system is. Discussions like this are what lead us there.