Hacker News Reader

Comment by bscphil | Hacker News Reader

> I think the benefits of saving disk space by sharing libraries do not justify the inconveniences we, desktop BSD and Linux users, obtain from being forced to disrupt and upgrade hundreds of installed software packages, just because one single desired upgrade requires to pull its dependencies

It's funny, from your point of view having a centralized repository with a (usually) single (usually) latest version of a library is a bad thing that may be (and probably isn't) justified by the goal of saving space.

From my point of view having a centralized repository with a (usually) single (usually) latest version of a library is an awesome thing that I would leave any other ecosystem to get, and the space savings is just a bonus that doesn't much matter.

Most dependency maintainers don't provide updates for more than a few versions of their software. When one piece of software depends on -latest and another piece of software depends on -legacy, you can ship both with the central repository model. In the Linux distributions I've used this is a solved problem. Arch Linux has five different versions of the JRE that are separately installable.

View on HN

> From my point of view having a centralized repository with a (usually) single (usually) latest version of a library is an awesome thing

This reasoning assumes that future versions of software are always better. This is certainly not the case. I would like that a working program does not spontaneusly break because a third party "upgrades", thus introducing a new bug. I am willing to give up anything else to be assured that working programs continue to work no matter what.

I suppose I should clarify by "latest" that I mean a version of a piece of software that is actively supported and has all the security patches. Like it or not, the ecosystem is currently built around the assumption that you do want to have this, that nobody should still be running e.g. Firefox 34. The question is what the best way of shipping it is.

The conversation in the two posts you replied to isn't about whether you always want to be on the bleeding edge all the time, it's about whether it makes sense to have a centralized repository that contains the latest version on some supported channel, which isn't necessarily the same thing as the latest -nightly. I take the position that it is; that shipping a (potentially) different version of a library with every application is a bad approach which is often less secure and harder to maintain.

But didn't the OP show exactly a situation where this system broke down?

There is a new version of the Rust library. In theory, either anything that supports it should be updated selectively (i.e. Firefox) or all consumers should be updated in lockstep. Yet in practice the maintener decided that neither option was feasible so nothing was updated at all. What went wrong here?

What they should do is have a centralized repository of packages but allow multiple versions that function independently. That way nothing breaks when one program installs a newer version.

That would require exponential amounts of binaries.

I left arch linux because I got tired of all the breakages, so not a great example.

Sometimes it feels like I am living in an alternate reality. After I started using Arch Linux as my main OS I was fully prepared for it to break every few months. But it's been more then 2 years (maybe even 3 or 4 ?) and not one breakage. Also keep in mind that I update it every single day. From time to time I check the Arch Linux news site to see if anything needs manual intervention. So far I haven't needed to do anything.

> Also keep in mind that I update it every single day.

I can't remember what I was looking at, but within the past week I ran across a comment that said Arch Linux only supports constant upgrades such as that, and any delays that result in skipping a version are what risk causing breakages. The commenter was very surprised that they were even thinking about supporting a version jump on whatever the thread was about (pretty sure it was somewhere here on HN).

I also have another VM that I use from time to time. I think my longest update was about after a year. I don't remember having any problems like that.

can confirm, went to arch linux due to constant breakage under Debian & Ubuntu, it's be so much more pleasant since then. No more everything exploding left and right as soon as I need a newer GCC or libav version.

Changing the system default GCC version, like it seems you did, is not good practice in environments with conservative package policies.

There's also no need to do that, since nobody prevents users from installing newer versions alongside old ones, and invoking them directly.

Even not considering the fact that different GCC versions can coexist, complaining about this breakage in absolute terms doesn't make any sense. Releases changing default compiler versions inevitably cause more breakages with packages who haven't been updated to be compatible with newer GCC versions. So ultimately it's a matter of choosing the distributions with the appropriate release model, not a matter of Ubuntu/Debian breaking stuff.

Libav has also been deprecated in Ubuntu long ago, so it's not clear what you refer to. If you happen to refer to the transition from and back to ffmpeg, that's very old history.

