7 ms·

As a former Debian enthusiast (I even helped staff a Debian booth at a conference once!) who also tends to be conservative with new technology and who is conseq

by evmar 5y ago

As a former Debian enthusiast (I even helped staff a Debian booth at a conference once!) who also tends to be conservative with new technology and who is consequently also skeptical of all these random Linux distros, I eventually tried out Arch and found it ... super awesome, I really love it! I highly recommend it to anyone else like me, who is generally cranky about new things. They did a really great job with Arch. This policy you mention is a great example of what I like about it.

rjzzleep 5y ago
I've been using arch for a few years as daily driver, and I mostly like it, but I would be lying if I said it doesn't break at random intervals during system updates. Nothing unrecoverable, but it's definitely a thing that comes with frequent upgrades.
- nemetroid 5y ago
  What part of it breaks for you? It's not that I don't believe you, and I've seen this sentiment before, but I've used Arch as my daily driver for about five years, and can't recall a single time where it broke from a system update.
  - Lex-2008 5y ago
    not OP, and not Arch, but Manjaro (so you can take it with a grain of salt), reporting from memory so details might be incorrect. * after "BootHole" GRUB vulnerability, I've read that upgrade requires re-installation of the bootloader. And just in case, did run `sudo grub-install …`. After reboot, system didn't boot. Had to use installation USB to restore. * More recently, during routine upgrade pamac (Manjaro's pacman alternative) GUI showed me some "transaction can't be completed" error message. Shuddered it away - few days later pamac wasn't starting at all. Starting it from terminal showed error message about some missing *.so file. Googling showed that this is a required file for pacman (Arch package manager) to function. Typing `pacman` in terminal showed "command not found" error message. Restored the missing *.so file from snapper snapshot (thanks btrfs!), after that pamac started fine and happily upgraded my system. I'm not sure what happened in second case and why pamac left system in broken state (looks like it wanted to upgrade pacman by first removing old files and then putting new files in place, but aborted in the middle), but first one might be quite distro-independent. Also, reading through recent Arch news, I believe this could bite someone: https://archlinux.org/news/sshd-needs-restarting-after-upgrading-to-openssh-82p1/ https://archlinux.org/news/sshd-needs-restarting-after-upgra... > After upgrading to openssh-8.2p1, the existing SSH daemon will be unable to accept new connections. When upgrading remote hosts, please make sure to restart the SSH daemon right after running pacman -Syu. If you are upgrading to openssh-8.2p1-3 or higher, this restart will happen automatically.
    - majewsky 5y ago
      > I'm not sure what happened in second case and why pamac left system in broken state FWIW, as a vanilla Arch user, I have not encountered this issue. I remember a time when pacman updates were kind of iffy (and in fact, pacman itself asked you to update it first before proceeding with the rest of the updates), but since 5.0, all subsequent updates have been completely unremarkable in the best way.
  - paulfurtado 5y ago
    I use arch on all my machines and there are really a lot of ways it has broken. - Arch will release a new version of Xorg before the graphics card vendors release new drivers that are compatible with it. Same for kernel versions too. - I've had gedit start crashing in new minor versions of gnome due to a setting being incompatible, needing to track that down and unset - If you have python virtualenvs for development and system python is upgraded to a new major version, all your virtualenvs break - If arch upgrades the major version of glibc during some random package install (rather than a system upgrade), and you don't upgrade the whole system at once, every app that didn't get upgraded will fail to start due to soname mismatches... and that can mean that pacman, sudo, etc are all busted (this has actually happened to me) - If you do a full system upgrade and have AUR stuff installed, you need to be sure to upgrade the AUR stuff otherwise it could break due to being incompatible with any library that was upgraded. - In general (not specific to arch linux), new versions of software break stuff all the time. You tend to hit way more of this on arch if you keep your system up to date.
    - formerly_proven 5y ago
      > - If arch upgrades the major version of glibc during some random package install (rather than a system upgrade), and you don't upgrade the whole system at once, every app that didn't get upgraded will fail to start due to soname mismatches... and that can mean that pacman, sudo, etc are all busted (this has actually happened to me) Okay I just wanna point something out here, partial upgrades in Arch are broken by design because they simply can't work. Don't do it. That being said... > - Arch will release a new version of Xorg before the graphics card vendors release new drivers that are compatible with it. Same for kernel versions too. ... kernel ABI is stable and even ancillary interfaces are usually stable, so usually it's quite A-OK to not immediately upgrade the kernel.
      - Liskni_si 5y ago
        Can you elaborate why has Arch chosen to not support partial upgrades by design? They do work in Debian and it's saved my day a number of times. They let me roll back a broken upgrade without holding back upgrades of the rest of the system, and my computer then continues to be usable until the package in question is fixed.
  - maddyboo 5y ago
    I was an XMonad user during the time that Arch switched from statically linked Haskell packages to dynamically linked and oh my god was that a nightmare. Other than that I’ve had far, far fewer issues with Arch than any other distro I’ve used.
- ohazi 5y ago
  I use Debian testing as my daily driver at home and at work, and have found it to be plenty stable over the decade or so that I've been using it. I've also been using Arch on a "for messing around; I don't care if it breaks" laptop for about two years, and haven't had any major breakages. For me, the most noticable difference has been that Debian will install new kernels as new packages, will suggest removing old kernel packages, but won't suggest removing the currently booted kernel. I like this behavior. By default, Arch will swap your currently booted kernel and modules out from under you. You don't necessarily need to reboot right away, but if you don't, you can run into issues loading modules or recovering from hibernation. You can work around this once you realize what's happening, but it seems like a needlessly dangerous default.
  - nemetroid 5y ago
    See https://bugs.archlinux.org/task/16702 https://bugs.archlinux.org/task/16702 for a discussion about versioned kernel installs in Arch.
  - DyslexicAtheist 5y ago
    I'm using Sid as a daily driver on all my dev machines[1]. I run apt dist-upgrade twice a week too and I back up to external drive once a week. I've never once been in a situation (since ca. mid 2000) where I needed to restore from backup or boot into single user mode. My favorite documentation is the arch wiki and there has never been an issue due to it not being compatible to the "Debian way" When upstream devs package for a distribution they usually put some effort into it. Just because a package gets published to Sid/unstable doesn't mean the package is unstable. There are some devs that mostly work on higher layer GUI and user-lamd applications who are perhaps inexperienced or reckless who do sometimes introduce breaking changes. It's rare though since most people understand that packaging for a distro means a potential huge number of issues if they're not careful My 70+ year old aunt also runs sid since a couple of years with unattended upgrades since I installed it for her (and she has KDE). She never had issues with stability or things not working and she uses her computer daily for writing (libreoffice), printing and research (probably reddit idk, I didn't ask :)). [1] my install is fairly minimal: not much gui, server systems etc are started with docker so hardly anything actually runs on bare-metal which can cause issues during upgrade jeopardizing the things I work on (e.g. due to config file changes). And I don't have a huge DE like gnome/KDE. My sway/wlroots and i3, and tooling like x-terminal/wofi/Waybar/etc are always compiled from git/source. All my dev tooling is the latest and I can still install older versions of clang/gcc or other environments with my package manager if I have to.
