Paul Eggert wrote: > > "Dr. David Kirkby" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
