Re: Market pressures for more reliable software

Re: Market pressures for more reliable software

[robin]

Lao Xiao Hai <laoxhai@ix.netcom.com> writes: > 
> 
> "Shmuel (Seymour J.) Metz" wrote:
> 
> > ENIAC was before my time, but I'd agree that development was probably
> > centralized in those days. What is in dispute is whether development was
> > centralized in the years or decades immediately preceding the PC. But
> > distributed development occurred even when the computer was centralized, even
> > before the 7090.
> 
> Perhaps.  But, for most organizations, emphasis on the word most, computing
> resources within an organization was under the centralized managment of
> one central authority.  Moreover, most of the computing was located in one
> place.  It is true that some very large corporations had computers distributed
> across their divisions, but that was a luxury not affordable by most of industry.
> 
> This centralization, during the 70's and through the mid-80's even extended to
> collections of companies.   Ever hear of a service bureau.   In service bureaus
> we centralized the computing for vertical markets as well as for such things
> as payroll, general accounting, and other business applications.   There was
> very little distributed development before the advent of, first the minicomputer,
> and later the microcomputer.
> 
> Networks were still a mystery for most people.   Programmers were busy
> grinding out programs in COBOL.   Compilers needed large memory spaces
> and operating systems and these were hosted on million dollar plus machines,
> making it too expensive to distribute them all over the place.

Neither large nor expensive.
One machine we had cost (then) $150,000 and had 402 words of main
memory and 32K bytes of rotating storage.
The smaller IBM 360 machines had 16K bytes to 32K bytes.

>  The exceptions
> were the Fords, Chryslers, and other industrial giants with money to burn.
> 
> I spent a lot of years consulting to, developing software for, and cleaning up
> after these centralized computing facilities.
> 
> Things are a lot more distributed now.   Frankly, as I look at the quality of some
> of the software, I am not sure that can be classified as progress.
> 
> Richard Riehle

Re: Market pressures for more reliable software

[R. Vowels]

"Gary Labowitz" <garyl@enter.net> writes: 
> This is getting ridiculous. You are SO hoping that computing and programming
> were not centralized that you skip an entrie generation.
> When most people talk about early days, they mean when computers actually
> came into the marketplace and were large centralized systems. Certainly
> programmers could be stationed anywhere. But terminal systems (starting with
> the various 1050-type systems) weren't available in the "early days."
> Actually, I remember the introduction of the 1050 as a big deal (about 1963
> or so, maybe a little later). To get programming into the machine it first
> had to be keypunched, and that was almost always "centralized."

We did almost ALL of our own keypunching until 1970 and even then
quite some after that.

> You sent
> your coding sheets to the center to be keypunched. Some of us would go there
> ourselves and do our own keypunching (those that typed).

I finished up buying a keypunch in about 1977 so that I could do some
at home..

> On the Univac-I we
> went to the computer and used the console keypunch.
> Anyway, the later systems developed the RJE-type systems, which
> decentralized the point at which program streams could be entered and
> printed. They still connected to centralized processing, however. Since all
> the terminals were dumb, there was only decentralized job entry and
> printing.
> The real point is: so what? So you said "in the early days we had
> decentralized computing" and were wrong.
> Live with it.
> Let's get on with today's problems.
> Gary
> "Shmuel (Seymour J.) Metz" <nospam@acm.org> wrote in message
> news:3B432AD8.3828FB9@acm.org...
> >
> >
> > Lao Xiao Hai wrote:
> >
> > > I must be missing the point.    What was not centralized?
> >
> > As I said multiple times, programming.
> >
> >
> > > Programming was pretty
> > > much centralized and under the control of a data processing manager.
> Computers
> > > were pretty much centralized, and there weren't that many that could
> drive remote
> > > terminals really well.
> >
> > Well enough. Can you say RAX? QUICKTRAN? CRBE? CRJE? RJE? SGJP? ATS? HASP
> Multileaving? And
> > that's just IBM supplied. There were also ALPHA, ROSCOE (nee WRAP) and
> Wylbur on S/360, and
> > others on non-IBM hardware. There was enough time sharing and remote batch
> to drive a market
> > in plug-compatible terminals and modems.
> >
> > > Most of the data processing was in batch mode.
> >
> > Which doesn't make it centralized.
> >
> >
> > > That is not how I remember it.
> >
> > Clearly. Either your experience was limited or your memory is faulty.
> >
> >
> >
> > > Most of the programs I recall were written by the
> > > programmers
> > > at the service bureau.  Some were packages purchased from elsewhere.
> It was the rare
> > > customer who had programming resources on which they could rely for
> their own software.
> >
> > By the 70s most service bureaus were offering remote access. Ever wonder
> why?
> >
> >
> > > Not that common.
> >
> > Common enough to drive a market in brand X clones of terminals and modems,
> e.g., Cope 45 for
> > remote batch, Vadic modems.
> >
> >
> > > And it was expensive.
> >
> > TI 700s were dirt cheap in the 70s and 80s, as were acoustic couplers.
> >
> >
> > > I have done both.   Certainly a lot of scientific computing was done
> using remote
> > > computers.   However, I recall quite vividly those sites that had their
> own IBM 1130
> > > and did their own Fortran programming.   I spent many late night hours
> writing Fortran II
> > > and debugging on the 1130.
> >
> > And how many of those 1130s cost $150,000? To say nothing of the fact that
> a lot of them were
> > submitting jobs to larger machines.
> >
> >
> > > The IBM 1401 was the workhorse of industry for a long time.
> >
> > And cost nowhere near $150,000.
> >
> >
> > > Oh, and you forgot one of my personal favorites, the CDC
> > > 160 series.
> >
> > I didn't forget it, any more than I forgot LGP or RCA; I omitted it
> because I was
> > concentrating on the IBM marketplace.
> >
> > > The IBM System 360 series came along in 1964 and, along with its
> lots of
> >

Re: Market pressures for more reliable software

[robin]

Roedy Green <roedy@mindprod.com> writes: > On Wed, 27 Jun 2001 09:41:58 GMT, "Gary Labowitz" <garyl@enter.net>
> wrote or quoted :
> 
> >I'm curious what you mean by "relocation" that you were shocked that S/360
> >didn't have it.
> 
> The univac 1100, the IBM 360s predecessor, had a relocation register
> so you could load a ram image and start executing without having to
> make any adjustments.  
> 
> The 360 used absolute addresses.

No. It used relative addressing, and base-relative addressing.
(strictly speaking, it used base-displacement-indexed addressing.)
The assembler allowed "absolute" addresses to be specified,
which had to be filled in by the loader.

Any program can be loaded anywhere in memory.
Programs can be made dynamically relocatable, but only with some effort.

In the days when the 360 first came out, dynamin program relocation
would have been an advantage (programs were relatively small, say, 200K bytes).
These days the disadvantage of dynamic relocation is that the
time taken to relocate a large program 10Mb, 100Mb becomes significant.

> To load you had to adjust all the
> address references to account for where in RAM the program was loaded.

No, only those words that had been specified as containing an absolute
address.

> This greatly slowed down the process of getting a program started.
> 
> Exploiting relocation hardware to speed loading is still not fully
> exploited even in Windows NT.
> --
> Roedy Green, Canadian Mind Products

Re: Market pressures for more reliable software

[Roedy Green]

On Thu, 28 Jun 2001 04:01:02 GMT, robin <robin_v@bigpond.nospam.com>
wrote or quoted :

>> To load you had to adjust all the
>> address references to account for where in RAM the program was loaded.
>
>No, only those words that had been specified as containing an absolute
>address.

you only had a 12 bit displacement, so you needed great many ADCONS
(address constants), to fill your base registers with before you could
get at anything. On load, all these had to be adjusted to account for
where the program was actually loaded in RAM.



For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[Dale King]

Guys, I think this has strayed way off topic for any of these newsgroups. If
you want to continue it I suggest finding a more suitable place and subject
line. Perhaps comp.misc?

--
 Dale King

"Roedy Green" <roedy@mindprod.com> wrote in message
news:s0nljt02faoreuqrftur6k9qpmjsotv6hc@4ax.com...
> On Thu, 28 Jun 2001 04:01:02 GMT, robin <robin_v@bigpond.nospam.com>
> wrote or quoted :
>
> >> To load you had to adjust all the
> >> address references to account for where in RAM the program was loaded.
> >
> >No, only those words that had been specified as containing an absolute
> >address.
>
> you only had a 12 bit displacement, so you needed great many ADCONS
> (address constants), to fill your base registers with before you could
> get at anything. On load, all these had to be adjusted to account for
> where the program was actually loaded in RAM.
>
>
>
> For more detail, please look up the key words mentioned in this post in
> the Java Glossary at: http://mindprod.com/gloss.html
>
> --
> Roedy Green, Canadian Mind Products
> Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

robin wrote:


> No. It used relative addressing, and base-relative addressing.
> (strictly speaking, it used base-displacement-indexed addressing.)
> The assembler allowed "absolute" addresses to be specified,
> which had to be filled in by the loader.

You're confusing two different things. The S/360 used absolute addresses, but they were not present in
instructions. At least, it did until prefixing came along. As to assembler language, it was relocatable addresses
that had to be adjusted by the loader; if the program specified an absolute address, then the loader did not have
to adjust it.

> Any program can be loaded anywhere in memory.
> Programs can be made dynamically relocatable, but only with some effort.

That was the theory in VMS; IBM had to scrap it and replace it with MVS.


> In the days when the 360 first came out, dynamin program relocation
> would have been an advantage (programs were relatively small, say, 200K bytes).
> These days the disadvantage of dynamic relocation is that the
> time taken to relocate a large program 10Mb, 100Mb becomes significant.

No, it's insignificant, because you only need to change the page tables.

--
Shmuel (Seymour J.) Metz

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <2_x_6.6808$e5.26279@newsfeeds.bigpond.com>, on 06/28/2001
   at 04:01 AM, robin <robin_v@bigpond.nospam.com> said:

>No. It used relative addressing, and base-relative addressing.
>(strictly speaking, it used base-displacement-indexed addressing.)
>The assembler allowed "absolute" addresses to be specified, which had
>to be filled in by the loader.

See "Address Generation" on page 13 of the S/369 Principles of
Operation. The displacement is not an address. The address that the
processor generates form the base, displacement and index is an
absolute address except on a 65MP or 360/67.

>The assembler allowed "absolute" addresses to be specified, which
>had to be filled in by the loader.

You're confusing absolute with reolcatable. A relocatable adress had
to be adjusted by the loader; an absolute address did not.

>No, only those words that had been specified as containing an
>absolute address.

See above.


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Pete Thompson]

On Thu, 07 Jun 2001 13:58:13 GMT, Ted Dennison<dennison@telepath.com> wrote:

Lawsuits over bugs?!  Say it ain't so!

In all seriousness, yes you could try to use safeguards, but there are cases
where you simply cannot defend someone from themselves.  How would you put
safeguards on a hammer?  A hammer's already pretty basic.  The only thing I
could think of is to tell someone to use an electric hammer instead, but that's
an entirely different tool to accomplish the same task.  Similarly, if
someone's so worried about pointers and memory, then I'd just tell him to use
Java instead.

But there are times where you just can't anticipate ahead of time what the
programmers may do... who woulda thunk that NASA would allow a simple
imperial/metric mistake to screw up a mission?  :) 





>In article <vj7tht0jkrkoivki4lsadlivgghdr0b6pe@4ax.com>, Pete Thompson says...
>>
>>Well, sure it's subject to abuse.  However, that's the fault of the programmer,
>>not the language itself.  I too froth at the mouth whenever someone makes a
>>stupid use of operator overloading in C++, or write unnecessary compound
>>statements.
>..
>>A hammer's just so damn useful, but I still sometimes hit my thumb.
>
>Real-world tools are actually a damn good analogy here. For example, whenever
>someone takes their fingers off with a table-saw, its the fault of the user.
>However, that doesn't stop table-saw makers from putting guards and other safety
>features on them, does it? Languages, like any other tool, can be designed with
>user safety in mind, or they can be built in a way that practicly invites users
>to maim themselves. Sure, its the user's own stupid fault when they do so. But
>their first mistake was using the unsafely designed tool in the first place.
>
>(I know, I know. Lawsuits are actually an issue here, and they aren't typically
>in the software world. Please lets ignore that issue for a minute. No analogy is
>perfect. )
>
>---
>T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>          home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Larry Kilgallen]

In article <hpgvht8u8j7nr2gtel8f90g9motg7ga7aq@4ax.com>, Pete Thompson <blackpete@nowhere.somewhere.anywhere.com> writes:
> On Thu, 07 Jun 2001 13:58:13 GMT, Ted Dennison<dennison@telepath.com> wrote:
> 
> Lawsuits over bugs?!  Say it ain't so!
> 
> In all seriousness, yes you could try to use safeguards, but there are cases
> where you simply cannot defend someone from themselves.  How would you put
> safeguards on a hammer?

Remember that in the good old US of A manufacturers of aluminum
ladders are obliged to attach labels telling the user not to lean
the aluminum ladder against an overhead power wire.

Re: Long names are doom ?

[Marin David Condic]

Ladders are supposed to be so overly expensive here specifically because of
all the product liability insurance the manufacturers have to carry. What
I'd like to know is how come a woman can spill hot coffee in her lap, sue
McDonalds for making the coffee hot & *win*, yet nobody seems to be able to
sue Bell Labs or Micro$oft for manufacturing operating systems with *known*
unsafe technology. (Comes The Revolution, the lawyers will be the second
ones up against the wall, right after the entire marketing department of
Cirrus Cybernetics Corporation! :-)

As for the hammer? I'd suggest OSHA require they all be wrapped in
styrofoam. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message
news:FzmIx3$T4lbd@eisner.encompasserve.org...
> In article <hpgvht8u8j7nr2gtel8f90g9motg7ga7aq@4ax.com>, Pete Thompson
<blackpete@nowhere.somewhere.anywhere.com> writes:
> > On Thu, 07 Jun 2001 13:58:13 GMT, Ted Dennison<dennison@telepath.com>
wrote:
> >
> > Lawsuits over bugs?!  Say it ain't so!
> >
> > In all seriousness, yes you could try to use safeguards, but there are
cases
> > where you simply cannot defend someone from themselves.  How would you
put
> > safeguards on a hammer?
>
> Remember that in the good old US of A manufacturers of aluminum
> ladders are obliged to attach labels telling the user not to lean
> the aluminum ladder against an overhead power wire.

Re: Long names are doom ?

[Benjamin.Altman]

Cause you don't expect coffee do give you 3rd degree burns, but everyone knows
that the software is unsafe or buggy when they buy it (not excuse, but...)

Marin David Condic wrote:

> Ladders are supposed to be so overly expensive here specifically because of
> all the product liability insurance the manufacturers have to carry. What
> I'd like to know is how come a woman can spill hot coffee in her lap, sue
> McDonalds for making the coffee hot & *win*, yet nobody seems to be able to
> sue Bell Labs or Micro$oft for manufacturing operating systems with *known*
> unsafe technology. (Comes The Revolution, the lawyers will be the second
> ones up against the wall, right after the entire marketing department of
> Cirrus Cybernetics Corporation! :-)
>
> As for the hammer? I'd suggest OSHA require they all be wrapped in
> styrofoam. :-)
>
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> Web:      http://www.mcondic.com/
>
> "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message
> news:FzmIx3$T4lbd@eisner.encompasserve.org...
> > In article <hpgvht8u8j7nr2gtel8f90g9motg7ga7aq@4ax.com>, Pete Thompson
> <blackpete@nowhere.somewhere.anywhere.com> writes:
> > > On Thu, 07 Jun 2001 13:58:13 GMT, Ted Dennison<dennison@telepath.com>
> wrote:
> > >
> > > Lawsuits over bugs?!  Say it ain't so!
> > >
> > > In all seriousness, yes you could try to use safeguards, but there are
> cases
> > > where you simply cannot defend someone from themselves.  How would you
> put
> > > safeguards on a hammer?
> >
> > Remember that in the good old US of A manufacturers of aluminum
> > ladders are obliged to attach labels telling the user not to lean
> > the aluminum ladder against an overhead power wire.

Re: Long names are doom ?

[Marin David Condic]

When I was in kindergarden, the teacher gave us these sage words of advice:
"Hot things burn. Sharp things cut." You *expect* coffee to be hot - that's
the point. If it was cold, you would complain. Through your own
carelessness, a thing expected to be what it is is actually what it is and
it does you harm. That is the fault of McDonalds? OTOH, One *expects*
software to work just like one expects their car to work or their TV to
work. (O.K. We all know better, but why do we stand for it?) When it doesn't
do what it is expected to do, we let the manufacturer off the hook - even
when there are proven methods for making software more reliable and they are
not followed?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Benjamin.Altman" <benjamin.altman@noaa.gov> wrote in message
news:3B1FE1FE.B49AE27F@noaa.gov...
> Cause you don't expect coffee do give you 3rd degree burns, but everyone
knows
> that the software is unsafe or buggy when they buy it (not excuse, but...)
>
> Marin David Condic wrote:
>
> > Ladders are supposed to be so overly expensive here specifically because
of
> > all the product liability insurance the manufacturers have to carry.
What
> > I'd like to know is how come a woman can spill hot coffee in her lap,
sue
> > McDonalds for making the coffee hot & *win*, yet nobody seems to be able
to
> > sue Bell Labs or Micro$oft for manufacturing operating systems with
*known*
> > unsafe technology. (Comes The Revolution, the lawyers will be the second
> > ones up against the wall, right after the entire marketing department of
> > Cirrus Cybernetics Corporation! :-)
> >
> > As for the hammer? I'd suggest OSHA require they all be wrapped in
> > styrofoam. :-)
> >
> > MDC
> > --
> > Marin David Condic
> > Senior Software Engineer
> > Pace Micro Technology Americas    www.pacemicro.com
> > Enabling the digital revolution
> > e-Mail:    marin.condic@pacemicro.com
> > Web:      http://www.mcondic.com/
> >
> > "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message
> > news:FzmIx3$T4lbd@eisner.encompasserve.org...
> > > In article <hpgvht8u8j7nr2gtel8f90g9motg7ga7aq@4ax.com>, Pete Thompson
> > <blackpete@nowhere.somewhere.anywhere.com> writes:
> > > > On Thu, 07 Jun 2001 13:58:13 GMT, Ted
Dennison<dennison@telepath.com>
> > wrote:
> > > >
> > > > Lawsuits over bugs?!  Say it ain't so!
> > > >
> > > > In all seriousness, yes you could try to use safeguards, but there
are
> > cases
> > > > where you simply cannot defend someone from themselves.  How would
you
> > put
> > > > safeguards on a hammer?
> > >
> > > Remember that in the good old US of A manufacturers of aluminum
> > > ladders are obliged to attach labels telling the user not to lean
> > > the aluminum ladder against an overhead power wire.
>

Re: Long names are doom ?

[Dale King]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> wrote in
message news:9fotpi$4k6$1@nh.pace.co.uk...
> When I was in kindergarden, the teacher gave us these sage words of
advice:
> "Hot things burn. Sharp things cut." You *expect* coffee to be hot -
that's
> the point. If it was cold, you would complain. Through your own
> carelessness, a thing expected to be what it is is actually what it is and
> it does you harm. That is the fault of McDonalds? OTOH, One *expects*
> software to work just like one expects their car to work or their TV to
> work. (O.K. We all know better, but why do we stand for it?) When it
doesn't
> do what it is expected to do, we let the manufacturer off the hook - even
> when there are proven methods for making software more reliable and they
are
> not followed?


Unfortunately, a software lawsuit would have little ground to stand on.
Imagine if McDonald's required all customers who order hot coffee to sign an
agreement before they are given the coffee where they acknowledge that the
coffee is hot and can cause burns and that the customer assumes all
responsibility for the proper handling of the coffee. If you got burnt from
the coffee would you be able to win a suit agains McDonald's? Not likely,
since you agreed to accept the responsibility.

Read most software license agreements and you'll find that most are like my
hypothetical coffee agreement. Here is a sample from an IBM license
agreement: "IBM does not warrant uninterrupted or error-free operation of
the Program or that we will correct all Program defects. You are responsible
for the results obtained from the use of the Program." And since "IBM WILL
LICENSE THE PROGRAM TO YOU ONLY IF YOU FIRST ACCEPT THE TERMS OF THIS
AGREEMENT. " then you don't really have a legal leg to stand on. They even
have clauses limiting their liability.
--
 Dale King

Re: Long names are doom ?

[James Kanze]

Dale King wrote:

> Unfortunately, a software lawsuit would have little ground to stand
> on.  Imagine if McDonald's required all customers who order hot
> coffee to sign an agreement before they are given the coffee where
> they acknowledge that the coffee is hot and can cause burns and that
> the customer assumes all responsibility for the proper handling of
> the coffee. If you got burnt from the coffee would you be able to
> win a suit agains McDonald's? Not likely, since you agreed to accept
> the responsibility.

Did you sign such an agreement when you bought your software?

> Read most software license agreements and you'll find that most are
> like my hypothetical coffee agreement. Here is a sample from an IBM
> license agreement: "IBM does not warrant uninterrupted or error-free
> operation of the Program or that we will correct all Program
> defects. You are responsible for the results obtained from the use
> of the Program." And since "IBM WILL LICENSE THE PROGRAM TO YOU ONLY
> IF YOU FIRST ACCEPT THE TERMS OF THIS AGREEMENT. " then you don't
> really have a legal leg to stand on. They even have clauses limiting
> their liability.

Can you read this agreement before purchasing?  If you aren't in
agreement, can you get a refund?

A license agreement is a contract.  It only exists if both parties are
in agreement.  IBM (or MS, or whoever) can say whatever they want, but
they cannot hold you to it unless you actively agree as well.  What
they are doing is about the same as if I added words at the bottom of
my posting, stating that the information within it is licensed, and by
reading the posting, you agree to pay me a consulting fee.

I don't know what the situation is in America, but I'm pretty sure
having read of a case here in Europe where such "licenses" were held
to be non-binding, because they lacked the informed agreement of one
of the parties.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Dan Mercer]

In article <3B25D5FB.15C9B240@dresdner-bank.com>,
James Kanze <James.Kanze@dresdner-bank.com> writes:
> Dale King wrote:
> 
>> Unfortunately, a software lawsuit would have little ground to stand
>> on.  Imagine if McDonald's required all customers who order hot
>> coffee to sign an agreement before they are given the coffee where
>> they acknowledge that the coffee is hot and can cause burns and that
>> the customer assumes all responsibility for the proper handling of
>> the coffee. If you got burnt from the coffee would you be able to
>> win a suit agains McDonald's? Not likely, since you agreed to accept
>> the responsibility.
> 
> Did you sign such an agreement when you bought your software?

The agreement is part of the installation process.  You can't
install the software unless you agree to the license terms.
This constitutes a legal "acceptance".

-- 
Dan Mercer
damercer@mmm.com

> 
>> Read most software license agreements and you'll find that most are
>> like my hypothetical coffee agreement. Here is a sample from an IBM
>> license agreement: "IBM does not warrant uninterrupted or error-free
>> operation of the Program or that we will correct all Program
>> defects. You are responsible for the results obtained from the use
>> of the Program." And since "IBM WILL LICENSE THE PROGRAM TO YOU ONLY
>> IF YOU FIRST ACCEPT THE TERMS OF THIS AGREEMENT. " then you don't
>> really have a legal leg to stand on. They even have clauses limiting
>> their liability.
> 
> Can you read this agreement before purchasing?  If you aren't in
> agreement, can you get a refund?
> 
> A license agreement is a contract.  It only exists if both parties are
> in agreement.  IBM (or MS, or whoever) can say whatever they want, but
> they cannot hold you to it unless you actively agree as well.  What
> they are doing is about the same as if I added words at the bottom of
> my posting, stating that the information within it is licensed, and by
> reading the posting, you agree to pay me a consulting fee.
> 
> I don't know what the situation is in America, but I'm pretty sure
> having read of a case here in Europe where such "licenses" were held
> to be non-binding, because they lacked the informed agreement of one
> of the parties.
> 

Re: Long names are doom ?

[Marin David Condic]

That's the part that gets legally questionable. In normal contract law,
there are many aspects that ride on your ability to inspect the goods for
sale. Do the goods match up with what is contracted? Are the goods
non-conforming? Have you accepted non-conforming goods sent by the seller in
leu of conforming goods? If I can't possibly inspect the software without
first installing it, how can the act of installing it constitute acceptance?
The whole thing is on legally shakey grounds.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Dan Mercer" <damercer@mmm.com> wrote in message
news:9g5as6$hbq$1@magnum.mmm.com...
>
> The agreement is part of the installation process.  You can't
> install the software unless you agree to the license terms.
> This constitutes a legal "acceptance".
>

Re: Long names are doom ?