- bachmeier 5y ago
  I used Arch many years ago as my main OS. I eventually had to give up on it because (i) several packages I needed were badly out of date, combined with (ii) a rule against AUR having packages that were only updates of something in the repos. I was left handling the compilation process all by myself. When several of us raised the issue in the forum...I'll just say we didn't get a warm reception. That was more than a decade ago, so things may be completely different now, but it left a bad taste in my mouth.
- matheusmoreira 5y ago
  Could you post more details about what broke, why and how you fixed it? I'm curious. I've been using Arch for years and I never experienced any breakage. I update it every month or so and it's still stable even after these huge updates. There's nothing for me to do other than merge .pacnew files.
- SJetKaran 5y ago
  You can try one of the Arch derivatives like Manjaro. That might help with this issue a bit.
  - chaorace 5y ago
    Seconded. Manjaro's stable channel is the best of both worlds -- a meticulously manicured package ecosystem with just enough time lag behind the bleeding edge that it's very rare for a bad patch to sneak in. I think it's happened to me once in just over four years now?
The_rationalist 5y ago
Archlinux is far from being up to date though e.g openjdk is stuck with release from last year (15 instead of 16) It's a quite miserable experience in 2021 to not have a single distro that is universally up to date with software development. Windows has this since day 1 if we talk about auto updating software and the windows store apps, being owned by the app makers instead of by a poor middleman (the distro village) are by design up to date.
- ticviking 5y ago
  So pay for open source. Or volunteer. As engineers we have no one but ourselves to blame for this one
