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.
Arch Linux pulls the plug on 32-bit
51–60 of 201 posts
Re: Arch Linux pulls the plug on 32-bit
#52Earlier quoted context omitted.
There are other distributions better suited (even specialized) to be run on old hardware.
Which ones provide a similar approach to Arch? A six-year-old 32-bit processor (e.g. an Atom in an EeePC 901 or HP Mini 311c) is more than capable of running a modern desktop system.
I understand that some people would like to keep Arch 32 bit for their use cases. But as any open source project, the developer are mostly working on it on their spare time, you can not force them to work on anything. Having followed a little bit the discussion on the mailing list [1], I don't remember having seen a lot of objection among the developers. Also, they encourage the creation of a community around i686 [2]:
However, as there is still some interest in keeping i686 alive, we would like to encourage the community to make it happen with our guidance. The arch-ports mailing list and #archlinux-ports IRC channel on Freenode will be used for further coordination.
So if there are people willing to do the job, Arch will still be usable on 1686.[1] https://lists.archlinux.org/pipermail/arch-dev-public/2016-D... [2] https://www.archlinux.org/news/phasing-out-i686-support/
Re: Arch Linux pulls the plug on 32-bit
#53Earlier quoted context omitted.
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.
So to avoid re-opening the debate of Python 2 vs Python 3, let's take this point of view: The Python 3 language may, or may not, have been an improvement, and the transition from 2 to 3 may, or may not, have been done correctly. Everyone has its own opinion on this. But at the end this problem concerns the Python community. From the Arch developers point of view, the Python developers decided to release a new version…
They both contained Python scripts, and I had to waste my time figuring out why they had broken when I had e-mails from Arch users complaining they didn't work -- and then keep replying to future Arch users with the fix.
I don't know how many hours and days of other developer's time was wasted by Arch with this change, but it certainly wasted a good day of my time over the last few years.
Re: Arch Linux pulls the plug on 32-bit
#54It 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 tha…
> 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?
I have a device based on the Quark SoC. Support is abysmal for this SoC, especially considering it's been on the market for 3 years (2014). Intel has clearly abandoned this market segment since their repeated headlines of new Quark SoCs has totalled exactly 0 new product launches since 2014.
In mainline Linux I can't use the onboard Ethernet because of some modifications Intel made to the stmmaceth module that weren't pushed upstream. The internet is full of people trying to run newer versions of Linux on their Quark hardware and Intel telling them to use old Yocto Linux BSPs [0] because they can't be bothered to clean up and push their code upstream (or upstream refused to merge it, I don't know and haven't checked).
Also the Quark is affected by the F0 0F bug, so you can't run normal distributions on it because processes will segfault. [1]
> It might solve this issue for Intel Quark, but it would break for any multicore processors. This is not something acceptable.
Honestly I'm not sure why anyone would want to buy a Quark based system. Support is bad, performance is terribad, and power consumption is also terrible (my Quark system idles at 7W, and consumes 2W when in S5 "off" state). You would be very wise to look for an ARM instead of choosing this dumpster fire of a CPU.
[0] https://communities.intel.com/thread/105047
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738575
Re: Arch Linux pulls the plug on 32-bit
#55It 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…
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.
Re: Arch Linux pulls the plug on 32-bit
#56It 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…
> Side effect will be that people will be encouraged to get a modern computer if not already. All those netbooks (atom processors; 1 GB or 2 GB ram; 32 GB hard drive) would be great with Linux (once the drivers get fixed) and really benefit from 32 bit because of the ram limitations. Now? They'll end up in landfill.
Re: Arch Linux pulls the plug on 32-bit
#57Earlier quoted context omitted.
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.
What I wonder is why one would assume the python command would run python 2, instead of running python 1, assuming python 1 was a thing. By your logic, shouldn't python2, run python3 run python 3, etc. What I'm getting at, is we get used to things being a certain way, but often we're just following a convention that was set in place before we got onboard. Why do we still type "bash" instead of "bash4"?
The reason we don't need a 'bash4' is that, by and large, bash tried very hard to make sure they didn't break any bash3 scripts, so there is no need for old bash3 scripts to know they are now running in bash4, unlike python3.
Re: Arch Linux pulls the plug on 32-bit
#58Earlier quoted context omitted.
> 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…
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 New init systems were widely used long before Arch officially implemented them. Talking about facts, yours seem to be "alternate facts".
Re: Arch Linux pulls the plug on 32-bit
#59Other 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.
x86 isn't just 32-bit. Linux distros have been reluctant to upgrade their notion of 32-bit x86 to require SSE2. This means that x86 isn't just 32-bit but involves weird 387 floating-point math when other mainstream architectures use IEEE floating-point math.
Re: Arch Linux pulls the plug on 32-bit
#60Earlier quoted context omitted.
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 New init systems were widely used long before Arch officially implemented them. Talking about facts, yours seem to be "alternate facts".
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?
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.