[Dan Mercer]

In article <9g5ipg$roq$1@nh.pace.co.uk>,
"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
> That's the part that gets legally questionable. In normal contract law,
> there are many aspects that ride on your ability to inspect the goods for
> sale. Do the goods match up with what is contracted? Are the goods
> non-conforming? Have you accepted non-conforming goods sent by the seller in
> leu of conforming goods? If I can't possibly inspect the software without
> first installing it, how can the act of installing it constitute acceptance?
> The whole thing is on legally shakey grounds.

Considering the amount of legal talent applied to the problem,
I very much doubt they're on legally shakey grounds.   We could
debate the issue more,  but I would guess that the legal opinions
of amateurs are as amusing to lawyers as the depictions of
computers in the movies are to us.

-- 
Dan Mercer
damercer@mmm.com


> 
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> Web:      http://www.mcondic.com/
> 
> 
> "Dan Mercer" <damercer@mmm.com> wrote in message
> news:9g5as6$hbq$1@magnum.mmm.com...
>>
>> The agreement is part of the installation process.  You can't
>> install the software unless you agree to the license terms.
>> This constitutes a legal "acceptance".
>>
> 
> 
> 

Re: Long names are doom ?

[Roedy Green]

On 12 Jun 2001 21:21:22 GMT, damercer@mmm.com (Dan Mercer) wrote or
quoted :

>Considering the amount of legal talent applied to the problem,
>I very much doubt they're on legally shakey grounds

The law in the US is just one part of the equation.  If even part of
the world community toughens the laws, you get the California effect.

E.g California creates stiffer emissions laws.  To play in that market
car makers must devise new technology to comply.  Eventually that
spins off to all jurisdictions.  It costs no more to do it right for
the other jurisdictions.

If Canada and Europe start demanding truth in advertising Americans
would immensely benefit.  It costs less to emit the good software to
everyone than maintain a separate buggy version.




For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Marin David Condic]

I don't think that would work. The "California Effect" in all likelyhood is
going to be to drive business out of California. (Notice how California has
steadfastly produced stringent environmental regulations that have basically
made it impossible to build power plants or affordable housing. Now property
values are astronomical and electricity is in short supply. Net effect:
Businesses and individuals start looking for other places to live & work.)
The Law Of Unintended Consequences is what's going to get you here...

If (hypothetically) California were to produce stringent product liability
regulations on software and/or advertising laws, etc. that attempted to make
software manufacturers responsible for defects in quality and workmanship,
you'd likely see some strange effects. For example - a "gray market" - I
don't sell my software in California because of the liability - I sell it on
the Internet from the Caymen Islands. If I *do* sell it in California, the
price tag goes *way* up to cover all the liability lawsuits. Lots of things
would happen, but I don't think one of them would be better software across
the board - at least not any time soon. (and in the long run, I'll be dead!)

Better to rely on market forces for this kind of thing. If someone came out
with an equivalent to Micro$oft Office & made it more reliable & stable,
they'd have some advertising edge. "We - unlike our unnamed competitors whos
initials are "Micro$oft" - stand behind our product with the following
guarantee....." IOW, if it is *possible* to build a better mousetrap then
the answer is to *build* it and start selling it. The world will follow.
(Notice the threat posed to Micro$oft by Linux? Better moustrap? Path beaten
to the door? Markets can work to solve these problems.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Roedy Green" <roedy@mindprod.com> wrote in message
news:enoditglutmp6d4bmlfaddt9qipf0n8cbp@4ax.com...
> On 12 Jun 2001 21:21:22 GMT, damercer@mmm.com (Dan Mercer) wrote or
> quoted :
> The law in the US is just one part of the equation.  If even part of
> the world community toughens the laws, you get the California effect.
>
> E.g California creates stiffer emissions laws.  To play in that market
> car makers must devise new technology to comply.  Eventually that
> spins off to all jurisdictions.  It costs no more to do it right for
> the other jurisdictions.
>
> If Canada and Europe start demanding truth in advertising Americans
> would immensely benefit.  It costs less to emit the good software to
> everyone than maintain a separate buggy version.
>
>
>
>
> For more detail, please look up the key words mentioned in this post in
> the Java Glossary at: http://mindprod.com/gloss.html
>
> --
> Roedy Green, Canadian Mind Products
> Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Ted Dennison]

In article <9g7r02$mni$1@nh.pace.co.uk>, Marin David Condic says...
>Better to rely on market forces for this kind of thing. If someone came out
>with an equivalent to Micro$oft Office & made it more reliable & stable,
>they'd have some advertising edge. "We - unlike our unnamed competitors whos

Its a fallacy that the market cares about quality. Sure users whine about lack
of it, once they get the product. But before that point, they just want the damn
product yesterday (and as cheap as possible), no matter how badly it works.
Mostly its us *developers* who care about quality. After all, who wants to spend
their life whole building shoddy crap? (Its rhetorical; please, don't answer.
:-) )

For a good reference on this subject read "Worse is Better" (
http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html )

It also provides a pretty good explanation of why C is more widely used than
pretty much every language whose group this thread is crossposted to.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Marin David Condic]

That seems to be a misunderstanding of markets. Seems a few years ago, GM,
Ford & Chrysler were having all sorts of hardships over "Quality" because
apparently, once "Quality" was available from another source, people were
staying away from American automakers in droves.

"Quality" means different things to different people at different times.
Sometimes "Quality" is a nice crystal Stubenware wineglass. Sometimes
"Quality" is an inexpensive Dixie cup that will hold water for a brief time
before failing. "Quality" is not synonymous with "never breaks". A
quick-and-dirty program that patches some disk problem for me at zero cost
can "break" in unusual conditions that I never produce & still be "Quality"

If market forces won't favor reliable software, I submit that this needs to
be demonstrated. Find an unreliable product with no competing reliable
product available. Produce a reliable product at a similar price and with
similar features and with a similar marketing budget. (IOW, all other
parameters held constant) Will the public purchase the Reliable product or
the P.O.S.?

I think if we duplicated the functionality of - say - Netscape, only wrote
it in Ada so that it didn't periodically lock up, core dump, etc., & made it
available under similar terms, it would probably become the browser of
choice. (Of course, my current copy of Explorer seems to be working with
more reliability than the version of Netscape I have, so there *is* a better
quality product in the market. Hard to test the theory unless AdaBrowser
(tm) is more reliable than that.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:kbLV6.6795$pb1.259296@www.newsranger.com...
> In article <9g7r02$mni$1@nh.pace.co.uk>, Marin David Condic says...
>
> Its a fallacy that the market cares about quality. Sure users whine about
lack
> of it, once they get the product. But before that point, they just want
the damn
> product yesterday (and as cheap as possible), no matter how badly it
works.
> Mostly its us *developers* who care about quality. After all, who wants to
spend
> their life whole building shoddy crap? (Its rhetorical; please, don't
answer.
> :-) )
>
> For a good reference on this subject read "Worse is Better" (
> http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html )
>
> It also provides a pretty good explanation of why C is more widely used
than
> pretty much every language whose group this thread is crossposted to.
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

Market pressures for more reliable software

[Roedy Green]

On Wed, 13 Jun 2001 12:22:43 -0400, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> wrote or quoted :

> Produce a reliable product at a similar price and with
>similar features and with a similar marketing budget.

The problem with software is you have to use it for at least a few
months to evaluate its quality and suitability FOR YOUR NEEDS. Adobe
may create some extremely good and expensive software, but their
packages could be overwhelming for a newbie.

BUT, by then it is too late. The vendor already has your money,
whether or not he has delivered a suitable, working product.

This problem with buying a pig in a poke greatly favours market
leaders who can afford advertising, and whose products will be
purchased by newcomers simply on name recognition. There is not enough
incentive for a market leader to produce a high quality product.

I see three ways around this:

1. try-before-you-buy which is becoming much more common.  Electronic
distribution lets you try several packages before making your final
decision.  My problem with the technique is software trials are TIME
limited rather than USE-limited.  I sometimes get sidetracked before
completing evaluating a package, then lose the right to examine it.

2. software rental.  You don't give the vendor all the money up front.
You can leave the vendor at any time and PUNISH him for not living up
to your expectations.

3. Consumer Reports so that new software is much less a pig in a poke.
General computer literacy should help along these lines too.  The new
generation coming up are not going to be such lambs lead to the
slaughter.
 

For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[Ted Dennison]

In article <40gfitgrvd8cgu27r3vfib6eptmapb3pfl@4ax.com>, Roedy Green says...
>
>This problem with buying a pig in a poke greatly favours market
>leaders who can afford advertising, and whose products will be
>purchased by newcomers simply on name recognition. There is not enough
>incentive for a market leader to produce a high quality product.
>
>I see three ways around this:
1..2..3..

4. Free Software. If it doesn't quite do what you want, you've lost nothing but
your evaluation time. Even better, you have more options than just trying
something else. You can fix it yourself to do what you want, or pay someone else
(preferably someone intamately familiar with the code) to do it for you.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Market pressures for more reliable software

[Marin David Condic]

Yes, presuming the company that made the product is willing to go this
route. (Free in what sense?) They have to see their future income as coming
from selling support or other stuff if they are going to give away the
program. (Not all software has this potential - do people regularly buy
support for, say, a computer game?)

If they *sell* the program with the source code, you *do* have the option of
fixing it yourself - but there may be real good reasons why they don't fix
the bugs themselves. (If its crap code, it may be real hard or impossible to
fix.) So saying "Yeah, it's a turd, but you're welcome to polish it up for
yourself..." doesn't really get you out of it. They took your money and gave
you crap and had a little salve for their conscience because they gave you
the source.

Now there might be something to the notion of software developed under the
Ada Developer's Cooperative License (or similar) in that the guys who build
the code only get paid if the code gets used and sold. The only way for that
to work consistently is if what they wrote is reliable enough for other
developers to have confidence in it and reuse it. There is incentive to fix
and improve components rather than pitch them all and start from
bottom-dead-center as is often done in C/C++ consumer software development.
Its not like you can sell the code up front and say "Tough Noogies!" if it
turns out it sucks. So presuming someone builds "Ada$oft Works (tm)" in Ada
utilizing subsystems and components under the ADCL, it might increase the
probability that the end-product doesn't suck because a) the developers of
the code have a stake in its quality and b) its written in Ada which
improves the quality right there. Could it help?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:zeQV6.7400$pb1.285004@www.newsranger.com...
> In article <40gfitgrvd8cgu27r3vfib6eptmapb3pfl@4ax.com>, Roedy Green
says...
> 4. Free Software. If it doesn't quite do what you want, you've lost
nothing but
> your evaluation time. Even better, you have more options than just trying
> something else. You can fix it yourself to do what you want, or pay
someone else
> (preferably someone intamately familiar with the code) to do it for you.
>

RE: Market pressures for more reliable software

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Marin David Condic et al.

Thank you for your kind words on the Ada Developer's Cooperative License.
Since you mentioned "or similar", I always have stated that what I wrote was
a draft. I would be gratified if others would enhance it.

I should explain that since a good part of my training is in biology, I
tried to create a system that would benefit from Darwinian selection or in
engineering terms feedback. Evolving a system with good feedback is an
excellent way to optimize. The combination of ASIS and the Ada package
structure offers the possibility of creating a market economy for software.
Or reverting to my biological training, we Ada mammals can destroy the
present software dinosaurs. We can develop a very low overhead distributed,
profitable, equitable software development system.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Marin David Condic
Sent: Wednesday, June 13, 2001 2:27 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: Market pressures for more reliable software


Yes, presuming the company that made the product is willing to go this
route. (Free in what sense?) They have to see their future income as coming
from selling support or other stuff if they are going to give away the
program. (Not all software has this potential - do people regularly buy
support for, say, a computer game?)

If they *sell* the program with the source code, you *do* have the option of
fixing it yourself - but there may be real good reasons why they don't fix
the bugs themselves. (If its crap code, it may be real hard or impossible to
fix.) So saying "Yeah, it's a turd, but you're welcome to polish it up for
yourself..." doesn't really get you out of it. They took your money and gave
you crap and had a little salve for their conscience because they gave you
the source.

Now there might be something to the notion of software developed under the
Ada Developer's Cooperative License (or similar) in that the guys who build
the code only get paid if the code gets used and sold. The only way for that
to work consistently is if what they wrote is reliable enough for other
developers to have confidence in it and reuse it. There is incentive to fix
and improve components rather than pitch them all and start from
bottom-dead-center as is often done in C/C++ consumer software development.
Its not like you can sell the code up front and say "Tough Noogies!" if it
turns out it sucks. So presuming someone builds "Ada$oft Works (tm)" in Ada
utilizing subsystems and components under the ADCL, it might increase the
probability that the end-product doesn't suck because a) the developers of
the code have a stake in its quality and b) its written in Ada which
improves the quality right there. Could it help?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:zeQV6.7400$pb1.285004@www.newsranger.com...
> In article <40gfitgrvd8cgu27r3vfib6eptmapb3pfl@4ax.com>, Roedy Green
says...
> 4. Free Software. If it doesn't quite do what you want, you've lost
nothing but
> your evaluation time. Even better, you have more options than just trying
> something else. You can fix it yourself to do what you want, or pay
someone else
> (preferably someone intamately familiar with the code) to do it for you.
>

Re: Market pressures for more reliable software

[Ted Dennison]

In article <9g8lrk$37c$1@nh.pace.co.uk>, Marin David Condic says...
>
>Yes, presuming the company that made the product is willing to go this
>route. (Free in what sense?) They have to see their future income as coming
>from selling support or other stuff if they are going to give away the
>program. (Not all software has this potential - do people regularly buy
>support for, say, a computer game?)

When I capitalize "Free", its to indicate that I'm talking about FSF-style "Free
Software".

Nearly all software is already developed as custom software under a system where
the deveopers are paid for the development. That includes *every* project I've
ever worked on in my career. Even for most of the "licensed" commercial software
I deal with, the "support" is the most expensive part. So using Free Software
models wouldn't even noticably impact the vast majority of the software
developed.

Of course this skirts around the issue that the small minority of software left
actually gets distributed the most. But there are still ways to make money using
Free Software in that realm. RedHat has shown that. They just won't make nearly
as *much* money as they would if they could somehow charge a toll on each copy.

You bring up games. To answer your question directly, yes people *do* pay for
"support" for games. 900-number "hint lines" for adventure games are not unheard
of. Also, nearly every game company has some kind of customer support (the money
to pay for for that obviously comes from game sales, so you can think of it as
sort of a "support tax"). 

I've played computer games avidly for over 20 years (since back when games were
distributed in compliation books as BASIC source code). So I have thought about
this a lot. For a computer game, what I'd try to sell is the manual. There's
already a racket going where the shipped manuals are useless, and anyone who
wants to know what's really going on buys a "game guide". They might as well
make it official. I also collect the boxes, and on one glorious occasion, got
one autographed by the heads of the development team (Sid Meyer, Brian Reynolds,
et al). So I'm quite confident that people would still pay for an official
"hard" copy (perhaps even more for a hand-autographed one).

>Now there might be something to the notion of software developed under the
>Ada Developer's Cooperative License (or similar) in that the guys who build
>the code only get paid if the code gets used and sold. The only way for that

That might work out OK in a world of mass-produced shrink-wrapped software. But
remember paragraph 1: the vast majority of software *developed* does not fit
that mold. In the world in which I work, I can't use any nifty routine that's
going to add to the system's costs, because *I* don't get to make those kinds of
decisions. The folks that do are my managager's manager, who's already obsessing
about overruns, and the paper-pushers off in accounting, who require all sorts
of paperwork and market research and competitive sourcing and several weeks to
make any kind of decision (You should see us trying to buy a PC video card
before it goes obsolete. Its sad, really). Unless we are talking some pretty
significant functionality, its far easier for me to just rewrite it all myself
(and what a shameful waste of human effort that is!). 

So that license might get some lucky package shipped in lots of software copies.
But for the vast majority of *developers*, its just going to render the package
useless.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Market pressures for more reliable software

[Marin David Condic]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:jK3W6.8329$pb1.316095@www.newsranger.com...
> In article <9g8lrk$37c$1@nh.pace.co.uk>, Marin David Condic says...
> When I capitalize "Free", its to indicate that I'm talking about FSF-style
"Free
> Software".
>
Yeah, but even under FSF, I can *sell* you the program - I just have to give
you the source as well. That was my point.


> Nearly all software is already developed as custom software under a system
where
> the deveopers are paid for the development. That includes *every* project
I've
> ever worked on in my career. Even for most of the "licensed" commercial
software
> I deal with, the "support" is the most expensive part. So using Free
Software
> models wouldn't even noticably impact the vast majority of the software
> developed.
>
Custom software isn't where I'm worried about the quality. You get what you
pay for there. If you want something that runs forever and never crashes,
you pay for the quality steps involved. Where I think there is an issue is
with shrink-wrap products that you just either have to buy or ignore and
accept whatever it is you get.


> You bring up games. To answer your question directly, yes people *do* pay
for
> "support" for games. 900-number "hint lines" for adventure games are not
unheard
> of. Also, nearly every game company has some kind of customer support (the
money
> to pay for for that obviously comes from game sales, so you can think of
it as
> sort of a "support tax").
>
I was simply trying to illustrate that there are a lot of off-the-shelf
products purchased that you install, use and never go back to the company
for anything. Not even upgrades. Maybe there is some percentage of the
population that will want some kind of support, but probably most of the
people who have "Space Invaders" or "Pong" aren't paying for that. How does
the company make money if they don't charge for the software? If things like
that need to have higher reliability, there has to be some kind of market
pressure to do so.


> >Now there might be something to the notion of software developed under
the
> >Ada Developer's Cooperative License (or similar) in that the guys who
build
> >the code only get paid if the code gets used and sold. The only way for
that
>
> That might work out OK in a world of mass-produced shrink-wrapped
software. But
> remember paragraph 1: the vast majority of software *developed* does not
fit
> that mold. In the world in which I work, I can't use any nifty routine
that's
> going to add to the system's costs, because *I* don't get to make those
kinds of
> decisions. The folks that do are my managager's manager, who's already
obsessing
> about overruns, and the paper-pushers off in accounting, who require all
sorts
> of paperwork and market research and competitive sourcing and several
weeks to
> make any kind of decision (You should see us trying to buy a PC video card
> before it goes obsolete. Its sad, really). Unless we are talking some
pretty
> significant functionality, its far easier for me to just rewrite it all
myself
> (and what a shameful waste of human effort that is!).
>
Been there. Done that. I understand. I know it is hard to market
components - especially with restrictive licenses - especially to companies
building a custom product with limited sales potential. It typically has to
be some sort of major subsystem with well defined capabilities (databases?
graphics packages?) before anybody wants to include it in their product. I
don't know what the answer is. Perhaps there needs to be a variety of tiers
to the payment scheme that makes it *easy* for people to get into it, but if
there are any profits made from it, they give *something* to the developers
who contributed code to the project.


> So that license might get some lucky package shipped in lots of software
copies.
> But for the vast majority of *developers*, its just going to render the
package
> useless.
>
Even for the high-volume stuff, it gets problematic. Think about it. If I
sell "Ada$oft Works" to the general public with a worldwide distribution of
tens (hundreds?) of millions of copies, the *cost* is no longer in the
engineering - its in the stamping out of disks & manuals. I'm going to give
some geek in a garage 10% of each sale for having contributed 10% of the
code? Guess again! I'll *eat" the whole engineering cost because it falls
below the noise level. OTOH, if I have a product being custom built for some
govet. contract that maybe gets handed over to the govt for one lump sum,
suddenly getting me 10% of the way to completion in one transaction looks a
little more attractive. Especially if it is reliable, proven software.

There are still problems with the pricing structure that I think would need
to be worked out - just because I bill my customer $1m for 10,000 SLOCs and
you gave me 1,000 SLOCs doesn't mean I can still make a profit after giving
you $100,000. And then throw in all the complexities of accounting (ask
movie stars who sign up for a percentage of the profits how the studios can
make sure a picture *never* amkes a profit!). Its not an easy question.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: Market pressures for more reliable software

[Ted Dennison]

In article <9gaj53$nlp$1@nh.pace.co.uk>, Marin David Condic says...
>
>I was simply trying to illustrate that there are a lot of off-the-shelf
>products purchased that you install, use and never go back to the company
>for anything. Not even upgrades. Maybe there is some percentage of the
>population that will want some kind of support, but probably most of the
>people who have "Space Invaders" or "Pong" aren't paying for that. How does
>the company make money if they don't charge for the software? 

As I said, you don't *have* to stop charging for hard copies just because its
(capital 'F') Free, and there are actually lots of ways that those companies
*already* make money outside of charging for their software. (Starcraft even has
a line of dolls...er..."action figures" out). There are lots more things they
now do for free with the purchase price that folks would probably still pay for.


>... If things like
>that need to have higher reliability, there has to be some kind of market
>pressure to do so.

Ahh...that's the exact issue though. :-)  The way things are set up now, there
can be no market pressure for doing anything outside of pumping that baby out to
as many stores as possible as quickly as possible. If you move away from the
"copy toll" model, then suddenly you have to make your product good enough that
people will want a hard-copy that they can easily reinstall after hard-drive
wipes, etc. Suddenly you have an incentive to provide good hardcopy
documentation. Suddenly you have an incentive to continue to support the product
after initial release.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Market pressures for more reliable software

[Gautier]

Marin David Condic:

> Even for the high-volume stuff, it gets problematic. Think about it. If I
> sell "Ada$oft Works" to the general public with a worldwide distribution of
[...]

BTW, there are at least two "Adasoft"s :
  http://www.adasoft.ch/   (you see their devices in lifts)
  http://www.adasoft.com/

G.

Re: Market pressures for more reliable software

[Marin David Condic]

Thanks for that info. In case anyone there is listening - I picked the name
strictly as a parody of Microsoft. Any relationship is purely coincidental.
:-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Gautier" <gautier_niouzes@hotmail.com> wrote in message
news:17cd177c.0106150721.688aed8d@posting.google.com...
> Marin David Condic:
>
> > Even for the high-volume stuff, it gets problematic. Think about it. If
I
> > sell "Ada$oft Works" to the general public with a worldwide distribution
of
> [...]
>
> BTW, there are at least two "Adasoft"s :
>   http://www.adasoft.ch/   (you see their devices in lifts)
>   http://www.adasoft.com/
>
> G.

Re: Market pressures for more reliable software

[Wes Groleau]

> to be worked out - just because I bill my customer $1m for 10,000 SLOCs and
> you gave me 1,000 SLOCs doesn't mean I can still make a profit after giving

I need new glasses--but I never noticed before how much SLOCS looks like
SUCKS.
(Is Dr. Oliver listening?)


-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Market pressures for more reliable software

[Ed Jensen]

In comp.lang.java.programmer Ted Dennison <dennison@telepath.com> wrote:
: When I capitalize "Free", its to indicate that I'm talking about FSF-style "Free
: Software".

Is anyone else annoyed that the FSF has decided to redefine the term
"free software" for marketing purposes?

I think I'll scoop up some doggie poo, put it in a bowl, and place a
sticker on it that says "Rose Petals".

-Ed, who thinks "Free Software" (GPL-style) is unethical.

Re: Market pressures for more reliable software

[Marin David Condic]

I'll second that notion. For better or worse, people have come to associate
the word "Free" as meaning "No $$$ Charged" when the word is connected to a
product. FSF wants to redefine it more to mean "Unrestricted Usage" - which
is *not* what most people think when they see the word. (Hence all the
confusion over "Free" meaning I can download it and evaluate it and it costs
me nothing but my time - not the case...) They probably should have used the
word "Open" as in "Open Architecture" or "Open Standard" or "Open Source" -
you can see inside and use it in any way you like - you might still have to
*pay* for it, but once you do, there are no unreasonable restrictions on its
use.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ed Jensen" <ejensen+usenet@tiny.net> wrote in message
news:tM4W6.14397$Dd5.3411079@ruti.visi.com...
> In comp.lang.java.programmer Ted Dennison <dennison@telepath.com> wrote:
> : When I capitalize "Free", its to indicate that I'm talking about
FSF-style "Free
> : Software".
>
> Is anyone else annoyed that the FSF has decided to redefine the term
> "free software" for marketing purposes?
>
> I think I'll scoop up some doggie poo, put it in a bowl, and place a
> sticker on it that says "Rose Petals".
>
> -Ed, who thinks "Free Software" (GPL-style) is unethical.

Re: Market pressures for more reliable software

[Ted Dennison]

In article <9ganmu$pj5$1@nh.pace.co.uk>, Marin David Condic says...
>
>I'll second that notion. For better or worse, people have come to associate
>the word "Free" as meaning "No $$$ Charged" when the word is connected to a
..
>me nothing but my time - not the case...) They probably should have used the
>word "Open" as in "Open Architecture" or "Open Standard" or "Open Source" -
>you can see inside and use it in any way you like - you might still have to
>*pay* for it, but once you do, there are no unreasonable restrictions on its
>use.
"Open" doesn't quite reach it, because there's no implication that the right to
redistribute is present, only the right to inspect.

