I prefer my turkey...
at about 3PM on October 12th , thank you very much!
Yes. We use PowerChute everywhere; it's a good product.
But, at least in a production system, you still should be doing regular "real" failover tests to ensure that what is supposed to happen does really happen. For example, a common problem is a sequence like:
- Power fails, UPS predicts 20 minutes of runtime;
- Servers are set to shut themselves down when 5 minutes of runtime remains;
- Fifteen minutes later, the servers start their shutdown sequences;
- The increased CPU and disk activity from the shutdown increase the power draw, causing the battery to empty and all power to be cut 90 seconds earlier than expected.
Another issue is that software added during a system's lifetime can cause a server that took 180 seconds to shut down last year to now require 240 seconds.
Either issue can mean you wind up with servers that powered off with a 90% completed shutdown.
The only way you'll discover these kinds of problems is to actually simulate a real power fail once in a while.
Really, a $150 investment to protect your $500+ computer is more than worth it.
Don't forget to add the cost of replacing the UPS battery every year or two. Plus the time to setup and regularly test the fail-over and auto-shutdown.
FWIW I generally use a UPS on the servers and firewalls, but not on any of the clients.
So would you prefer your V-Brain to be running on Hyper-V or VMWare? What about checkpointing your V-Brain and clone a whole farm of V-You's?
Not to mention that there are options for "a year or less" and "until about ten years from now". Kind of jarring for those of us statistically unlikely to survive another ten years -- does this mean we only have a year to live?
Well, for one thing, this discussion is more useful to many of us (who may be in a similar situation) if the comments are kept general. The moment the product is identified, the comments will naturally drift towards issues specific to that situation.
Better to mount them on ceiling as that way your feet don't get so hot.
BALR *,13 to you, sir.
surely it was
BALR 15,0
USING *,15
no?
PS: I blame this to be the start of the enormous overuse of #define in subsequent decades, as most people thought it was cool to equate R15 to 15 (etcetera) and then write the above as
BALR R15,R0
USING *,R15
leading to the endless nested equating we get in modern C and C++.
PPS: for the worst such mess ever created, does anyone else remember the COBOL "ALTER" command?
Using a text editor to write code for a device like an iOS device, that simply displays the weather or a stock price is so
Well -- 1970's maybe. 1960's were more about drum storage and all that. Even in the early '70s, the 029 keypunches didn't let us correct typos -- you had to hold the "dup" key down to duplicate the bit you got right, and then carry on keying from where the mistake started. The 129's were much better, as they only punched the card after you finished the whole line.
Although come to think of it, I did write a nice simple weather app in 360/Assembler for a class in 1974.
Hello fellow pedant.
You have to extend the planes into the plane of the camera view.
When the front and back planes are extended it is entirely possible for the camera view plane to be perpendicular to both. In fact, it would be impossible for it to be perpendicular to only one since you pointed out that the front and back planes are parallel.
True. Mea culpa.
What I was objecting to was something else, implied in parent post, to the effect that the lens axis lay on the both the front and back planes of the phone at the same time. But I expressed it poorly.
I've noticed several design suggestions in your code.