Slashdot Mirror

For those /.ers who are interested enough about DMCA to want to write to their representatives in Congress about it, there is a note in the latest Risks Digest from another person who has concluded that he cannot take the risk of continuing to work in the encryption field either commercially or academically. Tracing the back links in that story gives other instances.

Visit this site, and learn some more information about voting, as well as some interesting con points about computerized voting.

The whole premise of the article is that the current system(s) in place don't work well. This is just plain false.

You think current development methodologies work well?

I want you to remember that statement the next time your machine crashes. The next time you get an e-mail containing a virus. The next time you can't get to a website because the server's down.

Go read the RISKS forum. Then tell me that current software methodologies work.

• 2001-08-11 13:18:46 Warhol Worm proposed: 15 minutes to total infection! (articles,bug) (rejected)

Here's the scoop (more meat at K5):

According to an article in the latest issue of the RISKS digest, Nicholas Weaver of UC Berkeley has written a description of a new type of worm, the Warhol Worm. He believes that using a divide-and-conquer method, all vulnerable machines over the entire IPv4 addressspace could be compromised in only 15 minutes!

`In the future, everybody will have 15 minutes of fame' -Andy Warhol

• 2001-08-11 13:18:46 Warhol Worm proposed: 15 minutes to total infection! (articles,bug) (rejected)

Here's the scoop (more meat at K5):

According to an article in the latest issue of the RISKS digest, Nicholas Weaver of UC Berkeley has written a description of a new type of worm, the Warhol Worm. He believes that using a divide-and-conquer method, all vulnerable machines over the entire IPv4 addressspace could be compromised in only 15 minutes!

`In the future, everybody will have 15 minutes of fame' -Andy Warhol

About ten years ago there was a postscript virus that Did Things to printers

There's some info about it here. Was apparantly quite nasty on some hardware, as it changed a password that required an EPROM replacement to correct. This might have been more a "trojan" than a "virus", as I didn't find any references to it spreading itself (just that it could be a payload in clipart or other EPS files).

http://catless.ncl.ac.uk/Risks/10.32.html#subj1
ftp://ftp.minolta-qms.com/pub/cts/out_going/dos/po stv.txt
http://www.sevenlocks.com/password/pspass.txt

I thought that there was also something a few years ago where viewing a postscript file could alter files on your local machine (buffer overflow in a particular viewer program, unsafe default security settings, or something). However I couldn't find any information, so I might be mis-remembering.

According to a Recent Risks Digest it's pretty damn easy to break even a 2048 bit WEP key.

Risks13-19.3
Risks13-32.1
Risks13-37.2
Risks13-46.4

Risks13-19.3
Risks13-32.1
Risks13-37.2
Risks13-46.4

Risks13-19.3
Risks13-32.1
Risks13-37.2
Risks13-46.4

Risks13-19.3
Risks13-32.1
Risks13-37.2
Risks13-46.4

Reference here with the priceless quote, "There was only one person programming the code for this system and he largely did all the testing". A chilling excerpt from the URL:

"A month later at the same hospital, with the same technician another fatal dosage was given. The technician made the same error of quickly changing the mode from X-ray mode to Electron mode using the 'cursor up' key. This again caused "Malfunction 54". The patient this time was receiving treatment on his face. When the overdose was administered he yelled and then began to moan. The audio equipment was working this time but the initial dose was too much for the man. He received severe neurological damage, fell into a coma and died only 3 weeks later.

Another reference here.

It'll save time when propagating worms, too -- you just have to receive the worm once on your work email account and it can forward itself using your work identity, your home identity, any of the pseudonymous identities you use to post on the not-quite-mainstream newsgroups and discussion forums, etc. It can even mix and match the contact lists for an amusing effect!

Seriously, who would bet Windows will not leak information between your identities? Microsoft's C compilers insert arbitrary chunks of your disk into compiled binaries!

This is an Urban Legend.

The usual good source of thoughful and insightful comments, is RISKS / comp.risks, and in particular Vol 21 Issue 14.

The usual good source of thoughful and insightful comments, is RISKS / comp.risks, and in particular Vol 21 Issue 14.

I discovered the RISKS digest when reading the about software engineering, and it has certainly helped me think about failures and recovery when designing and building systems.

There is also the underlying thesis in the article about how complexity, whether in a bungled redundant network connection or just a large poorly documented, poorly tested, and poor configured system is your enemy in building reliable systems. A lot of systems were built like Slashdot during the dot.com IPO craze, I wonder how many of us rely on such poorly built systems?