"Liberated" is actually a little closer to what I think they were shooting for.
However, that word implies previous enslavement, which isn't quite right either.
"Free" really has the perfect meaning. The only problem is that is has other
seprate meanings as well. :-(

Anyway, better minds than ours (OK, better than mine at least) have been all
over this nomenclature issue to exhaustion. I doubt we'll be able to fix it
here, short of switching this whole thread to French.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Market pressures for more reliable software

[Charles Hixson]

Ted Dennison wrote:

> In article <9ganmu$pj5$1@nh.pace.co.uk>, Marin David Condic says...
> ...
> Anyway, better minds than ours (OK, better than mine at least) have been all
> over this nomenclature issue to exhaustion. I doubt we'll be able to fix it
> here, short of switching this whole thread to French.
> 
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com
> 

Well, I don't suppose that too many people would misunderstand if you 
said software libre (sorry about the missing accent, but I don't know 
how to type one wo switching to html).  Unfortunatly for the "liberated 
software" suggestion, that also has a couple of overloaded meanings that 
context couldn't disambiguate. (i.e., prior enslavement and theft). 
Liberty software would have the right meaning if it were the right part 
of speech.

My personal choice is, e.g., GPL software.  That's too specific to cover 
the entire field, however, as, e.g., BSD, Artistic, NPL, MPL, ... etc. 
are all parts of the set currently designated by the term "free 
software".  Freedom software?  Again the wrong part of speech.  Open 
Software designates another, larger, group of licenses.  The set "Open 
Software" properly contains the set "Free Software".

It matters not.  By this stage, nobody would be willing to change what 
they were calling things, and if they did, then it would just increase 
the confusion, as you can be sure that not everybody would switch.  But 
there is reason behind the choice of name.  It just wasn't centered on 
money.
-- 
Charles Hixson

Copy software legally, the GNU way!
Use GNU software, and legally make and share copies of software.
See http://www.gnu.org
     http://www.redhat.com
     http://www.linux-mandrake.com
     http://www.calderasystems.com/
     http://www.linuxapps.com/

Re: Market pressures for more reliable software

[Roedy Green]

On Thu, 14 Jun 2001 17:55:40 GMT, Charles Hixson
<charleshixsn@earthlink.net> wrote or quoted :

>Unfortunatly for the "liberated 
>software" suggestion, that also has a couple of overloaded meanings that 
>context couldn't disambiguate

The first meaning that comes to mind from a child of the 70s would be
"stolen".


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[Larry Elmore]

Roedy Green wrote:
> 
> On Thu, 14 Jun 2001 17:55:40 GMT, Charles Hixson
> <charleshixsn@earthlink.net> wrote or quoted :
> 
> >Unfortunatly for the "liberated
> >software" suggestion, that also has a couple of overloaded meanings that
> >context couldn't disambiguate
> 
> The first meaning that comes to mind from a child of the 70s would be
> "stolen".

Not just a "child of the '70s", but anyone who's served in the American
military in  the last half-century or more.

Larry

Re: Market pressures for more reliable software

[Roedy Green]

On Thu, 14 Jun 2001 17:32:21 GMT, Ted Dennison<dennison@telepath.com>
wrote or quoted :

>"Open" doesn't quite reach it, because there's no implication that the right to
>redistribute is present, only the right to inspect.

Let's see what we can come up with for a less ambiguous term for "free
software".

Basically the only right you have is to inspect the software. You may
still be restricted from selling it or modifying it. You may still
have to pay to look.

"white box" software as opposed to "black box" software is my top
choice.

The term has some unwanted NeXT connotations. It also might me
confused to mean generic cheap packaging.

some other possibilities:

"glass box"

"clear box"

"inspectable"

"uncovered"

"unveiled"

"glass coffin"

"source-visible"

"transparent"

"visible"

"disclosed"

"sheer"

"not opaque"

"overt"   

"unconcealed"

"unwrapped"

"icy"

"ice cubed"

"iced"

"porous"

"goldfish bowl"

"naked"

"nude"

"topless"



For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[Ted Dennison]

In article <jj5iitksq0v75aavlrqpouuq9rmmdepdjj@4ax.com>, Roedy Green says...
>
>Basically the only right you have is to inspect the software. You may
>still be restricted from selling it or modifying it. You may still
>have to pay to look.

Not true. That's only one of the 4 freedoms you have, and you may *not* be
restricted from selling or modifying it. "Free Software" is in fact defined by
the 4 rights you have. They are (this is mostly a direct quote):

0) The freedom to run the software for any purpose.
1) The freedom to study how the program works, and adapt it to your needs 
2) The freedom to redistribute copies.
3) The freedom to improve the program, and release your improvements to the
public.

Note this has nothing to say about how you got it in the first place. It also
says nothing about any freedom to combine it with other stuff and distribute
that.

(rights text taken from http://www.fsf.org/philosophy/free-sw.html )

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Market pressures for more reliable software

[Roedy Green]

On Thu, 14 Jun 2001 21:43:25 GMT, Ted Dennison<dennison@telepath.com>
wrote or quoted :

>0) The freedom to run the software for any purpose.
>1) The freedom to study how the program works, and adapt it to your needs 
>2) The freedom to redistribute copies.
>3) The freedom to improve the program, and release your improvements to the
>public.

Do (1) and (2) imply free in the ordinary sense? May I do this without
having to pay a fee to the originator?



For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[Joseph T. Adams]

In comp.lang.java.advocacy Roedy Green <roedy@mindprod.com> wrote:
: On Thu, 14 Jun 2001 21:43:25 GMT, Ted Dennison<dennison@telepath.com>
: wrote or quoted :

:>0) The freedom to run the software for any purpose.
:>1) The freedom to study how the program works, and adapt it to your needs 
:>2) The freedom to redistribute copies.
:>3) The freedom to improve the program, and release your improvements to the
:>public.

: Do (1) and (2) imply free in the ordinary sense?


I consider "freedom" far more important than "price," but both terms
are part of the ordinary meaning of "free" although the context
implies that you are referring to the second meaning ("price").

Nothing in any of these items implies "zero price," but item (3)
places a practical upper limit on how much can be charged, because
once you have the software, you are free to redistribute it with or
without a fee.  So can anyone else.  In practice, this means you can't
sell free software itself, although you can sell packaging, branding,
support, and services in connection with it.


: May I do this without
: having to pay a fee to the originator?

Absolutely yes, because if you didn't, then you would not have freedom
#3.

The person *distributing* the software might ask you for a fee.  He or
she has every right to do so.  Of course you also have the right to
find another distributor who might charge less, or perhaps even
nothing at all.


Joe

Re: Market pressures for more reliable software

[Ted Dennison]

In article <9lhlit0pt6711apais5d9o1n07i7q7u15p@4ax.com>, Roedy Green says...
>
>On Thu, 14 Jun 2001 21:43:25 GMT, Ted Dennison<dennison@telepath.com>
>wrote or quoted :
>
>>0) The freedom to run the software for any purpose.
>>1) The freedom to study how the program works, and adapt it to your needs 
>>2) The freedom to redistribute copies.
>>3) The freedom to improve the program, and release your improvements to the
>>public.
>
>Do (1) and (2) imply free in the ordinary sense? 

I suppose that's ultimately a matter of opinion. But the alternative in the case
of #1 is that there is someone out there who makes it their business what I do
with the software in my own home on my own computer. The alternative in case #2
is that I cannot share certian information with my neighbor without breaking the
law. That sure doesn't make me *feel* free. 

This is of couse just a list of freedoms, so you could argue that it isn't
comprehensive enough to merit the title "free". But then you'd have to come up
with some important freedom that isn't a result of one of the listed freedoms. 

Some like to argue that you aren't *truly* free without the right to make your
own proprietary (non-Free) software out of the "free software". However, some
also like to argue that we in the US aren't truly free people, as we are
prohibited from selling ourselves into slavery. :-)  I believe the operative
principle in our case was that you have to take away some rights to ensure that
the rest will always remain. At least that's what I remember them telling me in
school.

>May I do this without having to pay a fee to the originator?
If you are not allowed to do any of the above without first paying someone a
toll, then no, you are not free to do so.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

RE: Market pressures for more reliable software

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Roedy Green et al.

The term "topless" should be reserved for when the specifications are given
in source and the rest is binary. I might note that this is a familiar and
very useful compromise employed by the Ada community.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Roedy Green
Sent: Thursday, June 14, 2001 1:10 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: Market pressures for more reliable software


On Thu, 14 Jun 2001 17:32:21 GMT, Ted Dennison<dennison@telepath.com>
wrote or quoted :

>"Open" doesn't quite reach it, because there's no implication that the
right to
>redistribute is present, only the right to inspect.

Let's see what we can come up with for a less ambiguous term for "free
software".

Basically the only right you have is to inspect the software. You may
still be restricted from selling it or modifying it. You may still
have to pay to look.

"white box" software as opposed to "black box" software is my top
choice.

The term has some unwanted NeXT connotations. It also might me
confused to mean generic cheap packaging.

some other possibilities:

"glass box"

"clear box"

"inspectable"

"uncovered"

"unveiled"

"glass coffin"

"source-visible"

"transparent"

"visible"

"disclosed"

"sheer"

"not opaque"

"overt"

"unconcealed"

"unwrapped"

"icy"

"ice cubed"

"iced"

"porous"

"goldfish bowl"

"naked"

"nude"

"topless"



For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[Wes Groleau]

> The term "topless" should be reserved for when the specifications are given
> in source and the rest is binary. I might note that this is a familiar and
> very useful compromise employed by the Ada community.

Isn't that more like "bottomless"

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Market pressures for more reliable software

[The Ghost In The Machine]

In comp.lang.java.advocacy, Roedy Green
<roedy@mindprod.com>
 wrote
on Thu, 14 Jun 2001 20:09:41 GMT
<jj5iitksq0v75aavlrqpouuq9rmmdepdjj@4ax.com>:
>On Thu, 14 Jun 2001 17:32:21 GMT, Ted Dennison<dennison@telepath.com>
>wrote or quoted :
>
>>"Open" doesn't quite reach it, because there's no implication that
>>the right to redistribute is present, only the right to inspect.
>
>Let's see what we can come up with for a less ambiguous term for "free
>software".

<voice mode=paranoia>

The FSF license is inherently viral.  While allowing for a number of
operations on the source code, the following requirements must
be met:

[1] The authors of previous modifications must be preserved.  You can of
    course put your name in there for your bug fixes -- in fact, you
    have to.

[2] The source code of the GPL portion must be available on a
    machine-readable medium to anyone who is sold the derived work.
    For example, if one uses the GNU-licensed readln library, one
    must make it available to anyone who uses your product.  (This
    in itself isn't too onerous, but...)

[3] If your work can be shown to be a derived work of the GPLed
    software, then the entire work must be published under the GPL.
    (Hence the term "viral".)  There might be some issues here, of
    course -- is a proprietary, sophisticated CAD program which
    happens to depend on the GNU readline library a "derived work"?
    Or merely a user of the readline library's functionality, which
    happens to solve a particular subproblem?

    Of course, if one takes, say, geda (which is a GNU-licensed
    CAD program), and modifies it by adding a sophisticated but minor
    input method (assuming it hasn't done such already), and releases
    it, then that is most definitely a derived work.  At least, I
    for one would think so...

</voice>

Of course, this may be a feature; one nice thing about GNU-licensed
stuff is that one does have the opportunity to inspect and if
necessary modify it, and then release the modifications back to the
pool.  With so many eyes, bugs can't hide too well, but there
is the issue that, if interest wanes, the software will have problems.
One might call it software evolution in action....

>
>Basically the only right you have is to inspect the software. You may
>still be restricted from selling it or modifying it. You may still
>have to pay to look.

I'm not sure how, unless you're talking about a different license
(e.g., the Sun Community-type deal).  Mozilla's license is also
slightly strange -- part of that might simply be the fact that
Netscape was originally proprietary.

>
>"white box" software as opposed to "black box" software is my top
>choice.
>
>The term has some unwanted NeXT connotations. It also might me
>confused to mean generic cheap packaging.

It's also confusable with a specific testing method, although
I'm not sure if the term is precisely enough defined or not;
"black box" testing can only use public interfaces, but
"white box" can use anything and everything it can lay its
hands on.  A rough analogy would be testing a (populated?) PC board
by only electrically probing the fingers which plug into the motherboard,
versus probing anywhere it makes sense to on the board itself.

I can't say anything about NeXT, although I've been exposed to it;
it looked neat at the time, :-) although quite underpowered by
today's standards.  (Then again, that's a hardware issue; NeXT
could probably run on today's computers without problem, especially
since there is (was?) an x86 version floating around.)

>
>some other possibilities:
>

[rest snipped]

If one wants to be ultra-pedantic about it, how about
"[license-name]-licensed software"?  E.g., readline is
GPL-licensed software.

It's not free, although it's designed to be very easy to work with.
(A lot more so than, say, Microsoft Word's EULA.  It's not even
legal to disassemble the darned thing, and one wonders whether
one can even disassemble its output -- a Word-formatted file.)

-- 
ewill@aimnet.com -- insert random misquote here
EAC code #191       25d:20h:07m actually running Linux.
                    Most likely, no neutrinos were found during this message.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <slrn9mufsb.r0j.ewill@lexideb.athghost7038suus.net>, on 08/07/2001
   at 01:08 AM, ewill@lexideb.athghost7038suus.net (The Ghost In The
Machine) said:

>The FSF license is inherently viral. 

True. But so is micro$soft's license, in a much more onerous fashion.

>[2] The source code of the GPL portion must be available on a
>    machine-readable medium to anyone who is sold the derived work.

AFAIK you only need to distribute the source for the object code you
distribute. I'm not sure what you mean by GPL portion, since you must
license the modified version under the GPL if you distribute it.

>[3] If your work can be shown to be a derived work of the GPLed
>    software, then the entire work must be published under the GPL.

Note that the existence of the LGPL makes this less stringent than it
sounds.

-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[The Ghost In The Machine]

Followups restricted to the newsgroup I actually read. :-)

In comp.lang.java.advocacy, Shmuel (Seymour J.) Metz
<spamtrap@library.lspace.org.invalid>
 wrote
on Mon, 06 Aug 2001 22:38:56 -0400
<3b6f54c1$1$fuzhry$mr2ice@va.news.verio.net>:
>In <slrn9mufsb.r0j.ewill@lexideb.athghost7038suus.net>, on 08/07/2001
>   at 01:08 AM, ewill@lexideb.athghost7038suus.net (The Ghost In The
>Machine) said:
>
>>The FSF license is inherently viral. 
>
>True. But so is micro$soft's license, in a much more onerous fashion.

Agreed in part.  :-)  And at least the FSF GPL license says so.
Microsoft is insidious.

>
>>[2] The source code of the GPL portion must be available on a
>>    machine-readable medium to anyone who is sold the derived work.
>
>AFAIK you only need to distribute the source for the object code you
>distribute. I'm not sure what you mean by GPL portion, since you must
>license the modified version under the GPL if you distribute it.

The GPL portion is the portion licensed under the GPL, as opposed to
the portion of the proprietary package happening to use it.

>
>>[3] If your work can be shown to be a derived work of the GPLed
>>    software, then the entire work must be published under the GPL.
>
>Note that the existence of the LGPL makes this less stringent than it
>sounds.

Only if the library actually uses it.  :-)

[.sigsnip]

-- 
ewill@aimnet.com -- insert random misquote here
EAC code #191       32d:06h:43m actually running Linux.
                    [ ] Check here to always trust monopolistic software.

Re: Market pressures for more reliable software

[Joseph T. Adams]

In comp.lang.java.advocacy Ted Dennison <dennison@telepath.com> wrote:
: In article <9ganmu$pj5$1@nh.pace.co.uk>, Marin David Condic says...
:>
:>I'll second that notion. For better or worse, people have come to associate
:>the word "Free" as meaning "No $$$ Charged" when the word is connected to a
: ..
:>me nothing but my time - not the case...) They probably should have used the
:>word "Open" as in "Open Architecture" or "Open Standard" or "Open Source" -
:>you can see inside and use it in any way you like - you might still have to
:>*pay* for it, but once you do, there are no unreasonable restrictions on its
:>use.
: "Open" doesn't quite reach it, because there's no implication that the right to
: redistribute is present, only the right to inspect.

: "Liberated" is actually a little closer to what I think they were shooting for.
: However, that word implies previous enslavement, which isn't quite right either.


Free software by definition respects the freedom of users. 
Proprietary software by definition asks users to give up many of their
rights in exchange for using it, and most commonly, one of the rights
it asks them to give up is the right to see the source code and
therefore to know exactly what they are getting.

This differs from feudalism, and therefore slavery, only in degree,
not in kind.


Joe

Re: Market pressures for more reliable software

[Ed Jensen]

In comp.lang.java.programmer Ted Dennison <dennison@telepath.com> wrote:
: "Open" doesn't quite reach it, because there's no implication that the right to
: redistribute is present, only the right to inspect.

: "Liberated" is actually a little closer to what I think they were shooting for.
: However, that word implies previous enslavement, which isn't quite right either.
: "Free" really has the perfect meaning. The only problem is that is has other
: seprate meanings as well. :-(

: Anyway, better minds than ours (OK, better than mine at least) have been all
: over this nomenclature issue to exhaustion. I doubt we'll be able to fix it
: here, short of switching this whole thread to French.

The BSD license seems much closer to "free" than the
many-strings-attached GPL.

Of course, the true goal of the FSF, and their chosen tool, the GPL, is
not software freedom.  It is the destruction of commercial software,
which they find unethical.

The BSD license already offers software freedom.  The GPL is merely an
attempt to enforce their manifesto through brilliant viral-like
propagation.

-Ed

Re: Market pressures for more reliable software

[Roedy Green]

On Fri, 15 Jun 2001 15:43:52 GMT, Ed Jensen <ejensen+usenet@tiny.net>
wrote or quoted :

>The GPL is merely an
>attempt to enforce their manifesto through brilliant viral-like
>propagation.

See the Zen story of the box facing east.

A Zen master presented his student with a valuable box, with the
stipulation that it must always face east.  The student took the box
and placed it in his room.  However to place the box east, he had to
place the table against the wall on the opposite side of the room.
This meant he had to move the bed. This made getting in and out of the
room awkward, so he had to move the doorway in the wall.  This caused
a structural weakness in the house which required ....


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[Roedy Green]

On Fri, 15 Jun 2001 15:43:52 GMT, Ed Jensen <ejensen+usenet@tiny.net>
wrote or quoted :

>The GPL is merely an
>attempt to enforce their manifesto through brilliant viral-like
>propagation.

My own equivalent is the "for non military use only" clause applied to
all the source I write.


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[James A. Robertson]

Roedy Green wrote:
> 
> On Fri, 15 Jun 2001 15:43:52 GMT, Ed Jensen <ejensen+usenet@tiny.net>
> wrote or quoted :
> 
> >The GPL is merely an
> >attempt to enforce their manifesto through brilliant viral-like
> >propagation.
> 
> My own equivalent is the "for non military use only" clause applied to
> all the source I write.

Why?  

> 
> For more detail, please look up the key words mentioned in this post in
> the Java Glossary at: http://mindprod.com/gloss.html
> 
> --
> Roedy Green, Canadian Mind Products
> Custom computer programming since 1963. Ready to take on new work.

-- 
James A. Robertson
Product Manager (Smalltalk), Cincom
jarober@mail.com
<Talk Small and Carry a Big Class Library>

Re: Market pressures for more reliable software

[Roedy Green]

On Sat, 16 Jun 2001 14:25:17 GMT, "James A. Robertson"
<jarober@mail.com> wrote or quoted :

>> 
>> My own equivalent is the "for non military use only" clause applied to
>> all the source I write.
>
>Why?  

see http;//mindprod.com/roedy.html#NONMILITARY

For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[James A. Robertson]

So then, you would have objected to the allies using your code against
the Axis?  You have to accept the simple fact that sometimes, force is
the only alternative against evil.  And the UN isn't a viable option in
most cases either - non of the peace keeping operations they have run
have made things better.  At best, they delay further bloodshed into the
future (Balkans missions) - at worst, they achieve nothing at all or
make things worse (middle east)



The best way to ensure peace is to have the best preparedness for war -
so that no one dares bother you.  Follow that with a simple maxim to
stay out of the affairs of others (which the US frequently does <not>
do), and you don't have many problems.



Roedy Green wrote:
> 
> On Sat, 16 Jun 2001 14:25:17 GMT, "James A. Robertson"
> <jarober@mail.com> wrote or quoted :
> 
> >>
> >> My own equivalent is the "for non military use only" clause applied to
> >> all the source I write.
> >
> >Why?
> 
> see http;//mindprod.com/roedy.html#NONMILITARY
> 
> For more detail, please look up the key words mentioned in this post in
> the Java Glossary at: http://mindprod.com/gloss.html
> 
> --
> Roedy Green, Canadian Mind Products
> Custom computer programming since 1963. Ready to take on new work.

-- 
James A. Robertson
Product Manager (Smalltalk), Cincom
jarober@mail.com
<Talk Small and Carry a Big Class Library>

Re: Market pressures for more reliable software

[Ted Dennison]

In article <f0ilitkr3g1qdrffsqss5h8so9tgg1unt5@4ax.com>, Roedy Green says...
>
>On Fri, 15 Jun 2001 15:43:52 GMT, Ed Jensen <ejensen+usenet@tiny.net>
>wrote or quoted :
>
>>The GPL is merely an
>>attempt to enforce their manifesto through brilliant viral-like
>>propagation.
>
>My own equivalent is the "for non military use only" clause applied to
>all the source I write.

That's actually more restrictive than the GPL in many ways. I can and do use GPL
code on military projects. Mostly the GPL just requires that they get the
source, and don't deny it to anyone they give the software to. Since the
military requires the sources anyway, and refuses to give out the software in
most cases, they are quite compatabile with the GPL. I believe discriminating
aginst users automaticly renders software "non-free" too.

However, I understand where you are comming from. I've done DoD work all my
career, and I can feel good that most of my work (particularly the simulator
stuff) actually saves lives. But there are just some jobs even I can't
rationalize away enough to accept. (The tank simulator for the Chineese govt.
approx. 3 years after the Tianamen massacre being a prime example).

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Market pressures for more reliable software

[Al Christians]

Ted Dennison wrote:
> 
> Since the
> military requires the sources anyway, and refuses to give out the 
> software in most cases, they are quite compatabile with the GPL. 

That's a curious one.  GPL says:

"If ... conditions are imposed on you ... that contradict the conditions
of this License, they do       not excuse you from the conditions of
this License. If you cannot distribute so as to satisfy simultaneously
your obligations under this License and any other pertinent obligations,
then as a consequence you may not distribute the Program at all." 

This would appear to make it impossible, for example for a military
contractor that 'distributes' its products to military customers to
include GPL code in a weapons system that was under security
restrictions, or for one country to license military technology
that included GPL code to another country with any restrictions on 
to whom the weapons could be re-sold.  And is hurling a projectile 
that contains embedded software 'redistribution'?


Al

Re: Market pressures for more reliable software

[Ted Dennison]

In article <3B2E2261.303FE952@easystreet.com>, Al Christians says...
>
>This would appear to make it impossible, for example for a military
>contractor that 'distributes' its products to military customers to
>include GPL code in a weapons system that was under security
>restrictions, or for one country to license military technology

True. The GPL'ed stuff I used was all self-contained development tools
(compilers, editors, etc). So I guess that wasn't much of an issue. Also, it was
all for stuff that would not be redistributed anyway. (One thing I touched on
later in the post...I have not worked on anything considered a munition).

>that included GPL code to another country with any restrictions on 
>to whom the weapons could be re-sold.  And is hurling a projectile 
>that contains embedded software 'redistribution'?

That would be an interesting legal question indeed. On one hand, it would be
funny to see a bombed country sue its bomber for GPL violations (or the right to
examine the bomb's souce code). On the other, it would be interesting to see one
country sue another over reverse-engineering the software on captured miliatary
apparatus, under international copyright law, due to a closed-source software
license. (You've *really* ticked us off now. Call back the troops! Recall the
bombers! Tell everyone to stand down at the ICBM silos! We're sending in the
{shudder} lawyers.)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Market pressures for more reliable software

[Marin David Condic]

If your customer is, say, the Air Force & you sell them a program that has
GPL code in it & give them the source, then I don't think that in the case
where the Air Force were to share the system with the Navy would mean that
the Navy must now get the source as well. After all, the United States of
America is in posession of the source code somewhere and if they decide not
to let the left hand know what the right hand is doing, that's not an issue
for the FSF to go suing over. (Besides, in order to sue the United States,
you first have to get the permission of the United States.) Same as if
Ford-Detroit decides not to send the source to Ford-England. Its an internal
matter for Ford.

Sending embedded code to some other location and energetically disassembling
the computer on which it is stored doesn't give the foreign government at
your new storage site/test facility on their soil the right to demand the
source under terms of the GPL. Its still your bomb - you just decided to put
it somewhere inconvenient to some other country and then turn it on and test
it. After all, you neither sold them nor gave them the software. Chances
are, they'd want you to take back the whole delivery package anyway. They
may return the favor and when one side or the other decides to give up, the
winner can make it part of the terms of surrender that they cough up the
GPL'ed code if they want.

As for the NATO allies getting some system that included GPL code? I'd guess
that the U.S. as a member of NATO could say that they are in posession of
the source - hence NATO is in posession of the source. No need for them to
give it to the branch office of NATO that calls itself France or England -
just like the first case.

Besides, its all moot under the terms and conditions of Catch 22 which
clearly states: "The Army can do anything you can't stop it from doing."
They're the guys holding all the guns and bombs. If they don't feel like
redistributing the source code and feel rather strongly about it, what can
FSF, et alia do about it? Go to war?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Al Christians" <achrist@easystreet.com> wrote in message
news:3B2E2261.303FE952@easystreet.com...
>
> That's a curious one.  GPL says:
>
> "If ... conditions are imposed on you ... that contradict the conditions
> of this License, they do       not excuse you from the conditions of
> this License. If you cannot distribute so as to satisfy simultaneously
> your obligations under this License and any other pertinent obligations,
> then as a consequence you may not distribute the Program at all."
>
> This would appear to make it impossible, for example for a military
> contractor that 'distributes' its products to military customers to
> include GPL code in a weapons system that was under security
> restrictions, or for one country to license military technology
> that included GPL code to another country with any restrictions on
> to whom the weapons could be re-sold.  And is hurling a projectile
> that contains embedded software 'redistribution'?
>
>
> Al

Re: Market pressures for more reliable software

[Ted Dennison]

In article <9glcks$dvk$1@nh.pace.co.uk>, Marin David Condic says...
>Sending embedded code to some other location and energetically disassembling
>the computer on which it is stored doesn't give the foreign government at
>your new storage site/test facility on their soil the right to demand the
>source under terms of the GPL. Its still your bomb - you just decided to put
..
>Besides, its all moot under the terms and conditions of Catch 22 which
>clearly states: "The Army can do anything you can't stop it from doing."
>They're the guys holding all the guns and bombs. If they don't feel like

At work we pictured it going like this:

Serbia: It has come to our attention that your organization (hereafter referred
to as NATO) has redistributed thousands of copies of software to our cities
which is covered under the GNU Public License (hereafter referred to as the GPL)
inside of the casings of shells, missiles, and bombs. Under the redistribution
terms of the GPL, you are required to provide us with the sources to all the
GPL'ed code that you have distributed, and to all code linked with it, yet this
source code has been purposely and maliciously denied us. We are hereby suing
NATO for $1.5 Billion US in compensatory and punitive damages, and for full
compliance with the terms of the GPL.

NATO: We are currently in the process of formulating a full and complete
response to your legal brief. We respectfully request that Serbia provide the
GPS coordinates of its legal council, so that we may ensure that our response is
delivered properly...

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Market pressures for more reliable software

[Al Christians]

Marin David Condic wrote:
> 
> Same as if .....   ....  ... .... 
> ... Ford-Detroit decides not to send the source to Ford-England. Its 
> an  internal matter for Ford.
> 

Yes. It's  an internal matter until the GPL software gets 'distributed',
as from weapons maker to military.  If that happens, then either
(1) military can't prosecute spies for slipping source to Pottsylvanian  
OGPU, or (2) the whole deal should never have happened according to GPL,
or (3) if I tell you (3), the black helicopters will come back.


Al

Re: Market pressures for more reliable software

[Marin David Condic]

(plugging ears) "I can't hear you... YAYAYAYAYAYAYA!!!!" :-)

No, I think that from ACME Atom Bombs (Slogan: "Good to the last drop!") to
DoD, they'd have to provide source with the distribution, but that doesn't
*force* the DoD to redistribute it to anybody. Nor does it stop the DoD from
having an agreement with ACME Atom Bombs that they not distribute anything
either. It is, after all, their software and if they don't want to make it
public, that's their choice. Correct me if I am wrong, but the mere use of
GPL software AFAIK, doesn't suddenly obligate you to print up a CD full of
your software and mail it to everyone in the country, right? So you're still
free to take all of your software and lock it in a vault, correct?

I also don't believe that the GPL is going to override the government's
ability to slap a "Classified" sticker on top of anything they write and say
"Copyleft My A**!" They can already do this to software that *you* write in
your garage in your spare time if they feel like it - *and* lock you up in
prison for having written it in the first place. ("Catch 22" - Remember?)
Its been done before.

As for the black helecopters, I've found the solution: At night, you wear an
aluminum foil helmet, grounded to a cold water pipe. It keeps them from
monitoring your thoughts and they can't home in on you. It works best if you
shape it like a pyramid. Either that, or turn your whole house into a
Faraday cage. Both together work exceptionally well. I have not seen the
black choppers - or the Shadow People - for some weeks now. (Maybe they're
just getting better at it?)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Al Christians" <achrist@easystreet.com> wrote in message
news:3B2E42A9.F5ACF80E@easystreet.com...
> Yes. It's  an internal matter until the GPL software gets 'distributed',
> as from weapons maker to military.  If that happens, then either
> (1) military can't prosecute spies for slipping source to Pottsylvanian
> OGPU, or (2) the whole deal should never have happened according to GPL,
> or (3) if I tell you (3), the black helicopters will come back.
>

Re: Market pressures for more reliable software

[tmoran]

>... Ford-Detroit decides not to send the source to Ford-England.
>Its an internal matter for Ford.
  The solution is clear: When everything in the world is a subsidiary
of Microsoft then all distribution will be purely an internal matter!
;)
p.s.
  That also solves the problem of underproduction of software because
