Live data from Hacker News

Arch Linux pulls the plug on 32-bit

pcworld.com

131–140 of 201 posts

Re: Arch Linux pulls the plug on 32-bit

#131
post #73

Earlier quoted context omitted.

Except that python says that python 3 should be an executable named `python3` and `python` should refer to `python2` [0] 0: https://www.python.org/dev/peps/pep-0394/

It says right in the pep "...however, end users should be aware that python refers to python3 on at least Arch Linux (that change is what prompted the creation of this PEP), so python should be used in the shebang line only for scripts that are source compatible with both Python 2 and 3..." There was no guidance before the Arch devs made their choice. There's no reason to change back. Especially since the goal is tha…

There's a good reason to change back. There is now convention in place, and Arch's approach is obsolete.

Re: Arch Linux pulls the plug on 32-bit

#132
post #118

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.

The [multilib] (ie, 32-bit libraries on 64-bit installs) support isn't going anywhere.

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.

Re: Arch Linux pulls the plug on 32-bit

#133

Earlier quoted context omitted.

I agree, but I'd guess the chief complaint is that doing so requires the `python2` symlink to be available. There's at least one claim up thread that it doesn't exist on all systems (create it yourself?). I didn't catch the distribution used, but I DID check an older Ubuntu image I have (I run Arch) and there's definitely a python2 link pointing to python2.7 (`python` also points to python2.7 and there's a `python3`…

In 2017, indeed everyone has added python2, but I assure you it wasn't that way when Arch originally did the python3 -> python rename. While this is a small issue, this original thread used it as an example of how Arch is good and pragmatic. To me it seemed like the opposite -- it broke lots of code and packages for no good reason. Why should users of older distros have to add a symlink, when before Arch everyone cou…

> for no good reason.

There was good reason, to move to the latest version of a particular software, since that's kind of the whole philosophy of Arch, in fact the reason I originally switched to it in 2011 was because I had enough of me not being able to use the latest software on Ubuntu.

> Why should users of older distros have to add a symlink, when before Arch everyone could be sure that '/usr/bin/python' if present would be python2

If you made no effort to detect the actual version, it's wrong to assume that. It could've just as well been python 1.

Re: Arch Linux pulls the plug on 32-bit

#135

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…

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.

Ubuntu does this now with Xenial.

Re: Arch Linux pulls the plug on 32-bit

#136

Earlier quoted context omitted.

>They were always in the early birds for taking decision about the future What. It was Arch who * stuck to SysVinit and told users "you want Systemd, make a package" until long after the big distros had made the switch to Systemd/upstart ( https://en.wikipedia.org/wiki/Upstart ) * refused to sign packages properly, because "our users don't need that" It's exactly that kind of decision that makes me stay clear of it.…

Arch made systemd the default in October 2012, and added it to repos in January 2012. There's only one "major" OS that was earlier, which is Fedora - to be expected given that systemd is a red hat project. Suse was October 2014. Debian and Ubuntu were April 2015. RHEL was June 2014.

Ubuntu had Upstart in 9.04 (2009), as did others before they used systemd. I posted a source...

Re: Arch Linux pulls the plug on 32-bit

#137
post #101

Earlier quoted context omitted.

There are other distributions better suited (even specialized) to be run on old hardware.

There are brand new machines. Some haven't been released yet. They come with a tiny bit of ram 2 gb, 4 gb if you're lucky. The processor is 64 bit, but because of the small ram you'll suffer with a 64 bit OS. (Both Microsoft and Arch wiki agree here).

The "correct" solution to this problem is the x32 ABI [1]. I wouldn't be surprised if it's not well supported in the real world, however.

[1]: https://en.wikipedia.org/wiki/X32_ABI

Re: Arch Linux pulls the plug on 32-bit

#138
post #73

Earlier quoted context omitted.

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…

Except that python says that python 3 should be an executable named `python3` and `python` should refer to `python2` [0] 0: https://www.python.org/dev/peps/pep-0394/

Using the official, graphical installer for Python 3 on Windows with no previous version installed creates an executable 'python' that refers to Python 3.

(Normally not a Windows user so I have no idea why this is the case or if by design.)

Re: Arch Linux pulls the plug on 32-bit

#139
post #3

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.

There are a lot of things that gives bigger memory usage and larger code size that modern compilers do that we could try to address. * The stack is always kept aligned at 16 bytes boundary. This is needed for external calls by the ABI, but LTCG could drop these for internal calls and align the stack when needing SSE instead. This may be slightly more expensive than keeping the stack constantly 16-byte aligned, but it…

> * Inefficient instructions are replaced with more efficient instructions. For example gcc will for a simple x % 19 generate no less than 16 instructions instead of a single div/idiv. This is probably still faster, but it may still be detrimental if it's not in a hot path. It should be noted that gcc emits this even at -O0.

Does it emit it at -Os ?

Post reply on HN