31 ms·

Arch Linux pulls the plug on 32-bit

149 points by kxait 10y ago

nebulon 10y ago
Will be interesting if a part of the community "forks" arch like they did for 16bit back then. However lowarch is apparently also dead by now: http://www.lowarch.org/ http://www.lowarch.org/ I still have that installed on a i386 machine, but not booted since years.
- creshal 10y ago
  > I still have that installed on a i386 machine, but not booted since years. Did it even work usefully? While Linux itself retains backwards compatible drivers for a long time, X.org and others aren't quite as diligent. E.g., five years ago I could not run any up to date distribution on Pentium 4 era notebooks with anything more than unaccelerated VESA framebuffers, because there were no compatible drivers for their integrated graphics card any more. (At the same time, we still had Pentium 4 servers in production use!)
  - stinkytaco 10y ago
    I feel like this is a place where slackware shines. They keep pushing out security updates for years.
- rlpb 10y ago
  Do they need to fork? The reason given is "decreasing popularity of i686 among the developers and the community". If enough developers were prepared to maintain a fork, why wouldn't they just do it as part of the Arch project? As far as I can tell, they're not being turned away; it's being dropped because there isn't anyone to turn away.
nailer 10y ago
Other tech folk have always talked about 32 bit support as a necessary evil since smaller types mean less memory. The complexity of managing a secondary 32 bit environment has been worse than the memory usage of 64 bit apps for a very, very long time.
- __s 10y ago
  If people want 32 bit pointers on 64 bit hardware they should pick the x32 ABI instead
  - jwilk 10y ago
    ...which is not supported by Arch either.
    - Volundr 10y ago
      What do you mean? The announcement specifically says multilib is unaffected. I run 32-bit programs all the time.
      - dfox 10y ago
        Multilib is different concept from x32 ABI. Typical usecase for multilib is running i386 binaries that use i386 ABI on amd64 system (or sun4m binaries on sun4u, mips32 on mips64...), x32 ABI is alternate ABI for amd64 that uses 32bit pointers, but all other amd64 ISA extensions.
        Volundr 10y ago
        Today I learned something. Thanks!
    - andreyv 10y ago
      Even though it is not supported officially, you can install the x32 libraries from AUR: https://aur.archlinux.org/packages/?K=libx32 https://aur.archlinux.org/packages/?K=libx32
- joaomsa 10y ago
  That need has been met by the x32 ABI for some time now, it combines some of the best parts of the x86_64 arch with the lower memory consumption of 32bit (still limited to 4gb max memory though) https://en.wikipedia.org/wiki/X32_ABI https://en.wikipedia.org/wiki/X32_ABI
solnyshok 10y ago
they did not mention anything about Arch on 32-bit ARM. Still plenty of devices in the wild
- rhinoceraptor 10y ago
  Arch Linux ARM is a separate project to Arch Linux.
- coldpie 10y ago
  The ARM ports have never been "official" ports of Arch Linux. This announcement is about dropping one of the official ports, the 32-bit-only version.
dhekir 10y ago
One thing that concerns me is packaging desktop virtual machine images for easy reproducibility. We realized that some users do not (or cannot, due to security policies) turn on VT-x/AMD-V in their machines, and therefore Virtualbox and VMWare Player cannot run 64-bit guests. So we had to make 32-bit virtual machine images for them. If popular distros stop supporting 32-bit, we will have a harder time packaging such images, since we'll have to use a different distro for them, with different package names, settings, etc.
- ryanlol 10y ago
  This just means that you'll need to charge your customers more for supporting such obscure configurations.
  - ethagnawl 10y ago
    It also means they'll have fewer customers running 32-bit builds.
StreakyCobra 10y ago
It is one of the reasons that makes me love Arch: developers are pragmatic. They were always in the early birds for taking decision about the future, like switching to Python3 as default interpreter system-wide, embracing the change to systemd, and now this. The rolling release aspect imposes to stay as close as possible to upstream versions because upstream does not wait on Arch to update their dependencies to newer libraries versions. This, plus the fact that Arch tries to stay as close as possible to vanilla upstream packages (i.e. less changes as possible), force them to be pragmatic about their choices. They prefer to embrace a change directly when it is happening, encouraging at the same time to contribute upstream for helping them make the transition, instead of trying to maintain a legacy compatibility that can only get worse with the time. For me the picture is simple here: Arch is mostly used/oriented towards personal computers of power users, and most - if not all - of them are on 64 bit for years now. Instead of wasting efforts to maintain 32 bits compatibility, they prefer to drop it. Side effect will be that people will be encouraged to get a modern computer if not already.
- CJefferson 10y ago
  The switch to the 'python' command running python 3, as a non-arch user, put me off Arch forever. It just broke everything, which had long assumed 'python' would run python 2. Not installing python 2, and just python 3, with the name python3, would have been fine. Arch put us in a situation where it was basically impossible to run python 2 with a #! line, as some distros hadn't yet introduced a 'python2' symlink yet.
  - Asooka 10y ago
    In fairness, this was back when we all thought Py3 would take over Py2 "any day now"™
    - avian 10y ago
      "back then" the decision made even less sense, since a lot of efforts to make Python 3.x code backwards compatible did not happen yet. Like for instance the u'' literals introduced in 3.3.
