Why we like building from source

Isn't building things from source anachronistic in a world of reach-out-and-upgrade package managers?

No (and we are not alone in this view). Here are a few main reasons.

1. While every main flavor of Unix has package management facilities (Sun: pkgadd, etc; HP-UX: swinstall, etc.), there is none that can be used for packaging of all software across all platforms. Sorry, HP won't give you HP-UX OS extensions in RPM files...

   If you're going to be forced to spend some time outside of a nice neat "package manager" world, why not just go straight back to source (where applicable)?

2. Building from source may be unavoidable if you want the same software on all machines in a multiplatform system.

   For example, there is a lot to be said for using various GNU utilities (coreutils, etc.) on vendor-Unix systems (HP-UX, Solaris, etc.). The main reason is that users then see a consistent set of tools across all machines.

3. In our "multi-platformism" comments, we recommended a healthy aversion to vendor lock-in. Insofar as possible, you should be able to change hardware platforms and/or change pieces of your software base, with minimal pain.

   Binary bundles of software make that kind of flexibility harder. Besides the obvious, they make it harder to know precisely what services that software provides and/or what dependencies with other software it has.

4. If you're building from source yourself, you can react to security alerts more quickly. There is almost always at least a day or two's lag between a security fix becoming known and (for example) the vendor-updated RPMs being available.

   This point would suggest that, even if you live in a mostly vendor-binaries world, you might choose to build your most security-sensitive infrastructure components (e.g. network-facing services) yourself from source.

5. As we noted above, we're not alone: the BSD "ports" system is a big package-handling system that believes in building from source. As they say, "If you ain't got the source, it ain't software! ;-)"

6. [The Big One] At the heart of "serious" sysadmin (as opposed to "sysadmin of convenience") is knowing what software you've got and how it came to be that way. Taking a binary bundle of bits from someone just doesn't fit the bill (not that you always have a choice).

   What are all the things that go into making an executable that you use?

   • That application's source code
   • Ditto for all the libraries that it links to
   • Ditto for the OS that handles the app's system calls
   • The #include files which, in effect, make assertions about the facilities that the libraries (and OS) provide
   • The compiler(s), assembler(s), linker(s) used to put together the application and libraries (and OS)

   Now, obviously, you can have out-and-out bugs in any of those pieces, and/or "mismatches" in the middle. (E.g., an OS component changes, but the #include file that "describes" that component isn't changed. [This really happens.])

   Looked at it this way, it's kinda surprising that any executables work at all :-!

   The truth is, if you take a binary bundle of bits from (a trusted) someone, you don't know the details about all the tools/libraries/etc. that they used to put the package together. Even if you do know, it could be non-trivial to verify rigorously that their setup is compatible with yours.

   Conversely, if you build tools yourself, with a compiler that you built yourself (and run against an OS that you built yourself), then you know exactly what you've got -- and that all of the pieces that went into it really can work together.

   The main practical benefit is a decrease in "brittleness" of applications. You see, it's not that binary-delivered applications simply crash and burn (they typically don't), but you might expect to see more trouble at the "edge cases" (under load, infrequently-used options or combinations thereof...).

   What if things go wrong, e.g. a program crash? If you got the program in a binary bundle, you can perhaps raise a support call with a vendor. (Good luck.) If you built it yourself, you've got everything you need to go digging. Not desirable, not something to do often, but still -- the ultimate "software insurance".

(NB: you can be a full ARK enthusiast even if you think we're bonkers on this source-ism thing...)