Building complex, reliable networks is hard, and expensive. About 3 times what your estimate is, which is about 2 times what you boss expects to spend.

Of course not - everyone should remember when he rwall'ed the entire ARPAnet and in doing so single-handedly forced the invention of the firewall...

There might be a legitimate reason for keeping SETI@Home (or any random application) off of a major organization's computers. Go look at this issue of Risks digest. The problem described here is not a security issue, but a feature of the SETI software that can cause a few copies of it to wedge a net connection if it can't reliably get to its server.

I found some more info here. Apparently it was 620,000$ CDN that he won. They been the odds of "1 in 6 billion" 3 times in a row. Here are some excerpts

- Corriveau used an "antique 286" computer to analyse 7,000 combinations from the keno game, [which uses an electronic pseudo-random number generator].
- The Casino managers shut the game down and called the police.
- The Surete du Quebec [provincial police] fraud squad investigated; Corriveau and his family even took polygraph tests.
Might want to look on yahoo or somewhere to find the details of the actual judgement. Though I am pretty sure he was let off completely.

... and start saying "What Microsoft is trying to do is cool, but what we can do is *better*."

You are missing the point. micro~1.oft has realised they can't compete with OSS on a technical playing field, because the OSS community will eventually win. So M$ is changing the playing field while they still have a monopoly.

The new playing field is using the law (copyrights and patents) to give them exclusive control over who gets to play with their authentication schema. The open source community can come up with a working alternative, but in doing so will become a criminal group, breaking copyright laws and violating patents. M$, and many of the leading IT/computer/software/networking/services companies have realised that playing in a free and open commodity market spreads the profits too thin. So there has been a major push for the last 5-8 years to craft laws to support the new playing field, where free and open competitors are outlawed.

You've no doubt heard of the american UCITA laws, passed in some states, proposed in all the rest. There are initiatives here in Europe to provide the same protections to large companies, but the progress is slower due to socialist leaning countries. Years ago companies who saw the service model and copyright as a potential new area to limit free and open competition created the WIPO, and neatly folded it under the protection of the UN. /. readers regularly complain about these restrictive laws, but are mostly powerless to do anything about them. Money buys votes, so most western democracies are for sale, which is why large crowds protest in Davos and Seattle and any place else. The protests are getting so costly, the world banque is meeting in cyberspace to avoid physical risks.

a protocol (http) which was just plain better ... the OSS community was already there.

For the next 5 to 10 years, M$ and a handful of other companies are going to completely dominate all the greatness the OSS community created. The GPL isn't going to stop them, free and open isn't going to stop them either. Many smart people getting paid large salaries have looked at many ways to continue to earn money when there is a free product running your industry. They know, now, how to defeat the advantages of OSS and free and open. That is what the article is about. The best hope for the Next Great Thing lies where it has always lain, in academia and government assisted research. That is why M$ bought MIT and dozens of other universities in the US and Europe, and why they just bought the UK government.

The OSS community creates free software. I agree with RMS, software should be free. But the big and steady money is in services, always has been, always will be(until the trek universe occurs) There are no free alternatives to services. Maybe there should be an Open Services Alliance :-) I'd love to get 24/7/365 support services for free, but then I'd be out of a job. :-(

the AC

• Biryukov and Shamir cryptanalysis of A5/1 GSM privacy algorithm
• Discussion on cracking A5/1
• Cryptome's copy of the A5 algorithm (PS format)

Try Risks Digest Volume 21:Issue 32

I tried to get my (computer illiterate) sister a couple of gadgets to to word processing and email on, but it was cheaper to buy a low end PC. And even factoring in the support costs ("all my text has gone green") it's cheaper and easier to have the PC sitting there. For $20 they even bought a "fax machine" (software) that uses no power or space (that wasn't already used). Can't beat that in dedicated hardware.

For true joy, read risks digest about the guy who couldn't connect his PDA to anything, then one day... oopsie, no more data. Imagine that when you own a network appliance, a smart phone, a pda, a smartass fridge-freezer that talks to the microwave but not the toaster oven, yadda yadda, then one day you sync (of course, they all have to sync together, otherwise what's the point), and get multilateral data destruction. All your data are belong to us!

While I don't think either of them were really overtly trying to mentor me, I owe a lot of credit for what I know and what I can do to a couple of brilliant programmers that I've had the privilege to work with. Both of these fellows are very kind, pleasant people and went out of their way to help me. They also both go out of their way to write correct code, as opposed to, say, just screwing around with it until it sort of works.