the producer cannot appropiate the buyer's full value - if the "buyer"
is just another division, then the overall company captures full value.

Re: Market pressures for more reliable software

[Charles Hixson]

Al Christians wrote:

> Ted Dennison wrote:
> 
>>Since the
>>military requires the sources anyway, and refuses to give out the 
>>software in most cases, they are quite compatabile with the GPL. 
>>
> 
> That's a curious one.  GPL says:
> 
> "If ... conditions are imposed on you ... that contradict the conditions
> of this License, they do       not excuse you from the conditions of
> this License. If you cannot distribute so as to satisfy simultaneously
> your obligations under this License and any other pertinent obligations,
> then as a consequence you may not distribute the Program at all." 
> 
> This would appear to make it impossible, for example for a military
> contractor that 'distributes' its products to military customers to
> include GPL code in a weapons system that was under security
> restrictions, or for one country to license military technology
> that included GPL code to another country with any restrictions on 
> to whom the weapons could be re-sold.  And is hurling a projectile 
> that contains embedded software 'redistribution'?
> 
> 
> Al
> 

The owner of the copyright has all necessary rights to do whatever he 
feels like with it.  GPL is one manifestation of this, and explicitly 
allows one to release it under other licenses.

OTOH, if you mean that including GPL code written by others would be a 
problem, only those who are have a legitimate binary copy  have the 
right to require source code, and the only person/company obligated to 
supply them with the source code is the person/company that they got the 
binary from.

The only time this becomes at all questionable is when military equiment 
is decomissioned.  In that case they might be required to either remove 
the binary code or to distribute the source.  OTOH, I believe that the 
current understanding is that having an embedded module that contains 
binary code is not the same as having the source code unless it contains 
some method for dumping the code.  But I'm less than certain about that.

-- 
Charles Hixson

Copy software legally, the GNU way!
Use GNU software, and legally make and share copies of software.
See http://www.gnu.org
     http://www.redhat.com
     http://www.linux-mandrake.com
     http://www.calderasystems.com/
     http://www.linuxapps.com/

Re: Market pressures for more reliable software

[Al Christians]

> Al Christians wrote:
> 
> only those who are have a legitimate binary copy  have the
> right to require source code

My understanding is that once a work has been released under GPL, 
all copies are legitimate, source and/or binary.    You must allow
it to be licensed to any and all third parties without any conditions
beyond those in the GPL. There's a new  FAQ a few weeks ago from FSF on 
GPL that explains some of these issues.  


Al

Re: Market pressures for more reliable software

[Charles Hixson]

Al Christians wrote:

 >> Al Christians wrote:
 >>
 >> only those who are have a legitimate binary copy  have the right
 >> to require source code
 >>
 >
 > My understanding is that once a work has been released under GPL,  all
 >  copies are legitimate, source and/or binary.    You must allow it
 > to be licensed to any and all third parties without any conditions beyond
 >  those in the GPL. There's a new  FAQ a few weeks ago from FSF on  GPL
 >  that explains some of these issues.
 >
 >
 > Al
 >
Umn... not precisely.  Anyone you give or sell a copy to has the right 
to further release it, but that doesn't make all copies legitimate.  You 
could give it to a business associate for use in some project, and 
someone could steal it from him, or someone could break into your 
computer and steal a copy.  These would not be legitimate copies.  If 
they were to be distributed further, the holder could be required to 
provide source, but would not necessarily have any access to the 
appropriate source.

OTOH, practically speaking, anything which is widely distributed under 
the GPL has legitimate copies available to anyone.

P.S.:  Steal in this case simply means acquiring a copy illegally. 
E.g., a piece of software could be licensed GPL, but only be used 
internally in an organization (i.e., no public release).  And an 
employee who did not have the right to do so could e-mail it to an 
external associate.  No malice need be involved.  For that matter, I 
don't even assume any damages beyond the assumption of the requirement 
to make source available.  My statement is that there is no such 
requirement.  The employee didn't have the right to distribute it, so 
the copy is illegitimate.  And the firm doesn't have to keep the 
unchanged source on file for three years (presuming the source wasn't 
distributed with or instead of the binary).

Now IANAL, so there are lots of special cases in here that depend on 
points of law that I have no knowledge of.  But that's the broad outline.
-- 
Charles Hixson

Copy software legally, the GNU way!
Use GNU software, and legally make and share copies of software.
See http://www.gnu.org
     http://www.redhat.com
     http://www.linux-mandrake.com
     http://www.calderasystems.com/
     http://www.linuxapps.com/

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <3B2E7263.9080804@earthlink.net>, on 06/18/2001
   at 09:29 PM, Charles Hixson <charleshixsn@earthlink.net> said:

>The only time this becomes at all questionable is when military
>equiment  is decomissioned.

If the source code is classified then the object code will be
protected. As part of decommissioning they will erase or destroy the
memory containing the object code. If they don't, they will have more
serious legal problems than GPL violations.


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[Florian Weimer]

Ted Dennison<dennison@telepath.com> writes:

> "Liberated" is actually a little closer to what I think they were
> shooting for.  However, that word implies previous enslavement,
> which isn't quite right either.

The EU is using the term "libre software", I think, to avoid such
connotations.

Re: Market pressures for more reliable software

[David Chase]

Ed Jensen wrote:

> In comp.lang.java.programmer Ted Dennison <dennison@telepath.com> wrote:
> : When I capitalize "Free", its to indicate that I'm talking about FSF-style "Free
> : Software".
> 
> Is anyone else annoyed that the FSF has decided to redefine the term
> "free software" for marketing purposes?

Compared to most for-profit marketing, it is incredibly tame.

> I think I'll scoop up some doggie poo, put it in a bowl, and place a
> sticker on it that says "Rose Petals".

Your implicit comparison of free software with dog poo is
completely unjustified, and reflects more on your experience
and judgement than it does on Free Software.

> -Ed, who thinks "Free Software" (GPL-style) is unethical.

If you think it's unethical, you aren't much of a thinker.  I
don't believe all the FSF dogma, but their code works as
advertised, and I always have the option of not
using their code as a basis for my own work.  That "option"
is the mandatory default if I use (just for example, and MS
is by no means the only example) Microsoft products.  We USE
Free software in our own work all the time, and we treat it
almost exactly (*) as we treat software that we pay for, because
in either case the licensing terms do not allow us unencumbered
modification and redistribution of the software.

(*) we're more likely to report bugs in Free software, partly
because we have access to the source code.  We also copy it
from machine to machine with less concern for licensing,
because their licensing doesn't include any significant
restrictions on the creation/distribution of binary copies
within a company.

I am also very impressed with the compatibility over time
that I have seen in one "Free" effort, which is MikTeX and
the new version of LaTeX.  It processed a 15-year old
document without any problems at all, and with only a
three-line change in the header the document could be
processed in modern (instead of "compatibility") mode,
allowing me access to features like generation of PDF
files with automatic inclusion of indexing and thumbnails.
Compare this with Word, which is not even compatible
between installations (of the same version) on different
machines.

The quality of Free software is also generally quite high.
I find bugs in it, but I find bugs in most software, and
the bug rate is no higher than that in un-Free products.

David Chase

Re: Market pressures for more reliable software

[James A. Robertson]

Ted Dennison wrote:
> When I capitalize "Free", its to indicate that I'm talking about FSF-style "Free
> Software".
> 

The problem occurs once your software reaches a 'mature' state - then
few are buying new licenses (there's no need), and few buy support (it's
mature and doesn't need it).  This is what is starting to happen with MS
Office, and is also something that has hit the development tools sector.

The answer that seems to work is a subscription model, which you can
find large numbers of people railing against.

The base problem is that over time, people in fact won't pay for support
- especially once the product gets to a state where it doesn't need a
lot of it.

> Nearly all software is already developed as custom software under a system where
> the deveopers are paid for the development. That includes *every* project I've
> ever worked on in my career. Even for most of the "licensed" commercial software
> I deal with, the "support" is the most expensive part. So using Free Software
> models wouldn't even noticably impact the vast majority of the software
> developed.
> 
> Of course this skirts around the issue that the small minority of software left
> actually gets distributed the most. But there are still ways to make money using
> Free Software in that realm. RedHat has shown that. They just won't make nearly
> as *much* money as they would if they could somehow charge a toll on each copy.
> 
> You bring up games. To answer your question directly, yes people *do* pay for
> "support" for games. 900-number "hint lines" for adventure games are not unheard
> of. Also, nearly every game company has some kind of customer support (the money
> to pay for for that obviously comes from game sales, so you can think of it as
> sort of a "support tax").
> 
> I've played computer games avidly for over 20 years (since back when games were
> distributed in compliation books as BASIC source code). So I have thought about
> this a lot. For a computer game, what I'd try to sell is the manual. There's
> already a racket going where the shipped manuals are useless, and anyone who
> wants to know what's really going on buys a "game guide". They might as well
> make it official. I also collect the boxes, and on one glorious occasion, got
> one autographed by the heads of the development team (Sid Meyer, Brian Reynolds,
> et al). So I'm quite confident that people would still pay for an official
> "hard" copy (perhaps even more for a hand-autographed one).
> 
> >Now there might be something to the notion of software developed under the
> >Ada Developer's Cooperative License (or similar) in that the guys who build
> >the code only get paid if the code gets used and sold. The only way for that
> 
> That might work out OK in a world of mass-produced shrink-wrapped software. But
> remember paragraph 1: the vast majority of software *developed* does not fit
> that mold. In the world in which I work, I can't use any nifty routine that's
> going to add to the system's costs, because *I* don't get to make those kinds of
> decisions. The folks that do are my managager's manager, who's already obsessing
> about overruns, and the paper-pushers off in accounting, who require all sorts
> of paperwork and market research and competitive sourcing and several weeks to
> make any kind of decision (You should see us trying to buy a PC video card
> before it goes obsolete. Its sad, really). Unless we are talking some pretty
> significant functionality, its far easier for me to just rewrite it all myself
> (and what a shameful waste of human effort that is!).
> 
> So that license might get some lucky package shipped in lots of software copies.
> But for the vast majority of *developers*, its just going to render the package
> useless.
> 
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

-- 
James A. Robertson
Product Manager (Smalltalk), Cincom
jarober@mail.com
<Talk Small and Carry a Big Class Library>

Re: Market pressures for more reliable software

[Al Christians]

"James A. Robertson" wrote:
> 
> The problem occurs once your software reaches a 'mature' state - then
> few are buying new licenses (there's no need), and few buy support (it's
> mature and doesn't need it).  This is what is starting to happen with MS
> Office, and is also something that has hit the development tools sector.
> 
> The answer that seems to work is a subscription model, which you can
> find large numbers of people railing against.
> 
> The base problem is that over time, people in fact won't pay for support
> - especially once the product gets to a state where it doesn't need a
> lot of it.
> 

The answer you propound is evidently the answer to the question "How
do I get a perpetual income from a single project?"  Good software 
may be usable in perpetuity,  but if the market is competitive,  the
price will compensate the seller only for what is sold and  will not 
saddle the buyer with additional costs (short-term or long-term) for 
what is neither wanted nor needed.  Reliable software ought to be 
produced in  a comparatively short time and last a comparatively long 
time.  The justification for market economies is that they produce a 
bounty for consumers (buyers).  Producers are supposed to be smart 
enough to deal with that.

Where I live there is some of the back end of the game development 
business.  That market has adapted to the economics of software as 
a permanent good. They produce a game and move on.  Embedded software
ought to work the same way.  I might not buy an appliance if I knew
there was a permanent development group somewhere continually turning 
out bug fixes for the appliance's embedded software.  If consumers
prefer to pay once and use forever, it's market failure if they can't
find a way to get what they want.


Al

Re: Market pressures for more reliable software

[tmoran]

>... but if the market is competitive, the price will compensate the
>seller only for what is sold and will not saddle the buyer with
>additional costs (short-term or long-term) for what is neither wanted
>nor needed.  ...  The justification for market economies is that they
>produce a bounty for consumers (buyers).  Producers are supposed to
>be smart enough to deal with that.
  And in a situation where the value to a buyer of an item is greater
than the value to a producer of supplying that item, there will be an
undersupply.  In particular, if support and upgrades are free, and
don't generate significant advertising, good will, or money to
producers, support and upgrades will cease, even if they would be
useful to some buyers.

Re: Market pressures for more reliable software

[Marin David Condic]

The basic idea ought to be this: Produce a really good word processor that
may evolve for a while as you discover the features people will want. When
it matures and stabilizes on a feature set, move on to the next frontier.
Don't keep trying to sell the word processor to the people who already own
it. Sell them a spreadsheet or a database instead.

You can't really get around a mature market. Sooner or later, you've filled
the pipeline and the only new sales are going to be to the handful of
consumers who are just entering the market or replacing what has worn out.
(In software terms, "wearing out" would be analogous to a new hardware or OS
technology - the end of useful life.) Put the product on the shelf & accept
the trickle of revenue it brings in with little or no cost to you & start
looking for the next thing you can build. Eventually, new technology will
come around that will demand you go rebuild the product but why waste the
resources to rebuild it constantly along the way?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Al Christians" <alc@PublicPropertySoftware.com> wrote in message
news:3B2BEA63.34116398@PublicPropertySoftware.com...
>
> The answer you propound is evidently the answer to the question "How
> do I get a perpetual income from a single project?"  Good software
> may be usable in perpetuity,  but if the market is competitive,  the
> price will compensate the seller only for what is sold and  will not
> saddle the buyer with additional costs (short-term or long-term) for
> what is neither wanted nor needed.  Reliable software ought to be
> produced in  a comparatively short time and last a comparatively long
> time.  The justification for market economies is that they produce a
> bounty for consumers (buyers).  Producers are supposed to be smart
> enough to deal with that.
>
> Where I live there is some of the back end of the game development
> business.  That market has adapted to the economics of software as
> a permanent good. They produce a game and move on.  Embedded software
> ought to work the same way.  I might not buy an appliance if I knew
> there was a permanent development group somewhere continually turning
> out bug fixes for the appliance's embedded software.  If consumers
> prefer to pay once and use forever, it's market failure if they can't
> find a way to get what they want.
>

Re: Market pressures for more reliable software

[Marin David Condic]

Is it a surprise that Bill Gates has noticed this and is busy trying to con
people into keeping their software & data on some central server for which
he can charge? Has anybody noticed that the model he suggests is absolutely
*no* different at its core from the model we used to have of a large
centralized datacenter that wrote all your software for you and stored all
your data for you and managed everything for you? Ever wonder why that model
fell on the wayside once computers got fast enough and cheap enough for the
average person to own one? (Synonym: Those in the Federal Govt who would say
"Send us all your money and we'll spend it for you and take care of you...")

What disturbs me is not that there are those out there who would suggest
such a large, centralized model and call it "new". What disturbs me is the
credit they give to our intelligence. That and the fact that there are
people out there who *will* swollow it whole - and they are allowed to vote
and drive cars.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"James A. Robertson" <jarober@mail.com> wrote in message
news:3B2B6D5E.F9AE7CAB@mail.com...
> The problem occurs once your software reaches a 'mature' state - then
> few are buying new licenses (there's no need), and few buy support (it's
> mature and doesn't need it).  This is what is starting to happen with MS
> Office, and is also something that has hit the development tools sector.
>
> The answer that seems to work is a subscription model, which you can
> find large numbers of people railing against.
>
> The base problem is that over time, people in fact won't pay for support
> - especially once the product gets to a state where it doesn't need a
> lot of it.
>

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <9gl0sh$9gq$1@nh.pace.co.uk>, on 06/18/2001
   at 09:49 AM, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> said:

>Is it a surprise that Bill Gates has noticed this and is busy trying
>to con people into keeping their software & data on some central
>server for which he can charge? Has anybody noticed that the model he
>suggests is absolutely *no* different at its core from the model we
>used to have of a large centralized datacenter that wrote all your
>software for you and stored all your data for you and managed
>everything for you?

A model that has no basis in reality. Applications developement was
decentralized for as far back as I can remember. Santayana.


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[Marin David Condic]

How far back can you remember? :-)

Seriously. I worked in a datacenter where the programming for the whole
organization was done in a central location by an MIS department and batch
jobs were run by the computer operators and all anybody had was dumb
terminals. There may have been *pockets* of development taking place outside
of MIS (the model was already beginning to crumble because of mini
computers) but basically, if you wanted some program developed or changed,
you had to go through MIS. (We were infinitely more responsive to customer
change requests than Microsoft will ever be given that your chances of
asking them to change something about MS-Word and getting anything but
laughter are zero.) The big mainframe stored all your code and all your data
and had all the advantages that Bill Gates is claiming for his internet
based central repository - access to your data & programs from wherever you
happen to be (if a terminal was there) and immediate updates of any code as
they occur. The disadvantages are all those we had with centralized MIS
departments/mainframes and then some.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in
message news:3b2f40fc$7$fuzhry$mr2ice@va.news.verio.net...
>
> A model that has no basis in reality. Applications developement was
> decentralized for as far back as I can remember. Santayana.
>

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <9gnn8m$979$1@nh.pace.co.uk>, on 06/19/2001
   at 10:23 AM, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> said:

>How far back can you remember? :-)

Well before the term "MIS" came into vogue. My first computer was a
vacuum tube machine that I will never be nostalgic about.

>Seriously. I worked in a datacenter where the programming for the
>whole organization was done in a central location by an MIS
>department and batch jobs were run by the computer operators and all
>anybody had was dumb terminals. There may have been *pockets* of
>development taking place outside of MIS (the model was already
>beginning to crumble because of mini computers) 

No doubt there were organizations where all of the programming was
done by a centralized DP staff. But there were also organizations
where the programming of a single machine was decentralized and the DP
staff was only concerned with such issues as operations, maintenance
of systems software and scheduling. In fact, there were shops where
users were expected to run their own jobs as well as program them.

Santayana.

-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[Charles Hixson]

Marin David Condic wrote:

> How far back can you remember? :-)
> 
> Seriously. I worked in a datacenter where the programming for the whole
> organization was done in a central location by an MIS department and batch
> jobs were run by the computer operators and all anybody had was dumb
> ...
> 

Well, back in 1960-64 I was in several different places.  Some were 
centralized and some weren't.  The keypunching was centrallized.  The 
computers were centralized.  But we did all the coding on paper or 
coding sheets.  And those were decentrallized.

Some people only created data, and a few others only created programs, 
and several did both, and most did neither.  But though the machinery 
was centrallized, in most of the places that I was the coding wasn't. 
There were exceptions.  OTOH, much (not all) of this experience was 
around a university, so that might skew things.

-- 
Charles Hixson

Copy software legally, the GNU way!
Use GNU software, and legally make and share copies of software.
See http://www.gnu.org
     http://www.redhat.com
     http://www.linux-mandrake.com
     http://www.calderasystems.com/
     http://www.linuxapps.com/