> Libav has also been deprecated in Ubuntu long ago, so it's not clear what you refer to

I'm referring to the libav* libraries which are part of the ffmpeg project (not the horribly-named libav fork) - and external debian repos providing updated version of those (due to better codec support in media players, etc) such as debian-multimedia

That's funny because I've been running Debian Sid for 15 years as my main OS doing weekly updates and the two single cases of breakage I've seen were glibc6 transition (which was announced and expected) and proprietary video card drivers. You must be thinking of Ubuntu specifically.

To keep the anecdotes going, I've been using a mix of Debian and Ubuntu, both stable/LTS and testing/biannual, for pretty much exactly the same 15 years as you've been running Sid and I've never had any breakage that wasn't caused by me fucking around with binary drivers.

ndiswrapper was the main cause back in the day, shockingly giving Windows drivers access to the Linux kernel can cause problems. The most recent time was when VDPAU was new and I was trying to get HD video playback working on a mini-PC with an nVidia Ion GPU by running a version of the nVidia driver much newer than Ubuntu packaged. Now that I think about it that must have been around a full decade ago.

I'm not old enough to be able to run a Linux distribution for 15 years. And I also never run Debian on any of my personal computers. Thus, my anecdotes are definitely way less convincing. In other words, you can stop reading here.

The only two major distributions that I used for a sufficient amount of time are Ubuntu and Arch. Arch "unstableness" is exactly what I want most of the time on my personal computer as it's my to-go Petri dish. "Stability" would mean that it's harder for me to break it apart, and make a Frankenstein out of it. That's exactly what I have been experiencing with Ubuntu LTS releases --- stability.

Most of the time, I want to have all the available LLVM versions alongside with all the GCC versions, with all the available binutils (Qemu, Docker, Oracle VBox, etc.) versions on the latest kernel full of my monkey patched printk's. When I finally get to break its back I dive the Wiki for few hours to restore it.

I can imagine a non-office, hacking desktop OS that follows the Arch packaging strategy being highly successful.

I also maintain a few compute servers for 10-20 people. They are on Ubuntu LTS. The packages that I need there are always the ones that just work and don't let anyone do anything "cutting edge".

This is the proper response, imo.

Arch is rolling release and you take the good with the bad. The ones who try to defend arch as some paragon of stability miss the point that Arch's model is inherently unstable, but it comes with other benefits.

I'm the one who kicked off this entire conversation pointing out that arch is unstable, and it cracks me up watching silly people scramble to try and defend Arch as being some paragon of stability.

No, it's not. That's baked into its identity.

Aside from patching the kernel I have done everything GP said. Just because the Arch wiki says it is unstable doesn't mean it always is. It just means Arch Linux can do breaking changes (systemd) without worrying about backwards compatibility. And FYI I wasn't defending Arch Linux. It just seems strange to me that everyone is having instability problems and I can't even reproduce it.

I also agree that you shouldn't run your production database on Arch Linux. It isn't made for workloads like that. But personally I find maintaining Arch Linux+"custom packages"(with AUR) easier then Debian+"latest packages"+"custom packages".

That is only if you use the debian-specific definition of "stable" which is "does not change". The rest of the world thinks of "less bugs" when they think of stable software.

yes, because randomly declaring the other person as using a different definition somehow adds to the conversation and changes their point.

Back here in reality, rolling release is less stable because more bugs in the software get through. And this is a reasonable expectation and not some magical fairyland where bugs never get written so being right up against the dev branch is as stable as being on the stable branch.

> Back here in reality, rolling release is less stable because more bugs in the software get through.

We really live in two different software worlds. Every software I'm using has its number of bugs a purely decreasing function of time, especially in the "main" paths and use cases.

Your statement is a logical paradox.

If it were true, it means there wouldn't be bugs in the first place because they wouldn't have gotten written. The very fact that the bugs got written implies new bugs can, and will, be introduced.

I'm running Debian testing since 4.0 beta and never had an un-bootable system or something got broken due to normal updates. I've just reinstalled the system once to migrate it to 64 bit, since there was no proven procedure to migrate a running 32 bit system to 64 bit.