- jpetso 5y ago
  With packaging technologies such as Flatpak and Snap, app makers now have the option to distribute a bundled-everything version of their software to Linux users. This has drawbacks too though, in that it's now up to app makers to take care of keeping supporting libraries up to date and secure. That's not necessarily their top priority though, which is a risk for the end user. Also, unnecessary duplication of libraries increasing memory use, when the distro is able to share most of them. Plus the poor middleman has an incentive to set user-friendly, privacy-preserving defaults that I wouldn't trust as much when the package is provided by a commercial company with different incentives. It's great to have the option, but overall I would still prefer to use distro packages except in the rare special case.
- vngzs 5y ago
  Yeah, sorry, the openjdk situation sucks. It's an "extra" package, which means the maintainer is a community member rather than being part of the Arch core group. The nice thing about Arch packages, though, is that they're basically just bash scripts. And if all you need is a simple version bump, it's usually quite easy: download the package tarball from [0] and change [1] to the version you want, then do a `makepkg -s` in the directory of the package. It will build the package in a (usually reproducible) chroot. If it builds without errors, then you'll end up with a tarball that you can `pacman -U ${pkg}.tar.zst` to install the produced files. If you need help, makepkg documentation on the wiki[2] is pretty great. And don't forget to send a patch to arch-dev-public[3] and CC the maintainer. At the very least, it'll kick off a discussion that will get the package updated. Rolling your own packages is easy in contrast to, say, Red Hat - where compiling an RPM is easy if you've done it a bunch, but really difficult to get bootstrapped on. [0]: https://archlinux.org/packages/extra/x86_64/jdk-openjdk/ https://archlinux.org/packages/extra/x86_64/jdk-openjdk/ [1]: https://github.com/archlinux/svntogit-packages/blob/packages/java-openjdk/trunk/PKGBUILD#L8 https://github.com/archlinux/svntogit-packages/blob/packages... [2]: https://wiki.archlinux.org/title/Makepkg https://wiki.archlinux.org/title/Makepkg [3]: https://lists.archlinux.org/listinfo/arch-dev-public https://lists.archlinux.org/listinfo/arch-dev-public
joana035 5y ago
I used Arch a lot back in the days there was no dkms (got a new kernel? Recompile your gpu module otherwise no desktop on the next reboot, specially with nvidia) and Arch is a very good place to learn Linux, but I eventually went to Debian because everything just works. For the topic I think is good to have dfsg and to patch any software with the goal to provide better integration with the system and for user's freedom.

by evmar 5y ago

rjzzleep 5y ago

I've been using arch for a few years as daily driver, and I mostly like it, but I would be lying if I said it doesn't break at random intervals during system updates. Nothing unrecoverable, but it's definitely a thing that comes with frequent upgrades.

