Live data from Hacker News

Arch Linux turns 20: Small, simple, great documentation

theregister.com

141–150 of 153 posts

Re: Arch Linux turns 20: Small, simple, great documentation

#141

While some may see it as a learning tool I have used Arch on my workstations for 14 years. The last time I remember having to manually fix things was when it migrated to systemd. I am a linux sysadmin so I might be biased but I think people overestimate the effort required to get exactly what you want and nothing more out of an Arch setup.

It depends on how uncommon what you want is, although I agree it is very low effort in general. For example, there was not too long ago an issue with the kernel not booting from syslinux for a few weeks. Also, arch-announce mentions a manual fix needed if you have a particular package installed every few months, so good to subscribe to that and fix as described if needed.

https://lists.archlinux.org/mailman3/lists/arch-announce.lis...

My suggestions: 1) Keep both linux and linux-lts installed since otherwise you have no backup if the one you normally use doesn't work. 2) Always fully update the system since dependencies aren't always fully specified and a partial update can damage the rest of the system. If you need to hold back a package, add it to the IgnorePkg= line in /etc/pacman.conf until it works again. 3) Avoid AUR except for rare cases where you review the package manually (always avoid AUR helpers). 4) Don't be too lazy even though things mostly just work, check your boot logs at least every year or so to improve the chance of fixing issues before they cause trouble and look for and deal with pacnew files at least a few times a year.

Re: Arch Linux turns 20: Small, simple, great documentation

#142

Earlier quoted context omitted.

How exactly does any other distro solve that? Please don't tell me you genuinely find PPAs to be a better alternative...

If the PPA is run by the project then you don't need to trust someone else. Sometimes AUR packages are created by a developer for the project but since you aren't trusting a particular URL that is run by the project it is possible that that will change later without you noticing if you are auto updating from AUR.

Whoever makes the PKGBUILD, it almost always points to and builds from the original project's git server in a client machine. You can verify that from the package's AUR web page.

And about project maintainers running PPAs - Say you're a dev, and you want to package binaries for your software. What's easier, whipping up a quick PKGBUILD once and putting it in your git server, thus allowing anyone to get the latest updated build at anytime, or setting up accounts and painstakingly compiling and updating each build to a PPA? Are you aware of the hundreds of abandoned PPAs that lie orphaned after maintainers gave up in frustration about how cumbersome they are?

Re: Arch Linux turns 20: Small, simple, great documentation

#143

Earlier quoted context omitted.

If the PPA is run by the project then you don't need to trust someone else. Sometimes AUR packages are created by a developer for the project but since you aren't trusting a particular URL that is run by the project it is possible that that will change later without you noticing if you are auto updating from AUR.

Whoever makes the PKGBUILD, it almost always points to and builds from the original project's git server in a client machine. You can verify that from the package's AUR web page. And about project maintainers running PPAs - Say you're a dev, and you want to package binaries for your software. What's easier, whipping up a quick PKGBUILD once and putting it in your git server, thus allowing anyone to get the latest upd…

I haven't looked that often since it is easiest to try to avoid software that isn't in the main package system, but I rarely see PKGBUILD checked into the upstream project. It is more common in my experience that an upstream developer manages the AUR package on the Arch website, not as part of the project. You can verify AUR packages before using them (this is what I do) but it is an extra step vs. a maintained PPA. AUR packages can be unmaintained as well. No matter the system the best situation for users is when the software you use is in the main package system.

Re: Arch Linux turns 20: Small, simple, great documentation

#144
post #19

> The installation process, and the documentation behind it, lead to the third virtue: a complete installation tends to be very small and simple, because you only install the bits you need. If you don't know what bits you need, the documentation will help you to work it out, and the result is something that is both fairly minimal and that, with luck, you understand. You know what's in there because you installed it.…

> Then I tried installing Arch in a VM… and it took me several days and several attempts, but when I finally got it working I felt, for the first time ever, like I actually understood the system I was using. Honest question: why days? I have installed arch multiple times in the past decade and I don’t remember anything exceptionally out of the ordinary. You just follow the step-by-step instruction and you are good to…

I often have to boot back into the live media because I forgot to install a tool like iwd while chrooted. This information is not included in the single page installation guide. Maybe it’s those scripts i’m unfamiliar with that would shorten the feedback loop.

Re: Arch Linux turns 20: Small, simple, great documentation

#145
post #82

Earlier quoted context omitted.

I have been using it for 10+ years and it hasn't corrupted things for me. It can't corrupt. It could get a bit tricky if you update very rarely, like once a year, but not sure what else there is to do to break things. Please elaborate a bit more.

