Right, I agree, but I said "right to modify any software for Windows in any way they saw fit", not just any software they distribute. Debian has always been clear that the only supported way to get software onto their system is via their repositories, and that they reserve the right to patch software in their repositories as they see fit. It'd be sorta like Windows only accepting software from the Microsoft Download service, and Microsoft insisting on being able to modify the code of, say, Skype.
Well, not necessarily. The most serious Debian packaging bug I've investigated myself was when they decided that the regedit utility was not an important part of Wine and separated it into an optional (not installed by default) wine-utils package. Simple change to the package definitions.
Except that regedit is not optional. It's often invoked by installers, which expect it to be there. You can't install Windows without regedit, so these installers typically never check if it worked or not. They just assume it did, and the programs then assume the registry keys exist (because if you installed the software, they must exist) and crashed when they didn't. It took a long time to figure this one out, and even longer to get them to fix it.
I stand corrected. That's a pretty odd mistake for Ben to make.
Still, I remain pissed off - I think I narrowly avoided this problem (my Debian is old enough that it predates the patch) but this is still the latest example of a series of problems that Debian has introduced into software its packaged (including software I've worked on).
It's Debian, I don't think they background check at all. For the longest time the official Debian Wine packager worked for TransGaming, a company with very clear financial motives to make Wine not work well. It wasn't exactly a secret.
I'm sure it was just an accident, but for all we know, the guy could be working for the Russian mafia.
Right, that's why Debian renames Firefox. I remember them not being very happy about being forced to do that at the time. But seriously, are all open source projects supposed to use trademarks to force distributors hands? It seems like a bad precedent.
No, he posted a question openssl-dev, which is a mailing list for people writing software that uses OpenSSL. This OpenSSL developer doesn't read it and that's similar with most open source project - developers often don't read mailing lists for end users.
What's more, that mail doesn't contain a patch. It contains a misleading question with two lines posted in isolation. An actual patch, submitted for an actual code review, would almost certainly have revealed the problem via context.
You don't change crypto code of all things based on an idle question on a mailing list populated mostly by users. What's next, changing the kernel scheduler based on a conversation in #kernel-newbies?
The problem is that the email is rather misleading, from what I understand. It talks about two places causing the problem even though only one of them actually was making valgrind complain (and you can see, purify already picked up on the problem some time before). The trick is that his patch, not included in the email, removed both calls. Which was busted. So if he'd actually sent a full patch, proposed it for inclusion and had it properly code reviewed, the mistake would probably have been caught.
Well apparently, the patch that removed the uninitialized memory as a source of randomness, managed to remove lots of other sources (all of them?) as well. So it sounds possible that/dev/random isn't used either, yes.
He would have been told, but who says he would have cared? This happens all the time, although usually it doesn't result in a giant fucking security hole. I was warning people this sort of thing would happen more than two years ago back when I was working on autopackage. It was entirely predictable.
Having distributors randomly change source code as they package it is fundamentally broken. It cannot ever work. It's not just OpenSSL that's been broken like this. Wine often went through periods in which the Debian packages were completely hosed in subtle ways. It would look like a bug in Wine, but was in fact due to parts of the software "going away", because the Debian packager felt they weren't important enough to be a part of the base install. Pointing out that their change was broken didn't help. The result was many, many hours wasted tracking down non-bugs. Then you go through a giant waste of time trying to get the bug in the packages fixed, and just as you finally get it sorted out, some other distribution introduces some other bug into their packages.
So I got sick of this, and started telling people to avoid their distros packages. Some distributors (especially Debian) took it personally and started childish slanging matches. But really, who cares how "integrated" a program is, if it could have had arbitrary bugs silently introduced? It's just a busted model of software distribution.
Imagine if Microsoft reserved the right to modify any software for Windows in any way it saw fit! Yet that's exactly what Debian (and Fedora and Mandrake and Ubuntu) said to me - they reserve the right to make any modifications they like to the software they ship, and if upstream don't like it, tough luck.
I wonder if they'll re-evaluate that policy in light of this disaster. Probably not.
The piracy rates for modern games are astonishing. I'll give you a hint - usually, the number of pirates is far larger than the number of paying customers. Thus most "customers", if you can call them that, are in fact thieves.
So why do you need the password if you're only allowed to activate once? I don't really understand this scheme, sorry. Besides, you're assuming it's hard to fake an activation. It probably wouldn't be.
Well not really. Epic and ID have both said publically that the reason they've moved towards cross-platform (console) gaming is that they have a serious piracy problem on the PC platform. So presumably, their simple systems don't work so well. Ditto for games like Crysis.
No, that's not correct. It does "hurt the pirates" and for the good schemes it can be statistically proven to be true. The developers of, I think Heros, published some very interesting statistics on their experience with StarForce if you want to find the figures I'm thinking of, but I've seen similar stories repeated by other game devs.
Look. Very few high-budget games are released without DRM. I know this is an emotional issue for a lot of Slashdotters, but the number of people here assuming they're smarter than, well, almost every game publisher in the world is pretty sad to see. Do you really think they pay for expensive DRM systems over and over again if it loses them money? Even if you assume some of them are completely dysfunctional, we're not talking about a few publishers. We're talking about the vast majority.
DRM does work. It does not last forever, but it was never intended to anyway. The success of a PC video game DRM system is the time-to-crack. For good schemes this can be measured in months. For bad schemes it can be measured in days, or even be negative.
The majority of a copies of a game are sold within the months following its release. After a year, sales of a typical game are minimal and if you lose them, well, no big deal. So if your DRM scheme holds up 6 months, that's 6 months with no piracy. It's well understood in the industry that the DRM cracking problem comes from people who just don't want to pay for the game. Very few are pure hearted people who conscientiously want to make backups of their disks. Some of those people will never pay for the game, ever, and some of them will pay for the game when it becomes clear that a crack isn't coming out anytime soon (because they want to play the latest thing, with their friends, etc).
So, holding on for a few months can increase sales quite significantly. It's a simple economic equation - how much do you pay for the DRM vs how many extra sales do you get as various wannabe-pirates "time out" and decide to buy the game anyway?
On another PC related note, we pulled some disturbing numbers this past week about the amount of PC players currently playing Multiplayer (which was fantastic). What wasn't fantastic was the percentage of those numbers who were playing on stolen copies of the game on stolen / cracked CD keys of pirated copies (and that was only people playing online).
Not sure if I can share the exact numbers or percentage of PC players with you, but I'll check and see; if I can I'll update with them. As the amount of people who pirate PC games is astounding. It blows me away at the amount of people willing to steal games (or anything) simply because it's not physical or it's on the safety of the internet to do.
If you want to see what a good DRM system can achieve compare the piracy rates of console games vs PC games. Obviously due to its nature the PC versions will not get close to such low rates anytime soon, but the contrast is remarkable (I've read a game developer blog where they searched for torrents of their game for XBox 360 vs PC and the difference in number of torrents/downloaders was huge).
Abandoning open source means abandoning constructionism to some extent as well, since whatever closed-source binaries you use are opaque and unavailable for exploration.
You're mixing up "closed source" with "interpreted". There's no reason why the OLPC software could not have been written in C++ or hell, even D for all I care, and still allowed children so inclined to explore it. This would have been a much more sane approach because it would have meant that the 99% of users who aren't going to learn programming to get a more responsive and capable system that can do more with less, whilst the 1% who cared could grab an SDK from the school server and see the source code there. Done properly it doesn't need to be much harder to change the code.
Anyway, the whole idea that kids are going to learn programming by reading the Sugar codebase is laughable. Have you actually read it? Here, try it for yourself. That's some of the code that manages the pop-out frame around the edges. Observe that there are no comments, except for the occasional cryptic fixme like. Hippo? I haven't been out of the Linux scene for that long, but even so I'm thinking "what's Hippo"? Trying to learn programming by reading Sugar is like trying to learn industrial engineering by looking at a bridge. It isn't going to happen.
BTW, I say this as somebody who did learn programming as a child (around 6 or 7). I remember the process pretty well. It would not have been possible without my father who was not only a skilled programmer, but also amazingly patient.
You're blaming Microsoft for this, but I think that's a little naive personally. OLPC is about "empowering children", if by that you mean getting educational software into their hands.
The original plan was to use Linux, and they gave the task of doing the software bits to Red Hat. As it happens, Red Hat chose to make OLPC into a user interface research project, which - to put it bluntly - was not compatible with the sort of timeline OLPC was shooting for with the hardware.
When Negroponte said that "Sugar didn't have an architect who did it in a crisp way" I think he was being polite. Sugar is tremendously exciting as a melting pot of new GUI ideas, but invariably, some of those ideas won't work, or they'll work but just won't be improvements on the current way we do things. When I first played with Sugar I was expecting many years of field testing, but no - they just built the damn thing, with apparently no usability testing at all, they built it entirely in Python which is exactly the wrong language to use if you want a good user experience on a constrained device, the result sucked and Negroponte started looking for alternatives.
The story here is not that OLPC "sold out" or their pure intentions were "corrupted by Microsoft". That's garbage. Microsoft don't have mind control powers. The story is that OLPC and specifically Red Hat screwed up with Sugar by producing something raw and unfinished. Windows, for all its faults, does actually work and is somewhat usable by large numbers of people in the third world who likely already have light exposure to computers via internet cafes.
Oh, and contrary to popular opinion Windows is pretty lightweight compared to Sugar for what it does (which is a lot). Remember that it originated in a world where 8MB of RAM was a lot. Once you strip out all the extra stuff that you don't need on a fixed hardware profile, you're left with a highly optimized C++ codebase that I'm sure Microsoft would love to tweak even further for the OLPC hardware. It's not clear to me at all that an entirely Python based shell can ever beat Windows in memory usage or CPU efficiency.
It's too late anyway. Presumably the Kraken authors aren't stupid and will find out about this soon, at which point expect the vulnerability to disappear.
You didn't say what kind of software you're writing. Personally, I think using Python for large codebases is shooting yourself in the foot (I've seen it tried several times and the results were never pleasant).
Problems Python has that C++ doesn't (imho) - Python is oddly easier to write than read in my experience, because it's so dynamic. The result is that it's a lot of fun to write and really no fun at all to try and figure out when you're new to a codebase, because you can'
Python doesn't even try and be efficient. Fans of Python tend to say that it doesn't matter because either performance doesn't matter for their application, or because they can write the hot-spots in C. Well, for a lot of apps there aren't really any well defined hotspots after some optimisation. Instead the app just chugs. Look at the fate of Chandler or Sugar for instance. You can't fix that kind of thing by jucidiously rewriting the bottlenecks in C because there isn't one bottleneck - it's death by a thousand cuts. This is especially true of memory-constrained environments like desktop software. I've seen way too many apps where the developers clearly thought they'd "make it fast later" and then discovered that they didn't understand performance like they thought...
It's rather hard to distribute Python apps without distributing a giant runtime with them as well. For many apps that doesn't matter, but if you want people to download your app, it's going to hurt. Any consumer desktop app for instance...
Really? I'd be kinda surprised if an 11-year-old can figure out the Sugar code. I looked at how feasible it'd be to modify BlockParty here. Basically, there are no quality bars for Sugar code - some of the shipped apps have no comments or other documentation whatsoever. What's more, they use advanced APIs and techniques. Python doesn't really improve the readability either, as you have the same problem you have when reading any large Python codebase - there are no type declarations to help you find your way around.
So let me get this straight.. I leave myself at the mercy of google in order to save the cost of IT administration? That doesn't sound like a good business decision.
The point about App Engine is that it's based on Google technologies like BigTable and GFS (along with a bunch of others that I can't talk about, but are equally cool). The real saving is not on IT administration but on the enormous pain of scaling up your infrastructure as the site grows.
The IT industry is littered with companies that failed the scaling challenge and lost their advantage. Friendster is the canonical example. You really don't want to build a successful business and then see it fall over and die because you aren't equal to the challenge of resharding your MySQL databases every month.
But wait. There are other advantages. App Engine is really a platform for Google to expose its technology to others. Scalable databases is only one part of it. There are plenty of other advantages to running on top of the Google platform. I haven't had a chance to check out the videos yet, so I'd rather not shoot my mouth off, but seriously - the stuff we have here simplifies a *lot* of annoying goop that otherwise you'd have to handle yourself (managing datacenters being only one obvious example).
Having seen for myself what it takes to run a large, popular website at a high degree of availability, I'm pretty excited about the launch of this service (disclaimer: I work for Google but not on App Engine). It means people can spend more time writing interesting software and less time on crap like debugging database replication and figuring out the annoying parts of how to geocode Japanese street addresses - cuz we do it for you.
I don't really get WoW. A colleague of mine loves it and invited me round to his place to play it with him one day (he plays it with his girlfriend, to banish one stereotype).
Anyway, I played it for about an hour I guess and found it pretty dull. I mean, the scenery was pretty, but seeing as the whole point is role-playing I felt there should be at least some immersion in the game world. But there's no collision detection between players and most cities are full of inane chatter in pidgin English (like most multiplayer games I guess). The world was also amazingly static. I mean, I know the game is getting old, but even so - the NPCs just stood there doing squat.
So chalk me up as somebody who played it and wasn't instantly struck down with addiction. Maybe it's a personality thing. I don't play online multiplayer games that often but when I do it's usually something like Call of Duty - something you can drop into, play for exactly how much time you {have available/feel like} and then leave. No commitment. Of course you tend to get killed a lot like that so it's not for people who are sore losers:)
Slashdot Mirror
What makes you think Sugar is fast, reliable and stable? Last time I tried it, it was extremely slow and buggy.
Right, I agree, but I said "right to modify any software for Windows in any way they saw fit", not just any software they distribute. Debian has always been clear that the only supported way to get software onto their system is via their repositories, and that they reserve the right to patch software in their repositories as they see fit. It'd be sorta like Windows only accepting software from the Microsoft Download service, and Microsoft insisting on being able to modify the code of, say, Skype.
Well, not necessarily. The most serious Debian packaging bug I've investigated myself was when they decided that the regedit utility was not an important part of Wine and separated it into an optional (not installed by default) wine-utils package. Simple change to the package definitions.
Except that regedit is not optional. It's often invoked by installers, which expect it to be there. You can't install Windows without regedit, so these installers typically never check if it worked or not. They just assume it did, and the programs then assume the registry keys exist (because if you installed the software, they must exist) and crashed when they didn't. It took a long time to figure this one out, and even longer to get them to fix it.
I stand corrected. That's a pretty odd mistake for Ben to make.
Still, I remain pissed off - I think I narrowly avoided this problem (my Debian is old enough that it predates the patch) but this is still the latest example of a series of problems that Debian has introduced into software its packaged (including software I've worked on).
It's Debian, I don't think they background check at all. For the longest time the official Debian Wine packager worked for TransGaming, a company with very clear financial motives to make Wine not work well. It wasn't exactly a secret.
I'm sure it was just an accident, but for all we know, the guy could be working for the Russian mafia.
Right, that's why Debian renames Firefox. I remember them not being very happy about being forced to do that at the time. But seriously, are all open source projects supposed to use trademarks to force distributors hands? It seems like a bad precedent.
No, he posted a question openssl-dev, which is a mailing list for people writing software that uses OpenSSL. This OpenSSL developer doesn't read it and that's similar with most open source project - developers often don't read mailing lists for end users.
What's more, that mail doesn't contain a patch. It contains a misleading question with two lines posted in isolation. An actual patch, submitted for an actual code review, would almost certainly have revealed the problem via context.
You don't change crypto code of all things based on an idle question on a mailing list populated mostly by users. What's next, changing the kernel scheduler based on a conversation in #kernel-newbies?
The problem is that the email is rather misleading, from what I understand. It talks about two places causing the problem even though only one of them actually was making valgrind complain (and you can see, purify already picked up on the problem some time before). The trick is that his patch, not included in the email, removed both calls. Which was busted. So if he'd actually sent a full patch, proposed it for inclusion and had it properly code reviewed, the mistake would probably have been caught.
Well apparently, the patch that removed the uninitialized memory as a source of randomness, managed to remove lots of other sources (all of them?) as well. So it sounds possible that /dev/random isn't used either, yes.
He would have been told, but who says he would have cared? This happens all the time, although usually it doesn't result in a giant fucking security hole. I was warning people this sort of thing would happen more than two years ago back when I was working on autopackage. It was entirely predictable.
Having distributors randomly change source code as they package it is fundamentally broken. It cannot ever work. It's not just OpenSSL that's been broken like this. Wine often went through periods in which the Debian packages were completely hosed in subtle ways. It would look like a bug in Wine, but was in fact due to parts of the software "going away", because the Debian packager felt they weren't important enough to be a part of the base install. Pointing out that their change was broken didn't help. The result was many, many hours wasted tracking down non-bugs. Then you go through a giant waste of time trying to get the bug in the packages fixed, and just as you finally get it sorted out, some other distribution introduces some other bug into their packages.
So I got sick of this, and started telling people to avoid their distros packages. Some distributors (especially Debian) took it personally and started childish slanging matches. But really, who cares how "integrated" a program is, if it could have had arbitrary bugs silently introduced? It's just a busted model of software distribution.
Imagine if Microsoft reserved the right to modify any software for Windows in any way it saw fit! Yet that's exactly what Debian (and Fedora and Mandrake and Ubuntu) said to me - they reserve the right to make any modifications they like to the software they ship, and if upstream don't like it, tough luck.
I wonder if they'll re-evaluate that policy in light of this disaster. Probably not.
The piracy rates for modern games are astonishing. I'll give you a hint - usually, the number of pirates is far larger than the number of paying customers. Thus most "customers", if you can call them that, are in fact thieves.
So why do you need the password if you're only allowed to activate once? I don't really understand this scheme, sorry. Besides, you're assuming it's hard to fake an activation. It probably wouldn't be.
Well not really. Epic and ID have both said publically that the reason they've moved towards cross-platform (console) gaming is that they have a serious piracy problem on the PC platform. So presumably, their simple systems don't work so well. Ditto for games like Crysis.
No, that's not correct. It does "hurt the pirates" and for the good schemes it can be statistically proven to be true. The developers of, I think Heros, published some very interesting statistics on their experience with StarForce if you want to find the figures I'm thinking of, but I've seen similar stories repeated by other game devs.
Look. Very few high-budget games are released without DRM. I know this is an emotional issue for a lot of Slashdotters, but the number of people here assuming they're smarter than, well, almost every game publisher in the world is pretty sad to see. Do you really think they pay for expensive DRM systems over and over again if it loses them money? Even if you assume some of them are completely dysfunctional, we're not talking about a few publishers. We're talking about the vast majority.
DRM does work. It does not last forever, but it was never intended to anyway. The success of a PC video game DRM system is the time-to-crack. For good schemes this can be measured in months. For bad schemes it can be measured in days, or even be negative.
The majority of a copies of a game are sold within the months following its release. After a year, sales of a typical game are minimal and if you lose them, well, no big deal. So if your DRM scheme holds up 6 months, that's 6 months with no piracy. It's well understood in the industry that the DRM cracking problem comes from people who just don't want to pay for the game. Very few are pure hearted people who conscientiously want to make backups of their disks. Some of those people will never pay for the game, ever, and some of them will pay for the game when it becomes clear that a crack isn't coming out anytime soon (because they want to play the latest thing, with their friends, etc).
So, holding on for a few months can increase sales quite significantly. It's a simple economic equation - how much do you pay for the DRM vs how many extra sales do you get as various wannabe-pirates "time out" and decide to buy the game anyway?
Of course it's not 100% business, there's an emotional aspect to it as well. Consider a developer at Infinity Ward and his perspective:
If you want to see what a good DRM system can achieve compare the piracy rates of console games vs PC games. Obviously due to its nature the PC versions will not get close to such low rates anytime soon, but the contrast is remarkable (I've read a game developer blog where they searched for torrents of their game for XBox 360 vs PC and the difference in number of torrents/downloaders was huge).
Downloading free games isn't fair use, obviously.
You're mixing up "closed source" with "interpreted". There's no reason why the OLPC software could not have been written in C++ or hell, even D for all I care, and still allowed children so inclined to explore it. This would have been a much more sane approach because it would have meant that the 99% of users who aren't going to learn programming to get a more responsive and capable system that can do more with less, whilst the 1% who cared could grab an SDK from the school server and see the source code there. Done properly it doesn't need to be much harder to change the code.
Anyway, the whole idea that kids are going to learn programming by reading the Sugar codebase is laughable. Have you actually read it? Here, try it for yourself. That's some of the code that manages the pop-out frame around the edges. Observe that there are no comments, except for the occasional cryptic fixme like. Hippo? I haven't been out of the Linux scene for that long, but even so I'm thinking "what's Hippo"? Trying to learn programming by reading Sugar is like trying to learn industrial engineering by looking at a bridge. It isn't going to happen.
BTW, I say this as somebody who did learn programming as a child (around 6 or 7). I remember the process pretty well. It would not have been possible without my father who was not only a skilled programmer, but also amazingly patient.
You're blaming Microsoft for this, but I think that's a little naive personally. OLPC is about "empowering children", if by that you mean getting educational software into their hands.
The original plan was to use Linux, and they gave the task of doing the software bits to Red Hat. As it happens, Red Hat chose to make OLPC into a user interface research project, which - to put it bluntly - was not compatible with the sort of timeline OLPC was shooting for with the hardware.
When Negroponte said that "Sugar didn't have an architect who did it in a crisp way" I think he was being polite. Sugar is tremendously exciting as a melting pot of new GUI ideas, but invariably, some of those ideas won't work, or they'll work but just won't be improvements on the current way we do things. When I first played with Sugar I was expecting many years of field testing, but no - they just built the damn thing, with apparently no usability testing at all, they built it entirely in Python which is exactly the wrong language to use if you want a good user experience on a constrained device, the result sucked and Negroponte started looking for alternatives.
The story here is not that OLPC "sold out" or their pure intentions were "corrupted by Microsoft". That's garbage. Microsoft don't have mind control powers. The story is that OLPC and specifically Red Hat screwed up with Sugar by producing something raw and unfinished. Windows, for all its faults, does actually work and is somewhat usable by large numbers of people in the third world who likely already have light exposure to computers via internet cafes.
Oh, and contrary to popular opinion Windows is pretty lightweight compared to Sugar for what it does (which is a lot). Remember that it originated in a world where 8MB of RAM was a lot. Once you strip out all the extra stuff that you don't need on a fixed hardware profile, you're left with a highly optimized C++ codebase that I'm sure Microsoft would love to tweak even further for the OLPC hardware. It's not clear to me at all that an entirely Python based shell can ever beat Windows in memory usage or CPU efficiency.
It's too late anyway. Presumably the Kraken authors aren't stupid and will find out about this soon, at which point expect the vulnerability to disappear.
Because people are afraid to find out if it's enforceable or not (it's probably not, but do YOU want to argue with Apples lawyers?)
Yeah, exactly. They're too large as well :)
You didn't say what kind of software you're writing. Personally, I think using Python for large codebases is shooting yourself in the foot (I've seen it tried several times and the results were never pleasant).
Problems Python has that C++ doesn't (imho) - Python is oddly easier to write than read in my experience, because it's so dynamic. The result is that it's a lot of fun to write and really no fun at all to try and figure out when you're new to a codebase, because you can'
Python doesn't even try and be efficient. Fans of Python tend to say that it doesn't matter because either performance doesn't matter for their application, or because they can write the hot-spots in C. Well, for a lot of apps there aren't really any well defined hotspots after some optimisation. Instead the app just chugs. Look at the fate of Chandler or Sugar for instance. You can't fix that kind of thing by jucidiously rewriting the bottlenecks in C because there isn't one bottleneck - it's death by a thousand cuts. This is especially true of memory-constrained environments like desktop software. I've seen way too many apps where the developers clearly thought they'd "make it fast later" and then discovered that they didn't understand performance like they thought ...
It's rather hard to distribute Python apps without distributing a giant runtime with them as well. For many apps that doesn't matter, but if you want people to download your app, it's going to hurt. Any consumer desktop app for instance ...
Really? I'd be kinda surprised if an 11-year-old can figure out the Sugar code. I looked at how feasible it'd be to modify BlockParty here. Basically, there are no quality bars for Sugar code - some of the shipped apps have no comments or other documentation whatsoever. What's more, they use advanced APIs and techniques. Python doesn't really improve the readability either, as you have the same problem you have when reading any large Python codebase - there are no type declarations to help you find your way around.
What I want to know is what text-to-speech engine was used in the video. Damn, that is the best one I heard yet.
The point about App Engine is that it's based on Google technologies like BigTable and GFS (along with a bunch of others that I can't talk about, but are equally cool). The real saving is not on IT administration but on the enormous pain of scaling up your infrastructure as the site grows.
The IT industry is littered with companies that failed the scaling challenge and lost their advantage. Friendster is the canonical example. You really don't want to build a successful business and then see it fall over and die because you aren't equal to the challenge of resharding your MySQL databases every month.
But wait. There are other advantages. App Engine is really a platform for Google to expose its technology to others. Scalable databases is only one part of it. There are plenty of other advantages to running on top of the Google platform. I haven't had a chance to check out the videos yet, so I'd rather not shoot my mouth off, but seriously - the stuff we have here simplifies a *lot* of annoying goop that otherwise you'd have to handle yourself (managing datacenters being only one obvious example).
Having seen for myself what it takes to run a large, popular website at a high degree of availability, I'm pretty excited about the launch of this service (disclaimer: I work for Google but not on App Engine). It means people can spend more time writing interesting software and less time on crap like debugging database replication and figuring out the annoying parts of how to geocode Japanese street addresses - cuz we do it for you.
I don't really get WoW. A colleague of mine loves it and invited me round to his place to play it with him one day (he plays it with his girlfriend, to banish one stereotype).
Anyway, I played it for about an hour I guess and found it pretty dull. I mean, the scenery was pretty, but seeing as the whole point is role-playing I felt there should be at least some immersion in the game world. But there's no collision detection between players and most cities are full of inane chatter in pidgin English (like most multiplayer games I guess). The world was also amazingly static. I mean, I know the game is getting old, but even so - the NPCs just stood there doing squat.
So chalk me up as somebody who played it and wasn't instantly struck down with addiction. Maybe it's a personality thing. I don't play online multiplayer games that often but when I do it's usually something like Call of Duty - something you can drop into, play for exactly how much time you {have available/feel like} and then leave. No commitment. Of course you tend to get killed a lot like that so it's not for people who are sore losers :)