Updated: Due to much feedback, I now know of three ways to do this . . .

1) On BSD systems, you can use jot(1):
sleep `jot -r 1 1 900`

2) If you are scripting with bash, you can use $RANDOM:
sleep `echo $RANDOM%900 | bc`

3) For portability, you can resort to my first solution:
# Sleep up to fifteen minutes
sleep `echo $$%900 | bc`

$$ is the process ID (PID), or “random seed” which on most systems is a value between 1 and 65,535. Fifteen minutes is 900 seconds. % is modulo, which is like division but it gives you the remainder. Thus, $$ % 900 will give you a result between 0 and 899. With bash, $RANDOM provides the same utility, except it is a different value whenever you reference it.

Updated yet again . . . says a friend:
nah it’s using `echo .. | bc` that bugs me, 2 fork+execs, let your shell do the math, it knows how
so $(( $$ % 900 )) should work in bsd sh

For efficiency, you could rewrite the latter two solutions:
2.1) sleep $(( $RANDOM % 900 ))
3.1) sleep $(( $$ % 900 ))

The revised solution will work in sh-derived shells: sh, bash, ksh. My original “portable” solution will also work if you’re scripting in csh or tcsh.

0-20:57 djh@noneedto ~$ env TZ=UTC date
Tue May  6 03:57:07 UTC 2008

The env bit is not needed in bash, but it makes tcsh happy.

Update: Mark points out an easier solution:
date -u

Knowing you can set TZ= is still useful in case you ever need to contemplate an alternate timezone.

(Thanks, Saul and Dave for improving my knowledge.)

I got started graphing various Linux distributions against each other, XP versus Vista, and trying to figure out the best keyword for OS X. Then, I wondered about FreeBSD. Against Ubuntu, it was a flatline. So, I asked myself: what is the threshold for a dead or dying Operating System?

Amiga vs FreeBSD:

Ouch! Can we get deader?

Amiga vs FreeBSD vs BeOS:

To be fair, the cult of Amiga is still strong . . . BeOS is well and truly dead. But how do the BSDs fare?

Amiga vs FreeBSD vs BeOS vs NetBSD vs OpenBSD:

NetBSD has been sleeping with the BeOS fishes for a while, and OpenBSD is on its way. And that’s a league below Amiga!

In Red Hat land, only Fedora beats “the Amiga Line”. For Unix in general, nothing stops the Ubuntu juggernaut. But there’s a long way to go to catch up with Uncle Bill.

(Yes, it is a rainy night and the girlfriend is out of town.)

Postscript: Ubuntu versus Obama

I’d say, any reasonable SysAdmin should default to /etc/crontab because every other reasonable SysAdmin already knows where it is. If anything is used in addition to /etc/crontab, leave a note in /etc/crontab advising the new guy who just got paged at 3:45am where else to look for crons.

For production systems, I strongly object to the use of per-user crontabs. I’m glad to hear I’m not alone. One thing I have to do in a new environment tends to be to write a script that will sniff out all the cron entries.

And then there was the shop that used /etc/crontab, user crons, and fcron to keep crons from running over each other. This frustrated me enough that I did a poor job of explaining that job concurrency could easily be ensured by executing a command through (something like) the lockf utility, instead of adding a new layer of system complexity.

Yes, I am a cranky old SysAdmin.

It is telling that Al Gore has the funniest line.

I hope Bill’s foundation does much good in the world. I almost feel sorry for Microsoft that after all the effort, Vista has proven to be a cold turkey. For what its worth, from a UI and performance perspective, I prefer Windows XP to Mac OS X. Though I’m not sure that this is praise for Microsoft as much as it is an aversion to the Smug Cult of Apple.

(Yes, I am a contrarian. People hate contrarians. Especially Mac people, who think they have the contrarian cred: the last thing a contrarian wants to encounter is a contradicting contrarian!)

12a Is there anything else you would like to tell Apple about your recent in-store repair experience at the Apple Retail Store? (NOTE: 2000 character limit)

Replacing the optical drive on a Mac Mini is a simple procedure that takes fifteen minutes, requiring a screwdriver and a putty knife. That I should have to drive to a God damned mall and explain to a “genius” that he doesn’t actually need my password to log in to OS X, wait for twenty minutes as the “genius” engages in manual data entry, then wait “seven to ten business days” for the part to be replaced is FUCKING SAD.

(Note: Hold down command+s during boot, run to the appropriate init level and type “passwd” to reset the password. Even someone who isn’t a “genius” can pull that off!)

12b The comment above is a

