You know what's scary? This looks like it would have been fun. What they showed in the video looks like the original Half Life running in the Doom 3 engine. (i.e. Yet Another FPS(TM))
...only movie-based games mentioned in the summary? Those are the games most likely to suck! The actual Gamespot page has titles like "Toki Tori" in its summary, which is a game that I was far more excited about than any movie rip-off. (It's a great game, BTW! Has a very Amiga-ish feel to it, too.)
That being said, the Kung-Fu Panda game does look interesting. The real questions are if the Wii controls really work as well as the previews suggest, and if the developers really put the time and effort into making the game interesting rather than a quick cash-in.
(Anyone remember back when Capcom used to NAIL Disney properties? Chip n' Dale Rescue Rangers & Duck Tales are some of the best games ever made for the NES.)
It's not my graph. It's the graph that the parent was referring to. As you pointed out, the data is skewed toward a certain segment of Unix users. My point was that if we take that chart as gospel (which we cannot, because it's not representative of the market as a whole) both GIT and Mercurial have already lost. Badly.
Git didn't have windows support very early on but very soon you could compile it with Cygwin.
Installing a Cygwin environment is not a supportable solution for most corporations. They needed native solutions. Something which has begun to appear.
Target audience were Linux hackers so having support for various other systems wouldn't have done much at all.
I agree with you wholeheartedly. The target audience is Linux hackers. They are the ones using GIT. The business world, OTOH, has chosen Mercurial. Such is the way of things.
Mercurial is the solution currently in use at Mozilla, Sun, and quite a few Linux projects. (Though not the main kernel branch. That's GIT. Think something more along the lines of ALSA.)
Mercurial is interesting because it encourages teams to work together, pushing and pulling source code from each other. When the source reaches a stable point, you can push that to a central repository for building and archiving.
The interesting aspect about this design is that it actively encourages branching! Rather than treating branches as a special thing that needs to be done under a certain set of circumstances, it treats every copy of the repository as a branch. So developers can work independently. When they come back together, the tool is able to auto-merge most projects back into a single whole.
Mercurial is able to do this because it tracks the point of divergence. With that information, it can see if any of the changes truly conflict. 95% of the time, there is no conflict and Mercurial is able to merge the files auto-magically. The other 5% of the time, Mercurial will launch a merge tool and make you answer YES/NO to each difference. This process is amazingly smooth.
The key thing to keep in mind with Mercurial is that you won't want to keep all your source in one repository. (Like most companies do with CVS.) Keep a separate repository for each project or module. You can keep the repositories all in the same path, but it's much easier to work with only the code you need rather than copying around a 10GB source tree from developer to developer.
If you do decide to try Mercurial and are given a Windows development machine, I highly recommend TortoiseHG. You'll occasionally have to run 'hg update' from the command line (the tool will prompt you), but it's otherwise a very slick way of working with Mercurial repositories.
Oh, and don't use the CVS->Mercurial conversion tools. It leaves CVS-style droppings all over creation. Just import the latest codebase and keep CVS running in read-only mode for as long as you need historical data.
GIT lost the version control war early on. Its focus on Linux development with little to no support for Windows and Mac made it unpopular. That's a situation that has changed (somewhat), but the stigma is still attached to it. Which is not really a problem. GIT was developed to meet the needs of the Linux Kernel Project. If it happens to meet the needs of other projects, great. If it doesn't, that's just as fine.
In any case, Mercurial ended up being the "best of breed" solution. It offered all the features of the competing version control systems, was portable across platforms, had a significant toolchain appear practically overnight, and is used by HUGE OSS companies like Sun and Mozilla. I've used it in my own projects and have found that it is much easier and more dynamic than the classic, monolithic model of CVS.
...how does this compare to Tamarin? With Javascript running for longer periods of time, a runtime-optimizing JIT seems to make a lot of sense. SquirrelFish's optimized bytecode engine sounds interesting, but I can't help but feel that it's going to fall short in the next-gen race for Javascript performance.
Of course, anything that improves JS performance in browsers (making some of the libraries faster and/or hardware accelerated always helps... hint, hint!) is a win for the consumer. And from that perspective this sounds very interesting.:-)
Looks like the same keyboard design to me. High impact plastic keycaps mounted on through-hole plastic posts, sprung with a small spring around the post. IIRC, the contact for the key is on the bottom of the post on the other side of the board through which the posts are threaded. (The plastic posts are usually + crosses to ensure that they don't exert unexpected torque on the keycaps. Also, the shape helps secure the keycaps as pressure is the only thing holding them on.)
The problem with this design is that a key that is not struck correctly (e.g. you hit the side of the key, or exert pressure in a direction other than straight down), friction can develop between the key and the board underneath. The post may even lean sideways during the strike. Since everything about the keys is designed to prevent this, the key effectively locks in place and the strike is missed. Thus the keyboard requires a certain amount of training, and is only effective when used from particular angles. (And with laptops, the angle of impact can change regularly.) This problem can be mitigated by striking the key harder to push past the sticking point, but why? Modern keyboards like the ones in the MacBook do just as good of a job with less force. They have a good feel about them, make it easy to find keys based on tactile feel, and generally are nice to type on.
If you're used to the keyboard on a TRS-80 Model 100 (which I'm amazed no one has drug out the infamous tag-line of "Trash 80" yet) then you won't notice the many quirks of such old keyboard designs. However, they are there, and they do frustrate modern users. Which is one of the many reasons why modern keyboards look nothing like those of the TRS-80 and C64 eras.
The difference is that the Model M really was an excellent keyboard. With every key exceptionally well sprung, the keyboard was so heavy you could kill someone with it. (Hmmm... Colonel Mustard did it in the office with the keyboard?) Yet the keys were very responsive, well spaced, and easy to type on. I'm not sure I'd go as far as to demand that all modern keyboards should emulate the Model M, but it was a good keyboard.
I have a first revision Commodore 64 with a keyboard like the TRS-80 Model 1000's. If it's all the same to you, I'd rather keep my flat-key MacBook keyboard. Typing on the C64 is not something I'd like to do on a regular basis. But typing on my MacBook? That is something I already do on a regular basis.
Sorry, but nostalgia is not a good stand-in for real-world superiority. (And I say that as a classic video game/computer collector.)
Thats the older generation for you...Thats the older generation for you...
Actually, I'd say it's more a matter of practical security vs. air-tight security.
Most of the posts here act like signed faxes come out of the blue and magically make things happen. Well, that's not a very secure way to use a fax machine. e.g. I'd hate to have Presidential orders executed with only a fax as evidence that the order is issued!
In real life, faxes of documents occur after a verbal agreement is reached. For example, let's say a company owes me stock options. I tell the company that I wish to exercise the options. They tell me that I need to review the terms of the options and sign them before the stocks are issued to me. Documents are faxed (or emailed!) to me for review. I review the documents and either deliver a verbal rejection (perhaps followed by modified terms) or I sign the documents and fax them in.
Let's look at the possible attacks in this situation. I have already verbally agreed to pursue this contract. If someone tries to forge my signature (why?) before I decide to reject the contract, the forgery will be discovered when I contact the company to offer my rejection of the terms.
Well, what if someone poses as me and begins the process? That could potentially be a problem. Except that my identity is usually verified up front. In a smaller company they already know me, my voice, my email, and my address. When I contact them, they know who I am. In a larger company, they will usually require proof of identification along with any papers being signed.
Someone can still steal the certificates from my mail, but that goes above and beyond the issues with fax machines.
To give another example, let's say I'm offered an employment contract. Obviously such a contract has been under negotiation for some time. By the time it's been faxed, it's clear as day that it was me who signed it and agreed to the terms. If my signature was forged for whatever reason, it would become rather clear when I don't show up for work the first day, or when some impostor shows up.
Granted, someone could have been impersonating me the entire time, but then they'd also need forged proof of identification to fill out the necessary tax forms at employment time.
I think you'll find that any contracts where there is concern of forgery or claims of forgery are handled in one of two ways:
1. The fax is used to confirm your agreement and get the process started. The actual documents must be physically mailed before the terms of the contract are fully realized.
2. Fax is unacceptable. The documents must be FedExed and signed for so that they can be tracked from person to person. Someone is ALWAYS accountable for the documents.
In short, faxes are just fine. Just don't act stupid when working with them. If you ever find a company that does, work to get their legal counsel fired. If that company is signing important documents without legal counsel, RUN. Run far away and never look back.
They fixed that. And sent replacement discs to everyone who had the problem.
There's definitely plenty to be upset at Activision for, but at least they own up to their mistakes after being caught. Harmonix just sticks their fingers in their ears and sings, "LALALALALALANINTENDOLALALALALAICANTHEARYOULALALALA".
4 songs for 100MB is not a problem. That's ~80 songs per 2GB SD Card. The problem is that the Rock Band FMV would be a lot more than 100mb/4 songs. That's the real reason why Harmonix thinks Nintendo "needs a hard drive". High-quality, FMV-based songs would chew through the available storage at an ungodly rate.
I don't think Activision or Harmonix had much choice of a choice but to strip these features out.
Activision didn't strip anything out. Online play exists in GHIII. Varied characters and costumes and purchases exist in GHIII. Even DLC is supposed to be arriving for GHIII. (Though I get the distinct impression that Activision is reneging on that particular promise in favor of making it a feature of GHIV. DLC was supposed to arrive as part of the "Pay to Play" branding that Nintendo released with WiiWare.)
So what has changed on the Wii where suddenly Harmonix is screwed and Activision can succeed?
Oh, I dunno. Activision already does everything that Harmonix says is impossible? Or am I just imagining that Nintendo WiFi support in GHIII? Harmonix can claim that the problem is that Rock Band is so much more complex than GHIII, but that excuse isn't going to fly with GHIV coming out. (Not that anyone bought it to begin with.)
Harmonix did a cheap port to the Wii. Worse yet, they expect everyone to pay PS3 and 360 prices for a PS2 game. Those are the facts. People are upset and are going to continue to be upset. Given that Harmonix shows no real signs of fessing up to their (rather stupid and transparent) attempts to pass blame onto Nintendo, they can expect that consumers will tell them to go screw themselves.
Looks like Guitar Hero is really turning up the heat in the ongoing war with Rock Band for dominance.
Especially when it comes to the most popular console in this generation: The Wii.
Harmonix got a lot of bad press lately for declaring that the Wii version would have no online play, no band tour support, no custom characters, no DLC, no support for the GHIII guitar, and just about every other major feature removed or gimped.
Harmonix has tried to pass the blame on to every possible target, especially Nintendo and Activision. Yet Activision already had most of the features in GHIII that Harmonix removed from Rock Band. Now with GHIV, Activision is announcing every feature that Harmonix claimed was impossible to support on the Wii, AND they have the full band support. Which further makes Harmonix look like they're trying to gyp customers.
The truth is that Harmonix had a contracted developer do a cheap-o port of Rock Band to the PS2. Since the PS2 had the weakest hardware of the last generation, they replace the game visuals with FMV and hoped that no one would notice. (Thus the lack of character creator.) At some point, some Harmonix or MTV exec got the bright idea that doing a quicky port of the PS2 revision (which is completely inappropriate for a console of the Wii's caliber, regardless of its graphical capability in comparison to the 360/PS3), thus resulting in a ton of missing features. Especially things that didn't make sense on the PS2. (e.g. No networking meant no online play or DLC. And the more massive FMV wasn't a problem since no one could download new songs anyway.)
Honestly, I think Harmonix would do a lot better if they just owned up to their mistakes and worked to correct them in the future. Instead, they keep blaming Nintendo for all their problems. As a result, I've decided that Harmonix does not need my $170. I'll be saving it for GHIV.
I find they generally have a lower failure rate than other manufacturers I have used in the past, and their tech support has been second to none.
To offer a counter-point, my last place of work saw regular failures with our Dell server equipment. My personal favorite was when the SQL Server database went offline and no one could figure out why. At first it appeared to be a disk failure. But if that was the case, why didn't the RAID array continue working with the other drives? Turns out, the RAID controller failed. Corrupted all the data on the disks, too. We had to pull the previous day's backup and apologize to customers that the day's data had been lost. (Thankfully it happened on a Saturday.)
(For those of you unfamiliar with JSON, it's basically a textual representation of JavaScript. e.g.
{ name: "Jenny", phone: "867-5309" }
If you trust the server, you can read that with a simple "var obj = eval('('+json+')');". If you don't trust the server, it's still easy to parse with very little code.)
Your link says: "Unfortunately, there's also a third conclusion. It seems that it's much, much easier to create a well performing program in Java. So, please consider it for a moment before you start recoding your Java program in C++ just to make it faster..."
In any case, the author of that test failed. The test includes start-up times in the results. Java is always going to lose micro-benchmarks where start-up time is included. Why? Because the JVM load gets included in the benchmarks. As anyone who knows Java well can tell you, Java's startup time is extremely costly. Once the JVM is running, however, it produces much better performance. The end result is that the startup cost will eclipse the actual benchmark being run.
I'm willing to bet you'll have a hard time finding a modern benchmark for Java that doesn't make that (simple!) mistake.
However, I will admit that I was overextending my reach by suggesting that no one runs benchmarks anymore because of the strong performance of Java. The reality is (as one might expect) much more complex. It's not that Java performed poorly in benchmarks. Quite the contrary. By 2004, Java was cleaning up in benchmarks. The problem is that micro-benchmarking sucks. All you end up getting is the two sides fighting over who can produce the most optimized benchmark possible. Which invariably ends up defeating the purpose of benchmarking for "real-world" code.
The long and short of it is that Java was proven to be more than fast enough, with the average case easily keeping pace or beating C++ code. Thus the statement by the author of the article you linked to:
"Unfortunately, there's also a third conclusion. It seems that it's much, much easier to create a well performing program in Java. So, please consider it for a moment before you start recoding your Java program in C++ just to make it faster..."
Hmm... lemme think about that. Maybe because Java has decent threading support built into the language? Maybe because the platform is portable to any architecture? Maybe because the JVM can "optimize the hell" out of the running Java code far better than you could "optimize the hell" out of your C++ by hand?
"Java is Slow" is a mantra that is easily 5+ years out of date. Java surpassed C++ performance many years ago, and by such a wide margin that no one even bothers running benchmarks anymore. Anyone repeating the "Java is Slow" mantra is merely branding themselves ignorant.
BSD has had a history of focusing on compactness. Something which evolved on the Linux side out of necessity rather than as a stated goal. I don't know what the size of a fully modern FreeBSD installation is, but a basic install used to be as little as 60 megs. Heck, I remember running a fully-featured desktop system off of a 300MB drive. (With swap!) I imagine that if you install a basic BSD distribution and a lightweight desktop, you could easily reach a usable system for under 300 megs. You shouldn't even need the latest in hardware.:-)
I'll see your Debian and raise you a copy of Linux from Scratch. Small, light, and does everything I need it to.:-)
Re:Doesn't even have to be live life...
on
The Phoenix Has Landed
·
· Score: 0, Redundant
Easier or not, JUST ONCE I'd like to see a few images from cheap color cameras just so we could put the "Is the sky ever blue or always putrid yellow?" question to rest. Both sides have made pretty good arguments, so the question was never really settled. As long as NASA continues to composite color images using non-visible lighting to "fill in" for the visible spectrum, there will always be a question.
Sometimes I think NASA forgets the human aspect of what they're doing. The science is good, but some folks just want to know if the sky is blue. Heck, I could see a television network getting huge ratings out of the "reality show" aspect of following a few astronauts around the moon with a handicam. At the very least, the general public would get to share the sensation (however abstracted) of what it's like to actually be there. That's an aspect that hasn't been considered in this race for the latest spectrographic results from a pile of rocks.
Probably less than you'd expect. Intel's latest line of Quad-core Xeon processors use 45nm fab technology. If these are 2.33GHz "Harpertown" chips, then each chip (not core!) uses only ~50 watts. That means these machines could be running in as little as 150 watts for the dual processor machines, and 250 watts for the quad processor machines. (Though the quad core machines are most likely drawing a lot more power than that for a full RAID array.) Which really isn't too shabby.
Slashdot Mirror
You know what's scary? This looks like it would have been fun. What they showed in the video looks like the original Half Life running in the Doom 3 engine. (i.e. Yet Another FPS(TM))
The list was so heavily weighted toward movies that it didn't make sense to call out the exception that proved the rule.
...only movie-based games mentioned in the summary? Those are the games most likely to suck! The actual Gamespot page has titles like "Toki Tori" in its summary, which is a game that I was far more excited about than any movie rip-off. (It's a great game, BTW! Has a very Amiga-ish feel to it, too.)
That being said, the Kung-Fu Panda game does look interesting. The real questions are if the Wii controls really work as well as the previews suggest, and if the developers really put the time and effort into making the game interesting rather than a quick cash-in.
(Anyone remember back when Capcom used to NAIL Disney properties? Chip n' Dale Rescue Rangers & Duck Tales are some of the best games ever made for the NES.)
It's not my graph. It's the graph that the parent was referring to. As you pointed out, the data is skewed toward a certain segment of Unix users. My point was that if we take that chart as gospel (which we cannot, because it's not representative of the market as a whole) both GIT and Mercurial have already lost. Badly.
If you go by Debian's popcon, Subversion has already kicked both our asses and we should all go home:
http://people.debian.org/~igloo/popcon-graphs/index.php?packages=darcs%2Cgit-core%2Cmercurial%2Cbzr%2Csubversion%2C+cvs&show_installed=on&want_legend=on&want_ticks=on&from_date=2003-10-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
Googlefight!
git tutorial: 512,000 results
mercurial tutorial: 1,100,000 results
Winner: Mercurial!
Google doesn't provide JACK for GIT. GIT uses SVN. In order to use GIT with Google, you need to have a GIT->SVN translator:
http://nigel.mcnie.name/blog/using-git-for-your-sourceforgegoogle-code-project Installing a Cygwin environment is not a supportable solution for most corporations. They needed native solutions. Something which has begun to appear.I agree with you wholeheartedly. The target audience is Linux hackers. They are the ones using GIT. The business world, OTOH, has chosen Mercurial. Such is the way of things.
Mercurial is the solution currently in use at Mozilla, Sun, and quite a few Linux projects. (Though not the main kernel branch. That's GIT. Think something more along the lines of ALSA.)
Mercurial is interesting because it encourages teams to work together, pushing and pulling source code from each other. When the source reaches a stable point, you can push that to a central repository for building and archiving.
The interesting aspect about this design is that it actively encourages branching! Rather than treating branches as a special thing that needs to be done under a certain set of circumstances, it treats every copy of the repository as a branch. So developers can work independently. When they come back together, the tool is able to auto-merge most projects back into a single whole.
Mercurial is able to do this because it tracks the point of divergence. With that information, it can see if any of the changes truly conflict. 95% of the time, there is no conflict and Mercurial is able to merge the files auto-magically. The other 5% of the time, Mercurial will launch a merge tool and make you answer YES/NO to each difference. This process is amazingly smooth.
The key thing to keep in mind with Mercurial is that you won't want to keep all your source in one repository. (Like most companies do with CVS.) Keep a separate repository for each project or module. You can keep the repositories all in the same path, but it's much easier to work with only the code you need rather than copying around a 10GB source tree from developer to developer.
If you do decide to try Mercurial and are given a Windows development machine, I highly recommend TortoiseHG. You'll occasionally have to run 'hg update' from the command line (the tool will prompt you), but it's otherwise a very slick way of working with Mercurial repositories.
Oh, and don't use the CVS->Mercurial conversion tools. It leaves CVS-style droppings all over creation. Just import the latest codebase and keep CVS running in read-only mode for as long as you need historical data.
GIT lost the version control war early on. Its focus on Linux development with little to no support for Windows and Mac made it unpopular. That's a situation that has changed (somewhat), but the stigma is still attached to it. Which is not really a problem. GIT was developed to meet the needs of the Linux Kernel Project. If it happens to meet the needs of other projects, great. If it doesn't, that's just as fine.
In any case, Mercurial ended up being the "best of breed" solution. It offered all the features of the competing version control systems, was portable across platforms, had a significant toolchain appear practically overnight, and is used by HUGE OSS companies like Sun and Mozilla. I've used it in my own projects and have found that it is much easier and more dynamic than the classic, monolithic model of CVS.
...how does this compare to Tamarin? With Javascript running for longer periods of time, a runtime-optimizing JIT seems to make a lot of sense. SquirrelFish's optimized bytecode engine sounds interesting, but I can't help but feel that it's going to fall short in the next-gen race for Javascript performance.
:-)
Of course, anything that improves JS performance in browsers (making some of the libraries faster and/or hardware accelerated always helps... hint, hint!) is a win for the consumer. And from that perspective this sounds very interesting.
This is about a video. That you can download. And watch. For $2.99 an episode or $24.99 for 12 episodes. Games need not apply.
Looks like the same keyboard design to me. High impact plastic keycaps mounted on through-hole plastic posts, sprung with a small spring around the post. IIRC, the contact for the key is on the bottom of the post on the other side of the board through which the posts are threaded. (The plastic posts are usually + crosses to ensure that they don't exert unexpected torque on the keycaps. Also, the shape helps secure the keycaps as pressure is the only thing holding them on.)
The problem with this design is that a key that is not struck correctly (e.g. you hit the side of the key, or exert pressure in a direction other than straight down), friction can develop between the key and the board underneath. The post may even lean sideways during the strike. Since everything about the keys is designed to prevent this, the key effectively locks in place and the strike is missed. Thus the keyboard requires a certain amount of training, and is only effective when used from particular angles. (And with laptops, the angle of impact can change regularly.) This problem can be mitigated by striking the key harder to push past the sticking point, but why? Modern keyboards like the ones in the MacBook do just as good of a job with less force. They have a good feel about them, make it easy to find keys based on tactile feel, and generally are nice to type on.
If you're used to the keyboard on a TRS-80 Model 100 (which I'm amazed no one has drug out the infamous tag-line of "Trash 80" yet) then you won't notice the many quirks of such old keyboard designs. However, they are there, and they do frustrate modern users. Which is one of the many reasons why modern keyboards look nothing like those of the TRS-80 and C64 eras.
As I said, nostalgia is not a good stand-in.
The difference is that the Model M really was an excellent keyboard. With every key exceptionally well sprung, the keyboard was so heavy you could kill someone with it. (Hmmm... Colonel Mustard did it in the office with the keyboard?) Yet the keys were very responsive, well spaced, and easy to type on. I'm not sure I'd go as far as to demand that all modern keyboards should emulate the Model M, but it was a good keyboard.
I have a first revision Commodore 64 with a keyboard like the TRS-80 Model 1000's. If it's all the same to you, I'd rather keep my flat-key MacBook keyboard. Typing on the C64 is not something I'd like to do on a regular basis. But typing on my MacBook? That is something I already do on a regular basis.
Sorry, but nostalgia is not a good stand-in for real-world superiority. (And I say that as a classic video game/computer collector.)
Most of the posts here act like signed faxes come out of the blue and magically make things happen. Well, that's not a very secure way to use a fax machine. e.g. I'd hate to have Presidential orders executed with only a fax as evidence that the order is issued!
In real life, faxes of documents occur after a verbal agreement is reached. For example, let's say a company owes me stock options. I tell the company that I wish to exercise the options. They tell me that I need to review the terms of the options and sign them before the stocks are issued to me. Documents are faxed (or emailed!) to me for review. I review the documents and either deliver a verbal rejection (perhaps followed by modified terms) or I sign the documents and fax them in.
Let's look at the possible attacks in this situation. I have already verbally agreed to pursue this contract. If someone tries to forge my signature (why?) before I decide to reject the contract, the forgery will be discovered when I contact the company to offer my rejection of the terms.
Well, what if someone poses as me and begins the process? That could potentially be a problem. Except that my identity is usually verified up front. In a smaller company they already know me, my voice, my email, and my address. When I contact them, they know who I am. In a larger company, they will usually require proof of identification along with any papers being signed.
Someone can still steal the certificates from my mail, but that goes above and beyond the issues with fax machines.
To give another example, let's say I'm offered an employment contract. Obviously such a contract has been under negotiation for some time. By the time it's been faxed, it's clear as day that it was me who signed it and agreed to the terms. If my signature was forged for whatever reason, it would become rather clear when I don't show up for work the first day, or when some impostor shows up.
Granted, someone could have been impersonating me the entire time, but then they'd also need forged proof of identification to fill out the necessary tax forms at employment time.
I think you'll find that any contracts where there is concern of forgery or claims of forgery are handled in one of two ways:
1. The fax is used to confirm your agreement and get the process started. The actual documents must be physically mailed before the terms of the contract are fully realized.
2. Fax is unacceptable. The documents must be FedExed and signed for so that they can be tracked from person to person. Someone is ALWAYS accountable for the documents.
In short, faxes are just fine. Just don't act stupid when working with them. If you ever find a company that does, work to get their legal counsel fired. If that company is signing important documents without legal counsel, RUN. Run far away and never look back.
They fixed that. And sent replacement discs to everyone who had the problem.
There's definitely plenty to be upset at Activision for, but at least they own up to their mistakes after being caught. Harmonix just sticks their fingers in their ears and sings, "LALALALALALANINTENDOLALALALALAICANTHEARYOULALALALA".
Activision didn't strip anything out. Online play exists in GHIII. Varied characters and costumes and purchases exist in GHIII. Even DLC is supposed to be arriving for GHIII. (Though I get the distinct impression that Activision is reneging on that particular promise in favor of making it a feature of GHIV. DLC was supposed to arrive as part of the "Pay to Play" branding that Nintendo released with WiiWare.)
Oh, I dunno. Activision already does everything that Harmonix says is impossible? Or am I just imagining that Nintendo WiFi support in GHIII? Harmonix can claim that the problem is that Rock Band is so much more complex than GHIII, but that excuse isn't going to fly with GHIV coming out. (Not that anyone bought it to begin with.)
Harmonix did a cheap port to the Wii. Worse yet, they expect everyone to pay PS3 and 360 prices for a PS2 game. Those are the facts. People are upset and are going to continue to be upset. Given that Harmonix shows no real signs of fessing up to their (rather stupid and transparent) attempts to pass blame onto Nintendo, they can expect that consumers will tell them to go screw themselves.
Harmonix got a lot of bad press lately for declaring that the Wii version would have no online play, no band tour support, no custom characters, no DLC, no support for the GHIII guitar, and just about every other major feature removed or gimped.
Harmonix has tried to pass the blame on to every possible target, especially Nintendo and Activision. Yet Activision already had most of the features in GHIII that Harmonix removed from Rock Band. Now with GHIV, Activision is announcing every feature that Harmonix claimed was impossible to support on the Wii, AND they have the full band support. Which further makes Harmonix look like they're trying to gyp customers.
The truth is that Harmonix had a contracted developer do a cheap-o port of Rock Band to the PS2. Since the PS2 had the weakest hardware of the last generation, they replace the game visuals with FMV and hoped that no one would notice. (Thus the lack of character creator.) At some point, some Harmonix or MTV exec got the bright idea that doing a quicky port of the PS2 revision (which is completely inappropriate for a console of the Wii's caliber, regardless of its graphical capability in comparison to the 360/PS3), thus resulting in a ton of missing features. Especially things that didn't make sense on the PS2. (e.g. No networking meant no online play or DLC. And the more massive FMV wasn't a problem since no one could download new songs anyway.)
Honestly, I think Harmonix would do a lot better if they just owned up to their mistakes and worked to correct them in the future. Instead, they keep blaming Nintendo for all their problems. As a result, I've decided that Harmonix does not need my $170. I'll be saving it for GHIV.
To offer a counter-point, my last place of work saw regular failures with our Dell server equipment. My personal favorite was when the SQL Server database went offline and no one could figure out why. At first it appeared to be a disk failure. But if that was the case, why didn't the RAID array continue working with the other drives? Turns out, the RAID controller failed. Corrupted all the data on the disks, too. We had to pull the previous day's backup and apologize to customers that the day's data had been lost. (Thankfully it happened on a Saturday.)
Done. What's next on your list?
(For those of you unfamiliar with JSON, it's basically a textual representation of JavaScript. e.g. If you trust the server, you can read that with a simple "var obj = eval('('+json+')');". If you don't trust the server, it's still easy to parse with very little code.)
Your link says: "Unfortunately, there's also a third conclusion. It seems that it's much, much easier to create a well performing program in Java. So, please consider it for a moment before you start recoding your Java program in C++ just to make it faster..."
In any case, the author of that test failed. The test includes start-up times in the results. Java is always going to lose micro-benchmarks where start-up time is included. Why? Because the JVM load gets included in the benchmarks. As anyone who knows Java well can tell you, Java's startup time is extremely costly. Once the JVM is running, however, it produces much better performance. The end result is that the startup cost will eclipse the actual benchmark being run.
I'm willing to bet you'll have a hard time finding a modern benchmark for Java that doesn't make that (simple!) mistake.
However, I will admit that I was overextending my reach by suggesting that no one runs benchmarks anymore because of the strong performance of Java. The reality is (as one might expect) much more complex. It's not that Java performed poorly in benchmarks. Quite the contrary. By 2004, Java was cleaning up in benchmarks. The problem is that micro-benchmarking sucks. All you end up getting is the two sides fighting over who can produce the most optimized benchmark possible. Which invariably ends up defeating the purpose of benchmarking for "real-world" code.
The long and short of it is that Java was proven to be more than fast enough, with the average case easily keeping pace or beating C++ code. Thus the statement by the author of the article you linked to:
"Unfortunately, there's also a third conclusion. It seems that it's much, much easier to create a well performing program in Java. So, please consider it for a moment before you start recoding your Java program in C++ just to make it faster..."
Hmm... lemme think about that. Maybe because Java has decent threading support built into the language? Maybe because the platform is portable to any architecture? Maybe because the JVM can "optimize the hell" out of the running Java code far better than you could "optimize the hell" out of your C++ by hand?
"Java is Slow" is a mantra that is easily 5+ years out of date. Java surpassed C++ performance many years ago, and by such a wide margin that no one even bothers running benchmarks anymore. Anyone repeating the "Java is Slow" mantra is merely branding themselves ignorant.
Whatchoo' talkin' 'bout, Willis? Have you never heard of NanoBSD and TinyBSD?
Not to mention Damn Small BSD, M0n0wall, and the FreeBSD LiveCD. (Among others.)
BSD has had a history of focusing on compactness. Something which evolved on the Linux side out of necessity rather than as a stated goal. I don't know what the size of a fully modern FreeBSD installation is, but a basic install used to be as little as 60 megs. Heck, I remember running a fully-featured desktop system off of a 300MB drive. (With swap!) I imagine that if you install a basic BSD distribution and a lightweight desktop, you could easily reach a usable system for under 300 megs. You shouldn't even need the latest in hardware.
I'll see your Debian and raise you a copy of Linux from Scratch. Small, light, and does everything I need it to. :-)
Easier or not, JUST ONCE I'd like to see a few images from cheap color cameras just so we could put the "Is the sky ever blue or always putrid yellow?" question to rest. Both sides have made pretty good arguments, so the question was never really settled. As long as NASA continues to composite color images using non-visible lighting to "fill in" for the visible spectrum, there will always be a question.
Sometimes I think NASA forgets the human aspect of what they're doing. The science is good, but some folks just want to know if the sky is blue. Heck, I could see a television network getting huge ratings out of the "reality show" aspect of following a few astronauts around the moon with a handicam. At the very least, the general public would get to share the sensation (however abstracted) of what it's like to actually be there. That's an aspect that hasn't been considered in this race for the latest spectrographic results from a pile of rocks.