Athlon X2: Dual Core Present

I've talked about Multiple Core CPU Futures, but how about the dual core present?

The Athlon 64 X2 is now widely available in both OEM and retail* packaging, ranging from the 4200+ to 4800+. AMD just released a cheaper Athlon 64 X2 3800+ at under $400. As a developer, you will not find a CPU that compiles code faster. In fact, it's not even close. So what are you waiting for? You'll certainly need something to counteract VS.NET 2005's higher system requirements.

* The retail package includes, by far, the best stock heatsink I've ever seen-- it's a thin-fin aluminum affair with copper inlay and two heatpipes. If you can get the retail box for not much more than the OEM, it's definitely worth it. And you get an AMD X2 sticker, too. A STICKER!

Steve Ballmer: Sweatiest Billionaire Ever

A colleague recently pointed me to a Steve Ballmer video I hadn't seen before; the one where he pitches Windows 1.0. All three of the Ballmer videos are essential viewing for any Windows developer:

• Windows 1.0 sales pitch
• Dance Monkeyboy
• Developers, Developers, Developers

I love the fact that Steve Ballmer is a billionaire 12 times over, and yet he isn't afraid to get up on stage and make a complete and utter ass out of himself. You have to respect a man with that much unbridled enthusiasm. I certainly can't see staid, boring old Michael Dell dancing around on stage, screaming about how much he loves his company at the top of his lungs. Steve Ballmer is unique:

Steve Ballmer can be so zealous in expressing his enthusiasm that once his vocal cords required surgery after he screamed "Windows, Windows, Windows" continuously at a Japan meeting in 1991. When Microsoft celebrated its 25th Anniversary in 2000, CEO Ballmer popped out of the anniversary cake to surprise the audience. His wild screaming and dancing on stage at an employees convention was caught on a widely-circulated video known as "Dance Monkeyboy." A few days later at a developers conference, a sweat-soaked Ballmer repeatedly chanted "developers" at least 14 times in front of the bemused gathering. Beyond his jovial image, this second cousin of famous comedian Gilda Radner is known to be a shrewd businessman with a flair to grab opportunities when they come.

Ballmer has also called Linux "communism" and the GNU GPL "a cancer". He advocates Digital rights management and has said that "DRM is the future."

Linux may have Tux, but we've got Ballmer. Pudgy cartoon penguin versus sweaty screaming billionaire? C'mon. That's not even close.

What if it was infinitely fast?

When it comes to performance, there's always a bottleneck. The question is, which bottleneck? That's why one of the more interesting back of the envelope calculations is to ask, "what if it was infinitely fast?"

One way to make something infinitely fast is to make it a no-op. Instead of doing work, it does nothing. This is also known as "null driver" in hardware circles. It shows how fast your hardware could be given the limits of the underlying operating system infrastructure. Standard 2D graphics operations in Windows have been equal to null driver performance since about 1999:

Modern graphics companies concerned about 2D performance take something called a NULL driver -- a graphics driver than accepts the low level rendering commands but does no rendering work whatsoever -- and see how close they can come to its performance. Companies like Matrox are basically almost at the NULL driver performance in all situations.

Gary Tarolli was the CTO of 3dfx Interactive. Their Voodoo series of add-on video cards pioneered real time 3D graphics on the PC. Gary had this to say about infinitely fast 3D hardware in 1998:

I just want to put in a few cents here. I know Voodoo2 relieves the CPU of triangle setup processing, however, that is all it relieves the CPU of. If a game is taking up 80% of the CPU time, which is not that uncommon, then even if we replaced our hardware with INFINITELY fast hardware, you only get a small increase in performance (1.25x). Voodoo2 isn't infintely fast, so the results are even smaller. Each game takes up a different amount of the CPU, so you will see different results for different games.

It's hard to imagine the CTO of a hardware startup actually answering questions about the product he designed in the newsgroups. Only in 1998, I guess.

AnandTech's review of the first affordable solid state hard drive offers a tantalizing glimpse of infinitely fast storage devices-- and some new bottlenecks we couldn't see before:

It's an interesting experiment. Kudos to Gigabyte for making a 4gb solid state hard drive affordable. All you need is $70 for the i-RAM device itself, and 4gb of PC3200 DDR RAM (at current pricing, $90 x 4). Sure, "under $500" isn't exactly cheap, but relative to other solid state hard drives, it's an incredible bargain.

