The 360 is selling to the EXACT same people who bought the first Xbox.
Now that is provably false. The XBox sold a mere 24 million units in the 4+ years it was on the market. In comparison, the 360 sold about 10 million units in the first year. Unless sales fall off dramatically, Microsoft is still in a better position than they were with the XBox.
In addition, movements like Wii60 are causing many gamers to see the 360 as a companion to the Wii rather than a competitor. This has driven the consumer thinking of, "I'll use the Wii for 'fun' games, then use the 360 for FPSes, Simulations, and HD Entertainment." I see this thinking on a daily basis, so it would appear to be working.
I'm no fan of Microsoft, but they've done just as much right with the 360 as they have done wrong. I'm actually *happy* that they've screwed up the hardware yields so royally as it's one of the few things keeping them from getting a stronger hold on the market.
Virtually no one in Japan.
This is true. However, Microsoft doesn't actually need Japan to sell well. Japan is the center for quite a bit of gaming, but there's enough game development elsewhere in the world to keep Microsoft's machine running.
A fairly small number of people in Europe, mostly in the UK.
According to VGCharts, Microsoft has managed about 3.18 million in non-Japanese international sales compared to their 6.5 million domestic sales. That's hardly "a fairly small number". In fact, it's about 30% of their market.
The truth is that the 360 has expanded Microsoft's hold considerably. It's costing them a very large fortune to hold it, but it would be foolish to let it slip through their grasp now.
I seriously doubt that Microsoft is ready to give up the fight yet. At the moment, they have Sony's "hardcore gamers" market by the balls. It would be foolish to give it up now, no matter what happens.
No, I imagine that Microsoft is regrouping and rethinking their strategy. They're examining what worked for them and what didn't so that they can focus on doing more of what works. Useless trade shows that no one has ever heard of probably fall under the "not working" category.
The game the lawsuit is over is a fucking 360 only game dimwit!
Before you insult the guy, maybe you should have RTFA?
From Kotaku:
Epic once again supposedly missed a deadline for an Engine Silicon Knights was going to use on a PLAYSTATION 3 game. Epic missed this deadline by six-months. A functional UE3 for the PS3 was supposed to be delivered by February 2007. It wasn't.
Of course, if the grandparent had read the article, he'd also know that this lawsuit relates to general problems with the engine across the board. Not just for the PS3 and 360.
Perhaps next time, both of you children will read the article?
Metroid Prime: Corruption (orginally slated to be out for this year)
I think you mean last year. It was briefly slated to be a launch title in 2006 before being pushed out to March 2007. Right before it was supposed to be released, it was again pushed out to later in 2007. Now we have a firm release date of August 27th.
Amen. Microsoft can talk when they at least have DOM 2 implemented. Until then, their promises of "standards compliance" are nothing more than an insult to the development community at large.
Who modded this informative? Suv4x4 is incorrect. The W3C came up with their HTML5 standard by taking a dump of the WHATWG HTML5 standard and putting the W3C colors on it. Which isn't surprising as most of the WHATWG members are also W3C members. It was always their intention to make their standard more "legitimate" by submitting it to the W3C once it was ready.
Don't believe me? Here are the two standards. Compare:
The canvas tag (originally from Mozilla, I believe, but now in WebKit and Opera)
Actually, it was originally from Apple Safari. Apple invented it for their desktop widget thingys. Opera and Mozilla have both embraced it with open arms.:)
my favourite is client-side storage.
I agree. I absolutely love this feature! Unfortunately, it's only implemented by Firefox at the moment. I was hoping that it would show up in Safari 3.0 so that richer iPhone applications could be written, but it was not to be. The feature request is still sitting out there with no assigned implementer. I'm tempted to dive into Webkit and maybe see if I can add it.
Or are the W3C just trying to justify their existence?
That's a bit cynical, don't you think?
HTML5 is the result of the hard work done by the Web Hypertext Application Technology Working Group (WHATWG). The WHATWG is composed of members from all browser makers, with the occasional public comment thrown in for good measure. As a result, the group has been removing or reducing the ambiguity about implementing the various standards (especially the parser!) and have added features that bring HTML up to a true application platform. Their work is represented in web browsers every time someone uses the Canvas tag, Audio object, Storage API, and other modern features.
The WHATWG was formed because the W3C was seen as too slow to execute such new technologies. Now that the WHATWG specs are stablizing, the W3C has taken a dump of the WHATWG HTML 5 standard and proposed it for ratification under W3C bylaws. This has several advantages over the WHATWG standardization, not the least of which is extracting patent waivers from companies like Apple who technically "own" some of the technologies behind the WHATWG standards.
Note that the HTML5 group at the W3C is a bit different from most. In an attempt to remain as open as the WHATWG, they are accepting just about anyone as an "invited expert" to provide input and comments on the standards process. This is a huge departure from the way that most W3C standards are handled, and is probably a good choice for a standard as comprehensive and complex as HTML5.
I'm sure the hackers in us all are VERY curious as to how this encoding works... no?
I'm actually more curious to see if MP3/AAC encoding is going to whack these "inaudible" audio codes out of the stream. That could have a nasty effect on their tracking attempts for several types of media.:-P
See the box on the left that says "34 Comments" or somesuch? It's probably split between gray and white areas. Just drag the middle bar all the way to the bottom until the entire box is white. That should expand all the comments.
That being said, I'm still using the "Nested a +0" thankyouverymuch.:-)
A fatally flawed project can often not be recovered or redirected. There is nothing special about IT projects.
I have to wonder, though, if the growing "success" of IT projects isn't related to more inhouse development. Back in 1994, large projects almost always relied on external consulting agencies like Anderson. These services were very poor at delivery, in part because of their lack of understanding of how each business worked. Staff employees usually had a better understanding, but even in large corporations there was limited number of people to obtain access to. Things were not helped by the common "waterfall" methodology, not because waterfall is inherently flawed, but because the flow of information was too tightly controlled.
Fast forward to today and the challenges facing businesses require an online presence. Because these presences usually require a larger staff to maintain, it makes sense to also do most (if not all) of the development in-house. This neatly sidesteps the internal resource issues previous faced by large IT projects, and thus the very reasons for outsourcing.
I won't comment too much on the situation of Indian outsourcing other than to say that my experience has been a matter of keeping enough local staff on hand to do a lot of command, control, and repair to the project on the fly. I simply won't comment on whether that results in a realization of the supposed Indian outsourcing savings or not.
I don't think that the analog hole is the real concern. The question that everyone should be asking is: How many pirates get their music from web radio? Does anyone even bother trying to record web radio?
It seems to me that the RIAA members are stuck back in the 1980's when everyone used their tape decks to record music over the airwaves. We're not there anymore. Most people care enough about the audio quality that they'll either purchase the song from iTunes (more convenient, less hassle!) or download a copy from P2P that someone else has already pirated. And I can tell you that the "someone else" probably didn't use net radio as a master. He probably went out and purchased a single CD, ripped it, and (if he was enough of a jerk) returned it to the store as defective.
The RIAA and its members need to get their heads out of their rears and get with modern times. Dollars to donuts says that any study on the piracy of net radio would find it to be nearly non-existent. Their worries amount to nothing more than chicken little crying "The sky is falling, the sky is falling!" If by some miraculous event the studies showed that people were stream ripping, then maybe it would be a good time to embrace services like iTunes to their fullest extent?
Offering the product that people want at a price the market will bear is the best thing that any music company can do. The people who would spend the time engaging in stream ripping or P2P piracy aren't going to pay for the music anyway, so you gain very little by spending your time trying to stop them. Having DJs talk over music has never stopped freeloaders in the past, so I don't see why it would stop them now.
Since no one else will just answer the darn question, I will.
The answer is that it may technically affect the Wii. However, it is a practically useless exploit on such a device. For one thing, the system does not multitask. So if the only keypresses that could be trapped are the ones already available through Javascript or Flash. Secondly, there are no keypresses. Flash does not receive anything as a keypress, while Javascript is capable of receiving the Wii Remote buttons as if they were "keys".
Information placed in text fields cannot be logged, as it is handled by a "stop-the-world" on screen keyboard. (Oddly, the Flash player does not run while the keyboard is on the screen, but scheduled Javascript events continue to execute in the background. Go figure.) Since neither Flash nor Javascript can interact with this keyboard, the user is pretty safe from having their passwords or credit card information stolen. The only real exploit is the old-fashion social engineering exploit. i.e. Try to get someone to enter their information into a compromised Flash Movie or webpage. Which does not require a security exploit to accomplish.:)
Shockwave was Macromedia's original online animation plugin. It is extremely feature-rich and quite fast at what it does. It's also quite large. So when a company called FutureWave created a much smaller vector-graphics competitor, Macromedia bought them out and renamed it "Shockwave Flash" to give the impression that Flash was a subset of their Shockwave technologies. (You'll notice that the Flash movie extension is "SWF". "ShockWave Flash")
In reality, it was all just marketing BS. Flash had enough features to make animation authors (and later game developers) happy, so it quickly replaced the more heavyweight Shockwave. After the acquisition of Macromedia by Adobe, they stopped trying to maintain the charade and simply called it "Adobe Flash". There are still a few vestigial pieces of the software that refer to "Shockwave Flash", but they're slowly disappearing as time goes on.
I believe the buttons on the Wiimote map to a few keys (for use in Flash games)
Actually, the keypresses only make it as far as Javascript. In order to "hear" the presses in Flash, you need to use the WiiCade API, which traps all the keypresses and forwards them to Flash. There's also the earlier Quasimondo API, but it fails to trap the keypresses, making it useless under most circumstances.
It does affect everything from mobile devices to servers, because they all run Java 6 (more mobile devices run mobile Java, but some still run full Java).
You don't know what you're talking about. There are absolutely no mobile devices on the market that run Java 6. For that matter, I seriously doubt there's a mobile device in existence with enough OS services and horsepower to handle a complete Java 6 implementation. Do you have any idea the range of functions that are covered by the J6SE standard? By the time you're compatible, you might as well have shipped a laptop!
Futhermore, even if they did run Java 6, it's doubtful that they would be vulnerable. This vulnerability is in a specific library used by the Sun implementation. Other implementations would be unaffected unless they used the exact same library.
When even Sun prefers writing large chunks of the Java implementation in C, that tells you that the Java language just isn't very good at those things.
You know, it always amazes me how people continue to put Java down despite the fact that they plainly don't know what the hell they're talking about. You get one fellow over here saying, "Java doesn't have a print API." So you show him the print API and he says, "Oh." You get another fellow saying, "Java can't do OpenGL!" So you show him the OpenGL API and he says, "Oh." Then some damned fool comes along and says that Java can't be implemented in Java. You point him to JNode and Jalepeno, and he says, "Oh."
But there's always another fool behind him just waiting to tell the world about his highly uninformed opinion as to why Java sucks. Not a single one of them is correct, but that doesn't stop them at all!
*sigh*
For your information, Sun used native libraries for things like ImageIO because it was easy, not because it was smart. The reasoning seems sound enough. Why reimplement the wheel when it's already been done? Of course, that belies the fact that you cut Java off at the knees by doing so. All the problems you shouldn't be having come back to bite you in the rear. Hopefully Sun will heed these security issues, and reimplement the ImageIO routines in the near future.
Most image upload sites generate a thumbnail image, which requires that the image be loaded, resized, then saved out. So anyone that deals with image uploads should double check to be certain they're not vulnerable somewhere in the system.
But you are correct. If you just have a simple file upload with no parsing, you'll be just fine.
...which is not a trivial thing to do unknowingly on a headless server.
It's not trivial if it's truly headless. Java has had headless support for a while now that is capable of doing graphics even without a graphical system running. The only way that it absolutely doesn't work is if you have absolutely no X11 libraries in your path. Windows and Mac machines will always work.
Also, you don't actually need to modify the image to trigger the vulnerability. If you parse it at all you will trigger the exploit. The image IO libraries are not dependent on a graphics library and will work on a truly headless server. So if, for example, you change all BMPs uploaded into PNGs for storage, you may be in need of an immediate update to your JVM.
in other words... you may not need any decoder at all
This is incorrect. The J2ME spec specifically calls for PNG support. The first revision of J2ME, in fact, did not support arrays of pixels. Image data in an array was expected to be packed in PNG format. The result is that quite a few developers came up with a way of loading images, extracting the pixel data, then reencoding them as PNGs after they resized them for the device. They could then be put through the APIs to retrieve an image capable of being drawn to the screen.
While it's possible for a vendor to support JPEG, the spec ONLY requires PNGs. And in practice, that is the only image format you can rely on.
Implementations are required to support images stored in the PNG (Portable Network Graphics) format, version 1.0. [...] Creates an immutable image which is decoded from the data stored in the specified byte array at the specified offset and length. The data must be in a self-identifying image file format supported by the implementation, such as PNG.
You've been looking for someone who's heard of it? Dude, SFII isn't exactly obscure. I could understand if you said, "I've been looking for an American who's heard of Doctor Who, because this is hilarious," but I think most everyone knows SFII.:-P
Ok, apparently you're not getting this. Java was created to prevent security hazards like this by design. Which means that if there actually is a "Write Once, Run Anywhere" vulnerability in Java, it's a massive flaw in Java's design.
It's possible that such a flaw could have been found 10 years ago, but at this point its security has been tested by fire. There's no way to pierce the veil of Java's security design. Major flaws are further down the pipeline in the implementation of the JVM, which means that (by definition) the flaw does not exist on all JVMs.
As it turned out, this is a flaw in the implementation of the JVM. Someone linked in native code where it probably wasn't a good idea to do so. In result, desktops and some servers are vulnerable. (Actually, very few are thanks to Java's autoupdater which has already upgraded most machines to a fixed JVM.) This hyperbole about PDAs, Cell Phones, etc. is exactly that: Hyperbole. These devices are NOT vulnerable. It's just some analysts lame attempt to extend the issue where it isn't because he doesn't understand the problem in the first place.
And THAT is why I shouted that it required extraordinary proof. Not because it ended up being a fairly textbook bug in native code, but because of the article's extraordinary claims of all JVMs being affected.
Again, extraordinary claims require extraordinary evidence. The article made extraordinary claims and was unable to follow up based on the evidence at hand.
Well, actually you can, but that's beside the point.
First, for trusted code (for example, normal applications) avoiding native libraries has a potentially huge performance cost. I'm not talking so much about the overhead of Java itself, but portable OS- and application-independent code can't take advantage things like a native graphics API that's directly mapped to GPU operations. I'm sure you can call OpenGL from Java, but I would hope that you can't do it from a Java applet - so applications should perhaps not be held to such a strict regimen.
I'm not quite sure what you mean. Java has used DirectX/OpenGL as its renderer for some time now. It's simply hidden beneath the covers of the Java core libraries. Versions 1.4 and higher can even access full screen modes and sync to the monitor's refresh rate. (Though not in an unsigned Applet, of course.)
Second, one of the problems with Java as a "run anywhere" language for applications is that so much of Java is implemented in Java, emulating a Windows style user interface (I don't have a problem with Sun choosing Windows here, that's where the market is, but it does make Java less attractive to people wanting to "run anywhere".
I agree that the Swing approach is problematic, but so is the AWT approach. Even SWT, which is tuned to Windows, has a variety of cross-platform display issues. The unfortunate truth is that the only true cross-platform GUI is a GUI that doesn't adhere to any platform. Such is the way of things.:(
On the bright side, Java wouldn't have done any better on the desktop even if had been given the perfect solution to a cross platform GUI. The majority of desktop applications we use today were already in existence by the time that Java arrived on the scene. Thus we still use Microsoft Office (or the even older codebase of OpenOffice), IE or Firefox (derivatives of Spyglass and Netscape, respectively), Microsoft Outlook, Photoshop, etc. Java applications were unlikely to displace these programs anyway, and with things moving toward the web there are even fewer niches for Java to fill.
It did well in the P2P arena, though.
Third, solving this problem for Java may be less useful when it comes to security than fixing the native libraries so they're secure whether they're called from Java or some other component for the display of untrusted content (like a browser).
The Sun JVM tends to use some rather obscure libraries. It does not hook into the browser services, so fixing the underlying libraries really has no direct effect on anything except Java. And in any case, there is no real excuse for not doing the image libraries in Java save for that it was quicker and easier to link in an existing native library. Probably licensed from someone like Kodak, no less.
The amusing part is that Sun had paid big bucks to acquire a pure-Java imaging library back in the Java 1.1 days, but chose instead to build a brand new library called JAI. JAI was overly complicated, difficult, and unwieldy, so it was replaced with the core ImageIO library. I guess they didn't consider going back to improving JIMI when they were looking for an implementation for ImageIO.
To get over sections full of small jumps, hold the run button and run across.
Likitu is a pain. The best strategy for dealing with him is...
Hammer Bros. are an enemy that require precise timing and movement to defeat. The best strategy is...
Seriously, anyone remember when strategy books were about strategy and not just answer keys? I probably still have my SFII strategy guide somewhere, which goes into detailed strategies that people figured out for playing the various characters in the game. This included sets of combos that were most effective against particular opponents and at what ranges.
Slashdot Mirror
Now that is provably false. The XBox sold a mere 24 million units in the 4+ years it was on the market. In comparison, the 360 sold about 10 million units in the first year. Unless sales fall off dramatically, Microsoft is still in a better position than they were with the XBox.
In addition, movements like Wii60 are causing many gamers to see the 360 as a companion to the Wii rather than a competitor. This has driven the consumer thinking of, "I'll use the Wii for 'fun' games, then use the 360 for FPSes, Simulations, and HD Entertainment." I see this thinking on a daily basis, so it would appear to be working.
I'm no fan of Microsoft, but they've done just as much right with the 360 as they have done wrong. I'm actually *happy* that they've screwed up the hardware yields so royally as it's one of the few things keeping them from getting a stronger hold on the market.
This is true. However, Microsoft doesn't actually need Japan to sell well. Japan is the center for quite a bit of gaming, but there's enough game development elsewhere in the world to keep Microsoft's machine running.
According to VGCharts, Microsoft has managed about 3.18 million in non-Japanese international sales compared to their 6.5 million domestic sales. That's hardly "a fairly small number". In fact, it's about 30% of their market.
The truth is that the 360 has expanded Microsoft's hold considerably. It's costing them a very large fortune to hold it, but it would be foolish to let it slip through their grasp now.
Actually, I thought I was bolstering your point. But feel free to take it as you will. ;-)
I seriously doubt that Microsoft is ready to give up the fight yet. At the moment, they have Sony's "hardcore gamers" market by the balls. It would be foolish to give it up now, no matter what happens.
No, I imagine that Microsoft is regrouping and rethinking their strategy. They're examining what worked for them and what didn't so that they can focus on doing more of what works. Useless trade shows that no one has ever heard of probably fall under the "not working" category.
Before you insult the guy, maybe you should have RTFA?
From Kotaku:
Of course, if the grandparent had read the article, he'd also know that this lawsuit relates to general problems with the engine across the board. Not just for the PS3 and 360.
Perhaps next time, both of you children will read the article?
I think you mean last year. It was briefly slated to be a launch title in 2006 before being pushed out to March 2007. Right before it was supposed to be released, it was again pushed out to later in 2007. Now we have a firm release date of August 27th.
Amen. Microsoft can talk when they at least have DOM 2 implemented. Until then, their promises of "standards compliance" are nothing more than an insult to the development community at large.
Who modded this informative? Suv4x4 is incorrect. The W3C came up with their HTML5 standard by taking a dump of the WHATWG HTML5 standard and putting the W3C colors on it. Which isn't surprising as most of the WHATWG members are also W3C members. It was always their intention to make their standard more "legitimate" by submitting it to the W3C once it was ready.
Don't believe me? Here are the two standards. Compare:
WHATWG HTML5
W3C HTML5
Save for some slight divergences as the WHATWG's standard is updated, they're exactly the same.
Actually, it was originally from Apple Safari. Apple invented it for their desktop widget thingys. Opera and Mozilla have both embraced it with open arms.
I agree. I absolutely love this feature! Unfortunately, it's only implemented by Firefox at the moment. I was hoping that it would show up in Safari 3.0 so that richer iPhone applications could be written, but it was not to be. The feature request is still sitting out there with no assigned implementer. I'm tempted to dive into Webkit and maybe see if I can add it.
That's a bit cynical, don't you think?
HTML5 is the result of the hard work done by the Web Hypertext Application Technology Working Group (WHATWG). The WHATWG is composed of members from all browser makers, with the occasional public comment thrown in for good measure. As a result, the group has been removing or reducing the ambiguity about implementing the various standards (especially the parser!) and have added features that bring HTML up to a true application platform. Their work is represented in web browsers every time someone uses the Canvas tag, Audio object, Storage API, and other modern features.
The WHATWG was formed because the W3C was seen as too slow to execute such new technologies. Now that the WHATWG specs are stablizing, the W3C has taken a dump of the WHATWG HTML 5 standard and proposed it for ratification under W3C bylaws. This has several advantages over the WHATWG standardization, not the least of which is extracting patent waivers from companies like Apple who technically "own" some of the technologies behind the WHATWG standards.
Note that the HTML5 group at the W3C is a bit different from most. In an attempt to remain as open as the WHATWG, they are accepting just about anyone as an "invited expert" to provide input and comments on the standards process. This is a huge departure from the way that most W3C standards are handled, and is probably a good choice for a standard as comprehensive and complex as HTML5.
I'm actually more curious to see if MP3/AAC encoding is going to whack these "inaudible" audio codes out of the stream. That could have a nasty effect on their tracking attempts for several types of media.
See the box on the left that says "34 Comments" or somesuch? It's probably split between gray and white areas. Just drag the middle bar all the way to the bottom until the entire box is white. That should expand all the comments.
:-)
That being said, I'm still using the "Nested a +0" thankyouverymuch.
I have to wonder, though, if the growing "success" of IT projects isn't related to more inhouse development. Back in 1994, large projects almost always relied on external consulting agencies like Anderson. These services were very poor at delivery, in part because of their lack of understanding of how each business worked. Staff employees usually had a better understanding, but even in large corporations there was limited number of people to obtain access to. Things were not helped by the common "waterfall" methodology, not because waterfall is inherently flawed, but because the flow of information was too tightly controlled.
Fast forward to today and the challenges facing businesses require an online presence. Because these presences usually require a larger staff to maintain, it makes sense to also do most (if not all) of the development in-house. This neatly sidesteps the internal resource issues previous faced by large IT projects, and thus the very reasons for outsourcing.
I won't comment too much on the situation of Indian outsourcing other than to say that my experience has been a matter of keeping enough local staff on hand to do a lot of command, control, and repair to the project on the fly. I simply won't comment on whether that results in a realization of the supposed Indian outsourcing savings or not.
...as long as all the characters are made of Paper.
What's that? They'll be 3D models in the Sonic Team "Universe" that sports about 3 billion more characters than common sense?
Um, nevermind then.
I don't think that the analog hole is the real concern. The question that everyone should be asking is: How many pirates get their music from web radio? Does anyone even bother trying to record web radio?
It seems to me that the RIAA members are stuck back in the 1980's when everyone used their tape decks to record music over the airwaves. We're not there anymore. Most people care enough about the audio quality that they'll either purchase the song from iTunes (more convenient, less hassle!) or download a copy from P2P that someone else has already pirated. And I can tell you that the "someone else" probably didn't use net radio as a master. He probably went out and purchased a single CD, ripped it, and (if he was enough of a jerk) returned it to the store as defective.
The RIAA and its members need to get their heads out of their rears and get with modern times. Dollars to donuts says that any study on the piracy of net radio would find it to be nearly non-existent. Their worries amount to nothing more than chicken little crying "The sky is falling, the sky is falling!" If by some miraculous event the studies showed that people were stream ripping, then maybe it would be a good time to embrace services like iTunes to their fullest extent?
Offering the product that people want at a price the market will bear is the best thing that any music company can do. The people who would spend the time engaging in stream ripping or P2P piracy aren't going to pay for the music anyway, so you gain very little by spending your time trying to stop them. Having DJs talk over music has never stopped freeloaders in the past, so I don't see why it would stop them now.
Isn't that like saying that everyone is after your secret stash of iron pyrite?
Since no one else will just answer the darn question, I will.
The answer is that it may technically affect the Wii. However, it is a practically useless exploit on such a device. For one thing, the system does not multitask. So if the only keypresses that could be trapped are the ones already available through Javascript or Flash. Secondly, there are no keypresses. Flash does not receive anything as a keypress, while Javascript is capable of receiving the Wii Remote buttons as if they were "keys".
Information placed in text fields cannot be logged, as it is handled by a "stop-the-world" on screen keyboard. (Oddly, the Flash player does not run while the keyboard is on the screen, but scheduled Javascript events continue to execute in the background. Go figure.) Since neither Flash nor Javascript can interact with this keyboard, the user is pretty safe from having their passwords or credit card information stolen. The only real exploit is the old-fashion social engineering exploit. i.e. Try to get someone to enter their information into a compromised Flash Movie or webpage. Which does not require a security exploit to accomplish.
Shockwave was Macromedia's original online animation plugin. It is extremely feature-rich and quite fast at what it does. It's also quite large. So when a company called FutureWave created a much smaller vector-graphics competitor, Macromedia bought them out and renamed it "Shockwave Flash" to give the impression that Flash was a subset of their Shockwave technologies. (You'll notice that the Flash movie extension is "SWF". "ShockWave Flash")
In reality, it was all just marketing BS. Flash had enough features to make animation authors (and later game developers) happy, so it quickly replaced the more heavyweight Shockwave. After the acquisition of Macromedia by Adobe, they stopped trying to maintain the charade and simply called it "Adobe Flash". There are still a few vestigial pieces of the software that refer to "Shockwave Flash", but they're slowly disappearing as time goes on.
Actually, the keypresses only make it as far as Javascript. In order to "hear" the presses in Flash, you need to use the WiiCade API, which traps all the keypresses and forwards them to Flash. There's also the earlier Quasimondo API, but it fails to trap the keypresses, making it useless under most circumstances.
You don't know what you're talking about. There are absolutely no mobile devices on the market that run Java 6. For that matter, I seriously doubt there's a mobile device in existence with enough OS services and horsepower to handle a complete Java 6 implementation. Do you have any idea the range of functions that are covered by the J6SE standard? By the time you're compatible, you might as well have shipped a laptop!
Futhermore, even if they did run Java 6, it's doubtful that they would be vulnerable. This vulnerability is in a specific library used by the Sun implementation. Other implementations would be unaffected unless they used the exact same library.
You know, it always amazes me how people continue to put Java down despite the fact that they plainly don't know what the hell they're talking about. You get one fellow over here saying, "Java doesn't have a print API." So you show him the print API and he says, "Oh." You get another fellow saying, "Java can't do OpenGL!" So you show him the OpenGL API and he says, "Oh." Then some damned fool comes along and says that Java can't be implemented in Java. You point him to JNode and Jalepeno, and he says, "Oh."
But there's always another fool behind him just waiting to tell the world about his highly uninformed opinion as to why Java sucks. Not a single one of them is correct, but that doesn't stop them at all!
*sigh*
For your information, Sun used native libraries for things like ImageIO because it was easy, not because it was smart. The reasoning seems sound enough. Why reimplement the wheel when it's already been done? Of course, that belies the fact that you cut Java off at the knees by doing so. All the problems you shouldn't be having come back to bite you in the rear. Hopefully Sun will heed these security issues, and reimplement the ImageIO routines in the near future.
But you are correct. If you just have a simple file upload with no parsing, you'll be just fine.
It's not trivial if it's truly headless. Java has had headless support for a while now that is capable of doing graphics even without a graphical system running. The only way that it absolutely doesn't work is if you have absolutely no X11 libraries in your path. Windows and Mac machines will always work.
Also, you don't actually need to modify the image to trigger the vulnerability. If you parse it at all you will trigger the exploit. The image IO libraries are not dependent on a graphics library and will work on a truly headless server. So if, for example, you change all BMPs uploaded into PNGs for storage, you may be in need of an immediate update to your JVM.
This is incorrect. The J2ME spec specifically calls for PNG support. The first revision of J2ME, in fact, did not support arrays of pixels. Image data in an array was expected to be packed in PNG format. The result is that quite a few developers came up with a way of loading images, extracting the pixel data, then reencoding them as PNGs after they resized them for the device. They could then be put through the APIs to retrieve an image capable of being drawn to the screen.
While it's possible for a vendor to support JPEG, the spec ONLY requires PNGs. And in practice, that is the only image format you can rely on.
From here: http://theoreticlabs.com/dev/api/midp-1.0a/javax/
You've been looking for someone who's heard of it? Dude, SFII isn't exactly obscure. I could understand if you said, "I've been looking for an American who's heard of Doctor Who, because this is hilarious," but I think most everyone knows SFII. :-P
;-)
It was a pretty funny video, though.
Ok, apparently you're not getting this. Java was created to prevent security hazards like this by design. Which means that if there actually is a "Write Once, Run Anywhere" vulnerability in Java, it's a massive flaw in Java's design.
It's possible that such a flaw could have been found 10 years ago, but at this point its security has been tested by fire. There's no way to pierce the veil of Java's security design. Major flaws are further down the pipeline in the implementation of the JVM, which means that (by definition) the flaw does not exist on all JVMs.
As it turned out, this is a flaw in the implementation of the JVM. Someone linked in native code where it probably wasn't a good idea to do so. In result, desktops and some servers are vulnerable. (Actually, very few are thanks to Java's autoupdater which has already upgraded most machines to a fixed JVM.) This hyperbole about PDAs, Cell Phones, etc. is exactly that: Hyperbole. These devices are NOT vulnerable. It's just some analysts lame attempt to extend the issue where it isn't because he doesn't understand the problem in the first place.
And THAT is why I shouted that it required extraordinary proof. Not because it ended up being a fairly textbook bug in native code, but because of the article's extraordinary claims of all JVMs being affected.
Again, extraordinary claims require extraordinary evidence. The article made extraordinary claims and was unable to follow up based on the evidence at hand.
Well, actually you can, but that's beside the point.
I'm not quite sure what you mean. Java has used DirectX/OpenGL as its renderer for some time now. It's simply hidden beneath the covers of the Java core libraries. Versions 1.4 and higher can even access full screen modes and sync to the monitor's refresh rate. (Though not in an unsigned Applet, of course.)
I agree that the Swing approach is problematic, but so is the AWT approach. Even SWT, which is tuned to Windows, has a variety of cross-platform display issues. The unfortunate truth is that the only true cross-platform GUI is a GUI that doesn't adhere to any platform. Such is the way of things.
On the bright side, Java wouldn't have done any better on the desktop even if had been given the perfect solution to a cross platform GUI. The majority of desktop applications we use today were already in existence by the time that Java arrived on the scene. Thus we still use Microsoft Office (or the even older codebase of OpenOffice), IE or Firefox (derivatives of Spyglass and Netscape, respectively), Microsoft Outlook, Photoshop, etc. Java applications were unlikely to displace these programs anyway, and with things moving toward the web there are even fewer niches for Java to fill.
It did well in the P2P arena, though.
The Sun JVM tends to use some rather obscure libraries. It does not hook into the browser services, so fixing the underlying libraries really has no direct effect on anything except Java. And in any case, there is no real excuse for not doing the image libraries in Java save for that it was quicker and easier to link in an existing native library. Probably licensed from someone like Kodak, no less.
The amusing part is that Sun had paid big bucks to acquire a pure-Java imaging library back in the Java 1.1 days, but chose instead to build a brand new library called JAI. JAI was overly complicated, difficult, and unwieldy, so it was replaced with the core ImageIO library. I guess they didn't consider going back to improving JIMI when they were looking for an implementation for ImageIO.
To get to the warp zone...
Mole enemies are invulnerable to fireballs...
To get over sections full of small jumps, hold the run button and run across.
Likitu is a pain. The best strategy for dealing with him is...
Hammer Bros. are an enemy that require precise timing and movement to defeat. The best strategy is...
Seriously, anyone remember when strategy books were about strategy and not just answer keys? I probably still have my SFII strategy guide somewhere, which goes into detailed strategies that people figured out for playing the various characters in the game. This included sets of combos that were most effective against particular opponents and at what ranges.