One of the great joys in my life has always been reading a good Raymond Chen post.  I've linked to Mr. Chen's wikipedia entry but I feel the need to also mention that he is the creator of an old Win '95 utility called TweakUI.  That isn't listed in the Wikipedia article but to people who used TweakUI way back when it's probably what distinguishes him the most.

Anyway, one of his trademarks is that he posts about technical decisions made in Windows that seemed to make no sense and goes to the trouble of explaining why that choice was made.  In this case he tackles .ini files and why Windows started using a registry.  I was never a fan of the Registry and still lament the death of .ini files but after reading Mr. Chen's explaination the decision (as always) makes perfect sense.  Check it out!

I don't dislike Doc Searls but I've never been his biggest fan either.  He's one of those guys that get off by "feeling" like they're making a difference without making any attempt to "actually" make a difference.

So you get things like the Cluetrain Manifesto which everyone pays a lot of lip service to but which is entirely impractical and which has never gained any real traction.  Some people like to site changes made by companies like Ebay and Amazon but the truth is these companies were on their current track well before Doc Searls et. al ever typed a word. 

In the end the Cluetrain Manifesto was just a few guys throwing theoretical and completely unsustainable ideas out there and then patting themselves on the back for having been "visionaries".   So I'm understandably unimpressed when I read this in one of his posts…

For too long we’ve lived with “relationship management” that’s asymmetrical and one-way. Creating the grounds for symmetrical relationships cannot be the job of Facebook, Google, Microsoft or any big company. They can’t do it, and they won’t. We can’t petition those lords with prayer, blogs, or anything else. (Well, we can, but it won’t be enough.)

We need to create our own new rules — ones that protect our privacy while making us better members of the social and business systems we create together. I say “better” because that’s what we’re bound to be when we cease being eyeballs and start acting like whole human beings.

My reaction…"Oh Goody, Doc Searls' is going to write another useless Manifesto to make himself feel good".   Now let me make my point clear, I'm not against theoretical discussions nor am I against people putting their ideas out there.  What I AM against are people who make no attempt to subject their ideas to real world Scrutiny.   That's where the attitude above comes from, "we're the users and we'll decide what we want and force the companies to do it that way"  

Well no, you won't….

If you really want to bring about change you need to bring the companies you want to change into the fold and find a way to create a situation that serves them too.   Change is made from Compromise not random pontification on one side's part.  No problem was ever truly solved by one side bullying the other side into submission and Doc Searls certainly isn't going to be the first to make that happen.  

So I'm back, brighter and earlier than I would have liked but I guess that was inevitable after 4 days away.  A few things that caught my eye over the (rather slow) weekend...

Sometimes I think everything in this world is controversial to someone.   Case in Point, Glenn Reid has an interesting post about XML where he says...

XML does not deserver its "ML", or even its "X". But first, the "ML" part.

I am one of the world's leading experts on markup languages. I'll start there. I'm a 20-year veteran of desktop publishing, am personally related to the author of one of the very first markup languages in the world (Scribe), and have actually used SGML, MML, HTML, and most of the other markup languages that came along decades before XML.

So I know what I'm talking about. XML is not a markup language.

Well, ok then.  I don't really know how to respond to that to be honest.  He may very well be right but (a) it really doesn't matter what you call something and (b) XML is easily the most widely adopted markup language in existence (if you count XHTML) so I would think that would be enough to change the definition (if we're brining it to a vote). 

Anyway...

In other news Scott Watermasysk of Telligent has a post asking "Are Trackbacks (still) Worth It?" and I have no real answer for him.  They do seem to be causing a lot of spam lately and though they're a good idea in theory I rarely see them used in any useful way.  That said, from his perspective and the maker of blogging/community software I don't think we're to the point where you can drop it from the feature list and expect everyone to accept that. 

Finally, on the "just kind of cool front",  Greg Dolley posted on how he converted Quake II to managed C++ in the latest version of Visual Studio.  It's a good post but the part I found most interesting was this...

On modern computer hardware and the commodity-priced video cards out there, it’s difficult to come up with speed comparisons between .NET versus native C++ when running Quake II. What I mean is this - pretty much all computers with a decent 3D video card run the game at its maximum frame rate anyway regardless of whether native or managed mode is used. However, I did see a difference in performance when I turned on just software rendering and used a high resolution. The speed differences weren’t that much - the .NET version was about 9% slower (94 FPS in native versus 85 FPS in managed).

However, non graphics related things, such as initializing the game and loading maps between levels were noticeably slower in the .NET version. I would wait about seven to ten seconds for the game to load in a managed build versus about two seconds in native mode. The same amount of slowdown was noticeable when switching between levels.

The truth is that very few people need the graphics power behind Quake II as it is so the fact that managed code is performing that well tells me that you are probably safe doing 99% of things in a managed environment.  If you are planning the next Halo on the PC you are probably better off with unmanaged code but if you're planning the next Halo in this day and age you probably aren't targeting the PC anyway.