[apetresc]

I think you're confusing Arch with Gentoo or something - the Arch package manager is not from-source, it ships binaries just like apt. Perhaps you're thinking of the AUR, which does usually just host the PKGBUILD which you run makepkg on directly to compile, but that's analogous to something like an Ubuntu PPA, not the core package manager.

The main thing that people like about it is the rolling release model; new packages for virtually everything are updated within hours or days of an upstream release, with incredible practical stability.

> > Before upgrading, users are expected to visit the Arch Linux home page to check the latest news, or alternatively subscribe to the RSS feed or the arch-announce mailing list > Like... why?

That's very much a "cover-your-ass" type disclaimer, like a ToS that says you have no right to expect anything to work. In practice, 99.99% of upgrades work completely unattended, and in the .01%, you see a failure, you go to the News site and it says "sorry, we made a backwards-incompatible push, please delete this path before upgrading" or something like that, you do it, and then everything is fine again for another 18 months.

Arch still has the vestiges of this reputation as a wild-west distribution for reckless code cowboys, but in practice it is the de-facto "set it and forget it" distro. I spend literally 10x less time worrying about my distribution and package manager when I'm on Arch then on any other computing system I've ever encountered.

[lgunsch]

I have used Arch Linux for the past 8 years. I've had 3 installations on four different laptops (I migrated one installation to a second laptop).

Your comment would be a really great description of my experience.

[matheusmoreira]

Same here. I really don't understand why it has a reputation for instability. I use it on my home server.

[HKH2]

With Arch, I've had several times on separate machines when after updating I have had to mess around with recovery stuff, manually boot and reinstall grub or whatever.

I really don't need cutting edge packages, so I don't use it any more, but I understand why people would want a lean system by default.

[bavell]

I've used Arch for the better part of the last decade and agree with this assessment as well.

[pxc]

> The main thing that people like about it is the rolling release model; new packages for virtually everything are updated within hours or days of an upstream release, with incredible practical stability.

Fedora Rawhide and openSUSE Tumbleweed are both nearly as up-to-date[1] as the Arch repos but they have package managers with correct dependency solvers and continuous integration pipelines with tests produce their repos. NixOS Unstable is more up-to-date than Arch Linux[1], and its package manager never breaks your system on upgrades and features automatic rollbacks no matter what filesystem you use.

‘I want a rolling release’ doesn't really explain the choice to use Arch in particular, imo, and it's weird that this extremely common answer to ‘why Arch’ talks about a feature that isn't really specific to Arch

—

1: https://repology.org/repositories/statistics/pnewest

[matheusmoreira]

I had really bad experience with Fedora and Arch Linux just didn't give me any problems. Maybe it's better now, I don't know.

[dralley]

I don't recommend using Rawhide, but standard Fedora is pretty up to date anyway, so it's not necessary.

[II2II]

It is probably a reference to the AUR, but its use is not as common as some people seem to think and is somewhat discouraged (since, like PPA, the packagers are not necessarily trusted). I would also have a hard time claiming that programs from the AUR are compiled yourself. Yes, the software is usually compiled on your own hardware. On the other hand, the compilation process is handled by makepkg or an AUR helper. With an AUR helper, the process is remarkably like installing a program with pacman since it will handle dependencies.

[pxc]

> It is probably a reference to the AUR, but its use is not as common as some people seem to think and is somewhat discouraged

Arch proper has like 60% the package count of openSUSE, fewer than 1/2 as many packages as Fedora, fewer than 1/3 as many packages as Debian, and fewer than 1/6 as many packages as NixOS.[1]

Maybe some of this is Arch having larger packages (splitting fewer of them out), but whatever fudge factor you wanna add in, the Arch repos are extraordinarily small. You have to get into really niche shit like Solus or Exherbo to find a distro with a smaller software selection than the Arch repositories.

The idea that Arch is as usable as most Linux distros without leveraging the AUR is ridiculous.

—

1: https://repology.org/repositories/statistics/total

[II2II]

What matters is the relevance of the packages in the main repositories, not the quantity. While the quantity will affect some people, it will primarily affect those who use obscure packages.

As for the fudge factor, it would be difficult to even agree upon criteria. For example: should python or rust libraries be included, given they have their own package managers?

[pxc]

> What matters is the relevance of the packages in the main repositories, not the quantity.

This is a good point. It would be awesome if we had the metrics to look at this. I would not be surprised if Arch had a good focus on popular packages.