There were rough patches along the way but, all distros were having the same problem in someway or another (vdpau, fglrx, multi-gpu support, ndiswrapper & wireless stuff, etc.) but it's a set it and forget it affair for a very very long time.

...and obligatory xkcd: https://xkcd.com/963/

No, I only ran Ubuntu a few times. My worst breakages were on debian (generally testing). I remember the mysql packages completely killing my apt as well as grub updates wreaking havoc as two individual examples.

This has to be one of the most inaccurate memes of all time.

To counter with anecdata: I've been running Arch Linux testing repositories for over a year now with no issues whatsoever.

I like Arch. I run it at home.

That said, just because you had good luck doesn't mean that it's stable.

Here's the most trivial way I can think to explain this:

Check out Arch News.[0] Ctrl-F (Find) 'manual intervention'. Six years of results on the first page ; 13 instances of 'manual intervention required'.

Reliability != stability. Stability usually implies a platform on which one can use and develop for without expecting common major changes, if ever.

As for the anecdote of using the [Testing] repositories, a users experience with such things really depends on their use of new and currently developing software.

A simple computer with simple peripherals that is used to run emacs all day isn't likely to be broken by the Testing repositories.

Personally , my anecdote : the second someone starts using Arch for something new-fringe (hi-dpi, touch, tablets, SPDIF, SLI, NVRAM, new window managers, new x-windows replacements, prototype schedulers, filesystems, or kernels, PCI pass-through, exotic RAID configurations..) [Testing] repository is an act of masochism. It's only a matter of time before something drops out.

I found that my best bet was chicken sacrifice and Opus Dei-style self flagellation before each [Testing] 'pacman -Syu' . At least then I had a 50/50 chance of the next boot. But, granted, I use a lot of weird or fringe hardware.

All that said : other distributions don't have better [Testing] repositories. It's just that [Testing] is for .. testing. It's unstable by its' very nature.

[0]:https://www.archlinux.org/news/

I used to run Arch, I don't anymore although not for stability reasons.

13 instances of "manual intervention required" over 6 years seems awesome.

I think I did 2 manual interventions during my time using Archlinux, and each time it took maybe 2 minutes, it was just a matter of copy-pasting the commands in Arch News.

That's not awesome at all, it means something happening every 6 months. In corporate environments this means all the ceremony around it: tickets, CAB, etc.

Meanwhile you can use RHEL or CentOS and basically leave the thing alone for 5 years.

RHEL and CentOS are not targeting the same users as Arch.

Distros targeting the same desktop needs are Ubuntu, Mint, Debian-flavors, Fedora, Gentoo, ...

In corporate environment for critical software you would get a contract with an on-call duty and you would only have a limited choice fo supported distros.

absolutely, but the problem is that when I pointed out that arch is less stable than these other distro's, I had people trying to defend that claim.

There is no defending it, it's a fact of life. You get bleeding edge at the cost of stability.

In corporate environments

I probably wouldn't recommend Arch for corporate environments, but at this point I feel I should point out I wouldn't recommend Linux either if you're working in a windows shop.

I don't know about your experience, but if at most 13 little manual interventions in 6 years would be the only problem of most "stable" distros I would have never switched to Arch.

I've had various non-rolling distros fall apart on all sides within 6 months. With Arch I've had one manual intervention(aka one copy-pasted command) in over a year and one minor issue where I needed to restart a service. That's amazing and something I'll gladly take in exchange for painless and straightforward setup of pretty much anything.

Not to mention with regular backups(that should be done either way) and delaying updates in critical time periods you can easily minimize the risk.

> Not to mention with regular backups(that should be done either way) and delaying updates in critical time periods you can easily minimize the risk.

That's the minimum that you should be doing regardless of the OS. And thus, that's not where the risk is at.

It's probably more difficult to understand if you get paid regardless of whether you can get meaningful work done.

But for those of us who live on the other side, losing an unplanned half a day due to an OS issue that actively causes us to lose money, it matters.

