[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: backward compatability of tools
From: |
Dr. David Kirkby |
Subject: |
Re: backward compatability of tools |
Date: |
Tue, 18 Feb 2003 10:18:17 +0000 |
Paul Eggert wrote:
>
> "Dr. David Kirkby" <address@hidden> writes:
>
> > SunOs 4.1.4
>
> Sun has been withdrawing support for that OS. Since September 2000
> Sun has not issued patches for new bugs in that operating system. On
> September 30, Sun will further transition SunOS 4.1.4 to "custom
> quote" level, which means you will need to spend a lot of money (and
> have service division VP approval!) in order to get a bug fixed.
I take your point, although you are saying it is still an operating
system supported by Sun. They are not issuing bug fixes, but it is
still supported - for a few months at least.
> For quite some time now, the vast majority of bug reports that I've
> gotten from SunOS 4.x users are from people who are doing portability
> checking. In other words, they don't need the software themselves;
> they just think that other people might need the software.
As I stated at the beginning, portability testing was why I was doing
this under SunOs 4.1.4. I don't need to run the software on a 10 year
old hardware/software, when I own a Sun Ultra 80 with 4 CPUs and 4 Gb
of RAM, running the latest Solaris release.
However, I do feel there is some merit in testing software on
platforms even if you, *nor anyone else*, wants to use it on those
platforms! That may sound a stupid statement, but is not quite so
stupid as it first sounds. There may *real bugs* that become evident
under SunOs 4.1.4, that are not evident on more modern platforms that
I personally have access to, but otheres do use. Certainly experience
has shown the software to have real bugs which only affect Dec Alphas,
only seem to affect gcc-2.8.1, or only seem to affect Windoze XP, yet
in each case the bugs were real - not just silly things like ignoring
the return value of printf.
I know Lint is useful in this respect, but I do feel trying to change
code to make lint happy is likely to introduce more bugs than it
solves. In contrast, real bugs found on a particular platform might
well affect others now or in the future.
If developers of engineering tools A and B try to ensure backward
compatibility whilst developers of engineering tools C and D don't,
that is their choice. Tools A and B work on old machines, whilst C and
D don't. In contrast, once developers of development tools such as
autoconf and automake break backward compatibility, it screws it up
for ALL developers, so now engineering tools A and B stop working,
despite the efforts of their developers. Hence I feel there is some
moral responsibility for developers of *development tools* like
autoconf and automake to avoid breaking backward compatibility if
*reasonably* practical.
Clearly my views seem to be in a minority!!
--
Dr. David Kirkby,
Senior Research Fellow,
Department of Medical Physics,
University College London,
11-20 Capper St, London, WC1E 6JA.
Tel: 020 7679 6408 Fax: 020 7679 6269
Internal telephone: ext 46408
e-mail address@hidden
- backward compatability of tools, Dr. David Kirkby, 2003/02/16
- Re: backward compatability of tools, Paul Eggert, 2003/02/17
- Re: backward compatability of tools,
Dr. David Kirkby <=
- Re: backward compatability of tools, Paul Eggert, 2003/02/18
- Re: backward compatability of tools, Dr. David Kirkby, 2003/02/18
- Re: backward compatability of tools, Alex Hornby, 2003/02/19
- Re: backward compatability of tools, Paul Eggert, 2003/02/19
- Re: 1,000 year backward compatability of tools, Bruce Korb, 2003/02/19
- Re: 1,000 year backward compatability of tools, John W. Eaton, 2003/02/19
- Re: 1,000 year backward compatability of tools, Bob Friesenhahn, 2003/02/19
- Re: 1,000 year backward compatability of tools, Thomas E. Dickey, 2003/02/19
- Re: 1,000 year backward compatability of tools, Paul Eggert, 2003/02/19
- Re: 1,000 year backward compatability of tools, Charles Wilson, 2003/02/19