After a few shenanigans with Rogers and Teksavvy, I managed to switch over to my cable Internet service yesterday. Thankfully the only issues were administrative. After 24 hours of service, I’m cautiously optimistic that my local segment doesn’t seem to be especially congested.
I’ve not quite cracked 100Mbps download speed in any of my tests, but I have been able to hit 98Mbps pretty consistently and I’m always hovering around 10Mbps up. My ping times seem to stay to between 10-15ms to servers hosted in the downtown Toronto core. This is up about 5-7ms from my DSL service, but I’m fortunate enough to have always had good ping times in artificial tests simply because of location and this doesn’t seem to be a showstopper. I guess I’ll know more when I get a chance to sit down and play a few online games.
Last night during the supposed peak usage period, I was only seeing a drop in download bandwidth of 3-4Mbps at worst and barely any difference in upload bandwidth at all. My latency did increase a little bit as well but never more than 5ms and most of the time it was closer to 1ms.
If this holds, then four times the bandwidth is a fair trade for not having the lowest ping on the server! I thought I’d share this in case anybody else is considering Teksavvy cable as I found it incredibly hard to find anything other than horror stories which were clearly a result of unique circumstances when I was researching the switch.
So for the first time at home I have what until relatively recently would have been viewed as LAN speed for my Internet service, and with an unlimited, and reasonably managed bandwidth policy. I’m not an abusively high user, I’ve almost always stuck inside my current cap on my DSL service, but I do appreciate that a good service provider should manage their networks during extreme congestion.
My experience with Teksavvy has been positive enough over the years, I’ve been a customer since 2006, and I’ve only ever had one provider that was better and this was back in the .com bubble days when Ottawa was crawling with technically savvy and responsive providers! So I’m giving them the benefit of the doubt that they will not do anything naughty with their traffic shaping policies. Continue reading →
Check it out, I’m a huge fan of Derek Muller (the host) and anything on PBS doesn’t tend to go too far astray. I’ve read several books on Uranium and the weapons development over the past several years and as much as I’m pretty strongly opposed to the development and stockpiling of nuclear weapons there really is no escaping that it’s one of the most thrilling scientific, engineering, and espionage stories of the 20th century.
I have whatever the most minimal unit of Internet based notoriety might be for having originally been a bit of a naysayer on HTTP/2 due to my irrational bias against binary protocols! Well, I’m over it.
It’s good news to see that the future beginning to arrive. For a real Internet geek like me this is one of the biggest technological changes in my life!
If you’re like me and you have an obsession with aircraft then this series is a bit of a treat. Wings of Russia is sort of a Russian equivalent to the Great Planes/Wings series produced in the United States but focused almost exclusively on the history of Russian and Soviet aircraft.
Check it out! It’s fairly in depth and it’s great to watch a series that doesn’t treat Soviet and Russian aerospace development as simply a reaction to Western aircraft. From what I know about the topic it’s a fairly well balanced presentation.
I was having a conversation today with a colleague about API usage and why it’s a key to success when building complex systems. I tried to track down the original post from Steve Yegge regarding his thoughts from his time at Amazon and how they applied to the Google context and was a bit surprised that I couldn’t actually track down the original any longer.
For the sake of posterity I want to make sure I keep a copy rather than rely on G+, so with all credit to Mr. Yegge, here it is. Continue reading →
I just learned something about OS X that I didn’t realize was a feature. Then again, sometimes these days the difference between a feature and a bug is marginal!
At work I routinely run my Macbook connected to a second monitor, either at my desk for extra screen space while preparing the latest round of paperwork or when presenting at a meeting. From time to time, the dock (which I just keep at the bottom of my screen) seemingly snaps to the second monitor. This can range from mildly amusing to completely enraging depending on my state of mind and or caffeine level at the moment.
I just learned that this is actually a feature that I’ve been accidentally triggering with sloppy mousemanship. It turns out that you can move the dock on OS X to another display device simply by briefly holding your mouse cursor at the bottom of the device in question.
Now that I know this, what used to seem like a really annoying desktop environment bug has become a cool feature!
Now that I’ve converted the site to use TLS, I’m going about replacing my old homebrewed Flickr plugin to use SlickrFlickr since it seems to be maintained and has similar, but extended, functionality.
I switched mostly so that I wouldn’t have maintain my own plugin, unfortunately I discovered after I finished setting up SlickrFlickr that it only returns the http scheme and not https scheme for the Flickr API.
Not to be too discouraged, I’ve created a simple fix for this and even though it’s a freemium plugin, I may submit a patch to the developer because it’s so simple.
There are three variables that contain the URL scheme in them:
# the variable $url in phpFlickr.php sets some image locations
sed 's/\$url = \"http/$url = \"https/g' wp-content/plugins/slickr-flickr/phpFlickr.php
# these strings also need to be changed in slickr-flickr-api-photo.php
sed -e 's/\$this->url = \"http/\$this->url = \"https/g' -e 's/\$this->link = \"http/\$this->link = \"https/g' wp-content/plugins/slickr-flickr/slickr-flickr-api-photo.php
I’ve actually implemented it as a check in my own local copy of the plugin by verifying the Apache server variables to figure out if the connection is HTTPS. I just don’t currently have this implementation in patch format. I will post it soon.
I’ve not posted in quite some time (I cringed when I realized it had been more than three years), but that doesn’t mean that I haven’t been maintaining the software around these parts. It’s been strange, what little time I’ve made for non-recreational use of computers has been almost completely consumed with mundane details. Definitely the tail wagging the dog!
Anyway, I just thought I’d announce that I’ve converted everything on this domain to use TLS. Heartbleed made me realize that it was time I really tightened things up. I’ve been running the currrent configuration since 2008 with very few changes to the underlying platform. I’ve made two changes to implement this feature.
First, I’ve moved all of the HTTPS accessible content to https://quay.net/ and have removed all of the historical subdomains for different services (e.g.: the RPM repository — more on that in a future blog post). This is necessary unless you want to buy a wildcard X.509 certificate, which I don’t.
Secondly, this has resulted in a restructuring of the URLs for the aforementioned content. In most cases there is an automated redirect or error message, but if you’re searching out something that you have bookmarked let me know and I’ll help you out.
I came across an odd bug a couple weeks ago with MacOS X 10.6.6 and the “Desktop & Screen Saver” System Preference pane. Seemingly out of the blue, when I attempted to modify my screensaver, it would just hang indefinitely and when attempting to click it again it would (usually) crash with EXC_BAD_ACCESS (SIGSEGV) errors. At least anecdotally I seemed to be experiencing crashes of other applications, incl. Steam and Safari (Flash plugins) as well. I could be completely out to lunch, but it seemed as though this issue just manifested for the first time in January after working fine for months. After running through a long list of diagnostics and fairly extensively researching this issue with Google and on Apple’s support forums, I finally called Apple Care to see what they thought.
To make a long story short, after visiting an Apple Store to demonstrate my mystery bug, we discovered that what apparently happened was that I reinstalled the operating system using the retail MacOS X 10.6.0 DVDs rather than the MacOS X 10.6.3 DVD that shipped with my Mac Pro when I purchased it last summer. As best we could tell, even though the installer appeared to work without issues, I ended up with the incorrect drivers due to the fact that the 2010 Mac Pro (5,1) didn’t exist when Snow Leopard originally shipped.
I’m posting this primarily because there was nothing online related to this issue and hopefully if somebody else comes across this problem they can save themselves some effort and headache. This problem is particularly nefarious because you can still apply the 10.6.6 update without any evidence that there are issues but you will still have the bug despite being completely up-to-date.
First thing tomorrow, I’ll be calling Apple to order replacement reinstallation media.