That *might* be true, but if it were, you'd think they'd have been asked to conduct some real science, not focus on the golly-gee-whiz-we-found-ice aspect.
Most of the comments so far are focusing on the oven door problems. Naturally, because that's what's mentioned in the summary and no one RTFAs.
Anyway, the *much* more interesting revelation is that after the problems came up, the directive came all the way down from the top of NASA directing the mission scientists to change their plans. "At the end of June, word came down that the Phoenix team was to treat its next TEGA sample as its last, and to go after a sample of rock-hard ice before it did anything else. The Tucson team had lost its autonomy." After that, the team blew at least a month trying to meet this directive, and missed out on doing some of the basic science they wanted to do, just so NASA heads could trumpet feel-good publicity about having detected ice with Phoenix.
Agreed, adoption is still pretty low, but it's definitely a game-changer. Surprisingly, SSDs might show up first en masse at the low end in netbooks like the Eee. Consider the lower power requirements and instant-on possibilities.
Blood to squeeze? How about a new stone? Solid-state drives.
SSDs. Yep, they will completely change the rules for filesystems. Decades of tricks and tweaking to deal with rotational latency and head movement have virtually zero application in SSDs. All the code for that will become worse than useless. It will have to be removed or at least turned off. Leaving it on will actually result in worse performance on SSDs.
Actually, Dijkstra spent a lot of time showing how to prove a program's correctness.
He did. In fact, he spent more time proving the program correct than it took to write, test, run, debug, and fix, the program, and then the proof still has to be checked for correctness. I learned the Dijkstra techniques for proving code. Even something as painfully simple as proving a loop invariant holds and would terminate was mind-numbingly difficult and tedious, and still fails to be correct in the presence of concurrency. Somehow the program proof advocates lost sight of Gödel's incompleteness theorems. On top of being theoretically shaky, the technique is so wildly inefficient that the costs overwhelm the value almost before you get started. See the previous/. article, on how avoiding mistakes is a mistake.
There's no worry about actually using this for real data tracking or metrics purposes
I agree with the other comments saying to just fake it with pretty gadgets. It's already a fake from conception, no point spending any effort beyond satisfying the requirement that it impress potential customers.
Have you considered Visual Complex Analysis by Tristan Needham? It might be too low-level, I don't know. I also second the suggestion of Penrose's "Road to Reality"
I don't know about Windows machines, but I heard that certain robotic probes run VxWorks and are remotely controlled via a low-bandwidth, high-latency connection. Those devices have a lot of programmed autonomy and fail-safe built in. And they don't run Windows.
Cheaper in the short term, and the long term costs are difficult or impossible to see. As anyone who has been paying attention to economic news lately knows, it's all about the short term, and damned be the long term.
There's no good economic or technical reason to keep these systems around -- the fact that they are still being used and patched is a reflection of office politics and managerial failures.
I also like the central server aspect, so that there is one place where the code is located, and I just have to keep that backed up.
Nothing wrong with that, if it's effective for you and your team, and clearly svn wins out over git. Trying to make git within that model is just adding complexity without getting the benefits. If, in the future, you and your team decide you need to change how you do source control, then git, or some other distribute peer-to-peer system, might be the solution. But don't just use it as a drop-in replacement for centralized server development.
The most effective use of GIT happens when the team changes its mindset away from the central repository with multiple developers checking into it to a true peer-to-peer development team. I wouldn't switch away from svn until the organization I was with was prepared to "think different" and make that transition. Using GIT like a fancy svn just makes it like a complicated svn, not a better way of doing version control.
Since at least the dot-com era and maybe before, there's been a demand for entry-level software developers. It's the subject of Steve McConnell's essay Orphans Preferred. Companies like pulling cheap labor from colleges and grinding the people down until they either burn out or get wise and fight back at the bullshit, at which point the company replaces the burnouts and malcontents with the next wave of suckers.
From Wikipedia: "anyone who makes a false claim of infringement... is liable for the damages suffered by the other parties, including legal fees."
The law is very one-sided about it though, and recovering damages is prohibitively expensive. Oh yeah, there's also the fact that the law states that a counter-notification to restore the material must be sworn under penalty of perjury, unlike the original takedown notice, which just needs to be a good-faith attempt, with no criminal penalty for falsehood.
Slashdot Mirror
That *might* be true, but if it were, you'd think they'd have been asked to conduct some real science, not focus on the golly-gee-whiz-we-found-ice aspect.
Most of the comments so far are focusing on the oven door problems. Naturally, because that's what's mentioned in the summary and no one RTFAs.
Anyway, the *much* more interesting revelation is that after the problems came up, the directive came all the way down from the top of NASA directing the mission scientists to change their plans. "At the end of June, word came down that the Phoenix team was to treat its next TEGA sample as its last, and to go after a sample of rock-hard ice before it did anything else. The Tucson team had lost its autonomy." After that, the team blew at least a month trying to meet this directive, and missed out on doing some of the basic science they wanted to do, just so NASA heads could trumpet feel-good publicity about having detected ice with Phoenix.
Agreed, adoption is still pretty low, but it's definitely a game-changer. Surprisingly, SSDs might show up first en masse at the low end in netbooks like the Eee. Consider the lower power requirements and instant-on possibilities.
Blood to squeeze? How about a new stone? Solid-state drives.
SSDs. Yep, they will completely change the rules for filesystems. Decades of tricks and tweaking to deal with rotational latency and head movement have virtually zero application in SSDs. All the code for that will become worse than useless. It will have to be removed or at least turned off. Leaving it on will actually result in worse performance on SSDs.
At last, something to put on my flying toasters! Do you btrfs will handle the requirements of Video Toaster?
Actually, Dijkstra spent a lot of time showing how to prove a program's correctness.
He did. In fact, he spent more time proving the program correct than it took to write, test, run, debug, and fix, the program, and then the proof still has to be checked for correctness. I learned the Dijkstra techniques for proving code. Even something as painfully simple as proving a loop invariant holds and would terminate was mind-numbingly difficult and tedious, and still fails to be correct in the presence of concurrency. Somehow the program proof advocates lost sight of Gödel's incompleteness theorems. On top of being theoretically shaky, the technique is so wildly inefficient that the costs overwhelm the value almost before you get started. See the previous /. article, on how avoiding mistakes is a mistake.
Famous last words:
There's no worry about actually using this for real data tracking or metrics purposes
I agree with the other comments saying to just fake it with pretty gadgets. It's already a fake from conception, no point spending any effort beyond satisfying the requirement that it impress potential customers.
Different essay here: Regardless of law, marriage has only one definition, and any government that attempts to change it is my mortal enemy.
Have you considered Visual Complex Analysis by Tristan Needham? It might be too low-level, I don't know. I also second the suggestion of Penrose's "Road to Reality"
Doesn't Microsoft already own patents for embedding objects in videos with OLE? /silly
Oddly, at least in the non-vibrating version, the cartridges are cheaper per unit than Gillette's older 3-blade Sensor.
Tastes like chicken. Duh.
I don't know about Windows machines, but I heard that certain robotic probes run VxWorks and are remotely controlled via a low-bandwidth, high-latency connection. Those devices have a lot of programmed autonomy and fail-safe built in. And they don't run Windows.
Couldn't happen to a better guy.
http://cobolforgcc.sourceforge.net/
Cheaper in the short term, and the long term costs are difficult or impossible to see. As anyone who has been paying attention to economic news lately knows, it's all about the short term, and damned be the long term.
There's no good economic or technical reason to keep these systems around -- the fact that they are still being used and patched is a reflection of office politics and managerial failures.
I also like the central server aspect, so that there is one place where the code is located, and I just have to keep that backed up.
Nothing wrong with that, if it's effective for you and your team, and clearly svn wins out over git. Trying to make git within that model is just adding complexity without getting the benefits. If, in the future, you and your team decide you need to change how you do source control, then git, or some other distribute peer-to-peer system, might be the solution. But don't just use it as a drop-in replacement for centralized server development.
The most effective use of GIT happens when the team changes its mindset away from the central repository with multiple developers checking into it to a true peer-to-peer development team. I wouldn't switch away from svn until the organization I was with was prepared to "think different" and make that transition. Using GIT like a fancy svn just makes it like a complicated svn, not a better way of doing version control.
More like the set of imaginary numbers. The square root of the value of DRM to ordinary people who listen to music and watch movies.
Also to muddle the meaning of "open source" to the point where people start to believe it means what Microsoft says it means.
Oh no! http://xkcd.com/386/
Luckily, I believe in the market
I believe in the Tooth Fairy, the Easter Bunny, and Santa Clause. Where's my pony?
Or a CueCat. We know how big of a killer app.
Since at least the dot-com era and maybe before, there's been a demand for entry-level software developers. It's the subject of Steve McConnell's essay Orphans Preferred. Companies like pulling cheap labor from colleges and grinding the people down until they either burn out or get wise and fight back at the bullshit, at which point the company replaces the burnouts and malcontents with the next wave of suckers.
From Wikipedia: "anyone who makes a false claim of infringement ... is liable for the damages suffered by the other parties, including legal fees."
The law is very one-sided about it though, and recovering damages is prohibitively expensive. Oh yeah, there's also the fact that the law states that a counter-notification to restore the material must be sworn under penalty of perjury, unlike the original takedown notice, which just needs to be a good-faith attempt, with no criminal penalty for falsehood.