Pacman will happily break pacman and sudo without warning if the user requests updating openssl without upgrading the entire system. When updating a package it does not pull in all of the other packages which will break if not updated simultaneously.

Indeed, pacman does not know which library versions are necessary for any particular app version. And almost all of the applications are dynamically linked.

Archlinux repo holds only a single latest version. There are some community maintained repos that contain older versions (and those can be easily fetched through downgrade utility).

When updating Archlinux, upgrade everything and then reboot. This way it should not break.

Re: Arch Linux turns 20: Small, simple, great documentation

#146
post #19

> The installation process, and the documentation behind it, lead to the third virtue: a complete installation tends to be very small and simple, because you only install the bits you need. If you don't know what bits you need, the documentation will help you to work it out, and the result is something that is both fairly minimal and that, with luck, you understand. You know what's in there because you installed it.…

> Then I tried installing Arch in a VM… and it took me several days and several attempts, but when I finally got it working I felt, for the first time ever, like I actually understood the system I was using. Honest question: why days? I have installed arch multiple times in the past decade and I don’t remember anything exceptionally out of the ordinary. You just follow the step-by-step instruction and you are good to…

Yeah, configuring a kernel is one part plus the install wasn’t always like it is now — in the old times there weren’t as many helper scripts (chrooting manually comes to mind)

Re: Arch Linux turns 20: Small, simple, great documentation

#147
post #38

Earlier quoted context omitted.

I'm afraid simple and easy don't go well together. You either have automation to make things easy to the user, but then it's no longer simple. Or you require the user to do everything manually, but then it's no longer easy.

True. Maybe there's a viable middle ground between Ubuntu & Arch. Perhaps with a focus on the audience (e.g. a web dev distro), it becomes viable to make sensible compromises on both (easiness & simplicity) that result in a good combination for the user.

Slackware.

Only reason I've seen to use anything else is if doing a full desktop installation doesn't make sense, as the installer is largely geared around just installing most everything, or perhaps leaving out a category or two. Beyond that, the documentation is clear, and it's made as easy to use as makes sense without just hiding things behind a black box so that when things go wrong, they REALLY go wrong.

Nice to see some of these newer distros like Arch and Ubuntu are coming along though; choice is good.

Re: Arch Linux turns 20: Small, simple, great documentation

#148

Earlier quoted context omitted.

Whoever makes the PKGBUILD, it almost always points to and builds from the original project's git server in a client machine. You can verify that from the package's AUR web page. And about project maintainers running PPAs - Say you're a dev, and you want to package binaries for your software. What's easier, whipping up a quick PKGBUILD once and putting it in your git server, thus allowing anyone to get the latest upd…

I haven't looked that often since it is easiest to try to avoid software that isn't in the main package system, but I rarely see PKGBUILD checked into the upstream project. It is more common in my experience that an upstream developer manages the AUR package on the Arch website, not as part of the project. You can verify AUR packages before using them (this is what I do) but it is an extra step vs. a maintained PPA.…

Well if you're avoiding software that isn't in the main package system then it doesn't make a difference either way - the official Arch repository has almost everything the official Debian/Ubuntu repositories do that isn't distro-specific.

Re: Arch Linux turns 20: Small, simple, great documentation

#149

How does a similar Nix OS setup compare as far as number of packages? Is Nix just as minimal as Arch?

In terms of addressing "you want to know what your system has got", OP argues Arch is good because Arch will only have what you install. With NixOS, the whole system configuration is declared starting from a single configuration file. So, NixOS is great for addressing "I forgot how I set up". You'll likely end up using more disk space with NixOS if you're changing your system, since NixOS has functionality which make…

I'm fairly new to NixOS, but suspect that a NixOS install might end up smaller over time. With the ability to try out one-off package installs that don't become part of the more permanent config, and the "garbage collection" mechanism that cleans up, I think I at least would have less long-term cruft.

Re: Arch Linux turns 20: Small, simple, great documentation

#150

I've been using Arch for well over 10 years, they say it's true that you "learn Linux" using Arch. It's an excellent distro, but a few things make it a great learning OS. First it's as vanilla as possible, which mean that packages are modified as little as possible from upstream. This means you don't learn anything distro-specific by mistake, and you actually learn more how the package is intended to function. The se…

I'm not so sure about learning. I think that you're mostly just learning how to administer an Arch Linux system.

After using and contributing to Gentoo for a few years, I don't think I could confidently explain how all of the pieces of the desktop graphics and audio stack fit together - I just installed it and it worked.

Post reply on HN