Squeak in IEEE Software

Kevin Fisher kfisher at rim.net
Mon Feb 1 16:48:33 UTC 1999


On Mon, 01 Feb 1999, Peter Crowther wrote:
>> 
>I have a different opinion: the problem is not the IS managers [the
>technical ones, anyway], it's the finance departments and non-technical
>managers who see a product that doesn't say 'Microsoft' on the box.
>Nobody
>ever got sacked for buying Microsoft --- it ain't IBM any more.
>

I have to agree heartily there.  Wasn't there an article recently in some
engineering magazine about how engineers and scientists are starting to revolt
against the top-down institution of NT?  I wish I could remember where that
article was...very revealing.  I think first heard about it on slashdot.org..


A good friend of mine who works for a large motor company is going through the
pointy-headed-boss gauntlet right now.  The company higher-ups (suit-and-tied
types) are the ones who get to say what technology gets used in the company
infrastructure....all Microsoft, surprise surprise.  The techie types have said
again and again that the NT based solutions they have are expensive and
difficult to manage...they want to do it all under Linux because it is cheaper
and more reliable. 

However the real surprise is that the higher-ups seem to be having a change
of heart...they are now evaluating Linux, and looking into accepting it in the
company infrastructure.

 >>  >This is good.  If you
can get the same functionality into fewer lines of >code, you will have fewer
defects --- by his own arguments.  If, by >contrast, commercial UNIXes have c.
10M LOC, but only exercise the same >100k >LOC or so as Linux does, the
reliability figures are comparable.  Either >way, I disagree with his
conclusions.

Same here.  Plus, the high LOC count in microsoft software certainly doesn't
mean that they've gotten a handle on things either...our NT servers crash
regularly while our Linux servers click on for months at a time, rarely (if
ever) needing to be rebooted.  Personally I have zero faith that Microsoft will
ever get the bugs out of their software (especially with their habit of late of
denying security holes and bugs...yikes).



>
>Commercial UNIXes are full of bloat that never gets used.  Linux isn't
>(yet).
>

True, but Linux also comes with lots of nice bloat-reducing features like
kernel modules.  Even if the featureset of Linux continues to grow you should
still be able to pare the system down to just what you need, and have a nice
lean and mean kernel...I can't say the same thing about NT (I just think about
the size of NT 5 -er- WIndows 2000 and I shudder...)


>> Lewis believes
that as the programming tasks get more complex, >> only commercial programmers
will be able to put in the time and >effort. >> 
>This is where re-use comes in.  Problem is, you have to know what's out
>there to re-use.  I haven't found a central component store for open
>source
>software in the same way that there are indexed central sources for COM
>components --- maybe I should create one.  Anyone know where I should be
>looking?
>

Hmm, I know this isn't exactly what you mean but you could search at
freshmeat.net.  But freshmeat is more of a 'what's new, what's just been
released' type of site.

There seem to be a LOT of CVS servers out there for all the respective Linux
projects underway.  Maybe a meta-catalogue of all the CVS servers would help
get the ball rolling.  


>> 
>>From memory, but without references, several have looked at
>well-designed
>C++, and a couple have touched Smalltalk.  Again, the advantage of
>Smalltalk
>and the other fine-grain O-O languages is fewer LOC to accomplish the
>same
>end; so, assuming the defect density is (at worst) no higher than with
>conventional code, we get more reliable functionality.
>
>"Lies, damn lies and statistics".  It's amazing what you can do to an
>argument with a bit of thought and some statistical Ju-Jitsu :-).
>
>		- Peter

ohh, too much to think about this early on a monday morning... (what, it's noon
already??)

 >--
>Peter Crowther, MCSE+I, MCSD, MCT, CCI, LLAHN





More information about the Squeak-dev mailing list