Even before the quake, Sony emphasized it wasn't likely to get a global launch. In Japan, where portable gaming has taken over, an NGP launch before the end of the year is critical to keep the 3DS from an insurmountable lead. But elsewhere, where the PSP has done less well, it's not quite as important.
Although tablets really aren't my thing, their utility seems obvious. A lot of casual computer users like to do a lot of basic content consumption (browse the web, read email, listen to music, play games) without the hassle of operating a full-scale computer with a full-scale operating system.
Microsoft, whose main business is selling complicated, full-scale operating systems, simply doesn't understand why people would favor a device that lets them do those things without one.
As I recall, their function was to carry things between the Earth and some orbiting station. To "shuttle" them, if you will. The problem is that they were meant to perform this shuttling with rapid turnaround times that never materialized in practice. Therefore, it seems some launch vehicle with less emphasis on reusability would likely be a better replacement.
I'm not at all convinced by these arguments. I'd much rather write performance-critical code in something like C, and the clever stuff in a much higher language.
I've also had quite a bit of success with this approach. For my programs, there's a small kernel of operations that need to be really fast, while the remainder is either limited by disk speed or not executed that often. By implementing the stuff that needs to be fast as C modules, I gain a massive speed boost without adding lots of complexity to everything else.
Starting with some high level scripting language and working down to low level is also a nice way to get a functional design up and running first before concentrating on making it fast.
If the developers just wanted lots of users and didn't care for what those users did with their code, they could've just placed code in the public domain and not used the GPL(3) license at all. But since they used that license, they're not losing any sleep over the fact that people who don't like it aren't using their code.
Just as Apple sells iWork under a license that prevents people from distributing it for free on the internet. Therefore, they're not too upset that they might have less iWork users because some people are unwilling to pay for it instead.
But whose fault is that? If Samba's license came with the rare "not to be installed in baby mulchers" clause that interfered with Apple's new iMulch product and caused it to be dropped, is it the fault of Samba for the license or Apple for not being willing to comply with it?
Samba loses some of its userbase and Apple loses a mature codebase, but I don't see how the GPL's terms are more onerous than any other sort of licensing disagreement.
If you're a developer using someone else's GPLed code, you'd need to be careful to ensure compliance with those licensing terms. But if you're the one writing the GPLed code, the care other people should be taking to comply with that license ensures that you can merge their changes with your own.
It's not just a one-way street as far as headaches are concerned.
If Apple doesn't like the licensing terms of other peoples' code, they're free to write their own code. But that doesn't make the license bad simply because it makes Apple's life more difficult for whatever it is they want to do with it.
Assembling a standard from several different, somewhat divergent implementations is hardly a new practice. The idea with HTML5 seems to be that once browsers implement all these fancy proposed features, the resulting subset will be hammered into an actual standard.
The alternative is specifying a standard first and throwing it at the feet of implementors to see what sticks, but I doubt that approach will work any better for HTML than it did for Perl6.
Precise controls at first-person shooters and strategy games, at least. Keyboard and mouse are completely inadequate for other genres such as racing (where a wheel would be best), platforming (analog stick), golf (motion control), fighting (multi-button arcade stick) and so on.
You can force people to need passwords, but you can't force them to care. A lot of accounts on a lot of sites are considered disposable by a large number of people. Therefore, they'll always choose a password that's as trivial as allowed.
They're probably envisioning post-launch patching and/or DLC which gets added to the game itself - in addition to the save game storage. Though exact details are still sketchy.
The whole excuse is crap, really. Adding all new CG effects required the original film elements that had been transferred to digital. Therefore, making an unaltered version would be a matter of transferring all those pre-CG elements back into a movie. The "Star Trek" series Blu-Ray treatment working similarly, placing both the enhanced and original versions on disc via branching. LucasFilm could do the same, but they choose not to.
And yet Miyamoto and Nintendo EAD spent more time and effort on Doki Doki Panic than they did on the quick-and-dirty expansion pack that was the Japanese "Super Mario Bros. 2". In fact, far more features from the former became mainstays to the series than anything from the latter.
It wasn't full software emulation. As I recall, the original PS3s had both a PS2 CPU and PS2 video chip. A later revision performed CPU emulation in software but kept the video chip. Finally, Sony removed both chips and all backwards compatibility entirely.
Graphics that take weeks to produce were better than ones that were rendered in realtime? Shocking!
What he means is that the arcade games made for the movie, and played by characters in the movie, weren't possible at the time. Contrast with "the Last Starfighter" whose fictional arcade game was less complex than main visual effects CG.
Have these guys ever disrupted any company significantly? TFA mentions they've taken down the RIAA, MPAA and Mastercard front pages, but none of those have affected their core businesses. It seems like in order to have a Waterloo, they would first need to have some real accomplishments beforehand.
I believe "Empire" is so fondly remembered because it expanded so much on the first and delivered so much potential for a third. Obi-Wan had lied to Luke about his father. The Luke-Leia-Han triangle suddenly got more complicated. There was another Jedi.
All that glorious potential that the third movie promptly piddled down its leg by resolving it all in the least dramatic ways possible. But still, when I rewatch "Empire" to this day, I can still recall how good its sequel could have been.
Slashdot Mirror
Apple seems to be doing okay without included numpads. I don't think average people care that much one way or another.
Even before the quake, Sony emphasized it wasn't likely to get a global launch. In Japan, where portable gaming has taken over, an NGP launch before the end of the year is critical to keep the 3DS from an insurmountable lead. But elsewhere, where the PSP has done less well, it's not quite as important.
Although tablets really aren't my thing, their utility seems obvious. A lot of casual computer users like to do a lot of basic content consumption (browse the web, read email, listen to music, play games) without the hassle of operating a full-scale computer with a full-scale operating system.
Microsoft, whose main business is selling complicated, full-scale operating systems, simply doesn't understand why people would favor a device that lets them do those things without one.
As I recall, their function was to carry things between the Earth and some orbiting station. To "shuttle" them, if you will. The problem is that they were meant to perform this shuttling with rapid turnaround times that never materialized in practice. Therefore, it seems some launch vehicle with less emphasis on reusability would likely be a better replacement.
I've also had quite a bit of success with this approach. For my programs, there's a small kernel of operations that need to be really fast, while the remainder is either limited by disk speed or not executed that often. By implementing the stuff that needs to be fast as C modules, I gain a massive speed boost without adding lots of complexity to everything else.
Starting with some high level scripting language and working down to low level is also a nice way to get a functional design up and running first before concentrating on making it fast.
If the developers just wanted lots of users and didn't care for what those users did with their code, they could've just placed code in the public domain and not used the GPL(3) license at all. But since they used that license, they're not losing any sleep over the fact that people who don't like it aren't using their code.
Just as Apple sells iWork under a license that prevents people from distributing it for free on the internet. Therefore, they're not too upset that they might have less iWork users because some people are unwilling to pay for it instead.
But whose fault is that? If Samba's license came with the rare "not to be installed in baby mulchers" clause that interfered with Apple's new iMulch product and caused it to be dropped, is it the fault of Samba for the license or Apple for not being willing to comply with it?
Samba loses some of its userbase and Apple loses a mature codebase, but I don't see how the GPL's terms are more onerous than any other sort of licensing disagreement.
If you're a developer using someone else's GPLed code, you'd need to be careful to ensure compliance with those licensing terms. But if you're the one writing the GPLed code, the care other people should be taking to comply with that license ensures that you can merge their changes with your own.
It's not just a one-way street as far as headaches are concerned.
If Apple doesn't like the licensing terms of other peoples' code, they're free to write their own code. But that doesn't make the license bad simply because it makes Apple's life more difficult for whatever it is they want to do with it.
Assembling a standard from several different, somewhat divergent implementations is hardly a new practice. The idea with HTML5 seems to be that once browsers implement all these fancy proposed features, the resulting subset will be hammered into an actual standard.
The alternative is specifying a standard first and throwing it at the feet of implementors to see what sticks, but I doubt that approach will work any better for HTML than it did for Perl6.
Precise controls at first-person shooters and strategy games, at least. Keyboard and mouse are completely inadequate for other genres such as racing (where a wheel would be best), platforming (analog stick), golf (motion control), fighting (multi-button arcade stick) and so on.
They're certainly not a solution for everything.
You can do that already, on Ubuntu at least. Python 2 and Python 3 are in different packages which can be installed simultaneously.
You can force people to need passwords, but you can't force them to care. A lot of accounts on a lot of sites are considered disposable by a large number of people. Therefore, they'll always choose a password that's as trivial as allowed.
They're probably envisioning post-launch patching and/or DLC which gets added to the game itself - in addition to the save game storage. Though exact details are still sketchy.
It uses Flash-style cartridges, essentially.
The whole excuse is crap, really. Adding all new CG effects required the original film elements that had been transferred to digital. Therefore, making an unaltered version would be a matter of transferring all those pre-CG elements back into a movie. The "Star Trek" series Blu-Ray treatment working similarly, placing both the enhanced and original versions on disc via branching. LucasFilm could do the same, but they choose not to.
108 of them are, at least.
And yet Miyamoto and Nintendo EAD spent more time and effort on Doki Doki Panic than they did on the quick-and-dirty expansion pack that was the Japanese "Super Mario Bros. 2". In fact, far more features from the former became mainstays to the series than anything from the latter.
It wasn't full software emulation. As I recall, the original PS3s had both a PS2 CPU and PS2 video chip. A later revision performed CPU emulation in software but kept the video chip. Finally, Sony removed both chips and all backwards compatibility entirely.
No. PS2 backwards compatibility required additional chips that aren't in the newer PS3s.
It helped that ST:TMP made a lot of money, whereas Tron did not.
I'm still rather fond of them both, but nostalgia may have a lot to do with it.
What he means is that the arcade games made for the movie, and played by characters in the movie, weren't possible at the time. Contrast with "the Last Starfighter" whose fictional arcade game was less complex than main visual effects CG.
Have these guys ever disrupted any company significantly? TFA mentions they've taken down the RIAA, MPAA and Mastercard front pages, but none of those have affected their core businesses. It seems like in order to have a Waterloo, they would first need to have some real accomplishments beforehand.
I believe "Empire" is so fondly remembered because it expanded so much on the first and delivered so much potential for a third. Obi-Wan had lied to Luke about his father. The Luke-Leia-Han triangle suddenly got more complicated. There was another Jedi.
All that glorious potential that the third movie promptly piddled down its leg by resolving it all in the least dramatic ways possible. But still, when I rewatch "Empire" to this day, I can still recall how good its sequel could have been.