Will be interesting if a part of the community "forks" arch like they did for 16bit back then. However lowarch is apparently also dead by now: http://www.lowarch.org/
I still have that installed on a i386 machine, but not booted since years.
> I still have that installed on a i386 machine, but not booted since years.
Did it even work usefully? While Linux itself retains backwards compatible drivers for a long time, X.org and others aren't quite as diligent.
E.g., five years ago I could not run any up to date distribution on Pentium 4 era notebooks with anything more than unaccelerated VESA framebuffers, because there were no compatible drivers for their integrated graphics card any more. (At the same time, we still had Pentium 4 servers in production use!)
Do they need to fork? The reason given is "decreasing popularity of i686 among the developers and the community". If enough developers were prepared to maintain a fork, why wouldn't they just do it as part of the Arch project? As far as I can tell, they're not being turned away; it's being dropped because there isn't anyone to turn away.
Multilib is different concept from x32 ABI. Typical usecase for multilib is running i386 binaries that use i386 ABI on amd64 system (or sun4m binaries on sun4u, mips32 on mips64...), x32 ABI is alternate ABI for amd64 that uses 32bit pointers, but all other amd64 ISA extensions.
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)
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.
x86 isn't just 32-bit. Linux distros have been reluctant to upgrade their notion of 32-bit x86 to require SSE2. This means that x86 isn't just 32-bit but involves weird 387 floating-point math when other mainstream architectures use IEEE floating-point math.
Interestingly however, Linux distros have been quick to adopt i686. I remember setting up a router on a small PC with a VIA processor several years ago. Inserted a Debian hard drive into that box — "cmov instruction not supported" instead of booting. The i586 version existed of course, but wasn't the default download IIRC.
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 avoids wasting a lot of stack, so may very well be faster overall just by nature of less cache utilization.
* No push and pop, reserves needed stack space (even for function calls) in prologue and accesses stack with mov and lea instead. The full mov/lea instructions with mod/rm+sib takes up far more bytes that simple push and pop, but apparently it's faster.
* 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.
* Multiple versions of code copying, scanning or comparing arrays for handling different alignments. This seems quite stupid as there isn't even any penalty for unaligned accesses on modern x86 cpus except in some very specific circumstances[0]
These are all microoptimizations for getting the absolutely maximal performance out of tiny programs containing only hot code. However
in reality programs rarely looks like that, and the increased code size and stack usage costs more than it gives. Profile guided optimizations
is probably the way to go here, but distributed binaries have rarely if ever been compiled with PGO. Also I have no idea if PGO actually
does drop these enlarging optimizations on non-hot codepaths on modern compilers.
> * 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.
So it kinda performs an optimization when disabling all optimizations that it doesn't do when optimizing for size. Or well, the default codegen is the optimized version. Interesting.
One thing that concerns me is packaging desktop virtual machine images for easy reproducibility.
We realized that some users do not (or cannot, due to security policies) turn on VT-x/AMD-V in their machines, and therefore Virtualbox and VMWare Player cannot run 64-bit guests.
So we had to make 32-bit virtual machine images for them. If popular distros stop supporting 32-bit, we will have a harder time packaging such images, since we'll have to use a different distro for them, with different package names, settings, etc.
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 libraries versions. This, plus the fact that Arch tries to stay as close as possible to vanilla upstream packages (i.e. less changes as possible), force them to be pragmatic about their choices. They prefer to embrace a change directly when it is happening, encouraging at the same time to contribute upstream for helping them make the transition, instead of trying to maintain a legacy compatibility that can only get worse with the time.
For me the picture is simple here: Arch is mostly used/oriented towards personal computers of power users, and most - if not all - of them are on 64 bit for years now. Instead of wasting efforts to maintain 32 bits compatibility, they prefer to drop it. Side effect will be that people will be encouraged to get a modern computer if not already.
> Side effect will be that people will be encouraged to get a modern computer if not already.
All those netbooks (atom processors; 1 GB or 2 GB ram; 32 GB hard drive) would be great with Linux (once the drivers get fixed) and really benefit from 32 bit because of the ram limitations.
For a "similar" approach, I would opt for a slackware or a gentoo.
I understand that some people would like to keep Arch 32 bit for their use cases. But as any open source project, the developer are mostly working on it on their spare time, you can not force them to work on anything. Having followed a little bit the discussion on the mailing list [1], I don't remember having seen a lot of objection among the developers. Also, they encourage the creation of a community around i686 [2]:
However, as there is still some interest in keeping i686 alive, we would like to encourage the community to make it happen with our guidance. The arch-ports mailing list and #archlinux-ports IRC channel on Freenode will be used for further coordination.
So if there are people willing to do the job, Arch will still be usable on 1686.
Debian testing is similar in "rollingness", Slackware and Alpine are similar in the sense of "no frills". OpenBSD is a good non-Linux choice to try out.
Absolutely! I have a perfectly good little netbook currently running lubuntu 32-bit. If other distros were to follow suit then they would quickly render my netbook useless.
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.
I've had excellent results running OpenBSD on old laptops. I have a Dell Latitude CPx (Pentium III) that is 100% supported and runs very fast (relatively speaking) under that OS. I ran it on a Latitude D400 and D620 as well until I gave those machines away (I'm a bit of a Dell collector if you can't tell), and it works fairly well on an Acer Aspire One netbook I keep for when we go camping and my wife wants to have a machine to write her book reviews.
With OpenBSD, my experience has been generally good. On some laptops it just works by default, on others you have to configure it a bit and it will work fine after that. Here's the relevant man page:
Good point about other distros catching up. Arch will be updating 32-bit until at least November and it could be another year or more until others like Tiny Core or Debian catch up to the package versions that Arch left off with. Will that now 8+ year old hardware still be worth using enough to switch distros when it is 10+ years old?
It looks like the community had the same thought. I follow the arch-ports mailing list and there is discussion right now about a community maintained 32-bit port. They've registered a github account (https://github.com/archlinux32) but there isn't any activity yet.
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.
"back then" the decision made even less sense, since a lot of efforts to make Python 3.x code backwards compatible did not happen yet. Like for instance the u'' literals introduced in 3.3.
It really wasn't that bad and the AUR + official channels had patched packages with the correct shebang line. The worst offender for a while was the node-waf builder, had to patch it manually to get any packages to build, otherwise you needed a command line arg every time. This was like 5 years ago tho... These days I have never hit an issue w/ a properly installed python package.
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.
Eventually logically python 2 will be little used enough to be dropped and there may not be a python4 any time in the foreseeable future so perhaps you are just borrowing trouble.
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.
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 of their language. They were going to support python 2 for a while, but the direction that the language was taking for the future was Python 3, so one day or another Python 3 would become the standard, so doing the switch was the good decision.
As said by @tbranyen the work of adapting shebangs have been done on the Arch side anyway, so I don't see a problem for people developing their projects in Python. Also Arch users are mostly power users (you need to understand quite a bit about linux to install it) so they are usually able to handle python 2 vs 3 errors quite well, especially as it is known than Arch use Python 3 by default.
I work on two programs which either not distributed by Arch, or our users choose to download directly (I don't know).
They both contained Python scripts, and I had to waste my time figuring out why they had broken when I had e-mails from Arch users complaining they didn't work -- and then keep replying to future Arch users with the fix.
I don't know how many hours and days of other developer's time was wasted by Arch with this change, but it certainly wasted a good day of my time over the last few years.
"...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 that python3 will be default eventually.
"...in preparation for an eventual change in the default version of Python, Python 2 only scripts should either be updated to be source compatible with Python 3 or else to use python2 in the shebang line."
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 distro not having a symlink for python2 is at this point nearly 5 years into being "old school").
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.
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.
> 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.
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.)
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 is no need for old bash3 scripts to know they are now running in bash4, unlike python3.
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.
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` symlink that does what you'd expect). So outside some LTS build, it seems surprising to me that it wouldn't exist in 2017 on a modern distro. I still can't shake the feeling that the thread started around a relatively insignificant complaint (dumping Arch because they use Python3 by default? Come on...).
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.
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 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.
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.
> 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).
> I assure you it wasn't that way when Arch originally did the python3 -> python rename.
I disagree. I don't believe it was as painful as some make it out to be. The official packages were updated within a relatively short period of time, and while the AUR packages took longer they're also not officially supported. There was also a news announcement [1]. Honestly, I think of a few other transitions over my years of using Arch as being far, far more painful. The Python2 -> Python3 defaults change isn't one of them.
Although I would agree that Gentoo's approach was somewhat better via eselect, which I believe predated Arch's migration.
> Why should users of older distros have to add a symlink
You're right. That should be the responsibility of the package maintainer. Conversely, why should I, as a developer, have to continue assuming `/usr/bin/python` points to any particular version of Python when most distributions have migrated away from this anachronism? sed does magic, and you really should be using the appropriate symlink for your desired version anyway. Python 3 isn't new. I have a hard time seeing this as problematic because 1) things change and 2) the solution is easy. I'd be happy to entertain a use case where this actually has presented material difficulties, however.
> 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.
Well, I do agree: It's a problem for the end user, but the solutions aren't difficult (if someone's using Linux, they probably know enough to fix it). So, either change the hashbang, add a symlink, and--failing that--complain to the package maintainer if it's been packaged up by the distro and the upstream software itself has changed (it should).
My recommendation for developers would be to use the appropriate /usr/bin/python* symlink. Nearly all distros have them in place now (including Ubuntu from a couple years ago). Perhaps assuming /usr/bin/python will always point to a fixed version is a matter of misplaced assumptions.
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.
You really shouldn't install global packages circumventing the package manager (this applies to python and everything else really). You're just asking for eventual breakage, or leaking obsolete files.
Exactly. In retrospect, I'm actually not sure I've done something quite so stupid in a long time. However, I'm sure I did it ~10 years ago on Gentoo and/or FreeBSD when I was much stupider about dependencies. Either way, what I should've said is outlined below in my last paragraph, and mostly what I mean by polluting global site-packages (with PKGBUILDs!)--and trying not to clobber things.
As an aside first: I sometimes make a PKGBUILD for most things just on the merit that it's better for pacman to manage site-packages on its own--or anything, really. It's a terrible idea to stuff things into global library directories that aren't managed in general (although incautious use of things like npm or pip can certainly do that for you--still an awful idea).
However, I do recommend installing packages into a virtualenv for anything with modest complexity, because some applications have requirements/install_requires that lock specific versions which may not be mutually compatible with others, and there's also the circumstance where official packages aren't new enough but you still want the package manager to maintain the dependent package. I guess you could go with versioned packages in this case, but since the official ones will inevitably find themselves updated at some point, I see it as easier to circumvent the issue in the first place via a virtualenv.
Anyway, I did the above polluting nonsense once when building a package with quite a few dependencies: Trying to maintain a half dozen individual PKGBUILDs just for dependencies and pestering easily a half dozen other maintainers to update their respective PKGBUILDs versus modifying the application's setup.py (either with patch or sed) to match older versions were both terrible ideas and scaled poorly. It's far easier to simply build what's needed in a virtualenv and avoid polluting the global site-packages even with the package manager handling them on its own. This is especially true for complex applications with many dependencies that may already be installed (but with conflicting versions).
Sorry for the rant, you just reminded me and tickled all the right spots! :)
That doesn't address the part where python2 didn't exist in a lot of places at the time, so scripts using python2 to work on Arch would have to be adjusted to work elsewhere. There was no universal solution.
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 maverick decision. It was just moving forward.
Not everyone wants to be tied to ancient stuff for backwards compatibility - if you do, it's your job to deal with that.
I thought the official advice was that 'python' should remain 'python2'?
from https://www.python.org/dev/peps/pep-0394/ (not yet replaced/update) "for the time being, all distributions should ensure that python refers to the same target as python2 ."
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 rest of the world, including all of the scripts that people run but distros don't necessarily ship.
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.
> There was official guidance from Python on the switchover, this wasn't some maverick decision.
No, there wasn't, and yes, it was some maverick decision. It was done without consultation with upstream.
> 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.
> 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 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.
> 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<glob>' 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.
The rest of the world explicitly doesn't ship the latest software, check the kernel version in the latest version of ubuntu vs arch, same for GNOME etc. Ubuntu did not even had python3 installed for a long time by default, you had to apt-get it
The ABI was never documented and at best a convention-enforced one.
> Ubuntu did not even had python3 installed for a long time by default, you had to apt-get it
I call your straw man. As I've already repeatedly said, the issue is about breaking ABI, not about what software distributions shipped, nor what they had installed by default. Making /usr/bin/python point to Python 3 has nothing to do with what distributions shipped, nor what they had installed by default. The issues are completely orthogonal. Stop trying to pretend otherwise.
> The ABI was never documented and at best a convention-enforced one.
Upstream shipped build systems that put Python 2 in /usr/bin/python, and Python 3 in /usr/bin/python3. That's about as good a definition of ABI as one gets in the free software world. Arch deliberately patched the ABI. You can try to argue that their decision to do so was correct, even though I disagree. You cannot argue that they didn't know they were changing an ABI when they patched the ABI.
> call your straw man. As I've already repeatedly said, the issue is about breaking ABI, not about what software distributions shipped,
But it is very much about that. Arch ships latest software, Python 3 is the latest python, python 2 is not. Ubuntu, Debian etc. ship old, outdated software regularly, Arch doesn't.
Because the latest python was python 3, /usr/bin/python pointed there. The other distributions explicitly decided not to ship the latest python.
Prior to Arch making the switch, the 'ABI' was not /usr/bin/python points to python 2, it simply pointed to the latest python release, which on most systems happened to be python 2, because they did not even ship python 3 at all at the time.
You may not agree with the decision, but to pretend like it was "out of nowhere" is unhelpful.
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.
> 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.
Which part of "I want it now, not in the future" do you not understand?
> 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.
I want to speed up the migration for everything - that's why I run Arch. That 'override' is a manual step I don't want to have to do.
The decision is pretty simple: if a user doesn't like the way Arch does things, they're free to use any of a hundred other distros. I'm with you, I think this is fine.
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.
"Explicit is better than implicit." is the Python mantra. Although it's not often taken as literally as some would like, I think it's appropriate in this case. After all, magic detection sounds good on the surface, but it's liable to be problematic and bug ridden.
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.
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.
You're getting the ordering of events wrong. Arch's actions weren't in response to the PEP. The PEP was written in response to Arch's actions.
> Also, the python2 symlink should have already been there.
Nope. There was no such convention or specification at the time. There was, however, convention and specification (in the form of "what Python upstream build systems do") on what /usr/bin/python means, which is "Python 2".
>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.
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.
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 in-memory objects being now bigger in size)?
> 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-64 without the pointer bloat).
But wait. This could actually work out really well for Chrome, since it's multiprocess, and each process will likely consume <4GB.
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...
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 orders of magnitues. My Desktop has 8 times as much useable RAM as it could have with 32bit - but 32bit datatypes are only double in size.
Athlon 64 came out in 2003, Pentium 4F in 2005. I'll concede that 32-bit Atoms were reasonably popular in certain market segments, but hasn't generally every consumer computer been 64-bit for over 10 years?
Sure, but the point has nothing todo with the availabilty or popularity of 64-bit CPUs. Rather, it has to do with the amount of memory deemed necessary in a computer. As far as I remember, Windows Vista, which was released into the wild just about 10 years ago, was predominantly 32-bit, 64-bit intalls, just like with XP, being more of a curiosity. Few consumer devices had more than 2GB of RAM back then.
The Athlon 64 was released in September 2003, the Prescott Pentium 4 in February 2004, and the iMac G5 in August 2004.
Desktop CPUs have been basically guaranteed to be 64 bit since 2005.
The Pentium 3 derived Pentium M and Core Solo/Duo delayed wide mobile adoption of 64 bit until Core 2 came around in July 2006. I'd guess by 2007 you could probably safely assume 64 bit across all but the cheapest laptops as well.
tl;dr: Aside from a few Atom-powered netbooks 64 bit has been standard in anything resembling a normal computer for around a decade.
It is a shame that many major Linux distributions are dropping 32-bit x86 support. I used to be able to say with confidence that the old laptop or PC in your garage can run any major Linux distribution, breathing new life into aging hardware. For example, I have an old ThinkPad T42, which I use to test out new Linux distros, which incidentally, is currently running Arch. Using older hardware increases the chances that stable drivers will be available. I put in the CD (or flash drive), boot up, and everything seems to just work(tm). Its no speed demon, but its usable. But now with Arch dropping support for a significant amount of commonly available and being a major, top-level distribution, I feel I now must make specific recommendations for Linux newcomers to try rather then have them waste time downloading a large ISO, transferring it to a flash drive or disc, to find they are unable to boot up with it. This may cause users to give up before even giving Linux or open source software an honest try.
Also, I wonder what this means for the Intel Quark SoC (found in Intel Edison and Intel Galileo boards). Does this mean Arch Linux wont be an option for these devices?
Despite RHEL 7/CentOS 7 not supporting 32-bit x86, there is now a community-led effort to port it to 32-bit x86. I wonder if Arch would consider doing the same (supporting 32-bit x86 as an alternative architecture).
I have a T40p running Arch which I still occasionally use, even for development, because it's just such a pleasing machine ergonomically. So I'm a bit concerned about this as well -- but then, I've been happily using Arch for years and it's not like I've ever contributed anything to the effort of maintaining it.
I completely agree with you on the pleasure of using such a well-crafted machine. From the keyboard, to the connectivity, to the overall build-quality and the way in which the designers thought out so many things so well, it makes me sad that that I cannot just swap out its socketed (yes socketed!) single-core processor for something more modern.
You make a good point- I too have been an open-source consumer. Yea I have filed a few bug reports, helped some people experience Linux or switch from IE6 to Firefox, but have not contributed much to these projects time- or money-wise. With things like the Linux kernel, that are suported by the likes of Red Hat and SUSE (which are in turn supported by big businesses), I am not too concerned about their survival. But after reading about the GPG maintainer and now the GNU Octave maintainer being forced to stop their their generous contributions, I realize perhaps I need to be doing more as a user for open-source things I care about being around in the future.
It's increadibly easy (although the computer will spend hours crunching) to make a boot disk for pretty much anything using buildroot. That honestly sounds like a better plan for underpowered hardware than expecting a major distro to support it.
This is definately something I need to look into. Not only would I be able to produce install images but also would have the chance to learn more about what goes into making that ISO file I take for granted. Thanks for posting!
tl;dr - due to a CPU bug, you can't run normal i686 distributions on the Quark anyway, and support in mainline Linux is still shit 3 years after release.
> Also, I wonder what this means for the Intel Quark SoC (found in Intel Edison and Intel Galileo boards). Does this mean Arch Linux wont be an option for these devices?
I have a device based on the Quark SoC. Support is abysmal for this SoC, especially considering it's been on the market for 3 years (2014). Intel has clearly abandoned this market segment since their repeated headlines of new Quark SoCs has totalled exactly 0 new product launches since 2014.
In mainline Linux I can't use the onboard Ethernet because of some modifications Intel made to the stmmaceth module that weren't pushed upstream. The internet is full of people trying to run newer versions of Linux on their Quark hardware and Intel telling them to use old Yocto Linux BSPs [0] because they can't be bothered to clean up and push their code upstream (or upstream refused to merge it, I don't know and haven't checked).
Also the Quark is affected by the F0 0F bug, so you can't run normal distributions on it because processes will segfault. [1]
> It might solve this issue for Intel Quark, but it would break for any multicore processors. This is not something acceptable.
Honestly I'm not sure why anyone would want to buy a Quark based system. Support is bad, performance is terribad, and power consumption is also terrible (my Quark system idles at 7W, and consumes 2W when in S5 "off" state). You would be very wise to look for an ARM instead of choosing this dumpster fire of a CPU.
Thanks for your post (and tl;dr comment too - I need to work on being more concise :-). I own no Quark powered boards but have some friends who do. It's a shame that they fall into the category of boards with poor software support (and even more of a shame since they are based off the Intel architecture). I own a few raspberry pi's and have been extremely pleased that even my rPi model B+ from 2012 still gets support and updates (and hopefully will for a while longer now that the rPi zero exists with similar hardware). Friends would brag about the faster or cheaper O-droid, Pine-64 or Banana-pi, but with dismal software support, I couldn't justify even a descent performance boost. This reminds me of the little I know of the Android ecosystem, where a tablet I bought in 2013 is still stuck on Jelly Bean, while my 2012 iPhone 5 still gets updates. I wish there was some sort of regulatory label put on these devices (or boards) that would clearly state how many years of support they would commit to.
> I wish there was some sort of regulatory label put on these devices (or boards) that would clearly state how many years of support they would commit to.
As someone who owns a Raspberry Pi, PandaBoard, BananaPi, Orange Pi, and Intel DK200 I've learned this important life lesson:
Always assume that the most support you'll ever receive for the board is on the day you buy it.
Apart from the Raspberry Pi, no one else gives half a shit to fix bugs or even provide distro updates for their hardware.
Cheap Chinese boards are even worse for this. They'll typically take the SoC kernel (an ancient version several years out of date with the worst patches you've ever seen) and roll some shitty old distro around it (e.g. Ubuntu 14.04, Android 4.4).
A good recommendation for people looking to buy a board is to look at the Armbian [0] or Arch Linux ARM [1] supported hardware (read the notices!!!) and buy that.
Supporting this view. Got given a Quark SoC based box by someone at Intel. Tried to get something going with it, only to realise I had to use WindRiver Linux. Tried to obtain toolchain for building even simple software for it online, couldn't find it. Asked contacts at Intel: radio silence.
Smart choice. Bypassing signature verification in grub was an interesting challenge, but I'll be binning mine soon. Can't be bothered to keep something without mainline support and crap performance.
> It is a shame that many major Linux distributions are dropping 32-bit x86 support.
Really it's that nobody who is interested in 32-bit x86 support is prepared to maintain it. In Free Software land, that's almost always the reason that stuff gets dropped. If it's enough of a shame, those interested would step up and make it happen. They haven't.
> stuck to SysVinit and told users "you want Systemd, make a package" until long after the big distros had made the switch
Bullshit, Arch was one of the first to switch to systemd as the default way back in 2012. The only "big distros" that switched before Arch were Fedora (obviously since that's where it came from), Mageia which is based on Fedora, and OpenSUSE (but not SLES). The next distro to switch was CoreOS a full year later, and Debian didn't switch until 2015.
I'm not a fan of Arch anymore either, but if you're going to disparage any distro, at least get your facts straight.
Edit: Getting my own facts straight: Mageia was based on Mandriva, not Fedora.
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.
...and now you are trolling. You edited out your original post, calling the people replying to you "Arch fanboys" (even though I stated my own disdain for Arch), reposted it with an addendum to make it appear you were talking about Upstart all along when you were initially only talking about systemd, and now you're paraphrasing me in a way that makes it look like I agree with you. Consequently, I have now flagged all of the above mentioned posts by you (the edited original, the "new" post, and this one I'm replying to) since it's obvious what you are doing. I still choose not to flag the one post you accused me of flagging, as others have already taken care of that.
Please consider how your actions in this thread make you appear, and have a good day.
Systemd and Upstart are both advanced init systems and serve a very similar purpose. Complaining that one wasn't initially mentioned is just a way to prevent admitting that you're wrong. Arch took a very long time to make the step. That's a fact.
Flagging posts that are correct and provide sources should rather make you consider your own actions, but Arch users are often notoriously bad at facing reality.
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.
> The Pentium D brand refers to two series of desktop dual-core 64-bit x86-64 microprocessors with the NetBurst microarchitecture, which is the dual-core variant of Pentium 4 "Prescott" manufactured by Intel.
Blerg, sorry, I have no clue where I got mixed up on this. I think I got confused with Drangonfly because I was going to try that at shortly after I got FreeBSD set up just to compare. FreeBSD seems to be going strong with i386.
Damn, am I the only one who doesn't feel long ago when we were looking for 64bit distributions to test owr brand new opterons? Arch did not exist at the time(if I remember well).
32-bit is sometimes used on new hardware to save memory. For example, my Windows 10 tablet has only 1GiB of RAM, and I assume that's why it was pre-loaded with the 32-bit version.
I doubt Linux distros are generally targeting these devices, though.
If you're interested, Parabola (an Arch derivative) is continuing i686 support pretty much solely because so many of the Parabola developers love their X60's (which is largely due to Libreboot support).
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 who has never installed a Linux distro.
Can anyone comment about their experiences with moving to Arch and the learning curve?
To be honest Arch as a distro is more for advanced users -- if you're trying to dip your toes into linux the quintessential starting point is probably Ubuntu or ElementaryOS (linux mint is also pretty good). Arch's philosophy is very much to give you the bare minimum and then you can get what you need to stack on top of it, which often involves a bit of config tweaking. This might get frustrating if you aren't fairly intimate with working with a linux command line environment.
Personally I started out with Arch on an old 64bit Atom netbook. I got a nice hobby out of it, and liked it so much I put it on all my computers. If you have a knack for googling and enjoy reading high quality wiki pages that document far beyond the scope of the operating system, you'll probably enjoy it. It requires patience and some time investment, but it's no rocket science.
"Can anyone comment about their experiences with moving to Arch and the learning curve?"
To me arch is designed to force you to learn the guts of your system, so it has a relatively high learning curve but it is one that pays dividends in the form of understanding what your system is doing and how it is setup. (this aside from the side-effect of keeping it debloated and therefor fast)
Honestly, what I would suggest is this:
Step 1:(if you have the time) go through a full arch install. Now format and do it again without following the guide. Now maybe do it one more time.
Step 2: (if pressed for time and/or lazy) Install Manjaro. I distro-hop frequently, and while I generally try to use debian on servers, for desktop/laptop use I have gone from Arch to Suse to Fedora, but I recently gave Majaro a shot, and I can honestly say next to Suse it has the easiest and most graceful linux installer I have ever seen (beating even Ubuntu). I generally don't like using Mint-like everything in a box distros, but the slimness of Arch along with the Just works of Ubuntu/Fedora/Suse I am finding it highly likely Manjaro is going to be my distro of choice for a long time to come. If in doubt, you can always just fire up different installs in a virtualbox first.
Arch was my first distro, ten years ago, and I'm still using it. There's a learning curve, but the documentation is second to none and at the end you'll have a system that you actually understand and can maintain and troubleshoot. When I try other distros, I find they always fall over in some baffling way[1] and I pine for the dead-simple package management of Arch.
[1] Installing a 32-bit package on Debian uninstalls all 64-bit packages????????????????? Why is this even allowed?
The installation is the most challenging part but it really just boils down to "Can you follow directions?"
Best simple/minimal install: use XFCE without a login manager. This gives you a very nice "default" environment without having to spend any time configuring.
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.
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?
Debian testing might work. I don't know if it is technically a rolling release distro but it stays up to date. Also OpenSuse tumbleweed. And there's a similar Fedora distro: rawhide, maybe?
I don't really know, I haven't seriously used unstable. That being said, I like testing because the packages are generally new enough for my purposes but they've also had more vetting, so I don't have to worry about a broken system as much.
I'm curious why you think Arch is not user friendly? It's not the rolling release since you're asking for other distributions that use that model. I've used my fair share and from what I've seen Arch is by far the most user friendly.
The maintainers are dropping a hard requirement for 32 bit and asking the community to step up if they want to. 32 bit packages can and will continue to be still packaged under archlinux perhaps from [community] instead of [core]
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.
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.
200 comments
[ 2.9 ms ] story [ 314 ms ] threadI still have that installed on a i386 machine, but not booted since years.
Did it even work usefully? While Linux itself retains backwards compatible drivers for a long time, X.org and others aren't quite as diligent.
E.g., five years ago I could not run any up to date distribution on Pentium 4 era notebooks with anything more than unaccelerated VESA framebuffers, because there were no compatible drivers for their integrated graphics card any more. (At the same time, we still had Pentium 4 servers in production use!)
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.
https://en.wikipedia.org/wiki/X32_ABI
4GB max address space per process. It should support much more memory through PAE [1], which makes things more reasonable.
[1]: https://en.wikipedia.org/wiki/Physical_Address_Extension
* 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 avoids wasting a lot of stack, so may very well be faster overall just by nature of less cache utilization.
* No push and pop, reserves needed stack space (even for function calls) in prologue and accesses stack with mov and lea instead. The full mov/lea instructions with mod/rm+sib takes up far more bytes that simple push and pop, but apparently it's faster.
* 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.
* Multiple versions of code copying, scanning or comparing arrays for handling different alignments. This seems quite stupid as there isn't even any penalty for unaligned accesses on modern x86 cpus except in some very specific circumstances[0]
These are all microoptimizations for getting the absolutely maximal performance out of tiny programs containing only hot code. However in reality programs rarely looks like that, and the increased code size and stack usage costs more than it gives. Profile guided optimizations is probably the way to go here, but distributed binaries have rarely if ever been compiled with PGO. Also I have no idea if PGO actually does drop these enlarging optimizations on non-hot codepaths on modern compilers.
[0]: http://lemire.me/blog/2012/05/31/data-alignment-for-speed-my...
Does it emit it at -Os ?
-O0:
-Os: So it kinda performs an optimization when disabling all optimizations that it doesn't do when optimizing for size. Or well, the default codegen is the optimized version. Interesting.We realized that some users do not (or cannot, due to security policies) turn on VT-x/AMD-V in their machines, and therefore Virtualbox and VMWare Player cannot run 64-bit guests.
So we had to make 32-bit virtual machine images for them. If popular distros stop supporting 32-bit, we will have a harder time packaging such images, since we'll have to use a different distro for them, with different package names, settings, etc.
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 libraries versions. This, plus the fact that Arch tries to stay as close as possible to vanilla upstream packages (i.e. less changes as possible), force them to be pragmatic about their choices. They prefer to embrace a change directly when it is happening, encouraging at the same time to contribute upstream for helping them make the transition, instead of trying to maintain a legacy compatibility that can only get worse with the time.
For me the picture is simple here: Arch is mostly used/oriented towards personal computers of power users, and most - if not all - of them are on 64 bit for years now. Instead of wasting efforts to maintain 32 bits compatibility, they prefer to drop it. Side effect will be that people will be encouraged to get a modern computer if not already.
All those netbooks (atom processors; 1 GB or 2 GB ram; 32 GB hard drive) would be great with Linux (once the drivers get fixed) and really benefit from 32 bit because of the ram limitations.
Now? They'll end up in landfill.
Of course, there's the Arch Linux Archive, which lets you sync packages as they were on a particular date.
A six-year-old 32-bit processor (e.g. an Atom in an EeePC 901 or HP Mini 311c) is more than capable of running a modern desktop system.
Also, for some of these machines they use a 32 bit UEFI, so even if you want to use a 64 bit OS you'll need some weird tinkering to get it installed.
I've successfully run Arch on a set of 10 EeePC 901s for a club. Linux plus Arduino programming = awesome kids.
I understand that some people would like to keep Arch 32 bit for their use cases. But as any open source project, the developer are mostly working on it on their spare time, you can not force them to work on anything. Having followed a little bit the discussion on the mailing list [1], I don't remember having seen a lot of objection among the developers. Also, they encourage the creation of a community around i686 [2]:
So if there are people willing to do the job, Arch will still be usable on 1686.[1] https://lists.archlinux.org/pipermail/arch-dev-public/2016-D... [2] https://www.archlinux.org/news/phasing-out-i686-support/
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).
[1]: https://en.wikipedia.org/wiki/X32_ABI
I suspect this means they'll end up in the landfill regardless.
http://man.openbsd.org/apmd
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.
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.
It seems to me that the same approach could work for Python.
From the Arch developers point of view, the Python developers decided to release a new version of their language. They were going to support python 2 for a while, but the direction that the language was taking for the future was Python 3, so one day or another Python 3 would become the standard, so doing the switch was the good decision.
As said by @tbranyen the work of adapting shebangs have been done on the Arch side anyway, so I don't see a problem for people developing their projects in Python. Also Arch users are mostly power users (you need to understand quite a bit about linux to install it) so they are usually able to handle python 2 vs 3 errors quite well, especially as it is known than Arch use Python 3 by default.
They both contained Python scripts, and I had to waste my time figuring out why they had broken when I had e-mails from Arch users complaining they didn't work -- and then keep replying to future Arch users with the fix.
I don't know how many hours and days of other developer's time was wasted by Arch with this change, but it certainly wasted a good day of my time over the last few years.
0: https://www.python.org/dev/peps/pep-0394/
[1] https://www.archlinux.org/news/python-is-now-python-3/
"...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 that python3 will be default eventually.
"...in preparation for an eventual change in the default version of Python, Python 2 only scripts should either be updated to be source compatible with Python 3 or else to use python2 in the shebang line."
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 distro not having a symlink for python2 is at this point nearly 5 years into being "old school").
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.
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.
(Normally not a Windows user so I have no idea why this is the case or if by design.)
https://www.python.org/dev/peps/pep-0397/
As you say though, it doesn't rely on the names of the exes.
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 is no need for old bash3 scripts to know they are now running in bash4, unlike python3.
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.
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.
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.
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.
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).
I disagree. I don't believe it was as painful as some make it out to be. The official packages were updated within a relatively short period of time, and while the AUR packages took longer they're also not officially supported. There was also a news announcement [1]. Honestly, I think of a few other transitions over my years of using Arch as being far, far more painful. The Python2 -> Python3 defaults change isn't one of them.
Although I would agree that Gentoo's approach was somewhat better via eselect, which I believe predated Arch's migration.
> Why should users of older distros have to add a symlink
You're right. That should be the responsibility of the package maintainer. Conversely, why should I, as a developer, have to continue assuming `/usr/bin/python` points to any particular version of Python when most distributions have migrated away from this anachronism? sed does magic, and you really should be using the appropriate symlink for your desired version anyway. Python 3 isn't new. I have a hard time seeing this as problematic because 1) things change and 2) the solution is easy. I'd be happy to entertain a use case where this actually has presented material difficulties, however.
> 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.
Well, I do agree: It's a problem for the end user, but the solutions aren't difficult (if someone's using Linux, they probably know enough to fix it). So, either change the hashbang, add a symlink, and--failing that--complain to the package maintainer if it's been packaged up by the distro and the upstream software itself has changed (it should).
My recommendation for developers would be to use the appropriate /usr/bin/python* symlink. Nearly all distros have them in place now (including Ubuntu from a couple years ago). Perhaps assuming /usr/bin/python will always point to a fixed version is a matter of misplaced assumptions.
[1] https://www.archlinux.org/news/python-is-now-python-3/
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.
As an aside first: I sometimes make a PKGBUILD for most things just on the merit that it's better for pacman to manage site-packages on its own--or anything, really. It's a terrible idea to stuff things into global library directories that aren't managed in general (although incautious use of things like npm or pip can certainly do that for you--still an awful idea).
However, I do recommend installing packages into a virtualenv for anything with modest complexity, because some applications have requirements/install_requires that lock specific versions which may not be mutually compatible with others, and there's also the circumstance where official packages aren't new enough but you still want the package manager to maintain the dependent package. I guess you could go with versioned packages in this case, but since the official ones will inevitably find themselves updated at some point, I see it as easier to circumvent the issue in the first place via a virtualenv.
Anyway, I did the above polluting nonsense once when building a package with quite a few dependencies: Trying to maintain a half dozen individual PKGBUILDs just for dependencies and pestering easily a half dozen other maintainers to update their respective PKGBUILDs versus modifying the application's setup.py (either with patch or sed) to match older versions were both terrible ideas and scaled poorly. It's far easier to simply build what's needed in a virtualenv and avoid polluting the global site-packages even with the package manager handling them on its own. This is especially true for complex applications with many dependencies that may already be installed (but with conflicting versions).
Sorry for the rant, you just reminded me and tickled all the right spots! :)
Because Bash was made by, and is maintained by, people who understand how backwards compatability in their program is important.
I get your frustration though, it's a change that breaks a whole lot of existing scripts.
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 maverick decision. It was just moving forward.
Not everyone wants to be tied to ancient stuff for backwards compatibility - if you do, it's your job to deal with that.
from https://www.python.org/dev/peps/pep-0394/ (not yet replaced/update) "for the time being, all distributions should ensure that python refers to the same target as python2 ."
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 rest of the world, including all of the scripts that people run but distros don't necessarily ship.
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.
> There was official guidance from Python on the switchover, this wasn't some maverick decision.
No, there wasn't, and yes, it was some maverick decision. It was done without consultation with upstream.
(I am a non-Arch distribution developer)
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.
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.
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<glob>' 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.
The ABI was never documented and at best a convention-enforced one.
I call your straw man. As I've already repeatedly said, the issue is about breaking ABI, not about what software distributions shipped, nor what they had installed by default. Making /usr/bin/python point to Python 3 has nothing to do with what distributions shipped, nor what they had installed by default. The issues are completely orthogonal. Stop trying to pretend otherwise.
> The ABI was never documented and at best a convention-enforced one.
Upstream shipped build systems that put Python 2 in /usr/bin/python, and Python 3 in /usr/bin/python3. That's about as good a definition of ABI as one gets in the free software world. Arch deliberately patched the ABI. You can try to argue that their decision to do so was correct, even though I disagree. You cannot argue that they didn't know they were changing an ABI when they patched the ABI.
But it is very much about that. Arch ships latest software, Python 3 is the latest python, python 2 is not. Ubuntu, Debian etc. ship old, outdated software regularly, Arch doesn't.
Because the latest python was python 3, /usr/bin/python pointed there. The other distributions explicitly decided not to ship the latest python.
Prior to Arch making the switch, the 'ABI' was not /usr/bin/python points to python 2, it simply pointed to the latest python release, which on most systems happened to be python 2, because they did not even ship python 3 at all at the time.
You may not agree with the decision, but to pretend like it was "out of nowhere" is unhelpful.
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.
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.
Expecting that is as weird as expecting super stable LTS releases to run the latest-and-greatest of everything.
Which part of "You wouldn't have to do it manually" do you not understand?
> 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.
I want to speed up the migration for everything - that's why I run Arch. That 'override' is a manual step I don't want to have to do.
Well, the fact that over a decade after the release of python 3 we're _still_ arguing about it shows that lot of people think we should.
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.
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.
> Also, the python2 symlink should have already been there.
Nope. There was no such convention or specification at the time. There was, however, convention and specification (in the form of "what Python upstream build systems do") on what /usr/bin/python means, which is "Python 2".
There was no formal specification, but there was a convention that many distributions were already following (and quite a few others were not).
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.
Suse was October 2014. Debian and Ubuntu were April 2015. RHEL was June 2014.
https://en.opensuse.org/Archive:Portal:12.1
RHEL7 already dropped support for 32-bit hardware (although it still maintains the compat toolchain+libs for 32-bit binaries on 64-bit O/S).
I believe Windows Server 2012 similarly only runs on 64-bit hardware.
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-64 without the pointer bloat).
But wait. This could actually work out really well for Chrome, since it's multiprocess, and each process will likely consume <4GB.
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...
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 orders of magnitues. My Desktop has 8 times as much useable RAM as it could have with 32bit - but 32bit datatypes are only double in size.
64-bit computers started gaining popularity in the consumer market only, what, 5 years ago?
Athlon 64 came out in 2003, Pentium 4F in 2005. I'll concede that 32-bit Atoms were reasonably popular in certain market segments, but hasn't generally every consumer computer been 64-bit for over 10 years?
Desktop CPUs have been basically guaranteed to be 64 bit since 2005.
The Pentium 3 derived Pentium M and Core Solo/Duo delayed wide mobile adoption of 64 bit until Core 2 came around in July 2006. I'd guess by 2007 you could probably safely assume 64 bit across all but the cheapest laptops as well.
tl;dr: Aside from a few Atom-powered netbooks 64 bit has been standard in anything resembling a normal computer for around a decade.
Also, I wonder what this means for the Intel Quark SoC (found in Intel Edison and Intel Galileo boards). Does this mean Arch Linux wont be an option for these devices?
Despite RHEL 7/CentOS 7 not supporting 32-bit x86, there is now a community-led effort to port it to 32-bit x86. I wonder if Arch would consider doing the same (supporting 32-bit x86 as an alternative architecture).
Yes: https://lists.archlinux.org/pipermail/arch-ports/2017-Januar...
(Also https://lists.archlinux.org/pipermail/arch-ports/2017-Januar...)
I have a T40p running Arch which I still occasionally use, even for development, because it's just such a pleasing machine ergonomically. So I'm a bit concerned about this as well -- but then, I've been happily using Arch for years and it's not like I've ever contributed anything to the effort of maintaining it.
You make a good point- I too have been an open-source consumer. Yea I have filed a few bug reports, helped some people experience Linux or switch from IE6 to Firefox, but have not contributed much to these projects time- or money-wise. With things like the Linux kernel, that are suported by the likes of Red Hat and SUSE (which are in turn supported by big businesses), I am not too concerned about their survival. But after reading about the GPG maintainer and now the GNU Octave maintainer being forced to stop their their generous contributions, I realize perhaps I need to be doing more as a user for open-source things I care about being around in the future.
> Also, I wonder what this means for the Intel Quark SoC (found in Intel Edison and Intel Galileo boards). Does this mean Arch Linux wont be an option for these devices?
I have a device based on the Quark SoC. Support is abysmal for this SoC, especially considering it's been on the market for 3 years (2014). Intel has clearly abandoned this market segment since their repeated headlines of new Quark SoCs has totalled exactly 0 new product launches since 2014.
In mainline Linux I can't use the onboard Ethernet because of some modifications Intel made to the stmmaceth module that weren't pushed upstream. The internet is full of people trying to run newer versions of Linux on their Quark hardware and Intel telling them to use old Yocto Linux BSPs [0] because they can't be bothered to clean up and push their code upstream (or upstream refused to merge it, I don't know and haven't checked).
Also the Quark is affected by the F0 0F bug, so you can't run normal distributions on it because processes will segfault. [1]
> It might solve this issue for Intel Quark, but it would break for any multicore processors. This is not something acceptable.
Honestly I'm not sure why anyone would want to buy a Quark based system. Support is bad, performance is terribad, and power consumption is also terrible (my Quark system idles at 7W, and consumes 2W when in S5 "off" state). You would be very wise to look for an ARM instead of choosing this dumpster fire of a CPU.
[0] https://communities.intel.com/thread/105047
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738575
As someone who owns a Raspberry Pi, PandaBoard, BananaPi, Orange Pi, and Intel DK200 I've learned this important life lesson:
Always assume that the most support you'll ever receive for the board is on the day you buy it.
Apart from the Raspberry Pi, no one else gives half a shit to fix bugs or even provide distro updates for their hardware.
Cheap Chinese boards are even worse for this. They'll typically take the SoC kernel (an ancient version several years out of date with the worst patches you've ever seen) and roll some shitty old distro around it (e.g. Ubuntu 14.04, Android 4.4).
A good recommendation for people looking to buy a board is to look at the Armbian [0] or Arch Linux ARM [1] supported hardware (read the notices!!!) and buy that.
[0] http://armbian.com
[1] https://archlinuxarm.org/
You can boot other Linuxes on it (e.g. Yocto) but as per my parent comment, not much will work.
I have an SPI image and instructions to flash if you're interested. You'll need an SPI programmer like the ch341a.
I think Intel is violating the GPL by not providing sources, since they include a written offer and GPL requires source availability for 3 years.
I tried to download the WindRiver SDK using the code in the box, and Intel told me the product was no longer receiving support...
Really it's that nobody who is interested in 32-bit x86 support is prepared to maintain it. In Free Software land, that's almost always the reason that stuff gets dropped. If it's enough of a shame, those interested would step up and make it happen. They haven't.
Bullshit, Arch was one of the first to switch to systemd as the default way back in 2012. The only "big distros" that switched before Arch were Fedora (obviously since that's where it came from), Mageia which is based on Fedora, and OpenSUSE (but not SLES). The next distro to switch was CoreOS a full year later, and Debian didn't switch until 2015.
I'm not a fan of Arch anymore either, but if you're going to disparage any distro, at least get your facts straight.
Edit: Getting my own facts straight: Mageia was based on Mandriva, not Fedora.
https://en.wikipedia.org/wiki/Upstart
New init systems were widely used long before Arch officially implemented them. Talking about facts, yours seem to be "alternate facts".
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'm going to bow out. Cheers.
Thanks for acknowledging it, then.
Please consider how your actions in this thread make you appear, and have a good day.
Systemd and Upstart are both advanced init systems and serve a very similar purpose. Complaining that one wasn't initially mentioned is just a way to prevent admitting that you're wrong. Arch took a very long time to make the step. That's a fact.
Flagging posts that are correct and provide sources should rather make you consider your own actions, but Arch users are often notoriously bad at facing reality.
> The Pentium D brand refers to two series of desktop dual-core 64-bit x86-64 microprocessors with the NetBurst microarchitecture, which is the dual-core variant of Pentium 4 "Prescott" manufactured by Intel.
https://www.freebsd.org/where.html 11-RELEASE and 12-CURRENT snapshots are still being published for i386!
* https://blog.pcbsd.org/2013/06/pc-bsd-status-update/
I doubt Linux distros are generally targeting these devices, though.
Can anyone comment about their experiences with moving to Arch and the learning curve?
To me arch is designed to force you to learn the guts of your system, so it has a relatively high learning curve but it is one that pays dividends in the form of understanding what your system is doing and how it is setup. (this aside from the side-effect of keeping it debloated and therefor fast)
Honestly, what I would suggest is this:
Step 1:(if you have the time) go through a full arch install. Now format and do it again without following the guide. Now maybe do it one more time.
Step 2: (if pressed for time and/or lazy) Install Manjaro. I distro-hop frequently, and while I generally try to use debian on servers, for desktop/laptop use I have gone from Arch to Suse to Fedora, but I recently gave Majaro a shot, and I can honestly say next to Suse it has the easiest and most graceful linux installer I have ever seen (beating even Ubuntu). I generally don't like using Mint-like everything in a box distros, but the slimness of Arch along with the Just works of Ubuntu/Fedora/Suse I am finding it highly likely Manjaro is going to be my distro of choice for a long time to come. If in doubt, you can always just fire up different installs in a virtualbox first.
[1] Installing a 32-bit package on Debian uninstalls all 64-bit packages????????????????? Why is this even allowed?
Best simple/minimal install: use XFCE without a login manager. This gives you a very nice "default" environment without having to spend any time configuring.
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.
I'm sure Arch for what it is trying to be is user friendly in that sense, but it's not what I'm looking for right now.
I have a few 32 bit machines under my watch, and this is disheartening.
see; https://manjaro.org/get-manjaro/
Or simply use "Manjaro Minimal Net Edition (32-bit)"
Another alternative is to use BlackArch (32-bit)
https://blackarch.org/downloads.html