For the record, the optical drive on my Mini started acting up last year. In March, I took it in to the Apple Store. I wanted to get the issue resolved quickly, so I figured I would call the store to ask them if the part was available and what was the best time for them to make an appointment. That call got routed to a call center, where someone with a South Asian accent filled in the same form that I could have filled in online to wait in line at the store for service. Once I got to see the genius, he explained that there was no way to tell how long equipment might be “on the rack” and there was nothing he could do but advise me that it would take 3-5 business days . . . over the months I eventually built a PC out of spare parts to use while my workstation was away, and recently got the drive replaced. Nowadays it is 5-7 business days.

I love that it takes longer for the “Genius” to enter my data into the system after I had previously visited, than it must take the Morlock at the repair center to diagnose, test, and repair the bloody thing. If this were inferior PC technology I could carry it down to any number of local neighborhood stores and wait as the guy replaced the part for a modest charge. The charge for my repair was presented to me as $300, but covered by warranty. I think that is what three-year next-day on-site service for a laptop costs from Dell.

I just spent a fair amount of time wrestling with Apache on my Macintosh. The problem is that it simply refused to read the .htaccess file in my user directory.

My First Approach

I took the “Unix Guy” approach and edited /etc/httpd/httpd.conf to ensure that Apache was configured to consult my user’s .htaccess file. I changed this bit:

<Directory /Users/*/Sites>
    AllowOverride FileInfo AuthConfig Limit
    Options MultiViews Indexes FollowSymLinks IncludesNoExec
    [ . . . ]

To read:

<Directory /Users/*/Sites>
    # AllowOverride FileInfo AuthConfig Limit
    AllowOverride All
    Options MultiViews Indexes FollowSymLinks IncludesNoExec
    [ . . . ]

But . . . nada.

Why That Didn’t Work

Eventually, I found the answer in an O’Reilly Tutorial. Under the section “User-Based Configurations” Kevin Hemenway explains how “per-user” configurations are done in the world of Macintosh:

mini-toldme-com:~/Sites djh$ ls /etc/httpd/users/
djh.conf
mini-toldme-com:~/Sites djh$ cat /etc/httpd/users/djh.conf 
<Directory "/Users/djh/Sites/">
    Options Indexes MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

The O’Reilly article explains that you could edit that file, sure, but then on the next page, it suggests that .htaccess may be a bit more convenient:

As you’ve run through these various tweaks and twiddles of the Apache configuration file, one thing has always remained true: to make the changes active, you’ve had to stop and start Apache after each edit. Not only is this tedious and subject to forgetfulness, it’s also avoidable with a little thing called an .htaccess file.

He then goes on to explain the AllowOverride thing, but doesn’t point out that /etc/httpd/users is going to spank you. Hopefully, his readers paid enough attention and know that within their ~/Sites directory they’ll have to edit /etc/httpd/users/`whoami`.conf . . .

How I Fixed It

I considered changing my /etc/httpd/users/djh.conf but I suspected that some day whatever created it might create it anew, clobbering my changes, and I would forget it had ever existed, and I would go through this frustration all over again. Since I had already made the appropriate change in my /etc/httpd/httpd.conf and since I am the only user on the system, I simply made one more edit to /etc/httpd/httpd.conf. Down near the end, I changed this line:

Include /private/etc/httpd/users/*.conf

To this:

# What the f_ck g_d d_mned insanity!?
# Include /private/etc/httpd/users/*.conf

Restart Apache and now I can use .htaccess as much as I please.

I’m into Chapter 3: Installing Rails, and the instructions for me don’t quite cut it, and a link they provide to Lucas Carlson’s blog no longer exists. But that needn’t stop us, because Google found me a very handy tutorial from Hivelogic: Building Ruby, Rails, Subversion, Mongrel, and MySQL on Mac OS X. It is from February and it does an excellent job of walking through the steps to fetch, build, and install the various pieces on a Macintosh, in /usr/local, like a real Unix system, and explaining all the important bits like fixing your $PATH and installing Xcode, and what the heck is sudo anyway. Stepping through the article is a breeze and you are left with a working Rails server, backed by MySQL, and the beginnings of a clue as to contemporary “best practices” like deployment-via-Capistrano. Huzzah!

In my case, I had to complete one other hurdle along the way. The “gem install rails” bit was erroring out for me when I followed the book and again with the Hivelogic article, with an error like: “Could not find rails (> 0) in any repository” . . . Google again found me an answer from Army of Evil Robots that basically boils down to:

gem update

Anyway, now I have a working Ruby setup on this computer, and I can hitch along to the next chapter, where I’ll learn to hop a freight.

I’m not sure what I might want to do with Rails, but “re-implement lnk.to” seems sort of obvious. If you are reading this and happen to have feelings about lnk.to, or link-shortening services, I welcome any thoughts, suggestions, wishes . . . thanks! -d