Other operating systems have pulled ahead and probably will continue to do so. Office has been nearly feature complete since Office 97 (which is perfectly serviceable for 99% of people), and Open Office will eventually get there, if it hasn't already. Internet Explorer continues to slip.

Microsoft continues to win in business software like Exchange and Outlook, and things that integrate with them. My guess is that they're putting a hell of a lot of money in SharePoint, because what other CMSs integrate that well with things like Exchange and Office and Active Directory? SharePoint will help them maintain their business dominance as they get clobbered in other areas.

I'm not sure what the cloud can do for them, there seems to be a lot of "magic happens here" in it. This could be a way for them to move Exchange and SharePoint up to a service pool in the sky.

Microsoft usually takes a few times to get things right. The next iteration of Xbox ought to be a monster, but I wouldn't rely on their cloud for a few more years.

It's that simple. A core percentage of your users simply refuse to read what is in front of them. They skim, they look for only the things they expect, and absolutely nothing else. They're basically running the visual equivalent of an Expect script, responding to a prompt in a way which may or may not be appropriate.

I'll give an example. I had a password reset program which, of course, required an email address specific to our users. However, there was a possibility that users would use a different email address that wasn't valid. No, I had no access to that list of addresses to match and verify, that was simply out. Instructions were provided on the page as to which kinds of email addresses were allowed, and which were not. Of course users ignore instructions, as we all know. They see "email address" and they begin typing. Instructions could be on the top, on the bottom, or right before that row -- it didn't matter. This happened about 45% of the time. Okay, half of our users read directions, yay.

So I added something which would detect the wrong type, I could at least do that much, and tell them, via a nice, big Javascript window you had to click to make go away, that they used the wrong kind, and here is what the right kind looked like. What kind of drastic reduction in errors did I see?

95%? No.
80%? Such an optimist!
50%? Ha!

Only thirty percent of my users, presented with a HEY IT LOOKS LIKE YOU ARE USING THE WRONG EMAIL ADDRESS HERE IS WHAT IT SHOULD LOOK LIKE kind of prompt, right in their face, changed their behavior. It was big! It was colored! It covered the form until you made it go away. The rest kept doing it the wrong way. Sometimes several times in a row (I watched the logs). I could see them return a month later to reset their password, which they had forgotten, and make the same mistakes. They will not remember more than a few minutes ago, they will not read instructions, and they will not respond to error messages. They will not remember error messages they see.

Once you accept the existence of this core group and realize that you can do nothing to help them besides providing hopefully appropriate environmental prompts, the rest explains itself. Do not waste time trying to solve the problems with this group. If you carefully watch their behavior on other systems, they experience identical problems wherever they may go. They exist in a perpetual struggle with computers, thrashing like a goldfish thrashing in a corner of an aquarium. Feel sorry for them if you must, design around them if you can, but you cannot change their behavior for them, only provide a padded environment where they cannot hurt themselves too much and can hopefully mouth soft objects with rounded corners.

I sincerely hope that this version is better than the first edition, although anything short of a random re-arrangement of pages would serve as an improvement. The first edition actually delayed my initial use of Python by about a year and a half. I had heard wonderful things about the language so I figured, "Ah, an O'Reilly book!" Big mistake.

Endless bits about immutability, without hints as to why I ought to care. I can appreciate the use of the interactive prompt now, but to start with it seems ... strange. I was not transitioning to Python from shell programming, and I doubt many do. Lambda expressions, entirely too early. Not a great deal of attention paid to idiom, which is just about central to learning a new language. Little discussion of how you might have accomplished tasks in other languages and wish to do the Pythonic equivalent. I loathed the first edition and refer to it precisely never. I eventually dropped it in a puddle and felt no urgency towards retrieving it. The now-wrinkly cover suggests that some unhappy deity has attempted to purify it by flood.

I ought to have tried fire.

It's time to replace all of those "Microsoft as the Borg" images with "Google as the Borg."

At this point, given how little I use my cell phone, anyway, I am strongly considering making a little box out of mu-metal. I think (but have not run the numbers) that it would be more effective than simple copper at the given frequencies. Whenever I want to use the phone, I will take it out of the box. Seeing as how I have used no minutes or text messages this month (already a third over), there's an argument to be made for switching to a much cheaper service.

I might get a pager, in case work (or anyone else) needs to get ahold of me.

We should log lollipop purchases, so we can crack down on those guys in big white vans with FREE CANDY on the side.

You're right, I completely ignored the hardware decoding aspects. Every time I look at video/audio encoding/decoding, I end up adding at least one more link in the chain. I don't know if video encoding is all that easy. I don't know personally anyone who does it and I know a fair bunch of programmers in disparate knowledge domains. Maybe I just don't know the right guys.

I'm not completely ignorant of serving video over HTTP, I'm just not a huge fan of it. I know it's what the cool kids are doing right now, but it overloads the protocol in a way it wasn't meant to be. Traffic shaping alone kills the issue for me. I would much rather have my lightweight text delivered to me over HTTP and then someone else's bandwidth hoarking video over another protocol. I know everyone talks about the coming bandwidth utopia, but where I am at, we're having significant issues with certain folks (ahem, students) absolutely slamming the Teh Tubes with torrent traffic and videos, so much so that people are having trouble checking email and reading webpages.

Streaming is not downloading. At all.

Downloading sends the whole file. It might as well be over FTP. Streaming is completely different.

