Privacy-Centric Linux Distro Tails 3.0 Will Drop 32-Bit Processor Support (betanews.com) 97
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."
One line could use some explanation. (Score:4, Insightful)
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?
Re: One line could use some explanation. (Score:3, Informative)
As per Tails:
"software built for 64-bit processors can benefit from several improvements that make it harder for attackers to exploit security vulnerabilities (improved Address space layout randomization, compulsory support for the NX bit)."
Re: (Score:2, Interesting)
Re: (Score:3)
Generations of malware could expect an OS and memory to work in a set way and code for information gathering.
With 64 bit that information can be spread over memory in different ways or over a lot more memory beyond the limits of older systems malware.
Protecting is provided by making malware have to hunt for more secure details in more random places in memory every time on n
Re: (Score:1)
Please, most malware as-is today doesn't give two fucks about ASLR. They depend upon the practices taught today which results in shoddy bloated, vulnerable code.
These problems simply wouldn't happen if people knew how to code small and quit trying to make a program do everything. This is why Unix is so rock fucking solid.
Re: (Score:2)
It goes both ways. More modern systems also have more features that might be exploited, while older systems may have a much higher ratio of vulnerabilities already discovered and with workarounds for them.
And, of course, the number of attacks against a system is going to have at least some proportionality to how popular it is.
Re: (Score:3)
Re: (Score:1)
That's the purpose of this news, to encourage everyone to use 64 bit CPU with Intel's IME so everyone can be de-anonimized and tracked.
Re: (Score:2)
Just dump Intel and be more secure overall.
Re: (Score:2)
In favour of what exactly?
Re: (Score:2)
I'm replying here to explicitly doubt the author's assertion. It's a silly thing to be asserting. Security is not in the size of a system's registers or address bus. A good 32-bit SoC with crypto hardware may be much more secure than a 64-bit CPU.
Re: (Score:1)
seems to be time... (Score:1)
Consumer 64 bit CPUs have been around since the 2003 AMD Opteron, so getting on towards a decade and a half soon now. And workstation class 64 bit was available for many years before that.
It's cool that Linux itself supports really old hardware, but when it comes to a small distro team trying to support niche architectures, sometimes you have to pick your battles. If there's sufficient interest in 32 bit, then the interested parties can provide the necessary support.
Dealing with security and privacy is ha
Re:seems to be time... (Score:5, Interesting)
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.
How do they know... (Score:5, Interesting)
... that 4% of users are using 32-bit systems? Can't be that private if they're collecting telemetry from their own userbase...
Re:How do they know... (Score:5, Informative)
The official announcement [boum.org] says "These statistics are gathered from bug reports we have received from WhisperBack." WhisperBack is a voluntary, manual bug reporting system [boum.org] that comes with Tails. So they're only collecting "telemetry" from users who are voluntarily submitting it; that may not be the best barometer of who's using 32-bit systems, but it's all they have to go by.
Re: (Score:2)
As a comparison, Debian popcon [debian.org] shows i386 users being 27% of amd64's number, yet by counting bug reports filed after 2016-01-01 that include system information, that's 7%.
I see two possible explanations for this discrepancy: either i386 installations are old ones that were installed as such because the user didn't know better (the i386 installer was shown more prominently), or that such users are too untechnical to participate in filing reports.
In any case, getting a non-thoroughly-embedded machine without
Re: (Score:2)
A year or two ago, my dad (an avid dumpster diver) found a working and very clean Dell Latitude 32-bit D620 laptop. I shaved some parts off that I needed for my own D620 and sold the display+housing complete on Ebay, because...because.
I'm about to ditch the D620 altogether (in favor of kvm/qemu guest, possibly Tails) and then I will not have any more 32-bit x86 machines for my own personal purposes.
Re: (Score:2)
Not really, the Coppermine P3's are pretty efficient. A lot of them use less than 20W at full load until you start approaching the 1 GHz mark.
Re: (Score:1)
Debian supports multiarch, so many of us have i386 packages installed on the amd64 of Debian. Wine / Crossover does this a lot. That's another explanation for the discrepancy.
Re: (Score:2)
It could also mean that the software isn't yet 64 bit clean.
That's not good... (Score:5, Interesting)
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.
Re: (Score:1)
Or... you've been living under Taliban rule and now they've fled you've dug up your trusty old Commodore. What then, huh?
Re: (Score:1)
Free wi-fi is intriguing to me, but I don't see anything about wi-fi in your newsletter.
Re: (Score:2)
With 64 bit and better security, encryption and memory an application might just offer a bit more protection.
With very old computers a lot of interesting user details just exist in memory in set places for any security service to gather without much effort.
Computers that will be tracked and will face equipment interference need all the encryption and modern hardware support a developer can o
Re: (Score:2)
You have no access to modern computer, but could possibly scrape together some old computer parts to make one, perhaps an old discarded 32 bit laptop somewhere in the dumpsters in an oppressed country where even old computers are gold.
It may just be a sign of the times but a) if you're in such an oppressed country if the laptop is working you won't find it in a dumpster, and b) if you're not in quite such an oppressed country your dumpster laptop will very likely be 64bit anyway. Do remember that 64bit processors have been around for 15 years now. If your only source of equipment is older than this, being able to get software to run on it will be the least of your problems.
and focus more on safe communications
This is exactly why they are making the move.
Re: (Score:2)
AMD released the first intel-compatible 64 bit processors in 2000. That's almost 17 years ago. Sure, people kept buying 32-bit crap for a long while after that, but even Intel saw the writing on the wall, licensed the tech, and eventually mostly moved everything over to it.
It's more difficult to find electricity and an internet connection than it is to find a 64 bit machine in poverty-stricken and/or war-torn countries. I threw away my first 64-bit AMD machine well over a decade ago. I'm sure there's
BIOS for 32b x86 CPU's are not Backdoored ... (Score:1)
You have to go back over 10 years for Intel and a few generations for AMD to be able to build firmware for your mainboard that is all open source, without all the closed Blobs. So what's the point of a secure OS with a backdoored BIOS?
Inevitable (Score:5, Insightful)
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
Re: (Score:2)
The problem with Windows 10 (and Windows 8) is that it requires the NX bit be present on the processor. The NX bit came in around the same time as Intel was making the transition to 64-bit, so while there are a small handful of 32-bit processors that can run Windows 10, the vast majority of 32-bit Windows 10 systems are going to be running on 64-bit hardware because it won't boot on most 32-bit systems. So while you can run Tails (for now) on that Socket 478 P4 or Athlon XP, you can't run Windows 10 on it
Re: (Score:2)
Re: (Score:2)
it's also open source, if there is that many demand for a 32bit Tails somebody will pick it up and maintain it as a fork.
Re: (Score:2)
Re: (Score:3)
The grandparent poster is volunteering his time to make a thing that people like (DragonFly BSD). There are limited resources to be spread. Old versions will continue to work unmaintained, just like the old hardware does.
How much should he increase his effort to support smaller and smaller populations? If supporting x86 is a 15% "tax" on developer time and resources-- is it worth it if 10% of the userbase is x86-64? 5%? 1%? How long should we still be supporting things? 386's are still out there.
>
Re: (Score:1)
Switch to OpenBSD 6.0. They still release i386 versions and my little netbook runs happily.
OpenBSD still supports the following:
alpha Digital Alpha-based systems
amd64 AMD64-based systems
armv7 ARM-based devices, such as BeagleBone, BeagleBoard, PandaBoard ES, Cubox-i, SABRE Lite, Nitrogen6x and Wandboard
hppa Hewlett-Packard Precision Architecture (PA-RISC) systems
i386 Standard PC and clones based on the Intel i386 architecture and compatible processors
landisk IO-DATA Landisk systems
Re: (Score:2)
Yes, and get results like this: http://www.phoronix.com/scan.p... [phoronix.com]
Re: (Score:1)
Whoa hold on there!!
there's really no reason under the sun to continue to produce 32-bit cpus, even for highly embedded and IOT stuff.
You actually had me going until that. There are a whole slew of reasons why a lower byte count would be needed for embedded and IOT stuff. For example countless IOT applications are going to need to be low current - low power low heat devices controlled by low current low power processors. It sometime still feels like to me that many 64bit processors still require close proximity to a nuclear plant because of their current draw. Certainly nothing that can be powered by a small battery al
Re: (Score:3)
Yup, bigger CPUs take more power, there's no need for a large amount of address space (which is the only practical thing you get from 64-bit). I'm working on a system with 20kb RAM which has to run off of a small battery for more than a decade. 64-bit has no applicability there. If it's a PC then sure, the newer CPUs tend to be 64-bit but outside of the PC monoculture there is a whole lot of other stuff that can run linux where 32-bit could actually be more secure. The smartcard market has parts that ar
Re: (Score:2)
32-bit machines may eventually go away but, to argue that the reason for them to go away is "because kernel stuff is irritating" is crazy. Even if there is no reason to continue to produce 32-bit hardware, it will be around for *decades*. The number of 32-bit embedded ARM CPUs out there has got to number in the billions. Changing hardware is much, much harder than changing software so, as a kernel developer, I think you'll find it's a very uphill battle to "put an exclamation mark on that point". The ke
Re: (Score:2)
Why would they go away? 8-bit CPUs are still around and going strong.
Re: (Score:2)
(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.
If you think you can beat the power draw of the 8 bit PIC 10F series or some sort of attiny with a 64 bit (!) CPU then please send me whatever it is you're smoking because it's some good shit.
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 m
Re: (Score:1)
Those 8-bit systems aren't running Linux or *BSD, so bringing them up is irrelevant. Why even bother with them when you can't run Linux on this single transistor here?
Re: (Score:2)
Your claim doesn't stand up.
Very many embedded 32 bit cores are too small to rnu Linux and BSD as well, yet the OP claims there's no need to ever use a 32 bit ARM core when 64 bit ones exist. Embeddd stuff covers a vast amount of profiles from 8 bit with literally bytes of RAM to massive DSP beasts.
He's claiming that on 32 bit cores it's hard to implement some kernel feature if you have less than a gig of RAM. Hardly any embedded system has remotely that much.
Re: (Score:2)
They should just be clear and say "We're making linux for PeeCees. We don't understand other types of systems. We think 32-bit means old and 64-bit means new."
Re: (Score:2)
The cost of replacing that old machine is minimal. Live with it. It's part of the price of progress.
Some of us quite literally can't. Your "minimal" cost is over $150K for one of the machines I use, with the actual machine being maybe $600, the rest being software licenses to work on OS's newer than the mid 90's and interface adapters to work with machines more advanced than a Pentium II.
Surprising (Score:2)
Re: (Score:1)
I am a NetBSD fan, but OpenBSD is very similar and almost as portable. If it is capable of running NetBSD it exists. That's nearly the case, though I have some PalmPC devices that won't run NetBSD and Apple machines need to be new enough to sport a 68030 processor.
Seems a bit odd (Score:2)
Ok, I'll drop Tails then... (Score:2)
... as my preferred privacy-centric OS. It's not as if there weren't alternatives. And 32-bit machines will be good enough to access the internet for many years to come. I'm allergic to software producers forcing me to upgrade hardware for no reason, and seeing what the audience for systems like Tails is, the decision is even more despicable, and I'd expect there to be a lot of people who'll be much less inclined, if even able, to upgrade their hardware on a whim than I am.
As long as it compiles, (Score:1)
we will not remove 32-bit x86 support from T2SDE [t2-project.org]:
Also still got some mice 32-bit vintage machines, like Oqo01+ with Transmeta Efficieon, or Nokia Booklet 3G, with 32-bit only Atom Z, ...
In general I find it a bit sad to remove support to use older machines for poor families and third world countries.