From: Leif Roar Moldskred on
In comp.lang.java.programmer Brian <coal(a)mailvault.com> wrote:
>
> That is true in a traditional model of exchanging
> money for a product or service. If you don't pay
> for the good or service, you have no "rights."

That's quite simply not correct.

--
Leif Roar Moldskred
From: James Kanze on
On Feb 11, 9:33 pm, Andy Champ <no....(a)nospam.invalid> 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?

> 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.

The "standard" life of a railway locomotive is thirty or fourty
years. Some of the Paris suburbain trainsets go back to the
early 1970's, or earlier, and they're still running.

> 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.

Have you been to a bank lately, and seen what the clerk uses to
ask about your account? In more than a few, what you'll see on
his PC is a 3270 emulator. Again, a technology which goes back
to the late 1960's/early 1970's.

> Where do you get your conclusions that there was much software
> out there that was worth re-writing eighteen years ahead of
> time?

It depends on what you're writing, but planned obsolescence
isn't the rule everywhere.

--
James Kanze
From: James Kanze on
On Feb 12, 1:07 am, Lew Pitcher <lpitc...(a)teksavvy.com> wrote:
> On February 11, 2010 19:15, in comp.lang.c, nowh...(a)a.com wrote:

> > Lew wrote :
> >> 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.

> > At the time (70's etc) hard drive space was VERY expensive.
> > All sorts of tricks were being used to save that one bit of
> > storage. Remember COBOL's packed decimal?

> Packed decimal (the COBOL COMP-3 datatype) wasn't a "COBOL"
> thing; it was an IBM S370 "mainframe" thing. IBM's 370
> instructionset included a large number of operations on
> "packed decimal" values, including data conversions to and
> from fixedpoint binary, and math operations. IBM's COBOL took
> advantage of these facilities with the (non-ANSI) COMP-3
> datatype.

Packed decimal and COBOL are a lot older than the S370.
Although the 1401 used unpacked decimal, I believe it's been
available on a lot of machines since then.

--
James Kanze
From: James Kanze on
On Feb 12, 11:42 am, Leif Roar Moldskred
<le...(a)huldreheim.homelinux.org> wrote:
> In comp.lang.java.programmer Arved Sandstrom <dces...(a)hotmail.com> wrote:
> > This is what I am getting at, although we need to have
> > Brian's example as a baseline. In this day and age, however,
> > I'm not convinced that a person could even give away a free
> > car (it wouldn't be free in any case, it would still get
> > taxed, and you'd have to transfer title) and be completely
> > off the hook, although 99 times out of 100 I'd agree with
> > Brian that it's not a likely scenario for lawsuits.

> Where Brian's example falls down is that the previous owner of
> the car is, in effect, just a reseller: he isn't likely to
> have manufactured the car or modified it to any degree.

> However, let us assume that he _has_ done modifications to the
> car such as, say, replacing the fuel tank. If he messed up the
> repair and, without realising it, turned the fuel car into a
> potential firebomb, he would be liable for this defect even if
> he gave the car away free of charge.

He doesn't even have to have done that much. If he knows that
the brakes doen't work, and he lets you drive it, he's legally
responsible.

> > With software the law is immature.

> I don't think the law is immature when it comes to software.
> Ultimately, software is covered by the same laws as Ford
> Pintos. That said, the legal practice might be lagging behind,
> as might the market and users' awareness of legal rights and
> duties.

It is, because there's relatively little jurisprudence. That's
one of the things that makes liability insurance for a
contractor so expensive---the insurance company doesn't really
know how much they're risking (so they assume the worst).

--
James Kanze
From: Brian on
On Feb 12, 3:14 pm, Leif Roar Moldskred
<le...(a)huldreheim.homelinux.org> wrote:
> In comp.lang.java.programmer Brian <c...(a)mailvault.com> wrote:
>
>
>
> > That is true in a traditional model of exchanging
> > money for a product or service.  If you don't pay
> > for the good or service, you have no "rights."
>
> That's quite simply not correct.
>

Who has successfully sued a Boost developer or Boost
as a whole over their open source code? No one has
sued Ebenezer Enterprises either. T


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