Be a Better Raindrop

no single raindrop believes it is to blame for the flood

The computing industry is already awash in condescension and negativity, and it’s getting worse. Yes, I know it’s not a new phenomenon, but I’ve been around long enough to be sure of the trend. I’ve been blogging for over a decade, I was on Usenet even longer than that before, and I was on other forums even before that. I know all about operating-system wars, language wars, editor wars, license wars, and their ilk. I’ve fought many of those wars myself. Still, things seem to be getting worse. Practically no technical news nowadays comes unaccompanied by a chorus of hatred from those who prefer alternatives. Half the time I find out about something that’s really pretty cool only because I see the bitching about it. How sad is that?

The thing is, it really doesn’t matter why people act this way. Yes, some people are just basically spiteful or insecure. Others might think they’re acting from more noble motives, such as bursting a hype bubble or squashing an idea they believe is truly dangerous. Half of the articles on this site are based in such motivations, so I’m by no means claiming innocence. The problem is that even the best-motivated snark still contributes to the generally unpleasant atmosphere. Contrary to popular belief, we techies are social animals. We have our own equivalent of the Overton Window. Every Linus eruption or similar event from a perceived leader shifts that window toward a higher spleen-to-brain ratio. Others emulate that example, and the phenomenon reinforces itself. Those of us who are older, who are leaders, who find ourselves quoted often, owe it to the community not to keep shifting that window in the wrong direction. That’s not being “honest” or “blunt” or “clear” either, if your honesty/bluntness/clarity is only apparent when your comments are negative. Real life is not one-sided. If your commentary is, then you’re not being any of those things. You’re just being part of the problem.

Linus not helping

No one of us caused this and no one of us can fix it. However, we can each try to do better. That’s my New Year’s resolution: to start taking the high road and giving people the benefit of the doubt just a bit more often. Sure, some people might get besotted with a particular idea or technology that I think is inferior, but that doesn’t make them stupid or bad. Some people might get carried away with their praise for a company or its products/people, but that doesn’t make them fanbois or shills. Some people are all of those things, and I’m sure I’ll still let slip the dogs of war from time to time when the occasion warrants it, but I’ll at least try to adopt a doctrine of no first strikes and proportional response instead of the ever escalating verbal violence that is now commonplace. Would anyone else like to give it a try?

Limiting Bash Script Run Time

Another self-explanatory bash hack. This one was developed to limit the total run time of a test script, where one of the commands was hanging but I was trying to chase down a different bug.

# Run code with a time limit.  This is trickier than you'd think, because the alarm
# signal (or any other) won't be delivered to the parent until any foreground task
# completes.  That kind of defeats the purpose here, since a hung task will also
# block the signal we're using to un-hang it.  Fortunately, a directed "wait" gives
# us a way to work around this issue.  We start both the alarm task and the task
# that does real work in the background, then either way we get into exit_handler
# and kill whichever one's still running.  It's a little bit inconvenient that
# everything has to be wrapped in a "main" function to work, but there's a lot about
# bash that's unfortunate.
function exit_handler {
	if [ -n "$ALREADY_EXITING" ]; then
	if [ -n "$WATCHER" ]; then
		echo "killing watcher"
	if [ -n "$WORKER" ]; then
		echo "killing worker"
	echo "time to die"
trap exit_handler EXIT
function alrm_handler {
	echo "alarm went off"
	unset WATCHER
trap alrm_handler ALRM
export PARENT_PID=$$
(sleep $TIME_LIMIT; echo "ring ring"; kill -s SIGALRM $PARENT_PID) &
export WATCHER=$!
# Example function to demonstrate different completion sequences.
function main {
	if [ "$1" != 0 ]; then
		echo "sleeping"
		sleep $1
		echo "waking up"
main "$@" &
export WORKER=$!
wait $WORKER
unset WORKER
# Test with shorter sleep times to see the worker finish normally, with longer
# sleep times to see the watcher cut things short.