> I really like Arch, because contrary to the popular belief it is the most hassle free distro I've encountered.
I completely agree. I tried switching to Linux a few times in high school (early-mid '00s), and always had false starts with Fedora or Ubuntu. Usually the package manager would break and everything would fall to pieces. I ended up installing Arch as a Subversion server for some personal projects, and that's what finally made it click.
I use Arch exclusively at work and at home. I do Linux development, which means I have to test out our product on other distros, usually Ubuntu. Eight-plus years later, and Ubuntu's package manager still falls over nine times out of ten. Fedora falls over. Mint falls over. I don't know what I'm doing wrong.
Arch Just Works. It's dead simple, requires very little maintenance, and when something does go wrong (maybe once a year), it's easy to fix or roll back. Arch is just files on a hard drive, not some nebulous set of five different package sources and databases and "releases" and blech.
I've been using Arch on my workstation and on my laptop for several years already. I can sign all the points you gave in here and I really appreciate how easy it is to setup and use the distribution.
Although many years ago I had problems when updating, in the recent years everything just works and I don't need to worry about upgrading the whole distro every 6 months.
Yeah, there were more upgrade conflicts years ago before most system software switched to the "conf.d" directory-style configuration system. Now the Arch-provided config upgrades cleanly as the user configuration is separate. Upgrade conflicts have been very rare lately.
That is good to hear. I used Arch and loved it until that upgrade thing you mentioned a few years ago. It basically made a machine I had unusable so I stopped using Arch altogether. Maybe it is time to go back.
Honestly, I don't know. I'm not really familiar with non-Arch distros, and I only install a different distro maybe once a year, so I've never dug into the problem. The first thing I do when I install a non-rolling-release distro (usually one of Ubuntu, Mint, or Fedora) is update the software using the package manager. The upgrade process almost always fails in some way and leaves me with a broken system. On the odd installation where it does work, it will then inevitably fail on a future update after a few months of dormancy.
I figure it must be something I'm doing, but I don't know what it could be, as updating is literally the first thing I do.
I have a machine that runs debian stable thats been continually upgraded / updated with debian since 2007. Never had any issues. I think one thing to keep in mind with debian and ubuntu is to not use any ppa's / custom repos since most of the time people dont maintain them as dilligently as the main repos. Also dont try to jump back and forth between stable and experimental.
Girlfriends OpenSUSE for example ran fine for a few months and now its stuck in an infinite update/upgrade loop or whatever it is trying to do - I really dont have the time to look into it. But the problem is, zypper cant update but really wants to update. Most likely it is conflicts between different repositories, or unavailable shit from some repository. But how useful would OpenSUSE be without the ability to play mp3 files?
So all her programs are now outdated, getting older and older.
Ive seen the same on most .deb based distros Ive tried - failure to update/upgrade a package or collection of packages - breaks the entire system.
Oh you ran apt-get install something previously? Well now that failed, and I will not let you continue until you resolve the issue, the other package will be REMOVED, and the current package cannot be installed, but for an update is who the fuck cares stfu ragequit* * (installs archlinux).
Well put, that mirrors my experience. A year or two ago (recent history), I had an issue where I tried to install a 32-bit package on a 64-bit system accidentally. apt (or apt-get, or deb, or gdebi, or aptitude, or synaptic, or Software Update, or Software Center, or something else, I forget which one) detected conflicts and the default action had I pressed enter would have been to uninstall every 64-bit package on the system that conflicted with that 32-bit package or any of its many dependencies. That's not sane. Hopefully they've fixed this by now.
I've had apt-related troubles in the past, but they almost always were caused by the use of custom repositories/PPAs.
Further, it might seem arcane to have to type "apt-get install -f" to install dependencies for an autonomous .deb package, but I'm not sure how different that is from having to learn, for example, the myriad switches for pacman.
Pacman doesnt leave me with a broken package-manager when a package fails to install. For example
pacman -S thatprogram
and if it fails, then next time I do pacman -S otherpgoram or pacman -Syu
it goes fine, there is nothing from thatprogram which complains or bugs me. Unlike Ubuntu/Debian where
apt-get install fail
and thus everything I try to do now will fail unless I resolve the fail.
pacman also has far less switches,
at least I know only of -Q -Qs -S -Ss -Sy -U and -Ql | grep for something Im looking for. Thats all I need to know really. Like 4 or 5 switches/commands.
But look at apt,
apt-get {things here but not search!} {ugh so many switchs here}
apt-{what its not really called search!?}
dpkg-{jesus-christ-so-many-options}
> and thus everything I try to do now will fail unless I resolve the fail.
This is exactly why I detest apt.
Our products at my last company ran Ubuntu and Mint. I detested dealing with the package manager.
I wrote so much stuff to get around apt when dealing with software packages. I wrote a Maven-based update system (with user-friendly wrappers) for pulling down updates on customer units, and my boss wrote an SVN-based solution for internal dev work. I wrote our own validation system to determine if a package can be safely installed, and if it passed, it'd get shoved in with dpkg -i --force-all, because I didn't trust dpkg to do it itself. I wrote a meta-package system (basically a tarball of debs + a manifest file) so I could guarantee atomic installation (read the manifest, verify every deb in the metapackage, and abort before installing anything if even a single package fails verification).
> pacman also has far less switches, at least I know only of -Q -Qs -S -Ss -Sy -U and -Ql | grep for something Im looking for. Thats all I need to know really. Like 4 or 5 switches/commands.
> Ive seen the same on most .deb based distros Ive tried - failure to update/upgrade a package or collection of packages - breaks the entire system.
Which means you didn't try Debian stable. deb based or not doesn't matter, all that matters is distribution policies on packaging, migrations and releases.
> Havent tried Debian stable, but then again, I dont live in 1999 either.
> What is the nginx version for Debian stable, is it even in the repositories yet?
It's none of my business to stop you from hating Debian. Just don't blame ".deb based distros" as if them being deb based was the reason of your suffering.
> ... and always had false starts with Fedora or Ubuntu. Usually the package manager would break and everything would fall to pieces. I ended up installing Arch as a Subversion server for some personal projects, and that's what finally made it click.
Glad you've had a good experience with Arch. I've been using Debian and derivatives for years. I've occasionally seen hiccups with apt but I can almost always trace them to network trouble rather than the distro itself. In the other cases, reading the manpages or googling a bit helped unbork the system. It sounds like you didn't exercise your sysadmin/debugging skills.
Yes, part of it is ignorance on my part. I'm not familiar with DEB or RPM package management conventions. For example, on RPM systems, it turns out you can install two RPMs of the same name, but different versions! And this is the default instead of upgrading! Boy, that took ages to debug.
But really, installing a system and using the system-provided package manager to perform a system update should "Just Work." And my experience is that this almost always ends in failure, and usually in a broken system. I dunno.
I completely agree. I tried switching to Linux a few times in high school (early-mid '00s), and always had false starts with Fedora or Ubuntu. Usually the package manager would break and everything would fall to pieces. I ended up installing Arch as a Subversion server for some personal projects, and that's what finally made it click.
I use Arch exclusively at work and at home. I do Linux development, which means I have to test out our product on other distros, usually Ubuntu. Eight-plus years later, and Ubuntu's package manager still falls over nine times out of ten. Fedora falls over. Mint falls over. I don't know what I'm doing wrong.
Arch Just Works. It's dead simple, requires very little maintenance, and when something does go wrong (maybe once a year), it's easy to fix or roll back. Arch is just files on a hard drive, not some nebulous set of five different package sources and databases and "releases" and blech.