From: Brian on
On Feb 11, 3:07 am, Arved Sandstrom <dces...(a)hotmail.com> wrote:
>
> Free (as in beer) software brings up an interesting set of arguments. If
> I understand your point as being, if a product is free how can one
> possibly sue the maker of it for flaws in the product? Correct me if I'm
> wrong.
>
> I have my own thoughts on this topic but I simply want to make sure what
> we're discussing.
>

Imagine driving by a house and seeing a car in front with
this sign -- "Free car." It is your responsibility to
check out the car. If I were interested in that car, I'd
talk to the giver of the car, check out the car for
myself (is it stolen?) and then either drive it carefully
to a mechanic or have a mechanic come to the car. After
that I'd be the only one that rides in the car for a
month or two to be more certain that it is in fact a safe
car. As long as the giver reveals any known problems
about the car to me, I don't think there's any basis for
suing him if the car is later found to have a serious problem.


Brian Wood
http://webEbenezer.net
(651) 251-9384

From: Andy Champ on
Lew wrote:
>
> Andy Champ wrote:
>> In 1982 the manager may well have been right to stop them wasting
>> their time fixing a problem that wasn't going to be a problem for
>> another 18 years or so. The software was probably out of use long
>> before that.
>
> Sure, that's why so many programs had to be re-written in 1999.
>
> Where do you get your conclusions?
>

Pretty well everything I saw back in 1982 was out of use by 1999. How
much software do you know that made the transition?

Let's see.. Operating systems. The PC world was... umm.. CP/M 80?
Maybe MS-Dos 1.0? And by 1999 I was working on drivers for Windows
2000. That's at least two, maybe three depending how you count it,
ground-up re-writes of the OS.

With that almost all the PC apps had gone from 8 bit versions in 64kb of
RAM to 16-bit DOS to Windows 3.1 16-bit with non-preemptive multitasking
and finally to a 32-bit app with multi-threading and pre-emptive
multitasking running in hundreds of megs.

OK, so how about embedded stuff? That dot-matrix printer became a
laserjet. The terminal concentrator lost its RS232 ports, gained a
proprietary LAN, then lost that and got ethernet. And finally
evaporated in a cloud of client-server computing smoke.

I'm not so up on the mainframe world - but I'll be surprised if the
change from dumb terminals to PC clients didn't have a pretty major
effect on the software down the back.

Where do you get your conclusions that there was much software out there
that was worth re-writing eighteen years ahead of time? Remember to
allow for compound interest on the money invested on that development...

Andy.
From: Bo Persson on
MarkusSchaber wrote:
> Hi,
>
> On 10 Feb., 22:53, Andy Champ <no....(a)nospam.invalid> wrote:
>> Can any locksmith or
>> burglar alarm maker guarantee that a building will withstand all
>> attacks for 12 months? _That_ is the equivalent of withstanding
>> all virus attacks for 12 months - and it's on a far simpler system.
>
> Maybe not the locksmith itself, but there are insurance companies
> which calculate how high the risk is, and they take that liability.
>
> For locks, cars, even airplanes, insurance companies do that all the
> time. But there are only a few cases where this is done for
> software.

Is it? What about the software that controls the locks, cars, and
airplanes?


Bo Persson


From: Wojtek on
Andy Champ wrote :
> Lew wrote:
>>
>> Andy Champ wrote:
>>> In 1982 the manager may well have been right to stop them wasting their
>>> time fixing a problem that wasn't going to be a problem for another 18
>>> years or so. The software was probably out of use long before that.
>>
>> Sure, that's why so many programs had to be re-written in 1999.
>>
>> Where do you get your conclusions?
>>
>
> How much software do you know that made the transition?

> I'm not so up on the mainframe world

Yup. Made lots of money transitioning mainframe apps.

--
Wojtek :-)


From: Lew on
Andy Champ wrote:
>>> In 1982 the manager may well have been right to stop them wasting
>>> their time fixing a problem that wasn't going to be a problem for
>>> another 18 years or so. The software was probably out of use long
>>> before that.

Lew wrote:
>> Sure, that's why so many programs had to be re-written in 1999.
>>
>> Where do you get your conclusions?

Andy Champ wrote:
> Pretty well everything I saw back in 1982 was out of use by 1999. How
> much software do you know that made the transition?

Pretty much everything I saw back in 1982 is in production to this day, never
mind 1999.

Pretty much everything that had Y2K issues in 1999 was in production since the
1980s or earlier. By the 90s, more software was written without that bug.

Again, why do you think Y2K was such an issue, if affected software had gone
out of production by then?

> Let's see.. Operating systems. The PC world was... umm.. CP/M 80? Maybe
> MS-Dos 1.0? And by 1999 I was working on drivers for Windows 2000.
> That's at least two, maybe three depending how you count it, ground-up
> re-writes of the OS.

PCs were not relevant in 1982. PCs largely didn't have Y2K issues; it was
mainly a mainframe issue.

> With that almost all the PC apps had gone from 8 bit versions in 64kb of
> RAM to 16-bit DOS to Windows 3.1 16-bit with non-preemptive multitasking
> and finally to a 32-bit app with multi-threading and pre-emptive
> multitasking running in hundreds of megs.

Largely irrelevant to the discussion of Y2K issues, which were a mainframe
issue for the most part.

PCs were not in common use in 1982.

> OK, so how about embedded stuff? That dot-matrix printer became a
> laserjet. The terminal concentrator lost its RS232 ports, gained a
> proprietary LAN, then lost that and got ethernet. And finally
> evaporated in a cloud of client-server computing smoke.

Not relevant to the discussion of Y2K issues.

> I'm not so up on the mainframe world - but I'll be surprised if the
> change from dumb terminals to PC clients didn't have a pretty major
> effect on the software down the back.

This was mainframe stuff. Most PC software didn't have Y2K bugs, and there
weren't PCs in common use in 1982.

PCs have had negligible effect on mainframe applications, other than to
provide new ways of feeding them.

> Where do you get your conclusions that there was much software out there
> that was worth re-writing eighteen years ahead of time? Remember to
> allow for compound interest on the money invested on that development...

Software development costs are inversely proportional to the fourth power of
the time allotted. That's way beyond the inflation rate.

Y2K repair costs were inflated by the failure to deal with them early, not
reduced.

The point of my example wasn't that Y2K should have been handled earlier, but
that the presence of the bug was not due to developer fault but management
decision, a point you ignored.

--
Lew