"A cardiac surgeon doesn't know much otolaryngology; an EE doesn't know much about steam turbines; a personal injury lawyer isn't going to be much help with your corporate takeover."

Thus why I often use the phrase "A proctologist wouldn't do the job of a brain surgeon unless he had his head up his ass".

People may like generic terms, but it's not hard to educate them on the differences relatively easily if you just compare it to things they're already familiar with.

Well, FWIW, for the project I was working on, FF was too slow to be acceptable for public use. Whether it was really 3x slower or not I don't know, but it was a considerable decline in performance from using Chrome. I have no doubt that in some other environment (with a different usage than what I was using it for) FF could very well be faster.

Didn't know about the SunSpider fix/non-release. Good to know.

"What with all this AJAX and Javascript stuff out on the web these days, what IE badly needs is a really good Javascript engine."

It really does. I've been working on an interactive touchscreen kiosk for work, and decided to go the JS route in the browser since it's what I know. As such I wanted to know the relative JS performance of the various browsers out there. I used the SunSpider benchmark to test them. Here were the results (smaller numbers are better):

Safari 4.04 (482)
Chrome 4.0b (518)
FF 3.5 (1502)
IE8 (7773)

Two things surprised me here. One is that Chrome and Safari are 3x faster than FF. I was going to use FF for my kiosk until I saw this. The other is the abysmal performance of IE. When you are 15x slower than two of your rivals that is just horrible. As it is I used Chrome for my project and couldn't be happier.

Chrome is just faster, as is Safari (funny, they both use Webkit). In my experience they can both be up to 3x faster than FF in doing JS related tasks. This is especially apparent to me as I build a touchscreen kiosk for my company. It's fairly interactive with the JS, but always seemed sluggish in practice. I assumed it was just an underpowered machine (running Vista), until I tried it in Chrome. It was like night and day.

I still love FF, but if you're trying to push the envelope online a bit, then a browser like Chrome is going to make you smile a lot more.

"If I had to choose between IQ and work ethic, the work ethic would win out every time."

When I was in 8th grade one of my teachers pulled me aside at the end of the year. He said I was one of the smartest kids he'd ever taught, but that if I wanted to get anywhere in High School and beyond, I would need to learn to apply myself. He pointed out a girl in my class who got straight A's, but said really, she wasn't particularly bright, she just worked her ass off. This surprised me, I just assumed she was really smart.

When people tell kids at a young age they're really smart I think at times it does them a disservice. I was told that so much I didn't feel like I needed to have a good work ethic to achieve things. Things came easy to me, so they always would right? Wrong. Once you actually do hit a stumbling block, it can be devastating. While the kid who has worked his butt of his entire life just plows right through it like he has everything else. Ability is meaningless without application.

"While this begs the question of why you changed it in to that in the first place"

No, it really doesn't. The fact that a user *can* change it is the only thing that matters. This is the issue with many (not all) devs in general. Say something they wrote isn't easy or is unintuitive and instead of fixing it they say "well nobody with a brain would do that" or "if they don't know how to figure it out then too bad for them". These are not valid comebacks.

I get that most devs are analytical and if there is at least one way to do something then it's "good enough". But UI's are subjective and as such just because there is a way to perform a given task in your software it does not mean that there isn't a better way to do the same thing for a larger number of people. When we say "the user experience sucks" we're not saying *you* as a dev suck. We're saying we simply want a better experience. This is something many designers learn early on (we create designs and get shot down on them all the time), but something many devs seem to never fully grasp.

Or better, for PARC to sue SPARC. At least they're the same industry, "sound similar", use all caps in the name, etc. But that's right, it's just easier to go after the little guy.

Disclaimer, I work for a large contemporary art museum in New Media. We deal with this stuff all of the time and it's something I have an interest in (obviously). The answer for you is there is no tried and true method for archiving digital media. Every arts institution struggles with this, especially when it relates to computational or internet enabled or social media works of art. There are various opinions on what it even *means* to archive some of this stuff and there are varying degrees of opinions out there about all of it.

That said, several things you can do to help yourself. One, any museum worth their salt and who actually wants to acquire your work will work with you to get it in the format they are most comfortable with. New Media art tends to have varying requirements on what needs to be in place to replicate it, what that means, how it works, etc. A museum putting your work into their collection should work with you to define those things and how to keep it working and usable for the long term. That is the museum's *job*.

Second, if you want it to last you need to have original source material. Almost 100% of the time that is what the museum will want. If it's a video they do not want a compressed DVD, they'd rather have the uncompressed DV files or 35mm film if they can get it. If it's an application they want the app, the hardware used to run it, the docs used to create it, etc. Sure, you don't have to give these things up if you don't want to, but you can bet the museum will want as much of the original source and documentation of it as they can get. This will help them down the line when they need to convert the original into yet-another-new-format, and help them catalog the work for later generations of staff (and viewers for that matter, meta data is gold).

Basically, let the museum help you, that's what they're there for. In the meantime, backup, backup, backup, until such time as you have your work acquired by a professional institution.

Inciteful as the statement is, it's true... There's no way it can be false. A browser containing IE's engine *and* WebKit has all the security holes from both, and all the security holes gained in pushing one into the other.

It's also true for any plug in you use in IE. I'm curious if MS would say the same about Flash, Java, etc? Because they all introduce their own security problems in IE in a similar way as Chrome Frame. The fact that MS is singling out Chrome Frame says more about how MS feels about Google than it does about the security of their browser.

has anyone come out and said it flat out won't work?

No, and you're right. All Adobe said is they're not going to test CS3 in 10.6. This doesn't mean it won't work, it just means they're not bothering to test whether it does or not. Nobody is really going to know until Friday, but people with dev builds say it runs with some minor bugs. Really though, CS3 is buggy enough I doubt it'll be much of a deterrent.

I think the appropriate comic for this is here:

http://www.crispygamer.com/comics/ding/ding-2008-05-29.aspx

Is you can't turn off SMS on the iPhone. At least I haven't found out how. I don't particularly like SMS, it costs me money to receive texts, and I have an flippin iPhone, why would I need it when I can email, IM, tweet, etc? Yet here we have an SMS back door and the only solution is to shut down the entire phone because there's no way to disable SMS by itself.

My site doesn't see much of a difference either. 175,000 visits per month and here's the change in browser usage from May to July:

IE: -0.91%
FF: -0.13%
Safari: +1.15%
Chrome: +0.32%