Re: Market pressures for more reliable software

[Marin David Condic]

Well, the point was, at one time lots (if not most or all) of the computing
was done in some centralized manner. You had a mainframe to which you
connected and on that mainframe was where you had your data and programs.
That had the advantage (as Micro$oft will tell you) that you could access
your data from anywhere on any piece of equipment (a dumb terminal at the
time) and if some piece of software you used was supported by the central
location, you instantly got updates as they were made.

Eventually, this model began to wane because of the prevalence of mini and
microcomputers. People now had their software stored on their *own* personal
machine. You didn't need to ask permission of some central DP organization
to get something done (change software, update data, make backups, get more
disk quota, etc.) You just up and did it - including deciding if you wanted
to buy a new version of some software product or just live with what you
have.

Now Bill Gates, et alia, are suggesting that you go back to the old model
because this way, they can keep charging you every day for the storage of
your data and the execution of your programs. (That's basically what you had
in the old days, right? Or is the suggestion that somehow it wasn't this way
or that B.G., et al., are offering you something fundamentally different? Or
maybe it is just unclear what I meant when I said "Centralized"?) I suppose
you are free to do that if you like, but personally, I would rather have all
that stuff sitting on my desk at home & not keep buying Micro$oft Word every
time I want to execute it. (Nor trusting Micro$oft not to go "data mining"
through my private files. Assuming they aren't doing that already every time
I connect to the Internet... :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Charles Hixson" <charleshixsn@earthlink.net> wrote in message
news:3B30C75D.2020507@earthlink.net...
> Marin David Condic wrote:
>
> > How far back can you remember? :-)
> >
> > Seriously. I worked in a datacenter where the programming for the whole
> > organization was done in a central location by an MIS department and
batch
> > jobs were run by the computer operators and all anybody had was dumb
> > ...
> >
>
> Well, back in 1960-64 I was in several different places.  Some were
> centralized and some weren't.  The keypunching was centrallized.  The
> computers were centralized.  But we did all the coding on paper or
> coding sheets.  And those were decentrallized.
>
> Some people only created data, and a few others only created programs,
> and several did both, and most did neither.  But though the machinery
> was centrallized, in most of the places that I was the coding wasn't.
> There were exceptions.  OTOH, much (not all) of this experience was
> around a university, so that might skew things.
>
> --
> Charles Hixson
>
> Copy software legally, the GNU way!
> Use GNU software, and legally make and share copies of software.
> See http://www.gnu.org
>      http://www.redhat.com
>      http://www.linux-mandrake.com
>      http://www.calderasystems.com/
>      http://www.linuxapps.com/
>

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <9gqkhf$c10$1@nh.pace.co.uk>, on 06/20/2001
   at 12:55 PM, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> said:

>Well, the point was, at one time lots (if not most or all) of the
>computing was done in some centralized manner. You had a mainframe to
>which you connected and on that mainframe was where you had your data
>and programs.

That much is correct. However, it does not imply that maintenance of
either the data or the programs was centralized.

>You didn't need to ask permission of some central DP organization to
>get something done (change software, update data, make backups, get
>more disk quota, etc.) You just up and did it - including deciding
>if you wanted to buy a new version of some software product or just
>live with what you have.

Are you saying that you didn't have to budget for additional hardware,
personnel, etc.? On the centralized mainframe you were already free to
get something done (change software, update data, make backups, get
more disk quota, etc.) The only difference was that some things were
done automatically, e.g., periodic backups.

>Now Bill Gates, et alia, are suggesting that you go back to the old
>model

No such thing; he wants to go to a model that has never existed.

>(That's basically what you had
>in the old days, right? 

Wrong. The DP staff had to answer to the users. Gill bates doesn't
want that. The users were able to buy other software and install it
themselves if they could afford it. He certainly doesn't want that.



-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[Roedy Green]

On Tue, 19 Jun 2001 10:23:17 -0400, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> wrote or quoted :

> centralized MIS

This is different from what is being proposed. Each vendor would look
after maintenance and installation of its own software and updates.
This is not the same as having it all done by one group.

However, to do it securely, you do need a fascist OS that has its
finger on the pulse to make sure no app meddles with data and programs
it has no business meddling with.


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <3B28FAD5.5FFB643F@world.std.com>, on 06/14/2001
   at 05:56 PM, David Chase <chase@world.std.com> said:

>> I think I'll scoop up some doggie poo, put it in a bowl, and place a
>> sticker on it that says "Rose Petals".

>Your implicit comparison of free software with dog poo is completely
>unjustified, and reflects more on your experience and judgement than
>it does on Free Software.

I don't see where he has made any such comparison, implicit or
otherwise. What he was criticising was the spin control.

>> -Ed, who thinks "Free Software" (GPL-style) is unethical.
>If you think it's unethical, you aren't much of a thinker. 

Now there I agree with you. If I write a piece of software, it's my
property and, to a first approximation, I am free to decide who may
use it and under what circumstances. If I decide to release it under a
GPL, that's my right, whether mickey$oft likes it or not. 

-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[tmoran]

>4. Free Software. If it doesn't quite do what you want, you've lost nothing but
>your evaluation time. Even better, you have more options than just trying
>something else. You can fix it yourself to do what you want, or pay someone else
>(preferably someone intamately familiar with the code) to do it for you.
  "Well of course it doesn't actually drive - the motor's in the back
seat.  You can cancel your purchase and not pay a dime (other than taxi
fare home), or you can install the motor yourself, or you can hire our
service department to install it.  You couldn't ask for more."

Re: Market pressures for more reliable software

[Larry Elmore]

Roedy Green wrote:
> 
> On Wed, 13 Jun 2001 12:22:43 -0400, "Marin David Condic"
> <marin.condic.auntie.spam@pacemicro.com> wrote or quoted :
> 
> > Produce a reliable product at a similar price and with
> >similar features and with a similar marketing budget.
> 
> The problem with software is you have to use it for at least a few
> months to evaluate its quality and suitability FOR YOUR NEEDS. Adobe
> may create some extremely good and expensive software, but their
> packages could be overwhelming for a newbie.
> 
> BUT, by then it is too late. The vendor already has your money,
> whether or not he has delivered a suitable, working product.
> 
> This problem with buying a pig in a poke greatly favours market
> leaders who can afford advertising, and whose products will be
> purchased by newcomers simply on name recognition. There is not enough
> incentive for a market leader to produce a high quality product.

Sure there is. There _is_ a lag time, but it's not really any different
than the original example of American-made automobiles. After all, it's
not at all obvious that a car will rust out in 4-5 years after only a
few months on the market -- but it will take years for that manufacturer
to rebuild its reputation once it's lost and it will lose a lot of sales
during that time period.

Larry

Re: Market pressures for more reliable software

[Charles Hixson]

Larry Elmore wrote:

 > Roedy Green wrote:
 >
 >> On Wed, 13 Jun 2001 12:22:43 -0400, "Marin David Condic" 
<marin.condic.auntie.spam@pacemicro.com>
 >>  wrote or quoted :
 >>
 >>
 >>> Produce a reliable product at a similar price and with similar
 >>> features and with a similar marketing budget.
 >>>
 >> The problem with software is you have to use it for at least a few 
months
 >>  to evaluate its quality and suitability FOR YOUR NEEDS. Adobe may
 >>  create some extremely good and expensive software, but their packages
 >>  could be overwhelming for a newbie.
 >>
 >> BUT, by then it is too late. The vendor already has your money, whether
 >>  or not he has delivered a suitable, working product.
 >>
 >> This problem with buying a pig in a poke greatly favours market leaders
 >>  who can afford advertising, and whose products will be purchased
 >>  by newcomers simply on name recognition. There is not enough incentive
 >>  for a market leader to produce a high quality product.
 >>
 >
 > Sure there is. ... but it will take years for that manufacturer to
 > rebuild its reputation once it's lost and it will lose a lot of
 > sales during that time period.
 >
 > Larry
 >

There seem to be an awful lot of companies that don't count that 
expense.  Considerably more than a mere majority.  And frequently the 
larger ones.  Marketing makes up for some horrendous blunders.

In general my experience it that if I pay a wad of cash, I'll get a much 
slicker product than a free one.  Free one's often even have text 
interfaces (though tcl and gtk are becoming more common).

OTOH, I'm not talking about custom software here.  I can't.  If I need 
custom software I either write it or do without.  (Or customize it 
myself, but that only applies to BSD and GPL style licensed products.)
That said, I must admit that I'm more likely to write it myself than to 
customize it, unless it's a *very* simple job.  Figuring out C code is 
generally nearly as bad as writing it in the first place, and that's 
what most of the source I see is.  (And with C++ it really depends alot 
on the coding style of the programmer.  That's another big chunk.)

-- 
Charles Hixson

Copy software legally, the GNU way!
Use GNU software, and legally make and share copies of software.
See http://www.gnu.org
     http://www.redhat.com
     http://www.linux-mandrake.com
     http://www.calderasystems.com/
     http://www.linuxapps.com/

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <40gfitgrvd8cgu27r3vfib6eptmapb3pfl@4ax.com>, on 06/13/2001
   at 07:48 PM, Roedy Green <roedy@mindprod.com> said:

>1. try-before-you-buy which is becoming much more common.  Electronic
>distribution lets you try several packages before making your final
>decision.  My problem with the technique is software trials are TIME
>limited rather than USE-limited.  I sometimes get sidetracked before
>completing evaluating a package, then lose the right to examine
>it.

I've found shareware authors to be generally cooperative on this. When
I've asked for an extension, they've usually gone along with it. I've
registered several shareware products after an extension that I would
have discarded without one.

>3. Consumer Reports so that new software is much less a pig in a
>poke.

That would help if CU had a clue about computers. Every
computer-related review of theirs that I've read has been seriously
flawed at best.

-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[Ted Dennison]

In article <3b28b7a7$4$fuzhry$mr2ice@va.news.verio.net>, Seymour J. says...
>
>That would help if CU had a clue about computers. Every
>computer-related review of theirs that I've read has been seriously
>flawed at best.

Among other problems, they have a nasty tendancy to consider price *way* out of
proportion to other factors (which is OK if you feel that way too, I guess). I
remember an issue back in the mid 80's where they recommended that everyone go
out and buy AtariST's. :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Market pressures for more reliable software

[Roedy Green]

On Thu, 14 Jun 2001 09:09:59 -0400, "Shmuel (Seymour J.) Metz"
<spamtrap@library.lspace.org.invalid> wrote or quoted :

>>3. Consumer Reports so that new software is much less a pig in a
>>poke.
>
>That would help if CU had a clue about computers. Every
>computer-related review of theirs that I've read has been seriously
>flawed at best.

You need something like CR though to avoid the problem of refraining
from giving the dirt to avoid hurting advertisers.

Perhaps there will be a way of organising reports from the field from
ordinary folk that are hard to forge.

But even then, you really need one person looking at all the packages
side by side, who represents a typical user.  So often the reviewer
has no idea what is important since he has never used such a package
in production.  They get hypnotised by cute features.

There are several TV shows now that talk about software.  One of them
seems to be on nearly all the time on Shaw Cable. The guy wings it and
tends thus to be unusually honest. 

I was hired once by such as a TV show,  Dotto on Data, as a "regular"
columnist, On my first live show I took a strip out of Compuserve.
That was my last show.  It turned out Compuserve was one of the
sponsors.


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <407iitsqevc9j85mcuadk4ha392ega7jmj@4ax.com>, on 06/14/2001
   at 08:25 PM, Roedy Green <roedy@mindprod.com> said:

>You need something like CR though to avoid the problem of refraining
>from giving the dirt to avoid hurting advertisers.

You need somebody unbiased. But you also need somebody competent and
educated. The reviews in CR are full of techobable[1] and lack
awareness of the existence of alternatives to the
least-common-denominator products.

[1] E.g., legitimate words used with no understanding of what they
actually mean.


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[Larry Kilgallen]

In article <40gfitgrvd8cgu27r3vfib6eptmapb3pfl@4ax.com>, Roedy Green <roedy@mindprod.com> writes:

> This problem with buying a pig in a poke greatly favours market
> leaders who can afford advertising, and whose products will be
> purchased by newcomers simply on name recognition. There is not enough
> incentive for a market leader to produce a high quality product.
> 
> I see three ways around this:


> 3. Consumer Reports so that new software is much less a pig in a poke.
> General computer literacy should help along these lines too.  The new
> generation coming up are not going to be such lambs lead to the
> slaughter.

I fear use of reviews naturally degrades into faulty use of reviews.
Recently I commented that I bought something because of the reviews.
The response was -- I didn't see that getting the best score in the
reviews.  The response was correct, since I did not care about the
overall score from reviewers, but rather their detailed comments on
the aspects of the product about which I was most interested. The
easiest thing for a reviewer to write is a bullet-list of "features".
It wins points with editors, too, because it leads to a graphical
presentation.  So we are back at the old bugaboo of feature lists
prevailing over quality, since the latter is so subjective.

Re: Market pressures for more reliable software

[Larry Kilgallen]

In article <9gl1h0$9rp$1@nh.pace.co.uk>, "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:

> You can't really get around a mature market. Sooner or later, you've filled
> the pipeline and the only new sales are going to be to the handful of
> consumers who are just entering the market or replacing what has worn out.
> (In software terms, "wearing out" would be analogous to a new hardware or OS
> technology - the end of useful life.)

Another approach is to gain control of a related product (perhaps the
operating system upon which the first product depends) and introduce
changes that are desired in that related product but require a new
version of the first product in order to interoperate.

Re: Market pressures for more reliable software

[Larry Kilgallen]

In article <9gqkhf$c10$1@nh.pace.co.uk>, "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
> Well, the point was, at one time lots (if not most or all) of the computing
> was done in some centralized manner. You had a mainframe to which you
> connected and on that mainframe was where you had your data and programs.
> That had the advantage (as Micro$oft will tell you) that you could access
> your data from anywhere on any piece of equipment (a dumb terminal at the
> time) and if some piece of software you used was supported by the central
> location, you instantly got updates as they were made.

But that was centralized within a legal entity, generally not across
legal entities like Microsoft is suggesting.

Re: Market pressures for more reliable software

[Marin David Condic]

I don't see how that matters in the context in which I was trying to make my
point. You could always lease mainframe time - McDonnel Douglas had a big
business doing exactly that (McAuto, if I recall) and there were others as
well. That's centralized computing across legal entities. We don't do that
much anymore - or if we do, I'd ask to see some evidence that the volume of
business computing done on PCs/Workstations/Other-Local-Arrangements is
exceeded by the volume of computing done by someone's centralized mainframe.
I have the evidence of my own eyes when I look around in various businesses.
If there's some evidence I'm not seeing, then I'd like someone to bring it
forward.

I seem to be getting misunderstood for reasons I don't comprehend. We
*used*to* have centralized computing. We moved to *distributed* computing
because it had big advantages over a centralized model. Microsoft is
*repackaging* a centralized model and telling us "No. Really. We were wrong
all along. It actually *is* Shinola!" and asking us to believe it is
something new and wonderful and that we should all want to get out our
checkbooks and start sending them money in order to get it.

I don't think my claim here is really a strong one. I'm *not* saying that it
is an exact duplicate of the centralized mainframe/data center concept. I'm
*not* saying that there aren't big and important differences between the
two. What I *am* saying is that we once had a centralized model and opted
out of it and that what Bill Gates is suggesting is essentially a
centralized model - with window dressing to try to fool us into believing it
is something new and wonderful.

Sort of like X-terminals being a "Glass-Teletype-With-Attitude" - it was a
rehash of something we once had and moved away from. Yes, X-terminals do
have important differences from teletypes (glass or otherwise) but the
notion that the central computer will do all the "real" computing and the
terminal will just be responsible for display of the information and input
from the user wasn't some sort of revolutionary new advancement in the field
of computer science. I wasn't fooled into thinking it was something new and
apparently most other people weren't either because when you go into your
garden-variety office you don't see thousands of x-terminals wired up to a
central mainframe. You see lots of PCs and workstations. If someone wants to
dispute this, I'd simply ask them for a reference to some kind of industry
survey that shows how X-terminals outnumber PCs/Workstations in the business
computing market.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message
news:aPN5ieyHFSfT@eisner.encompasserve.org...
>
> But that was centralized within a legal entity, generally not across
> legal entities like Microsoft is suggesting.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <YXDX6.1$MM4.254@nsw.nnrp.telstra.net>, on 06/19/2001
   at 08:21 AM, lesbell@nospam.lesbell.com.au said:

>"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> wrote:


>I seem to be getting misunderstood for reasons I don't comprehend.

You haven't been misunderstood, you've been corrected. Your knowledge
of DP history is faulty, and you haven't paid attention to those who
were there in the old days and told you the reality.

>We
>*used*to* have centralized computing. 

What you mean "we", kimosabi? As I said, it's not a question of
misunderstanding you, it's a question of correcting you. Maybe you
worked at a shop that had centralized computing, although I doubt it.
Such shops were not the norm.

>What I *am* saying is that we once had a centralized model and opted
>out of it 

And as long as you keep saying something demonstrably false your
conclusions remain suspect. The industry has had both decentralized
development on centralized hardware and centralized development on
decentralized hardware for as long as I can remember. Centralization
of one does not, has not and will not imply centralization of the
other.

-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[Ken Garlington]

"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in
message news:3b366a2b$6$fuzhry$mr2ice@va.news.verio.net...

: The industry has had both decentralized
: development on centralized hardware and centralized development on
: decentralized hardware for as long as I can remember.

Just out of curiosity, how long can you remember?

Re: Market pressures for more reliable software

[Ken Garlington]

"Ken Garlington" <Ken.Garlington@computer.org> wrote in message
news:bbvZ6.1539$Cb1.798560367@newssvr17.news.prodigy.com...
: "Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in
: message news:3b366a2b$6$fuzhry$mr2ice@va.news.verio.net...
:
: : The industry has had both decentralized
: : development on centralized hardware and centralized development on
: : decentralized hardware for as long as I can remember.
:
: Just out of curiosity, how long can you remember?

Let's say, just hypothetically, that you've been programming since 1960. How
long can you remember trends in the computing industry (which, presumably,
is different from either academic computing or hobbyist programming)?

In fact, let's go further - does your memory confirm that the OS/360
development effort described in Brooks was fairly typical (if not advanced)
for industrial computing in the early-to-mid 1960's?

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

Ken Garlington wrote:


> Let's say, just hypothetically, that you've been programming since 1960. How
> long can you remember trends in the computing industry (which, presumably,
> is different from either academic computing or hobbyist programming)?

Trends were also different between scientific and commercial computing.
Centralized development was much more common in the commercial sector.

> In fact, let's go further - does your memory confirm that the OS/360
> development effort described in Brooks was fairly typical (if not advanced)
> for industrial computing in the early-to-mid 1960's?

I remember being shocked that the S/360 didn't include any relocation
capability. I remember that OS/360 inherited some nice features from
IBSYS/IBJOB. Overall, my memory confirms that it was less advanced but more
comprehensive than what was available from other vendors. In particular, both
UNIVAC and Burroughs had working multiprocessors on standard lines well before
the 65MP or even the 9020.

--
Shmuel (Seymour J.) Metz

Re: Market pressures for more reliable software

[Gary Labowitz]

I'm curious what you mean by "relocation" that you were shocked that S/360
didn't have it. From the very outset the OS/360 design included a relocating
loader, which was very advanced for its time. The hardware redirection of
memory addresses (dynamic address translation -or DAT) came later (as I
recall about four years).
The development activity in Poughkeepsie was very untypical at the time.
The MP65 was pretty much a late-comer to market with multiprocessing, but it
never really went anywhere. Neither, BTW, did Burroughs, NCR, or Bendix.
Univac held on much longer. I remember losing a large contract to Univac in
the early '70's, but they later switched back to IBM.
As I went about learning PC's (and Apple) operating systems (including
Win32) I was struck with the fact that much of what was the "new" thing was
just a reimplementation of what we did on the S/360 in the mid '60's. Names
changed, and there was a lot more packed into the hardware, but a great deal
was the same. It has drifted a bit,by which I mean that there are some new
concepts pushing PC development in a different direction from the way OS/360
did things, but we were very close to what OOP is all about. IBM's biggest
mistake (like Apple) was trying to keep everything proprietary for market
advantage, and losing to the clones. I think Java is finally breaking into
the same sort of hold Microsoft has used by its "fully integrated" approach.
I will, of course, learn C#, but frankly I'm having more fun now with Java
than with VB (I never committed to C/C++). Perhaps it's just that it's newer
to me, but as long as the performance improves steadily, Java may well be
the challenge Microsoft needs for change, not court mandated crippling.
Gary
"Shmuel (Seymour J.) Metz" <nospam@acm.org> wrote in message
news:3B387768.FF5E9744@acm.org...
>
>
> Ken Garlington wrote:
>
>
> > Let's say, just hypothetically, that you've been programming since 1960.
How
> > long can you remember trends in the computing industry (which,
presumably,
> > is different from either academic computing or hobbyist programming)?
>
> Trends were also different between scientific and commercial computing.
> Centralized development was much more common in the commercial sector.
>
> > In fact, let's go further - does your memory confirm that the OS/360
> > development effort described in Brooks was fairly typical (if not
advanced)
> > for industrial computing in the early-to-mid 1960's?
>
> I remember being shocked that the S/360 didn't include any relocation
> capability. I remember that OS/360 inherited some nice features from
> IBSYS/IBJOB. Overall, my memory confirms that it was less advanced but
more
> comprehensive than what was available from other vendors. In particular,
both
> UNIVAC and Burroughs had working multiprocessors on standard lines well
before
> the 65MP or even the 9020.
>
> --
> Shmuel (Seymour J.) Metz
>
>

Re: Market pressures for more reliable software

[Roedy Green]

On Wed, 27 Jun 2001 09:41:58 GMT, "Gary Labowitz" <garyl@enter.net>
wrote or quoted :

>I'm curious what you mean by "relocation" that you were shocked that S/360
>didn't have it.

The univac 1100, the IBM 360s predecessor, had a relocation register
so you could load a ram image and start executing without having to
make any adjustments.  

The 360 used absolute addresses. To load you had to adjust all the
address references to account for where in RAM the program was loaded.
This greatly slowed down the process of getting a program started.

Exploiting relocation hardware to speed loading is still not fully
exploited even in Windows NT.


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[tmoran]

>The 360 used absolute addresses. To load you had to adjust all the
>address references to account for where in RAM the program was loaded.
>This greatly slowed down the process of getting a program started.
  IIRC in 1963 I was able to load and relocate on a CDC 1604 on
the fly as data came in from the high-speed tape drive (92 mics/word
or 46 mics/address, as I recall).  So relocation time shouldn't have
been a big problem for a 360.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

Gary Labowitz wrote:

> I'm curious what you mean by "relocation" that you were shocked that S/360
> didn't have it.

At the time the S/360 was announced, CDC, GE and UNIVAC had block relocation in
the hardware. Ferranti had paging. Burroughs had segmented virtual memory. IBM
had paging in the laboratory. And S/360? S/360 had nada.

> From the very outset the OS/360 design included a relocating
> loader, which was very advanced for its time.

You're confusing S/360 with OS/360. Fetch was software. Further, once a program
was loaded it could not be moved, despite the vain hopes of those developing VMS
(no, not that VMS.)


> Neither, BTW, did Burroughs, NCR, or Bendix.
> Univac held on much longer.

Burroughs continued selling the B2500 and B6500 lines for a considerable amount
of time. More to the point, the degree of market success tells nothing about
what technological features were present.


> As I went about learning PC's (and Apple) operating systems (including
> Win32) I was struck with the fact that much of what was the "new" thing was
> just a reimplementation of what we did on the S/360 in the mid '60's.

There we agree. The PC industry has been characterized by reinventing the wheel
and by the NIH syndrome.

--
Shmuel (Seymour J.) Metz

Re: Market pressures for more reliable software

[Gary Labowitz]

And now it's you that needs correction. Most shops in the early days were
centralized computing. And most of those were centralized development as
well. [Definition: centralized -- a single computer at a centralized
location. All computing is done on that computer. Users go physically to
that computer site and either submit jobs directly to the machine, being
given time on the machine to use it, or submit jobs to a checkpoint from
which operators submit the jobs for the user. If the site was large enough
to have several computers they were clustered in the same general area and
users selected which of the computers would be used for their individual
jobs.]

