I'm actually typing this from a Fujitsu P series, and I will admit it's great and highly portable, but it still has to boot and running always on still gives you only 4 hours, 8 with the add-on batter pack.
Isn't the whole idea at some point is to get some type of realistic convergence on all these devices? Seriously, I hate having to pack a PDA, and a cell phone, and a laptop, and an MP3 player, and my solar powered battery charger, and my 18 different adapters, and my........you get the idea.
My girlfriend just got an Audiovox-PPC 6601 and I have to admit it's pretty slick with a 1GB SD card, handles cell duties, PDA, and music duties reasonably well, although it's not great. I figure the amount it would cost to buy all those devices separately, you're probably looking at at least the same amount if not more.
I think something like the OQO or the Fliptop will prolly be the ideal device, but I still think they're having issues with getting extended battery life out of it.
I don't understand all these people pounding on their chest about how this was due to disaster recovery planning, or lack thereof....
From what I gather, there should have been some sort of usage stats that should have been monitored. However, if the limit wasn't documented and wasn't readily known to the developer or the users, how was anyone supposed to flag it?
There should have been a software lifespan that was originally projected, not because of software aging, etc, but because no one can realistically expect that a piece of software should last forever, even if it's working just fine. On a general level, it will probably cost you less to stay current than it will to suffer something like Comair did, but that's a blanket statement that is not always true. Either way, it's a complicated issue.
There probably was some sort of disaster recovery plan in place, but I'm not sure since it wasn't mentioned. Even if we had a time delayed secondary site up that accepted changes and was accessible, could someone please point out to me how this would have been avoided? I'm gonna say that this system was prolly not coded to be a distributed or clustered system and would share the load between two sites so that neither site would then suffer the fate of having more that 32000 changes on that day, but that only means that we're still a ticking time bomb before the error shows up or the system is upgraded and you hope that a similar type of limit isn't imposed on the new app.
How does a DR plan let them avoid a fatal flaw in their app, short of upgrading/code change/etc? I'm gonna guess that if the primary failed, and they were too worried about getting the DR site up, rather than actually figuring out what the issue was, they would've walked right into the same problem at the DR site.
We're talking about a system that affects millions upon millions of dollars, and it's a definite risk for someone to stick their neck out and be on the line for the success or failure of the successor to an app that had apparently, for better or worse, become a lynchpin within the organization. Does that excuse some of their obvious circular laziness that got them to where they went? No, but it is also understandable that not everyone has the cajones to stick their neck out on something that is so high profile.
Few people are leaders and propogate change, most are policy enforcers that only appear to lead. So should it really be a suprise that there are hundreds (more likely thousands) of companies that are potentially going to be the next Comair?
The number of times I had to use "should" is a strong indicator that there are a number of things that could have been done to avoid the issue, but bottom line, the problem in this particular case was poor coding on the part of the developer, and nothing else. This problem as mentioned before, could have appeared at any time during it's use, and the article I think puts completely the wrong slant on what needs to be done to correct issues like this.
Slashdot Mirror
I'm actually typing this from a Fujitsu P series, and I will admit it's great and highly portable, but it still has to boot and running always on still gives you only 4 hours, 8 with the add-on batter pack. Isn't the whole idea at some point is to get some type of realistic convergence on all these devices? Seriously, I hate having to pack a PDA, and a cell phone, and a laptop, and an MP3 player, and my solar powered battery charger, and my 18 different adapters, and my........you get the idea. My girlfriend just got an Audiovox-PPC 6601 and I have to admit it's pretty slick with a 1GB SD card, handles cell duties, PDA, and music duties reasonably well, although it's not great. I figure the amount it would cost to buy all those devices separately, you're probably looking at at least the same amount if not more. I think something like the OQO or the Fliptop will prolly be the ideal device, but I still think they're having issues with getting extended battery life out of it.
I don't understand all these people pounding on their chest about how this was due to disaster recovery planning, or lack thereof.... From what I gather, there should have been some sort of usage stats that should have been monitored. However, if the limit wasn't documented and wasn't readily known to the developer or the users, how was anyone supposed to flag it? There should have been a software lifespan that was originally projected, not because of software aging, etc, but because no one can realistically expect that a piece of software should last forever, even if it's working just fine. On a general level, it will probably cost you less to stay current than it will to suffer something like Comair did, but that's a blanket statement that is not always true. Either way, it's a complicated issue. There probably was some sort of disaster recovery plan in place, but I'm not sure since it wasn't mentioned. Even if we had a time delayed secondary site up that accepted changes and was accessible, could someone please point out to me how this would have been avoided? I'm gonna say that this system was prolly not coded to be a distributed or clustered system and would share the load between two sites so that neither site would then suffer the fate of having more that 32000 changes on that day, but that only means that we're still a ticking time bomb before the error shows up or the system is upgraded and you hope that a similar type of limit isn't imposed on the new app. How does a DR plan let them avoid a fatal flaw in their app, short of upgrading/code change/etc? I'm gonna guess that if the primary failed, and they were too worried about getting the DR site up, rather than actually figuring out what the issue was, they would've walked right into the same problem at the DR site. We're talking about a system that affects millions upon millions of dollars, and it's a definite risk for someone to stick their neck out and be on the line for the success or failure of the successor to an app that had apparently, for better or worse, become a lynchpin within the organization. Does that excuse some of their obvious circular laziness that got them to where they went? No, but it is also understandable that not everyone has the cajones to stick their neck out on something that is so high profile. Few people are leaders and propogate change, most are policy enforcers that only appear to lead. So should it really be a suprise that there are hundreds (more likely thousands) of companies that are potentially going to be the next Comair? The number of times I had to use "should" is a strong indicator that there are a number of things that could have been done to avoid the issue, but bottom line, the problem in this particular case was poor coding on the part of the developer, and nothing else. This problem as mentioned before, could have appeared at any time during it's use, and the article I think puts completely the wrong slant on what needs to be done to correct issues like this.