Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
For the out-of-band Slashdot experience (mostly headlines), follow us on Twitter, or Facebook. ×

Wii 2 Delay Is Hurting Nintendo 310 310

Posted by Soulskill
from the hurting-all-the-way-to-the-bank dept.
BanjoTed writes "Michael Pachter's ongoing spat with Nintendo regarding the Wii 2 is well documented. Pachter is sure it's coming, Nintendo says it's not. Now the analyst has gone one further by claiming that the declining sales of the Wii documented in the platform holder's recent financial statements will only get worse unless it speeds up attempts to get its successor to market. He said, 'The reason for this is clear: the software being created is just not interesting enough or compelling enough to drive Wii owners to buy more than two [games] per year, and most of those purchases are first party software. We can blame the third party publishers for making shovelware, or for misjudging the Wii market, but the simple fact is that the publishers have to develop completely separate games for the Wii because its CPU is not powerful.'"

Comment: Re:Clarifications (I'm the quoted source) (Score 2, Informative) 393 393

by gdamore (#31877026) Attached to: Oracle Wants Proof That Open Source Is Profitable
Okay, this is not anonymous. I had forgotten my password. But yes, those clarifications above are from me. The same as the poster. The subject of this article is totally, and completely wrong. Open source was never in question. Only Open Development.

Comment: Re:Better recovery... (Score 1) 411 411

by gdamore (#18725811) Attached to: Word 2007 Flaws Are Features, Not Bugs
Anyone here do kernel programming?

A common practice in kernel programming when encountering a totally unexpected situation is to "panic". The unexpected situations where this is acceptable are often one of two classes:

1) critical failure of a critical piece of hardware (e.g. your root disk going out to lunch), uncorrectable memory errors (but detectable), etc.

2) programming errors. (generally "bugs".) When developing code that makes certain assumptions, its often a good idea to validate those assumptions with something called an "assertion". (For example, an assumption that a linked list is properly terminated can be checked, or that the caller owns a particular lock, etc.)

In both cases, the response is to "crash" (or "panic").

Why do we do this? First, we've encountered a situation from which we do not have any realistic hope of recovering... so rather than risk data corruption or worse problems later down the road, we crash, to "stop the hemorrhaging" so to speak.

Second, this a good panic will also cause a dump of the system state to be taken, so that it can be analyzed later. In the case of hardware failure, it may give some clue as to what the bad component is that needs to be replaced. In the case of a programmer error, it often provides the details necessary to find and fix the bug.

Its not unreasonable to believe that situations like this could come up for application programs as well.

However, one thing that is _unacceptable_ for a kernel to do, is to crash just because a user happened to send bad input, or a network happened to spew bad data. (Errors _inside_ the chassis can cause a panic... errors from _outside_ the chassis should not.)

I think M$ have some debugging to do...

The rate at which a disease spreads through a corn field is a precise measurement of the speed of blight.