Posted by Julian Dunn
on March 31, 2005
Culture /
No Comments
Recently on sage-members folks have been having a discussion about just how expensive it is to work in the Bay Area. I think Dustin Puryear started the thread as he’s thinking of moving from Louisiana. Anyway, someone posted the following link:
Bill Manning’s Blog >> A crazy little chart about the Bay Area
The numbers in there seem astonishing. When I told my girlfriend, who’s lived in the Bay Area (working for Sun), she wondered how it compares with Toronto. So, after some research at the Toronto Urban Affairs Library, I give you numbers for Toronto. (Here’s a PDF illustrating this in a similar manner to Bill’s original post.)
First, some metadata about wages:
| Gross Minimum Wage |
$7.45 per hour |
|
Federal Income Tax |
$1.19 per hour |
|
Ontario Income Tax |
$0.45 per hour |
|
EI Deduction |
$0.15 per hour |
|
CPP Deduction |
$0.13 per hour |
| Net Minimum Wage |
$5.54 per hour |
Now for some rental rates from CMHC‘s research report:
Private Apartment Average Rental Rates for 2004
York Region$851.00$212.7538.43
| Zone |
Avg. Rent/Month |
Avg.Rent/Week |
Hours Needed @ Minimum Wage |
| Toronto (Old City) |
$950.00 |
$237.50 |
42.91 |
| Etobicoke (South) |
$841.00 |
$210.25 |
37.98 |
| York |
$811.00 |
$202.75 |
36.63 |
| East York |
$844.00 |
$211.00 |
38.12 |
| Scarborough |
$831.00 |
$207.75 |
37.53 |
| North York |
$865.00 |
$216.25 |
39.07 |
| Mississauga City |
$890.00 |
$222.50 |
40.20 |
| Brampton City |
$887.00 |
$221.75 |
40.06 |
| Oakville |
$918.00 |
$229.50 |
41.46 |
So, assuming you were to spend your after-tax income on nothing but accommodations, you could work a regular week in Toronto and be able to rent an apartment. This is about 1/4 the effort it would require in the Bay Area. Pretty shocking!
Posted by Julian Dunn
on March 25, 2005
Backups,
Hardware,
Windows /
No Comments
While on the topic of tape hardware and backups… never mind my little DLT7000 drive at home. How do you back up a 4TB Titan NAS?
We bought one of these servers at work last year; we’re finally getting around to using it for something. Our current challenge is trying to figure out how to back up a 1TB Interwoven content store (we’ve just bought almost the entire product line from Interwoven) without IT screaming at us for taking up their entire tape rotation schedule. This is on top of having to back up a large MediaBin store as well.
I’ll be happy when the Titan is actually up and running, though. We’ve been having some problems getting the CIFS partitions running, because the Titan really needs an Active Directory server in order to enforce permissions, and all we have is a Windows NT 4 domain controller (think again about hacking it; it’s on an internal network). The problem is that we never originally intended the Titan to be used for Windows shares; the unit was purchased long before we decided to go with Interwoven on Windows entirely.
Interesting technical challenges abound…
Posted by Julian Dunn
on March 25, 2005
Backups,
Hardware /
No Comments
After my girlfriend‘s Powerbook crashed, taking with it several months of her un-backed-up data, I decided enough was enough with my own antiquated backup hardware (ExaByte 8505 8mm tape drive, 5GB/10GB) and I bought a DLT7000 (35GB/70GB) drive off eBay, thus increasing my backup capability by seven times. With eight tapes, the whole adventure cost me approximately CAD$150.
I started thinking about what the purpose of hardware compression on tape drives is. In principle, it seems like it’s a good idea; offload compression, which is a CPU-intensive activity, onto the drive. The only problem is that it makes the estimation of whether or not a backup will fit onto a tape a virtual impossibility. I want to know, before I even start writing to the tape, whether or not a backup is going to fit. I don’t want to start writing to tape and then, 2 hours later, find I just hit End Of Media. It’s not something that you can recover from.
I don’t see a technical solution around this problem, so what I do is turn off hardware compression and just gzip the data to a holding disk. This is one of the great features of AMANDA; you can stage the entire backup to a temporary disk, and then write the backup to tape from that disk.
So, as far as I can tell, hardware compression is not very useful; it seems like a scenario where solving one technical problem (moving slow compression activities onto hardware) creates another (inability to know a priori if you’re going to run out of tape before you start writing the backup).