On Mon, 2020-12-14 at 14:54 -0800, Russ Allbery wrote: > Calum McConnell <calumlikesapple...@gmail.com> writes: > > The point I'm making is that i386 processors are still incredibly > > common, and we shouldn't abandon their users. > > Not abandoning users is a powerful motivating force, but it still has to > succeed in motivating people. Debian can't make a decision on the basis > of not abandoning users. We have to make a decision on the basis that > someone is volunteering to do the work. Perhaps they're volunteering to > do that work so that we're not abandoning users, and that's great, but > that additional step is important. > > I think it's therefore useful in this sort of thread to be very clear > whether your conclusion is "and therefore I am volunteering to do the > work to keep i386 alive" or whether your conclusion is "and therefore I > am asking other people to volunteer to keep i386 alive," and be aware > that the latter may not be successful because volunteer time is a > limited resource and there are many worthy things that we could all be > working on to make the lives of users better.
A very fair point, and quite equitably put. If I was remotely comfortable tweaking kernels, or used a 32 bit machine regularly, I would be more comfortable volunteering. As it is, I have only really learned to maintain packages in the past few months, and I feel nowhere near confident enough about my future to make a three-year commitment. But I would like to say that, while it is a significant workload, it isn't one that isn't being done. There is still only one porter, it's true, but that's also currently the case for ppc64el, and s390x has no confirmed porters. In fact, no architecture has any more than 2 porters. Plus, in other areas i386 is in a better position than most: it has more archive coverage than any other (non-amd64) port, and still has good upstream support. Further, unless "sudden death of most porters" can be added to the list of bad events of 2020, I feel confident in saying that there are still probably some more people who simply haven't gotten around to confirming that they can be a porter. Every port but arm64 has less than half the porters that it had for Buster, and many have a third or a fourth the people. So while it's true that I am asking others to give up their time, without backing it up with my own commitment as Johannes has, I feel that it is a request that will be met. > The reason why I'm focusing on the kernel is because the upstream kernel > developers have been signaling rather strongly for a while that i386 is > a semi-deprecated architecture that you should avoid running if you can, > and the amount of resources and attention that it is getting are > steadily dropping. Maybe the resources and attention it gets are still > something we consider "good enough" (although we're already at the point > where if you care about kernel security, you should put serious effort > into getting onto the amd64 kernel even if you keep an i386 userspace), > but at some point it seems likely they will no longer be. That means it > may be time to push our users a bit harder to switch to the amd64 kernel > if they can. I agree, but I don't think we are yet at that point where dropping support should be an issue. If the debate was whether i386 should be maintained as an LTS architecture [1], I would be more willing to agree. Perhaps for Bookworm, a reasonable compromise would be to drop security support for i386 kernels. But that discussion is at least a year down the road. While the kernel upstream may be discouraging i386 users, it is still (mostly) supported by them for the time being: as long as that remains the case, I don't think we should drop the i386 kernel. While I agree that i386 kernel support should be phased out, and might even need to be dropped altogether, I strongly disagree with the original premise of this thread, that all i386 support should be dropped for Bullseye. There is still a massive library of software that is only available as 32-bit: indeed, in my experience it has only been in the past few years that 64-bit has been the default. While keeping old binaries running isn't the responsibility of Debian, I do think that, after 20 years of recommending i386 as the most compatible target for code, we should try to support them at least a little longer. [1]: I mean a true LTS, not just the three years mentioned in the original subject
signature.asc
Description: This is a digitally signed message part
