These may seem elementary to more experienced software developers, but I’ve found that they’re a nice way to organize my thoughts.
It’s secondary, but it definitely matters.
This reminds me of a great talk I’ve watched two or three times: Breaking the 1000ms Time to Glass Mobile Barrier. The speaker discusses internal Google research in which users’ search loads were delayed slightly and often imperceptibly. Even people who experienced brief and minute delays used Google less for days or weeks.
In a sense, I’ve found software builds similar. Developers won’t usually complain that a project strains their machine or takes too long to build, but it creates a subconcious air of monotony that dissauades small changes and experiments. It also reduces responsiveness, making efficient focused debugging difficult.
Two offenders in this regard are Clang/LLVM and NetBSD. The LLVM
takes an impressive amount of CPU horsepower, and building it with
-j3 can bring a machine with 8 GB of RAM to a swapping crawl. Maybe
this is because of all of the generated C++ resulting from TableGen - I
haven’t had a chance to look into it.
NetBSD is a more subtle and confusing example. It’s known for running on embedded, low-power, and ancient hardware, but the base system seems sprawling. This is apparently due to the presence of many small command line tools, libraries, and kernel modules. I’m sure each one has its proponents and justification, but they accrete into an operating system that takes days to build on a mid- to high-end SoC.
OpenBSD has a more minimalist base system. I like their perspective on this:
Cross-compiling tools are in the system, for use by developers bringing up a new platform. However, they are not maintained for general use.
When the developers bring up support for a new platform, one of the first big tests is a native-build. Building the system from source puts considerable load on the OS and machine, and does a very good job of testing how well the system really works. For this reason, OpenBSD does all the build process on the platform the build is being used for, also known as “native building”. Without native building, it is much more difficult to be sure that the various platforms are actually running reliably, and not just booting.
I do like NetBSD, though, and I miss some of its tools and toys when I’m on OpenBSD.
They’re seductive and I’m often tempted, but avoid them when possible. The Practice of Programming describes this well, but I had to learn by experience. It seems that no matter how well-curated and widely-used a project is, many valid but non-default preprocessor paths will cause errors. Again, I like the OpenBSD FAQ’s coverage of this:
My IPv6-less system doesn’t work!
Yes. Please do not make modifications to the base system that you don’t understand the implications of. One “little” change in the kernel can have very large impact to the entire rest of the system.
I’ve given up on using mk.conf for leaner, quicker NetBSD builds. It
always seems to cause cryptic breakage in a faraway corner of the codebase.
I think that three general guidelines can be drawn from this: