Hacker News Reader

Comment by amcrouch | Hacker News Reader

It's a matter of tools. All distro's are basically very similar but come with different desktops and package managers.

I spent many years jumping around Debian and its derivatives but then I found Arch and it just felt right. I love the package manager and the fact I can control what I have installed. With a 9 cell Thinkpad battery and some cleaver settings I can last all day.

I have to admit that these days I tend to run from Antergos which is a great Arch derivative but that is mainly because of a lack of time and a need to get stuff done. Also from years of installing and running standard Arch I can tweak things very quickly from Pacman.

View on HN

When it comes to tooling, I found the packaging strategy of Arch to be pretty invaluable, too:

- Pacman is a great package manager (esp. when compared to e.g. ´yum´).

- The Arch User Repository (https://aur.archlinux.org/) has a large list of additional packages maintained by the community.

- The PKGBUILD format used by the AUR is easy to read and essentially just generates Pacman packages you can install alongside packages from the Arch repo.

- PKGBUILD also makes it really easy to create a package for some obscure software yourself (or e.g. a specific font), if necessary.

- There are tools that create PKGBUILD packages from language repos like gem, npm or pypi (via pip). Those are really useful since they prevent language based packages from clashing with pacman.

In addition, I really like that arch is built with choice in mind: There's no default "way to go" - you can e.g. choose from several desktop environments without having to install a specific one first, meaning you can configure your system from the ground up.

I think Slackware and Gentoo work similarly? (I've personally never tried them)

Another aspect of the AUR that I skipped: The way Pacman packages are set up, it's possible for multiple packages to deliver a certain functionality.

This allows for a great number of AUR packages (the ones ending with "-git", "-hg" or the like) that essentially download/compile a bleeding edge version from the according source versioning repo (e.g. on Github). If they're correctly set up, the system will recognize them as a replacement for another package, that might even be in the main system repos.

Slackware does indeed work similarly with its SlackBuilds system, albeit with much more minimalism (no dependency resolution is probably the most significant difference). SlackBuilds are also standalone shell scripts, unlike (AFAICT) PKGBUILD scripts (which seem to rely on being invoked by a separate command).

Gentoo is a whole other ballgame, and its packaging system is much closer to a modern-day BSD-style ports tree.

As for the starting environment, Slackware actually takes the opposite approach from Arch: the installer defaults to installing all package sets available, which in the case of the install DVD includes KDE, Xfce, a bunch of other window managers, and a whole lot more. You're of course free to deselect the package sets you don't want (or even individually deselect packages), but Slackware's approach is definitely to start the user off with a fully functional system rather than expect the user to set things up from the bottom up.

Gentoo's somewhere in between those two extremes, at least as far as I remember from last time I installed Gentoo.

Can you honestly say you remember the exact pacman syntax of how to perform a system upgrade or how to install a package? :-) For me the UX was a problem, even if technically the package management is good.

I just remember the commands I use most, namely:

´sudo pacman -Syy´ to update the package db

´sudo pacman -Suy´ to update all packages

´sudo pacman -S package´ to install/update a specific pakage

´sudo pacman -U package.pkg.tar.xz´ to install a package from a local file (useful if you're using makepkg)

Those are usually enough to maintain my system. I'll have to hit the wiki for the various query options though. But if the CLI side of pacman bothers you, I'd suggest defining aliases in your shell's RC. I track my dotfiles using git and share them on all my machines, and this method works quite well for me...

And -Ss to search, -Rns for purge/uninstall.

i too would recommend defining aliases. if not for UX reasons, for brevity and consistency. i use the same (short) commands for pacman as for apt or yaourt.

Pacman UX may be difficult to getting started, however once learn a bit it is really easy. For example, you know the "-S something" install a package named "something" and "-Ss" search a package in repositories. So, how to search an installed package? Well, there is "-Q' parameter that installs a local package, so maybe:

$ pacman -Qs package

And yeah, this is exactly how it works. Once you learn a bit about how pacman works, it all connects, same thing as vim.

You do not have standard package manager aliases in your dot files? Why would I want to remember sudo pacman -Syu when I can just enter pkg-update?

Useful if you have to jump distro's when you surely have your commands aliased.

Another upvote for Arch. I've been Mac only for 5 years, but my linux of choice for all personal projects and my Linux machines (when I use them) has been arch for 7 or 8 years already. Rolling updates are something I really, really appreciate in Arch.

Having recently broken my Arch Linux unbootable (needed USB stick rescue to fix) by not upgrading quite everything (needed some libs for new packages), I think it's a bit fragile.

I would recommend having root FS on ZFS or other filesystem with snapshots. Take a snapshot before or after running a full system update with pacman.

Another aspect I dislike about Arch is that package binaries get removed very soon - it's not an option to not keep it constantly up to date.

That said, it's still my favorite distro.

I don't know if it's just me, but I had this situation with pretty much any distro I've ever encountered (it also happened on Arch, of course): I'd try to update/install/configure something and after the next reboot I'm on the TTY or I need to fetch a USB stick with a live system.

From that perspective, what works in Arch's favor is that fixing it is usually more straightforward than other distros. I remember spending a saturday afternoon trying to uninstall the proprietary ATI graphics driver from an Ubuntu machine - only to find out (after much googling) that you need to set a very obscure, barely documented environment variable before the attempt.

With Arch, the benefit of installing it manually is that fixing the system works pretty much the same - you just skip a couple of steps (partitioning etc).

Also, I found the Arch and Gentoo Wikis to be very useful for those attempts, regardless of the distro I actually tried to repair.

On a related note: On Arch, I stopped breaking things through updates after I subscribed to their main news feed (https://www.archlinux.org/feeds/news/) - pretty much every breaking change is announced and explained properly there.

My last time was an issue (or oversight) with pacman, which allowed me to update libicu-x.y without updating all its reverse dependencies. Some important part of the system depended on libicu-x.z (earlier version) which was no longer present so I had to get to the rescue console.

So this was an Arch-specific issue that could have been mitigated with ZFS snapshots. E.g. Gentoo does consistency checks of dynamic libs, and other systems don't allow you to make such upgrades.

I had something critical happen to me twice in one year and both times it would have been avoidable with an earlier snapshot of the rootfs. I will definitely do that next time I re-format a disk.

Reply on news.ycombinator.com