Path: ...!weretis.net!feeder8.news.weretis.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: rbowman <bowman@montana.com>
Newsgroups: comp.os.linux.misc,comp.os.linux.advocacy
Subject: Re: GIMP 3.0.0-RC1
Date: 12 Feb 2025 18:50:08 GMT
Lines: 42
Message-ID: <m148qvFee9pU1@mid.individual.net>
References: <vkjmdg$30kff$1@dont-email.me> <lttopaFoh2cU8@mid.individual.net>
	<vle8uk$12sii$2@dont-email.me>
	<c686fb74-4fac-0809-7005-417c76ee0e3b@example.net>
	<nbReP.633803$oR74.271654@fx16.iad> <NnVeP.44028$vfee.11890@fx45.iad>
	<vo6ubb$3ue2q$2@dont-email.me>
	<RhOdnY5Kb8vulDr6nZ2dnZfqnPudnZ2d@earthlink.com>
	<vo7lp6$25uo$2@dont-email.me>
	<655acbf6-05e5-69ff-8a44-9f7075aafa2e@example.net>
	<vo8b6g$69pr$2@dont-email.me>
	<c78ec6bb-5cfb-72f4-3e2d-b9cf13778119@example.net>
	<slrnvqkhig.1ksd4.candycanearter07@candydeb.host.invalid>
	<9RycneStTKjZETf6nZ2dnZfqn_udnZ2d@earthlink.com>
	<m0vp8cFmqrtU3@mid.individual.net>
	<OVydnYztJ_VcQzf6nZ2dnZfqnPudnZ2d@earthlink.com>
	<m10a1kFpvndU1@mid.individual.net>
	<Wu2cnQALj-nzazf6nZ2dnZfqn_idnZ2d@earthlink.com>
	<m11levF1o50U1@mid.individual.net>
	<73idnXWOHfZXYTb6nZ2dnZfqnPqdnZ2d@earthlink.com>
	<m12gi0F6a4tU1@mid.individual.net>
	<nsucnfEFUK3ihzH6nZ2dnZfqn_idnZ2d@earthlink.com>
	<m12tbiF83a2U1@mid.individual.net>
	<il2dnXjUiKHmRDH6nZ2dnZfqn_GdnZ2d@earthlink.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Trace: individual.net 2bPuwRPEV1yJncfl4NXDOQRjgH2jmhqYXE6X9d/NFucxn02hKD
Cancel-Lock: sha1:EiIVrv/u/4A0jvDlTXYnp5QpBLM= sha256:R79QNZRLIu+iyxMuEDgxUF24AdyGAasv8UxPDvxOQ/0=
User-Agent: Pan/0.160 (Toresk; )
Bytes: 3750

On Wed, 12 Feb 2025 12:25:17 -0500, WokieSux282@ud0s4.net wrote:

>    I think the 86 series had 'more future possibilities'
>    than the 8085. There were too many 8-bit systems out there already,
>    so bumping up to 16 bit was smart for sales. Why make/compete-with
>    "just another TRS-80" ?

16/32 bit processors were in the air so it would make no sense to stay 
with 8 bits. 

https://spectrum.ieee.org/the-inside-story-of-texas-instruments-biggest-
blunder-the-tms9900-microprocessor

That covers the ground from a slightly different perspective, a TI 
engineer. It's interesting to speculate on IBM's view of future 
possibilities. A large part of the company didn't think there was a 
future. Intel thought the 432 was the future but that fell on its face. 
Using the 8088 solved the peripherals problem but it also meant the 
performance wasn't better than a Z80. Z80 designs were already doing bank 
switching. The 8088 just had the additional registers to implement it.

The TMS9900 wasn't a bad chip, if a little odd if you came from the Intel/
Zilog world. I worked with it on one project. Because of TI's roots they 
had a rad hard version 

https://retrocomputingforum.com/t/the-texas-instruments-tms-9900-
microprocessor/1370

That's a good description of the oddities. 

The first article points out the IBM was big-endian and suddenly thy were 
transported into the little-endian world. Our legacy software uses ONC-RPC 
which handle the byte order. Originally the system ran on RS6000 machines 
where the reshuffling was a NOOP. As we started using Linux in house for 
development, the x86 machines had to reverse the canonical big-endian 
data. No problem. Then our clients moved to Windows while we still used 
Linux leading to the absurdity of dual processing to move little-endian to 
big-endian and back to little-endian. 

All that is hidden in the RPC code but it becomes explicit when you find 
yourself using htonl, ntohl, and friends when building a socket 
connection.