Arch is bleeding edge, this means software bugs are far more likely on it.

I ran a stable arch system for 4 years with only one breaking change introduced. Everything else was minor with clear instructions on how to solve it on either main page or the forums

That's awfully nice for you. But my experience was horrible every single time I've tried Arch. The main problem is, every time you choose to update you have to brace yourself for possibly wasting another hour to repair the subtle breakage the new package version of some minor piece of software introduced.

I had Arch on a laptop I used for my freelance business once and took notes of the time spent on maintenance. So I actually have the numbers and know how much money I wasted compared to the time I used an Ubuntu LTS. Guess how many hours I wasted on repairing breakage on Ubuntu LTS. Exactly zero.

How long ago was your experience? That might be a factor. I have been using Arch for a long time, and if my memory serves, stability was a bigger issue years ago than it is now. These days, I have found Arch to be really solid.

That might be a factor, yes. Last time I tried Arch was around 2015.

However, I come from a business perspective here. You really don't need an operating system that introduces new versions on a whim in the middle of operations. There's a reason businesses run RHEL/Centos or macOS and whatever has LTS in Windows land: cost of maintenance and reliably wide windows of no possible breakage.

As a business, it's kind of a dodgy position to be at relying on "yeah, randomly upgrading versions worked for me so far. Fingers crossed, lol".

So I'm interested in what people use their Arch Linux for and what didn't work for them on any other stable platform. My personal observations point towards the Arch Linux users being the tinkerers who like to use cutting edge and hose their Debians trying to wedge some newer version into it. While the ones that ran screaming away from Arch pretty much never had the desire to change the underlying system and were happy with a security backport now and then.

Apparently businesses don't use rolling distro.

You don't want your PHP version to endlessly get updated during your operation when you build your app at a specific version.

It would mean not only you have to take care of distro update gotchas but you have to go through all the breaking changes the language introduces.

Stick with LTS. Rolling is for enthusiasts, though Arch does have put decent efforts on their wiki but I did find errors on minor pages that didn't make it work as written.

> You don't want your PHP version to endlessly get updated during your operation when you build your app at a specific version.

I think we'll figure out how to upgrade in the 2-3 years of support PHP has for each version. Trying to compare this to arch's rolling release style is bananas.

BINGO.

100% my experience as well, down to the freelance. I made another comment pointing out that the ones who think it's just a minor issue with Arch get paid whether they're getting meaningful work done or not.

https://wiki.archlinux.org/index.php/Frequently_asked_questi...?

> It is the user who is ultimately responsible for the stability of their own rolling release system. The user decides when to upgrade, and merges necessary changes when required. If the user reaches out to the community for help, it is often provided in a timely manner. The difference between Arch and other distributions in this regard is that Arch is truly a 'do-it-yourself' distribution; __complaints of breakage are misguided and unproductive, since upstream changes are not the responsibility of Arch devs__.

Even their wiki is very clear to inform you that you're at the whims of the package upgrades.

But I also want to point out that "it hasn't broke in a year" is cute, but I ran arch for probably 10+ years until I finally got tired of it and moved to Ubuntu. The last straw was me sitting down to get paying work done and spending half my day trying to recover my work environment. In the 2-3 years since I moved to Ubuntu I've never once sat down at my PC and had something stop working that was working before.

This defense of your favorite distro is especially silly when you think about it logically. Of course a rolling release system is going to have more breakages. The sensible response isn't "it never breaks!", but is instead "that's the nature of rolling release, you opt into it when you choose Arch".

This is funny, I could tell exactly the same story the other way around. I came as a 10+ year Debian user to Archlinux because it did too much automagic under the hood that broke and took a lot of time to fix. No breakage on arch because no automagic behind your back.

For a long time before using arch I thought too that rolling release might be more unstable, but I have come to the conclusion that quite the opposite might be true.

> I came as a 10+ year Debian user to Archlinux because it did too much automagic under the hood that broke and took a lot of time to fix.

