Re: Future of 32-bit platforms (including i386)

On Fri, Apr 28, 2023 at 07:16:12AM -0700, Cy Schubert wrote:
> On Thu, 27 Apr 2023 11:33:15 -0600
> Warner Losh <imp@bsdimp.com> wrote:
> 
> > On Thu, Apr 27, 2023 at 11:20 AM John Baldwin <jhb@freebsd.org> wrote:
> > 
> > > For 13.0, i386 was demoted from Tier 1 to Tier 2.  In the announcement
> > > of this for 13.0, the project committed to an update on i386's future
> > > around the time of 14.0.  The announcement at the time suggested that
> > > i386 would be supported less in 14.x than in 13.x.
> > >  
> > 
> > I like this. "In 14.0, i386 completes its journey to tier 2 status" maybe?
> > 
> > 
> > > My proposal is that for 14.x we treat i386 like any other Tier 2
> > > platform.  That is, release images and packages would only be provided
> > > on a best-effort basis, and we would not guarantee providing them.  I
> > > think we should also stop shipping binary updates for the base system
> > > (freebsd-update) for 14.x for i386.
> > >  
> > 
> > So no freebsd-update service for i386 for 14.x, but have it for arm64 and
> > amd64?
> > That seems reasonable (assuming that arm64 works).
> > 
> > 
> > > A larger question is what to do about 32-bit platforms moving forward.
> > > My proposal for powerpc, i386, and armv[67] is that we say publicly
> > > that we anticipate not supporting them in 15.  That is, that we may
> > > remove them outright from the tree, or we may leave them in the tree,
> > > but we do not plan on building packages or release images.  Another
> > > option to consider for 32-bit platforms perhaps in 15 is to remove
> > > kernel support and only retain the ability to build userland.  The
> > > goal of saying this now-ish (or about the time 14.0 is going to ship)
> > > would be to give time for users and developers to respond in the
> > > window between 14.0 and 15.0 so we can evaluate those responses as an
> > > input into the final decision for 15.
> > >  
> > 
> > I like this idea. It states intent strongly enough that people aren't
> > surprised,
> > but weakly enough that people with strong interests can show up. One lesson
> > we've learned repeatedly in the past, though, is that we get a lot people
> > showing up saying they'll do something, but then doing nothing. The
> > threshold
> > of doing something will be actually doing it and being an active member of
> > the community or providing other material support rather than "Geeze, I'd
> > hate to see sparc64 go, so I'll fix a port or two". I'm not sure how you'd
> > set
> > that expectation, but maybe something like "we'll evaluate the responses and
> > the robustness, size and vitality of those communities as input into our
> > decision"
> > which would set the bar higher, and have something vaguely measureable to
> > point at.
> > 
> > Side note: We should stop providing packages and re-built images for armv6
> > in 14, even if we don't completely decommission support for it right away.
> > That
> > might prove to be a good model here as well and give us some good experience
> > for how to do that with the other 32-bit platforms for 15.
> > 
> > I generally favor this idea... It's also a natural evolution of what we've
> > been saying
> > about platforms, eg you need to provide 64-bit atomics and other operations,
> > even if they are relatively inefficient because the base system is starting
> > to use them.
> > 
> > 32-bit going away is the long term trend, and the long term goal of the
> > project.
> > What remains in doubt is the timeline to accomplish this. Many 32-bit
> > platforms
> > still perform decently well, so we should expect to see some usage. But we
> > need
> > to weigh the size of that usage against the cost of providing it. We've
> > seen an increasing
> > cost to developers to provide this over the last few years. But as the
> > usage drops
> > the cost increases because unanticipated breakages become harder to fix as
> > they
> > are discovered further and further from the breaking point.
> 
> Agreed. This brings us in line with virtually all major Linux
> distributions, Oracle Solaris (whatever is left of it), the other major
> commercial O/S out there (AIX), and the other major distributions of
> BSD (except NetBSD).
> 
> I think we need to nudge the ports team in this direction, sooner than
> later, though in my experience, a good percentage of packages fail to
> build on i386 anymore here anyway, including all browsers in ports/www.
> 
From my testing chromium still builds on i386, but that platform needs some
more handholding than amd64. So sparc64 and arm4/5 (and base GCC) support
will be purged from the ports tree once 12 goes EOL in 2024, removing i386
and arm 6/7 should be a similar exercise.

René
> > 
> > Warner
> 
> 
> 
> -- 
> Cheers,
> Cy Schubert <Cy.Schubert@cschubert.com>
> FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  https://FreeBSD.org
> NTP:           <cy@nwtime.org>    Web:  https://nwtime.org
> 
> 			e^(i*pi)+1=0