nemetroid 5y ago
What part of it breaks for you? It's not that I don't believe you, and I've seen this sentiment before, but I've used Arch as my daily driver for about five years, and can't recall a single time where it broke from a system update.
- Lex-2008 5y ago
  not OP, and not Arch, but Manjaro (so you can take it with a grain of salt), reporting from memory so details might be incorrect. * after "BootHole" GRUB vulnerability, I've read that upgrade requires re-installation of the bootloader. And just in case, did run `sudo grub-install …`. After reboot, system didn't boot. Had to use installation USB to restore. * More recently, during routine upgrade pamac (Manjaro's pacman alternative) GUI showed me some "transaction can't be completed" error message. Shuddered it away - few days later pamac wasn't starting at all. Starting it from terminal showed error message about some missing *.so file. Googling showed that this is a required file for pacman (Arch package manager) to function. Typing `pacman` in terminal showed "command not found" error message. Restored the missing *.so file from snapper snapshot (thanks btrfs!), after that pamac started fine and happily upgraded my system. I'm not sure what happened in second case and why pamac left system in broken state (looks like it wanted to upgrade pacman by first removing old files and then putting new files in place, but aborted in the middle), but first one might be quite distro-independent. Also, reading through recent Arch news, I believe this could bite someone: https://archlinux.org/news/sshd-needs-restarting-after-upgrading-to-openssh-82p1/ https://archlinux.org/news/sshd-needs-restarting-after-upgra... > After upgrading to openssh-8.2p1, the existing SSH daemon will be unable to accept new connections. When upgrading remote hosts, please make sure to restart the SSH daemon right after running pacman -Syu. If you are upgrading to openssh-8.2p1-3 or higher, this restart will happen automatically.
  - majewsky 5y ago
    > I'm not sure what happened in second case and why pamac left system in broken state FWIW, as a vanilla Arch user, I have not encountered this issue. I remember a time when pacman updates were kind of iffy (and in fact, pacman itself asked you to update it first before proceeding with the rest of the updates), but since 5.0, all subsequent updates have been completely unremarkable in the best way.
- paulfurtado 5y ago
  I use arch on all my machines and there are really a lot of ways it has broken. - Arch will release a new version of Xorg before the graphics card vendors release new drivers that are compatible with it. Same for kernel versions too. - I've had gedit start crashing in new minor versions of gnome due to a setting being incompatible, needing to track that down and unset - If you have python virtualenvs for development and system python is upgraded to a new major version, all your virtualenvs break - If arch upgrades the major version of glibc during some random package install (rather than a system upgrade), and you don't upgrade the whole system at once, every app that didn't get upgraded will fail to start due to soname mismatches... and that can mean that pacman, sudo, etc are all busted (this has actually happened to me) - If you do a full system upgrade and have AUR stuff installed, you need to be sure to upgrade the AUR stuff otherwise it could break due to being incompatible with any library that was upgraded. - In general (not specific to arch linux), new versions of software break stuff all the time. You tend to hit way more of this on arch if you keep your system up to date.
  - formerly_proven 5y ago
    > - If arch upgrades the major version of glibc during some random package install (rather than a system upgrade), and you don't upgrade the whole system at once, every app that didn't get upgraded will fail to start due to soname mismatches... and that can mean that pacman, sudo, etc are all busted (this has actually happened to me) Okay I just wanna point something out here, partial upgrades in Arch are broken by design because they simply can't work. Don't do it. That being said... > - Arch will release a new version of Xorg before the graphics card vendors release new drivers that are compatible with it. Same for kernel versions too. ... kernel ABI is stable and even ancillary interfaces are usually stable, so usually it's quite A-OK to not immediately upgrade the kernel.
    - Liskni_si 5y ago
      Can you elaborate why has Arch chosen to not support partial upgrades by design? They do work in Debian and it's saved my day a number of times. They let me roll back a broken upgrade without holding back upgrades of the rest of the system, and my computer then continues to be usable until the package in question is fixed.
- maddyboo 5y ago
  I was an XMonad user during the time that Arch switched from statically linked Haskell packages to dynamically linked and oh my god was that a nightmare. Other than that I’ve had far, far fewer issues with Arch than any other distro I’ve used.
ohazi 5y ago
I use Debian testing as my daily driver at home and at work, and have found it to be plenty stable over the decade or so that I've been using it. I've also been using Arch on a "for messing around; I don't care if it breaks" laptop for about two years, and haven't had any major breakages. For me, the most noticable difference has been that Debian will install new kernels as new packages, will suggest removing old kernel packages, but won't suggest removing the currently booted kernel. I like this behavior. By default, Arch will swap your currently booted kernel and modules out from under you. You don't necessarily need to reboot right away, but if you don't, you can run into issues loading modules or recovering from hibernation. You can work around this once you realize what's happening, but it seems like a needlessly dangerous default.
- nemetroid 5y ago
  See https://bugs.archlinux.org/task/16702 https://bugs.archlinux.org/task/16702 for a discussion about versioned kernel installs in Arch.
- DyslexicAtheist 5y ago
  I'm using Sid as a daily driver on all my dev machines[1]. I run apt dist-upgrade twice a week too and I back up to external drive once a week. I've never once been in a situation (since ca. mid 2000) where I needed to restore from backup or boot into single user mode. My favorite documentation is the arch wiki and there has never been an issue due to it not being compatible to the "Debian way" When upstream devs package for a distribution they usually put some effort into it. Just because a package gets published to Sid/unstable doesn't mean the package is unstable. There are some devs that mostly work on higher layer GUI and user-lamd applications who are perhaps inexperienced or reckless who do sometimes introduce breaking changes. It's rare though since most people understand that packaging for a distro means a potential huge number of issues if they're not careful My 70+ year old aunt also runs sid since a couple of years with unattended upgrades since I installed it for her (and she has KDE). She never had issues with stability or things not working and she uses her computer daily for writing (libreoffice), printing and research (probably reddit idk, I didn't ask :)). [1] my install is fairly minimal: not much gui, server systems etc are started with docker so hardly anything actually runs on bare-metal which can cause issues during upgrade jeopardizing the things I work on (e.g. due to config file changes). And I don't have a huge DE like gnome/KDE. My sway/wlroots and i3, and tooling like x-terminal/wofi/Waybar/etc are always compiled from git/source. All my dev tooling is the latest and I can still install older versions of clang/gcc or other environments with my package manager if I have to.