I can remember back to 1962 (when I started with IBM) but built my first
computer in 1956.
Your turn.
Gary
"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in
message news:3b366a2b$6$fuzhry$mr2ice@va.news.verio.net...
> In <YXDX6.1$MM4.254@nsw.nnrp.telstra.net>, on 06/19/2001
>    at 08:21 AM, lesbell@nospam.lesbell.com.au said:
>
> >"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> wrote:
>
>
> >I seem to be getting misunderstood for reasons I don't comprehend.
>
> You haven't been misunderstood, you've been corrected. Your knowledge
> of DP history is faulty, and you haven't paid attention to those who
> were there in the old days and told you the reality.
>
> >We
> >*used*to* have centralized computing.
>
> What you mean "we", kimosabi? As I said, it's not a question of
> misunderstanding you, it's a question of correcting you. Maybe you
> worked at a shop that had centralized computing, although I doubt it.
> Such shops were not the norm.
>
> >What I *am* saying is that we once had a centralized model and opted
> >out of it
>
> And as long as you keep saying something demonstrably false your
> conclusions remain suspect. The industry has had both decentralized
> development on centralized hardware and centralized development on
> decentralized hardware for as long as I can remember. Centralization
> of one does not, has not and will not imply centralization of the
> other.
>
> --
> -----------------------------------------------------------
>      Shmuel (Seymour J.) Metz, SysProg and JOAT
>      Atid/2
>      Team OS/2
>      Team PL/I
>
> Any unsolicited commercial junk E-mail will be subject to legal
> action.  I reserve the right to publicly post or ridicule any
> abusive E-mail.
>
> I mangled my E-mail address to foil automated spammers; reply to
> domain acm dot org user shmuel to contact me.  Do not reply to
> spamtrap@library.lspace.org
> -----------------------------------------------------------
>

Re: Market pressures for more reliable software

[Marin David Condic]

Maybe I'm just in the springtime of my senility, but that's pretty much how
I remember it and pretty much what I was trying to describe. "distributed"
computing was not around in the days of the ENIAC and vacuume tube
computing - so pretty much ipso facto, "centralized" computing existed
first. When all that existed in the entire universe were big gigundous
computers that had to be kept in hermetically sealed rooms, people didn't
have one of them sitting under their desk - so "centralized" computing
existed and "distributed" computing didn't.

Like I said, I didn't think I was making an extravagant claim here or going
against what was pretty much accepted interpretation of computing historical
facts. Since I'm not trying to say something like "The Earth Is Flat!" I'm
believing that somehow I'm miscommunicating. OTOH, if someone wants to
believe that computing only started when IBM invented the PC, then I suppose
that belief would lead one to conclude that "distributed" and "centralized"
computing have always existed side-by-side and it has never been otherwise.
I suppose there really isn't anything I can do about that belief.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Gary Labowitz" <garyl@enter.net> wrote in message
news:AkCZ6.1988$Tt6.825475@monger.newsread.com...
> And now it's you that needs correction. Most shops in the early days were
> centralized computing. And most of those were centralized development as
> well. [Definition: centralized -- a single computer at a centralized
> location. All computing is done on that computer. Users go physically to
> that computer site and either submit jobs directly to the machine, being
> given time on the machine to use it, or submit jobs to a checkpoint from
> which operators submit the jobs for the user. If the site was large enough
> to have several computers they were clustered in the same general area and
> users selected which of the computers would be used for their individual
> jobs.]
>
> I can remember back to 1962 (when I started with IBM) but built my first
> computer in 1956.
> Your turn.
> Gary
> "Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in
> message news:3b366a2b$6$fuzhry$mr2ice@va.news.verio.net...
> > In <YXDX6.1$MM4.254@nsw.nnrp.telstra.net>, on 06/19/2001
> >    at 08:21 AM, lesbell@nospam.lesbell.com.au said:
> >
> > >"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> wrote:
> >
> >
> > >I seem to be getting misunderstood for reasons I don't comprehend.
> >
> > You haven't been misunderstood, you've been corrected. Your knowledge
> > of DP history is faulty, and you haven't paid attention to those who
> > were there in the old days and told you the reality.
> >
> > >We
> > >*used*to* have centralized computing.
> >
> > What you mean "we", kimosabi? As I said, it's not a question of
> > misunderstanding you, it's a question of correcting you. Maybe you
> > worked at a shop that had centralized computing, although I doubt it.
> > Such shops were not the norm.
> >
> > >What I *am* saying is that we once had a centralized model and opted
> > >out of it
> >
> > And as long as you keep saying something demonstrably false your
> > conclusions remain suspect. The industry has had both decentralized
> > development on centralized hardware and centralized development on
> > decentralized hardware for as long as I can remember. Centralization
> > of one does not, has not and will not imply centralization of the
> > other.
> >
> > --
> > -----------------------------------------------------------
> >      Shmuel (Seymour J.) Metz, SysProg and JOAT
> >      Atid/2
> >      Team OS/2
> >      Team PL/I
> >
> > Any unsolicited commercial junk E-mail will be subject to legal
> > action.  I reserve the right to publicly post or ridicule any
> > abusive E-mail.
> >
> > I mangled my E-mail address to foil automated spammers; reply to
> > domain acm dot org user shmuel to contact me.  Do not reply to
> > spamtrap@library.lspace.org
> > -----------------------------------------------------------
> >
>
>

Re: Market pressures for more reliable software

[David C. Hoos]

It seems to me that what we have here is a semantic tempest in a teapot.

In 1958, I had an IBM 610 computer that operated in an office
environment, and certainly was not "centralized," in that any member of
the engineering staff who wished to use it in his work was free to do so.

A few years later we moved up to an IBM 1620, again in an office
environment and not "centralized."

Not until we moved up to a 360, was there any semblance of
"centralization," and this was mainly for scheduling purposes.  We still
did our own keypunching, and ran our own jobs.

----- Original Message -----
From: "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>
Newsgroups:
comp.lang.ada,comp.lang.java.programmer,comp.lang.pl1,comp.lang.vrml,comp.la
ng.java.advocacy
To: <comp.lang.ada@ada.eu.org>
Sent: Monday, June 25, 2001 9:13 AM
Subject: Re: Market pressures for more reliable software


> Maybe I'm just in the springtime of my senility, but that's pretty much
how
> I remember it and pretty much what I was trying to describe. "distributed"
> computing was not around in the days of the ENIAC and vacuume tube
> computing - so pretty much ipso facto, "centralized" computing existed
> first. When all that existed in the entire universe were big gigundous
> computers that had to be kept in hermetically sealed rooms, people didn't
> have one of them sitting under their desk - so "centralized" computing
> existed and "distributed" computing didn't.
>
> Like I said, I didn't think I was making an extravagant claim here or
going
> against what was pretty much accepted interpretation of computing
historical
> facts. Since I'm not trying to say something like "The Earth Is Flat!" I'm
> believing that somehow I'm miscommunicating. OTOH, if someone wants to
> believe that computing only started when IBM invented the PC, then I
suppose
> that belief would lead one to conclude that "distributed" and
"centralized"
> computing have always existed side-by-side and it has never been
otherwise.
> I suppose there really isn't anything I can do about that belief.
>
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> Web:      http://www.mcondic.com/
>
>
> "Gary Labowitz" <garyl@enter.net> wrote in message
> news:AkCZ6.1988$Tt6.825475@monger.newsread.com...
> > And now it's you that needs correction. Most shops in the early days
were
> > centralized computing. And most of those were centralized development as
> > well. [Definition: centralized -- a single computer at a centralized
> > location. All computing is done on that computer. Users go physically to
> > that computer site and either submit jobs directly to the machine, being
> > given time on the machine to use it, or submit jobs to a checkpoint from
> > which operators submit the jobs for the user. If the site was large
enough
> > to have several computers they were clustered in the same general area
and
> > users selected which of the computers would be used for their individual
> > jobs.]
> >
> > I can remember back to 1962 (when I started with IBM) but built my first
> > computer in 1956.
> > Your turn.
> > Gary
> > "Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote
in
> > message news:3b366a2b$6$fuzhry$mr2ice@va.news.verio.net...
> > > In <YXDX6.1$MM4.254@nsw.nnrp.telstra.net>, on 06/19/2001
> > >    at 08:21 AM, lesbell@nospam.lesbell.com.au said:
> > >
> > > >"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> wrote:
> > >
> > >
> > > >I seem to be getting misunderstood for reasons I don't comprehend.
> > >
> > > You haven't been misunderstood, you've been corrected. Your knowledge
> > > of DP history is faulty, and you haven't paid attention to those who
> > > were there in the old days and told you the reality.
> > >
> > > >We
> > > >*used*to* have centralized computing.
> > >
> > > What you mean "we", kimosabi? As I said, it's not a question of
> > > misunderstanding you, it's a question of correcting you. Maybe you
> > > worked at a shop that had centralized computing, although I doubt it.
> > > Such shops were not the norm.
> > >
> > > >What I *am* saying is that we once had a centralized model and opted
> > > >out of it
> > >
> > > And as long as you keep saying something demonstrably false your
> > > conclusions remain suspect. The industry has had both decentralized
> > > development on centralized hardware and centralized development on
> > > decentralized hardware for as long as I can remember. Centralization
> > > of one does not, has not and will not imply centralization of the
> > > other.
> > >
> > > --
> > > -----------------------------------------------------------
> > >      Shmuel (Seymour J.) Metz, SysProg and JOAT
> > >      Atid/2
> > >      Team OS/2
> > >      Team PL/I
> > >
> > > Any unsolicited commercial junk E-mail will be subject to legal
> > > action.  I reserve the right to publicly post or ridicule any
> > > abusive E-mail.
> > >
> > > I mangled my E-mail address to foil automated spammers; reply to
> > > domain acm dot org user shmuel to contact me.  Do not reply to
> > > spamtrap@library.lspace.org
> > > -----------------------------------------------------------
> > >
> >
> >
>
>
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: Market pressures for more reliable software

[Marin David Condic]

O.K. I give up. There never were centralized computer centers where people
logged on and did work on data and programs that were kept in a central
place. People always had computers on their desks and computing was always
distributed. Networks of computers existed since before the vacuume tube was
invented and were *instantly* in use the very same day that the very first
computer was turned on - even though there were no other computers to
connect to. Bill Gates is therefore proposing something brand new that the
world has never seen before. Everyone should run out and buy it now because
it will dramatically change your life in a way never before seen or heard or
even dreampt of!

Just think: For the very first time in the entire history of the universe,
you can store your data on a big disk shared by thousands of other users!
You'll be able to execute a program maintained by a team of experts that is
continually updated so that every time you execute it from its central
storage location, you automatically get the latest and greatest version!
Never before have your eyes witnessed such a monumental feat or such a huge
advancement in the field of computer science! Watch and be amazed as our
small team of highly trained technicians actually *back*up* your data on a
nightly basis so that for the first time ever, you'll be safe in the event
of a disk crash! Why, you'll be so amazed by the convenience that you'll
*instantly* scrap that antique PC on your desk in favor of Microsoft's
latest invention which the marketing guys are calling "The Teletype"
utilizing all new "Paper v1.0 (tm)" as its micro-thin display technology.
You'll be able to connect to the centralized computer from anywhere in the
world at any hour of the day or night using a device Microsoft just invented
called "The Modem".

Gosh, I'm just so glad that everyone here has disabused me of the notion
that this might have somehow sounded familiar. I've seen the light. I think
I'll get down on my knees and thank God that Bill Gates is in the world
inventing new things daily. Where do I sign up?

Now maybe I can start an argument in the other direction? :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"David C. Hoos" <david.c.hoos.sr@ada95.com> wrote in message
news:mailman.993483499.4923.comp.lang.ada@ada.eu.org...
> It seems to me that what we have here is a semantic tempest in a teapot.
>
> In 1958, I had an IBM 610 computer that operated in an office
> environment, and certainly was not "centralized," in that any member of
> the engineering staff who wished to use it in his work was free to do so.
>
> A few years later we moved up to an IBM 1620, again in an office
> environment and not "centralized."
>
> Not until we moved up to a 360, was there any semblance of
> "centralization," and this was mainly for scheduling purposes.  We still
> did our own keypunching, and ran our own jobs.
>
> ----- Original Message -----
> From: "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>
> Newsgroups:
>
comp.lang.ada,comp.lang.java.programmer,comp.lang.pl1,comp.lang.vrml,comp.la
> ng.java.advocacy
> To: <comp.lang.ada@ada.eu.org>
> Sent: Monday, June 25, 2001 9:13 AM
> Subject: Re: Market pressures for more reliable software
>
>
> > Maybe I'm just in the springtime of my senility, but that's pretty much
> how
> > I remember it and pretty much what I was trying to describe.
"distributed"
> > computing was not around in the days of the ENIAC and vacuume tube
> > computing - so pretty much ipso facto, "centralized" computing existed
> > first. When all that existed in the entire universe were big gigundous
> > computers that had to be kept in hermetically sealed rooms, people
didn't
> > have one of them sitting under their desk - so "centralized" computing
> > existed and "distributed" computing didn't.
> >
> > Like I said, I didn't think I was making an extravagant claim here or
> going
> > against what was pretty much accepted interpretation of computing
> historical
> > facts. Since I'm not trying to say something like "The Earth Is Flat!"
I'm
> > believing that somehow I'm miscommunicating. OTOH, if someone wants to
> > believe that computing only started when IBM invented the PC, then I
> suppose
> > that belief would lead one to conclude that "distributed" and
> "centralized"
> > computing have always existed side-by-side and it has never been
> otherwise.
> > I suppose there really isn't anything I can do about that belief.
> >
> > MDC
> > --
> > Marin David Condic
> > Senior Software Engineer
> > Pace Micro Technology Americas    www.pacemicro.com
> > Enabling the digital revolution
> > e-Mail:    marin.condic@pacemicro.com
> > Web:      http://www.mcondic.com/
> >
> >
> > "Gary Labowitz" <garyl@enter.net> wrote in message
> > news:AkCZ6.1988$Tt6.825475@monger.newsread.com...
> > > And now it's you that needs correction. Most shops in the early days
> were
> > > centralized computing. And most of those were centralized development
as
> > > well. [Definition: centralized -- a single computer at a centralized
> > > location. All computing is done on that computer. Users go physically
to
> > > that computer site and either submit jobs directly to the machine,
being
> > > given time on the machine to use it, or submit jobs to a checkpoint
from
> > > which operators submit the jobs for the user. If the site was large
> enough
> > > to have several computers they were clustered in the same general area
> and
> > > users selected which of the computers would be used for their
individual
> > > jobs.]
> > >
> > > I can remember back to 1962 (when I started with IBM) but built my
first
> > > computer in 1956.
> > > Your turn.
> > > Gary
> > > "Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote
> in
> > > message news:3b366a2b$6$fuzhry$mr2ice@va.news.verio.net...
> > > > In <YXDX6.1$MM4.254@nsw.nnrp.telstra.net>, on 06/19/2001
> > > >    at 08:21 AM, lesbell@nospam.lesbell.com.au said:
> > > >
> > > > >"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>
wrote:
> > > >
> > > >
> > > > >I seem to be getting misunderstood for reasons I don't comprehend.
> > > >
> > > > You haven't been misunderstood, you've been corrected. Your
knowledge
> > > > of DP history is faulty, and you haven't paid attention to those who
> > > > were there in the old days and told you the reality.
> > > >
> > > > >We
> > > > >*used*to* have centralized computing.
> > > >
> > > > What you mean "we", kimosabi? As I said, it's not a question of
> > > > misunderstanding you, it's a question of correcting you. Maybe you
> > > > worked at a shop that had centralized computing, although I doubt
it.
> > > > Such shops were not the norm.
> > > >
> > > > >What I *am* saying is that we once had a centralized model and
opted
> > > > >out of it
> > > >
> > > > And as long as you keep saying something demonstrably false your
> > > > conclusions remain suspect. The industry has had both decentralized
> > > > development on centralized hardware and centralized development on
> > > > decentralized hardware for as long as I can remember. Centralization
> > > > of one does not, has not and will not imply centralization of the
> > > > other.
> > > >
> > > > --
> > > > -----------------------------------------------------------
> > > >      Shmuel (Seymour J.) Metz, SysProg and JOAT
> > > >      Atid/2
> > > >      Team OS/2
> > > >      Team PL/I
> > > >
> > > > Any unsolicited commercial junk E-mail will be subject to legal
> > > > action.  I reserve the right to publicly post or ridicule any
> > > > abusive E-mail.
> > > >
> > > > I mangled my E-mail address to foil automated spammers; reply to
> > > > domain acm dot org user shmuel to contact me.  Do not reply to
> > > > spamtrap@library.lspace.org
> > > > -----------------------------------------------------------
> > > >
> > >
> > >
> >
> >
> > _______________________________________________
> > comp.lang.ada mailing list
> > comp.lang.ada@ada.eu.org
> > http://ada.eu.org/mailman/listinfo/comp.lang.ada
> >
>

Re: Market pressures for more reliable software

[Wes Groleau]

> Not until we moved up to a 360, was there any semblance of
> "centralization," and this was mainly for scheduling purposes.  We still
> did our own keypunching, and ran our own jobs.

While I was in high school, "OTIS" was introduced:
the "Oregon Total Information System"  This was a 360
that contained ALL public school grade records for the
whole state.  How's that for centralization?

At the same time, my algebra teacher's husband had
full control of a PDP-8 (eight-bit computer bigger
than a file cabinet!) in his nuclear physics lab.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Market pressures for more reliable software

[Al Christians]

Wes Groleau wrote:
> 
> > Not until we moved up to a 360, was there any semblance of
> > "centralization," and this was mainly for scheduling purposes.  We still
> > did our own keypunching, and ran our own jobs.
> 
> While I was in high school, "OTIS" was introduced:
> the "Oregon Total Information System"  This was a 360
> that contained ALL public school grade records for the
> whole state.  How's that for centralization?
> 
> At the same time, my algebra teacher's husband had
> full control of a PDP-8 (eight-bit computer bigger
> than a file cabinet!) in his nuclear physics lab.
> 

These things live forever.  I think that OTIS still lives.
It's not run statewide anymore, but it is run by school
districts and extended school districts covering large
areas but not many kids.  I think that the commercial 
group that was supporting OTIS has just closed up, though,
and that the districts are picking up newer alternatives.

That ought to be a good market for Ada.  OTIS demonstrates
that these systems have a very long lifecycle, which is 
what Ada was designed for.  There is also some need for
reliability.  Note that about 10,000 kids in New York went
to summer school on account of a computer error in scoring
tests, and some principals have had their careers suffer on 
account of school software errors.  And then there are all
the security worries about kids trying to hack into everything. 

Anyone know if there are any competitors in that market that
make it an unattractive proposition for product development?


Al

Re: Market pressures for more reliable software

[David Thompson]

Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote :
...
> At the same time, my algebra teacher's husband had
> full control of a PDP-8 (eight-bit computer bigger
> than a file cabinet!) in his nuclear physics lab.

The PDP-8 was a 12-bit architecture, and
bigger than a file cabinet only if you had a
very large -8 configuration (lots of peripherals
to fill up a rack) or a very small file cabinet.
Might it have been a PDP-11?  Early models
of that family (before LSI) were usually at least
one full-height 19" rack and often several,
and the primary data paths are 16-bit
it does address 8-bit bytes (in memory).

--
- David.Thompson 1 now at worldnet.att.net

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

Marin David Condic wrote:

> Maybe I'm just in the springtime of my senility, but that's pretty much how
> I remember it and pretty much what I was trying to describe. "distributed"
> computing was not around in the days of the ENIAC and vacuume tube
> computing - so pretty much ipso facto, "centralized" computing existed
> first. When all that existed in the entire universe were big gigundous
> computers that had to be kept in hermetically sealed rooms, people didn't
> have one of them sitting under their desk - so "centralized" computing
> existed and "distributed" computing didn't.

ENIAC was before my time, but I'd agree that development was probably
centralized in those days. What is in dispute is whether development was
centralized in the years or decades immediately preceding the PC. But
distributed development occurred even when the computer was centralized, even
before the 7090.

> Like I said, I didn't think I was making an extravagant claim here or going
> against what was pretty much accepted interpretation of computing historical
> facts. Since I'm not trying to say something like "The Earth Is Flat!" I'm
> believing that somehow I'm miscommunicating. OTOH, if someone wants to
> believe that computing only started when IBM invented the PC, then I suppose
> that belief would lead one to conclude that "distributed" and "centralized"
> computing have always existed side-by-side and it has never been otherwise.
> I suppose there really isn't anything I can do about that belief.

Actually, IBM didn't invent the personal computer, although it did significantly
alter the accepted architecture. IBM did push "personal computing" before there
was a noticeable personal computer industry, with such products as CALL/360 and
VSPC.

Re: Market pressures for more reliable software

[David C. Hoos]

"Shmuel (Seymour J.) Metz" <nospam@acm.org> wrote in message
news:3B3879CE.AC550F8E@acm.org...
>
<snip>
> Actually, IBM didn't invent the personal computer, although it did
significantly
> alter the accepted architecture. IBM did push "personal computing" before
there
> was a noticeable personal computer industry, with such products as
CALL/360 and
> VSPC.
And such products as the 5100 and 5110.

Re: Market pressures for more reliable software

[Al Christians]

"Shmuel (Seymour J.) Metz" wrote:
> 
> Marin David Condic wrote:
> 
> 
> Actually, IBM didn't invent the personal computer, although it did significantly
> alter the accepted architecture. IBM did push "personal computing" before there
> was a noticeable personal computer industry, with such products as CALL/360 and
> VSPC.

And there was Joss, which ran on the Johnniac.  That was an early step
toward end-user programming.

Al

Re: Market pressures for more reliable software

[Marin David Condic]

Just for the record, I did not make the statement below. Depending on just
what sort of definition one has for "Personal Computer" - crediting IBM with
its invention becomes either true or false. I believe it is accurate to say
that IBM was the first to use the words "Personal Computer" in
characterizing a computer that they manufactured (Here is sunny Boca Raton,
BTW) in their advertising. However they were not the first to manufacture a
small, inexpensive computer designed to be used primarily by a single
individual.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Al Christians" <achrist@easystreet.com> wrote in message
news:3B38975D.7BE3BDE7@easystreet.com...
> "Shmuel (Seymour J.) Metz" wrote:
> >
> > Marin David Condic wrote:
> >
> >
> > Actually, IBM didn't invent the personal computer, although it did
significantly
> > alter the accepted architecture. IBM did push "personal computing"
before there
> > was a noticeable personal computer industry, with such products as
CALL/360 and
> > VSPC.
>
> And there was Joss, which ran on the Johnniac.  That was an early step
> toward end-user programming.
>
> Al

Re: Market pressures for more reliable software

[Wes Groleau]

.... they [IBM] were not the first to manufacture a
> small, inexpensive computer designed to be used primarily by a single
> individual.

But they  did  unintentionally give that market a big boost.
Hundreds of businessmen (women, too?) were scratching their
heads in front of computer store windows, wondering whether
it was worth the risk, when the stock clerk set out something
with the IBM logo, and the decision was made.  Ironically,
engineering-wise, PC meant Piece of Crap for that model.
Only thing worse, to my knowledge, for that era was the
appropriately nicknamed Trash-80.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

RE: Market pressures for more reliable software

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Marin David Condic et al.
Texas Instruments had a better computer running the UCSD Pascal system. When
the IBM PC appeared, TI dropped their good design and built an imperfect
clone. I believe Compac was started by some disgruntled TI engineers, who
wanted to build a proper clone. Altair, Sphere, and I believe Apple came
before the IBM PC. Amusingly, IBM had a scientific PC based on the Intel
Multibus and a Motorola processor. This scientific PC, which was
subsequently killed, was a better design than the Intel powered PC.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Marin David Condic
Sent: Tuesday, June 26, 2001 8:00 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Market pressures for more reliable software


Just for the record, I did not make the statement below. Depending on just
what sort of definition one has for "Personal Computer" - crediting IBM with
its invention becomes either true or false. I believe it is accurate to say
that IBM was the first to use the words "Personal Computer" in
characterizing a computer that they manufactured (Here is sunny Boca Raton,
BTW) in their advertising. However they were not the first to manufacture a
small, inexpensive computer designed to be used primarily by a single
individual.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Al Christians" <achrist@easystreet.com> wrote in message
news:3B38975D.7BE3BDE7@easystreet.com...
> "Shmuel (Seymour J.) Metz" wrote:
> >
> > Marin David Condic wrote:
> >
> >
> > Actually, IBM didn't invent the personal computer, although it did
significantly
> > alter the accepted architecture. IBM did push "personal computing"
before there
> > was a noticeable personal computer industry, with such products as
CALL/360 and
> > VSPC.
>
> And there was Joss, which ran on the Johnniac.  That was an early step
> toward end-user programming.
>
> Al

Re: Market pressures for more reliable software

[Marin David Condic]

