Practical computer tips, with a smattering of digital philosophy

Monthly Archives: January 2012

How disconnecting plugs us back into the world

A list of articles on the power of turning off for a while.


Random thought: is the open-source philosophy inherently libertarian, and capitalistic?

After having read a fascinating essay on Julian Assange, my train of thought somehow brought me to a rather startling conclusion that I wanted to write down before it slipped my mind.  Namely, that the open source philosophy is not particularly conducive to helping people actually get along with each other. Instead, it is an outgrowth of a kind of utopian libertarianism, predicated on the idea that a system that encourages each individual to do whatever he/she wants will maximize the value of the system for the entire collective.  Indeed, when resources are infinite, and conflict easy to ignore or escape (as is the case, to some extent, in digital spaces), this may be the case.

But even in the world of information, this approach has costs.  For example, there is a a hefty bias in the open source community in favor of a very narrow kind of power: technical wizardry, association with powerful techno-business interests, etc.  In some senses, this bias stems directly from the mandate for each individual in the “Linux community” to extract maximum individual value from the community – either in substantive terms, or in terms of garnering increased authority and respect (social capital).  That is, the “open source community” is something of a hyper-competitive meritocracy, with different individuals (or teams) each working to amass the greatest possible shares of technological achievement – the only kind of authority universally recognized by the “community” at large.  Thus, the core value of the open source “community” is distinctly anti-social (ie, vehemently, obsessively technical) in nature, and that fact sets the tone for much of what goes on within it.

And so voices with less technically-oriented priorities (eg, user education; accessibility; social responsibility etc.) are often ignored and discarded, left to either break off to form their own splinter groups (Fedora, Ubuntu, and LibreOffice being the most notable examples) or be quietly suffocated by disinterest.  As a result, unfathomable resources are wasted on parellel but independent efforts, undertaken by various splinter groups who couldn’t quite reconcile their differences, to accomplish almost exactly the same ends.  The guiding principle on which the entire Linux “community” is based is that if something isn’t quite right, it is the responsibility of the individual(s) who find it so to make the necessary corrective adjustments.  And so the entire “community” is maintained primarily by means of powerful individual-centered enticements: people give back, when they do, either as an accidental by-product of pursuing their own agendas, or to increase their own of fame, reputation, and authority within the community.   So if the Linux community at large doesn’t seem to be entirely comfortable embracing any kind of a broader social vision, that’s because it isn’t, at least not intrinsically.

After all, what happens when there is more than one metric of influence and worth in a community?  When people who have vastly different priorities must live and work side-by-side, and do not have the space to fork away from each other because of minor differences in philosophies?  When the resources needed to support such forks are physical rather than informational, and must come from a finite pool, shared by all?

The open-source movement has some intrinsically libertarian characteristics, it would seem, and while some of these – an emphasis on personal responsibility, democracy, egalitarianism, etc. – may be positive, they cannot be separated from their accompanying shadows: deprioritization of social responsibility, the rise of single-factor meritocracy, and the failure to recognize, much less address, pre-existing inequalities (in education, access to resources, and social status within the community) that place potential entrants into a given community on distinctly unequal footing.

Consider the following observation taken from an excellent Ars article on the “app-store” model of software governance, which presents the converse of the argument being made here:

Indeed, from the perspective of the ordinary user, the PC software market may not seem especially free. Lacking the sophistication to distinguish good software from bad, many users don’t feel free to install software at all. In a sense, a curated app store actually increases the freedom of the typical user by enabling him to buy software without the help of his IT-expert sister-in-law.

In other words, because the so-called curated computing philosophy of software governance takes into account and adjusts for differing levels of user competence, it actually gives users on the lower end of the technical spectrum much greater choice and autonomy than does the laissez-faire model of governance, by providing some basic level of user education and support, and safeguards to prevent users from doing something to harm themselves.  Admittedly, all this comes at something of a cost to the most advanced users, who would rather have unfettered control over every aspect of their own “user experience.” But if the goal of the open source community is actually to create a completely egalitarian information society (see Barlow), why shouldn’t this sacrifice be seen as necessary and proper?  The fact is, of course, that it isn’t, because the open source philosophy as a whole is not based on any unifying social ideal – save the dubious deification of individual autonomy.

The overall point, I suppose, is simply that governance is complex and nuanced.  Despotism is not universally evil, and democracy is not universally good.  Hopefully we’ll eventually be able to figure out better ways to incorporate the best elements of both, while discarding the worst.

Cron jobs not running properly? Check your paths (and other troubleshooting ideas)

It took me several hours of poking around to figure out why certain cron jobs were quietly failing to run, while others (which were seemingly far more complex) were running just fine.  The answer, it turns out, was sitting squarely in the middle of the manpage on crontabs (man 5 crontab):

Several  environment  variables  are  set  up automatically by the cron(8) daemon.  SHELL is set to /bin/sh, and LOGNAME and HOME are set from the /etc/passwd line of the crontab’s owner. PATH is set to “/usr/bin:/bin”

What this means is that even if a certain executable runs just fine from your own command prompt, cron may not know where to find it, because most user shells have PATHs far more extensive than the bare-bones default relied on by cron.  And if cron cannot find an executable, it simply won’t run the task in question.   There are two solutions to this problem.  First, you can tell cron to check all of the paths that are active in your own shell session (issue: echo $PATH at a terminal, then put the results of that command on its own line at the top of your crontab file, like so:

PATH = <what you just got from echo $PATH>

Alternatively, you can just make sure to always use absolute pathnames for every exectuable you invoke in your crontab.  To find the exact location of an executable, issue whereis <simple name of executable>.


Should you run into other problems getting your cron jobs to run (which is likely, given that any flaw in syntax anywhere in a crontab line can result in the entire line silently failing to execute), you can use output and error redirection to force the line in question to dump more information about why it’s failing to a specified location (basically, you’re creating your own mini-logging system).  Set up such a log, and then try running the troublesome task every minute (* * * * *) until you get it to work.