I met Haim Zamir at Live Picture (now MGI Software) in 1997 where I really began my C++ effort in a serious way (I tried it in 1990 to write test tools at Apple but didn't really enjoy the experience). Have a look at Haim's Resume, particularly under "Skills" where he lists:

Well grounded in disciplines of software engineering for correctness, robustness, performance, and longevity

Another brilliant programmer is my friend Andrew Green. Andy spares no amount of effort to get his code just right - he devoted nine years to developing the ZooLib cross-platform application framework before releasing under the MIT License. (Not five years as I say on the page.)

If you think being correct, as opposed to merely working ok isn't important, imagine trying to get platform-independent reference counted smart pointers to work in a multithreaded application framework. Andy did.

For an archive of anecdotes of interesting, funny and sometimes tragic technology quality problems, please read:

• The Forum on Risks to the Public in Computers and Related Systems, with such anecdotes as:
  • The Sinking of the USS Gitarro (because of either poor training, poor UI, or both)
  • The scary MSWord residue feature - exchange Word documents during legal negotiations?
  • Also see the book Computer Related Risks by Risks moderator Peter Neumann

If you write software, another good investment (more important than your hardware investment), is buying and reading good books. As a software consultant I keep the canceled checks and receipts for my technical book purchases; in 1999 I deducted about $750 worth of technical books from my taxes and about $250 in 1998.

But there are a lot of bad software books out there; much as there was a gold rush due to the Internet, there was a smaller-scale gold rush for technical book authors over the last couple years. A really good source of straight-talking book reviews by people who have good reason to know what they're talking about is maintainted by the Association of C and C++ Users at:

• The ACCU Book Reviews Section

(Note to CowboyNeal - writing C-sharp with the pound sign set off the lameness filter, driving me damn near out of my skull. How about adding something to the preview to let us know which characters are lame, exactly?).

And good news for those of you across the pond (but bad news for me), it's a British organization and holds regular technical conferences. I believe they also send observers to the ISO standards bodies.

If you program in C++ you should read these two books by Scott Meyers and put them to practice in your code. Read each item one at a time and then go through your code from beginning to end to see how you can apply it:

• Effective C++ - ACCU Review - be sure to get the 2nd Edition
• More Effective C++ - ACCU Review

-Weffc++ (C++ only)

Warn about violations of various style guidelines from Scott Meyers' Effective C++ books. If you use this option, you should be aware that the standard library headers do not obey all of these guidelines; you can use `grep -v' to filter out those warnings.

C++ is not the problem language it's often said to be if you follow Meyers' advice, but if you prefer C you certainly can have problems there too - and note that the preferred language for Gnome is C (while KDE is an extended C++), for C programmers you should read:

• C Traps and Pitfalls - ACCU Review

• The Elements of Programming Style

Back to the topic of compiler warnings, remember reading about lint in Kernighan and Ritchey's The C Programming Language? When I started out in my first real programming job, doing Sun system administration and writing image processing software back in the late '80's, I learned to write "lint" targets in my Makefiles, and I'd type "make lint" after editing but before compiling to actual machine code. This made my code much easier to debug and quicker to develop.

Much of lint's function is now available in the warnings of GCC (but I don't think all of it), but there are some proprietary products that will do extremely rigorous statis analysis of your source code. I haven't yet used either (although I plan to) but the two I know about are:

• PC-Lint and FlexeLint
• CodeWizard - Linux Journal Review

• Insure

You can search by patent number here.

And speaking of web programming, many Slashdot readers write web applications (Linux being a "server OS" as they say). How many of you validate the HTML that's generated by the web applications you write?

Your HTML should work well in any browser and it should be well designed for easy usability. I don't mean attractive graphics. I mean it shouldn't suck. Two links on design:

• Useit
• Ask Tog

• By uploading static files from your browser - most convenient during hand composition
• By entering its URL in a form - best for dynamic pages and final tuning of static pages

Mike

While I don't think either of them were really overtly trying to mentor me, I owe a lot of credit for what I know and what I can do to a couple of brilliant programmers that I've had the privilege to work with. Both of these fellows are very kind, pleasant people and went out of their way to help me. They also both go out of their way to write correct code, as opposed to, say, just screwing around with it until it sort of works.