This assertion makes no sense. Debian Stable has always the paragon of stability to the point that it's actually criticised for it. The Debian Testing release is even famous for being more solid than other distro's stable releases.

Breaking changes in Debian are practically only remotely possible in Debian Unstable or if you purposely install packages from backports or PPA repositories that have no assurance of stability or even maintenance.

The problem isn't so much that Debian packages or the ecosystem "breaks" as such, but that you run in to bugs (sometimes already fixed ones), and that you're then basically stuck with that unless you, the maintainer, or someone else decides to backport the fix, and they frequently don't get backported especially not for "minor" bugs.

Just compile it yourself and put it in /usr/local.

Well, yeah, but that's bypassing the package manager. You can say that in response to pretty much every argument about "I don't like package manager X because Y".

Use "checkinstall" instead of "make install". It builds and installs packages automatically.

Could you give some examples of the automagic stuff Debian does under the hood?

debhelper

debhelper is a library of tools for building packages. Debian users should not need to be aware debhelper exists, or even have it installed.

Maybe you meant debconf? When I was a DD it was an RC bug if your package used debconf to do "magic", i.e. using it as a registry for an application, or not properly re-seeding answers from the configuration and assuming the debconf db was the source of truth.

thankfully I said Ubuntu and not Debian.

Ubuntu has _more_ magic that breaks a lot more frequently in less expected ways than Debian.

Huh, when does anything break in Ubuntu LTS if you don't do a dist-upgrade? There's nothing to break if nothing changes. And the minor version upgrades along the years have not broken anything on any of my installs. Arch on the other hand ...

> Huh, when does anything break in Ubuntu LTS if you don't do a dist-upgrade?

That's a fist-full of caveats. Arch is willing to upgrade the kernel, maybe you should include a dist-upgrade in the comparison.

And that is precisely what you should not. The dist-upgrade is something you can plan for and set time aside for. The risky rolling mini upgrade every couple of weeks you can not. That is a huge difference!

> The dist-upgrade is something you can plan for and set time aside for. The risky rolling mini upgrade every couple of weeks you can not.

I can plan for it? You can see if you're upgrading your kernel. Nothing breaks if you decide not to run an upgrade.

And then I sit with a hopelessly old system I dare not to touch because I dread the day I have to do that kernel update or that one update that pulls in a new libc, leading to an upgrade orgy. I have seen that plenty of times.

This nonsense is why stable and LTS releases were introduced in the first place.

If I'm faced with a major upgrade of an LTS system, I usually choose to reinstall from scratch, shedding packages I haven't needed for a long time with it. But that happens every couple years or so.

If you're okay with hitting the forums now and then to find out why your desktop has been behaving oddly the last two weeks, rolling is your thing. You won't have to break in your new dist-upgraded or freshly installed system for like two weeks.

If you don't want to play lottery every time you hit enter for that update or if you're a business where you can't afford possibly breaking all your laptops for some security update, stable is your only option.

It's "choose the best tool for the job" I guess.

> If I'm faced with a major upgrade of an LTS system, I usually choose to reinstall from scratch, shedding packages I haven't needed for a long time with it. But that happens every couple years or so.

This goes back to my original point, which we've drifted a little from.

Ubuntu has more unexpected behaving when upgrading than Debian.

A working dist-upgrade should not be something that your OS struggles to provide. Asking people to reinstall their OS isn't an acceptable answer.

Upgrading should not be a lottery.

it's called LTS for a reason. Just don't dist-upgrade, problem solved.

This argument that you MUST dist-upgrade as soon as the next version is available, and completely ignore the entire idea around LTS, is silly.

> This argument that you MUST dist-upgrade as soon as the next version is available, and completely ignore the entire idea around LTS, is silly.

This idea that you never want to upgrade from one LTS to the next is equally ridiculous. Upgrading the operating system is part of the package manager's job.

this reply 100% mirrors my thoughts on the matter, all the way down to preferring re-installs over dist-upgrade's.