Unfortunately, Having an infinitely fast solid state hard drive doesn't do a whole lot to improve raw performance. It's probably best used as a device to reveal where all the other performance bottlenecks are.

The D.I.Y. PC

In Screwdrivers versus Couture, Ed Stroglio nailed the real difference between PC enthusiasts and Mac enthusiasts:

One might think case modders or overclockers [or developers] in general might be more prone to the Mac outlook, but that's not really so. What such people are proud of is not mere ownership of the equipment, but what they've done to it to make it what it is. It's a much more hands-on sense of accomplishment: what has been done rather than what it was out of the box.

PC enthusiasts are all about the D.I.Y. aspect of the PC. Sure, Dell's designers are laughable, but that's not the point. We make the beige box what we want it to be:

PC case modifications
Apple G5 case

I'm not saying one is inherently better or more aesthetically pleasing than the other. They just come from very different places. Apple's G5 systems are the product of a world-class design team and stamped out by the thousands; custom PC builds are the highly individual result of dozens or even hundreds of hours of personal investment.

This same D.I.Y. ethic also extends to PC software. Specifically, open source software. I know there's nothing that ties open source development to the PC platform in particular, but certainly Linux was born on PC hardware and the entire open source ecosystem is built primarily on PC hardware. Isn't building custom software a little bit like hot-rodding your automobile?

I read this [Edmunds] article and was struck by the similarities between this and the open source vs COTS model.

COTS (Commercial Off The Shelf) software is equivalent to a stock automobile. They're built by professional engineers, and tested as a whole. But you don't get to mess with the system.

On the other hand, open source gives you the ability to join the software equivalent of the tuner/modified market - you can tweak the system to your hearts content. You may make it go faster, but you're not totally sure what it's going to do to the overall quality of the system.

In fact, I constantly read that that's one of the huge benefits of open source - on an open source project, if you don't like how something works, you can just step in and fix it, while with COTS you don't have that ability.

Tinkering and tweaking isn't limited to open source projects; it applies to COTS software, too. I'm a COTS Windows user, but I have a dozen different utilities and tweaks I have to install before I'm happy with my build. I know plenty of users who go even further and retrofit the entire GUI using WindowBlinds.

While I certainly appreciate Apple's ability to box up elegant hardware designs with an elegant UNIX GUI makeover, that just isn't for me. I have more fun when I do it myself.

The Dancing Bunnies Problem

In an era of instant online worldwide connectivity, protecting users from themselves is a lot harder than it used to be. For one thing, full trust can't be trusted. And then there are all those dancing bunnies to contend with:

What's the dancing bunnies problem?

It's a description of what happens when a user receives an email message that says "click here to see the dancing bunnies".

The user wants to see the dancing bunnies, so they click there. It doesn't matter how much you try to disuade them, if they want to see the dancing bunnies, then by gum, they're going to see the dancing bunnies. It doesn't matter how many technical hurdles you put in their way, if they stop the user from seeing the dancing bunny, then they're going to go and see the dancing bunny.

There are lots of techniques for mitigating the dancing bunny problem. There's strict privilege separation - users don't have access to any locations that can harm them. You can prevent users from downloading programs. You can make the user invoke magic commands to make code executable (chmod +e dancingbunnies). You can force the user to input a password when they want to access resources. You can block programs at the firewall. You can turn off scripting. You can do lots and lots of things.

However, at the end of the day, the user still wants to see the dancing bunny, and they'll do whatever is necessary to bypass your carefully constructed barriers in order to see the bunny.

Here's hoping Longhorn (aka Windows Vista) is the first Microsoft OS to default users to non-administrator accounts. Because users can't help themselves-- they just have to poke the bunny.

I think the real solution, if there is one, is high-speed virtualization. The user will always play in a sandbox that looks and performs exactly like their current installation, but is in fact a Virtual PC style image. If something bad happens, you just ball it up and throw it away.

Show, Don't Tell

I picked up a copy of The Best Software Writing I: Selected and Introduced by Joel Spolsky. It's essentially just a collection of Joel's favorite blog entries from the last few years. But it's Joel, so you know they're going to be good ones. In the introduction, he explains why he's so enthusiastic about blog writing: it encourages the simple, but powerful use of show, don't tell:

