Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: David Brown 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: References: 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: Bytes: 4361 On 30/08/2024 22:03, John Dallman wrote: > In article , 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.