First off, your media player and the streaming server negotiate a good bandwidth.

Next, the streaming server selects either the file or a stream within the file (as with RealMedia's SureStream) which suits the bandwidth of your media player.

This gets handed off by the server to your media player in a packetized fashion, little chunks of video. If you want to skip to a minute before the end, you may do so, even if you have not downloaded the whole file.

If a few packets get dropped along the way, if the buffer on your media player fails to take care of it, there can be a resend.

Or if your pipe gets clogged up, the streaming server can renegotiate the bandwidth. Or switch to a different server on the cluster, without you knowing about it.

Then there's a bonus for the people who are concerned with piracy (or those fearful of being sued for enabling it), which is that a whole copy of the file is not left on your hard drive. (You can get one by using a "stream ripper," but this is due diligence we're talking about here)

There's a lot of other stuff involved, and I'm drastically over-simplifying, but Streaming is not Downloading.

For a commercial takeoff, we need to expand beyond quadruplegic patients and the locked-in. Always loved the idea, but let's be honest -- if typing is faster, typing will still win. And that's just output. For input, I don't think competing with something high-speed like vision is all that important. Just a BCI that would allow for IM rates might as well be freakin' telepathy.

Streaming video needs an Apache. By that, I mean a very standardized server and set of protocols for delivering files encoded in a non-proprietary, free-to-use, free-to-decode, unrestricted-in-every-imaginable-sense manner.

The source of what has held this back, in my opinion, is that taking giant video files (and you should see how big raw video is) and cramming them down into small, chunkable files which can decode at the end into recognizable images is hard. Hard in the sense of "takes people with a great deal of math knowledge and computer science knowledge to pull off." It's not like HTML, where you are pushing around what are basically text files that you can open in Notepad. It takes a great deal of intellectual know-how and deep domain knowledge to pull this off on the encoding end in some reasonable fashion that doesn't take a lot of CPU cycles.

The few people who can do this take a long time to figure out a new scheme, and they have to test the living hell out of it. You can write a primitive webserver without too much fuss, it's just a specialized server which kicks out text and binary files on command, after all. Encoding video and serving it, though, is not easy. That's why so much goes into protecting the intellectual property; it was not trivial to create. Wade around in the fifteen profiles for MPEG-4 Part 10 aka AVC aka H.264 for a while and realize that this is not trivial. Hell, it had to be jointly developed by two groups, ITU's video group and MPEG. Take a look at Theora -- even its codebase is descended from something that once took real money to make.

If streaming media is to have its Apache, an investment of money must be made in finding these highly talented individuals and paying them to make a new, open standard. And code must be made available for an end-to-end implementation on many platforms, everything from encoding to serving (with authentication fun, to boot) to decoding, on Windows, on Unix/Linux, on Macs. With regression tests and tutorials. Plug-ins to be written for the top, say, ten browsers. And a decoder library for Flash. While this is going on, political battles will have to be fought to keep Microsoft, Apple, and other companies out of the loop, or they'll pull the usual and destroy or cripple the product before it reaches market, just as they managed to poison HTML5's video standards.

None of this is technically impossible, but it will be hard, and it will cost money and political tokens and time and real effort. Can it be done?

.. which said that it was never that fusion was 50 years away, but that it was 500 billion dollars away. The fifty years was just an estimate based on how much funding, brainpower, and so forth went into it. Let's face it, you can't just put a basket in a storage locker with a placard atop it reading FUSION, then come back in fifty years and expect to find something in the basket.

We have not spent the large amounts of money required to do the research. When we do, it's in fits and starts, buffeted by people with ecodread and slavered over by those in the DOD who lust for some new level of destruction. It's always been easy to just ... drill another well. Blow up another mountaintop for coal that they assure us will be clean, this time around.

Human spaceflight is, at this time, an enormous waste and will remain so for decades.

We need a Beanstalk and variants thereof to get canned monkeys up into space at a reasonable price point, and we need semi-autonomous probes and drones to build the colonies on ... wherever, because this is not like the Frontier. You can't just stumble onto the Martian surface, chop down some trees, build a lean-to, then set traps for bunnies. We need drones to skitter through the Asteroid Belt, locate nickel-iron rich rocks, then smelt them down with either fusion (unlikely), fission (environmentally terrifying), or solar power to build three meter thick slabs of metal to shield the helpless, bored primates from the oncoming sleet of cosmic rays and other charming particles as they take a two year trek. By the time they get there, hardy robots will have needed to build an enormous infrastructure to support now less-healthy monkeys in an environment not particularly compatible with terrestrial life of more than a few dozen cells in scope.

We do not have the robotics and IT to make this happen. Instead, we get a metric/English issue and we slam probes down onto the surface of Mars.

Let me know when we get some reasonable colonization and return thereof from Antarctica. It's a far more welcoming environment. It's just not !!!SPACE!!! and therefore science-fiction fans everywhere do not get all excited about it.

Now I know everyone will get all excited about Tang and freeze-dried foods and all of the wonderful things we got out of our last serious space program. Great. What have we gotten since the Shuttle got started? Well, not much. Because we're doing the same old approach and have solved all of the technical issues encountered in doing that approach. If we use that approach to get to Mars, we will develop few new technologies.

Or we could build the aforementioned probes and drones. We'd learn a lot from that. Sending some folks to the Moon again? Not really.