<ASPO Houston: Day 1, part 1The Oil DrumCanadian Gas - Decline Sets in.>

240 comments on DrumBeat: October 19, 2007

Comments can no longer be added to this story.

Darwinian on October 19, 2007 - 12:34pm Permalink | Subthread | Parent | Comments top

If I recall, they had tons of 'old' computers that were made from the late 70's to late 90's that were NOT upgraded and allowed to pass through y2k naturally.

No, that is simply not true. I worked at NASA, as a CSC contractor, during the years running up to Y2K. We upgraded every computer on our site and made them Y2K compatable. A similar effort was made in all government sites as well as all banking and financial institutions.

There were no very old computers in use during those years. Those old mainframes were obsolete and cost more electricity to operate for a couple of months than a new computer cost. Plus they were much slower and had only a tiny fraction of the storage space. Remember computer technology, in speed and storage space, in those days was doubling about every 18 months. And the price of these new computers was tiny compared to the millions those old giant dinosaurs cost. There were simply no old computers in use in those days because of that very reason.

Any computer that still used two digit year codes, and there were a few of them, had serious problems. But the vast majority of them, at least 99%, had been upgraded to use four digit year codes.

Ron Patterson

0
Comments can no longer be added to this story.
hardhat on October 19, 2007 - 4:07pm Permalink | Subthread | Parent | Comments top

I didn't worry about Y2K one bit.

I have dissassemblers (WDASM, IDA) and a debuggers (SoftIce, HView, etc. ). If my machines did ANYTHING I did not like, I would just open the program and find out why - and patch it.

This was in the era where a lot of kids were out there reversing software to remove registration codes. I figured our computing infrastructure was extremely robust and resilent when you factor in how many people out there knew assembler and exactly how the processor and kernel code works.

Today, though, I am not nearly as confident of the resilence of commercial software, albeit I still have a very high confidence of open-source software.

I have no doubt that breaches of Linux kernels would be highly discussed in tech forums and solutions explained and freely shared. I do not have this confidence for proprietary software, which relies on salesmanship, not technical understanding, for its adoption.

Leanan gave a beautiful distinction a few drumbeats ago when she discussed how resilence differs from efficiency.

IMHO, proprietary software is more efficient due to central control, but - like having all your corn all one strain - - its not very resistant to a blight that could take out the entire crop. Open Source software is more robust, providing one hires/trains/retains the skills to know it.

Its not the Y2K type stuff that I fear - rather its our own ignorance on how our systems work that would enable hostile entities to plant unseen rootkits in the commercial stuff, using botnets and snooping scripts to make google-like databases of everything companies thought was private.

My fear is also based on the suspected cooperation between our supposed antivirus vendors and the government regarding non-reporting of "approved" system intrusions, and the likelihood of hostile entities using this backdoor much like they used the famous Sony rootkit to violate systems that had played a Sony disk.

All these "hold harmless" clauses in the EULAs destroy my confidence of "trusted computing". All this lawmaking concerning the enforcement of ignorance of how our own computing infrastructure works scares the hell out of me.

Basically, I fear we are selling the resilence of our computational infrastructure for a song. Literally. Just so that knowledge can be monopolized.

When I have anything to do with proprietary OS, it seems to me like going to the the car dealership for a car, then immediately trucking it over to the Norton garage to have the wheels welded on so they don't fall off. I feel so stupid allowing the car dealership to force me into their EULA denying any guarantee the car will work, but the businessman who sent me demands that car, and I must fulfill his funded desire, not mine.

If I do not know what my own system is doing, I am wide open for someone else to control it - and I won't know who they are or what they are doing.

Geez, Monsters under the Bed all over again.

Steve

0
Comments can no longer be added to this story.
eric blair on October 19, 2007 - 7:43pm Permalink | Subthread | Parent | Comments top

All these "hold harmless" clauses in the EULAs destroy my confidence of "trusted computing".

Software hold harmless clause did you say?
http://gizmodo.com/gadgets/weapons/robot-cannon-goes-berserk-kills-9-312...

. The Oerlikon GDF-005 antiaircraft gun suddenly began uncontrollably shooting as it swung back and forth, spraying hundreds of high-explosive 35mm cannon shells all over the place. The crazed robot's handlers are still trying to figure out what sort of software bug would cause such mayhem.

0
Comments can no longer be added to this story.
ET on October 19, 2007 - 8:07pm Permalink | Subthread | Parent | Comments top

have dissassemblers (WDASM, IDA) and a debuggers (SoftIce, HView, etc. ). If my machines did ANYTHING I did not like, I would just open the program and find out why - and patch it.

This was in the era where a lot of kids were out there reversing software to remove registration codes. I figured our computing infrastructure was extremely robust and resilent when you factor in how many people out there knew assembler and exactly how the processor and kernel code works.

hardhat, you don't sound like you have worked in a corporate software environment. Typically there are many software systems dependent on each other and it simply is not possible for one geek to patch a piece of software if it fails since the patch might screw up a whole lot of inter-dependencies. Not to mention that much, if not most of the software is under someone else's control and the lone geek doesn't have the authority to fix and replace the main source and object code.

In my own experience, Y2K software work was not at all straightforward and one often had to follow a 'trail' of dependency of different software systems and the data that was dealt with. In these conversations, people seem to ignore that it was not only a software problem but a data problem as well.

There were many situations where things probably would have been ok had nothing been done, but I remain convinced that Y2K would have been a much larger problem than it was. It remains one of those situations where you can't prove that the problem that was avoided would have happened if a lot of people hadn't paid attention to it.

0
Comments can no longer be added to this story.
ImSceptical on October 19, 2007 - 8:59pm Permalink | Subthread | Parent | Comments top

Ron, there was no need to change computers. The problem was one of software in which dates had benn coded for storage with two digits for the year, Dec. 31, 1999 was stored as 991231 and Jan 1. 2000 would be 000101. When the two dates were compared, Jan 1, 2000 would be less than Dec 31, 1999 and therefore earlier. Mostly it was a matter of inserting code around the comparison to handle the situation.

No computer in use on Dec. 31, 1999 had an internal clock problem. If I remember correctly, there was an obscure computer model that would roll over its internal clock in 2008, but it was being phased out because of the obsolence you identified. However, several major OS's have still to reach the limits of their internal clock buffers; these include IBM's MVS and descendants, all Microsoft systems, the original Apple, and all Unix.

However, I believe the question will be moot because we'll be deep into collapse by that time.

-
James Gervais

0
Comments can no longer be added to this story.