new cell phone activated

I decided to downgrade to a cheaper cell phone after looking over my bills for the last year or so. Previously, I was on Telus‘ Mike service, whose IDEN-based features I’d never used — the only person I knew who still owned an IDEN device was Meredith’s brother, but he ran over his phone with a tractor several months ago. Oops.

Looking at my bill, I was paying about $40/mo. for around 80 minutes of calls. This was insane! My per-minute rate worked out to about 50c/min., once you factored in the “Network Access Fee” (as though you have a choice as to whether to pay that) and taxes. I decided that getting a pay-as-you-go phone was the best alternative.

As a good engineer, I scoped out my requirements first, and did my research. Here’s a summary of my findings.

Company Name Cost Top-Up Details Other Charges Roaming Call Display Voicemail Text Messaging
President’s Choice Mobile 20c per minute $15 top up: provides up to 75 minutes of local calling, valid for 30 days; $25 top up: provides up to 125 minutes of local calling, valid for 60 days. N/A Need to coordinate 2+ weeks in advance and provide a credit/debit card x x x
Virgin Mobile 25c per minute (on “Small” plan, i.e. $0 monthly fee) $100 top-up expires in 365 days; $50 in 120; $25 in 49; $15 in 45 N/A No roaming possible x x x (15c per message sent)
Telus 25c, 33c or 40c a minute $50 top-up expires in 60 days; $25 in 60; $10 in 30 N/A unclear x $10/mo (SPARK10) only with SPARK
Rogers 25c to 39c a minute minimum $10-$30 top-up every month 911 access charge each month Roaming in US for $2.49/minute unclear x (but billed for each minute of a message too) x (15c per message sent)
Fido 20c per minute with >=$20 top-up; otherwise 30c a minute $50 top-up expires in 60 days; $30, $20 and $10 expire in 30 50c 9-1-1 charge every month Roaming not available (only with monthly invoice packages) x $5/mo x (15c per message sent, but it’s not explicit that SMS is included)
Bell Mobility 30¢/minute for the first 2 minutes and 5¢/minute for the rest of the call $25 card expires in 60 days; $15 card expires in 30 days $3.95/mo system access fee + $1.00/mo 9-1-1 fee only with automatic top-up no up to 3 one-minute messages no

You can see that there is quite a high variance between the various prepaid mobile providers out there. Some of them, like Bell, even charge you the same Network Access Fee even though you’re on a prepaid plan! I decided that my requirements were:

  • No network access fees or extra (e.g. 911) fees
  • Reasonable per-minute rate – no weird variations like Telus has
  • Possible to roam in the United States
  • Text messaging, for a cost, of course
  • Bundled voice mail
  • Call display

Based on these requirements, I selected President’s Choice Mobile and bought a new Nokia 2855i phone — much lighter than my old Motorola i90c, and it has a colour screen and Bluetooth too! I’m very happy both with the phone and the service from PC. One amusing fact: PC farms out the actual work to Bell, but if you were to get a pay-as-you-go service from Bell, they’d charge you $3.95/mo. for a system access fee, plus $1.00/mo. for a 9-1-1 access fee! PC Mobility has no such gouging — plus it’s more feature-rich (call display, bundled voice mail, etc.)

The best part is that since the phone is functionally the same as a Bell phone, I get even better reception within the CBC Broadcast Centre than I did with a Telus phone, and I can still send e-mail to the phone by specifying phone-number@txt.bellmobility.ca.

I’m very happy with my choice and I can definitely recommend PC Mobility for low-volume cellphone users. Oh – and if you’re interested in an old IDEN phone – I’m selling mine :-).

NetBSD 3.1 on an SGI Indy

On the other end of the spectrum from my last post, I decided this evening to install NetBSD 3.1 on the SGI Indy that fellow BSD user Jeff Buan gave me a few months ago. This system would have cost an obscene amount of money back in the day (1993) but now, it’s probably worth about $10. These boxes are pretty close to as rock-bottom as you can get these days:

mainbus0 (root): SGI-IP22 [SGI, 690887b5], 1 processor
int0 at mainbus0 addr 0x1fbd9880: bus 66MHz, CPU 133MHz

Jeff had problems giving it away until I took it as a challenge 🙂

Speaking of challenges (pun intended), the last time I tried to install anything on an SGI server, the victim box was an SGI Challenge L — a 200kg fridge-sized monster that my friend Naveen had muscled from the Department of Astrophysics at U of T. It required a 220V power converter that he ended up buying from the House of 220, and a custom-soldered RS-422 serial cable to get on the console. I hoped the Indy would be easier to set up.

Continue reading

A Review of SuSE Linux Enterprise Desktop 10

