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.
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.
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.
"...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."
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.)
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.
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.
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.
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.
> 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.
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.
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 ."
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.
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.
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.
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.
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".
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.
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.
"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.
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.
> 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.
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.
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.
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?
>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.
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).
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
"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.
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.
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.
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?
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.
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.
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).
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.
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).
> 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.
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.