5 ms·

Could someone explain what's special about Arch compared to other types of Linux? I don't know and I don't understand when reading it here.

viraptor 11y ago
About Arch itself - nothing much. It's just in the same bag as Gentoo regarding release process. Rolling rather than periodic release means that whenever upstream project releases a new package, it's either automatically monitored or someone clicks "out of date" on the package site (like https://www.archlinux.org/packages/core/x86_64/bash/ https://www.archlinux.org/packages/core/x86_64/bash/). Then you get the new version in hours or days, rather than when the next OS release comes out. Taking GCC for example, that means Arch users are at 5.3.0 now, while Debian is still on 4.9.2. For security patches though that means that on Arch you have to upgrade to the latest version, while Debian will likely give you the same version you're already running with the issue fixed. This may be annoying on Arch if you're patching PHP for example - it may not work anymore with the site you're running and you have to migrate to the latest version.
- g1n016399 11y ago
  Actually Debian's rolling release is newer than Arch, 5.3.1: https://packages.debian.org/source/testing/gcc-5 https://packages.debian.org/source/testing/gcc-5
  - viraptor 11y ago
    That's in testing though. Arch has 5.3.0 in core already. Not sure where the .1 comes from since it's not even released yet according to https://gcc.gnu.org/releases.html https://gcc.gnu.org/releases.html Edit: Actually it looks like the versions are just named differently. Debian uses SVN version from 20151205, while Arch uses 20160209. So Arch is more fresh (by 2 months), but uses different naming convention.
    - g1n016399 11y ago
      testing is Debian's rolling release. Ack on the version stuff.
      - Ao7bei3s 11y ago
        Except it's not, it's for testing. Testing doesn't always get security fixes in a timely manner. Read more at: https://www.debian.org/security/faq#testing https://www.debian.org/security/faq#testing
      - amdavidson 11y ago
        Testing isn't a rolling release, that's sid / unstable. Testing is where the next stable (currently Stretch) is being worked out.
      - _yy 11y ago
        > testing is Debian's rolling release. Except for when it freezes.
- _yy 11y ago
  > It's just in the same bag as Gentoo regarding release process. There's a big difference, though - Arch Linux has no concept of partial upgrades. You have to update, or things break. Gentoo allows you to stick with old versions and has a pretty sophisticated mechanism for that ("slots"). It's also complicated, which is one of the reasons Arch Linux is easier to use. This makes Arch Linux unsuitable for pretty much any "production" scenario. Puppet version updated to 4? Tough luck if you didn't scramble and update all of your code since version 4 has backwards-incompatible changes. Works pretty well for desktops - if something breaks, you can usually just fix it. But it does not scale. Gentoo, on the other hand, has an unstable and a "stable" channel and you can use it for production systems if you've got the necessary manpower to essentially build your own distro.
  - majewsky 11y ago
    I'm running Arch Linux in production for my private systems, and am currently extending it to a system previously on Debian oldstable in order to harmonize my processes. It works very well for me (I didn't have any update-induced downtimes yet, except for the usual reboots to apply kernel upgrades), but I can easily see how people could struggle with the no-partial-upgrade problem when they employ complex, fast-moving software stacks. My solution is to package that software myself in a private repo, so that I get to decide when to upgrade. In Arch, probably more than with any other binary distribution, it helps very much to have a good grip on the packaging process. Once you already have your private repo and signing key set up and rolled out everywhere, the barrier to rolling the next custom package is much slower.
    - _yy 11y ago
      > I didn't have any update-induced downtimes yet, except for the usual reboots to apply kernel upgrades Wait until the first major backwards-incompatible config format change breaks something. Puppet was one example of many. > My solution is to package that software myself in a private repo, so that I get to decide when to upgrade. Works fine for single applications, breaks horribly for system-wide shared libraries.
calpaterson 11y ago
Arch is based on "rolling" releases where they very quickly promote whatever the original author has released into their distro. I think there are some checks but it is quite a light process. You are a lot closer to the upstream developers of the software you use, but you have to take on the responsibility for stability. A lot of the Debian process is trying to avoid releasing packages with (known) bugs
- wfunction 11y ago
  Ahh, that explains it, thank you.

