2 ms·

> This is BS. No, it's not. The parent is reporting a personal experience. Just like you. Back in 2009 when I switched to Arch, one of the reasons why I switc

> This is BS. No, it's not. The parent is reporting a personal experience. Just like you. Back in 2009 when I switched to Arch, one of the reasons why I switched was because dist-upgrade frequently blew up on me and I didn't know how to fix it. Maybe it was user error. Maybe I didn't know what I was doing. Maybe Arch just empowered me to understand my system better. I don't really know what the reason is, but nevertheless, the experience isn't bullshit. It really happens.

ackalker 11y ago
I believe an important reason why Arch is easier to maintain has to do with its minimal package customization: Applications already have their own learning curve, custom packaging only adds to this. Just reading the documentation or googling for answers may not be enough, one also needs to understand how and why packagers have changed things to be different from upstream. Personally, I prefer the Arch way of keeping package customization to the bare minimum. Combined with the very simple package format and powerful tools, Arch is a winner.
VLM 11y ago
"dist-upgrade frequently" Why would you run dist-upgrade frequently? Its hard to diagnose a bug report like that, BUT, one reason to run dist-upgrade frequently would be if you're tracking unstable or testing especially during the early times of a dev cycle. Don't do that. Run unstable or testing I mean. Its a "let you shoot yourself in your foot if you insist on doing it" type thing. Unstable will tend to be unstable... You should have to run dist-upgrade exactly one day per release cycle if you run stable. You may have to run it twice for certain historical upgrades lost in the mists of time, so I can't say it never happens and always only run it once per release cycle.
- burntsushi 11y ago
  I think you may have misinterpreted. I didn't run dist-upgrade frequently, rather, the ratio of failure was high. (This my memory from 6-7 years ago. For all I know, it could have failed twice because I did something stupid, didn't know it, and moved on.) My central point is calling someone's else's experience bullshit, is, well, bullshit. My comment has little to do with anything else.

ackalker 11y ago

I believe an important reason why Arch is easier to maintain has to do with its minimal package customization: Applications already have their own learning curve, custom packaging only adds to this. Just reading the documentation or googling for answers may not be enough, one also needs to understand how and why packagers have changed things to be different from upstream. Personally, I prefer the Arch way of keeping package customization to the bare minimum. Combined with the very simple package format and powerful tools, Arch is a winner.

VLM 11y ago

"dist-upgrade frequently" Why would you run dist-upgrade frequently? Its hard to diagnose a bug report like that, BUT, one reason to run dist-upgrade frequently would be if you're tracking unstable or testing especially during the early times of a dev cycle. Don't do that. Run unstable or testing I mean. Its a "let you shoot yourself in your foot if you insist on doing it" type thing. Unstable will tend to be unstable... You should have to run dist-upgrade exactly one day per release cycle if you run stable. You may have to run it twice for certain historical upgrades lost in the mists of time, so I can't say it never happens and always only run it once per release cycle.

burntsushi 11y ago
I think you may have misinterpreted. I didn't run dist-upgrade frequently, rather, the ratio of failure was high. (This my memory from 6-7 years ago. For all I know, it could have failed twice because I did something stupid, didn't know it, and moved on.) My central point is calling someone's else's experience bullshit, is, well, bullshit. My comment has little to do with anything else.