I met Haim Zamir at Live Picture (now MGI Software) in 1997 where I really began my C++ effort in a serious way (I tried it in 1990 to write test tools at Apple but didn't really enjoy the experience). Have a look at Haim's Resume, particularly under "Skills" where he lists:

Well grounded in disciplines of software engineering for correctness, robustness, performance, and longevity

Another brilliant programmer is my friend Andrew Green. Andy spares no amount of effort to get his code just right - he devoted nine years to developing the ZooLib cross-platform application framework before releasing under the MIT License. (Not five years as I say on the page.)

If you think being correct, as opposed to merely working ok isn't important, imagine trying to get platform-independent reference counted smart pointers to work in a multithreaded application framework. Andy did.

For an archive of anecdotes of interesting, funny and sometimes tragic technology quality problems, please read:

• The Forum on Risks to the Public in Computers and Related Systems, with such anecdotes as:
  • The Sinking of the USS Gitarro (because of either poor training, poor UI, or both)
  • The scary MSWord residue feature - exchange Word documents during legal negotiations?
  • Also see the book Computer Related Risks by Risks moderator Peter Neumann

If you write software, another good investment (more important than your hardware investment), is buying and reading good books. As a software consultant I keep the canceled checks and receipts for my technical book purchases; in 1999 I deducted about $750 worth of technical books from my taxes and about $250 in 1998.

But there are a lot of bad software books out there; much as there was a gold rush due to the Internet, there was a smaller-scale gold rush for technical book authors over the last couple years. A really good source of straight-talking book reviews by people who have good reason to know what they're talking about is maintainted by the Association of C and C++ Users at:

• The ACCU Book Reviews Section

(Note to CowboyNeal - writing C-sharp with the pound sign set off the lameness filter, driving me damn near out of my skull. How about adding something to the preview to let us know which characters are lame, exactly?).

And good news for those of you across the pond (but bad news for me), it's a British organization and holds regular technical conferences. I believe they also send observers to the ISO standards bodies.

If you program in C++ you should read these two books by Scott Meyers and put them to practice in your code. Read each item one at a time and then go through your code from beginning to end to see how you can apply it:

• Effective C++ - ACCU Review - be sure to get the 2nd Edition
• More Effective C++ - ACCU Review

-Weffc++ (C++ only)

Warn about violations of various style guidelines from Scott Meyers' Effective C++ books. If you use this option, you should be aware that the standard library headers do not obey all of these guidelines; you can use `grep -v' to filter out those warnings.

C++ is not the problem language it's often said to be if you follow Meyers' advice, but if you prefer C you certainly can have problems there too - and note that the preferred language for Gnome is C (while KDE is an extended C++), for C programmers you should read:

• C Traps and Pitfalls - ACCU Review

• The Elements of Programming Style

Back to the topic of compiler warnings, remember reading about lint in Kernighan and Ritchey's The C Programming Language? When I started out in my first real programming job, doing Sun system administration and writing image processing software back in the late '80's, I learned to write "lint" targets in my Makefiles, and I'd type "make lint" after editing but before compiling to actual machine code. This made my code much easier to debug and quicker to develop.

Much of lint's function is now available in the warnings of GCC (but I don't think all of it), but there are some proprietary products that will do extremely rigorous statis analysis of your source code. I haven't yet used either (although I plan to) but the two I know about are:

• PC-Lint and FlexeLint
• CodeWizard - Linux Journal Review

• Insure

You can search by patent number here.

And speaking of web programming, many Slashdot readers write web applications (Linux being a "server OS" as they say). How many of you validate the HTML that's generated by the web applications you write?

Your HTML should work well in any browser and it should be well designed for easy usability. I don't mean attractive graphics. I mean it shouldn't suck. Two links on design:

• Useit
• Ask Tog

• By uploading static files from your browser - most convenient during hand composition
• By entering its URL in a form - best for dynamic pages and final tuning of static pages

Mike

While I don't think either of them were really overtly trying to mentor me, I owe a lot of credit for what I know and what I can do to a couple of brilliant programmers that I've had the privilege to work with. Both of these fellows are very kind, pleasant people and went out of their way to help me. They also both go out of their way to write correct code, as opposed to, say, just screwing around with it until it sort of works.

