On Wed, Jun 27, 2018 at 9:03 PM, Niels Thykier <ni...@thykier.net> wrote:
> armel/armhf: > ------------ > > * Undesirable to keep the hardware running beyond 2020. armhf VM > support uncertain. (DSA) > - Source: [DSA Sprint report] [other affected 32-bit architectures removed but still relevant] ... i'm not sure how to put this other than to just ask the question. has it occurred to anyone to think through the consequences of not maintaining 32-bit versions of debian for the various different architectures? there are literally millions of ARM-based tablets and embedded systems out there which will basically end up in landfill if a major distro such as debian does not take a stand and push back against the "well everything's going 64-bit so why should *we* bother?" meme. arm64 is particularly inefficient and problematic compared to aarch32: the change in the instruction set resulted in dropping some of the more efficiently-encoded instructions that extend a 64-bit program size, require a whopping FIFTY PERCENT instruction-cache size increase to compensate for, whch increased power consumption by over 15%. in addition, arm64 is usually speculative OoO (Cavium ThunderX V1 being a notable exception) which means it's vulnerable to spectre and meltdown attacks, whereas 32-bit ARM is exclusively in-order. if you want to GUARANTEE that you've got spectre-immune hardware you need either any 32-bit system (where even Cortex A7 has virtualisattion) or if 64-bit is absolutely required use Cortex A53. basically, abandoning or planning to abandon 32-bit ARM *right now* leaves security-conscious end-users in a really *really* dicey position. > We are currently unaware of any new architectures likely to be ready in > time for inclusion in buster. debian-riscv has been repeatedly asking for a single zero-impact line to be included in *one* file in *one* dpkg-related package which would allow riscv to stop being a NMU architecture and become part of debian/unstable (and quickly beyond), for at least six months, now. cc'ing the debian-riscv list because they will know the details about this. it's really quite ridiculous that a single one-line change having absolutely no effect on any other architecture whatsover is not being actioned and is holding debian-riscv back because of that. what is the reason why that package is not moving forward? l.
