10 ms·

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 switc

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.

CJefferson 10y ago
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.
- Asooka 10y ago
  In fairness, this was back when we all thought Py3 would take over Py2 "any day now"™
  - avian 10y ago
    "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.
- tbranyen 10y ago
  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.
- Fiahil 10y ago
  Well, even Ansible folks started to switch to python 3 (https://docs.ansible.com/ansible/python_3_support.html https://docs.ansible.com/ansible/python_3_support.html). Pushing people off python 2 is not "absolutely evil".
  - CJefferson 10y ago
    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.
    - simplyluke 10y ago
      So forever into the future $ python should run python2? That's not pragmatic at all.
      - michaelmrose 10y ago
        Why not? Can you elaborate?
        greggyb 10y ago
        Pythons 4, 5, 6..., N will feasibly exist in the future. Why should Python 2 forever retain the executable name 'python'?
        marvy 10y ago
        If Py4 is compatible with Py3, why bump the version number? If not, you better be careful which one you get!
        michaelmrose 10y ago
        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.
- StreakyCobra 10y ago
  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.
  - CJefferson 10y ago
    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.
  - bbatha 10y ago
    Except that python says that python 3 should be an executable named `python3` and `python` should refer to `python2` [0] 0: https://www.python.org/dev/peps/pep-0394/ https://www.python.org/dev/peps/pep-0394/
    - StreakyCobra 10y ago
      Fair point. But Archlinux made the switch in 2010 [1], and this PEP was created in 2011. [1] https://www.archlinux.org/news/python-is-now-python-3/ https://www.archlinux.org/news/python-is-now-python-3/
- michrassena 10y ago
  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"?
  - gravypod 10y ago
    > Why do we still type "bash" instead of "bash4" Because Bash was made by, and is maintained by, people who understand how backwards compatability in their program is important.
    - hobarrera 10y ago
      Just like python. That's why they bumped the major when release backwards-incompatible changes, which is the right thing to do.
  - CJefferson 10y ago
    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.
    - michrassena 10y ago
      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.
- throwaway7767 10y ago
  Those scripts should probably be using something like the following, if they really are python2-only: #!/usr/bin/env python2 I get your frustration though, it's a change that breaks a whole lot of existing scripts.
  - maxerickson 10y ago
    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.
- Latty 10y ago
  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.
  - CJefferson 10y ago
    I thought the official advice was that 'python' should remain 'python2'? from https://www.python.org/dev/peps/pep-0394/ 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 ."
    - StreakyCobra 10y ago
      Archlinux made the switch in 2010 [1], and this PEP was created in 2011. [1] https://www.archlinux.org/news/python-is-now-python-3/ https://www.archlinux.org/news/python-is-now-python-3/
  - rlpb 10y ago
    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. (I am a non-Arch distribution developer)
- seiferteric 10y ago
  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.
  - Zancarius 10y ago
    "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.
- djsumdog 10y ago
  Ubuntu does this now with Xenial.
  - pseudalopex 10y ago
    Ubuntu uses Python 3 where possible, but /usr/bin/python is 2.7.
- boznz 10y ago
  Lets hope Python 4 comes out soon so you guys can unite against the real enemy :-)
- hobarrera 10y ago
  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.
  - rlpb 10y ago
    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".
    - hobarrera 10y ago
      > There was no such convention or specification at the time. There was no formal specification, but there was a convention that many distributions were already following (and quite a few others were not).
pjmlp 10y ago
Or switch to a less pragmatic distribution.
- StreakyCobra 10y ago
  Indeed.
DanBC 10y ago
> 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.
- tbranyen 10y ago
  Install an earlier (supported) version of Arch, or use a different distro are the options to try before a landfill.
  - jonathonf 10y ago
    That's not how Arch works... ;)
    - recursive 10y ago
      How does Arch work?
      - LukeShu 10y ago
        Arch is rolling release; there isn't really an older version that you can go back to, the installer just fetches the latest versions of the packages. Of course, there's the Arch Linux Archive, which lets you sync packages as they were on a particular date.
        tbranyen 10y ago
        Obviously, but there are also full offline images. Have you never used Arch before?
- StreakyCobra 10y ago
  There are other distributions better suited (even specialized) to be run on old hardware.
yAnonymous 10y ago
>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 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.
- JetSetWilly 10y ago
  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.
  - the_why_of_y 10y ago
    openSUSE 12.1 had systemd by default, released in Nov. 2011. https://en.opensuse.org/Archive:Portal:12.1 https://en.opensuse.org/Archive:Portal:12.1
  - yAnonymous 10y ago
    Ubuntu had Upstart in 9.04 (2009), as did others before they used systemd. I posted a source...
