23 ms·
Can an Arch person explain to me why their approach is worth it over something with a more comprehensive package manager like apt or dnf? I don’t mind compiling
by gbrown 5y ago
Can an Arch person explain to me why their approach is worth it over something with a more comprehensive package manager like apt or dnf? I don’t mind compiling programs myself when needed, but for most things I’m happy to not have to hand-hold my OS when it comes to updates.
From the wiki:
> 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?
- jimjimjimjim 5y agoSometimes there are some manual interventions that you may have to perform.
- gbrown 5y agoYeah, exactly. Why?
- deleted 5y ago[deleted]
- nvarsj 5y agoIt's the philosophy of Arch to stick to vanilla as much as possible and keep things simple. It's a rolling distro too with no fixed release cycles. When you upgrade fedora, ubuntu, etc. they perform various scripts to migrate existing configuration. In Arch, it just simply installs the vanilla packages whenever you tell pacman to update. Very rarely there is some breaking change, maybe once or twice a year, that requires manual intervention. Yeah they could automate it all but such stuff takes effort and breaks in other ways.
- doubled112 5y agoBecause many of the changes are large enough that it will break, and that's expected. The KISS principle applies here. If a config file format changes in a service between version 3 and version 4, should the package manager be responsible for it? Or the admin? Sometimes it's not just merging changes in. In a non-rolling release distribution, you only need to worry about those changes during major upgrades. In a rolling release distro, they can change at any time. It's no different than a user reading the release notes for Debian 11 while upgrading from 10, except the upgrades are constant.
- nemetroid 5y agoFor one, not putting every single edge case into the package manager makes the behaviour of the package manager easier to understand.
- elitepleb 5y agoUpstream breaks your stuff, you roll into the incompatible release, getting to fix it yourself. There's no fixed release schedule that promises total compatibility at the cost of running years old releases.
- spystath 5y agoWell, manual interventions are rare [0] and almost all of them nowadays are due to the odd package restructuring. Usually the package manager will notify you about a conflict between two packages and won't proceed (so nothing will break). At this point you can check the website if there is a need to force install a package or two. Although definitely more technical than most distributions the perceived difficulty of Arch is mostly a meme at this point. The last large possibly-system-breaking change was almost 10 years ago [1]. And even then, the solution was quite trivial. Now if you are forcing updates that conflict without reading the news then you're in for a bad time, but that's true for all distributions. In general pacman is very conservative and won't leave your system partially updated. Now there is a chance upstream updates break things, but that's the nature of the rolling release model. Manual compilations are not necessary if you stick to the official repositories. If you need a package in the AUR then a ports-like setup is required. I have packaged stuff for both RPM and DEB-based distributions, nothing really beats the simplicity and flexiblity of the Archlinux packaging tools. [0]: https://archlinux.org/news/ https://archlinux.org/news/ [1]: https://archlinux.org/news/the-lib-directory-becomes-a-symlink/ https://archlinux.org/news/the-lib-directory-becomes-a-symli...
- vladvasiliu 5y agoLooking through the latest advisories of upgrades requiring manual intervention, those mostly seem to be files that were mishandled. I guess they want to avoid "being smart" and trying to second guess the system setup. Other distributions attempt to migrate the config / tools which mostly works, except when it doesn't. Earlier today I upgraded an Ubuntu 21.04 to 21.10. The computer is a glorified Spotify Connect player, so I don't configure anything on it. But for some reason, after the reboot, there's some issue with gvfsd-something-or-other. I never configured anything related to that. Is this normal / expected? No idea. A quick search on the release notes [0] yields nothing. So I guess there are always tradeoffs. Arch seems to adopt more of a hands-off approach, where you only get a basic system and then you build your own environment. As such, there's many possible variations. In contrast to Ubuntu / Fedora / etc, where the devs can reasonably expect that a system is in a roughly known state. [0] https://discourse.ubuntu.com/t/impish-indri-release-notes/21951 https://discourse.ubuntu.com/t/impish-indri-release-notes/21...
- omnicognate 5y agoYou can see the announcements at https://archlinux.org/ https://archlinux.org/. The most recent is from June: > Starting with libxcrypt 4.4.21, weak password hashes (such as MD5 and SHA1) are no longer accepted for new passwords. Users that still have their passwords stored with a weak hash will be asked to update their password on their next login.If the login just fails (for example from display manager) switch to a virtual terminal (Ctrl-Alt-F2) and log in there once. I wasn't affected. The next one before that was February, and also didn't affect me. I think I could count the number of such planned manual interventions that have affected me in the 6 years I've been running Arch on my laptop on the fingers of one hand. It's approximately the number of times I would have had to reinstall my OS from scratch in that time on most other distros, based on extensive prior experience of whole distro version upgrades messing things up in mysterious ways. I put this down to the rolling release and the arch devs not being lulled onto assuming everyone's running a fresh, pristine installation. I have a 6 year old, heavily used (including for work), heavily customised development laptop I have installed the OS on exactly once, and I have absolutely no reason to contemplate starting again from scratch. It's bang up to date and rock solid. You'd have to pry Arch from my cold, dead fingers.
- jorgemf 5y agoPacman now tells you when there is an announcement in the website. Most of this announcements are due some issue introduced in a package. I haven't faced all of them as usually they resolved quickly and when I update the system the new packages solves the issue. Rarely there has been a breaking change in a package that needed some easy manual intervention. I have maybe done this line 5 or 6 times in 15 years. Compared to Ubuntu, I find it upgrading process more tedious (I haven't tried it in the last year's so maybe now is better). Said that, probably i won't use arch for a production environment and stick to Ubuntu, but for home/work system, I love it
- javier2 5y agoThey announce (known) breaking changes that may require manual intervention. Meanwhile, when my ubuntu upgrade breaks something there is never any release notes or documentation to help me fix it. After my previous ubuntu upgrade at work, the screen locker is segfaulting instead of locking my screen, and clicking links inside the Slack crashes slack...
- ayushnix 5y agoYou can either deal with it once in while or you could let it pile up for years and then when a new major release comes up, you could spend days troubleshooting or reinstalling from scratch. I think either method is fine, depending on the circumstances. Your choice.
- apetresc 5y agoI 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.
- simion314 5y ago>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 5y agoUsually 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.
- schleck8 5y agoSometimes when visiting arch forums the undertone is a little gatekeep-ey and people asking for more beginner friendly ways to install software like GUIs or AUR helpers are responded to with answers like 'You don't. You compile it yourself from the command line'.
- cyber_kinetist 5y agoFor a more beginner-friendly approach to Arch, try Manjaro. The user experience is much better: you can choose one out of several desktop environments and get sane defaults, has its own system that can easily swap between different drivers and kernels, and generally very robust overall. Also the forums are more friendly towards beginners, so I view it as Arch without the elitism. The package updates are usually several weeks behind from Arch (since it uses a curated snapshot of Arch), but I view this as a plus (in reality you don’t need that much bleeding-edge updates).
- swasheck 5y agoi say this as a windows user for my workplace, but that's not being gatekeepers, it's upholding the ethos of the distribution. i've used arch quite a bit as a hobby linux and the reality is that i've learned more about linux via arch documentations and by being curious about how to resolve things instead of demanding an easy path. the knowledge gained produces the easy path.
- d3nj4l 5y agoThe the ethos of the distribution is gatekeeping :)
- alexarnesen 5y agoArch is the first system I have been able to support, fully. As in, 100% of the issues I run across with my distro, I can resolve. I used to run Ubuntu as my gnome desktop distribution, and when it worked (99% of the time), it was a superior experience to Arch. However when running Ubuntu I would inevitably run across some issue that seemed to require a level of sysadmin chops that I never have possessed. For the past year I've been running an Arch desktop, I have resolved every issue by using the Arch wiki and Google/ stack overflow. I suspect that partly, the Arch approach is appealing to those of us who prefer a simpler system, because those are easier to grapple with in a support context.
- stonemetal12 5y agoWould you recommend Arch to someone without a lot of Linux experience? Ubuntu has me thinking of switching to a different OS.
- assbuttbuttass 5y agoYou can give it a try but be prepared to spend a lot of time reading the wiki
- bavell 5y agoIf you're interested, I'd recommend checking out the Arch wiki - imo it's one of the most comprehensive repositories of Linux info out there and pretty easy to follow. Even other distros use and link to it since it's very general and has a huge scope. Great reference for power users and starting point for beginners.
- trevcanhuman 5y agoI’d recommend going for it, and as others have said, be prepared to read the Arch Wiki, a lot. I think what’s most important would be to simply have the guts and the inspiration to keep going, even if you think you’ve lost all hope. Personally, I started out my Linux journey with Ubuntu, then distro hopped and tried PopOS, and Ubuntu-based distro with extra things here and there. Then, I took a Linux course online (for free) and gave me general fundamentals, it advertises as the “The Start from scratch Linux course”. After that and spending tons of time on Reddit and seeing post after post and the memes about ‘I use arch btw’ I decided to try it out. It was definitely fun and a tad time consuming at first, but after that I’ve learned a ton more about Linux and how things work. I’ve only had a broken system a couple times. Again, the ArchWiki is your friend.
- foxfluff 5y ago> Can an Arch person explain to me why their approach is worth it over something with a more comprehensive package manager like apt or dnf? Can you explain to me how dnf or apt is more comprehensive than pacman? I use all three: arch on my laptop, fedora on my desktop, ubuntu on my work laptop. I do not see the difference in comprehensiveness. There are some house cleaning tasks pacman won't automatically do for you because doing so could break things you rely on. The same is true on fedora. It'll leave configs untouched, unless you run rpmconf which might then just break your stuff: > If you use rpmconf to upgrade the system configuration files supplied with the upgraded packages then some configuration files may change. After the upgrade you should verify /etc/ssh/sshd_config, /etc/nsswitch.conf, /etc/ntp.conf and others are expected. For example, if OpenSSH is upgraded then sshd_config reverts to the default package configuration. The default package configuration does not enable public key authentication, and allows password authentication. (From https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/ https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-u...) The problem is ultimately one of churn, and how the system deals with it. Anecdotally Ubuntu tries to deal with it harder than the others, and my experience is that Ubuntu breaks (or suddenly stops behaving the way you had it configured) the most during updates. The others break less but require some attention from you. Some of the churn is caused by distros, some of it is caused by the upstream projects. Churn is big in the Linux world.
- nonameiguess 5y agoI'm honestly not sure what you mean by apt or dnf being more comprehensive. The feature set of all Linux package managers are pretty similar. The major difference with Arch is you're heavily recommended not to do partial upgrades, but pacman will do it if you really want to. That's a difference in update philosophy between batched releases and rolling releases, not a difference in the package managers. If you mean comprehensive in terms of available software, corporate and commercial software seems to often offer debs and rpms but not tarballs installable by pacman. On the other hand, for anything open source, the Arch official repository plus AUR has way more packages available than the Debian/Ubuntu and Redhat official repos, and having everything in one AUR for third-party packages is much more convenient than the apt/dnf way of adding a repo per vendor. As for checking the home page every time you upgrade, you really don't need to. I think that's to stave off complaints if something breaks, because it might since you have full freedom to set things up however you want and Arch can't guarantee the standard packages with standard settings are going to work for the combinatorial explosion of possible individual setups everyone might have. But in five years of daily Arch use (I have it as the OS on 8 devices in my house right now), I've auto-upgraded daily and experienced one breakage I can think of, two days ago when certain graphical apps stopped showing a visible window. It was annoying and I still don't know why it happened (guessing something about the Wayland/NVIDIA combo is still creating issues), but it fixed itself on the next ugprade 7h hours later or so.
- ubercow13 5y ago> package managers are pretty similar. The major difference with Arch is you're heavily recommended not to do partial upgrades, but pacman will do it if you really want to. That's a difference in update philosophy between batched releases and rolling releases, not a difference in the package managers. No it’s a difference in package managers. Pacman doesn’t take into account library versions when resolving dependencies, it’s why partial upgrades aren’t supported because the only way to ensure every package you have installed is linked against the version of its dependencies you have installed is to have every package on your system come from a snapshot in time of the whole repo package tree. Better package managers don’t have this problem and understand how to not break your system with partial upgrades. This matters as soon as a new version of a package has a bug and you want to downgrade it, or you build and install a package from the AUR which, when you later update your system, could need rebuilding to continue working, but pacman has no way to tell you when this is the case.
- cturtle 5y agoIn the last two years I’ve been on the arch-announce mailing list I think I have only needed to respond to breaking updates twice. I choose arch for three reasons. 1. The official repos and the AUR have nearly every package I have ever needed. And usually packages are updated soon after a release. 2. Being rolling release, I never need to reinstall arch, just run updates periodically. 3. I love learning, and I have learned more about Linux and system maintenance from arch than anything else. While there might be a slightly larger cost of time spent setting up (and maintaining when I break something) arch, I have decided that the tradeoffs are worth it to me.
- guerrilla 5y ago> Can an Arch person explain to me why their approach is worth it over something with a more comprehensive package manager like apt or dnf? I don’t mind compiling programs myself when needed, but for most things I’m happy to not have to hand-hold my OS when it comes to updates. It sounds like you may be confusing Arch with some other distro. You rarely if ever need to compile anything yourself. Pacman works just like apt or dnf, i.e. resolves dependencies, downloads and installs packages for you, unless you have something specific in mind.
- matheusmoreira 5y ago> a more comprehensive package manager like apt or dnf I don't see how apt or dnf are any more comprehensive than pacman. What do you mean by that? Before Arch, I used Fedora. It used yum as its package manager. That thing managed to corrupt its own databases at least twice during normal usage. Distribution major version upgrades always caused problems. I never had problems like these after switching to Arch. > I don’t mind compiling programs myself when needed You only need to compile user packages. Official Arch Linux repositories host binary packages. You can download the PKGBUILD if you want. > for most things I’m happy to not have to hand-hold my OS when it comes to updates. 99% of the time updates just work for me. Sometimes they introduce a few .pacnew files, I diff and merge them with my local files and that's it. > Like… why? Sometimes manual intervention is necessary. Usually it's not a big deal. The news tell you what to do and most importantly why you must do it. The most complicated maintenance I ever experienced with Arch was when it switched /bin to /usr/bin.
- diffeomorphism 5y agoNot PP, but to me it means much less manual intervention/more hooks etc. . For instance, for debian I can just turn on automatic updates and basically never need manual intervention. For arch I am not supposed to use automatic updates and have to (!) read the news. Why? Why does arch need more manual intervention? Sure, I can do that but it just seems like a pointless waste of time.
- m01 5y agoI don't think Debian's automatic updates do major release upgrades automatically, do they? Those IIRC do require manual intervention - if nothing else you need to run the installer & possibly respond to prompts, but possibly more depending on your system.
- pxc 5y ago> I don't think Debian's automatic updates do major release upgrades automatically, do they? Those IIRC do require manual intervention For major release upgrades, the official upgrade procedure is to follow instructions like these: https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html https://www.debian.org/releases/stable/amd64/release-notes/c... So yeah, you have a somewhat manual upgrade process once every two years, if you're not on one of the rolling release (‘testing’ or ‘unstable’). On the other hand, you do get to choose when you make those updates. You don't get caught by surprise with them because you forgot to read the news. Debian's documentation on Testing and Unstable[1] contains some snippets that may feel familiar to Arch users, including this very relevant bit: > Consider (especially when using unstable) if you need to disable or remove unattended-upgrades in order to control when package updates take place. — https://wiki.debian.org/DebianUnstable#What_are_some_best_practices_for_testing.2Fsid_users.3F https://wiki.debian.org/DebianUnstable#What_are_some_best_pr...
- MegaDeKay 5y agoAs another plus, the Arch wiki itself is absolutely fantastic. People will point to the Arch wiki even when running other distributions. For example, it is the place to go when doing something like GPU passthrough to another OS running on qemu/KVM.
- evol262 5y agoWhich, honestly, is grating. It's great that the Arch wiki is as good as the Gentoo wiki was in 2002, but it would be even better if the Arch wiki actually acknowledged the people doing the work. For GPU passthrough, for example, the initial author/current maintainer of VFIO published a development blog which has a [multi-part series explaining VFIO and passthrough from the bottom up](http://vfio.blogspot.com/2015/05/vfio-gpu-how-to-series-part-1-hardware.html http://vfio.blogspot.com/2015/05/vfio-gpu-how-to-series-part...) six years ago. This is not referenced anywhere in the Arch wiki, despite the fact that it's the literal author, most of the steps in their wiki haven't changed in the intervening years, and it's almost certain that whatever place the authors of that wiki page eventually cribbed it from probably came from the original blog. The Arch wiki contributors, in this sense, aren't great netizens. Worse, the Arch wiki (and various subreddits) are almost as bad as the Arch/Ubuntu forums were in 2005. They often lead to a bunch of "shotgun debugging" where users are copy and pasting things they don't understand at all in the hopes that it will fix whatever problem they're encountering for reasons they won't understand. Arch is fine, and it has its place. There are some brilliant people using Arch. The community in general is full of people who intentionally shoot themselves in the foot and are then proud that they find superglue for the wound on the Arch wiki instead of using a distro with better engineering practices where they never would have had these problems at all. The mistaken belief that doing any of this somehow "teaches" you meaningful things about Linux as opposed to solving real problems (since 99% of the "problems" Arch users encountered will never be seen on other distros, due to the fact that the maintainers carefully ensure there are limited footguns out of the) is terrible.
- pxc 5y ago> Worse, the Arch wiki (and various subreddits) are almost as bad as the Arch/Ubuntu forums were in 2005. They often lead to a bunch of "shotgun debugging" where users are copy and pasting things they don't understand at all in the hopes that it will fix whatever problem they're encountering for reasons they won't understand. This drives me absolutely fucking nuts. > The community in general is full of people who intentionally shoot themselves in the foot and are then proud that they find superglue for the wound on the Arch wiki instead of using a distro with better engineering practices where they never would have had these problems at all. This. A thousand times, this. > The mistaken belief that doing any of this somehow "teaches" you meaningful things about Linux as opposed to solving real problems (since 99% of the "problems" Arch users encountered will never be seen on other distros, due to the fact that the maintainers carefully ensure there are limited footguns out of the[m]) is terrible. Idk. There are definitely some Arch-specific footguns (like the lack of distinction between upgrade and dist-upgrade, so that ordinary pacman updates can do things like uninstall literally all of your kernels (lmfao)). But I don't think the basic approach is necessarily fatally flawed. When I installed Gentoo for the first time as a kid, getting everything working taught me: - how to identify hardware using using common utilities (like `lsusb`, `lspci`, and `lshw` - how to set up a chroot environment, how to use a chroot to manage or repair another system - how to install and configure a bootloader, what configuration a bootloader needed - how to use basic CLI networking tools to get online - how to manage kernel modules (blacklisting them or adding them to initrd), although admittedly a good distro will *usually* be able to anticipate those needs for you - how to think about package version constraints and manage packages from different sources - fundamentals of building and managing software (i.e., what compile-time options are, how to think about dependencies and reverse dependencies) Probably the first two are the most valuable, and I guess nowadays the Arch installation tools basically hide what is going on in the chroot environment from you (and actually make it tricky to customize, like if you want to add extra mountpoints to it). But I don't think the whole ‘set everything up yourself once’ approach is worthless.
- javier2 5y agoYou don't have to run arch if you are happy with your Ubuntu or whatever other distro. I run arch because I like trying out new software when its released, not when maintainers of ubuntu decide to include it in the next release cycle. You are pretty much always on the latest kernel, for good or bad. aur also is a gem compared to apt when it comes to modifying in-tree packages and maintaining those with the system package manager. But well, if you are happy with your distro you don't have to use anything else.
- pxc 5y ago> Can an Arch person explain to me why their approach is worth it over something with a more comprehensive package manager like apt or dnf? I don’t mind compiling programs myself when needed, but for most things I’m happy to not have to hand-hold my OS when it comes to updates. People who like Arch because they think the AUR is actually good hate doing repo management. What they like about the AUR is that it's One Big Repo, and it (unlike the barren Arch repos themselves) is pretty comprehensive. > > 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? Because Arch's interpretation of ‘keep it simple, stupid’ means they are allergic to engineering in their distro tools. As a result, their package manager has deficient dependency resolution behavior. This is exacerbated by the fact that the devs make relatively little use of things like transitional packages, for some reason. But Pacman is fast, because by choosing not to have a complete dependency solver, it avoids tackling a problem with high computational complexity. For some people, that part of the user experience is good enough that it allows them to forgive Pacman for doing insane things like pointlessly breaking installed software every now and again.