Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Sat, 31 Aug 2024 16:00:35 +0200
Organization: A noiseless patient Spider
Lines: 76
Message-ID: <vav7m4$11ep6$2@dont-email.me>
References: <vasruo$id3b$1@dont-email.me>
 <memo.20240830210356.19028C@jgd.cix.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 31 Aug 2024 16:00:36 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3820a5a5a2d09da681b5b14bf37b4c3d";
	logging-data="1096486"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/lrQHAflx9dsSzeMDf8+m2ieunLGdQ8eQ="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:hGa0tYWz62gXVdWrHMdn4SLnpO8=
Content-Language: en-GB
In-Reply-To: <memo.20240830210356.19028C@jgd.cix.co.uk>
Bytes: 4361

On 30/08/2024 22:03, John Dallman wrote:
> 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.
> 

It is indeed simpler when you produce binaries.  (We make embedded 
systems - for many products, we have full control of the of software and 
the hardware, which makes it a lot easier to have a consistent test 
environment.)

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

That is a good compromise.

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

Agreed.  For a lot of businesses, customer loyalty comes not from making 
working products (lots of people can do that), but how you handle things 
when something goes wrong.