Live data from Hacker News

Arch Linux pulls the plug on 32-bit

pcworld.com

161–170 of 201 posts

Re: Arch Linux pulls the plug on 32-bit

#161
post #102
post #76

Earlier quoted context omitted.

I'm an Arch user, and it literally broke nothing for me. Packages were updated, life went on. You seem to be complaining because other distros hadn't done the right thing. I don't see how that's Arch's fault. Are we to hold back for the lowest common denominator? Do we need every distro to join together and agree to a switchover date? There was official guidance from Python on the switchover, this wasn't some maveric…

My Python 2 scripts on Github start with "#!/usr/bin/python", as do many others. All of these broke for you as an Arch user. Because Arch did what they did, Python now recommends that Python 2 scripts start "#!/usr/bin/python2" (or the env equivalent). > Are we to hold back for the lowest common denominator? Do we need every distro to join together and agree to a switchover date? It's not just other distros; it's the…

This just feels like culture clash to me - the whole change to Python 3 was about accepting the cost of breaking changes to avoid dragging around useless cruft and bad decisions forever.

The idea that we should then never use `python` to mean `python3` is just so backwards. Sure, in your corporate environment where backwards compatability is suepr important, do that.

In Arch, people have a distro that moves fast and breaks things, and we are fine with that. I'll accept the cost of occasionally having to change a shebang line (although as I have almost never had to go outside the AUR - someone else in the Arch community has almost always dealt with this for me).

> No, there wasn't, and yes, it was some maverick decision. It was done without consultation with upstream.

Fair enough, I got my timelines mixed up - but to be fair, it was then ratified as the correct way to do things because the upstream project agreed with the core idea.

> The right way to migrate would be to ship and use both /usr/bin/python2 and /usr/bin/python3. Leave /usr/bin/python as a symlink to python2 for a while. Eventually, drop the symlink, but do not replace it with python3. Allow users to opt-in to a compat symlink if they wish. Let stuff catch up. When the expectation that "python" is python2 has faded, then introduce a symlink from python to python3 by default, letting users opt-in earlier if they wish.

I don't really see why I should have to do this manually? If you don't want that behaviour, use another distro. This just feels like you feel like you should have some say in how other people set up their systems.

If you really hate it so much, don't support Arch - that'd be fair. Trying to shame the distro for doing it ignores the fact it's the core idea of the distro to do stuff like that, that's the point.

Re: Arch Linux pulls the plug on 32-bit

#162

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.

Lets hope Python 4 comes out soon so you guys can unite against the real enemy :-)

Re: Arch Linux pulls the plug on 32-bit

#163
post #109

Earlier quoted context omitted.

No. Before Arch made their change, that /usr/bin/python is Python 2 was the only possible assumption that could be made. No distribution shipped /usr/bin/python2 at that time. There was no need, because /usr/bin/python was always Python 2. It was only because of what Arch unilaterally did that forced the community to start providing a /usr/bin/python2. Before that, /usr/bin/python2 did not commonly exist at all.

> It was only because of what Arch unilaterally did Arch is a bleeding-edge, latest software kind of distribution. They did not made the decision 'unilaterally'. They made the decision to ship the latest software for their own distribution, as they always do. It may have proven that a lot of software is extremely poor/inflexible, (i.e. rests on weak assumptions), but I am glad Arch moved forward as that showed their…

> They made the decision to ship the latest software for their own distribution, as they always do.

As did all the other distributions. Shipping Python 3 is not the issue here. Breaking compatibility with all existing Python 2 scripts is what they did. The two are not mutually exclusive.

> I just think that instead of blaming Arch, try to make your scripts more robust, i.e. loop on all 'python' binaries in /usr/bin...

You want me to do that in a shebang line? No. That'd be crazy.

> ...when the latest version is 3 and Arch is known to ship latest software.

