You're using Internet Explorer, aren't you? Turn in your geek card, you're not welcome here.:P
Canvascape uses Google's IE Adapter to provide Canvas support. It's functional, but not particularly quick. If you try it in Firefox/Seamonkey or Opera, I think you'll find performance to be at least an order of magnitude better. There's no frame counter, but I'd estimate that I get about 30 frames per second. Which isn't bad for a software implementation of a 3D game, programmed in Javascript!
Psst, Buddy! Applets != Java. Applets are dead. Java is not. Clear?
I say this as a Java developer of 11 years. (1996, baby!) Yet I am perfectly happy logging in and telling the world that Applets are dead. In fact, I can't wait for them to become a distant memory. They have done so much to tarnish the reputation of Java that it's not even funny. Java has found much better uses in a variety of other industries. It's time to let DHTML and AJAX mature into the role of rich web content.
To be clear, Shockwave was the older technology that Flash originally piggybacked on to get its foot in the door.
Agreed. However, Shockwave had a variety of advanced technologies developed after Flash that were unavailable to Flash until recently. (Some never made it there.) Features like Hardware 3D and Classic Console Emulators seem like they should have kept Shockwave on the map. Unfortuantely, they didn't. So Macromedia/Adobe have been smart by running with what works.
Sun did a similar thing to Java with the J2ME spec. J2ME is the cutdown version of Java that far surpassed its big brother in end-user popularity. The only difference is that J2ME had to change platforms to do it.:(
Michael Swaine. Dr. Dobbs Journal. Yeah sure. Geez, what a pretentious twat you are.
I think your own post shows far more pretentiousness than mine does. I have the highest respect for Mr. Swaine, and the work he has done in the field of computer journalism. But that doesn't mean that everyone always expresses themselves clearly, or even have a solid enough concept of what they wish to communicate on paper. (As a fellow author - no, I'm not talking about blogging - I can identify.)
Fundamentally, I'm not disagreeing with Mr. Swaine. Only expounding on what he's attempting to say, and (hopefully) removing his confusion. If and when he reads this (which is a very likely possibility), I hope he thinks, "Yes! That is exactly what I was thinking!":)
I bet 10 bucks that Mr. Eckel's 3D card drivers are out of date or not installed....in which case Java should fail gracefully and warn the user of this fact. Just failing without any further info is inexcusable, regardless of the configuration issues.
Agreed. However, the problem is not one of Java, but rather poor error trapping by the programmer. He should have handled the situation where OpenGL couldn't be initialized rather than assuming that the context will always exist. The same problem exists in many C/C++ programs.
Bzzzt, sorry, this scenario has already failed the Mom Test. Mom doesn't want to debug an app... she doesn't even know what "debug" means.
"Mom" doesn't debug an app. "Mom" would troubleshoot to the best of her abilities. (Which, I'm afraid would not be very considerable.) Mr. Eckel asked how you would debug such an app. I answered.:)
I think there are a lot of things wrong with Java, one being the existence of something called JavaScript.
I think it's also important to point out that 95% of those who claim to know Javascript, don't know the first thing about writing it. I was just discussing "hardcore" Javascript with a fellow the other day. His opinion appeared to be that Internet Explorer was a lot easier to write code for than Opera. He never followed up on my reply, but I have a sneaky suspicion that he would have produced code like this:
document.getElementById("thething").innerHTML = "<div>Lots of wacko HTML here</div>"; [...] <body onclick="doSomething();"> <a href="javascript:alert('Phear my mad skillz!')"> <p id="thething"></p> </body>
It's so incredibly difficult to open the eyes of coders to the scalable, Object Oriented world of Javascript when they are so used to integrating cutsey scripts into their pages.:(
Java was "wrong". The technology seemed like a good fit to webbrowsers, but the implementation focused more on the type of functionality that Canvas and Flash offer rather than acting in a more useful role as a DOM Scripting language. Had Java taken the latter route (which would have required that the JVM be loaded at all times), it might have been more successful in that space. Unfortunately, by the time anyone got around to pushing Java into the DOM Scripting space, the implementation was screwed up by poor Livescript interfacing.
Computers are faster now, and the bandwidth is much, much greater (for most of us). AJAX can do some things, but it just seems like a mess of different technologies to me, and still isn't as rich as a general client-side programming language.
AJAX/DHTML is still a very young industry, partly because ubiquitous DOM Support is still a very new thing. (No thanks to Microsoft's inability to support the specs. Grrr.) If and when the WHATWG specs are ratified, I think you'll see a massive uptake in the capabilities of the average application.
If you still don't believe me, take a look at Canvascape and tell me that the prerelease technology isn't already impressive. All without sacrificing the existing Javascript/DOM design.:)
To be clear, I'm not saying that Flash didn't eventually meet its goal. When Flash was first introduced, we ended up with entire websites written in Flash. Not to mention the overriding need to add those damn animations to corporate websites in the same manner that everyone's homepage had a reflecting pool or tree menu Java Applet.
Flash would have lost out as badly as Java, but judicious use of the plugin combined with an extremely small runtime brought it back from the brink of failure. But only flash. You'll notice that the spinoff technologies like Shockwave have all but disappeared, except for particular circumstances like some Web Games. (The same area in which Java Applets continue to live on as Zombies.)
A common response to the "applets are dead" statement is "No they're not. I still use them." Applets aren't useless; people still create very impressive things with them. The Java Posse highlights one or more applets each week. The statement should instead read, "Applets are dead for Web RIAs." The installation process for the JRE and for any particular applet is not reliable enough for anyone to depend on them for a general-purpose website.
That's basically a fancy way of saying they're dead while simultaneously arguing the opposite. People still write software for the Colecovision, but you don't see anyone talking about the "missed opportunity" to compete with the Playstation, do you?
Desktop applications have also suffered, and left bad marks on Java in general, further sullying applets by association. I had an experience with a Java product called Memorex exPressit. The UI was terrible and buggy.
Poor UIs have been a hallmark of Java Applications. While much of the blame does lie heavily on inexperienced programmers doing GUI work, there's also the matter of Microsoft's interference with the platform. One of the reasons for Java's early popularity in applications was because Microsoft provided an excellent AWT implementation that integrated with their platform. Which was exactly how Sun wanted it. The most experienced company with a platform (i.e. the vendor) would handle the specific implementation of the JVM. The Sun JVM was just a reference implementation, and was not intended for deployment.
Then Microsoft went about their usual backstabbing and Sun didn't have a good feel for how to replace their expertise. The rest is history.
Consider Corel's attempt to create a word processor using Java (I don't remember whether they were trying to port WordPerfect or write something from scratch). It was obviously too early to try it, since all they had was the AWT.
Well, that and the fact that they were trying to write it as an Applet. I mean, you don't just take a full up office suite and cram it into a tiny portion of a Web Browser window! That's not exactly a recipe for a good interface. The Corel concept was good on paper, but the implementation was outright horrid. Unfortuantely, it was probably caused by the misconception that Java == Applets. Something that we programmers still struggle with today.
OpenOffice is not written in Java, but in C++. I don't believe it was because the programmers wanted to struggle with the cross-platform issues presented by C++. It was speed, and perhaps the need to more directly control the underlying platform.
Or maybe it had something to do with the fact that OpenOffice was based on StarOffice? You know, the Office Suite that was developed back in 1986? However, there are a number of modern OOo components that are written in Java. Database Access in particular is a lot better if you can rely on Java's APIs.
The show-stopper was Java's lack of support for MP3s and multimedia in general. As Dick Wall of the Java Posse has pointed out numerous times, the Java Media Framework (JMF) has been virtually ignored for many years.
Um... what? JMF is ignored because it's unnecessary. Java has Sound and MIDI APIs integrated into its core. MP3 support can be found in APIs like JavaLayer. Video has always been a problem, and not just Java. While there have always been solutions for standardized formats, the majority of video encoding/decoding takes advantage of proprietary codecs. Something that is not easy (or legal) to replicate. Linux makes use of a number of legal loopholes to bring us software like MPlayer and VLC. But these were never viable solutions for a straight-laced company like Sun. And the idea of better OS integration was something of an antithesis to Java technology. So Java focused on its strengths, not its weaknesses.
Mr. Eckel seems to forget that Java Applets were quite popular back in their day. But for much of the same reason that web users balked at Flash and Plugins, web users balked at Java. It was large, slowed down the browsing experience, and just didn't integrate all that well with the webpage.
Java eventually found its niche in server side programming. At that point Java Applets died. They were a nice idea, but they're effectively dead now and the web is better for it. There was no missed opportunity, only an opportunity that didn't pan out. In exchange, however, Java gained new opportunities in consumer areas like Video Game Development. Commercial games are slowly starting to deploy Java technology. But since one OpenGL/DirectX game looks just like another, who can tell it's Java? And that's a beautiful situation to be in.:)
Oh, and guess what's driving many (most?) of the SOAP/XML/RPC interfaces that AJAX applications use? You guessed it.;)
JNLP, a.k.a. Java WebStart, was supposed to solve some of these problems to create easy-install desktop applications. I think the reason that JNLP hasn't become commonly used can be summed up by looking at https://aerith.dev.java.net/, a page for one of the flagship "Cool JavaOne Demos." If you click on the JNLP version link on that page, it will appear to start up, downloading a bunch of stuff and asking you questions. And then it does nothing. No error messages or any information to tell you what happened. Repeated attempts yield the same results, only faster because the requisite files have already been downloaded. At least, that was my experience. If it worked for you, I'd say that's even worse--it randomly works on some platforms and not others. How do you debug such a thing?
I bet 10 bucks that Mr. Eckel's 3D card drivers are out of date or not installed. The application he linked to uses JOGL (Java OpenGL bindings), so if his computer is unable to run OpenGL, he will be unable to run the app. It's a rare issue, but it happens. The easy way of debugging the app is to either bring up the Java Console through the Coffee Cup in the system tray, or to go into the Java Web Start settings and enable the console (or logging!) there. Easy, peasy.:)
Oh, and Mr. Eckel? Web Technology has not yet begun to fight. At least if the WHATWG specs have anything to say about it.
It's difficult to precisely follow your vision in a quicky Slasdot post, but it sounds somewhat interesting. Have you considered snagging some free Blog space and doing a full writeup of your idea? At the very least, communicating the concept in detail can help you find problems and solutions that you haven't yet considered.:)
What is OpenGL? ODBC? SDL? XLib? They aren't part of the Operating System, and yet they're not programs. What are they?
Programmers think of them individually as APIs. Collectively, however, they add up to the platform the software targets. As long as that platform is available, the software is portable.
I think the author of the article is displaying a great deal of confusion over Operating Systems vs. Programming Platforms. Which is understandable. We've had the concept of "everything included on the CD is part of the operating system" idea drilled into our heads for the last decade or so. There has been little attempt to recognize how distinct different portions of today's "operating systems" actually are.
Consider for a moment: What is Debian on FreeBSD? Is it a FreeBSD operating system or a Linux operating system? Or is it a Frankenstein kitbash of both? The answer is, neither answer is correct. It is the FreeBSD kernel combined with the GNU Platform.
Separating the task of operating the hardware (traditionally the job of the kernel) from the higher level "platform" has a variety of implications. The most important implication is that the software is as portable as the platform is. It doesn't matter if the underlying kernel is FreeBSD, Linux, or Windows NT. If you software targets the GNU platform, it is portable across all those systems. At least at a source level, though binary compatibility is ideal.
Thus when programmers make the comment that Java "is like an Operating System", what they mean is that the Java Platform is sufficient to replace the platform that shipped with your operating system. While the focus is currently on integrating the disparate platforms, what you're starting to see is that the OS is taking a back seat to the platform. Programmers want portability across devices, and Information Technology wants more flexible deployment solutions. Combined, these two needs add up to a drive for further portability of platforms with an eye toward using the right kernel for the right deployment solution.
That is where "Operating Systems" are headed. Not the monoliths of yesteryear, but the flexibility to provide familiar functionality where you need it and when you need it.
Gmail still requires either an invation or the ability to receive text messages.
I haven't read the CNN article linked here, but I did read the article on my Wii last night. The long and short of it is that signup is geographically limited. Just about everyone not in North America is now able to sign up without going through the text message routine. The Google spokepeople have promised that North America will follow "soon".
IE's Javascript engine is excruciatingly slow. That's about the only serious complaint I have with it. For the most part, it does what I ask of it (just...very inefficiently, sometimes).
If you're coding to the DOM standards, how could IE possibly be doing what you want it to?
Opera, OTOH, almost always does what it's told when it's given DOM Compliant code. So unless you're not following the standards yourself, I can't see for a minute how "hardcore programming" in Javascript could be easier on IE than it is on Opera.
Specifically, what kind of bizarre behavior are you seeing? Are you sure it's actually as bizarre as you think it is, or are you perhaps giving it bizarre code? As they say in CompSci: Garbage In, Garbage Out.
What does source code have to do with anything? It's not like you have to target twelve different browsers when you develop. All you need to do is follow the DOM specs, then test on each browser to ensure that there are no quirks that need to be ironed out. It's not that hard.
In fact, it's a heck of a lot easier to support Firefox, Opera, Safari, and KHTML simultaneously than it is to support IE and Firefox. Why? Because the Microsoft programmers tell us how wonderful they are about supporting the W3C specs while ensuring that they do no such thing. So here we are, nearly seven years after the DOM Level 2 specifications became a W3C recommendation, and Microsoft still doesn't support it. Not even in their latest browser, which was released to (nay, forced upon) the public only 4 months ago!
Not that I'm despondent or anything. [...] Yeah, who am I kidding? I'm hopping mad that Microsoft promised standards compliance, and yet paid it only lip service at best! I'm not surprised in the slightest, I'm just mad. So much for the "new and more consumer friendly" Microsoft.
My advice is simple: Boycott IE. It's a cancer on the Web that must be stopped. IE isn't secure and isn't standards-compliant, which makes it unworkable both for end users and Web content creators.
Excellent point. I withdraw my point about the lack of an oath. I imagine it would still be incredibly hard to prosecute, however, for the reasons I stated.
The puzzle you're talking about isn't actually that hard. But IIRC, there's something about putting the crystal in its proper place before you can solve the puzzle. Or maybe you needed a scrap of metal. Something like that. Read the walkthrough if you're really stuck.:)
Honestly, why does it have to be Nintendo's job to save the adventure game?
Because it's Nintendo's job to save the industry from itself? The gaming industry has been on a headlong dive for extremely high mediocrity to high price ratios for a long time now. Only Nintendo has taken the time to step back and say, "Wait! Where are we going with this, again?" If Nintendo didn't take a stand, it's unlikely that anyone else in the industry would have.
It's like asking the question, "Why me?" The only good answer is, "If not you, then who else?"
Adventure games never really died. They just got lost in the massive push toward All Things 3D(TM). I'm happy to see that companies are starting to understand that these games are still popular, in the same way that RPGs are still popular both in 2D and 3D.
Translated to Marketeeringese: Good Adventure Games = $$$Ka Ching!$$$
While you're waiting, consider playing a little Stargate Adventure. It's short, but it will take you back.:)
I wonder if by firing off a C&D letter you're committing perjury if you're found to be wrong?
Unfortunately, no. IANAL, but my understanding is that Perjury requires proof of intent. Which means that they need to know that they're incorrect ahead of time. Since Viacom believes that their list of takedowns is correct to the best of their knowledge, there would be no perjury committed.
In any case, a DMCA notice would probably not be considered purjury. The sender took no oath to be truthful when they sent the notice. However, they could land in hot water for harrassment. It would be tricky to prosecute, but if you could show a significant degree of error in Viacom's takedown procedures, you could get them slammed with an injunction against sending DMCA notices. At least until a judge is fully convinced that Viacom has corrected the errors.
How about computer and television displays - will that likely ever surface?
Unlikely. At least anytime in the near-term. OLED technology is preferred in environments where small size, low power consumption, and low usage are valued. Under current technology, full size screens would die far too quickly. In addition, traditional LCD technology has been improving at a rapid pace.
Slashdot Mirror
You're using Internet Explorer, aren't you? Turn in your geek card, you're not welcome here.
Canvascape uses Google's IE Adapter to provide Canvas support. It's functional, but not particularly quick. If you try it in Firefox/Seamonkey or Opera, I think you'll find performance to be at least an order of magnitude better. There's no frame counter, but I'd estimate that I get about 30 frames per second. Which isn't bad for a software implementation of a 3D game, programmed in Javascript!
Psst, Buddy! Applets != Java. Applets are dead. Java is not. Clear?
I say this as a Java developer of 11 years. (1996, baby!) Yet I am perfectly happy logging in and telling the world that Applets are dead. In fact, I can't wait for them to become a distant memory. They have done so much to tarnish the reputation of Java that it's not even funny. Java has found much better uses in a variety of other industries. It's time to let DHTML and AJAX mature into the role of rich web content.
Agreed. However, Shockwave had a variety of advanced technologies developed after Flash that were unavailable to Flash until recently. (Some never made it there.) Features like Hardware 3D and Classic Console Emulators seem like they should have kept Shockwave on the map. Unfortuantely, they didn't. So Macromedia/Adobe have been smart by running with what works.
Sun did a similar thing to Java with the J2ME spec. J2ME is the cutdown version of Java that far surpassed its big brother in end-user popularity. The only difference is that J2ME had to change platforms to do it.
I think your own post shows far more pretentiousness than mine does. I have the highest respect for Mr. Swaine, and the work he has done in the field of computer journalism. But that doesn't mean that everyone always expresses themselves clearly, or even have a solid enough concept of what they wish to communicate on paper. (As a fellow author - no, I'm not talking about blogging - I can identify.)
Fundamentally, I'm not disagreeing with Mr. Swaine. Only expounding on what he's attempting to say, and (hopefully) removing his confusion. If and when he reads this (which is a very likely possibility), I hope he thinks, "Yes! That is exactly what I was thinking!"
Agreed. However, the problem is not one of Java, but rather poor error trapping by the programmer. He should have handled the situation where OpenGL couldn't be initialized rather than assuming that the context will always exist. The same problem exists in many C/C++ programs.
"Mom" doesn't debug an app. "Mom" would troubleshoot to the best of her abilities. (Which, I'm afraid would not be very considerable.) Mr. Eckel asked how you would debug such an app. I answered.
I think it's also important to point out that 95% of those who claim to know Javascript, don't know the first thing about writing it. I was just discussing "hardcore" Javascript with a fellow the other day. His opinion appeared to be that Internet Explorer was a lot easier to write code for than Opera. He never followed up on my reply, but I have a sneaky suspicion that he would have produced code like this: It's so incredibly difficult to open the eyes of coders to the scalable, Object Oriented world of Javascript when they are so used to integrating cutsey scripts into their pages.
Java was "wrong". The technology seemed like a good fit to webbrowsers, but the implementation focused more on the type of functionality that Canvas and Flash offer rather than acting in a more useful role as a DOM Scripting language. Had Java taken the latter route (which would have required that the JVM be loaded at all times), it might have been more successful in that space. Unfortunately, by the time anyone got around to pushing Java into the DOM Scripting space, the implementation was screwed up by poor Livescript interfacing.
AJAX/DHTML is still a very young industry, partly because ubiquitous DOM Support is still a very new thing. (No thanks to Microsoft's inability to support the specs. Grrr.) If and when the WHATWG specs are ratified, I think you'll see a massive uptake in the capabilities of the average application.
If you still don't believe me, take a look at Canvascape and tell me that the prerelease technology isn't already impressive. All without sacrificing the existing Javascript/DOM design.
To be clear, I'm not saying that Flash didn't eventually meet its goal. When Flash was first introduced, we ended up with entire websites written in Flash. Not to mention the overriding need to add those damn animations to corporate websites in the same manner that everyone's homepage had a reflecting pool or tree menu Java Applet.
Flash would have lost out as badly as Java, but judicious use of the plugin combined with an extremely small runtime brought it back from the brink of failure. But only flash. You'll notice that the spinoff technologies like Shockwave have all but disappeared, except for particular circumstances like some Web Games. (The same area in which Java Applets continue to live on as Zombies.)
That's basically a fancy way of saying they're dead while simultaneously arguing the opposite. People still write software for the Colecovision, but you don't see anyone talking about the "missed opportunity" to compete with the Playstation, do you?
Poor UIs have been a hallmark of Java Applications. While much of the blame does lie heavily on inexperienced programmers doing GUI work, there's also the matter of Microsoft's interference with the platform. One of the reasons for Java's early popularity in applications was because Microsoft provided an excellent AWT implementation that integrated with their platform. Which was exactly how Sun wanted it. The most experienced company with a platform (i.e. the vendor) would handle the specific implementation of the JVM. The Sun JVM was just a reference implementation, and was not intended for deployment.
Then Microsoft went about their usual backstabbing and Sun didn't have a good feel for how to replace their expertise. The rest is history.
Well, that and the fact that they were trying to write it as an Applet. I mean, you don't just take a full up office suite and cram it into a tiny portion of a Web Browser window! That's not exactly a recipe for a good interface. The Corel concept was good on paper, but the implementation was outright horrid. Unfortuantely, it was probably caused by the misconception that Java == Applets. Something that we programmers still struggle with today.
Or maybe it had something to do with the fact that OpenOffice was based on StarOffice? You know, the Office Suite that was developed back in 1986? However, there are a number of modern OOo components that are written in Java. Database Access in particular is a lot better if you can rely on Java's APIs.
Um... what? JMF is ignored because it's unnecessary. Java has Sound and MIDI APIs integrated into its core. MP3 support can be found in APIs like JavaLayer. Video has always been a problem, and not just Java. While there have always been solutions for standardized formats, the majority of video encoding/decoding takes advantage of proprietary codecs. Something that is not easy (or legal) to replicate. Linux makes use of a number of legal loopholes to bring us software like MPlayer and VLC. But these were never viable solutions for a straight-laced company like Sun. And the idea of better OS integration was something of an antithesis to Java technology. So Java focused on its strengths, not its weaknesses.
Java eventually found its niche in server side programming. At that point Java Applets died. They were a nice idea, but they're effectively dead now and the web is better for it. There was no missed opportunity, only an opportunity that didn't pan out. In exchange, however, Java gained new opportunities in consumer areas like Video Game Development. Commercial games are slowly starting to deploy Java technology. But since one OpenGL/DirectX game looks just like another, who can tell it's Java? And that's a beautiful situation to be in.
Oh, and guess what's driving many (most?) of the SOAP/XML/RPC interfaces that AJAX applications use? You guessed it.
I bet 10 bucks that Mr. Eckel's 3D card drivers are out of date or not installed. The application he linked to uses JOGL (Java OpenGL bindings), so if his computer is unable to run OpenGL, he will be unable to run the app. It's a rare issue, but it happens. The easy way of debugging the app is to either bring up the Java Console through the Coffee Cup in the system tray, or to go into the Java Web Start settings and enable the console (or logging!) there. Easy, peasy.
Oh, and Mr. Eckel? Web Technology has not yet begun to fight. At least if the WHATWG specs have anything to say about it.
It's difficult to precisely follow your vision in a quicky Slasdot post, but it sounds somewhat interesting. Have you considered snagging some free Blog space and doing a full writeup of your idea? At the very least, communicating the concept in detail can help you find problems and solutions that you haven't yet considered. :)
What is OpenGL? ODBC? SDL? XLib? They aren't part of the Operating System, and yet they're not programs. What are they?
Programmers think of them individually as APIs. Collectively, however, they add up to the platform the software targets. As long as that platform is available, the software is portable.
I think the author of the article is displaying a great deal of confusion over Operating Systems vs. Programming Platforms. Which is understandable. We've had the concept of "everything included on the CD is part of the operating system" idea drilled into our heads for the last decade or so. There has been little attempt to recognize how distinct different portions of today's "operating systems" actually are.
Consider for a moment: What is Debian on FreeBSD? Is it a FreeBSD operating system or a Linux operating system? Or is it a Frankenstein kitbash of both? The answer is, neither answer is correct. It is the FreeBSD kernel combined with the GNU Platform.
Separating the task of operating the hardware (traditionally the job of the kernel) from the higher level "platform" has a variety of implications. The most important implication is that the software is as portable as the platform is. It doesn't matter if the underlying kernel is FreeBSD, Linux, or Windows NT. If you software targets the GNU platform, it is portable across all those systems. At least at a source level, though binary compatibility is ideal.
Thus when programmers make the comment that Java "is like an Operating System", what they mean is that the Java Platform is sufficient to replace the platform that shipped with your operating system. While the focus is currently on integrating the disparate platforms, what you're starting to see is that the OS is taking a back seat to the platform. Programmers want portability across devices, and Information Technology wants more flexible deployment solutions. Combined, these two needs add up to a drive for further portability of platforms with an eye toward using the right kernel for the right deployment solution.
That is where "Operating Systems" are headed. Not the monoliths of yesteryear, but the flexibility to provide familiar functionality where you need it and when you need it.
If you want a GMail account, just send an email to the address in my Slashdot profile. I'll send you an invite in return.
I haven't read the CNN article linked here, but I did read the article on my Wii last night. The long and short of it is that signup is geographically limited. Just about everyone not in North America is now able to sign up without going through the text message routine. The Google spokepeople have promised that North America will follow "soon".
Hope that clarifies things.
Opera, OTOH, almost always does what it's told when it's given DOM Compliant code. So unless you're not following the standards yourself, I can't see for a minute how "hardcore programming" in Javascript could be easier on IE than it is on Opera.
Specifically, what kind of bizarre behavior are you seeing? Are you sure it's actually as bizarre as you think it is, or are you perhaps giving it bizarre code? As they say in CompSci: Garbage In, Garbage Out.
Actually, I have. It's a bit quirky, but it implements the specs well enough to be useful. Which is more than I can say for Internet Exploder. :-/
2. It's not a "plugin" per se. It's a bit of Javascript that adds compatibility for any webpage that includes it.
3. As someone else mentioned, it's possible to do most of the Canvas functionality with plain Jane Javascript. It's just a bit slower.
In fact, it's a heck of a lot easier to support Firefox, Opera, Safari, and KHTML simultaneously than it is to support IE and Firefox. Why? Because the Microsoft programmers tell us how wonderful they are about supporting the W3C specs while ensuring that they do no such thing. So here we are, nearly seven years after the DOM Level 2 specifications became a W3C recommendation, and Microsoft still doesn't support it. Not even in their latest browser, which was released to (nay, forced upon) the public only 4 months ago!
Not that I'm despondent or anything. [...] Yeah, who am I kidding? I'm hopping mad that Microsoft promised standards compliance, and yet paid it only lip service at best! I'm not surprised in the slightest, I'm just mad. So much for the "new and more consumer friendly" Microsoft.
The Promise:
http://blogs.msdn.com/ie/archive/2005/07/29/44524
Sorry, got a little carried away there.
Excellent point. I withdraw my point about the lack of an oath. I imagine it would still be incredibly hard to prosecute, however, for the reasons I stated.
The puzzle you're talking about isn't actually that hard. But IIRC, there's something about putting the crystal in its proper place before you can solve the puzzle. Or maybe you needed a scrap of metal. Something like that. Read the walkthrough if you're really stuck.
It's like asking the question, "Why me?" The only good answer is, "If not you, then who else?"
Adventure games never really died. They just got lost in the massive push toward All Things 3D(TM). I'm happy to see that companies are starting to understand that these games are still popular, in the same way that RPGs are still popular both in 2D and 3D.
:)
Translated to Marketeeringese: Good Adventure Games = $$$Ka Ching!$$$
While you're waiting, consider playing a little Stargate Adventure. It's short, but it will take you back.
In any case, a DMCA notice would probably not be considered purjury. The sender took no oath to be truthful when they sent the notice. However, they could land in hot water for harrassment. It would be tricky to prosecute, but if you could show a significant degree of error in Viacom's takedown procedures, you could get them slammed with an injunction against sending DMCA notices. At least until a judge is fully convinced that Viacom has corrected the errors.