Hacker News Reader

Comment by viraptor | Hacker News Reader

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

View on HN

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

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.

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

Actually Debian's rolling release is newer than Arch, 5.3.1:

https://packages.debian.org/source/testing/gcc-5

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

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.

testing is Debian's rolling release.

Ack on the version stuff.

Testing isn't a rolling release, that's sid / unstable.

Testing is where the next stable (currently Stretch) is being worked out.

Except it's not, it's for testing.

Testing doesn't always get security fixes in a timely manner.

> testing is Debian's rolling release.

Except for when it freezes.

Reply on news.ycombinator.com