"Theodore Y. Ts'o" writes: > On Wed, Aug 21, 2019 at 10:03:01AM +0100, Luke Kenneth Casson Leighton wrote: >> so i hope that list gives a bit more context as to how serious the >> consequences of dropping 32 bit support really is. > > I very much doubt we are any where near "dropping 32-bit support". > There's a lot of "all or nothing thinking" in your argumentation > style.
The topic of this very thread is how to avoid dropping support for 32bit architectures. So people clearly want to continue supporting it. > As Sam has said multiple times, what's much more likely is that the > set of packages that can't be built on native packages on 32-bit > platforms will grow over time. The question is when will that > actually *matter*? There are many of these packages which no one > would want to run on a 32-bit platform, especially if we're focusing > on the embedded use case. It might matter pretty soon: for generic-purpose systems one almost always want to be able to use a web browser; even various embedded systems do. However web browsers are one of the most heavy packages to build. > At least initially, the simplest way of dealing with the problem is > that maintainers will simply not build their package on 32-bit > platforms. I don't think we want this to happen if we want to continue supporting 32bit systems. But using a 64bit toolchain in an otherwise 32bit userland as the thread suggests we now really should start looking at will avoid this. It will probably take a few more years until we have to worry about being able to run browsers in 32bit... But I would hope that most people understand that using 32bit for new generic-purpose systems is not future-proof (and hasn't been for a while); even phones have started to move to 64bit systems a while ago. Ansgar