I met Haim Zamir at Live Picture (now MGI Software) in 1997 where I really began my C++ effort in a serious way (I tried it in 1990 to write test tools at Apple but didn't really enjoy the experience). Have a look at Haim's Resume, particularly under "Skills" where he lists:

Well grounded in disciplines of software engineering for correctness, robustness, performance, and longevity

Another brilliant programmer is my friend Andrew Green. Andy spares no amount of effort to get his code just right - he devoted nine years to developing the ZooLib cross-platform application framework before releasing under the MIT License. (Not five years as I say on the page.)

If you think being correct, as opposed to merely working ok isn't important, imagine trying to get platform-independent reference counted smart pointers to work in a multithreaded application framework. Andy did.

For an archive of anecdotes of interesting, funny and sometimes tragic technology quality problems, please read:

• The Forum on Risks to the Public in Computers and Related Systems, with such anecdotes as:
  • The Sinking of the USS Gitarro (because of either poor training, poor UI, or both)
  • The scary MSWord residue feature - exchange Word documents during legal negotiations?
  • Also see the book Computer Related Risks by Risks moderator Peter Neumann

If you write software, another good investment (more important than your hardware investment), is buying and reading good books. As a software consultant I keep the canceled checks and receipts for my technical book purchases; in 1999 I deducted about $750 worth of technical books from my taxes and about $250 in 1998.

But there are a lot of bad software books out there; much as there was a gold rush due to the Internet, there was a smaller-scale gold rush for technical book authors over the last couple years. A really good source of straight-talking book reviews by people who have good reason to know what they're talking about is maintainted by the Association of C and C++ Users at:

• The ACCU Book Reviews Section

(Note to CowboyNeal - writing C-sharp with the pound sign set off the lameness filter, driving me damn near out of my skull. How about adding something to the preview to let us know which characters are lame, exactly?).

And good news for those of you across the pond (but bad news for me), it's a British organization and holds regular technical conferences. I believe they also send observers to the ISO standards bodies.

If you program in C++ you should read these two books by Scott Meyers and put them to practice in your code. Read each item one at a time and then go through your code from beginning to end to see how you can apply it:

• Effective C++ - ACCU Review - be sure to get the 2nd Edition
• More Effective C++ - ACCU Review

-Weffc++ (C++ only)

Warn about violations of various style guidelines from Scott Meyers' Effective C++ books. If you use this option, you should be aware that the standard library headers do not obey all of these guidelines; you can use `grep -v' to filter out those warnings.

C++ is not the problem language it's often said to be if you follow Meyers' advice, but if you prefer C you certainly can have problems there too - and note that the preferred language for Gnome is C (while KDE is an extended C++), for C programmers you should read:

• C Traps and Pitfalls - ACCU Review

• The Elements of Programming Style

Back to the topic of compiler warnings, remember reading about lint in Kernighan and Ritchey's The C Programming Language? When I started out in my first real programming job, doing Sun system administration and writing image processing software back in the late '80's, I learned to write "lint" targets in my Makefiles, and I'd type "make lint" after editing but before compiling to actual machine code. This made my code much easier to debug and quicker to develop.

Much of lint's function is now available in the warnings of GCC (but I don't think all of it), but there are some proprietary products that will do extremely rigorous statis analysis of your source code. I haven't yet used either (although I plan to) but the two I know about are:

• PC-Lint and FlexeLint
• CodeWizard - Linux Journal Review

• Insure

You can search by patent number here.

And speaking of web programming, many Slashdot readers write web applications (Linux being a "server OS" as they say). How many of you validate the HTML that's generated by the web applications you write?

Your HTML should work well in any browser and it should be well designed for easy usability. I don't mean attractive graphics. I mean it shouldn't suck. Two links on design:

• Useit
• Ask Tog

• By uploading static files from your browser - most convenient during hand composition
• By entering its URL in a form - best for dynamic pages and final tuning of static pages

Mike

Go to Neumann's page above and search for "Robust" using the "Find in Page" function of your browser.

Neumann is the moderator of The Forum on Risks to the Public in Computers and Related Systems and the author of the book Computer Related Risks, so he should know whereof he speaks.

Please also read Open Source and These United States.

In the previous article, someone suggested the problem of how to compose a letter to congressional representatives to promote open source - perhaps simply printing out that paper and mailing it to them with a brief cover letter explaining how you've found a way the U.S. Government and Military can achieve substantial savings in its software purchases, along with gains in reliability, would be helpful.

Mike

I think it would be appropriate to also link to the responses already generated on Risks:

http://catless.ncl.ac.uk/Risks/21.23.html#subj14

Lots of good comments involving previous such experiments and some of the implementation dangers by folks who generally know what they're talking about.

...that it isn't secure. This is a running theme on comp.risks

Peter G Neumann, the moderator of the RISKS forum, has collected information and recommendations on electronic and Internet elections.
__

I am adamantly opposed to the use of fully electronic systems for use
in anonymous balloting and vote tabulation applications. The reasons
for my opposition are manyfold, and are expressed in my writings as well
as those of other computer security experts (many papers are linked below).
To briefly summarize my opinion (based on a decade of research) on this
matter I state the following:

1. 
   
