Julian C. Dunn

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.

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…

It’s been a rough 48 hours for those of us at CBC.ca Operations. As you can see from the posted notice, a failure of the primary storage device hosting most of the site’s content has knocked out most of the website. Tod Maffin has posted a reasonably complete explanation on Inside The CBC, and I’m thankful for that. At the time of writing, the main volume containing the site content is still offline and fscking with no known ETA.

Originally I wasn’t going to say anything more about the outage, because Tod’s given an adequate update in his entry, and any speculation about the root cause of the outage (whether technical or managerial), and how soon it might be before we can restore service is just that — speculation. But some of the comments that have been posted on the above entry are just astounding and prompted me to write. While I am happy that many technical geeks are amongst our most enthusiastic audience members, I find the glib attitude of many of them with respect to operating the site to be very disturbing and upsetting. Continue reading…

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…