See https://en.wikipedia.org/wiki/Application_binary_interface. What Arch did was break the ABI of what /usr/bin/python means, breaking all scripts that relied on that ABI. Shipping the latest software is orthogonal to this. The rest of the world ships the latest software too, but without breaking ABI.

Re: Arch Linux pulls the plug on 32-bit

#164
post #161
post #102

Earlier quoted context omitted.

My Python 2 scripts on Github start with "#!/usr/bin/python", as do many others. All of these broke for you as an Arch user. Because Arch did what they did, Python now recommends that Python 2 scripts start "#!/usr/bin/python2" (or the env equivalent). > Are we to hold back for the lowest common denominator? Do we need every distro to join together and agree to a switchover date? It's not just other distros; it's the…

This just feels like culture clash to me - the whole change to Python 3 was about accepting the cost of breaking changes to avoid dragging around useless cruft and bad decisions forever. The idea that we should then never use `python` to mean `python3` is just so backwards. Sure, in your corporate environment where backwards compatability is suepr important, do that. In Arch, people have a distro that moves fast and…

> The idea that we should then never use `python` to mean `python3` is just so backwards.

I did not present any such idea. I presented a sane migration path to where `python` means `python3`.

> ...it was then ratified as the correct way to do things because the upstream project agreed with the core idea.

No. It was because the upstream project had their hand forced and are pragmatic about these things.

> I don't really see why I should have to do this manually?

In my proposal for a sane migration path to the ideal? You wouldn't have to do it manually. The distribution would do it. As a user you'd be able to override it to speed up the migration for yourself if you chose; that's all.

Re: Arch Linux pulls the plug on 32-bit

#166

Earlier quoted context omitted.

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 pres…

> 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.

It's funny. My reason for switching to Arch was almost the opposite. I grew tired of having to rebuild the latest software in Gentoo every time I updated and ran into someone on Slashdot who encouraged me to give Arch a try. Sure, there's more prebuilt packages, mirrors, etc for Gentoo these days, but then you're in the same boat as everyone else (waiting for the package to be built).

Re: Arch Linux pulls the plug on 32-bit

#167
post #153

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`…

You're right. - If Arch is targeted for power users, what's preventing them from configuring symlinks etc? - Why aren't they using virtualenvs? I never install Python packages outside of a virtualenv.

> I never install Python packages outside of a virtualenv.

Global site-packages is all fun and games until someone loses an eye (or a dependency).

I had a fun learning experience with a large Python package once while trying to mix and match dependency versions, simultaneously trying to avoid clobbering the ones already installed by pacman. Without a virtualenv, it quickly becomes impossible to guarantee you won't break something in the process of installing something else. I never made that mistake again.

Re: Arch Linux pulls the plug on 32-bit

#168

Earlier quoted context omitted.

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

It seems to me that Arch established their convention first, so why should Arch "change back" when they where first; why are others not "changing back" to Arch's convention, given that Arch's came first? Well, the answer is that this is a silly discussion. Arch is doing what Arch is doing because Arch is intentionally forward oriented, sometimes to the detriment of backwards compatibility with the old school (and yes…

A particular convention has been adopted by nearly all distros, the Python project and the Python community. That convention is better than Arch's, because it is backwards-compatible with the large body of Python 2 code that exists.

Arch's change angered many in the Python community, and broke a lot of code. That Arch refuse to adopt the established convention, because it would involve admitting a mistake, shows a distinct lack of professionalism.

Re: Arch Linux pulls the plug on 32-bit

#169

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.

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/

PC-BSD dropped it with version 9.2, in 2013.

* https://blog.pcbsd.org/2013/06/pc-bsd-status-update/

Re: Arch Linux pulls the plug on 32-bit

#170
post #84

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…

Try Manjaro Linux (https://manjaro.org/)

Manjaro is a user-friendly Linux distribution based on the independently developed Arch operating system. Available in both 32 and 64 bit versions, Manjaro is suitable for newcomers as well as experienced Linux users.

Post reply on HN