I’m writing this entry under SuSE Linux Enterprise Desktop (SLED) 10, which I recently installed on my CBC-issued ThinkPad T42. The laptop came with Windows XP installed, which I decided to retain in a dual-boot configuration, because there are still certain tools at CBC (like our antiquated Visual Basic-based “Guests & Boardrooms” booking system) that still require Windows. I did manage to get Remedy ARS to run properly under Wine, however (the latest version, 0.9.28, that is; earlier versions had weird problems rendering dropdowns).

I decided to evaluate SLED because of a number of reasons:

  1. I am fairly satisfied with my OpenSuSE-based CBC-issued desktop, and wanted to see what a “vendor-supported” branch of OpenSuSE would look like;
  2. Novell Client for Linux is only officially supported under SLED, although I have it installed under OpenSuSE, with some hackery (like --force and --nodeps manual installation of RPMs);
  3. There is a rumour flying about the IT grapevine that in the not-too-distant future, CBC will be converting many of its desktops to run SLED.

My expectations for SLED were somewhat low. Although I fully expected everything to work as advertised in the product literature, I worried that the feature set would lag behind the cutting-edge by at least twelve months, as is the norm with RedHat Enterprise Linux (RHEL). For example, I was surprised to see a 2.6.16.x Linux kernel; had I installed RHEL, I would probably be running a 2.4.x kernel.

I decided to put SLED through the paces by trying out a few things that it advertises as working, but with which I’ve had problems in the past:

  1. stable wireless networking
  2. wireless networking with WPA2-PSK encryption for my home
  3. NovellVPN client which purportedly talks to Nortel Contivity VPN concentrators (used at CBC)
  4. NetworkManager for switching connection profiles
  5. suspend/resume to disk
  6. Evolution connectivity to Groupwise servers using the Groupwise SOAP interface
  7. On-board Intel modem

Finally, I wanted to play around with the Xgl display effects, and to see how well that worked (and whether it looks as nifty as my colleagues claim)

I have to say that after a couple of weeks of using SLED that I’m very impressed. This is perhaps the nicest-looking Linux distribution I’ve ever used, and everything does “just work”. Wireless networking is stable and functional, which is absolutely unprecedented for me under Linux. The NovellVPN client does in fact talk to CBC’s Contivity VPN with no problems. And all the problems that have plagued NetworkManager in the past seem to have disappeared. Connection profile switching is as seamless as Mac OS X, which is more than can be said for the IBM Access Connections hackery that is required under Windows.

There’s only one challenge remaining for me, and that’s to see if I can get PPTP working under SLED. This is because the CBC in-building wireless network requires it; association to the AP requires no authentication or encryption, but in order to get onto the BAN, a PPTP VPN connection through a Bluesocket concentrator must be made. I’ll keep you all posted as to my progress!

And yes, the Xgl desktop effects are very nifty — but my laptop’s video card is woefully underpowered, so sometimes X fails to start with Xgl turned on. However, on a desktop machine with a decent video card, I’m sure they would perform perfectly.

Government of Canada to override CRTC on VoIP regulation

As many of my regular readers know, I’m an open-source VoIP hobbyist, and as such, I’m a "member" of the Toronto Asterisk Users’ Group (I use the quotations because the group does not have membership requirements nor is it a formal organization per se). One of the hot topics recently on the TAUG mailing list was the Government of Canada’s recent decision to override the CRTC‘s position that VoIP is a telephony service and should be regulated as such.

The CRTC has traditionally regulated telephone companies and set minimum pricing on services such as land lines and DSL so that the incumbent carriers like Bell Canada cannot use predatory pricing to drive non-incumbent firms out of business, only to raise those prices later when the marketplace has been clear-cut. Now that the government has proposed to override the commission, VoIP service will become a free-for-all, with hobbyist and startup VoIP providers like Unlimitel and AtlasVoice getting squeezed by the incumbents for large commercial deployments.

This is bad news for VoIP telephony in Canada and will greatly reduce consumer choice, except for those consumers, such as hobbyists, who are willing to take an "anything but Bell" attitude. The government’s actions in overriding the CRTC’s fair and thorough process aimed at protecting consumers is a blatant demonstration that it is pro-big-business to the exclusion of all other factors. (That process, by the way, arrived twice at the outcome that VoIP should be regulated like regular telephony, despite a Conservative government Privy Council Order which attempted to pressure them into reconsidering their original decision.)

It’s a shame that this particular issue is too esoteric for the mainstream press to cover, but I think it’s very much a bellwether for how the government plans to treat other emerging technology trends that threaten traditional big-business hegemony.

good in the aftermath of bad