2. Fully electronic systems do not provide any way that the voter can truly
   verify that the ballot cast corresponds to that being recorded, transmitted,
   or tabulated. Any programmer can write code that displays one thing
   on a screen, records something else, and prints yet another result.
   There is no known way to ensure that this is not happening inside of a
   voting system.
3. Electronic balloting systems without individual print-outs for examination
   by the voters, do not provide an independent audit trail (despite manufacturer
   claims to the contrary). As all systems (especially electronic) are
   prone to error, the ability to also perform a manual hand-count of the
   ballots is essential.
4. No electronic voting system has been certified to even the lowest level
   of the U.S. government or international computer security standards, nor
   has any been required to comply with such. Hence, no electronic voting
   system can be called secure (despite manufacturer claims).
5. There are no required standards for voting displays, so computer ballots
   can be constructed to be as confusing (or more) than the butterfly used
   in Florida, giving advantage to some candidates over others.
6. Electronic balloting and tabulation makes the tasks performed by poll workers,
   challengers, and election officials purely procedural, and removes any
   opportunity to perform bipartisan checks. The election process is
   entrusted to a small group of individuals who program and construct the
   machines.
7. Internet voting provides avenues of system attack to the entire planet.
   If the major software manufacturer in the USA could not protect their own
   company from an Internet attack, one must understand that voting systems
   will be no better (and probably worse) in terms of vulnerability.
8. Off-site Internet voting creates unresolvable problems with authentication,
   leading to possible loss of voter privacy, vote-selling, and coersion.
   These systems should not be used for any government election.

... and also look at the last few volumes of Risks; all the ones since the US election, basically. Much detailed analysis, mostly with the conclusion that it can't be done well.