Well, there were certainly a lot of computers before the IBM-PC. I seem to
recall that it was IBM who coined the phrase "Personal Computer" - prior to
that people called them "home computers" or "microcomputers" or a variety of
other terminology. If the name is what's important, then it would seem that
IBM "invented" the first "PC". If the architecture is what's important,
again IBM wins by simple definition - they designed the architecture that
everyone else followed. If its the concept of a "small computer for personal
use" that's important, then we have a whole slew of possible winners. It's
all just a matter of definition... :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Robert C. Leif, Ph.D." <rleif@rleif.com> wrote in message
news:mailman.993612920.5656.comp.lang.ada@ada.eu.org...
> From: Bob Leif
> To: Marin David Condic et al.
> Texas Instruments had a better computer running the UCSD Pascal system.
When
> the IBM PC appeared, TI dropped their good design and built an imperfect
> clone. I believe Compac was started by some disgruntled TI engineers, who
> wanted to build a proper clone. Altair, Sphere, and I believe Apple came
> before the IBM PC. Amusingly, IBM had a scientific PC based on the Intel
> Multibus and a Motorola processor. This scientific PC, which was
> subsequently killed, was a better design than the Intel powered PC.
>

Re: Market pressures for more reliable software

[tmoran]

>And there was Joss, which ran on the Johnniac.  That was an early step
>toward end-user programming.
  Toward the other end of the time-scale, T/Maker (an early competitor to
Visicalc) came from a programmer in a bank MIS department who got sick
of requests for simple tabular data reports that came to the MIS
department and spent months getting approved and assigned and then
hours getting implemented.  So that style still existed in the early '80s.

Re: Market pressures for more reliable software

[Roedy Green]

On Tue, 26 Jun 2001 08:02:24 -0400, "Shmuel (Seymour J.) Metz"
<nospam@acm.org> wrote or quoted :

>
>distributed development occurred even when the computer was centralized, even
>before the 7090.
 
That was true at universities, but not true at utilities.  There was a
computer department that handled all programming.

For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

Roedy Green wrote:

> That was true at universities, but not true at utilities.  There was a
> computer department that handled all programming.

There were a number of market segments. The financial sector tended more to
centralized development, the scientific and engineering segments more to
decentralized development. As costs came down, there was also movement towards
departmental mainframes lined with NJE.


--
Shmuel (Seymour J.) Metz

Re: Market pressures for more reliable software

[Roedy Green]

On Thu, 28 Jun 2001 07:50:51 -0400, "Shmuel (Seymour J.) Metz"
<nospam@acm.org> wrote or quoted :

>As costs came down, there was also movement towards
>departmental mainframes lined with NJE.

At the utilities I am familiar with that is what happened. Engineering
groups in the 80s went for minis, e.g. Vax, Prime, Data General, that
were easier to program for engineering.  There were great political
battles to keep everything in the IBM camp under central control.

I learned about the power of politics.  The entire evaluation and
implementation team was "released" after we picked the "wrong"
computer (Burroughs instead of IBM) for a new gas project to track
where all the pipes were in the ground.  Released means you are
effectively fired, but you are still on salary, free to roam the
company seeking something useful to do.


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

Roedy Green wrote:

> That was true at universities, but not true at utilities.  There was a
> computer department that handled all programming.

There were a number of different market segments, and practices differed. The
financial sector was more prone to centralized development and the scientific and
engineering sectors were more prone to decentralized development. Then there were
departmental mainframes linked by NJE, once prices came down.

Re: Market pressures for more reliable software

[Lao Xiao Hai]

"Shmuel (Seymour J.) Metz" wrote:

> ENIAC was before my time, but I'd agree that development was probably
> centralized in those days. What is in dispute is whether development was
> centralized in the years or decades immediately preceding the PC. But
> distributed development occurred even when the computer was centralized, even
> before the 7090.

Perhaps.  But, for most organizations, emphasis on the word most, computing
resources within an organization was under the centralized managment of
one central authority.  Moreover, most of the computing was located in one
place.  It is true that some very large corporations had computers distributed
across their divisions, but that was a luxury not affordable by most of industry.

This centralization, during the 70's and through the mid-80's even extended to
collections of companies.   Ever hear of a service bureau.   In service bureaus
we centralized the computing for vertical markets as well as for such things
as payroll, general accounting, and other business applications.   There was
very little distributed development before the advent of, first the minicomputer,
and later the microcomputer.

Networks were still a mystery for most people.   Programmers were busy
grinding out programs in COBOL.   Compilers needed large memory spaces
and operating systems and these were hosted on million dollar plus machines,
making it too expensive to distribute them all over the place.  The exceptions
were the Fords, Chryslers, and other industrial giants with money to burn.

I spent a lot of years consulting to, developing software for, and cleaning up
after these centralized computing facilities.

Things are a lot more distributed now.   Frankly, as I look at the quality of some
of the software, I am not sure that can be classified as progress.

Richard Riehle

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

Lao Xiao Hai wrote:"Perhaps.  But, for most organizations, emphasis on the word most,
computing

> resources within an organization was under the centralized managment of
> one central authority.  Moreover, most of the computing was located in one
> place.  It is true that some very large corporations had computers distributed
> across their divisions, but that was a luxury not affordable by most of industry.

You're missing the point the centralized equipment does not imply centralized use of
the equipment.


> This centralization, during the 70's and through the mid-80's even extended to
> collections of companies.   Ever hear of a service bureau.

ROTF,LMAO! Heard of them? I've worked for them. I've never heard of a service bureau
where the programming was centralized; the norm was that the customer did his own
programming.


> Networks were still a mystery for most people.

Most people didn't work with computers. Dialup access was common in the late '60s.


> Programmers were busy
> grinding out programs in COBOL.

I take it that you never had anything to do with scientific computing?


> Compilers needed large memory spaces
> and operating systems and these were hosted on million dollar plus machines,

Yeah, like the 650, 1401, 1620 and 1130? Maybe they weren't glamorous, and they were
too small to be of interest to service bureaus except for the odd 1401 used as c/t and
t/p, but there were a lot of them.

--
Shmuel (Seymour J.) Metz

Re: Market pressures for more reliable software

[Lao Xiao Hai]

"Shmuel (Seymour J.) Metz" wrote:

> Lao Xiao Hai wrote:"Perhaps.  But, for most organizations, emphasis on the word most,
> computing
>
> > resources within an organization was under the centralized managment of
> > one central authority.  Moreover, most of the computing was located in one
> > place.  It is true that some very large corporations had computers distributed
> > across their divisions, but that was a luxury not affordable by most of industry.
>
> You're missing the point the centralized equipment does not imply centralized use of
> the equipment.

I must be missing the point.    What was not centralized?   Programming was pretty
much centralized and under the control of a data processing manager.  Computers
were pretty much centralized, and there weren't that many that could drive remote
terminals really well.  Most of the data processing was in batch mode.

> > This centralization, during the 70's and through the mid-80's even extended to
> > collections of companies.   Ever hear of a service bureau.
>
> ROTF,LMAO! Heard of them? I've worked for them. I've never heard of a service bureau
> where the programming was centralized; the norm was that the customer did his own
> programming.

That is not how I remember it.  Most of the programs I recall were written by the
programmers
at the service bureau.  Some were packages purchased from elsewhere.   It was the rare
customer who had programming resources on which they could rely for their own software.
Usually, this task was contracted by the programmers within the service bureau.  Later,
there
were independent contractors who could do this for hire by the service bureau customer.

> > Networks were still a mystery for most people.
>
> Most people didn't work with computers. Dialup access was common in the late '60s.

Not that common.  And it was expensive.   We used it quite sparingly in most places.

> > Programmers were busy
> > grinding out programs in COBOL.
>
> I take it that you never had anything to do with scientific computing?

I have done both.   Certainly a lot of scientific computing was done using remote
computers.   However, I recall quite vividly those sites that had their own IBM 1130
and did their own Fortran programming.   I spent many late night hours writing Fortran II
and debugging on the 1130.

> > Compilers needed large memory spaces
> > and operating systems and these were hosted on million dollar plus machines,
>
> Yeah, like the 650, 1401, 1620 and 1130? Maybe they weren't glamorous, and they were
> too small to be of interest to service bureaus except for the odd 1401 used as c/t and
> t/p, but there were a lot of them.

The IBM 1401 was the workhorse of industry for a long time.   It was the first machine
I learned to program.   It was not cheap.   In the companies where I worked on that
computer, we usually had more than one, just to get the work done.  There were almost
no programmers from outside the company.   The other computers you named were
certainly small, but they were also under the control/guidance of the MIS manager
at many companies.   Oh, and you forgot one of my personal favorites, the CDC
160 series.   The IBM System 360 series came along in 1964 and, along with its
clones and cousins, did required lots of memory, lots of dollars, and lots of
programming talent.  Most of those machines were still centralized up through
the mid-1970's when the minicomputers became common.   Even those minicomputers
were pretty much centralized in the small businesses that leased them.

There was some decentralization.   But I don't recall it being as widespread as you do.
This is particularly true of data processing, which was almost always centralized in
those early days.   It was certainly not decentralized in the way it is today.    Even so,

I am noticing that some very large organizations are moving back to a more centralized
computing authority.    User developed applications  (UDA's) are getting out-of-hand
and instead of saving money, are costing money.     Worse, many of the amateur
programmers who create UDA's are failing to build in the kinds of error control and
security one would expect of more rigorously defined software.   This is creating
vulnerabilities that would not have been tolerated in the centralized era.

Richard Riehle

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

Lao Xiao Hai wrote:

> I must be missing the point.    What was not centralized?

As I said multiple times, programming.


> Programming was pretty
> much centralized and under the control of a data processing manager.  Computers
> were pretty much centralized, and there weren't that many that could drive remote
> terminals really well.

Well enough. Can you say RAX? QUICKTRAN? CRBE? CRJE? RJE? SGJP? ATS? HASP Multileaving? And
that's just IBM supplied. There were also ALPHA, ROSCOE (nee WRAP) and Wylbur on S/360, and
others on non-IBM hardware. There was enough time sharing and remote batch to drive a market
in plug-compatible terminals and modems.

> Most of the data processing was in batch mode.

Which doesn't make it centralized.


> That is not how I remember it.

Clearly. Either your experience was limited or your memory is faulty.



> Most of the programs I recall were written by the
> programmers
> at the service bureau.  Some were packages purchased from elsewhere.   It was the rare
> customer who had programming resources on which they could rely for their own software.

By the 70s most service bureaus were offering remote access. Ever wonder why?


> Not that common.

Common enough to drive a market in brand X clones of terminals and modems, e.g., Cope 45 for
remote batch, Vadic modems.


> And it was expensive.

TI 700s were dirt cheap in the 70s and 80s, as were acoustic couplers.


> I have done both.   Certainly a lot of scientific computing was done using remote
> computers.   However, I recall quite vividly those sites that had their own IBM 1130
> and did their own Fortran programming.   I spent many late night hours writing Fortran II
> and debugging on the 1130.

And how many of those 1130s cost $150,000? To say nothing of the fact that a lot of them were
submitting jobs to larger machines.


> The IBM 1401 was the workhorse of industry for a long time.

And cost nowhere near $150,000.


> Oh, and you forgot one of my personal favorites, the CDC
> 160 series.

I didn't forget it, any more than I forgot LGP or RCA; I omitted it because I was
concentrating on the IBM marketplace.

> The IBM System 360 series came along in 1964 and, along with its
> clones and cousins, did required lots of memory, lots of dollars, and lots of
> programming talent.

The S/360 may have required lots of memory, but the most it would take was 64K. The 360/20 was
even smaller.


> I am noticing that some very large organizations are moving back to a more centralized
> computing authority.    User developed applications  (UDA's) are getting out-of-hand
> and instead of saving money, are costing money.     Worse, many of the amateur
> programmers who create UDA's are failing to build in the kinds of error control and
> security one would expect of more rigorously defined software.   This is creating
> vulnerabilities that would not have been tolerated in the centralized era.

Those shops that were centralized in the old days had their own horror stories. Things like
configuration management and backups were often slipshod, if they existed at all. Some of the
decentralized shops had their act together better than some of the centralized shops.

--
Shmuel (Seymour J.) Metz

Re: Market pressures for more reliable software

[Phil Robyn]

"Shmuel (Seymour J.) Metz" wrote:

> <<<snip>>>
> Well enough. Can you say RAX? QUICKTRAN? CRBE? CRJE? RJE? SGJP? ATS? HASP Multileaving? And
> that's just IBM supplied. There were also ALPHA, ROSCOE (nee WRAP) and Wylbur on S/360

I'm still using Wylbur (the PC version) on WinNT!!!!

> , and
> others on non-IBM hardware. There was enough time sharing and remote batch to drive a market
> in plug-compatible terminals and modems.
>
> <<<snip>>>

--
Phil Robyn
Univ. of California, Berkeley

u n z i p    m y    a d d r e s s    t o    s e n d    e - m a i l

Re: Market pressures for more reliable software

[Gary Labowitz]

Ah, Universities! Seat of knowledge! Seat of learning! Seat of being
out-of-date in computer technology!
("... Be not the last to lay the old aside.")

"Phil Robyn" <probyn@zipuclink.berkeley.edu> wrote in message
news:3B4383D3.49C13CED@zipuclink.berkeley.edu...
> "Shmuel (Seymour J.) Metz" wrote:
>
<<snip>>
> I'm still using Wylbur (the PC version) on WinNT!!!!
 <<<snip>>>
>
> --
> Phil Robyn
> Univ. of California, Berkeley
>
> u n z i p    m y    a d d r e s s    t o    s e n d    e - m a i l
>
>

Re: Market pressures for more reliable software

[Phil Robyn]

Gary Labowitz wrote:

> Ah, Universities! Seat of knowledge! Seat of learning! Seat of being
> out-of-date in computer technology!
> ("... Be not the last to lay the old aside.")
>
> "Phil Robyn" <probyn@zipuclink.berkeley.edu> wrote in message
> news:3B4383D3.49C13CED@zipuclink.berkeley.edu...
> > "Shmuel (Seymour J.) Metz" wrote:
> >
> <<snip>>
> > I'm still using Wylbur (the PC version) on WinNT!!!!
>  <<<snip>>>
> >
>

Don't knock it if you haven't tried it....  Wylbur is still head and
shoulders above all other batch command interpreters.  Even
Windows Scripting Host still cannot put up a screen with multiple
fields for user input ....

--
Phil Robyn
Univ. of California, Berkeley

u n z i p    m y    a d d r e s s    t o    s e n d    e - m a i l

Re: Market pressures for more reliable software

[Gary Labowitz]

This is getting ridiculous. You are SO hoping that computing and programming
were not centralized that you skip an entrie generation.
When most people talk about early days, they mean when computers actually
came into the marketplace and were large centralized systems. Certainly
programmers could be stationed anywhere. But terminal systems (starting with
the various 1050-type systems) weren't available in the "early days."
Actually, I remember the introduction of the 1050 as a big deal (about 1963
or so, maybe a little later). To get programming into the machine it first
had to be keypunched, and that was almost always "centralized." You sent
your coding sheets to the center to be keypunched. Some of us would go there
ourselves and do our own keypunching (those that typed). On the Univac-I we
went to the computer and used the console keypunch.
Anyway, the later systems developed the RJE-type systems, which
decentralized the point at which program streams could be entered and
printed. They still connected to centralized processing, however. Since all
the terminals were dumb, there was only decentralized job entry and
printing.
The real point is: so what? So you said "in the early days we had
decentralized computing" and were wrong.
Live with it.
Let's get on with today's problems.
Gary
"Shmuel (Seymour J.) Metz" <nospam@acm.org> wrote in message
news:3B432AD8.3828FB9@acm.org...
>
>
> Lao Xiao Hai wrote:
>
> > I must be missing the point.    What was not centralized?
>
> As I said multiple times, programming.
>
>
> > Programming was pretty
> > much centralized and under the control of a data processing manager.
Computers
> > were pretty much centralized, and there weren't that many that could
drive remote
> > terminals really well.
>
> Well enough. Can you say RAX? QUICKTRAN? CRBE? CRJE? RJE? SGJP? ATS? HASP
Multileaving? And
> that's just IBM supplied. There were also ALPHA, ROSCOE (nee WRAP) and
Wylbur on S/360, and
> others on non-IBM hardware. There was enough time sharing and remote batch
to drive a market
> in plug-compatible terminals and modems.
>
> > Most of the data processing was in batch mode.
>
> Which doesn't make it centralized.
>
>
> > That is not how I remember it.
>
> Clearly. Either your experience was limited or your memory is faulty.
>
>
>
> > Most of the programs I recall were written by the
> > programmers
> > at the service bureau.  Some were packages purchased from elsewhere.
It was the rare
> > customer who had programming resources on which they could rely for
their own software.
>
> By the 70s most service bureaus were offering remote access. Ever wonder
why?
>
>
> > Not that common.
>
> Common enough to drive a market in brand X clones of terminals and modems,
e.g., Cope 45 for
> remote batch, Vadic modems.
>
>
> > And it was expensive.
>
> TI 700s were dirt cheap in the 70s and 80s, as were acoustic couplers.
>
>
> > I have done both.   Certainly a lot of scientific computing was done
using remote
> > computers.   However, I recall quite vividly those sites that had their
own IBM 1130
> > and did their own Fortran programming.   I spent many late night hours
writing Fortran II
> > and debugging on the 1130.
>
> And how many of those 1130s cost $150,000? To say nothing of the fact that
a lot of them were
> submitting jobs to larger machines.
>
>
> > The IBM 1401 was the workhorse of industry for a long time.
>
> And cost nowhere near $150,000.
>
>
> > Oh, and you forgot one of my personal favorites, the CDC
> > 160 series.
>
> I didn't forget it, any more than I forgot LGP or RCA; I omitted it
because I was
> concentrating on the IBM marketplace.
>
> > The IBM System 360 series came along in 1964 and, along with its
> > clones and cousins, did required lots of memory, lots of dollars, and
lots of
> > programming talent.
>
> The S/360 may have required lots of memory, but the most it would take was
64K. The 360/20 was
> even smaller.
>
>
> > I am noticing that some very large organizations are moving back to a
more centralized
> > computing authority.    User developed applications  (UDA's) are getting
out-of-hand
> > and instead of saving money, are costing money.     Worse, many of the
amateur
> > programmers who create UDA's are failing to build in the kinds of error
control and
> > security one would expect of more rigorously defined software.   This is
creating
> > vulnerabilities that would not have been tolerated in the centralized
era.
>
> Those shops that were centralized in the old days had their own horror
stories. Things like
> configuration management and backups were often slipshod, if they existed
at all. Some of the
> decentralized shops had their act together better than some of the
centralized shops.
>
> --
> Shmuel (Seymour J.) Metz
>
>

Re: Market pressures for more reliable software

[Marin David Condic]

You're wasting your breath. Sometimes people have such a strong need to be
right that they'll ignore all the reasoning and evidence to the contrary -
convoluting logic, redefining terminology, etc.. Often the original point is
totally forgotten in defending a position that isn't even related to it.

Move on to more productive concerns.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Gary Labowitz" <garyl@enter.net> wrote in message
news:zWX07.100$9d.9473@newshog.newsread.com...
> This is getting ridiculous. You are SO hoping that computing and
programming
> were not centralized that you skip an entrie generation.
> When most people talk about early days, they mean when computers actually
> came into the marketplace and were large centralized systems. Certainly
> programmers could be stationed anywhere. But terminal systems (starting
with
> the various 1050-type systems) weren't available in the "early days."
> Actually, I remember the introduction of the 1050 as a big deal (about
1963
> or so, maybe a little later). To get programming into the machine it first
> had to be keypunched, and that was almost always "centralized." You sent
> your coding sheets to the center to be keypunched. Some of us would go
there
> ourselves and do our own keypunching (those that typed). On the Univac-I
we
> went to the computer and used the console keypunch.
> Anyway, the later systems developed the RJE-type systems, which
> decentralized the point at which program streams could be entered and
> printed. They still connected to centralized processing, however. Since
all
> the terminals were dumb, there was only decentralized job entry and
> printing.
> The real point is: so what? So you said "in the early days we had
> decentralized computing" and were wrong.
> Live with it.
> Let's get on with today's problems.
> Gary
> "Shmuel (Seymour J.) Metz" <nospam@acm.org> wrote in message
> news:3B432AD8.3828FB9@acm.org...
> >
> >
> > Lao Xiao Hai wrote:
> >
> > > I must be missing the point.    What was not centralized?
> >
> > As I said multiple times, programming.
> >
> >
> > > Programming was pretty
> > > much centralized and under the control of a data processing manager.
> Computers
> > > were pretty much centralized, and there weren't that many that could
> drive remote
> > > terminals really well.
> >
> > Well enough. Can you say RAX? QUICKTRAN? CRBE? CRJE? RJE? SGJP? ATS?
HASP
> Multileaving? And
> > that's just IBM supplied. There were also ALPHA, ROSCOE (nee WRAP) and
> Wylbur on S/360, and
> > others on non-IBM hardware. There was enough time sharing and remote
batch
> to drive a market
> > in plug-compatible terminals and modems.
> >
> > > Most of the data processing was in batch mode.
> >
> > Which doesn't make it centralized.
> >
> >
> > > That is not how I remember it.
> >
> > Clearly. Either your experience was limited or your memory is faulty.
> >
> >
> >
> > > Most of the programs I recall were written by the
> > > programmers
> > > at the service bureau.  Some were packages purchased from elsewhere.
> It was the rare
> > > customer who had programming resources on which they could rely for
> their own software.
> >
> > By the 70s most service bureaus were offering remote access. Ever wonder
> why?
> >
> >
> > > Not that common.
> >
> > Common enough to drive a market in brand X clones of terminals and
modems,
> e.g., Cope 45 for
> > remote batch, Vadic modems.
> >
> >
> > > And it was expensive.
> >
> > TI 700s were dirt cheap in the 70s and 80s, as were acoustic couplers.
> >
> >
> > > I have done both.   Certainly a lot of scientific computing was done
> using remote
> > > computers.   However, I recall quite vividly those sites that had
their
> own IBM 1130
> > > and did their own Fortran programming.   I spent many late night hours
> writing Fortran II
> > > and debugging on the 1130.
> >
> > And how many of those 1130s cost $150,000? To say nothing of the fact
that
> a lot of them were
> > submitting jobs to larger machines.
> >
> >
> > > The IBM 1401 was the workhorse of industry for a long time.
> >
> > And cost nowhere near $150,000.
> >
> >
> > > Oh, and you forgot one of my personal favorites, the CDC
> > > 160 series.
> >
> > I didn't forget it, any more than I forgot LGP or RCA; I omitted it
> because I was
> > concentrating on the IBM marketplace.
> >
> > > The IBM System 360 series came along in 1964 and, along with its
> > > clones and cousins, did required lots of memory, lots of dollars, and
> lots of
> > > programming talent.
> >
> > The S/360 may have required lots of memory, but the most it would take
was
> 64K. The 360/20 was
> > even smaller.
> >
> >
> > > I am noticing that some very large organizations are moving back to a
> more centralized
> > > computing authority.    User developed applications  (UDA's) are
getting
> out-of-hand
> > > and instead of saving money, are costing money.     Worse, many of the
> amateur
> > > programmers who create UDA's are failing to build in the kinds of
error
> control and
> > > security one would expect of more rigorously defined software.   This
is
> creating
> > > vulnerabilities that would not have been tolerated in the centralized
> era.
> >
> > Those shops that were centralized in the old days had their own horror
> stories. Things like
> > configuration management and backups were often slipshod, if they
existed
> at all. Some of the
> > decentralized shops had their act together better than some of the
> centralized shops.
> >
> > --
> > Shmuel (Seymour J.) Metz
> >
> >
>
>

Re: Market pressures for more reliable software

[Ken Garlington]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> wrote in
message news:9i1q0r$324$1@nh.pace.co.uk...
: You're wasting your breath. Sometimes people have such a strong need to be
: right that they'll ignore all the reasoning and evidence to the contrary -
: convoluting logic, redefining terminology, etc.. Often the original point
is
: totally forgotten in defending a position that isn't even related to it.
:
: Move on to more productive concerns.
:
: MDC

If I understand the argument right, the proposed definition of
"decentralized programming" is "the programmer did not physically stand at
the CPU while working." By that definition, there *was* very little
centralized programming. Even when I had to submit batch cards to an
operator, who ran them through a reader standing next to the machine, I may
have punched the cards myself on a remote keypunch. Even when I had to have
someone sitting in the same room as the CPU punch the cards, I usually wrote
the contents down at my desk via card layout sheets. Even when I had to
physically key in programs at the console, I at least wrote flowcharts at my
desk. So, for the given definition, I suppose the argument is technically
true.

However, if you consider the environment described by Brooks as "centralized
programming," there was huge bunches of that when I got into the business,
both in academia and commercial worlds. Anyone who would claim that the
existence of HASP/JES (yay Houston!) significantly affected that model
didn't work in the places where I worked (which had both, but still followed
the Brooks model). The technology may have existed for large-scale
"distributed" (in the sense of time-sharing, significant distance from the
host, etc.), but a lot of organizations in the 70s and even 80s used a
tightly controlled batch job scheduling approach to manage assets.

To this day, if anyone says "OPTCD=Q" to me, I vow to hunt them down and
kill them.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

Ken Garlington wrote:

> If I understand the argument right, the proposed definition of
> "decentralized programming" is "the programmer did not physically stand at
> the CPU while working."

That might be Condic's definition; it certainly isn't mine. I'm referring to
such <dws>unimportant</dws> matters as analysis, design, coding, documentation,
configuration control, debugging and resource allocation.


> However, if you consider the environment described by Brooks as "centralized
> programming," there was huge bunches of that when I got into the business,
> both in academia and commercial worlds. Anyone who would claim that the
> existence of HASP/JES (yay Houston!) significantly affected that model
> didn't work in the places where I worked (which had both, but still followed
> the Brooks model). The technology may have existed for large-scale
> "distributed" (in the sense of time-sharing, significant distance from the
> host, etc.), but a lot of organizations in the 70s and even 80s used a
> tightly controlled batch job scheduling approach to manage assets.

I have no doubt that there were organizations where development was centralized.
I never worked in one even though I've been programming since 1960 and worked
for a hardware vendor, and only once did I work for a company that had a
customer with centralized development. I've said repeatedly that different
market sectors tended to have different organizations, but Condic et al seem to
prefer rebutting things that I didn't say instead of addressing what I did say.

> To this day, if anyone says "OPTCD=Q" to me, I vow to hunt them down and
> kill them.

Why? Kill the people that developed the translate tables instead.

--
Shmuel (Seymour J.) Metz

Re: Market pressures for more reliable software

[Ken Garlington]

"Shmuel (Seymour J.) Metz" <nospam@acm.org> wrote in message
news:3B4648A3.BECC1FE8@acm.org...
:
: Ken Garlington wrote:
:
: > If I understand the argument right, the proposed definition of
: > "decentralized programming" is "the programmer did not physically stand
at
: > the CPU while working."
:
: That might be Condic's definition; it certainly isn't mine. I'm referring
to
: such <dws>unimportant</dws> matters as analysis, design, coding,
documentation,
: configuration control, debugging and resource allocation.

Oddly enough, this is precisely the definition I *thought* you were using.
This definition, of course, means that there has never been truly
centralized programming, anywhere - even before the advent of computers -
for any organization of more than one or two people. (See the part of my
discussion that was snipped.) Sort of takes all of the meaning out of the
words "decentralized" and "centralized," doesn't it? Personally, I prefer my
words to have meaning...

: > However, if you consider the environment described by Brooks as
"centralized
: > programming," there was huge bunches of that when I got into the
business,
: > both in academia and commercial worlds. Anyone who would claim that the
: > existence of HASP/JES (yay Houston!) significantly affected that model
: > didn't work in the places where I worked (which had both, but still
followed
: > the Brooks model). The technology may have existed for large-scale
: > "distributed" (in the sense of time-sharing, significant distance from
the
: > host, etc.), but a lot of organizations in the 70s and even 80s used a
: > tightly controlled batch job scheduling approach to manage assets.
:
: I have no doubt that there were organizations where development was
centralized.
: I never worked in one even though I've been programming since 1960 and
worked
: for a hardware vendor, and only once did I work for a company that had a
: customer with centralized development.

Brooks describes the S/360 OS development environment in "Silver Bullet."
IIRC, that was an IBM product. Wasn't IBM a "hardware vendor" back then? (I
think they even had a pretty good market share :)

