A while back I had a few important (to me) bugs filed with PHP that had been fixed in trunk but hadn’t yet been released in an update. I wanted to be able to predict about when PHP’s next minor version would be released – but I didn’t find that info in an easily human-digestible format out there. Soooo… this script pumps out minor version release dates in a delumpishly simple format. Yum, yum.

#!/usr/bin/php
<?php

// this script pumps out version/date from php 5 changlog

$url = 'http://us3.php.net/ChangeLog-5.php';
$regex_version = '/^\<h3\>(.*)\<\/h3\>$/';
$regex_date = '/^\<b\>(.*)\<\/b\>$/';

$lines = file($url);
while(list($k, $v) = each($lines)) {
  if (preg_match($regex_version, $v, $matches)) {
    $version = $matches[1];
    list($k, $v) = each($lines);
    preg_match($regex_date, $v, $matches);
    $date = $matches[1];
    echo str_pad($date, 20) . $version . "\n";
  }
}

?>

As of 2009/03/10…

26-February-2009    Version 5.2.9
08-December-2008    Version 5.2.8
04-December-2008    Version 5.2.7
01-May-2008         Version 5.2.6
08-November-2007    Version 5.2.5
30-August-2007      Version 5.2.4
31-May-2007         Version 5.2.3
03-May-2007         Version 5.2.2
08-Feb-2007         Version 5.2.1
02-Nov-2006         Version 5.2.0
24-Aug-2006         Version 5.1.6
17-Aug-2006         Version 5.1.5
04-May-2006         Version 5.1.4
02-May-2006         Version 5.1.3
12-Jan-2006         Version 5.1.2
28-Nov-2005         Version 5.1.1
24-Nov-2005         Version 5.1.0
05-Sep-2005         Version 5.0.5
31-Mar-2005         Version 5.0.4
15-Dec-2004         Version 5.0.3
23-Sep-2004         Version 5.0.2
12-Aug-2004         Version 5.0.1
13-Jul-2004         Version 5.0.0
8-Jun-2004          Version 5.0.0 Release Candidate 3
25-Apr-2004         Version 5.0.0 Release Candidate 2
18-Mar-2004         Version 5.0.0 Release Candidate 1
12-Feb-2004         Version 5.0.0 Beta 4
21-Dec-2003         Version 5.0.0 Beta 3
30-Oct-2003         Version 5.0.0 Beta 2
29-Jun-2003         Version 5.0.0 Beta 1

Back of the envelope here…

  • Time cashier takes to give me a few pennies in change: ~5 seconds.
  • Time I spend later fiddling with those pennies in my wallet while trying to get at other stuff: ~10 seconds.
  • Time I spend getting those pennies out of my wallet at some point: ~5 seconds.

Assume I am a typical US worker, making $20 an hour.

$20 / 60 / 60 * (5 + 10 + 5) = $0.11

Average change in pennies given by a cashier: $0.025

Thus, every penny you give me costs me 0.11/0.025 – 1 = 344% its worth. Not to mention your lost time.

Forget Energy, Health Care and Education, we need a penny ban now!

Splashy is a linux-boot graphical boot screen thinger. It aims to make your booting process into x11 more full of rounded corners and less of 1970’s terminal text streaking by.

Want to get rid of it? Well, make sure to purge it when you remove it, or your system will fail partway through the init scripts on the next boot. You won’t have x11 or networking or dbus. You will have a screen full of errors and a login prompt. So make sure you do:

sudo apt-get --purge remove splashy

However, if you already did just a apt-get remove splashy just like you’d do for any other package, and now your system suddenly won’t boot past 1980, what should you do? Kill the offending file.

sudo rm -ffffffffffffffff /etc/lsb-base-logging.sh

And reboot. Your system should come back up with networking and all. At this point you probably want to re-install splashy then re-remove it using the –purge option to get rid of all its last traces.

This is straight off GoDaddy’s FTP user password requirements for their shared linux hosting plans:

You must create a password for your account. This means that your password:

  • Must contain 7 to 14 characters.
  • Must contain at least one lowercase letter.
  • Must contain at least one uppercase letter.
  • Must contain at least one number.
  • Must begin with a letter.
  • Cannot contain the user name.
  • Cannot contain the following characters: question mark, space, caret, single quote, double quote, colon, backslash, dollar sign, ampersand, greater than, less than, tilde, semi-colon, or accent.

The result of these kind of password requirements is that your user has to come up with a new password, or a new variation on one of their existing passwords, just for your site.  Now in the perfect world, users would have a unique password for everywhere on the internet they have a login.  There are programs out there to help users do that.  But guess what.  People don’t use them.  For some good reasons too – like now a copy of your passwords, one way or another, are being stored somewhere that isn’t your brain.  Which is the whole idea – your password is something that only you can produce and you can do so anywhere anytime you need to.