viraptor 11y ago

About Arch itself - nothing much. It's just in the same bag as Gentoo regarding release process. Rolling rather than periodic release means that whenever upstream project releases a new package, it's either automatically monitored or someone clicks "out of date" on the package site (like https://www.archlinux.org/packages/core/x86_64/bash/ https://www.archlinux.org/packages/core/x86_64/bash/). Then you get the new version in hours or days, rather than when the next OS release comes out. Taking GCC for example, that means Arch users are at 5.3.0 now, while Debian is still on 4.9.2. For security patches though that means that on Arch you have to upgrade to the latest version, while Debian will likely give you the same version you're already running with the issue fixed. This may be annoying on Arch if you're patching PHP for example - it may not work anymore with the site you're running and you have to migrate to the latest version.

g1n016399 11y ago
Actually Debian's rolling release is newer than Arch, 5.3.1: https://packages.debian.org/source/testing/gcc-5 https://packages.debian.org/source/testing/gcc-5
- viraptor 11y ago
  That's in testing though. Arch has 5.3.0 in core already. Not sure where the .1 comes from since it's not even released yet according to https://gcc.gnu.org/releases.html https://gcc.gnu.org/releases.html Edit: Actually it looks like the versions are just named differently. Debian uses SVN version from 20151205, while Arch uses 20160209. So Arch is more fresh (by 2 months), but uses different naming convention.
  - g1n016399 11y ago
    testing is Debian's rolling release. Ack on the version stuff.
    - Ao7bei3s 11y ago
      Except it's not, it's for testing. Testing doesn't always get security fixes in a timely manner. Read more at: https://www.debian.org/security/faq#testing https://www.debian.org/security/faq#testing
    - amdavidson 11y ago
      Testing isn't a rolling release, that's sid / unstable. Testing is where the next stable (currently Stretch) is being worked out.
    - _yy 11y ago
      > testing is Debian's rolling release. Except for when it freezes.
_yy 11y ago
> It's just in the same bag as Gentoo regarding release process. There's a big difference, though - Arch Linux has no concept of partial upgrades. You have to update, or things break. Gentoo allows you to stick with old versions and has a pretty sophisticated mechanism for that ("slots"). It's also complicated, which is one of the reasons Arch Linux is easier to use. This makes Arch Linux unsuitable for pretty much any "production" scenario. Puppet version updated to 4? Tough luck if you didn't scramble and update all of your code since version 4 has backwards-incompatible changes. Works pretty well for desktops - if something breaks, you can usually just fix it. But it does not scale. Gentoo, on the other hand, has an unstable and a "stable" channel and you can use it for production systems if you've got the necessary manpower to essentially build your own distro.
- majewsky 11y ago
  I'm running Arch Linux in production for my private systems, and am currently extending it to a system previously on Debian oldstable in order to harmonize my processes. It works very well for me (I didn't have any update-induced downtimes yet, except for the usual reboots to apply kernel upgrades), but I can easily see how people could struggle with the no-partial-upgrade problem when they employ complex, fast-moving software stacks. My solution is to package that software myself in a private repo, so that I get to decide when to upgrade. In Arch, probably more than with any other binary distribution, it helps very much to have a good grip on the packaging process. Once you already have your private repo and signing key set up and rolled out everywhere, the barrier to rolling the next custom package is much slower.
  - _yy 11y ago
    > I didn't have any update-induced downtimes yet, except for the usual reboots to apply kernel upgrades Wait until the first major backwards-incompatible config format change breaks something. Puppet was one example of many. > My solution is to package that software myself in a private repo, so that I get to decide when to upgrade. Works fine for single applications, breaks horribly for system-wide shared libraries.

calpaterson 11y ago

Arch is based on "rolling" releases where they very quickly promote whatever the original author has released into their distro. I think there are some checks but it is quite a light process. You are a lot closer to the upstream developers of the software you use, but you have to take on the responsibility for stability. A lot of the Debian process is trying to avoid releasing packages with (known) bugs

wfunction 11y ago
Ahh, that explains it, thank you.