Wednesday, March 28, 2007

I've been a Speakeasy customer for years and years. They have been - and continue to be - a fantastic ISP. Speakeasy is one of the few ISPs on the face of the planet where a support call can go something like this:

Me: "Hello, I seem to be dropping packets at a router about four hops past my own gateway."

Speakeasy CSR: "Just a moment while I look into it ... yup, we see that too and we've dispatched a technician to look into it."

This is radically different from the typical ISP experience where the CSR wants to know what version of Windows I'm running, have me reboot my computer, have me reboot my DSL modem, etc. Furthermore, Speakeasy provides me with true naked DSL - I have no ties to the local phone company and rely upon Speakeasy for my Voice-over-IP services (which, by the way, have been rock solid, including 911 call handling by the City of Chicago they way it should be!) I have more than enough dedicated IP addresses for my needs. I can host any and all network services I choose. Speakeasy does a fantastic job of providing me a high-speed gateway to the Internet, letting me do whatever I want with that link and supporting me in my efforts.

This morning, I awoke to a mail message from Bruce Chatterley, Speakeasy CEO, communicating they had been acquired by Best Buy. While I personally have not been burned by some of the Best Buy horror stories out there - in fact, I've had very good experiences with Best Buy's in-store customer service - I'm somewhat concerned over where this could go. Fortunately, the acquisition was made by Best Buy for Business, which gives me some hope that Best Buy has the proper focus around how to deal with customers with demanding needs. Speakeasy certainly understands this, which is why this acquisition certainly makes sense.

Rest assured I'll be closely watching this one. Should the stellar service provided by Speakeasy begin to falter as a result of Best Buy at the helm, I will no doubt look to something like FIOS from Verizon. However, until that day comes I will remain a loyal Speakeasy customer and relish in the stability of their service.

Speakeasy, you have treated me well for years ... please keep up the good work and keep me as a loyal customer!

Wednesday, March 28, 2007 6:02:36 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Saturday, March 17, 2007

I recently commented on Scott Hanselman's desire for the Ultimate Developer Rig and thought I'd share my comments directly with you all.

  1. Re: 64-bit Vista - unless you’re putting > 4GB of RAM in the machine, the return on performance for 64-bit Vista does not outweigh the potential for driver issues and the pure annoyance of the file system structure to store 32-bit applications, especially when you consider your list of power tools … how many of them have 64-bit versions? Yes, 64-bit Vista works great (surprisingly great, actually), but the market and adoption are still in their infancy
    1. On a related note, we recently did some benchmark testing of our 4GB Dell Latitude D820 boxes with 512MB nVidia Quadro 120Ms running both 64-bit Vista and 32-bit Vista; in all test cases, 64-bit did indeed outperform 32-bit, but that’s where the truth stops; the performance increase was ever so slight; so my recommendation here is to do a perf benchmark on your final rig in both configurations to determine if your 64-bit config blows 32-bit so far out of the water that it’s worth the potential 32-bit/64-bit application and driver compatibility hassles
  2. Visual Studio 2005 has no edit-and-continue support for 64-bit installations; while I don’t do a ton of edit-and-continue myself, I’ve done it enough times to be annoyed by 64-bit VS2K5 not supporting it
  3. Make sure your motherboard can address > 4GB of memory; it’s no secret that in many cases we’re staring the old days of 1MB DOS back in the face with the 640K/384K split for IO address mapping; read the Coding Horror article for good links to info/insight on this particular topic
    1. Then if you get a box that can address > 4GB of memory, either put 4GB or greater into it and run 64-bit Vista or put 3GB into it and run 32-bit Vista per the guidelines above
  4. I’d be real tempted to do a RAID 10 set for my data drives at 7,200 RPM or better … stripe and mirror; doubles your cost for hard drives but gives you wicked speed and reliability – especially when you’re potentially I/O bound on large compiles, file copies, etc.
    1. Make sure you trust your RAID controller and driver! Either can make scrambled eggs of your data regardless of the amount of redundancy you throw at it (RAID 1, 5, 10, etc.) if either decides to have a really bad day
  5. nVidia’s video drivers, while WHQL certified, are not as high performing as ATI across the board; video is often times a religious debate, as I’m sure you know; if you’re intent is to do development work and not gaming, I’d go with ATI every time whereas gaming can be a crap shoot
  6. If you do virtual machines and are a Virtual PC/Virtual Server fan rather than a VMware fan, then use Virtual Server 2005 R2 SP1 instead of Virtual PC, assuming of course that you’re getting a dual core or better machine; Virtual PC will not take advantage of more than one CPU, where as Virtual Server will, and it runs fine on Vista in its current release candidate form
  7. Get the largest/fastest CPU cache and memory speeds you can afford; a fast/large CPU cache makes a huge difference, though you pay for it
Saturday, March 17, 2007 12:21:54 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [1]  | 
 Tuesday, March 06, 2007

There's been a good deal of interest in my last post, How to Use Windows CardSpace with ASP.NET Forms Authentication. I recently went back and reviwed the screencast and noticed that I mistakenly stored the private personal identifier rather than the unique identifier.

If you're using my code as an example, you need to make some minor tweaks:

  1. In Link.aspx.cs, replace the token.Claims property usage with token.UniqueID on line 32
  2. In Login.aspx.cs, replace the token.Claims property usage with token.UniqueID on line 28

Technically you can leave the database changes alone and still use the field named PPID, but it may be desirable to refactor the database and the stored procedures names to reflect the storage of a unique identifier rather than the private personal identifier.

In short, you want to rely upon the unique identifier rather than the private personal identifier for a number of security reasons. Vittorio Bertocci does a great job of explaining the details about why you want to use the UniqueID rather than the PPID in his post UniqueID and PPID.

Tuesday, March 06, 2007 12:05:14 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [2]  |