Date: Fri, 28 Apr 2023 07:16:12 -0700 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arch <freebsd-arch@freebsd.org> Subject: Re: Future of 32-bit platforms (including i386) Message-ID: <20230428071612.16ca02bd@cschubert.com> In-Reply-To: <CANCZdfozwP6oKbu3d_LvMu-g_3ddMg5uLQ=KeLp5Xf9HxorZ=A@mail.gmail.com> References: <aaa3e005-5f72-f422-56b1-932842379e15@FreeBSD.org> <CANCZdfozwP6oKbu3d_LvMu-g_3ddMg5uLQ=KeLp5Xf9HxorZ=A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 27 Apr 2023 11:33:15 -0600 Warner Losh <imp@bsdimp.com> wrote: > On Thu, Apr 27, 2023 at 11:20=E2=80=AFAM John Baldwin <jhb@freebsd.org> w= rote: >=20 > > 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. > > =20 >=20 > I like this. "In 14.0, i386 completes its journey to tier 2 status" maybe? >=20 >=20 > > 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. > > =20 >=20 > So no freebsd-update service for i386 for 14.x, but have it for arm64 and > amd64? > That seems reasonable (assuming that arm64 works). >=20 >=20 > > 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. > > =20 >=20 > 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 less= on > 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. >=20 > 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 experie= nce > for how to do that with the other 32-bit platforms for 15. >=20 > 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 operatio= ns, > even if they are relatively inefficient because the base system is starti= ng > to use them. >=20 > 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. >=20 > Warner --=20 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=3D0
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20230428071612.16ca02bd>