Also see the Risks Digest. In particular, volume 21, issues 11, 12, 13, 14, 15, and 16. This whole issue has been discussed in a fair amount of depth in those particular issues, and a large number of links to relevant articles (including a PhD thesis, I think -- if it's online) are accessible through those pages.

Also see the Risks Digest. In particular, volume 21, issues 11, 12, 13, 14, 15, and 16. This whole issue has been discussed in a fair amount of depth in those particular issues, and a large number of links to relevant articles (including a PhD thesis, I think -- if it's online) are accessible through those pages.

Also see the Risks Digest. In particular, volume 21, issues 11, 12, 13, 14, 15, and 16. This whole issue has been discussed in a fair amount of depth in those particular issues, and a large number of links to relevant articles (including a PhD thesis, I think -- if it's online) are accessible through those pages.

Also see the Risks Digest. In particular, volume 21, issues 11, 12, 13, 14, 15, and 16. This whole issue has been discussed in a fair amount of depth in those particular issues, and a large number of links to relevant articles (including a PhD thesis, I think -- if it's online) are accessible through those pages.

Also see the Risks Digest. In particular, volume 21, issues 11, 12, 13, 14, 15, and 16. This whole issue has been discussed in a fair amount of depth in those particular issues, and a large number of links to relevant articles (including a PhD thesis, I think -- if it's online) are accessible through those pages.

Also see the Risks Digest. In particular, volume 21, issues 11, 12, 13, 14, 15, and 16. This whole issue has been discussed in a fair amount of depth in those particular issues, and a large number of links to relevant articles (including a PhD thesis, I think -- if it's online) are accessible through those pages.

Also see the Risks Digest. In particular, volume 21, issues 11, 12, 13, 14, 15, and 16. This whole issue has been discussed in a fair amount of depth in those particular issues, and a large number of links to relevant articles (including a PhD thesis, I think -- if it's online) are accessible through those pages.

... it's been around (and used successfully) for over fifteen years?

As Jim Coplien has pointed out, OO (objected oriented programming / design / analysis) is older today than "structured" programming / design / analysis was when OO first burst upon the scene. (The structured movement first got some serious press in the mid to late 1960s; the classic book by Dahl, Dijkstra, and Hoare was published in 1972. OO started no later than Simula-67 and Smalltalk-72, and first gathered mainstream attention in the 1980 - 1982 timeframe. The first OOPSLA conference was in 1986.)

Yes, some snake-oil salesmen overhype OO ... or whatever buzzword they can apply to their product. Surprise.

No, OO is not a panacea. It's not even always the right tool to apply to a particular design or programming problem. (Coplien's recent book, Multi-Paradigm Design for C++ , is a tough but worthwhile read that addresses this issue.)

You may dislike a particular language that supports OO (Smalltalk, C++, Java, even Perl) but find the paradigm worthwhile in some other language.

For comparison, compare with this message in Risks Digest: "The structured programming revolution is a real bad idea that has been significantly holding back progress for years.... Have there been any double blind studies which unambiguously show that the kind of programs that structured programming partisans enjoy are really more maintainable than some other kind of program? I've heard lots of testimonials, but no real evidence." Sound kind of familiar? (Heh.) --PSRC

So, can someone without a flaming streak of extremism or a conflicting interest and with some detailed technical knowledge of the facts please speak up. Is this Risks submission (from a guy from Intel) accurate?

I don't like it when zealots create a big wave and brou-ha-ha over nothing. It wouldn't be the first time.

So, can someone without a flaming streak of extremism or a conflicting interest and with some detailed technical knowledge of the facts please speak up. Is this Risks submission (from a guy from Intel) accurate?

I don't like it when zealots create a big wave and brou-ha-ha over nothing. It wouldn't be the first time.

While it's probably the case that software today is too complex to get all the bugs out, the situation could be vastly better than it currently is. There is a lot of discussion of current software problems and what to do about them in Risks.

It is frequented by many esteemed experts in software architecture, reliability, security as well as just plain folks. The bug anecdotes reported there are often pretty funny but sometimes frightening and sobering too.

I think anyone who works with computers in any substantial way should read Risks.

Michael D. Crawford
GoingWare Inc

The Forum on Risks to the Public in Computers and Related Systems

While certainly all us programmers should be reading it, much of the material is accessible to anyone who knows how to use a computer, and so really should be read by anyone who uses computers for anything of importance or makes policy decisions that involve computers.

While the complexity of todays software systems make it unlikely that we'll ever have truly bug-free software, the situation can be a lot better than it is today. One thing that's needed is for the public to wake up and demand that software companies take responsiblity for their products, and to understand that they're being ripped off.

Someone who's working towards that end is Mark Minasi, the author of the book The Software Conspiracy:

There are no significant bugs in our released software that any significant number of users want fixed... The reason we come up with new versions is not to fix bugs. It's absolutely not. It's the stupidest reason to buy a new version I ever heard... And so, in no sense, is stability a reason to move to a new version. It's never a reason.

-- Bill Gates

In the world I came from pursuits like software development were supposed to be clean and pure things, exercises to stimulate and enrich the mind and advance the cause of reason and promote the betterment of human existence.

Instead the industry which appears to be the main driving force behind the tremendous recent growth of the world economy, especially the US economy, is in my opinion a cancer that is desperately in need of the surgeon's knife.

Michael D. Crawford
GoingWare Inc

The solution chosen was quite a simple one, and I'm amazed that more people have never noticed it. It is thus: The second digit of all area codes is either a zero or a one. Thus, if the second digit dialed in is a zero or a one, the phone switch will wait for 10 digits as opposed to just seven.

Of course, this transition provided its share of fodder for comp.risks. See here and here, for example. A comment here (search for "Re: Upcoming telephone number problems") points out that one advantage of the current scheme is that if you dial a number that doesn't begin with 1, then it's free.[*]

[*] Footnote for non-Americans: residential customers in the US usually don't pay by the minute for local calls, which is why we can afford to spend obscenely long times with our modems running, exchanging email, surfing the Web, posting badly-written rants to Usenet, and otherwise extending American cultural hegemony.

PS: I'm reminded of Bjarne Stroustroup's remark (quoting from memory): "People used to say that the computer would become as easy to use as the telephone. That prediction has come true, because I can no longer use my telephone."
--

The solution chosen was quite a simple one, and I'm amazed that more people have never noticed it. It is thus: The second digit of all area codes is either a zero or a one. Thus, if the second digit dialed in is a zero or a one, the phone switch will wait for 10 digits as opposed to just seven.

Of course, this transition provided its share of fodder for comp.risks. See here and here, for example. A comment here (search for "Re: Upcoming telephone number problems") points out that one advantage of the current scheme is that if you dial a number that doesn't begin with 1, then it's free.[*]

[*] Footnote for non-Americans: residential customers in the US usually don't pay by the minute for local calls, which is why we can afford to spend obscenely long times with our modems running, exchanging email, surfing the Web, posting badly-written rants to Usenet, and otherwise extending American cultural hegemony.

PS: I'm reminded of Bjarne Stroustroup's remark (quoting from memory): "People used to say that the computer would become as easy to use as the telephone. That prediction has come true, because I can no longer use my telephone."
--

Research what laptop will run Linux real well.

Get some cash together and drive to a distant city and buy a laptop right off the store shelves. There won't be a chance for anyone to plant a bug in it.

Wipe the hard drive and install Linux on it. Install the Linux encrypting kernel and keep all your real files on an encrypted volume.

Install Tripwire on the machine - it verifies the integrity of important files to be sure they aren't patched.

Learn how to administrate your machine effectively. Always log in as a non-priveliged user and never become root unless you really need to.

Learn about security and tighten down your machine. If you care about security on your laptop you're not going to be running a webserver but I bet a lot of you are running both Apache and SAMBA on a standalone user machine without even knowing it. The more services that are disabled the less anyone can screw with it, even on a non-networked machine.

Don't ever let the machine leave your sight. If you have to put it away, lock it in a safe. Do something to the safe that will enable you to tell if someone's blackbagged you - something like the trick of wedging a matchstick in your door when you leave, but something more concealed. If you find the matchstick on the ground when you return, someone's opened your door.

Best of all don't use a computer for anything of real importance. You can find out why you shouldn't by reading The Forum on Risks to the Public in Computers and Related Systems for a while.

Michael D. Crawford
GoingWare Inc

If the machine went down or you got disconnected without saving, you could replay the journal file to recover your edits.

The cool thing was that this worked by literally replaying your keystrokes back into the editor, so you got to see your edit session happen over again at high speed.

So I quickly found I could make zippy little ASCII animations by laboriously editing out frame after frame of the pictures in an animation and then turning the terminal off when I was done. Turn the terminal on, log in, and replay the journal! Better than animated GIFs! Kids these days... Much to the chagrin of many people who thought they had kept something a secret, Microsoft Word does this too, with its "Fast Save" - it just saves deltas of each edit, rather than the whole file each time you save. It just does the replay in memory when it opens the file, but it is possible to see the changes, not just with a low-level editor but with Word itself. From The Forum on Risks to the Public in Computers and Related Systems:

The scary MSWord residue feature

I recently received a legal document as part of a personal negotiation that I am doing. The document was e-mailed to me in MSWord format. As I was showing it to my lawyer (who happens to be my wife), we decided to put our thoughts inline using the track changes feature of word. After selecting Tools, and Track Changes, we clicked on "Highlight changes in document" and voila, suddenly a whole bunch of red appeared on the screen. We looked at it closely and realized that everything in red represented changes in the document that my counterpart's lawyer had written. We got a good look at the previous version of the contract, as well as a bunch of comments and justifications that the lawyer wrote to his client. It was an eye opening experience.

It appears that instead of selecting "Accept all changes" before sending it to me, the other party to the contract simply turned off the highlighting to the track changes feature.

This is obviously a case of an unsophisticated person misusing a feature. However, it is very dangerous. Lawyers send word documents around all the time, and many of them do not really understand all the features that they use, nor should they have to. I imagine that I was not the first person to see some behind the scenes conversation in an important word document, that I was never intended to see.

If the machine went down or you got disconnected without saving, you could replay the journal file to recover your edits.

The cool thing was that this worked by literally replaying your keystrokes back into the editor, so you got to see your edit session happen over again at high speed.

So I quickly found I could make zippy little ASCII animations by laboriously editing out frame after frame of the pictures in an animation and then turning the terminal off when I was done. Turn the terminal on, log in, and replay the journal! Better than animated GIFs! Kids these days... Much to the chagrin of many people who thought they had kept something a secret, Microsoft Word does this too, with its "Fast Save" - it just saves deltas of each edit, rather than the whole file each time you save. It just does the replay in memory when it opens the file, but it is possible to see the changes, not just with a low-level editor but with Word itself. From The Forum on Risks to the Public in Computers and Related Systems:

The scary MSWord residue feature

I recently received a legal document as part of a personal negotiation that I am doing. The document was e-mailed to me in MSWord format. As I was showing it to my lawyer (who happens to be my wife), we decided to put our thoughts inline using the track changes feature of word. After selecting Tools, and Track Changes, we clicked on "Highlight changes in document" and voila, suddenly a whole bunch of red appeared on the screen. We looked at it closely and realized that everything in red represented changes in the document that my counterpart's lawyer had written. We got a good look at the previous version of the contract, as well as a bunch of comments and justifications that the lawyer wrote to his client. It was an eye opening experience.

It appears that instead of selecting "Accept all changes" before sending it to me, the other party to the contract simply turned off the highlighting to the track changes feature.

This is obviously a case of an unsophisticated person misusing a feature. However, it is very dangerous. Lawyers send word documents around all the time, and many of them do not really understand all the features that they use, nor should they have to. I imagine that I was not the first person to see some behind the scenes conversation in an important word document, that I was never intended to see.