Deorbiting i386

Poul-Henning Kamp phk at phk.freebsd.dk
Fri May 25 07:40:40 UTC 2018


--------
In message <52678325-8265-4333-8C4F-2C8D53C822F4 at theravensnest.org>, David Chisnall writes:
>On 25 May 2018, at 05:27, Maxim Sobolev <sobomax at freebsd.org> wrote:
>> 
>> The idea looks very inmature and short-sighted to me. i386 is here to 
>stay not as a server/desktop platform but as an embedded/low power/low 
>cost platform for at least 5-10 years to come. There are plenty of 
>applications in the world that don't need > 3gb of memory space and have 
>no use for extra bits (and extra silicon) to function.
>
>This argument seems very odd to me.  If you are targeting the embedded 
>space, it is far easier to build a low-power chip that targets the 
>x86-64 ISA than the x86-32 ISA.

Any company doing so would also have to consider IP/patent/licensing factors.

That said, the main reason why i386 is still doing surprisingly
well in the embedded space, is that there are still truckloads of
"legacy" software running under MS-DOS and similar, and it works
well enough that "a simple hardware upgrade" is enough to satisfy
contingency planning.

For FreeBSD that market centers on the "Soekris Segment"

Most of the chips in those platforms are EOL'ed now, Soekris has
moved into the audio-homeopathy market, and PCengines are also
phasing out their x86 kit.

That sucks for the people running other operating systems,
but various taiwanese companies produce usable HW.

Anything written moderately competent using FreeBSD on i386 can be
trivially ported to amd64, if the new hardware supports that, or
to an entirely different 32bit arch arch like arm or mips.

So absolutely:  Kill i386 once 12 has been branched.

Poul-Henning

... Who ran Win3.11 a couple of years ago because of Vladimir Putin.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


More information about the svn-src-all mailing list