The publisher wanted to get a quote from me to put on the back cover talking about how wonderful his book was. Normally I'd be happy to do that; I'm a complete publicity slut and will do just about anything to get my name in front of the reading public. My hope is that if I do this enough, telemarketers who call me at home will be able to pronounce my name.

The book started out looking promising. It filled a real need. I remember several times standing in bookstores desperately trying to find a book on the very topic, but there was nothing to be found. So I started reading the manuscript full of high hopes.

Bleah. I could hardly bear to keep reading. The author kept saying smart and interesting things. He even wrote clearly. But the book was thoroughly, completely, boring. And worse, it was completely unconvincing.

The author had violated the number one rule of good writing, the "Show, don't tell" rule. There was not a single story in the book. It was chock full of sentences like "A good team leader provides inspiration by setting a positive example." What the eff?

Pay attention. Here's the way to say "a good team leader provides inspiration by setting a positive example" without putting your audience to sleep:

For a few months in the army I worked in the mess hall, clearing tables and washing dishes nonstop for 16 hours a day, with only a half hour break in the afternoon, if you washed the dishes really fast. My hands were permanently red, the front of my blouse was permanently wet and smelly, and I couldn't take it any more.

Somehow, I managed to get out of the mess hall into a job working for a high-ranking Sergeant Major. This guy had years of experience. He was probably twenty years older than the kids in the unit. Even in the field, he was always immaculate, wearing a spotless, starched, pressed full dress uniform with impeccably polished shoes no matter how dusty and muddy the rest of the world was around him. You got the feeling that he slept in 300 threadcount Egyptian cotton sheets while we slept in dusty sleeping bags on the ground.

His job consisted of two things: discipline and the physical infrastructure of the base. He was a bit of a terror to everyone in the battalion due to his role as the chief disciplinary officer. Most people only knew him from strutting around the base conducting inspections, screaming at the top of his lungs and demanding impossibly high standards of order and cleanliness in what was essentially a bunch of tents in the middle of the desert, alternately dust-choked or mud-choked, depending on the rain situation.

Anyway, on the first day working for the Sergeant Major, I didn't know what to expect. I was sure it was going to be terrifying, but it had to be better than washing dishes and clearing tables all day long (and it's not like the guy in charge of the mess hall was such a sweetheart, either!)

On the first day he took me to the officer's bathroom and told me I would be responsible for keeping it clean. "Here's how you clean a toilet," he said.

And he got down on his knees in front of the porcelain bowl, in his pressed starched spotless dress uniform, and scrubbed the toilet with his bare hands.

To a 19 year old who has to clean toilets, something which is almost by definition the worst possible job in the world, the sight of this high ranking, 38 year old, immaculate, manicured, pampered discipline officer cleaning a toilet completely reset my attitude. If he can clean a toilet, I can clean a toilet. There's nothing wrong with cleaning toilets. My loyalty and inspiration from that moment on were unflagging. That's leadership.

See what I did here? I told a story. I'll bet you'd rather sit through ten of those 400 word stories than have to listen to someone drone on about how "a good team leader provides inspiration by setting a positive example."

True enough. And even if you don't entirely agree that Joel's choices are "The Best Software Writing"*, they're still pretty darn good:

1. Style is Substance, Ken Arnold
2. Award for the Silliest User Interface: Windows Search, Leon Bambrick
3. The Pitfalls of Outsourcing Programmers, Michael Bean
4. Excel as a database, Rory Blyth
5. ICSOC04 Talk, Adam Bosworth
6. Autistic Social Software, Danah Boyd
7. Why not just block the apps that rely on undocumented behavior?, Raymond Chen
8. Kicking the Llama #4, Kevin Cheng and Tom Chi
9. Save Canada's internet from WIPO, Cory Doctorow
10. EA: The Human Story, ea_spouse
11. Strong Typing vs. Strong Testing, Bruce Eckel
12. Processing Processing, Paul Ford
13. Great Hackers, Paul Graham
14. The Location Field is the New Command Line, John Gruber
15. Starbucks Does Not Use Two-Phase Commit, Gregor Hohpe
16. Passion, Ron Jeffries
17. C++ - The Forgotten Trojan Horse, Eric Johnson
18. How many Microsoft employees does it take to change a lightbulb?, Eric Lippert
19. What To Do When You're Screwed, Michael "Rands" Lopp
20. Larry's rules of software engineering #2: Measuring testers by test metrics doesn't, Larry Osterman
21. Team Compensation (pdf), Mary Poppendieck
22. Mac Word 6.0, Rick Schaut
23. A Group Is Its Own Worst Enemy, Clay Shirky
24. Group as User: Flaming and the Design of Social Software , Clay Shirky
25. Closing the Gap, Part 1, Eric Sink
26. Closing the Gap, Part 2, Eric Sink
27. Hazards of Hiring, Eric Sink
28. Powerpoint Remix, Aaron Swartz
29. A Quick (and Hopefully Painless) Ride Through Ruby (with Cartoon Foxes), why the lucky stiff