Those who worked *directly* for organizations developing business
application software might have a different perspective than those who
developed the hardware on which those machines operated.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

Ken Garlington wrote:

> "Shmuel (Seymour J.) Metz" <nospam@acm.org> wrote in message
> news:3B4648A3.BECC1FE8@acm.org...
> :
> : Ken Garlington wrote:
> :
> : > If I understand the argument right, the proposed definition of
> : > "decentralized programming" is "the programmer did not physically stand
> at
> : > the CPU while working."
> :
> : That might be Condic's definition; it certainly isn't mine. I'm referring
> to
> : such <dws>unimportant</dws> matters as analysis, design, coding,
> documentation,
> : configuration control, debugging and resource allocation.
>
> Oddly enough, this is precisely the definition I *thought* you were using.
> This definition, of course, means that there has never been truly
> centralized programming, anywhere - even before the advent of computers -
> for any organization of more than one or two people. (See the part of my
> discussion that was snipped.) Sort of takes all of the meaning out of the
> words "decentralized" and "centralized," doesn't it? Personally, I prefer my
> words to have meaning...

ROTF,LMAO!

There's never been truly decentralized analysis? There's never been truly
decentralized design? There's never been truly decentralized coding? There's
never been truly decentralized documentation? There's never been truly
decentralized configuration control? There's never been truly decentralized
resource allocation? Maybe in an anthill there isn't, but in any human
organization there certainly is.

If you want your words to have meaning, then you should invest some thought in
them before setting finger to keyboard.


> Brooks describes the S/360 OS development environment in "Silver Bullet."
> IIRC, that was an IBM product. Wasn't IBM a "hardware vendor" back then? (I
> think they even had a pretty good market share :)

Please learn the difference between an existential quantifier and a universal
quantifier. Although if George Mealy is to believe things weren't as well
controlled at IBM as they ought to have been, I never made any claims about how
IBM was run.

> Those who worked *directly* for organizations developing business
> application software might have a different perspective than those who
> developed the hardware on which those machines operated.

I've worked for both. Most of my experience has been on the customer side.

Re: Market pressures for more reliable software

[Ken Garlington]

"Shmuel (Seymour J.) Metz" <nospam@acm.org> wrote in message
news:3B47CB75.234C0543@acm.org...
:
:
: Ken Garlington wrote:
:
: > "Shmuel (Seymour J.) Metz" <nospam@acm.org> wrote in message
: > news:3B4648A3.BECC1FE8@acm.org...
: > :
: > : Ken Garlington wrote:
: > :
: > : > If I understand the argument right, the proposed definition of
: > : > "decentralized programming" is "the programmer did not physically
stand
: > at
: > : > the CPU while working."
: > :
: > : That might be Condic's definition; it certainly isn't mine. I'm
referring
: > to
: > : such <dws>unimportant</dws> matters as analysis, design, coding,
: > documentation,
: > : configuration control, debugging and resource allocation.
: >
: > Oddly enough, this is precisely the definition I *thought* you were
using.
: > This definition, of course, means that there has never been truly
: > centralized programming, anywhere - even before the advent of
computers -
: > for any organization of more than one or two people. (See the part of my
: > discussion that was snipped.) Sort of takes all of the meaning out of
the
: > words "decentralized" and "centralized," doesn't it? Personally, I
prefer my
: > words to have meaning...
:
: ROTF,LMAO!
:
: There's never been truly decentralized analysis? There's never been truly
: decentralized design? There's never been truly decentralized coding?
There's
: never been truly decentralized documentation? There's never been truly
: decentralized configuration control? There's never been truly
decentralized
: resource allocation? Maybe in an anthill there isn't, but in any human
: organization there certainly is.
:
: If you want your words to have meaning, then you should invest some
thought in
: them before setting finger to keyboard.

Errr... hello? Note that I am saying that *your definition* of decentralized
programming would lead one to the exact ridiculous conclusion that you take
so much care in ridiculing. I quote from my prior statement: "This
definition, of course, means..."

I'm glad that we agree that defining "decentalized" in the manner you appear
to espouse is silly, since then there would then be no possible chance to
have a "centralized" environment. Perhaps you could refocus your energy on a
better definition - one that would not lead to such an illogical conclusion.

I find your last statement satisfyingly ironic.

: > Brooks describes the S/360 OS development environment in "Silver
Bullet."
: > IIRC, that was an IBM product. Wasn't IBM a "hardware vendor" back then?
(I
: > think they even had a pretty good market share :)
:
: Please learn the difference between an existential quantifier and a
universal
: quantifier. Although if George Mealy is to believe things weren't as well
: controlled at IBM as they ought to have been, I never made any claims
about how
: IBM was run.

Actually, I made an A in my logic course. How did you do in your debate
course?

As I said below, I do not believe the experience described by Brooks is
atypical. Most respondents to this thread agree. Therefore, if we are to
build a case on which is position is merely based on an isolated anecdote,
and which represented the "usual" state of affairs, the weight of evidence
appears to be on my side.

: > Those who worked *directly* for organizations developing business
: > application software might have a different perspective than those who
: > developed the hardware on which those machines operated.
:
: I've worked for both. Most of my experience has been on the customer side.

So, you experience on the customer side indicates that the Brooks
description is atypical? Interesting. Perhaps you could justify such a
belief with some examples from your extensive business applications
development resume.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <eZq47.410$rt2.150095027@newssvr11.news.prodigy.com>, on 07/16/2001
   at 12:56 AM, "Ken Garlington" <Ken.Garlington@computer.org> said:

>Errr... hello? Note that I am saying that *your definition* of
>decentralized programming would lead one to the exact ridiculous
>conclusion that you take so much care in ridiculing. 

I noted that you said that; I also noted that your claim was bogus.

>I'm glad that we agree that defining "decentalized" in the manner
>you appear to espouse is silly, since then there would then be no
>possible chance to have a "centralized" environment. 

Really? No chance of having centralized control over programming, etc?
It's not only possible, it's been done, quite often. My claim was that
it was done only in specific contexts rather than as an industry norm.

However, now I'm quite puzzled at what position you are trying to
defend. JUst what is it that you claim was universally centralized
prior to the PC, and by what definition, since you deny that
cetralization of the obvious is possible?

>Actually, I made an A in my logic course.

Then you must have forgotten quite a bit. Either that, or you are
deliberate refraining from logic.

>How did you do in your debate course?

Ah, so you have decided that winning a debate is more important than
being correct?

>So, you experience on the customer side indicates that the Brooks
>description is atypical?

My experience on the customer side indicates that there is massive
variation in management style. I don't recall Brooks denying that.
Brooks was describing how things were at IBM, or at least how he
perceived them.

>Perhaps you could justify such a
>belief with some examples from your extensive business applications
>development resume.

Are you asking for examples of centralized development or for examples
of decentralized development? Or just trying to muddy the water?


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[Ken Garlington]

"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in
message news:3b52d7f5$1$fuzhry$mr2ice@va.news.verio.net...
: In <eZq47.410$rt2.150095027@newssvr11.news.prodigy.com>, on 07/16/2001
:    at 12:56 AM, "Ken Garlington" <Ken.Garlington@computer.org> said:
:
: >Errr... hello? Note that I am saying that *your definition* of
: >decentralized programming would lead one to the exact ridiculous
: >conclusion that you take so much care in ridiculing.
:
: I noted that you said that; I also noted that your claim was bogus.

Unfortunately, your argument was a straw man, since you used a definition
different than the one I referenced in my premise.

: >I'm glad that we agree that defining "decentalized" in the manner
: >you appear to espouse is silly, since then there would then be no
: >possible chance to have a "centralized" environment.
:
: Really? No chance of having centralized control over programming, etc?
: It's not only possible, it's been done, quite often. My claim was that
: it was done only in specific contexts rather than as an industry norm.

Since your definition of "centralized programming" seems now to be based on
organizational structures, not technology (making your earlier discussion of
remote job entry somewhat puzzling), perhaps you could post some examples of
"centralized programming" from this list of historical precedents which
occured "quite often," yet not frequently enough to be an "industry norm",
and discuss what key concepts they shared to make them "centralized". Per
your previous post, such "centralization" should encompass analysis, design,
coding, documentation, configuration control, debugging and resource
allocation. (This would seem to be more "software engineering" than
programming, but that's a minor point.)

: However, now I'm quite puzzled at what position you are trying to
: defend. JUst what is it that you claim was universally centralized
: prior to the PC, and by what definition, since you deny that
: cetralization of the obvious is possible?

As I noted previously, one definition of "centralized" programming is the
business environment as described in Brooks (and other respondents to this
thread), with the key concepts of (a) the CPUs are physically located close
together, in a single room or suite and (b) where the task of programming
(coding) requires the programmers to either enter the program at a single
"master" console, or to submit the programming job to a centrally located
operator corps for entry.

By contrast, "decentralized" programming has automation routinely available
at the programmer's work station (desk, etc.) without need of an
intermediary. (Brooks describes this as "interactive programming," and
indicates that it was rarely used at the time even though the technology was
available - see pg. 136.) We can further refine this by distinguishing
between the use of time-sharing systems connected directed to the
centralized set of CPUs described above using "dumb" terminals, etc., vs.
the availability of individual CPUs (PCs, etc.) from each programmer's desk.
The former case would still be considered "centralized" by some, since a
failure in the main computing cluster took down all available services, the
availability of tools, etc. could still be centrally controlled, and so
forth.

My claim (supported by Brooks and other respondents to this thread) is that
this concept of "decentralized programming," certainly the more "permissive"
second type described above, was not typically used in business computing in
the early years of that field. The definition presented above notes the
relevance of the PC to this argument.

: >Actually, I made an A in my logic course.
:
: Then you must have forgotten quite a bit. Either that, or you are
: deliberate refraining from logic.

Or that the logic taught in computer science in mathematics is a subset of
that needed for logical argument (see below).

: >How did you do in your debate course?
:
: Ah, so you have decided that winning a debate is more important than
: being correct?

Based on this evasive answer (and the inability to see more than two
possibilities in the previous statement), I assume you've never taken a
debate course and are unfamiliar with its goals. There are several resources
on the web that describe constructing a logical argument, and the associated
fallacies often committed by the uneducated or devious. I recommend

http://faqs.jmas.co.jp/FAQs/atheism/logic

I suppose that you could establish "being correct" through some means other
than the logic steps taught in debate classes (faith, etc.), but it would be
hypocritical to use these methods and then castigate others for "refraining
from logic."

: >So, you experience on the customer side indicates that the Brooks
: >description is atypical?
:
: My experience on the customer side indicates that there is massive
: variation in management style. I don't recall Brooks denying that.
: Brooks was describing how things were at IBM, or at least how he
: perceived them.

Actually, if you haven't read "Mythical Math-Month" (or have forgotten it),
you might want to read it (again). Certainly, no one who reads it should
come away thinking he was limiting himself to IBM. His description of
organizational structures is on pg. 78-79; given the various forms of your
definition of "decentralized programming", I couldn't say whether he
describes a "decentralized" organizational structure or a "centralized"
structure.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <lDF47.539$9H.206790759@newssvr11.news.prodigy.com>, on 07/16/2001
   at 05:37 PM, "Ken Garlington" <Ken.Garlington@computer.org> said:

>Unfortunately, your argument was a straw man, since you used a
>definition different than the one I referenced in my premise.

ROTF,LMAO!

>Since your definition of "centralized programming" seems now to be
>based on organizational structures, not technology

Now? That's been the case all along.

>(making your earlier discussion of
>remote job entry somewhat puzzling),

Only to one who doesn't understand the logistics.

perhaps you could post some examples of
"centralized programming" from this list of historical precedents
which occured "quite often,"

MAX, aka ALS.

>and discuss what key concepts they shared to make them
>"centralized". 

I've already enumerated them.

>As I noted previously, one definition of "centralized" programming
>is the business environment as described in Brooks (and other
>respondents to this thread), with the key concepts of (a) the CPUs
>are physically located close together, in a single room or suite and
>(b) where the task of programming (coding) requires the programmers
>to either enter the program at a single "master" console, 

What have you been smoking. That mode of operation died in the 50s, if
not earlier. Certainly by 1960 programs were entered from cards, paper
tape or magnetic tape, not from the console.

>or to submit the programming job to a centrally located operator
>corps for entry.

I'm not sure what you mean by "programming job". If you mean "batch
job", there were plenty of "self serve" card readers at computer
centers in the late sixties, to say nothing of the Bisync work
stations you seem not to believe in.

>By contrast, "decentralized" programming has automation routinely
>available at the programmer's work station (desk, etc.) without need
>of an intermediary. (Brooks describes this as "interactive
>programming,"

ROTF,LMAO! You're conflating unrelated terms.

>I suppose that you could establish "being correct" through some
>means other than the logic steps taught in debate classes (faith,
>etc.), but it would be hypocritical to use these methods and then
>castigate others for "refraining from logic."

So we agree that you're a hypocrite.

>Actually, if you haven't read "Mythical Math-Month"

I have.

>(or have forgotten it),

I haven't. Including the discrepancies that went over your head.


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[Ken Garlington]

"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in
message news:3b538445$1$fuzhry$mr2ice@va.news.verio.net...
: In <lDF47.539$9H.206790759@newssvr11.news.prodigy.com>, on 07/16/2001
:    at 05:37 PM, "Ken Garlington" <Ken.Garlington@computer.org> said:
:
: >Unfortunately, your argument was a straw man, since you used a
: >definition different than the one I referenced in my premise.
:
: ROTF,LMAO!

Based on this non-response response, you apparently concede that you cannot
dispute this point.

: >Since your definition of "centralized programming" seems now to be
: >based on organizational structures, not technology
:
: Now? That's been the case all along.
:
: >(making your earlier discussion of
: >remote job entry somewhat puzzling),
:
: Only to one who doesn't understand the logistics.

Based on this ad hominem response, you apparently concede that you cannot
dispute this fallacy (attempting to prove the widespread existence of an
organizational structure through the existence of technology), and accept
that it weakens your argument.

: perhaps you could post some examples of
: "centralized programming" from this list of historical precedents
: which occured "quite often,"
:
: MAX, aka ALS.

This does not appear to be an organizational structure. It appears to be a
technology. It also appears to be a single example, which would make the
support of the statement "quite often" to be tenuous at best. Therefore, it
does not support your argument.

: >and discuss what key concepts they shared to make them
: >"centralized".
:
: I've already enumerated them.

Based on this ad nauseum response, you apparently concede that you cannot
dispute this point.

: >As I noted previously, one definition of "centralized" programming
: >is the business environment as described in Brooks (and other
: >respondents to this thread), with the key concepts of (a) the CPUs
: >are physically located close together, in a single room or suite and
: >(b) where the task of programming (coding) requires the programmers
: >to either enter the program at a single "master" console,
:
: What have you been smoking. That mode of operation died in the 50s, if
: not earlier. Certainly by 1960 programs were entered from cards, paper
: tape or magnetic tape, not from the console.

The assertion that programs were *never* entered from a console would
surprise IBM 360 series operators, to say the least. However, since your
statement is covered in the very next clause, it is also irrelevant.

: >or to submit the programming job to a centrally located operator
: >corps for entry.
:
: I'm not sure what you mean by "programming job". If you mean "batch
: job", there were plenty of "self serve" card readers at computer
: centers in the late sixties, to say nothing of the Bisync work
: stations you seem not to believe in.

I assume the term "plenty" here is used in the same content as "quite often"
above; i.e. there was at least one example. Again, the availability of
technology is not particularly related to how it is routinely used within a
business organization. Coupled with the ad hominem non-response, the lack of
anything more than sparse anecdotal evidence fails to adequately support
your point. (Contrast this with my use of contemporary authoritative
references in the previous post).

: >By contrast, "decentralized" programming has automation routinely
: >available at the programmer's work station (desk, etc.) without need
: >of an intermediary. (Brooks describes this as "interactive
: >programming,"
:
: ROTF,LMAO! You're conflating unrelated terms.

Based on the absence of an explanation as to why these are "unrelated"
terms, I assume you're merely inserting a red herring to compensate for a
lack of a rational rebuttal.

: >I suppose that you could establish "being correct" through some
: >means other than the logic steps taught in debate classes (faith,
: >etc.), but it would be hypocritical to use these methods and then
: >castigate others for "refraining from logic."
:
: So we agree that you're a hypocrite.

No. You may believe I'm a hypocrite for using formal debate logic; this of
course does not advance your position any more than the other logical
fallacies (ad hominem attacks, in particular) that comprise this post.

: >Actually, if you haven't read "Mythical Math-Month"
:
: I have.
:
: >(or have forgotten it),
:
: I haven't. Including the discrepancies that went over your head.

Based on this ad hominem attack, coupled with the inability to support your
position through anything other than repeated assertions (e.g. by providing
references to MMM that were "over my head"), I see that you have no further
value to add to your position. Feel free to post additional irrelevant
observations if you like; however, I believe your position has been shown to
be fatally flawed. I can't see any reason to discuss it further.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <6pY57.813$Jv7.375807090@newssvr11.news.prodigy.com>, on 07/20/2001
   at 03:48 PM, "Ken Garlington" <Ken.Garlington@computer.org> said:

>Based on this non-response response, you apparently concede that you
>cannot dispute this point.

No, just that I don't suffer fools gladly. I make a statement, you
attempt to change what I said by applying a bogus definition and then
expect me to take you seriously? No way.

No, if you want to start with a discussion of what terms to use, agree
to definitions and then discuss what positions we take in terms of
those definitions, fine. Bute as long as you want to play those
rhetorical games, I will respond to them as they deserve.

>Based on this ad hominem response, you apparently concede that you
>cannot dispute this fallacy (attempting to prove the widespread
>existence of an organizational structure through the existence of
>technology), and accept that it weakens your argument.

Nope, I'm just pointing out that there is an issue that you are either
deliberately refusing to address or don't understand. Techology
constrains organizational structure but does not determine it. More
specifically, improved speed of comminications makes structures viable
that are impractical without it.

>It also appears to be a single example,

Why waste time with more, when you've denied that any are even
possible. One is all that it takes to demonstrate your error.

>The assertion that programs were *never* entered from a console
>would surprise IBM 360 series operators, to say the least

ROTF,LMAO! Programmers have been know to enter code from a S/360
console during, and probably CEs, but that was not the mode of
operation for production, development or most testing.

>I assume

Yes you do, frequently and erroneously.

>the term "plenty" here is used in the same content as "quite often"
>above; i.e. there was at least one example.

No, in the context of companies believing that there was enough of a
market to warrant developing plug compatible peripheral devices for
the purpose, e.g. the Cope 45.

>(Contrast this with my use of contemporary authoritative references
>in the previous post).

ROTF,LMAO!

>Based on the absence of an explanation as to why these are
>"unrelated" terms,

No, just refusing to explain the obvious to one unable to understand
it. If someone other than you wants an explanation, I'll be glad to
provide it.

>No. You may believe I'm a hypocrite for using formal debate logic;

No, for using rhetorical devices that have nothing to do with logic.

>Feel free to post additional irrelevant
>observations if you like;

No, I'll leave that to you; you seem so good at it.

>I can't see any reason to discuss it further.

Don't let the door hit you on the way out.

-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[Ken Garlington]

I know you are, but what am I?

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <pcM67.212$bN2.9929795@newssvr16.news.prodigy.com>, on 07/23/2001
   at 02:44 AM, "Ken Garlington" <Ken.Garlington@computer.org> said:

>I know you are, but what am I?

You know nothing, and you are a liar, for you said that you were
ending this thread.

-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

Marin David Condic wrote:

> You're wasting your breath. Sometimes people have such a strong need to be
> right that they'll ignore all the reasoning and evidence to the contrary -
> convoluting logic, redefining terminology, etc.. Often the original point is
> totally forgotten in defending a position that isn't even related to it.

ITYM that they'll resort to ad hominem arguments like the above.


> Move on to more productive concerns.

I'll take that advice.  FOAD. HTH. HAND.

*PLONK*

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

Gary Labowitz wrote:

> This is getting ridiculous. You are SO hoping that computing and programming
> were not centralized that you skip an entrie generation.

No, I'm simply taking into account the context of this thread, which is the
alleged difference before and after the PC became a major factor in the
marketplace.


> When most people talk about early days, they mean when computers actually
> came into the marketplace and were large centralized systems.

I see no evidence of that.  I believe that most of the current generation of
programmers would regard the era before S/370 as the early days.


> Certainly
> programmers could be stationed anywhere. But terminal systems (starting with
> the various 1050-type systems) weren't available in the "early days."
> Actually, I remember the introduction of the 1050 as a big deal (about 1963
> or so, maybe a little later).

While I certainly was using punched cards in those days, I was also reading
about systems that didn't. Certainly terminals were available on IBM computers
prior to 1963, even on the lowly 650.


> Anyway, the later systems developed the RJE-type systems, which
> decentralized the point at which program streams could be entered and
> printed. They still connected to centralized processing, however. Since all
> the terminals were dumb, there was only decentralized job entry and
> printing.
> The real point is: so what? So you said "in the early days we had
> decentralized computing" and were wrong.

Which part of "programming" don't you understand?


> Live with it.

Live with what? The fact that you can't read. I never denied that there was
centralized hardware.


> Let's get on with today's problems.

Santayan.

--
Shmuel (Seymour J.) Metz