gkya 10y ago
The original news on Archlinux.org: https://www.archlinux.org/news/phasing-out-i686-support/ https://www.archlinux.org/news/phasing-out-i686-support/
Koshkin 10y ago
Good for Arch, I guess. Still, there's plenty of uses for 32-bit platforms. Also, much of the attractiveness of Linux (the kernel) and the GNU software has always been in their excellent support for various architectures and platforms. Incidentally, wouldn't the exclusive use of 64-bit pointers (and size_t) prompted by the inflated need in large address spaces lead to an ever more increasing demand for memory (due to in-memory objects being now bigger in size)?
- gsnedders 10y ago
  > Incidentally, wouldn't the exclusive use of 64-bit pointers (and size_t) prompted by the inflated need in large address spaces lead to an ever more increasing demand for memory (due to in-memory objects being now bigger in size)? Yes. This is the reason why some people have pushed for "x32" support, and why Linux 3.4 and above supports it (tl;dr: x64-64, but with 32-bit pointers: you get all the advantages of x86-64 without the pointer bloat).
  - i336_ 10y ago
    Except processes can't use >4GB virtual memory. But wait. This could actually work out really well for Chrome, since it's multiprocess, and each process will likely consume <4GB. That is really cool. I've been wondering why Chrome on my T60 (64-bit but only 3GB RAM visible due to chipset stupidity) is noticeably, perceptibly slower and far more ready to swap itself to death than on my T43, which practically flies. (The T60 has a Core2 T7200, the T43 a Pentium M.) Bigger pointers sounds like a very interesting theory, especially considering the "enterprisey" nature of Chrome's C++ code - piles of vtables and pointers to pointers to callbacks to pointers to...
- StringEpsilon 10y ago
  All modern x86* CPUs are 64bit anyway and if this move means maintainers are freed up a bit, then I think it's worthwhile for the distro as a whole. Arch isn't really meant to be that one distro you can stick on a PC from the early nineties anyway. There are much more suitable distros for legacy hardware. And about the downsides of 64bit: I think the vastly improved address space offsets the improved memory use by orders of magnitues. My Desktop has 8 times as much useable RAM as it could have with 32bit - but 32bit datatypes are only double in size.
akoster 10y ago
It is a shame that many major Linux distributions are dropping 32-bit x86 support. I used to be able to say with confidence that the old laptop or PC in your garage can run any major Linux distribution, breathing new life into aging hardware. For example, I have an old ThinkPad T42, which I use to test out new Linux distros, which incidentally, is currently running Arch. Using older hardware increases the chances that stable drivers will be available. I put in the CD (or flash drive), boot up, and everything seems to just work(tm). Its no speed demon, but its usable. But now with Arch dropping support for a significant amount of commonly available and being a major, top-level distribution, I feel I now must make specific recommendations for Linux newcomers to try rather then have them waste time downloading a large ISO, transferring it to a flash drive or disc, to find they are unable to boot up with it. This may cause users to give up before even giving Linux or open source software an honest try. Also, I wonder what this means for the Intel Quark SoC (found in Intel Edison and Intel Galileo boards). Does this mean Arch Linux wont be an option for these devices? Despite RHEL 7/CentOS 7 not supporting 32-bit x86, there is now a community-led effort to port it to 32-bit x86. I wonder if Arch would consider doing the same (supporting 32-bit x86 as an alternative architecture).
- jonathonf 10y ago
  > I wonder if Arch would consider doing the same (supporting 32-bit x86 as an alternative architecture). Yes: https://lists.archlinux.org/pipermail/arch-ports/2017-January/000755.html https://lists.archlinux.org/pipermail/arch-ports/2017-Januar... (Also https://lists.archlinux.org/pipermail/arch-ports/2017-January/thread.html https://lists.archlinux.org/pipermail/arch-ports/2017-Januar...)
  - akoster 10y ago
    This is great news! Thanks for posting! I will definately keep an eye on this.