Popular political scientist Thomas Homer-Dixon was on CBC Radio One’s The Current this morning discussing his new book, The Upside of Down. His work warns of the potential downfall of Western civilization along the lines of the demise of the Roman Empire. Although this might seem like a very gloomy topic, he makes the key point that out of catastrophe can often come good, and describes, for example, 9/11 as a squandered opportunity to, for example, reduce America’s dependence on foreign oil. But I’m getting sidetracked — and this is a journal about technology, after all, not politics. Continue reading

searching for a 64-bit future

This month in ACM Queue there’s an interesting and lengthy article entitled The Long Road to 64 Bits, which addresses why, fifteen years later after the 64-bit MIPS R4000 was announced, most systems are still not fully 64-bit clean. I use the word “clean” to mean that most systems do not run entirely in 64-bit mode; many systems are running 32-bit operating systems on 64-bit processors, or even when a 64-bit operating system is in use, running many 32-bit programs in compatibility mode.

The article is a fascinating account of how technological decisions that were made all the way back in the 1970’s, both with respect to hardware and compilers, still impose limitations today. Although many of the hardware compatibility challenges have now gone away — for example, system designers now know enough to trap address bits that they are not using for addresses rather than letting "clever" programmers get away with using them for data — the assumptions that were made by programmers back in the days of 16 and 32-bit machines with respect to the size of C data types continues to hinder the porting of programs from 32 to 64-bit. One can’t just make and hope one’s pointers all work. As Mashey puts it, some programmers got sloppy and assumed things like

sizeof(int) == sizeof(long) == sizeof(ptr) == 32

All this may sound really abstract to readers who don’t have a hardware design background (admittedly, mine is minimal, but I understand enough of the general concepts) so let’s talk about how this impacts us end-users. We run into problems like “there is no 64-bit web browser that can execute Java and Flash” because the Java and Flash plugins haven’t been ported to 64-bit clean versions. In some ways, this is an example of shocking neglect on the part of software vendors like Sun and Macromedia (pardon me, Adobe). Bug Number 4802695, entitled “Support Java Plug-in on 64-bit AMD Opteron”, has been open with Sun since January 14, 2003, and after three years there is still no resolution in sight. This should be embarrassing for Sun, which is a vendor of 64-bit Opteron and UltraSparc IIIi workstations.

Continue reading

supervised disconnect on PSTN lines

It’s funny how sometimes you have a technical problem that you think is only attributable to your own (possibly crappy telephony) setup, but later on you discover that the problem is quite common. For example, today on the TAUG mailing list, someone complained about their Zap (analog) channel never being hung up by Asterisk particularly when the user at the other end hangs up right away. I have also had this problem on my home Asterisk setup, where Asterisk will busy-out the Zap channel for hours, preventing people from making incoming calls.

At first I attributed it to my crappy clone FXO card, but now I’m wondering if it’s a problem with Asterisk. Others seem to think so and feel that Asterisk doesn’t properly handle the supervised disconnect in situations when the channel hasn’t been Answer()ed. I haven’t done enough tests to nail down when in the dialplan it happens exactly.

Later in the day, someone claimed that one way to fix the root cause is to teach Asterisk how to handle the standard off-hook warning tone, but I don’t think it’ll be very simple to implement, since the warning tones are probably different for each country.

For now, I’m happy to ssh into the server and soft hangup Zap/1 (as someone suggested) but I wish there was a solution that didn’t require such manual intervention, so if any telephony enthusiasts are reading this and have any better ideas, feel free to comment.

static vs. dynamic content: a footnote

My colleague Blake recently wrote an article on the occasion of the decommissioning of NewsDelivery, a dynamic content display engine that until recently ran all the news stories on CBC.ca. I can’t speak for any of our alumni, but I think all of us at CBC.ca have learned one lesson:

Large websites should never, ever use dynamic rendering for content rendering.

It’s amazing how many content management systems still do not grasp this principle. On a busy site, especially one that is liable to be Slashdotted or visited heavily (say, on 11 September 2001), you do not want to be executing Java/ASP/Smalltalk/FORTRAN/whatever code every time someone visits a story. In short, you do not want CPU usage to rise proportionally to the number of visitors you have.

What you do want is to make the content rendering "system" as simple as possible; in the ideal case, you can barely call it a system. For content rendering, CBC.ca now mostly uses a bare Apache instances with server-side includes, meaning that aside from the core Apache engine, no other code needs to be executed every time you view a story.

This seems like a very simple principle, but many other news sites are still not grasping it. I can almost guarantee that if there is another 9/11-scale of event, sites that use a servlet-based dynamic execution system like The Globe and Mail and The Toronto Star will fall over under heavy load far sooner than CBC.ca. But I don’t really blame those organizations for choosing, for example, Fatwire Content Server (as in the Star’s case) because a news organization’s primary need is to create content. Displaying it is a whole separate problem entirely and the shame should be on the vendor for closely tying the two together.