And yeah, what's relevant will vary between users.

> As for the fudge factor, it would be difficult to even agree upon criteria. For example: should python or rust libraries be included, given they have their own package managers?

I don't think this particular case would be too tricky. We can probably exclude them, or just count them separately. Libraries packaged in the distro package manager are useful, but they're mostly useful for simplifying the process of creating new packages for the distro.

[matheusmoreira]

> The idea that Arch is as usable as most Linux distros without leveraging the AUR is ridiculous.

Not really. I don't have a single AUR package installed. The paperkey software used to be the only AUR package I had installed. It eventually became part of the official repositories.

[simion314]

>That's very much a "cover-your-ass" type disclaimer,

This is not true for all hardware configurations or true for all packages combination(including weird AUR ones) in the world. For sure if we Google if this really happens in the real world you will see that indeed update break things.

Also keeping up with upstream does not mean you only get the new features but also the new bugs, especially if you were using GNOME3 a fee years back at each new GNOME release the forums and reddit was filled with new memory leaks issue, new plugin/extension breakage issues and even GNOME not starting up.

[jorgemf]

Usually when gnome doesn't start up in arch it is due extensions which are not supported either gnome or arch. But you usually find them in AUR, which fix your issues quite quickly. I haven't had any issues with gnome 3 in arch since they move to it, apart from extensions and a couple of things not well integrated in Wayland+gnome. Said that, it has been much more a nightmare for me to install packages in docker images of Ubuntu.

[simion314]

My point is that in Arch you can't start your work day by updating your system, you might have to fix shit instead of working.

With an LTS distro I know when teh notification for updates appears that is a security thing and it is safe to update.

>Said that, it has been much more a nightmare for me to install packages in docker images of Ubuntu.

I am assuming you are trying to install something outside the official repos, like you want to get the latest node/python or some other latest stuff using a PPA. Those PPA might not be that good quality so you could get issues like conflicts. I am not a sysadmin or dev-ops guy to tell you what is the correct way to install newer version of stuff.

[jorgemf]

My point is that will lose more time installed unsupported packages than losing some time when arch breaks, because it rarely breaks (less than once a year). And fixes usually take 5 minutes

[simion314]

I think it depends on the user and hardware. Many years ago I had a laptop with an AMD GPU and CPU, it was new like 1 year old when AMD drop support for the driver. If I wanted decent compositing on Linux I had to stay with an older kernel and Xorg version so I used old Ubuntu LTSes and debian at that time. And i decided to never use AMD, I got an Intel+NVIDIA PC, but now it seems NVIDIA is the one with shit drivers, and I don't change my hardware often so I will continue using my GTX-970 as many years it will hold.

[jorgemf]

Many years ago is not the same in Linux in general. Try it now. I didn't have those issues in more than a decade. Everything worked out of the box

[gbrown]

> I think you're confusing Arch with Gentoo or something - the Arch package manager is not from-source, it ships binaries just like apt. Perhaps you're thinking of the AUR

Sorry, what I meant was: when I need to manage the version of something carefully, I just compile it from source and that's OK with me. My understanding is that people use the AUR for this on Arch, and the pains don't seem worth it.

> The main thing that people like about it is the rolling release model

Fair enough, though I've been pretty happy with the pace of update from, for example, Fedora.

> That's very much a "cover-your-ass" type disclaimer, like a ToS that says you have no right to expect anything to work.

Fair enough

[JeremyNT]

> Sorry, what I meant was: when I need to manage the version of something carefully, I just compile it from source and that's OK with me. My understanding is that people use the AUR for this on Arch, and the pains don't seem worth it.

Nobody's making you use the AUR! If you want to 'make && sudo make install' you can do that all day long.

The AUR value add is that other people have already figured out recipes for how to take the equivalent of 'make && sudo make install' and generate a package you can mange with the package manager.

There exist plenty of tools to automate all AUR interactions, but none of these will ever be included in Arch's main repos, since they are not a core part of Arch itself. This is to maintain a sharp delineation between properly supported Arch packages and the more wild west AUR recipes. That said, once you download a PKGBUILD from the AUR, you can use the same official tools to build and install the package that are used for the distro proper.

When I want to build from source, and something isn't in the AUR, I just spend the 5 minutes to make a proper PKGBUILD for myself. It is very easy and it simplifies management of things.