- cannam 10y ago
  > I have an old ThinkPad T42 I have a T40p running Arch which I still occasionally use, even for development, because it's just such a pleasing machine ergonomically. So I'm a bit concerned about this as well -- but then, I've been happily using Arch for years and it's not like I've ever contributed anything to the effort of maintaining it.
yAnonymous 10y ago
Reposted with added "upstart" so Arch fanboys can't nitpick their way out of this.
- morganvachon 10y ago
  > stuck to SysVinit and told users "you want Systemd, make a package" until long after the big distros had made the switch Bullshit, Arch was one of the first to switch to systemd as the default way back in 2012. The only "big distros" that switched before Arch were Fedora (obviously since that's where it came from), Mageia which is based on Fedora, and OpenSUSE (but not SLES). The next distro to switch was CoreOS a full year later, and Debian didn't switch until 2015. I'm not a fan of Arch anymore either, but if you're going to disparage any distro, at least get your facts straight. Edit: Getting my own facts straight: Mageia was based on Mandriva, not Fedora.
  - yAnonymous 10y ago
    Ubuntu and RHEL had Upstart for years before Arch made the switch to Systemd. SUSE beat them to it, too. https://en.wikipedia.org/wiki/Upstart https://en.wikipedia.org/wiki/Upstart New init systems were widely used long before Arch officially implemented them. Talking about facts, yours seem to be "alternate facts".
    - morganvachon 10y ago
      I was talking specifically about systemd as a rebuttal to the claim that Arch was the last distro to switch to it, when did Upstart ever come into the conversation?
      - yAnonymous 10y ago
        Flagging my post, because you're wrong? Very mature. Upstart and Systemd are both advanced init systems and Arch took long to implement them. That's the whole point. It doesn't really matter which one of them.
jasonkostempski 10y ago
FreeBSD did this too, right after I had just setup a local Minecraft server on an old Pentium D. It's a shame because it works perfectly for that purpose and now it'll just have to sit on FreeBSD 10 for the rest of it's life. I don't plan expose it to the outside world so that's OK for me, but surely 32-bit machines still have a purpose.
- peatmoss 10y ago
  OpenBSD and NetBSD both support i386 if you're looking for a BSD option.
  - jlgaddis 10y ago
    Yeah, so does FreeBSD. OP is mistaken.
- rolodato 10y ago
  Pentium D does support x64 as far as I can tell: https://en.wikipedia.org/wiki/Pentium_D https://en.wikipedia.org/wiki/Pentium_D > The Pentium D brand refers to two series of desktop dual-core 64-bit x86-64 microprocessors with the NetBurst microarchitecture, which is the dual-core variant of Pentium 4 "Prescott" manufactured by Intel.
- floatboth 10y ago
  Um, what?! Where did you find that? https://www.freebsd.org/where.html https://www.freebsd.org/where.html 11-RELEASE and 12-CURRENT snapshots are still being published for i386!
- ftigeot 10y ago
  As far as I know, the only BSD operating system to drop 32-bit support was DragonFly, back in 2014: https://www.dragonflybsd.org/release40/ https://www.dragonflybsd.org/release40/
  - JdeBP 10y ago
    PC-BSD dropped it with version 9.2, in 2013. * https://blog.pcbsd.org/2013/06/pc-bsd-status-update/ https://blog.pcbsd.org/2013/06/pc-bsd-status-update/
nspattak 10y ago
Damn, am I the only one who doesn't feel long ago when we were looking for 64bit distributions to test owr brand new opterons? Arch did not exist at the time(if I remember well).
TazeTSchnitzel 10y ago
32-bit is sometimes used on new hardware to save memory. For example, my Windows 10 tablet has only 1GiB of RAM, and I assume that's why it was pre-loaded with the 32-bit version. I doubt Linux distros are generally targeting these devices, though.
mhd 10y ago
Bad news for my old X60 Thinkpad (still the best laptop form factor I've ever owned).
- LukeShu 10y ago
  If you're interested, Parabola (an Arch derivative) is continuing i686 support pretty much solely because so many of the Parabola developers love their X60's (which is largely due to Libreboot support).
40acres 10y ago
Off topic: I've been in the market for a new laptop that runs Linux, I've never had a PC that ran Linux (closest thing was a Macbook running MacOS, I'm also discounting my work laptop that allows me to VNC into SuSe). After doing some research it seemed like Arch Linux might be a good fit, it seems like a very minimal OS that allows for great customization. However I'm unsure how user friendly it would be for someone who has never installed a Linux distro. Can anyone comment about their experiences with moving to Arch and the learning curve?
- the_commentary 10y ago
  To be honest Arch as a distro is more for advanced users -- if you're trying to dip your toes into linux the quintessential starting point is probably Ubuntu or ElementaryOS (linux mint is also pretty good). Arch's philosophy is very much to give you the bare minimum and then you can get what you need to stack on top of it, which often involves a bit of config tweaking. This might get frustrating if you aren't fairly intimate with working with a linux command line environment.
- sha666sum 10y ago
  Personally I started out with Arch on an old 64bit Atom netbook. I got a nice hobby out of it, and liked it so much I put it on all my computers. If you have a knack for googling and enjoy reading high quality wiki pages that document far beyond the scope of the operating system, you'll probably enjoy it. It requires patience and some time investment, but it's no rocket science.
- arca_vorago 10y ago
  "Can anyone comment about their experiences with moving to Arch and the learning curve?" To me arch is designed to force you to learn the guts of your system, so it has a relatively high learning curve but it is one that pays dividends in the form of understanding what your system is doing and how it is setup. (this aside from the side-effect of keeping it debloated and therefor fast) Honestly, what I would suggest is this: Step 1:(if you have the time) go through a full arch install. Now format and do it again without following the guide. Now maybe do it one more time. Step 2: (if pressed for time and/or lazy) Install Manjaro. I distro-hop frequently, and while I generally try to use debian on servers, for desktop/laptop use I have gone from Arch to Suse to Fedora, but I recently gave Majaro a shot, and I can honestly say next to Suse it has the easiest and most graceful linux installer I have ever seen (beating even Ubuntu). I generally don't like using Mint-like everything in a box distros, but the slimness of Arch along with the Just works of Ubuntu/Fedora/Suse I am finding it highly likely Manjaro is going to be my distro of choice for a long time to come. If in doubt, you can always just fire up different installs in a virtualbox first.
crimsonalucard 10y ago
I love the rolling release aspect of arch but I'm looking for something more user friendly. Anybody know of a good linux distro that is user friendly and has rolling releases?
- fiddlerwoaroof 10y ago
  Debian testing might work. I don't know if it is technically a rolling release distro but it stays up to date. Also OpenSuse tumbleweed. And there's a similar Fedora distro: rawhide, maybe?
  - EdwinHoksberg 10y ago
    Why use testing instead of unstable? (genuine question)
    - fiddlerwoaroof 10y ago
      I don't really know, I haven't seriously used unstable. That being said, I like testing because the packages are generally new enough for my purposes but they've also had more vetting, so I don't have to worry about a broken system as much.
- aaronmdjones 10y ago
  I've been using Linux Mint, Debian Edition, for years now. It's rolling.
- ctrlc-root 10y ago
  I'm curious why you think Arch is not user friendly? It's not the rolling release since you're asking for other distributions that use that model. I've used my fair share and from what I've seen Arch is by far the most user friendly.
  - crimsonalucard 10y ago
    User friendly in terms of I don't have to read documentation or learn anything to install it. Like windows or OSX. I'm sure Arch for what it is trying to be is user friendly in that sense, but it's not what I'm looking for right now.
pavanky 10y ago
The maintainers are dropping a hard requirement for 32 bit and asking the community to step up if they want to. 32 bit packages can and will continue to be still packaged under archlinux perhaps from [community] instead of [core]
shmerl 10y ago
What about supporting older 32-bit applications? Without 32-bit support, there won't be any way to run 32-bit games in Wine for example, unless Wine will somehow rewrite it all to work with underlying 64-bit libraries.
- LukeShu 10y ago
  The [multilib] (ie, 32-bit libraries on 64-bit installs) support isn't going anywhere.
  - shmerl 10y ago
    That's good! Though since the focus on 32-bit will decrease, it's possible that support for it in libraries will start deteriorating, and in the long term it can become an issue for use cases like Wine.
ChuckMcM 10y ago
This is unfortunate. One of the nice things about Arch was you could count on it to run on the older (32bit) systems.
imode 10y ago
welp, guess I'm switching to debian. I have a few 32 bit machines under my watch, and this is disheartening.
- anonbanker 10y ago
  Switch to Devuan instead, unless you really have a thing for systemd.
v0v 10y ago
Any one still wanting to install 32-bit with XFCE and easy GUI installer, see; https://manjaro.org/get-manjaro/ https://manjaro.org/get-manjaro/ Or simply use "Manjaro Minimal Net Edition (32-bit)" Another alternative is to use BlackArch (32-bit) https://blackarch.org/downloads.html https://blackarch.org/downloads.html

149 points by kxait 10y ago

Will be interesting if a part of the community "forks" arch like they did for 16bit back then. However lowarch is apparently also dead by now: http://www.lowarch.org/ http://www.lowarch.org/ I still have that installed on a i386 machine, but not booted since years.

creshal 10y ago
> I still have that installed on a i386 machine, but not booted since years. Did it even work usefully? While Linux itself retains backwards compatible drivers for a long time, X.org and others aren't quite as diligent. E.g., five years ago I could not run any up to date distribution on Pentium 4 era notebooks with anything more than unaccelerated VESA framebuffers, because there were no compatible drivers for their integrated graphics card any more. (At the same time, we still had Pentium 4 servers in production use!)
- stinkytaco 10y ago
  I feel like this is a place where slackware shines. They keep pushing out security updates for years.
rlpb 10y ago
Do they need to fork? The reason given is "decreasing popularity of i686 among the developers and the community". If enough developers were prepared to maintain a fork, why wouldn't they just do it as part of the Arch project? As far as I can tell, they're not being turned away; it's being dropped because there isn't anyone to turn away.

nailer 10y ago

Other tech folk have always talked about 32 bit support as a necessary evil since smaller types mean less memory. The complexity of managing a secondary 32 bit environment has been worse than the memory usage of 64 bit apps for a very, very long time.

__s 10y ago
If people want 32 bit pointers on 64 bit hardware they should pick the x32 ABI instead
- jwilk 10y ago
  ...which is not supported by Arch either.
  - Volundr 10y ago
    What do you mean? The announcement specifically says multilib is unaffected. I run 32-bit programs all the time.
    - dfox 10y ago
      Multilib is different concept from x32 ABI. Typical usecase for multilib is running i386 binaries that use i386 ABI on amd64 system (or sun4m binaries on sun4u, mips32 on mips64...), x32 ABI is alternate ABI for amd64 that uses 32bit pointers, but all other amd64 ISA extensions.
      - Volundr 10y ago
        Today I learned something. Thanks!
  - andreyv 10y ago
    Even though it is not supported officially, you can install the x32 libraries from AUR: https://aur.archlinux.org/packages/?K=libx32 https://aur.archlinux.org/packages/?K=libx32
joaomsa 10y ago
That need has been met by the x32 ABI for some time now, it combines some of the best parts of the x86_64 arch with the lower memory consumption of 32bit (still limited to 4gb max memory though) https://en.wikipedia.org/wiki/X32_ABI https://en.wikipedia.org/wiki/X32_ABI

solnyshok 10y ago

they did not mention anything about Arch on 32-bit ARM. Still plenty of devices in the wild

rhinoceraptor 10y ago
Arch Linux ARM is a separate project to Arch Linux.
coldpie 10y ago
The ARM ports have never been "official" ports of Arch Linux. This announcement is about dropping one of the official ports, the 32-bit-only version.

dhekir 10y ago

One thing that concerns me is packaging desktop virtual machine images for easy reproducibility. We realized that some users do not (or cannot, due to security policies) turn on VT-x/AMD-V in their machines, and therefore Virtualbox and VMWare Player cannot run 64-bit guests. So we had to make 32-bit virtual machine images for them. If popular distros stop supporting 32-bit, we will have a harder time packaging such images, since we'll have to use a different distro for them, with different package names, settings, etc.

ryanlol 10y ago
This just means that you'll need to charge your customers more for supporting such obscure configurations.
- ethagnawl 10y ago
  It also means they'll have fewer customers running 32-bit builds.

StreakyCobra 10y ago

It is one of the reasons that makes me love Arch: developers are pragmatic. They were always in the early birds for taking decision about the future, like switching to Python3 as default interpreter system-wide, embracing the change to systemd, and now this. The rolling release aspect imposes to stay as close as possible to upstream versions because upstream does not wait on Arch to update their dependencies to newer libraries versions. This, plus the fact that Arch tries to stay as close as possible to vanilla upstream packages (i.e. less changes as possible), force them to be pragmatic about their choices. They prefer to embrace a change directly when it is happening, encouraging at the same time to contribute upstream for helping them make the transition, instead of trying to maintain a legacy compatibility that can only get worse with the time. For me the picture is simple here: Arch is mostly used/oriented towards personal computers of power users, and most - if not all - of them are on 64 bit for years now. Instead of wasting efforts to maintain 32 bits compatibility, they prefer to drop it. Side effect will be that people will be encouraged to get a modern computer if not already.

CJefferson 10y ago
The switch to the 'python' command running python 3, as a non-arch user, put me off Arch forever. It just broke everything, which had long assumed 'python' would run python 2. Not installing python 2, and just python 3, with the name python3, would have been fine. Arch put us in a situation where it was basically impossible to run python 2 with a #! line, as some distros hadn't yet introduced a 'python2' symlink yet.
- Asooka 10y ago
  In fairness, this was back when we all thought Py3 would take over Py2 "any day now"™
  - avian 10y ago
    "back then" the decision made even less sense, since a lot of efforts to make Python 3.x code backwards compatible did not happen yet. Like for instance the u'' literals introduced in 3.3.

gkya 10y ago

The original news on Archlinux.org: https://www.archlinux.org/news/phasing-out-i686-support/ https://www.archlinux.org/news/phasing-out-i686-support/

Koshkin 10y ago

Good for Arch, I guess. Still, there's plenty of uses for 32-bit platforms. Also, much of the attractiveness of Linux (the kernel) and the GNU software has always been in their excellent support for various architectures and platforms. Incidentally, wouldn't the exclusive use of 64-bit pointers (and size_t) prompted by the inflated need in large address spaces lead to an ever more increasing demand for memory (due to in-memory objects being now bigger in size)?

gsnedders 10y ago
> Incidentally, wouldn't the exclusive use of 64-bit pointers (and size_t) prompted by the inflated need in large address spaces lead to an ever more increasing demand for memory (due to in-memory objects being now bigger in size)? Yes. This is the reason why some people have pushed for "x32" support, and why Linux 3.4 and above supports it (tl;dr: x64-64, but with 32-bit pointers: you get all the advantages of x86-64 without the pointer bloat).
- i336_ 10y ago
  Except processes can't use >4GB virtual memory. But wait. This could actually work out really well for Chrome, since it's multiprocess, and each process will likely consume <4GB. That is really cool. I've been wondering why Chrome on my T60 (64-bit but only 3GB RAM visible due to chipset stupidity) is noticeably, perceptibly slower and far more ready to swap itself to death than on my T43, which practically flies. (The T60 has a Core2 T7200, the T43 a Pentium M.) Bigger pointers sounds like a very interesting theory, especially considering the "enterprisey" nature of Chrome's C++ code - piles of vtables and pointers to pointers to callbacks to pointers to...
StringEpsilon 10y ago
All modern x86* CPUs are 64bit anyway and if this move means maintainers are freed up a bit, then I think it's worthwhile for the distro as a whole. Arch isn't really meant to be that one distro you can stick on a PC from the early nineties anyway. There are much more suitable distros for legacy hardware. And about the downsides of 64bit: I think the vastly improved address space offsets the improved memory use by orders of magnitues. My Desktop has 8 times as much useable RAM as it could have with 32bit - but 32bit datatypes are only double in size.

akoster 10y ago

It is a shame that many major Linux distributions are dropping 32-bit x86 support. I used to be able to say with confidence that the old laptop or PC in your garage can run any major Linux distribution, breathing new life into aging hardware. For example, I have an old ThinkPad T42, which I use to test out new Linux distros, which incidentally, is currently running Arch. Using older hardware increases the chances that stable drivers will be available. I put in the CD (or flash drive), boot up, and everything seems to just work(tm). Its no speed demon, but its usable. But now with Arch dropping support for a significant amount of commonly available and being a major, top-level distribution, I feel I now must make specific recommendations for Linux newcomers to try rather then have them waste time downloading a large ISO, transferring it to a flash drive or disc, to find they are unable to boot up with it. This may cause users to give up before even giving Linux or open source software an honest try. Also, I wonder what this means for the Intel Quark SoC (found in Intel Edison and Intel Galileo boards). Does this mean Arch Linux wont be an option for these devices? Despite RHEL 7/CentOS 7 not supporting 32-bit x86, there is now a community-led effort to port it to 32-bit x86. I wonder if Arch would consider doing the same (supporting 32-bit x86 as an alternative architecture).

jonathonf 10y ago
> I wonder if Arch would consider doing the same (supporting 32-bit x86 as an alternative architecture). Yes: https://lists.archlinux.org/pipermail/arch-ports/2017-January/000755.html https://lists.archlinux.org/pipermail/arch-ports/2017-Januar... (Also https://lists.archlinux.org/pipermail/arch-ports/2017-January/thread.html https://lists.archlinux.org/pipermail/arch-ports/2017-Januar...)
- akoster 10y ago
  This is great news! Thanks for posting! I will definately keep an eye on this.
cannam 10y ago
> I have an old ThinkPad T42 I have a T40p running Arch which I still occasionally use, even for development, because it's just such a pleasing machine ergonomically. So I'm a bit concerned about this as well -- but then, I've been happily using Arch for years and it's not like I've ever contributed anything to the effort of maintaining it.

yAnonymous 10y ago

Reposted with added "upstart" so Arch fanboys can't nitpick their way out of this.

morganvachon 10y ago
> stuck to SysVinit and told users "you want Systemd, make a package" until long after the big distros had made the switch Bullshit, Arch was one of the first to switch to systemd as the default way back in 2012. The only "big distros" that switched before Arch were Fedora (obviously since that's where it came from), Mageia which is based on Fedora, and OpenSUSE (but not SLES). The next distro to switch was CoreOS a full year later, and Debian didn't switch until 2015. I'm not a fan of Arch anymore either, but if you're going to disparage any distro, at least get your facts straight. Edit: Getting my own facts straight: Mageia was based on Mandriva, not Fedora.
- yAnonymous 10y ago
  Ubuntu and RHEL had Upstart for years before Arch made the switch to Systemd. SUSE beat them to it, too. https://en.wikipedia.org/wiki/Upstart https://en.wikipedia.org/wiki/Upstart New init systems were widely used long before Arch officially implemented them. Talking about facts, yours seem to be "alternate facts".
  - morganvachon 10y ago
    I was talking specifically about systemd as a rebuttal to the claim that Arch was the last distro to switch to it, when did Upstart ever come into the conversation?
    - yAnonymous 10y ago
      Flagging my post, because you're wrong? Very mature. Upstart and Systemd are both advanced init systems and Arch took long to implement them. That's the whole point. It doesn't really matter which one of them.

jasonkostempski 10y ago

FreeBSD did this too, right after I had just setup a local Minecraft server on an old Pentium D. It's a shame because it works perfectly for that purpose and now it'll just have to sit on FreeBSD 10 for the rest of it's life. I don't plan expose it to the outside world so that's OK for me, but surely 32-bit machines still have a purpose.

peatmoss 10y ago
OpenBSD and NetBSD both support i386 if you're looking for a BSD option.
- jlgaddis 10y ago
  Yeah, so does FreeBSD. OP is mistaken.
rolodato 10y ago
Pentium D does support x64 as far as I can tell: https://en.wikipedia.org/wiki/Pentium_D https://en.wikipedia.org/wiki/Pentium_D > The Pentium D brand refers to two series of desktop dual-core 64-bit x86-64 microprocessors with the NetBurst microarchitecture, which is the dual-core variant of Pentium 4 "Prescott" manufactured by Intel.
floatboth 10y ago
Um, what?! Where did you find that? https://www.freebsd.org/where.html https://www.freebsd.org/where.html 11-RELEASE and 12-CURRENT snapshots are still being published for i386!
ftigeot 10y ago
As far as I know, the only BSD operating system to drop 32-bit support was DragonFly, back in 2014: https://www.dragonflybsd.org/release40/ https://www.dragonflybsd.org/release40/
- JdeBP 10y ago
  PC-BSD dropped it with version 9.2, in 2013. * https://blog.pcbsd.org/2013/06/pc-bsd-status-update/ https://blog.pcbsd.org/2013/06/pc-bsd-status-update/

nspattak 10y ago

Damn, am I the only one who doesn't feel long ago when we were looking for 64bit distributions to test owr brand new opterons? Arch did not exist at the time(if I remember well).

TazeTSchnitzel 10y ago

32-bit is sometimes used on new hardware to save memory. For example, my Windows 10 tablet has only 1GiB of RAM, and I assume that's why it was pre-loaded with the 32-bit version. I doubt Linux distros are generally targeting these devices, though.

mhd 10y ago

Bad news for my old X60 Thinkpad (still the best laptop form factor I've ever owned).

LukeShu 10y ago
If you're interested, Parabola (an Arch derivative) is continuing i686 support pretty much solely because so many of the Parabola developers love their X60's (which is largely due to Libreboot support).

40acres 10y ago

Off topic: I've been in the market for a new laptop that runs Linux, I've never had a PC that ran Linux (closest thing was a Macbook running MacOS, I'm also discounting my work laptop that allows me to VNC into SuSe). After doing some research it seemed like Arch Linux might be a good fit, it seems like a very minimal OS that allows for great customization. However I'm unsure how user friendly it would be for someone who has never installed a Linux distro. Can anyone comment about their experiences with moving to Arch and the learning curve?

the_commentary 10y ago
To be honest Arch as a distro is more for advanced users -- if you're trying to dip your toes into linux the quintessential starting point is probably Ubuntu or ElementaryOS (linux mint is also pretty good). Arch's philosophy is very much to give you the bare minimum and then you can get what you need to stack on top of it, which often involves a bit of config tweaking. This might get frustrating if you aren't fairly intimate with working with a linux command line environment.
sha666sum 10y ago
Personally I started out with Arch on an old 64bit Atom netbook. I got a nice hobby out of it, and liked it so much I put it on all my computers. If you have a knack for googling and enjoy reading high quality wiki pages that document far beyond the scope of the operating system, you'll probably enjoy it. It requires patience and some time investment, but it's no rocket science.
arca_vorago 10y ago
"Can anyone comment about their experiences with moving to Arch and the learning curve?" To me arch is designed to force you to learn the guts of your system, so it has a relatively high learning curve but it is one that pays dividends in the form of understanding what your system is doing and how it is setup. (this aside from the side-effect of keeping it debloated and therefor fast) Honestly, what I would suggest is this: Step 1:(if you have the time) go through a full arch install. Now format and do it again without following the guide. Now maybe do it one more time. Step 2: (if pressed for time and/or lazy) Install Manjaro. I distro-hop frequently, and while I generally try to use debian on servers, for desktop/laptop use I have gone from Arch to Suse to Fedora, but I recently gave Majaro a shot, and I can honestly say next to Suse it has the easiest and most graceful linux installer I have ever seen (beating even Ubuntu). I generally don't like using Mint-like everything in a box distros, but the slimness of Arch along with the Just works of Ubuntu/Fedora/Suse I am finding it highly likely Manjaro is going to be my distro of choice for a long time to come. If in doubt, you can always just fire up different installs in a virtualbox first.

crimsonalucard 10y ago

I love the rolling release aspect of arch but I'm looking for something more user friendly. Anybody know of a good linux distro that is user friendly and has rolling releases?

fiddlerwoaroof 10y ago
Debian testing might work. I don't know if it is technically a rolling release distro but it stays up to date. Also OpenSuse tumbleweed. And there's a similar Fedora distro: rawhide, maybe?
- EdwinHoksberg 10y ago
  Why use testing instead of unstable? (genuine question)
  - fiddlerwoaroof 10y ago
    I don't really know, I haven't seriously used unstable. That being said, I like testing because the packages are generally new enough for my purposes but they've also had more vetting, so I don't have to worry about a broken system as much.
aaronmdjones 10y ago
I've been using Linux Mint, Debian Edition, for years now. It's rolling.
ctrlc-root 10y ago
I'm curious why you think Arch is not user friendly? It's not the rolling release since you're asking for other distributions that use that model. I've used my fair share and from what I've seen Arch is by far the most user friendly.
- crimsonalucard 10y ago
  User friendly in terms of I don't have to read documentation or learn anything to install it. Like windows or OSX. I'm sure Arch for what it is trying to be is user friendly in that sense, but it's not what I'm looking for right now.

pavanky 10y ago

The maintainers are dropping a hard requirement for 32 bit and asking the community to step up if they want to. 32 bit packages can and will continue to be still packaged under archlinux perhaps from [community] instead of [core]

shmerl 10y ago

What about supporting older 32-bit applications? Without 32-bit support, there won't be any way to run 32-bit games in Wine for example, unless Wine will somehow rewrite it all to work with underlying 64-bit libraries.

LukeShu 10y ago
The [multilib] (ie, 32-bit libraries on 64-bit installs) support isn't going anywhere.
- shmerl 10y ago
  That's good! Though since the focus on 32-bit will decrease, it's possible that support for it in libraries will start deteriorating, and in the long term it can become an issue for use cases like Wine.

ChuckMcM 10y ago

This is unfortunate. One of the nice things about Arch was you could count on it to run on the older (32bit) systems.

imode 10y ago

welp, guess I'm switching to debian. I have a few 32 bit machines under my watch, and this is disheartening.

anonbanker 10y ago
Switch to Devuan instead, unless you really have a thing for systemd.

v0v 10y ago

Any one still wanting to install 32-bit with XFCE and easy GUI installer, see; https://manjaro.org/get-manjaro/ https://manjaro.org/get-manjaro/ Or simply use "Manjaro Minimal Net Edition (32-bit)" Another alternative is to use BlackArch (32-bit) https://blackarch.org/downloads.html https://blackarch.org/downloads.html