You can save your $22.49 with a few deft mouse clicks, but I think it's reasonable to have these entries in book form, with Joel's typically insightful introduction for each entry. The book works quite well as a survey overview of the outstanding blog content that most people still don't even know is out there.

* For example, I couldn't even bring myself to finish reading Paul Ford's rambling, incoherent novella Processing Processing. Good Lord. I'd also drop the last one with the foxes on Ruby. It was neither funny nor particularly instructive. I don't mean to be overly negative; these are definitely the exceptions. The rest are quite good..

Just Try Again

It's funny because it's true:

A Software Engineer, a Hardware Engineer and a Departmental Manager were on their way to a meeting in Switzerland. They were driving down a steep mountain road when suddenly the brakes on their car failed. The car careened almost out of control down the road, bouncing off the crash barriers, until it miraculously ground to a halt, scraping along the mountainside. The car's occupants, shaken but unhurt, now had a problem: they were stuck halfway down a mountain in a car with no brakes. What were they to do?

"I know", said the Departmental Manager, "Let's have a meeting, propose a Vision, formulate a Mission Statement, define some Goals, and by a process of Continuous Improvement find a solution to the Critical Problems, and we can be on our way."

"No, no", said the Hardware Engineer, "That will take far too long, and besides, that method has never worked before. I've got my Swiss Army knife with me, and in no time at all I can strip down the car's braking system, isolate the fault, fix it, and we can be on our way."

"Well", said the Software Engineer, "Before we do anything, I think we should push the car back up the road and see if it happens again."

In all seriousness, I can't recall a single week that I haven't done this exact thing at least once: Geez, I dunno, just run it again and see if the problem recurs. I don't know if it's a sad indictment of the state of software engineering or a not-so-subtle hint that software engineers deal with thousands of variables in even the simplest of programs.

On Being Pushy

Via Scott Hanselman:

I've been reading as much as I can on how to be an effective manager lately. For a number of reasons, mostly internal, but also because in a recent lunch Chris Sells said (something like): "If you're not getting slapped by your boss at least twice a year, you're not pushing the envelope enough."

He then links to a set of management rules, specifically highlighting number three:

If you are not criticized, you may not be doing much.

There's a fine line between pushing and pushy, but you have to push. You may get slapped, but so what? Anything is preferable to indifference or, worse, the same old cliches.

For Best Results, Don't Initialize Variables

I noticed on a few projects I'm currently working on that the developers are maniacal about initializing variables. That is, either they initialize them when they're declared:

private string s = null;
private int n = 0;
private DataSet ds = null;

Or they initialize them in the constructor:

class MyClass
{
  private string s;
  private int n;
  private DataSet ds;

  public MyClass() 
  {
    s = null;
    n = 0;
    ds = null;
  }
}

Well, this all struck me as unnecessary work in the .NET world. Sure, maybe that's the convention in the wild and wooly world of buffer overrunsC++, but this is managed code. Do we really want to play the I'm smarter than the runtime game again?

Ok, so maybe you're a masochist and you like extra typing. What about the performance argument? According to this well-researched CodeProject article, initializing variables actually hurts performance. The author provides some benchmark test code along with his results:

That's on the author's Pentium-M 1.6ghz. I tested the same code (optimizations enabled, release mode) on my Athlon 64 2.1ghz and a Prescott P4 2.8ghz:

I recompiled under VS.NET 2005 beta 2 using the Athlon 64 to see how .NET 2.0 handles this:

