Live data from Hacker News

Arch Linux pulls the plug on 32-bit

pcworld.com

61–70 of 201 posts

Re: Arch Linux pulls the plug on 32-bit

#61

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.

Those scripts should probably be using something like the following, if they really are python2-only: #!/usr/bin/env python2

I get your frustration though, it's a change that breaks a whole lot of existing scripts.

Re: Arch Linux pulls the plug on 32-bit

#64

Earlier quoted context omitted.

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?

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.

I didn't flag you, I replied to you. That's my policy: If I disagree, I reply. I only flag trolls and spam, and I don't consider you either, just misinformed. Though, now you seem to be trying to pick a fight so I'm going to bow out. Cheers.

Re: Arch Linux pulls the plug on 32-bit

#65
post #5
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.

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

Does anyone use x32 ABI though? I once asked and only crickets answered. I'm experimenting with my own Linux distribution and was wondering if it is worth the time investment.

Re: Arch Linux pulls the plug on 32-bit

#66

Earlier quoted context omitted.

I run Arch on most everything -- up to now it's worked great on old hardware as long as I'm judicious about what I install. When they stop updating 32bit, I suppose I'll switch to Tiny Core. Or rather, well after they stop updating 32bit and Tiny Core catches up.

Debian will likely support 32 bit until the heat death of the universe, and Slackware probably will as well. There are also the BSDs; OpenBSD and NetBSD in particular will enjoy a long life on non-x64 hardware.

That's a good point about the BSDs. I've been meaning to try a BSD for a while -- it sounds like a good fit for my fleet of aging thinkpads.

Re: Arch Linux pulls the plug on 32-bit

#67

Earlier quoted context omitted.

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 you would assume it is that, for a long time on every Linux distribution, there was a single way to run python2, and it was called 'python'. I'm not sure what you are getting at, this was just the way it was. You couldn't run python 2 any other way in some linux distros. 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…

I get the point, python 2 scripts aren't fully compatible with python 3. I've written a little python and know that to be the case.

However, I can predict with near certaintly, if python 4 doesn't break python 3 scripts, people will complain if "python3" doesn't invoke python 4, because they've always used "python3" to run the new python and "python" to run python 2.

Re: Arch Linux pulls the plug on 32-bit

#68
post #27
post #4

Earlier quoted context omitted.

If people want 32 bit pointers on 64 bit hardware they should pick the x32 ABI instead

...which is not supported by Arch either.

Even though it is not supported officially, you can install the x32 libraries from AUR: https://aur.archlinux.org/packages/?K=libx32

Re: Arch Linux pulls the plug on 32-bit

#69

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…

>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. They have the latest packages, but on the system side changes take way too long.

Post reply on HN