Slashdot Mirror
Privacy-Centric Linux Distro Tails 3.0 Will Drop 32-Bit Processor Support (betanews.com)
All of its outgoing connections are routed through Tor, and it even blocks non-anonymous connections. You can carry it around on a USB stick, and Edward Snowden uses it. But a big change is coming with Tails 3.0. BrianFagioli quotes BetaNews: Unfortunately for some users, Tails will soon not work on their computers. The upcoming version 3.0 of the operating system is dropping 32-bit processor support. While a decline in compatibility is normally a bad thing, in this case, it is good. You see, because there are so few 32-bit Tails users, the team was wasting resources by supporting them. Not to mention, 64-bit processors are more secure too...
"In the beginning of 2016, only 4% of Tails users were still using a 32-bit computer. Of course, some of these computers will keep working for a while. But once the number had fallen this low, the benefits of switching Tails to 64-bit outweighed the reasons we had to keep supporting 32-bit computers," says the Tails team... "In the last few years, the developers who maintain Tails have spent lots of time addressing such issues. We would rather see them spend their time in ways that benefit our users on the long term, and not on problems that will vanish when Tails switches to 64-bit eventually."
"In the beginning of 2016, only 4% of Tails users were still using a 32-bit computer. Of course, some of these computers will keep working for a while. But once the number had fallen this low, the benefits of switching Tails to 64-bit outweighed the reasons we had to keep supporting 32-bit computers," says the Tails team... "In the last few years, the developers who maintain Tails have spent lots of time addressing such issues. We would rather see them spend their time in ways that benefit our users on the long term, and not on problems that will vanish when Tails switches to 64-bit eventually."
Not to mention, 64-bit processors are more secure too...
I'm not posting to doubt the author's assertion here, but rather to request more information: a link to the security benefits of one size over another would be nice. Is DEP something inherently impossible on 32-bit processors? Is the advantage really linked to word size, or is it more a function of new parts added to more recent processors?
... that 4% of users are using 32-bit systems? Can't be that private if they're collecting telemetry from their own userbase...
Considering who the platform was meant to help in the first place, this is not good news.
Imagine this scenario, you're an informer on the run, you have to hide because you've got a secret that must eventually get out to the public. You have no access to modern computer, but could possibly scrape together some old computer parts to make one, perhaps an old disgarded 32 bit laptop somewhere in the dumpsters in an opressed country where even old computers are gold.
And you can't install it because it requires a 64 bit processor, well - bummer.
Any other day I'd agree with that decision, but in this case - I think it should be as compatible as possible with as much hardware as possible, focus less on modern things, and focus more on safe communications.
What this world is coming to - is for you and me to decide.
Consumer 64 bit CPUs have been around since the 2003 AMD Opteron
Linux runs on many many embedded systems that are 32 bit, including plenty of new devices. It is likely that these are even the majority of running Linux instances. This particular distro may only be interested in the 64-bit desktop/laptop/server market, but many other distros would be foolish to abandon the embedded market.
We already dropped 32-bit support in DFly. There are many good reasons for doing it on Linux and the other BSDs as well. I will outline a few of them.
(1) The big reason is that kernel algorithms on FreeBSD, DragonFly, and Linux are starting to seriously rely on having a 64-bit address space to be able to properly size kernel data structures and KVM reservations. While (for FreeBSD) 32 bit builds still work, resource limitations are fairly confining relative to the resources that modern machines have (even 32-bit ones).
(2) Being able to have a DMAP makes kernel programming a whole lot easier. You can't have one on a 32-bit system unless you limit ram to something like 1GB. Being able to make a DMAP a kernel-standard requirement is important moving forwards.
(3) Modern systems are beginning to rely more and more (on x86 anyway) on having the %xmm registers available. To the point where many compilers now just assume that they will exist. ARM's 64-bit architecture also has some nice goodies that it would be nice to be able to rely on being available in-kernel.
(4) Optimizations for 64-bit systems create regressions on 32-bit systems. Memory copies, zeroing, and setmem, for example. Even if 32-bit support is kept, performance on those systems will continue to drop.
(5) There is a lot of ancient cruft in 32-bit code that we kernel programmers don't like to have to sift through. For example, being able to get rid of the EISA and most of the ISA support went a long ways towards cleaning up the codebase. Old drivers are a stick in the craw because nobody can test them any more, so the chances of them even working on an old system is reduced for every release. Eventually it gets to the point where there's no point trying to maintain the old driver.
(6) People should not expect modern features on old machines. The cost of replacing that old machine is minimal. Live with it. It's part of the price of progress. If the industry is a bit slow understanding what 'old' means, than the fewer systems which support these older architectures the better, it will make the point more obvious to the corporations who've lost their innovative edge.
(7) For ARM, going back to the corporate point, there's really no reason under the sun to continue to produce 32-bit cpus, even for highly embedded and IOT stuff. The world has moved on, and even embedded systems have major resource limitations in 32-bit configurations. If kernel programmers have to put an exclamation mark on that point, then so be it.
-Matt