Starting a thread for general notes/news/tips about Arch Linux.
I’ve been using Arch Linux for years and highly recommend it. Some reasons:
rolling distro so always have the latest of everything
set things up and they just work forever
the pacman package manager is fast. Way faster than RPM based systems, and noticeable faster than DEB based systems.
very stable – upgrades have been very reliable – never any serious problems
the Arch User Repo (AUR) has about everything that is not packaged in the distro. I almost never have to install stuff from source these days.
build system is simple, sane, and easy to use. For example, I tweaked the KiCad build so that I could run the 5.1 released version and 5.99 pre-release version in parallel.
It is a little work more to install, but you can use Manjaro to make installation easier. However, installing vanilla Arch is a good way to learn a lot about Linux.
The yay AUR helper is very useful. It is statically linked in written in Go, so never break when there are libc updates, etc. A few other things I like about it:
it shows diffs so you can review the PKGBUILD file it is using to do a quick sanity check.
if you previously installed a package, it shows you a diff of the last PKGBUILD file you installed.
I really like installing packaged software (instead of make install from source) because the package manager then keeps track of what is installed, so it is easy to do clean uninstalls, etc.
This tools is another thing that makes Arch the “low friction” distro to use.
I’ll tell one other Arch story – my son is studying computer engineering and taking a digital logic class that uses Altera FPGAs. We tried installing the tools on Ubuntu, but we did not have a machine with the officially support version, so were fighting various issues. Since it was hard to get things working on Ubuntu, we figured it would be impossible on Arch – I was wrong. It turns out the Quartus support on Arch Linux is quite good:
With the Arch packages, everything came up working!
In the PKGBUILD, there is the following comment:
# NOTE: If you plan on using the usbblaster make sure you are member of the plugdev group.
This is the kind of polish that makes Arch a pleasure to use. One of the reasons I think there are so many high quality packages in Arch is the build/package system is relatively easy to use, so it is not a huge deal to create and maintain a PKGBUILD, so more people end up doing this as it saves them time and effort long term.
Also learned a tip from @khem – if you use yay to do your updates, it will first update all packages from main repos, and then update all AUR packages. This is a good way to keep your entire system up to date. Simply type yay.
I was reminded again yesterday how efficient pacman is compared to other package management solutions. My son was setting up his new Macbook Air. I recommended installing brew (maybe there is something better now??) to manage open source applications, and even with our new fiber connection, it still took a long time to initialize everything and run, and brew always feel sluggish when you run it. One of the most important considerations in command line user interfaces is that they be fast and responsive. This probably means they can’t be written in Python or Ruby (I’m looking at you … dnf and brew).
In the past, an Ubuntu PPA would be the first Linux binary release for most things. However, more and more developers are using Arch, and its packaging system/tooling is much simpler, so I think we’ll see this trend continue.
BTW, CUE looks pretty neat, but that is discussion for another topic.
“So, Arch Linux, one of the main reasons, there’s a couple, but the main reason is the rolling updates of Arch allows us to have more rapid development for SteamOS 3.0,” says Yang. “We were making a bunch of updates and changes to specifically make sure that things work well for Steam deck, and Arch just ended up being a better choice for them.”
I’ve not seen Arch being used in devices/embedded much yet – other than I have been running Arch on rPI and Odroid-C2 devices here – works great.
One thing to consider is Arch does not provide granular packing like OE (and to a lesser extent Debian), where -dev,-doc, etc. packages are separate. With Arch, everything is included in the base package. Perhaps with flash devices being so large, and the OS taking proportionally less and less percent of the flash space, the size of the OS no longer matters. In the past, distributing a 30MB update image was better than a 150MB image (less chance of file corruption, download problems in the field, etc). However, as network bandwidth continues to increase across the board, this will likely change as well.
In the past, I’ve avoided package based OS updates for Embedded Linux devices. In my experience, it is much more reliable to simply update the entire disk image using something like the Yoe updater. My experience updating my Arch workstations has been pretty good. However, once a year or so I run into a package conflict that requires a small amount of manual intervention. It seems this will always be a potential problem with a package based system like Arch. Still need to look at NixOS …
Recently re-installed Arch on a workstation where I installed a new SSD. For some reason, I really enjoy going through the Arch install process – I’d almost call it fun. I’ve also put together a little playbook for how I set up Arch. Although the process may not be quite as quick as the Ubuntu installer, I think it is getting close – especially when you consider the long term benefits of Arch – in the end I feel I save time over fighting Ubuntu, slogging through the periodic updates, etc.
Maybe it is the feeling of being a little more in control over what happens on a computer – knowing exactly what got installed, only enabling services I really need, etc. Perhaps this is an example of taking care of yourself. It always helps to understand how things work.
I’ve been using systemd-networkd to manage the network connection on my workstations for years, but lately I’ve been puzzled why mDNS was not working. systemd-resolved has mDNS support.
The solution is to enable MulticastDNS in the network configuration file:
[cbrake@ceres ~]$ more /etc/systemd/network/20-wired.network
[Match]
Name=enp39s0
[Network]
DHCP=ipv4
MulticastDNS=yes
Now, ssh somemachine.local just works.
Are there any advantages to using Avahi? – perhaps more services could be discovered …
Can systemd-networkd advertise services for mDNS-SD?
I was just about to reply to mDNS (Multicast DNS) - #4 by cbrake about how on my desktop I’ve stopped using systemd-resolved for mDNS and switched back to normal avahi, but I forget what issue I actually had which caused me to do this. It wasn’t advertising services but something about name resolution which wasn’t working right for me with systemd-resolved but had always (and now still does) work fine with avahi.
I’ve not done a lot of the mDNS yet, but I have two workstations running systemd-networkd with MulticastDNS=yes, one system running avahi, and a Mac – I can ssh between them all using <hostname>.local.
Are there other services you are interested in using DNS-SD for?
At my previous job when I was working on networked document scanners we used mDNS-SD to discover which scanners were on a network. So the user would be able to just get a UI which showed all the available scanners and pick the one they wanted to use for each scan job. It’s a similar thing to how Apple’s AirPrint works on iOS devices (and how CUPS does network printer discovery now, too). The client device just does an mDNS query for “who provides _tcp._printer service?” and then all the printers reply and the user can pick the one they want to use: https://developer.apple.com/bonjour/printing-specification/bonjourprinting-1.2.1.pdf
.