So in reality, your users likely have somewhere between 10 and 100 logins across the internet. If they’re forced to try to remember a special username/password combo for your site – they won’t. They’ll write it down, and stick in their wallet. Or in the drawer next to their desk. Or in a plaintext file on their desktop. Which is about as secure as, well, putting something yummy in the snack room with a sign that says ‘yummy’.

When a hosting provider like GoDaddy does this kind of bad practice, it isn’t that big a deal. It just makes their FTP user base more likely to be compromised. Now when your bank does it (I believe all my banks do it at one level or another) it’s serious. This isn’t helping the security problem – it’s just passing the buck. Even though this makes the average user more vulnerable to attack, that’s no longer your bank’s fault. It was you who didn’t safely guard your 7 different usernames, 3 levels of passwords, and up to 5 variations on those different passwords for your various logins across the internet.  That’s what I’m up to: 7, 3 and 5. Now soon to be 6.

As a user, what do you guys use to manage all your usernames/passwords?  As a developer, what kind of restrictions do you apply for your users’ passwords and/or usernames?  Do you know of any standard set of password restrictions, or any standard algorithm for computing what constitutes a ‘good’ or a ‘weak’ password?

I’m no Rails expert, nor a Ruby expert, and this is only my second installation of Rails in 4 years, and my first on DreamHost.  So no promises.  But here are the steps I went through to get Rails working on DreamHost with MySQL.

  1. Set up a domain and directory. This where your Rails installation will live.  DreamHost’s preferred method of running Rails is now officially with Passenger (aka mod_rails) which they have on all their Apache 2 servers. You can use the DreamHost admin panel to set this up: go Domains->Manage Domains->Add New Domain/Sub-Domain and make sure to check off on “Ruby on Rails Passenger (mod_rails)”. If you plan on making ~/path/to/rails/root your root directory for your Rails installation, then you need set the web root directory to ~/path/to/rails/root/public when you add this domain using the DreamHost admin panel.

  2. Set up a database. You can do this through DreamHost’s admin panel as well.  Goodies->Manage MySQL->Create a new MySQL database.

  3. Set up Rails. Go to the directory you’re going to run your Rails installation out of (~/path/to/rails/root from step 1) and run:

    rails . -d mysql
    

    (Note the dot for ‘current directory’.)  This will create all the Rails directory structure and default starter files.

  4. Set the permissions. I’m not sure what the exact minimum possible permissions are to run Rails on DreamHost, but this created an acceptable situation for me for now: (note that I ran step 3 with a umask of 0027)

    find ./ -type d -exec chmod o+x {} \;
    find ./ -type f -exec chmod o+r {} \;
    chmod o-r config/database.yml
    

    You would absolutely want to lock these permissions down further if your application involved any sensitive data or services whatsoever. Leaving all your scripts world-readable allows any other DreamHost user to potentially scan your code and look for vulnerabilities.

  5. Do an intermediate test. At this point you should be able to navigate to your domain and see the Rails welcome page.  Note that the “About your application’s environment” link will not work in ‘production’ mode, DreamHost’s default. If things aren’t working, your friends are the logs in ~/logs/your.rails.domain.com/http and ~/path/to/rails/root/log.

  6. Set up the database connection. This involves editing the file config/database.yml.  DreamHost has its Virtual Hosts set up to default your Rails installation to run as ‘production’, but you can change this by setting ENV['RAILS_ENV'] in config/environment.rb.  Here’s a good way to do this automagically once you have development/staging/production sites all set up. After editing any of your Rails config files, you need to do:

    touch tmp/restart.txt
    

    to make sure Apache reloads the Rails config files on the next HTTP request.

  7. Test it. My test was to get the ’skeleton’ version of this project up and running by copying a few files into the Rails directory structure in the appropriate places.

Probability I find something wrong with these instructions in the next week or so?  ~80%.  I’ll update this post when I do.

Update:

Fyi, if you run the Webrick server in script/server, a DreamHost bot will auto email you telling you to please stop it:

From: DreamHost Policy Bot <support@dreamhost.com>
To: Michael Fogel <******@gmail.com>
Our automated system has come across the following activity under your account that is in violation of our Terms of Service.
We request that you take any necessary action to cease the activity as quickly as possible or we will be forced to take further action. If you were not aware of any such activity, please feel free to contact support and we can look into the issue further.

User **** running “ruby ./script/server”. This process is against our policies.

Please run ruby via cgi, not the built-in Webrick web server

