Deorbiting i386

[Matthew Macy]

On Thu, May 24, 2018 at 8:51 AM, Andrew Gallatin <gallatin at cs.duke.edu> wrote:
> On 05/23/18 20:09, Pedro Giffuni wrote:
>>
>> FWIW;
>>
>> On 23/05/2018 17:18, Cy Schubert wrote:
>>>
>>> In message <20180523202228.GC58848 at spindle.one-eyed-alien.net>, Brooks
>>> Davis wr
>>> ites:
>>>>
>>>>
>>>> --QRj9sO5tAVLaXnSD
>>>> Content-Type: text/plain; charset=us-ascii
>>>> Content-Disposition: inline
>>>> Content-Transfer-Encoding: quoted-printable
>>>>
>>>> On Thu, May 24, 2018 at 02:53:16AM +0700, Eugene Grosbein wrote:
>>>>>
>>>>> 24.05.2018 2:30, Cy Schubert wrote:
>>>>> =20
>>>>>>
>>>>>> Except for old computers and old software that segfaults on 64-bit,
>>>>>> how=
>>>>
>>>>   many people still use i386?
>>>>>>
>>>>>> =20
>>>>>> Full disclosure: I'd like to see i386 deorbited before I retire.
>>>>>
>>>>> =20
>>>>> Plese don't. I routinely use FreeBSD11/i386 for cheap VPS hosts having
>>>>> le=
>>>>
>>>> ss than 2G memory
>>>>>
>>>>> because amd64 has noticeable overhead. I even have ZFS-only i386 VPS,
>>>>> her=
>>>>
>>>> e is live example with 1G only:
>>>>>
>>>>> =20
>>>>> Mem: 10M Active, 69M Inact, 230M Wired, 685M Free
>>>>> ARC: 75M Total, 1953K MFU, 31M MRU, 172K Anon, 592K Header, 42M Other
>>>>>       3500K Compressed, 29M Uncompressed, 8.61:1 Ratio
>>>>> Swap: 1024M Total, 1024M Free
>>>>> =20
>>>>> The VPS has only 20G of disk space and ZFS compression gives
>>>>> compressratio 2.22x for ports, 2.51x for src, 2.29x for obj
>>>>> and 1.95x for installed i386 system plus other software and data.
>>>>
>>>> I think we're quite a ways from being ready to axe i386.
>>>>
>>>> For VPS applications, we should probably get x32 support in place which
>>>> should give us the best of both worlds.
>>>>
>>>> That said, we either need to rev the i386 ABI to use a 64-bit time_t or
>>>> kill it in the not to distant future or we risk embedded systems failing
>>>> in place in 2038.  If we assume a 15 year life for most equipment to
>>>> fail electrically or mechanically that says FreeBSD 13 shouldn't support
>>>> the current i386 ABI.
>>>
>>> Rereading this, I'm confused. FreeBSD 13? 2023? Either works for me,
>>> though 2023 is more reasonable and gives people more than enough time
>>> to migrate.
>>>
>>>
>> IMHO, we shouldn't at all plan to deorbit i386: it is a platform that is
>> very easy to test on Jenkins/bhyve. If we want to keep FreeBSD multiplatform
>> it is way easier to test and find bugs on i386 than on other 32 bit
>> platforms. It is fully functional and much more than historic value.
>>
>> X32 sadly didn't catch on linux on AFAICT, although I wouldn't object to
>> it appearing on FreeBSD.
>>
>> Pedro
>
> On the other hand, supporting all these architectures makes it rather
> challenging to make changes to the kernel & feel like you've tested
> them sufficiently.   Even build testing a header file change can take
> the better part of a day with make universe.  I'm quite jealous of
> Dragonfly's amd64 only approach for this reason.
>
> I realize this may be seen as ironic, as I'm one of the people that
> dragged FreeBSD into the multiplatform world with the FreeBSD/alpha
> port 20 years ago. On the other hand, I was happy to retire
> FreeBSD/alpha when the Alpha stopped being commercially viable.
> I always viewed NetBSD as the proper place for "historical" platforms
> to run BSD.   I wish we could retire some of the minor/historical
> platforms that we have now.
>

Additional platforms don't come without a cost. When I was doing
i386-xen and sun4v alc would routinely break the port and I was _fine_
with that. He shouldn't be slowing down for something marginal. When
it was clear to me that sun4v was never going to get much uptake I
asked that it be removed.

i386 is definitely on the wane, but so long as it's used by more than
a handful of people it will be supported. All you need to know about
sparc64 vitality is that HEAD didn't boot for 3 months until last
week.

-M