Probably because it's easier for Nintendo of Japan to negotiate payment for marketing data than with Nintendo of America. That's what registration is -- marketing research. Prizes is the cost of doing business, and a substantial number of US distributors don't make the game, just localize and distribute.
My brother bought Halo 3 and took it and the 360 over to a friends house to play. They have a dog, and he now has a ruined 60 dollar disc. You can't return it, you can't get a replacement. But when asked, companies insist that you don't own the game you purchased.
And if you're not the best developer, what are you doing guarding the gates?
There are many functions a gatekeeper has, that may actually be served by not having the best developer in that position. Open Source code is expected to be valuable based on the number of people who can understand and modify it. If the "best developer" can understand and approves more code than an average developer, you're actually reducing the value of the code.
This is why Bugzilla deployments universally suck. Mozilla took the best developers they could find and had them write perl code.
The first system that would today be known as RISC was not at the time; it was the CDC 6600 supercomputer, designed a decade earlier, in 1964, by Jim Thornton and Seymour Cray... Thus the joking comment later that the acronym RISC actually stood for "Really Invented by Seymour Cray".
Cray computer hardware was designed (on purpose) using an algorithm (I think for division) that was very fast, but did not always produce the correct result.
Admittedly, I was not alive at the time, but I'd like a good cite on that fact. As I understand it, Cray's innovative design was to build division and multiplication operations out of smaller instructions like bitshifts, because the resulting Reduced Instruction Set was capable of clocking faster. Perhaps you're confusing RISC with floating point operations, which ALWAYS have a range of error to be considered.
But I'll feed you an alternative fact to support your theory: NP complete problems are generally insolvable on computers and we instead use approximations that have a much more amenable runtime. But unlike your suggestion, instead of just accepting this as demonstrating that proofs are unworkable in real world, we use proofs to show that a solution is within an acceptable percentage of the optimal solution. It turns out that a number of operations algorithms are NP-complete, so this is very relevant to avionics software and real time computing.
If you honestly believe that "value brought to society" is the metric of a software engineer, then you've set in concrete Dijikstra's (and my) point that software engineering as practiced today has nothing to do with computers in particular.
People seem to think that scientists are different from academics; one sits in a lab with beakers while the other sits in an office filling out paperwork and wrestling for budget. I'd say a Nobel laureate has the right balance of bureaucratic experience and experience not being dependent on grant money (the Nobel prize is quite large after all) to bring change to the table.
Specifically on the case of the Arianne V; I imagine my own professors disagree simply by the photography time series on the cover of our programming logic book. It's a set of photos of the Arianne launching and exploding. And I'm inclined to agree with them; detecting a downcast is simple enough and not hardware dependent. It should have been the case that a proof that the system never enters that condition was found before disabling the trap for performance reasons; instead we have a very expensive case of premature optimization;)
If Djikstra's abilities isn't part of software engineering, then I'm afraid the typical tension between traditional engineering and software shall remain. Engineering is about producing designs to the best of our human ability. If you as an engineer know a design to be faulty and risks human life, you have an ethical obligation to not sign off on it. This means that the "balance" as you put it, is not in favor of time, money or production. What you've described can best be placed under the heading "management", and your comparison to Microsoft betrays you here.
Microsoft was a mediocre software development company. What they really became good at was not writing software, but buying and selling it. They specialize in negotiations with large companies, and all their flagship software shows it. But despite their apparent success, I don't think many avionics software engineers are quick to claim themselves engineers of the Microsoft variety.
My point is that if we could prove a bridge would stay up, it would be in the best interests of society to do so.
Rockets have not exploded from "gamma rays". They have exploded from catastrophic timing failures; people have gone back and looked at the Arianne V and proved it couldn't have worked in specific circumstances. Specific circumstances that were not exercised during testing. Specific circumstances that could have been avoided by world class software. Instead they tried to save money by integrating the software to Arianne IV and calling it a day; when the launch count deviated for 30 minutes, our good friend overflow showed up. You don't have to crash a rocket to know what integer overflow is, but apparently we need to crash more of them before its worth looking for them in the source.
And this is Dijikstra's point: we are not at the point where entropy is the primary engineering cause of software failure (certainly not when he wrote that), and trying to pretend that software is just like structural engineering leads to flawed analogies you consistently lean on.
The premise in his paper was can't use tests to prove a program is correct, only to prove it's incorrect. This is separate from proving programs correct in the general sense.
The halting problem is not a problem in interrupt routines, unless your interrupts happen to check whether they'll terminate before they try executing. What you are discussing is real time priorities, which thankfully many smarter people than I have studied deeply and constructed theory for. In this case, a switch statement (ie a series of if statements implemented efficiently) is one way to implement it. Another, way is to have interrupt priorities and interrupt vectors in hardware and have smart programmers trained in concurrent programming logic write re-entrant code.
In my experience, software engineers are generally not up to the task of reasoning about interrupt based systems, so the standard is retard control loops.
Dijistra's entire point is that proof-of-correctness is the only way to get correct programs, and the industry has chosen to ignore it even as they mire in a cess pool of buggy software because it's too radical. Not too computationally infeasible; too radical. A small error in software can lead to a huge disaster, in contrast to every day life. We know this, and generally try to pretend it doesn't apply to us -- we don't write rocket software, we don't write real time systems. And hell, we only write a small fraction of the software we use. But I think few of us bother to quantify the price of bad software for our company or clients.
Since he wrote this, I suspect a worthwhile rebuttal has been discovered: the fundamental error Dijkstra makes is assuming it's possible to find a specification worth proving the program against. In many cases, the hardest part is figuring out just what the hell is needed, not putting it into C or Java. On the other hand, my alma mater does teach freshman proof of correctness, but as a secondary course rather than in a "intro to programming" course. Simply put, far too many programs want an intro to programming course but feel a programming proof course will raise dropout rates.
I think it's a little ridiculous that they won't let you publish games for free. I understand it's hosted on their dime, so is there some side band of publishing I'm not aware of?
I can't speak for the hardware vendors, but it does bring a stable release cycle. If you're basing off of Debian, do you plan for lenny or lenny+1, and what do you do when you slip, or when they slip? Several DDs seem to pride themselves on the fact that it ships "when its done". This is stupid for several reasons, the easiest of which to point out is that with no automated software testing, Debian only has a record of reported bugs, not all bugs. "Perfect" Debian releases is one more reason the software comes out later than sooner.
Canonical also likely brings something to the table, with their build infrastructure running on ARMs hardware. You might look at it like this: Canonical knows Debian well enough to hire and work with Debian when hardware vendors can't or don't. So yes, Ubuntu/Canonical isn't much different than Debian, but they're the go-to guy when you want Debian technology.
"urging device manufacturers to start immediate testing with its pre-beta release" - Translation: Get on the ball and do our work for us.
Well, I think in an ideal world, manufacturers would work together with their OS vendor to ensure quality. After all, they're the people best able to write the drivers: they have the documentation, the IP and the designs. Microsoft's WHQL tries to twist manufacturer's arms to do adaquate testing already; this is more of a call for driver engineers to start earlier than they did on Vista.
This might be a key distinction between Linux and Windows. Linux has a lot of driver developers working on behalf of companies, either as contractors, consultants or employees, but are still subject to some peer review. They're expected to test their own hardware here too. And I think Greg K-H's assertion that once your code is in tree nobody will break it is bogus. Once your code is in tree, you get to do continual testing to make sure nobody broke it, because nobody else likely is.
From an economic standpoint, it's probably easier for a lot of firms to make a small investment in testing than it is a few firms to make a huge investment in hardware to test. Given all this, I don't think it's Microsoft's job to test motherboards etc.
Retro started out as a partnership, which evolved into an ownership position when the founder left (usually a bad sign). But you do bring up a good point; Nintendo's strategy to capitalize on the eager fan engineers was to farm out some franchises. It worked, to a degree. Fzero GX and Metroid Prime are two examples of that, an extension of an older program to lend characters to an existing game (mario golf and tennis). Retro is basically a one trick pony, and it looks like people have gotten a bit tired of of their pony show. I'm glad they were able to pay homage to the franchise, but they've basically worked themselves into a hole where if you deviate too much it's no longer Metroid, and if you don't, you're selling the same thing over and over again.
Amusingly, the actual team behind Portal were at DigiPen, a training institute that Nintendo of America is deeply intertwined with. I dare say part of the reason that Portal is that Nintendo is very Japan centric, and unable to fully embrace American innovators, even ones they grew. Valve happily snatched the group up and paired them with talent from everywhere. If you look at their one endeavor to actually capitalize on the eager people ready to work for Nintendo, NST, they're a damn near failure. Every game they make is a derivative or sequel, it's like a list of "all the games you fuckers should have played, damnit!" It's clearly not a matter of talent, so I'm willing to blame management.
Clearly many people involved with Portal are enamored with Miyamato's games. Seanbaby brings a culture of gaming steeped in the history of gaming, all the way back to the NES. And yet it seems like NoA would have made sure nobody with his edgy cult celebrity status would participate.
Slashdot Mirror
Probably because it's easier for Nintendo of Japan to negotiate payment for marketing data than with Nintendo of America. That's what registration is -- marketing research. Prizes is the cost of doing business, and a substantial number of US distributors don't make the game, just localize and distribute.
Sarcasm is one form of communicating insight, I suppose.
My brother bought Halo 3 and took it and the 360 over to a friends house to play. They have a dog, and he now has a ruined 60 dollar disc. You can't return it, you can't get a replacement. But when asked, companies insist that you don't own the game you purchased.
And if you're not the best developer, what are you doing guarding the gates?
There are many functions a gatekeeper has, that may actually be served by not having the best developer in that position. Open Source code is expected to be valuable based on the number of people who can understand and modify it. If the "best developer" can understand and approves more code than an average developer, you're actually reducing the value of the code.
This is why Bugzilla deployments universally suck. Mozilla took the best developers they could find and had them write perl code.
I enjoy your brand of logic. You owe me ten dollars, unless you can prove you don't.
From the wikipedia on RISC:
Cray computer hardware was designed (on purpose) using an algorithm (I think for division) that was very fast, but did not always produce the correct result.
Admittedly, I was not alive at the time, but I'd like a good cite on that fact. As I understand it, Cray's innovative design was to build division and multiplication operations out of smaller instructions like bitshifts, because the resulting Reduced Instruction Set was capable of clocking faster. Perhaps you're confusing RISC with floating point operations, which ALWAYS have a range of error to be considered.
But I'll feed you an alternative fact to support your theory: NP complete problems are generally insolvable on computers and we instead use approximations that have a much more amenable runtime. But unlike your suggestion, instead of just accepting this as demonstrating that proofs are unworkable in real world, we use proofs to show that a solution is within an acceptable percentage of the optimal solution. It turns out that a number of operations algorithms are NP-complete, so this is very relevant to avionics software and real time computing.
If you honestly believe that "value brought to society" is the metric of a software engineer, then you've set in concrete Dijikstra's (and my) point that software engineering as practiced today has nothing to do with computers in particular.
People seem to think that scientists are different from academics; one sits in a lab with beakers while the other sits in an office filling out paperwork and wrestling for budget. I'd say a Nobel laureate has the right balance of bureaucratic experience and experience not being dependent on grant money (the Nobel prize is quite large after all) to bring change to the table.
Specifically on the case of the Arianne V; I imagine my own professors disagree simply by the photography time series on the cover of our programming logic book. It's a set of photos of the Arianne launching and exploding. And I'm inclined to agree with them; detecting a downcast is simple enough and not hardware dependent. It should have been the case that a proof that the system never enters that condition was found before disabling the trap for performance reasons; instead we have a very expensive case of premature optimization ;)
If Djikstra's abilities isn't part of software engineering, then I'm afraid the typical tension between traditional engineering and software shall remain. Engineering is about producing designs to the best of our human ability. If you as an engineer know a design to be faulty and risks human life, you have an ethical obligation to not sign off on it. This means that the "balance" as you put it, is not in favor of time, money or production. What you've described can best be placed under the heading "management", and your comparison to Microsoft betrays you here.
Microsoft was a mediocre software development company. What they really became good at was not writing software, but buying and selling it. They specialize in negotiations with large companies, and all their flagship software shows it. But despite their apparent success, I don't think many avionics software engineers are quick to claim themselves engineers of the Microsoft variety.
My point is that if we could prove a bridge would stay up, it would be in the best interests of society to do so.
Rockets have not exploded from "gamma rays". They have exploded from catastrophic timing failures; people have gone back and looked at the Arianne V and proved it couldn't have worked in specific circumstances. Specific circumstances that were not exercised during testing. Specific circumstances that could have been avoided by world class software. Instead they tried to save money by integrating the software to Arianne IV and calling it a day; when the launch count deviated for 30 minutes, our good friend overflow showed up. You don't have to crash a rocket to know what integer overflow is, but apparently we need to crash more of them before its worth looking for them in the source.
And this is Dijikstra's point: we are not at the point where entropy is the primary engineering cause of software failure (certainly not when he wrote that), and trying to pretend that software is just like structural engineering leads to flawed analogies you consistently lean on.
Would that we could -- point is in most cases we can but don't. Software is not bridges.
BTW, D is not in standard Ubuntu repositories, but I've found this:
Umm, yes it is.
The premise in his paper was can't use tests to prove a program is correct, only to prove it's incorrect. This is separate from proving programs correct in the general sense.
The halting problem is not a problem in interrupt routines, unless your interrupts happen to check whether they'll terminate before they try executing. What you are discussing is real time priorities, which thankfully many smarter people than I have studied deeply and constructed theory for. In this case, a switch statement (ie a series of if statements implemented efficiently) is one way to implement it. Another, way is to have interrupt priorities and interrupt vectors in hardware and have smart programmers trained in concurrent programming logic write re-entrant code.
In my experience, software engineers are generally not up to the task of reasoning about interrupt based systems, so the standard is retard control loops.
Dijistra's entire point is that proof-of-correctness is the only way to get correct programs, and the industry has chosen to ignore it even as they mire in a cess pool of buggy software because it's too radical. Not too computationally infeasible; too radical. A small error in software can lead to a huge disaster, in contrast to every day life. We know this, and generally try to pretend it doesn't apply to us -- we don't write rocket software, we don't write real time systems. And hell, we only write a small fraction of the software we use. But I think few of us bother to quantify the price of bad software for our company or clients.
Since he wrote this, I suspect a worthwhile rebuttal has been discovered: the fundamental error Dijkstra makes is assuming it's possible to find a specification worth proving the program against. In many cases, the hardest part is figuring out just what the hell is needed, not putting it into C or Java. On the other hand, my alma mater does teach freshman proof of correctness, but as a secondary course rather than in a "intro to programming" course. Simply put, far too many programs want an intro to programming course but feel a programming proof course will raise dropout rates.
I think it's a little ridiculous that they won't let you publish games for free. I understand it's hosted on their dime, so is there some side band of publishing I'm not aware of?
Civilization allows ten saves per profile, and prompts you once per "age". If you don't overwrite it'll fill fast anyways.
How can you be sure of that? Canonical is a private company who doesn't have to disclose much about their expenses and revenues.
I can't speak for the hardware vendors, but it does bring a stable release cycle. If you're basing off of Debian, do you plan for lenny or lenny+1, and what do you do when you slip, or when they slip? Several DDs seem to pride themselves on the fact that it ships "when its done". This is stupid for several reasons, the easiest of which to point out is that with no automated software testing, Debian only has a record of reported bugs, not all bugs. "Perfect" Debian releases is one more reason the software comes out later than sooner.
Canonical also likely brings something to the table, with their build infrastructure running on ARMs hardware. You might look at it like this: Canonical knows Debian well enough to hire and work with Debian when hardware vendors can't or don't. So yes, Ubuntu/Canonical isn't much different than Debian, but they're the go-to guy when you want Debian technology.
And they were both godawful and slow.
Here's a hint: if you can, your regex aren't regular.
The regex is beautiful in the sense that it lets you not be one of those assholes who refuses valid email addresses.
Well, I think in an ideal world, manufacturers would work together with their OS vendor to ensure quality. After all, they're the people best able to write the drivers: they have the documentation, the IP and the designs. Microsoft's WHQL tries to twist manufacturer's arms to do adaquate testing already; this is more of a call for driver engineers to start earlier than they did on Vista.
This might be a key distinction between Linux and Windows. Linux has a lot of driver developers working on behalf of companies, either as contractors, consultants or employees, but are still subject to some peer review. They're expected to test their own hardware here too. And I think Greg K-H's assertion that once your code is in tree nobody will break it is bogus. Once your code is in tree, you get to do continual testing to make sure nobody broke it, because nobody else likely is.
From an economic standpoint, it's probably easier for a lot of firms to make a small investment in testing than it is a few firms to make a huge investment in hardware to test. Given all this, I don't think it's Microsoft's job to test motherboards etc.
Retro started out as a partnership, which evolved into an ownership position when the founder left (usually a bad sign). But you do bring up a good point; Nintendo's strategy to capitalize on the eager fan engineers was to farm out some franchises. It worked, to a degree. Fzero GX and Metroid Prime are two examples of that, an extension of an older program to lend characters to an existing game (mario golf and tennis). Retro is basically a one trick pony, and it looks like people have gotten a bit tired of of their pony show. I'm glad they were able to pay homage to the franchise, but they've basically worked themselves into a hole where if you deviate too much it's no longer Metroid, and if you don't, you're selling the same thing over and over again.
Amusingly, the actual team behind Portal were at DigiPen, a training institute that Nintendo of America is deeply intertwined with. I dare say part of the reason that Portal is that Nintendo is very Japan centric, and unable to fully embrace American innovators, even ones they grew. Valve happily snatched the group up and paired them with talent from everywhere. If you look at their one endeavor to actually capitalize on the eager people ready to work for Nintendo, NST, they're a damn near failure. Every game they make is a derivative or sequel, it's like a list of "all the games you fuckers should have played, damnit!" It's clearly not a matter of talent, so I'm willing to blame management.
Clearly many people involved with Portal are enamored with Miyamato's games. Seanbaby brings a culture of gaming steeped in the history of gaming, all the way back to the NES. And yet it seems like NoA would have made sure nobody with his edgy cult celebrity status would participate.