lamontcg 10y ago
> They were always in the early birds for taking decision about the future 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.

CJefferson 10y ago

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.

Asooka 10y ago
In fairness, this was back when we all thought Py3 would take over Py2 "any day now"™
- avian 10y ago
  "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.
tbranyen 10y ago
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.
Fiahil 10y ago
Well, even Ansible folks started to switch to python 3 (https://docs.ansible.com/ansible/python_3_support.html https://docs.ansible.com/ansible/python_3_support.html). Pushing people off python 2 is not "absolutely evil".
- CJefferson 10y ago
  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.
  - simplyluke 10y ago
    So forever into the future $ python should run python2? That's not pragmatic at all.
    - michaelmrose 10y ago
      Why not? Can you elaborate?
      - greggyb 10y ago
        Pythons 4, 5, 6..., N will feasibly exist in the future. Why should Python 2 forever retain the executable name 'python'?
        marvy 10y ago
        If Py4 is compatible with Py3, why bump the version number? If not, you better be careful which one you get!
        michaelmrose 10y ago
        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.
StreakyCobra 10y ago
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.
- CJefferson 10y ago
  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.
- bbatha 10y ago
  Except that python says that python 3 should be an executable named `python3` and `python` should refer to `python2` [0] 0: https://www.python.org/dev/peps/pep-0394/ https://www.python.org/dev/peps/pep-0394/
  - StreakyCobra 10y ago
    Fair point. But Archlinux made the switch in 2010 [1], and this PEP was created in 2011. [1] https://www.archlinux.org/news/python-is-now-python-3/ https://www.archlinux.org/news/python-is-now-python-3/
michrassena 10y ago
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"?
- gravypod 10y ago
  > Why do we still type "bash" instead of "bash4" Because Bash was made by, and is maintained by, people who understand how backwards compatability in their program is important.
  - hobarrera 10y ago
    Just like python. That's why they bumped the major when release backwards-incompatible changes, which is the right thing to do.
- CJefferson 10y ago
  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.
  - michrassena 10y ago
    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.
throwaway7767 10y ago
Those scripts should probably be using something like the following, if they really are python2-only: #!/usr/bin/env python2 I get your frustration though, it's a change that breaks a whole lot of existing scripts.
- maxerickson 10y ago
  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.
Latty 10y ago
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.
- CJefferson 10y ago
  I thought the official advice was that 'python' should remain 'python2'? from https://www.python.org/dev/peps/pep-0394/ 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 ."
  - StreakyCobra 10y ago
    Archlinux made the switch in 2010 [1], and this PEP was created in 2011. [1] https://www.archlinux.org/news/python-is-now-python-3/ https://www.archlinux.org/news/python-is-now-python-3/
- rlpb 10y ago
  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. (I am a non-Arch distribution developer)
seiferteric 10y ago
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.
- Zancarius 10y ago
  "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.
djsumdog 10y ago
Ubuntu does this now with Xenial.
- pseudalopex 10y ago
  Ubuntu uses Python 3 where possible, but /usr/bin/python is 2.7.
boznz 10y ago
Lets hope Python 4 comes out soon so you guys can unite against the real enemy :-)
hobarrera 10y ago
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.
- rlpb 10y ago
  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".
  - hobarrera 10y ago
    > There was no such convention or specification at the time. There was no formal specification, but there was a convention that many distributions were already following (and quite a few others were not).

pjmlp 10y ago

Or switch to a less pragmatic distribution.

StreakyCobra 10y ago
Indeed.

DanBC 10y ago

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

tbranyen 10y ago
Install an earlier (supported) version of Arch, or use a different distro are the options to try before a landfill.
- jonathonf 10y ago
  That's not how Arch works... ;)
  - recursive 10y ago
    How does Arch work?
    - LukeShu 10y ago
      Arch is rolling release; there isn't really an older version that you can go back to, the installer just fetches the latest versions of the packages. Of course, there's the Arch Linux Archive, which lets you sync packages as they were on a particular date.
      - tbranyen 10y ago
        Obviously, but there are also full offline images. Have you never used Arch before?
StreakyCobra 10y ago
There are other distributions better suited (even specialized) to be run on old hardware.

yAnonymous 10y ago

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

JetSetWilly 10y ago
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.
- the_why_of_y 10y ago
  openSUSE 12.1 had systemd by default, released in Nov. 2011. https://en.opensuse.org/Archive:Portal:12.1 https://en.opensuse.org/Archive:Portal:12.1
- yAnonymous 10y ago
  Ubuntu had Upstart in 9.04 (2009), as did others before they used systemd. I posted a source...

lamontcg 10y ago

> They were always in the early birds for taking decision about the future 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.