121–130 of 201 posts
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.
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.
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. So you made certain assumptions. Have you made your scripts use python2, which is safer anyway, everything would've been fine, don't blame Arch for your incorrect assumptions.
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.
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 resolve to move technology forward even in the face of a lot of pressure from outside groups.
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 and use the first one whose --version gives you '2.x' instead of relying on /usr/bin/python being python 2 when the latest version is 3 and Arch is known to ship latest software.
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…
[1] Installing a 32-bit package on Debian uninstalls all 64-bit packages????????????????? Why is this even allowed?
I love the rolling release aspect of arch but I'm looking for something more user friendly. Anybody know of a good linux distro that is user friendly and has rolling releases?
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.
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"?
Why not be explicit with 'python2' and be done with it?
Personally, I'd rather just use `/usr/bin/env python2` to invoke the appropriate interpreter (if you don't need to pass arguments to it), and if the symlink doesn't exist, the onus is on the user to create it. This is ESPECIALLY true for older distros.
Plus, for a sufficiently complicated application, why would someone want to pollute the global site-packages anyway? I'd rather manage most things inside a virtualenv or similar (pick your Python version), because I've seen far too many install_requires/requirements locking to a specific library version.
Earlier 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.
Why didn't python just opt to have the python 2 and 3 interpreter in the same binary? It could have detected if a file was python3 with a magic comment or something (overridable with a -2/-3 option), or otherwise assume python2. Or even simpler, have a wrapper script just called 'python' that checks if the file you are calling is python2 or 3 and calls the appropriate binary.
You don't need magical file-specific juju or a wrapper script on most systems these days to select the Python version. Just call python2 or python3 as appropriate; the symlinks usually exist depending on packager, distro, etc. The problem up-thread appears to be with calling the default `python` on $PATH. Sometimes it points to Python 2.x, sometimes it points to Python 3.x. Sometimes it might even change (Gentoo's eselect, IIRC). I don't see the problem being explicit with which version is needed in the script's hashbang. Python 3 isn't exactly new, and I remember when Gentoo and Arch both migrated to versioned symlinks. It wasn't that painful.
Earlier quoted context omitted.
Why not be explicit with 'python2' and be done with it?
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`…
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 could be sure that '/usr/bin/python' if present would be python2, and '/usr/bin/python3', if present, would be python3?
Now I agree that using virtualenv or similar is a good idea, but this actually caused the most problems for little 20 line python scripts, because often the users of those didn't even realise they were using python.
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…
All modern x86* CPUs are 64bit anyway and if this move means maintainers are freed up a bit, then I think it's worthwhile for the distro as a whole. Arch isn't really meant to be that one distro you can stick on a PC from the early nineties anyway. There are much more suitable distros for legacy hardware. And about the downsides of 64bit: I think the vastly improved address space offsets the improved memory use by or…
64-bit computers started gaining popularity in the consumer market only, what, 5 years ago?