bachmeier 5y ago
I used Arch many years ago as my main OS. I eventually had to give up on it because (i) several packages I needed were badly out of date, combined with (ii) a rule against AUR having packages that were only updates of something in the repos. I was left handling the compilation process all by myself. When several of us raised the issue in the forum...I'll just say we didn't get a warm reception. That was more than a decade ago, so things may be completely different now, but it left a bad taste in my mouth.
matheusmoreira 5y ago
Could you post more details about what broke, why and how you fixed it? I'm curious. I've been using Arch for years and I never experienced any breakage. I update it every month or so and it's still stable even after these huge updates. There's nothing for me to do other than merge .pacnew files.
SJetKaran 5y ago
You can try one of the Arch derivatives like Manjaro. That might help with this issue a bit.
- chaorace 5y ago
  Seconded. Manjaro's stable channel is the best of both worlds -- a meticulously manicured package ecosystem with just enough time lag behind the bleeding edge that it's very rare for a bad patch to sneak in. I think it's happened to me once in just over four years now?

The_rationalist 5y ago

Archlinux is far from being up to date though e.g openjdk is stuck with release from last year (15 instead of 16) It's a quite miserable experience in 2021 to not have a single distro that is universally up to date with software development. Windows has this since day 1 if we talk about auto updating software and the windows store apps, being owned by the app makers instead of by a poor middleman (the distro village) are by design up to date.

ticviking 5y ago
So pay for open source. Or volunteer. As engineers we have no one but ourselves to blame for this one
jpetso 5y ago
With packaging technologies such as Flatpak and Snap, app makers now have the option to distribute a bundled-everything version of their software to Linux users. This has drawbacks too though, in that it's now up to app makers to take care of keeping supporting libraries up to date and secure. That's not necessarily their top priority though, which is a risk for the end user. Also, unnecessary duplication of libraries increasing memory use, when the distro is able to share most of them. Plus the poor middleman has an incentive to set user-friendly, privacy-preserving defaults that I wouldn't trust as much when the package is provided by a commercial company with different incentives. It's great to have the option, but overall I would still prefer to use distro packages except in the rare special case.
vngzs 5y ago
Yeah, sorry, the openjdk situation sucks. It's an "extra" package, which means the maintainer is a community member rather than being part of the Arch core group. The nice thing about Arch packages, though, is that they're basically just bash scripts. And if all you need is a simple version bump, it's usually quite easy: download the package tarball from [0] and change [1] to the version you want, then do a `makepkg -s` in the directory of the package. It will build the package in a (usually reproducible) chroot. If it builds without errors, then you'll end up with a tarball that you can `pacman -U ${pkg}.tar.zst` to install the produced files. If you need help, makepkg documentation on the wiki[2] is pretty great. And don't forget to send a patch to arch-dev-public[3] and CC the maintainer. At the very least, it'll kick off a discussion that will get the package updated. Rolling your own packages is easy in contrast to, say, Red Hat - where compiling an RPM is easy if you've done it a bunch, but really difficult to get bootstrapped on. [0]: https://archlinux.org/packages/extra/x86_64/jdk-openjdk/ https://archlinux.org/packages/extra/x86_64/jdk-openjdk/ [1]: https://github.com/archlinux/svntogit-packages/blob/packages/java-openjdk/trunk/PKGBUILD#L8 https://github.com/archlinux/svntogit-packages/blob/packages... [2]: https://wiki.archlinux.org/title/Makepkg https://wiki.archlinux.org/title/Makepkg [3]: https://lists.archlinux.org/listinfo/arch-dev-public https://lists.archlinux.org/listinfo/arch-dev-public

joana035 5y ago

I used Arch a lot back in the days there was no dkms (got a new kernel? Recompile your gpu module otherwise no desktop on the next reboot, specially with nvidia) and Arch is a very good place to learn Linux, but I eventually went to Debian because everything just works. For the topic I think is good to have dfsg and to patch any software with the goal to provide better integration with the system and for user's freedom.