Path: ...!feeds.phibee-telecom.net!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: jgd@cix.co.uk (John Dallman)
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Fri, 30 Aug 2024 21:03 +0100 (BST)
Organization: A noiseless patient Spider
Lines: 58
Message-ID: <memo.20240830210356.19028C@jgd.cix.co.uk>
References: <vasruo$id3b$1@dont-email.me>
Reply-To: jgd@cix.co.uk
Injection-Date: Fri, 30 Aug 2024 22:03:57 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="38033b2def40f84b61277130ee7f3660";
	logging-data="675960"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/XK2mWpHLnrqvk24zv6YdplGlJfBuR27U="
Cancel-Lock: sha1:ZEbDd8aZ3k+LR6PgnfOA/Un3cYI=
X-Clacks-Overhead-header: GNU Terry Pratchett
Bytes: 3669

In article <vasruo$id3b$1@dont-email.me>, david.brown@hesbynett.no (David
Brown) wrote:

> On 30/08/2024 17:42, John Dallman wrote:
> > Plain old compiler bugs, introduced while fixing other ones, are 
> > quite enough to make me assume that I'll find problems on each
> > change of compiler.
> 
> I always keep old versions of compilers around, and don't change 
> compilers (or libraries) in the middle of a project.  

I always have at least a couple of machines at the previous build
standard of any platform, often more machines and/or older build
standards. 

Changing compilers or libraries is done at new major releases. 

> If you want to write software that is "correct because it passed 
> its tests", you can only expect it to be reliable when it is run 
> exactly as tested.  That means it must be compiled as it was during 
> tests (same compiler, same options, same library), and arguably 
> even run only on the same hardware (if you only test on one 
> particular cpu, OS, etc., you can only be sure it works on that 
> cpu, OS, etc.).

This is simpler when you produce closed-source binary software. We only
ship builds we've tested. That means the /same binaries/ as we tested,
not rebuilt or modified. This requires a separate test harness, rather
than testing code compiled into the binaries. 

We test on a wide variety of hardware for the most-used platforms, by
putting it into the distributed testing pools and always knowing which
machine an individual test case ran on, because it's recorded in the test
results. 

> That's why a lot of pre-compiled commercial software gives 
> particular versions of particular OS's or Linux distributions in 
> their lists of requirements - even though the software would 
> probably work fine on a much wider range.

We specify what we specifically support, because we've tested that, plus
the much broader requirements that it should work on. For Linux those are
a GCC runtimes version (currently 8.x) or later and a glibc version
(currently 2.28) or later. We don't seem to have problems with
compatibility since we understood how the compatibility works with those
libraries, and started doing it that way. 

If there's a problem on a specifically supported Linux, we'll fix it
unless that's impossible. If there's a problem on one where it should
work, we'll investigate it, and fix it if we can, which may cause a
distribution to be added to the specifically supported list. If we can't
fix a problem, we'll explain why not, and normally add the problem to the
documentation. We can't do miracles, but we do pretty well. 

Yes, doing good support is expensive, but it pays off in customer loyalty,
which means money. 

John