I like Linux, I don't dislike dealing with the OS. But I want to deal with it on my time. Expecting to get work done and then realizing something is broken and being forced to deal with it is a completely different proposition from picking out a weekend to reinstall your work PC with the newest LTS version.

They first time I tried Arch, I installed it, did a system update and libc completely broke and my system was unusable. I went back to Gentoo.

I went through some hell when I ran Gentoo unstable(~) but for the past several years I've been on Gentoo stable and have very few issues. I've even used it on work laptops at three different companies.

It is definitely more of a do-it-yourself distro than Arch for sure, but I enjoy working with it.

I ran Gentoo until shortly after Daniel Robbins left the project. It just started to have problems. A good example is that installing KDE would break to the point of needing to throw everything away unless you installed a few other packages in a very specific order.

That never seemed acceptable to me and I ended up moving over to Arch Linux for a good 10+ years before the instability of it finally got to me and I moved to Ubuntu.

Having said all of that, I'm glad to hear that Gentoo is stable for you. I really enjoyed my time with Gentoo and I got the feeling that after he left there were mistakes made in terms of everything working reasonably.

Your description of Arch reminds me of an experience I had with linode and arch years back. Due to an internal hardware issue, they basically lost my server. When I went to recreate, I discovered that you couldn't just update the world because it would immediately result in a broken system. You instead had to reconfigure a few things before updating the world.

I no longer use Linode.

At some point the vendor has to take responsibility. That's a large part of why I like Ubuntu, they do. It works every day without me having to worry about it.

I used to run Gentoo. At one point, trying to resolve dependency conflicts, and not knowing what I was trying to do, I uninstalled libc. Obviously, my system immediately became unusable.

I actually appreciate that Gentoo is set up to allow me to run that command if I want to.

But I did move off of Gentoo due to constant dependency conflicts. They took forever to deal with and they were pretty well guaranteed to happen whenever you didn't hold to a strict and frequent update schedule.

> Of course a rolling release system is going to have more breakages.

Well, no. The point of a rolling release system is that you upgrade by little increments, so you never have a moment when a 'major upgrade' happens and breaks your system or forces a reinstall.

I think a rolling release is going to have more breakages, but smaller.

> The last straw was me sitting down to get paying work done and spending half my day trying to recover my work environment.

Maybe don't pacman -Syu before work or if you're working the next day? It's not strictly necessary to update every day.

And no one said Arch never breaks, I just provided anecdotal counterevidence that it's really not that bad.

But I also want to point out that "it hasn't broke in a year" is cute

Why be condescending? The above user has a good point, and your view is clearly against the majority of Arch Linux users.

Obviously this is true for "Arch Linux users", but that is a self-selected set of individuals with correspondingly biased circumstances/behaviors etc... I wonder if your statement still holds holds when we change the domain to people who have used Arch Linux at some point in the past?

As I understand it, Arch Linux is like having a pet. It requires constant care and feeding to keep it alive but can be very rewarding (allegedly)

