can nail two pieces of wood together
in a few tries. The trouble is that the
market for two pieces of wood nailed
together—inexpertly—is fairly small
outside of the “proud grandfather”
segment, and getting from there to
a decent set of chairs or fitted cupboards takes talent, practice, and
education. The extra 9,900% had neither practice nor education when they
arrived in our trade, and before they
ever had the chance to acquire it, the
party was over and most of them were
out of a job. I will charitably assume
that those who managed to hang on
were the most talented and most
skilled, but even then there is no escaping that as IT professionals they
mostly sucked because of their lack of
ballast.
The bazaar meme advocated by
Raymond, “Just hack it,” as opposed
to the carefully designed cathedrals
of the pre-dot-com years, did, unfortunately, not die with the dot-com
madness, and today Unix is rapidly
sinking under its weight.
I updated my laptop. I have been
running the development version of
FreeBSD for 18 years straight now, and
compiling even my Spartan work environment from source code takes a full
day, because it involves trying to make
sense and architecture out of Raymond’s anarchistic software bazaar.
At the top level, the FreeBSD ports
collection is an attempt to create a
map of the bazaar that makes it easy
for FreeBSD users to find what they
need. In practice this map currently
consists of 22,198 files that give a
summary description of each stall
in the bazaar—a couple of lines telling you roughly what that stall offers
and where you can read more about
it. Also included are 23,214 Makefiles that tell you what to do with the
software you find in each stall. These
Makefiles also try to inform you of the
choices you should consider, which
options to choose, and what would
be sensible defaults for them. The
map also conveniently comes with
24,400 patch files to smooth over the
lack of craftsmanship of many of the
wares offered, but, generally, it is lack
of portability that creates a need for
these patch files.
Finally, the map helpfully tells you
that if you want to have www/firefox,
you will first need to get devel/nspr,
security/nss, databases/sqlite3, and
so on. Once you look up those in the
map and find their dependencies,
and recursively look up their dependencies, you will have a shopping list
of the 122 packages you will need before you can get to www/firefox.
Modularity and code reuse is, of
course, A Good Thing. Even in the
/*you are not expected to understand this*/
Whether `make' supports order-only prerequisites.
AC_CACHE_CHECK([whether ${MAKE-make} supports order-only prerequisites],
[lt_cv_make_order_only],
[mkdir conftest.dir
cd conftest.dir
touch b
touch a
cat >confmk << 'END'
a: b | c
a b c:
touch $[]@
END
touch c
if ${MAKE-make} -s -q -f confmk >/dev/null 2>& 1; then
lt_cv_make_order_only=yes
else
lt_cv_make_order_only=no
fi
cd ..
rm -rf conftest.dir
])
if test $lt_cv_make_order_only = yes; then
ORDER='|'
else
ORDER=''
fi
AC_SUBST([ORDER])
most trivially simple case, however,
the CS/IT dogma of code reuse is totally foreign in the bazaar: the software in the FreeBSD ports collection
contains at least 1,342 copied and
pasted cryptographic algorithms.
If that resistance/ignorance of
code reuse had resulted in self-contained and independent packages
of software, the price of the code duplication might actually have been
a good trade-off for ease of package
management. But that was not the
case: the packages form a tangled
web of haphazard dependencies that
results in much code duplication and
waste.
Here is one example of an ironic
piece of waste: Sam Leffler’s graphics/
libtiff is one of the 122 packages on
the road to www/firefox, yet the resulting Firefox browser does not render
TIFF images. For reasons I have not
tried to uncover, 10 of the 122 packages need Perl and seven need Python;
one of them, devel/glib20, needs both
languages for reasons I cannot even
imagine.
Further down the shopping list
are repeated applications of the Peter Principle, a belief that in an organization where promotion is based
on achievement, success, and merit,
that organization’s members will
eventually be promoted beyond their
level of ability. The principle is commonly phrased, “Employees tend to
rise to their level of incompetence.”
Applying the principle to software,
you will find that you need three different versions of the Make program,
a macroprocessor, an assembler, and
many other interesting packages. At
the bottom of the food chain, so to
speak, is libtool, which tries to hide
the fact that there is no standardized
way to build a shared library in Unix.
Instead of standardizing how to do
that across all Unixen—something
that would take just a single flag to the
ld( 1) command—the Peter Principle
was applied and made it libtool’s job
instead. The Peter Principle is indeed
strong in this case—the source code
for devel/libtool weighs in at 414,740
lines. Half that line count is test cases,
which in principle is commendable,
but in practice it is just the Peter Principle at work: the tests elaborately explore the functionality of the complex