Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Arch Linux pulls the plug on 32-bit

pcworld.com

Post reply on HN
Print view View original

171–180 of 201 posts

Re: Arch Linux pulls the plug on 32-bit

#171

Post by maxerickson »

groovy2shoes wrote: post #150
blipmusic wrote: post #138

Earlier quoted context omitted.

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

Windows doesn't support shebang lines, so the exact name/location of the interpreter doesn't matter as much as it does on 'nix.

Recent versions of python ship with a launcher shim for windows that does support the shebang line (to simplify using multiple interpreters):

https://www.python.org/dev/peps/pep-0397/

As you say though, it doesn't rely on the names of the exes.

Re: Arch Linux pulls the plug on 32-bit

#172

Post by greggyb »

michaelmrose wrote: post #155
simplyluke wrote: post #115

Earlier quoted context omitted.

So forever into the future $ python should run python2? That's not pragmatic at all.

Why not? Can you elaborate?

Pythons 4, 5, 6..., N will feasibly exist in the future. Why should Python 2 forever retain the executable name 'python'?

Re: Arch Linux pulls the plug on 32-bit

#173

Post by StreakyCobra »

srssays wrote: post #168
lelandbatey wrote: post #157

Earlier quoted context omitted.

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

I don't understand why people always want to tell other people how to behave. The change was decided by Arch developers and impacted only the Arch distribution. Arch developers and Arch users did their job by adapting the Arch packages to work with this. I don't see any problem. If users don't like this choice, they are free to use any other distribution. If software developer don't like this choice, they are also free to not support Arch. And even this is not a problem most of the time because Arch users are doing the effort of adapting and packaging applications themselves on AUR.

Re: Arch Linux pulls the plug on 32-bit

#174

Post by jlgaddis »

peatmoss wrote: post #43
jasonkostempski wrote: post #33

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.

OpenBSD and NetBSD both support i386 if you're looking for a BSD option.

Yeah, so does FreeBSD. OP is mistaken.

Re: Arch Linux pulls the plug on 32-bit

#176

Post by khedoros1 »

StreakyCobra wrote: post #173
srssays wrote: post #168

Earlier quoted context omitted.

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

I don't understand why people always want to tell other people how to behave. The change was decided by Arch developers and impacted only the Arch distribution. Arch developers and Arch users did their job by adapting the Arch packages to work with this. I don't see any problem. If users don't like this choice, they are free to use any other distribution. If software developer don't like this choice, they are also fr…

> The change was decided by Arch developers and impacted only the Arch distribution.

Well, until developers that do their work on other distributions start getting bug reports as a result of Arch's unexpected naming convention. Should someone outside of the distribution expect Arch to change so that their software works there? No. Should Arch expect outside developers to adapt their code to work on Arch? No. Honestly, I'd expect the kind of people that Arch attracts to be used to dealing with little snags in operation, and for them to just dive in and fix it on their own.

Re: Arch Linux pulls the plug on 32-bit

#177

Post by marvy »

simplyluke wrote: post #115
CJefferson wrote: post #79

Earlier quoted context omitted.

I have no problem with Arch having a "only install python3 by default" rule. They can even not distribute python2 for all I care. But, don't make /usr/bin/python run python3, that just confuses programs which have made the (reasonable based on past experience, and official python advice) assumption that it /usr/bin/python will run python2.

So forever into the future $ python should run python2? That's not pragmatic at all.

On Ubuntu, "sqlite" starts sqlite2.x; if you want sqlite3.x, you must type "sqlite3". The last version of sqlite2 came out in 2005. As far as I know, hardly anyone still uses sqlite2 for anything anymore. (I could be very wrong though.) Nevertheless, people must still type that extra character "3". The sky has not yet fallen :)

It seems to me that the same approach could work for Python.

Re: Arch Linux pulls the plug on 32-bit

#178

Post by marvy »

greggyb wrote: post #172
michaelmrose wrote: post #155

Earlier quoted context omitted.

Why not? Can you elaborate?

Pythons 4, 5, 6..., N will feasibly exist in the future. Why should Python 2 forever retain the executable name 'python'?

If Py4 is compatible with Py3, why bump the version number? If not, you better be careful which one you get!

Re: Arch Linux pulls the plug on 32-bit

#179

Post by i336_ »

gsnedders wrote: post #49
Koshkin wrote: post #21

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…

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

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

Re: Arch Linux pulls the plug on 32-bit

#180

Post by hobarrera »

CJefferson wrote: post #18
StreakyCobra wrote: post #12

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.

The thing is, python guidelines (PEPs) stated that shebangs should specify python2 or python3 explicitly during the transition period. Using "#!/usr/bin/env python" for a project that was python2-only was not following guidelines, so the breakage was really the dev's fault.

Also, the python2 symlink should have already been there. Bad packaging on some distros resulted in bad practices packaging by some devs. Don't blame that on Arch.

Post reply on HN