Clearly there's a substantial performance penalty for initializing variables in both .NET 1.1 and even .NET 2.0 (although the newer compiler appears to optimize away initialization on definition). I recommend avoiding initialization as a general rule, unless you have a compelling reason to do so. If you're only initializing variables to avoid the uninitialized variable compiler warning, check out the new #pragma warning feature to programmatically disable specific warnings in .NET 2.0.

Passwords vs. Pass Phrases

Microsoft security guru Robert Hensing hit a home run his first time at bat with his very first blog post. In it, he advocates that passwords, as we traditionally think of them, should not be used:

So here's the deal - I don't want you to use passwords, I want you to use pass-PHRASES. What is a pass-phrase you ask? Let's take a look at some of my recent pass-phrases that I've used inside Microsoft for my 'password'.

• "If we weren't all crazy we would go insane" (Jimmy Buffett rules)*
• "Send the pain below!"
• "Mean people suck!"

So why are these pass-phrases so great?

1. They meet all password complexity requirements due to the use of upper / lowercase letters and punctuation (you don't HAVE to use numbers to meet password complexity requirements)
2. They are so freaking easy for me to remember it's not even funny. For me, I find it MUCH easier to remember a sentence from a favorite song or a funny quote than to remember 'xYaQxrz!' (which b.t.w. is long enough and complex enough to meet our internal complexity requirements, but is weak enough to not survive any kind of brute-force password grinding attack with say LC5, let alone a lookup table attack). That password would not survive sustained attack with LC5 long enough to matter so in my mind it's pointless to use a password like that. You may as well just leave your password blank.
3. I dare say that even with the most advanced hardware you are not going to guesss, crack, brute-force or pre-compute these passwords in the 70 days or so that they were around (remember you only need the password to survive attack long enough for you to change the password).

Windows 2k and higher support passwords of up to 127 unicode characters. So this will work on virtually every Windows network in existence. Reggie Burnett, however, has some doubts:

The reason I think that Robert's logic is a bit flawed is that a pass phrase is likely to contain readable words (else it really isn't a pass phrase) and therefore can be attacked not at the letter level but at the word level. According to various sites I visited, the average English speaker knows about 20,000 words but uses only about 2,000 of those in a given week. Since the user is likely to use words they are used to, we can safely say that most pass phrases will contain one of about 5,000 words. And, if a pass phrase contains 4 words, then our possibilities are 5000^4. I'll spare you the math, but you'll see that the cracker that is trying pass phrases has alot fewer possibilities to try. Now, of course, using more words will increase the security, but we should also note that since the attack is at the word level, the length of the word would not matter. "Mean people suck" would be just as secure as "Extremely important password". They are both 3 words and both use common words.

While I see his point, he's completely ignoring the capitalization and punctuation in "Mean people suck!". I do agree that for the best security, your passphrase should include capitalization, punctuation, and possibly even numbers if you can work them in there in a logical way. Andy Johns elaborates:

As I've often mentioned, I'm a consultant and I see a lot of crap out in the wild. By far the most annoying crap I see is around passwords. The more paranoid the network admins (or security council, or board, or whoever sets the rules) the more obscure the passwords must be, and the more often they need to be changed. What these people fail to realize is the average human worker just wants to do their job, and can't remember Syz8#K3! as a password. So what do they do.... Out comes the post-it-note on the desk, or in the drawer, or under the keyboard, or the file on the desktop called "passwords.txt". Some workers try and be smart by leaving out a letter, or writing it backwards.... but still, if your password is so hard to remember that you have to write it down, then you have no security at all, and a significant portion of your support staff/costs must be spent dealing with resetting passwords.

A pass-phrase of "this is my password and it's for my eyes only" is far easier to remember than Syz8#K3! and also far more secure, and nearly takes the same amount of time to type. Need more security, throw in a few caps, or numbers: "My address is 1234 Main street" or "Jenny's number is 867-5309". Yes, I'm breaking rules about not including personal information in a password, but remember, 1) these are examples, and 2) a pass-phrase is different. A password of "Chris" because your son's name is Chris is a bad password, but a password of: "My oldest son's name is Chris and he is 10 years old" is a good password.

Passphrases are clearly more usable than traditional "secure" passwords. They are also highly likely to be more secure. Even naive worst-case passphrases like "this is my password" aren't all that hackable, at least when compared to their single word equivalents, eg, "password".

Easier on the user, harder for hackers: that's a total no-brainer. I've adopted passphrases across the board on all the systems I use.

* ugh