The trouble with Rover is revealed

EE Times ^ | 2/20/04 | Ron Wilson

[Bobby777]

hehe ... no kidding ... the big thrill for the Rover was when you won the game and the cards go bouncing all over the screen ... lol

[Bobby777]

While we are on the subject, would you happen to have a cheat for ms solitaire?

http://www.cheatchannel.com/files/windowssoe.htm

I found this on Google ... 3.x above

Draw One Card: Cheat mode (Windows 3.x): ---------------------------------------- Start a three card draw game. Hold [Ctrl] + [Alt] + [Shift] and click on the deck to only draw one card.

this also appears to work on my Windows 98 SR2 ... happy Solitaire!

[Final Authority]

Your reply cites a good example of what I was talking about but in detail. Oftentimes the problem I have is user interface and output controls. These should be relatively easy to deal with but if communication breaks down so does the outcome. Overall, considering the complexity of most jobs, the SW guy does a good job and the systems work, but dealing with constant upgrades is a pain especially in commercial and industrial applications where operators must be made aware of changes and the documentation must be updated and controlled as well.

[Ernest_at_the_Beach]

Thanks for posting this.

[Ernest_at_the_Beach]

As a postscript, Klemm noted that the other day he heard a car commercial on the radio that made reference to the Mars rover, comparing, for example, the car's speed over the ground to Spirit's. In the process of touting the car's extended-warranty program, the ad noted that the Mars rover came with "interplanetary roadside assistance." "That phrase just stuck in my mind," Klemm said. " love it."

LOL!

[onyx]

LOL!

[mosel-saar-ruwer]

Your reply cites a good example of what I was talking about but in detail. Oftentimes the problem I have is user interface and output controls. These should be relatively easy to deal with but if communication breaks down so does the outcome. Overall, considering the complexity of most jobs, the SW guy does a good job and the systems work, but dealing with constant upgrades is a pain especially in commercial and industrial applications where operators must be made aware of changes and the documentation must be updated and controlled as well.

You know what I think is possibly the most difficult task in writing a program? Especially if you don't know a priori [before starting the program] how long the program will run?

My Answer: Stopping the program. Getting a program up and running is pretty trivial [in and of itself], but stopping a running program is so difficult it's nigh unto impossible. If I were a team leader on a big software project, I'd design every system backwards: "OK, fellas, let's start our planning phase by asking ourselves: How will we go about shutting down this system?"

Figuring out how to start the system would be the very last step in the design phase.

[KayEyeDoubleDee]

You know what I think is possibly the most difficult task in writing a program? Especially if you don't know a priori [before starting the program] how long the program will run?

I've never had this problem/insight/epiphany.

[KayEyeDoubleDee]

a running program is so difficult it's nigh unto impossible

Whoops. This is the part that I've never had trouble with...

[KayEyeDoubleDee]

a running program is so difficult it's nigh unto impossible

Whoops. This is the part that I've never had trouble with...

ARGGGHHHH

stopping a running program is so difficult it's nigh unto impossible

[mosel-saar-ruwer]

Whoops. This is the part that I've never had trouble with...

Suppose you've got n threads, each keeping tabs on mission critical pieces of data, and suppose each of the n threads can be in m possible states. That gives you n sets of mission critical data in n*m possible states. Suppose further that there might be inter-relationships among the n*m states: If thread i is in state u, then that effects the behavior of thread j, which is in state v.

Now suppose you decide to shut the whole thing down: You've got to send n "kill" signals to each of the threads, and the way each thread responds to the kill signal depends on some possibly fantastically complicated logic describing the state of the relationships between the n threads and their m possible states.

If you're not careful, it's real easy to construct a house of cards where putting thread zero to sleep causes the whole thing to go crazy, and much of your mission-critical data gets lost in the shuffle, or gets overwritten with garbage [or you turn off the patient's ventilator, or you shut down the nuclear power plant's cooling system, or you alter the ICBM's launch status from comatose to pre-launch countdown...].

[KayEyeDoubleDee]

Like I said, I've never had this problem. Its possible that m threads have n states, each with different reactions to a shutdown event, but, in my experience, not very likely.