Comments on: Time change and is software reliability really a good thing?
In a few days, we will be setting our clocks back to return to standard time. In recent years, I've come to dislike daylight savings time. There are too many clocks that must be changed... Clocks on ovens, microwaves, desktops, telephones, cars, VCRs, pump timers, cameras, handhelds, on and on. Sometimes, I think we should just spring forward 30 minutes, and leave it there. Forever.
But, if we did that, one of those little gotcha side effects would pop up: We would forget how to set a lot of our clocks.
For instance, the clocks in my car and on the microwave oven are not obvious to set. The twice-a-year ritual keeps those procedures fresh in my mind. It's an odd, twisted kind of advantage, isn't it?
Is that same "advantage" also true for software systems? If software fails often enough, then you remember how to work on it, right? Many of us know quite well how to edit the Windows registry, because we do it often enough. Otherwise, it might become a lost "art". Imagine that.
So, if software does not fail enough, then you forget about it!
That is precisely why some of you found a few of our REBOL/IOS servers (like Alliance) offline recently. A primary, secondary (UPS), and tertiary (generator) power outage took down one of our server locations. The REBOL/IOS servers on that machine had been running continuously since the initial server boot more than a year ago. In fact, it was found that the IOS boot script had never actually been added to the Linux OS boot sequence (rc.local), accounting for the fact those IOS servers did not come back up when power was restored.
So there you go. There's the proof. If IOS went down more often, such things would not happen.
This observation is perhaps a bit tongue-in-cheek. But, I think there might be a grain of truth lurking in it somewhere. It's a corollary of the old "squeaky wheel gets the grease" syndrome. You know of it... it's that same syndrome that now runs all of our government, state, and local institutions. But, that rant is a story for another blog and another day. (Perhaps when I get a personal blog online someday.)
So, have fun setting all your clocks next week.
And by that time, it would be nice to have red-icons problem fixed :-) There is long time RAMBO ticket with sufficient enough analysis to it. And last week Ladislav added one comment to it - it seems to it, REBOL uses some different function for determination of time-zone, and that one fails ....
But maybe REBOL is more a living organism, than bits and bytes, and so is reluctant to time changes too :-)
Yes, lol. I agree, and it has been a long drawn-out problem with time! (So, let's not release 2.6.3 without getting that problem fixed for sure.)|
Ah, that fix would be nice, we could depend on time information a bit more then.
btw - how goes your R3 design schema picture release? :-)
Heh. Good 'ole IOS.|
Ah time. Oddly enough I had a client point out to me that a timezone in one of my online apps is wrong. But due to the magic of daylight savings, .. the time will be correct on Monday ;-) -- funny no-one noticed until now.|
One could argue, that if a system needs to break down now and then, because people then keep remembering how to fix it, there might be something wrong with the system. It might be too complicated!
Things should be so simple, that when they break, it should be no problem, almost triviel, to fix it. I guess, Carl is thinking in these lines.
A little philosophy:
Time! ... :-) What is time? Can you measure time? Actually, what you're measuring, is the change of a physical system. It's not possible to measure time directly like the other 3 dimensions (space coords). So we live in a 3+1 dimensional world, where the one time dimension isn't a real dimension like the other. Then it's funny, that we also have 3+1 natural forces. The electro-magnetic force, the strong and the weak nuclear force. And then we have gravity. Maybe gravity isn't a real force, like time isn't a real dimension? I hope, this wasn't too off-topic. ;-)
The reliability of the mainframe systems is causing the same concern. When they were written and broke often, there was expertise to fix them but when some parts have been running reliably for 15 years there is no current knowledge about what to do when they stop being reliable. |
Great point Mike. A friend of mine that works at Edwards AFB in the flight test division related a story about how the whole flight test operation was shut down for more than 24 hours when two Amiga 2000 computers failed after 15 years of continuous operation. They had to fly a guy in from Georgia who knew how to fix the problem with one of the custom chips. Fortunately they had an ample supply of chips on hand that had never been used. Apparently they have dozens of Amigas running over there.|
Seems that IOS and Amiga have the same "problem".|
I have that problem with some unix "cron" scripts that I wrote some years ago and have been running regularly without any problems. When something does go wrong, it gives me quite a headache to figure out all over again how they work.
Documentation can help with that. I think that the job of a programmer is not just to write programs, but to write programs plus documentation plus whatever else it takes to make it possible for those programs to be understood and maintained.
Post a Comment:
You can post a comment here. Keep it on-topic.