They should add to this email a thinger about mod_rails being their preferred way to run Rails.

Update 2:

Ug, you can’t use HTTP Basic Auth with mod_rails (as of version 2.0.6). Note this is what DreamHost will set up for you if you use their web panel to set up authentication. Here’s a relatively simple if not elegant solution to the problem while we wait for mod_rails 2.1 to be released.

The Senate and the House are currently munching on their respective plans for our mind-blowingly large economy kick-start stimulus package. Super-mind-blowingly large.  How large is that?  Well, let’s compare this stimulus package to some previous expensive programs that have come to help define the US of A as a country and a people:

The version of the stimulus currently on the Senate floor: ~900 Billion. Wow. This is more money than has been spent on any project we’ve ever seen in our lifetimes – excluding those readers that are old enough to remember WWII.

So what should we spend it on? Well, how about stuff that will work to keep our economy and productivity on top of the world on a time span of similar scale to the dollar amount being spent – say 100 years? Hum, what should we invest in that’s going to be keeping us going then?

How about new minivans?? Everybody gets a new minivan for cheap! Courtesy of your tax dollars.

Or how about a fat chunk of money (say 50 Billion – enough for ~8 new bay bridges) to repave all our highways? That’ll let us get around really fast in our new minivans, right?

Wrong.

Investment beyond required maintenance in our decaying automobile system will function only to slow us down and help speed our competition up.  Every dollar that makes it easier to drive reduces demand for other transport modes – which slows our transformation to a balanced mode share.  It’s not just a break-even investment – say sacrificing long-term productivity for short-term convenience – it’s plain detrimental to our progress.

China is using their stimulus to transform their national transportation system. They’ll reap benefits from this investment through the 21st century.  We can learn a lot from a little compare/contrast here.

Stimulating new minivans and repaved time-wasting mere 80mph highways will just push us deeper and deeper into the very hole we need to climb out of.  Rather than trying fix an unfixable system, we should be focusing on introducing a viable alternative. We can’t expect 21st century growth and prosperity to magically appear out of a 1950’s solution to our modern-day transportation problems.

Stanford’s big on promoting ‘alternative’ transportation (read: anything but you, driving alone in your private vehicle), especially for commuting. And to Stanford’s credit, Stanford apparently has one of the lowest rates of solo-driver commuting of any major organization in the area. Which is great.

And what’s most impressive, is that this is in spite of Stanford’s parking pricing structure.

Parking pricing? Who cares? Well, turns out this is one very key knob (some would argue that it’s the best knob) we have to help push us away from foreign oil, global warming, childhood asthma, chronic obesity and all those other happy products of our big bad-ass car culture.

To understand how Stanford’s parking pricing is such a powerful knob that is currently twisted the wrong way, it helps to look at a more-or-less typical case study. Let’s consider a hypothetical commuter, call her… “Jane Student” and let’s say like many Stanford students, she chooses to live up in San Francisco and commute down, for reasons like quality of life, culture, etc. Let’s say Jane has a car, but plans on taking the local commuter rail, Caltrain, about half the time.

At Stanford, there are two primary ‘zones’ for commuter parking: ‘A’ and ‘C’. ‘A’ is the good, close lots and costs about 2.5 times what ‘C’ does. You generally only find metered spots adjacent to the ‘A’ lots. Everything that holds true for ‘A’ also holds true for ‘C’, so for simplicity, we’re going to assume Jane doesn’t want to park a bus ride away from class, so we’re only going to consider ‘A’.

Now, to pay for her parking, Jane has three options:

  • Metered parking: $1.50 an hour
  • Daily permit: $11
  • Monthly permit: $60.50

When Jane sits down to consider this situation, the first thing she does is figure out what’s cheapest for her. Well, Jane is on campus usually about 7 hours a day. If she were to drive everyday (20 days a month), then her options cost per month:

  • Metered parking: 1.50*7*20 = $210
  • Daily permit: 11*20 = $220
  • Monthly permit: $60.50

Whoa! $60 versus $220? That’s quite a difference. But now Jane knows she’d rather take the train some days. So how many days a month would she have to drive to make the monthly permit worth it? Well, 60.50/11 = 5.5 and 60.50/1.50/7 = 5.76. So if Jane drives 6 or more days a month, it’s worth it for her to get a monthly permit. Since Jane plans on doing about 50-50 train/car, she goes ahead and buys a monthly permit.

Now, let’s consider Jane’s decision making process each morning when she’s choosing whether to take the local commuter rail, Caltrain, or drive alone.

Costs to take Caltrain:

  • Bike to Station: 15 min, Train: 45 min, Bike to Class: 15 min => 30 min of exercise, and 45 min of semi-productive time
  • Two Caltrain 3-zone tickets: 2 * 6 = $12

