240 comments on DrumBeat: October 19, 2007
Comments can no longer be added to this story.
| Show without comments | PDF version
240 comments on DrumBeat: October 19, 2007
Comments can no longer be added to this story.
| Show without comments | PDF version
Search The Oil Drum with Google
Support The Oil Drum
Recently on TOD:World
TOD:Campfire
- Thanksgiving Open Campfire Thread
- How Relocalization Worked
- How to Set Up and Run a Bicycle Repair Company
TOD:Europe
- Unique Times -- and the Future
- Peak Gold, Easier to Model than Peak Oil? - Part I
- Carbon Capture and Storage
TOD:Canada
- In this house, we obey the laws of thermodynamics!
- The Round-Up: October 24, 2008
- Compressed Air Energy Storage - How viable is it?
TOD:Australia/NZ
- The Bullroarer - Friday 27th November 2009
- International Energy Agency calls 'Peak' on OECD Oil Demand
- Australian Senate: Peak Oil motion defeated 31:6
TOD:Net Energy
Blogroll
Energy Sites
- The Coming Global Oil Crisis
- Die Off
- Dry Dipstick
- Energy Bulletin
- From the Wilderness
- Life After the Oil Crash
- Peak Oil Crisis
- Peak Oil News and Message Boards
- Powerswitch
- Rigzone
- Matthew Simmons
- Wolf at the Door
Environment & Sustainability Sites
- The Daily Green
- EcoGeek
- Eco Street
- Green Car Congress
- Green Options
- green.alltop.com
- Gristmill
- RealClimate
- Sustainablog
- Treehugger
- WorldChanging
Blogs
- Casaubon's Book
- Cleantech Blog
- Clusterf
k Nation (Jim Kunstler) - The Cost of Energy
- David Strahan
- Early Warning
- The Energy Blog
- European Tribune
- GraphOilology
- Health After Oil
- jeffvail.net
- Mobjectivist
- Peak Energy (Australia)
- Peak Energy (USA)
- R-Squared
- Resource Insights
Finance & Economics Blogs
- The Big Picture
- Calculated Risk
- The Crash Course
- Ecological Economics
- Econbrowser
- Environmental Economics
- Infectious Greed
- The Mess That Greenspan Made
- Mish's Global Economic Trend Analysis
Organizations
Peak Oil Primers
Beware email scams!
Beware email scams claiming to be from this site. We do not have any job openings. If anyone contacts you about a job at The Oil Drum, do not reply to them, and definitely do not give them any personal information or send them money. Read more here.
“Government is too big and too important to be left to the politicians.”
—Claire Huchet Bishop
User login
Contact
- Content: editors at theoildrum dot com
- Tech support: support at theoildrum dot com
Personnel
- Editors: Nate Hagens, Gail the Actuary, Prof. Goose
- DrumBeat Editor: Leanan
- Contributors: ace, Engineer-Poet, Heading Out, jeffvail, JoulesBurn, Sam Foucher, Robert Rapier
- TOD:Campfire: Glenn, Jason Bradford
- TOD:Europe: Chris Vernon, Euan Mearns, Francois Cellier, Jerome a Paris, Luís de Sousa, Rembrandt, Rune Likvern, Ugo Bardi
- TOD:Canada: benk, Libelle
- TOD:ANZ: Big Gav, Phil Hart, aeldric
- Emeritus: Stuart Staniford
- Technician: Super G
License
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.










GAIA Host Collective
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
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...
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.