Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Plea for help: The detriment of using Microsoft products



Jeffry Smith wrote:
	 On Tue, 16 May 2000, Kevin D. Clark wrote:
	 ...
	 > I don't think that a lot of shops out there do a lot of peer-review,
	 > and I believe that this tends to produce lower-quality software.  I'd
	 > bet a million dollars that Boeing's engineers do a lot of peer-review
	 > when designing their airplanes.  Because failure is not an option...
	 Bingo.  Failure is NOT an option, Boeing's a** is on the line.  They
	 CANNOT waive liability.  Unlike the standard SW company.

In my experience, code reviews are very common.  But I've yet to  see
such  reviews catch even a single bug.  The current "standard" in the
commercial software biz is so weak that it only qualifies as a parody
of a true review process.

When it was my code being reviewed, I have never seen  anyone  ask  a
question  that  I  hadn't already asked myself.  Now, you might think
that this just indicates what a competent  programmer  I  am,  and  I
wouldn't  want  to  disabuse  you of that idea.  But I think the real
explanation is indicated by the changes that do come out of  reviews.
I'm  thinking  of  the  hour-long debates over such things as whether
open braces should be on a separate line, or should be at the end  of
the  if/while/for expression.  This is the sort of "software quality"
problem that current reviews are designed to handle.

	 > Now, all of this said, the path of destruction left over by the recent
	 > worm only further confirms my belief that something is seriously wrong
	 > over in Microsoft's software shop.  I can't even believe that the
	 > (mis-)features in Outlook that allowed the worm to work in the first
	 > place ever made it through a design review.  What were they thinking?
	 > 
	 That if something goes wrong, oh well, it's someone else's problem.
	 We've waived all liability.  Tough luck, we'll fix it in the next
	 upgrade.

There's another possibility, and I'm continually disappointed by  not
hearing  anyone  (here  or in the media) mention it:  The behavior of
MS's email software is not an accident at all.

One very real possibility is that the default enabling  of  execution
of  incoming  code  is there because Microsoft (and some of their big
customers) are using it.  There have been several reports from people
who have used line monitors and traffic-analysis programs to discover
what was going over the line, and reported seeing detailed  lists  of
the contents of their hard disk going out to an MS address.

The fact that MS hasn't fixed the problem could very well be  because
they  and  others  are  using  their  scripting capability to collect
information from users' machines and send it to  interested  parties.
If they were doing this, how would you know?  Can it be blocked?  Not
by your typical user.

There is a large and growing market for  this  sort  of  information.
Unless  we  know  otherwise,  we  should  assume that any binary-only
software contains code that will report back to headquarters on where
and  how  it  is being used.  Running incoming scripts, as MS Outlook
does, is one easy way of implementing such features, but it far  from
the only way it can be done.

-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org