Costs to drive alone:

  • Walk to car: 5 min, Drive: 45 min, Walk to class: 10 min => 15 min of light exercise, 45 min of wasted time
  • Gas each way is 40 miles at 30 mpg and gas is now $2.00 a gallon => 2 * 40 / 30 * 2 = $5.33

(Note that medium and long-term costs like insurance, depreciation, health, environmental etc do not factor into Jane’s daily decision making process. Medium and long-term costs and benefits will factor into Jane’s medium and long-term decisions, but will be, generally, inconsequential for her short-term decision making.)

Wow, not only does it take longer for Jane to take the train, but it costs her more! This means Jane’s default behavior will be to drive. We can expect Jane’s commute to be dominated by solo driving with sprinkled Caltrain.

FAIL. That’s not what Jane wants, that’s not what Stanford wants, and that certainly isn’t what our community as a whole wants.

Let’s consider what would happen if Stanford implemented a different parking pricing structure. The following could be implemented with zero costly infrastructure change.

Proposed:

  • Metered Parking: $1.25 an hour
  • Daily permit: $8
  • Monthly permit: $125

Now, the following holds true for our wonderful Jane:

  • A daily permit is only worth it if you’re planning on parking 7 hours or longer that day.
  • A monthly permit is only worth it if you’re planning on parking 16 days or more that month.

All of a sudden the bar to buying a monthly permit is much higher. So Jane, who expects to go for a 50-50 mode share, now will no longer buy a monthly permit. She’ll buy a series of daily permits to use whenever she chooses to drive. Now, let’s consider Jane’s new decision making process each morning when deciding to take the train or drive alone.

Costs to take Caltrain (no change from above):

  • Bike to Station: 15 min, Ride: 45 min, Bike to Class: 15 min => 30 min of exercise, and 45 min of semi-productive time
  • Two Caltrain 3-zone tickets: 2 * 6 = $12

Costs to drive alone:

  • Walk to car: 5 min, Drive: 45 min, Walk to class: 10 min => 15 min of light exercise, 45 min of wasted time
  • Gas each way is 40 miles at 30 mpg and gas is now $2.00 a gallon => 2 * 40 / 30 * 2 = $5.33
  • Parking: $8

Bam. Jane’s total direct, tangible cost to drive alone each morning is now $13.33 – higher than the $12 it costs for Jane to take Caltrain. That, coupled with the benefit of reclaimed time Caltrain affords Jane changes Jane’s default behavior. Jane’s default behavior is now to take Caltrain. We can expect Jane will generally take the train, and occasionally drive.

Given that Stanford’s all about going green, this is puzzling. Thoughts? Anybody from Stanford Parking and Transportation out there with any deeper insight into this situation?

During this last Middle East & Europe wandering, I managed to buy the same semi-durable good three times. Opps. It’s a basic European to USA power adapter. Just two prongs. So, how much did this cost in Egypt, France and InternetLand?

  • Alexandria, Egypt: 0.27 USD (1.5 EGP)
  • Amazon.com, InternetLand: 0.95 USD (plus shipping… varies)
  • Paris, France: 6.71 USD (4.90 EUR)

That gives a 2,385% markup for Paris over Alexandria.  Ouch.

euro to USA power adapter for sale in paris

Are at all the tourist destinations. And you don’t need an ISIC card. Your standard authentic-looking laminated student ID will do.

The discounts are substantial too. For example, the Pyramids are pretty typical:

  • Adult: 60 EGP
  • Student: 30 EGP
  • Egyptian: 2 EGP

That last one isn’t advertised in English. You need an Egyptian residency card to get it.

Just as much a wonder of the world as the Pyramids, IMHO.

Wrong Way
one way street you say?
I don’t see any one coming
honk once, flash twice, go

There are a handful of traffic lights in Cairo. They are ignored by everybody including the traffic cops.

Red Light
I see it, it’s red
nobody in my way… why stop?
it must be broken

Lanes painted on the surface of the road have literally, nearly no meaning whatsoever. A small fender bender is not reason enough to actually stop and pull over.

Making Lanes
ou, can I squeeze in?
flash twice, ok let’s do it
ack opps tag! you’re it

There are no left turns in Egypt. I had no idea left turns were superfluous until traveling Egypt.

Left Turn
follow recipe
straight, then u-turn, then go right
or just make three rights

I don’t understand why, but people use their parking lights not their headlights at night. You use your headlights as a second horn – to flash them at other drivers or pedestrians when the honking isn’t working.

Headlights
from dusk till the dawn
it is dark and I can’t see
headlights? nah, I’m fine