You misunderstand it, then. Arch is stable enough that (unless you're doing stupid things, like grabbing half of your system from the AUR) there will only be a breaking change every three years or so. Just set a cron job to update it for you and you have nothing to worry about. It was literally created for lazy system administrators, and it's only gotten better for them as time goes on.

if that were true their FAQ wouldn't tell you that broken packages weren't their responsibility.

I don't think that's true at all. If you use Ubuntu, broken packages are ultimately your responsibility unless you're paying for support from Canonical. In both Ubuntu and Arch Linux, changes will be handled carefully by the maintainers to try to avoid breakage where at all possible. The difference is basically that on Arch you're supposed to be able to handle basic sysadmin tasks yourself, which means that Arch Linux will ship breaking changes (with a mailing list warning) that require you to run a command or two yourself. Even with that qualifier, this is uncommon.

> on Arch you're supposed to be able to handle basic sysadmin tasks yourself

And the reason for this is because you realize the latest update killed virtualbox and you require it for your work so you need to be able to downgrade and pin the vbox application to a specific version.

Meanwhile, Ubuntu catches the problem and refuses to update the package until it's fixed. Therefore I never even realize there was a breaking update to vbox somewhere.

The difference being that Arch tells me when to tinker because it blew up again, Ubuntu allows me to choose when to tinker because it doesn't.

That faq doesn't make a claim about how frequent such things are.

In my experience it happens very rarely and is often quite easily resolved.

  >happens very rarely 
  >is often quite

Well you sure convinced me!

> and your view is clearly against the majority of Arch Linux users.

I just gave a link from their FAQ that clearly states the system will break when packages break and they aren't responsible for it. As another user pointed out, you can go do a search for 'manual intervention' and find years of results on their front page.

Arch Linux users are ok with having their system randomly stop working. I used to be ok with it, until the umpteenth day that I lost half my working day getting the system back up and running.

Unless Arch Linux broke for you because they ship multiple versions of some packages, that's not really relevant. This is a thing all the popular Linux distributions do as far as I know.

Also, personally I've stuck with Arch Linux for 6-7 years now because it's the first distribution I found that consistently works for me, so I don't know that anecdotes will get us very far either way.

If we're honest: Arch is annoying, but the reason people (including me) run it is because they don't want their OS to explode in a shitstorm every time a 'major upgrade' cycle happens. (Looking at you, Ubuntu.)

So, your comment is 180 degrees off the mark. Arch exists for people who don't want breakages to happen.

(On the other hand, if you're conditioned by Windows to reinstall the system every year, then Ubuntu might work fine for you.)

> Arch exists for people who don't want breakages to happen.

Or, for people who don't want breakages but also want/need current software versions.

Debian-based stuff can be pretty nice and stable as well, but on Arch installing and setting up anything usually "just works" without missing dependencies, renamed packages etc.

The difference is I that I know the dist-upgrade is coming and can plan for it. With Arch it's on that one day that I really needed to get work done, but Arch decided it wasn't happening.

I think I'll take the planned upgrade, thanks.

Strange, the story has been quite the opposite for me, Since I moved to Arch Linux I only had one minor breakage (bluetooth) that was fixed in a day, whereas in Ubuntu I cannot count how many times an update or a PPA broke something.

It depends if your Ubuntu is LTS or not. I'd say LTS Ubuntu > Arch > non LTS Ubuntu as Arch tries to be stable on its only version but Ubuntu can be more aggressive between LTS.

PPA breaking is apparently not Ubuntu's fault.

Oh man. This seems to have spawned an anecdota war.

I think the main issue/benefit with arch linux is that it wont try to do anything for you, except give you extra instructions for when a package change requires "manual intervention".

I put that in quotes because I don't think of that as breakage, I think of that as normal upkeep. We'll, as long as it's listed.

Anyway, the implications are that things can be stable longer on arch because there is no magic under the hood. But there will be times (though I haven't experienced it myself), where something unexpectedly breaks, and it'll be hard to recover unless you know what your doing... though maybe it's actually easy with the rolling back packages? The package manage does keep copies of old versions of packages, I've just never needed them.

As an example if this, my co worker and I have very similar thinkpad laptops. His graphics start doing wierd things that hes has to go fix after every update (Fedora or Ubuntu, can't remember). I took 4+ hours to get mine working how I want, with research and experimentation, but nothing has broke it since.

Out-of-date software and related dependency hell is the breakage that rolling-release/Arch gets me away from.

More UX anecdote; I use Arch (btw) but trying Manjaro just now for something so I grabed an image from osboxes.org; the system update fails after hitting enter on the default options https://i.imgur.com/OTNRMrH.png

'y' for the last would have continued things, but "ugh, I have to think about something" is breakage to some.

> But there will be times (though I haven't experienced it myself), where something unexpectedly breaks, and it'll be hard to recover unless you know what your doing...

The thing is, my experience with Ubuntu is that there will be times when something unexpectedly breaks, and because of the added complexity, it will be nearly impossible to recover even if you know what you're doing.

Docker to the rescue! For development, docker is godsend. It is a developer must have just like git, I regret I didn't learn it sooner.

Reply on news.ycombinator.com