Replacing OpenSUSE Leap | Hacker News Reader

Replacing OpenSUSE Leap

lwn.net

31 pointscorbet17 comments

I migrated my Leap installation to TW a few weeks ago. So far, no problems. I’m running Arch in a VM also just to see which rolling release crashes first

Neither will, really. I have run both for the last decade or so, the packages are stable, it's not like rolling means "pile of random stuff".

I have been happily running tumbleweed for a long time, whereas my arch Linux for arm has required hand on healing many times.

Arch really scared me away from running rolling release distros. Services suddenly changing configuration formats leading to failure to start at boot. Breaking package changes that was my fault since I didn't keep up with the forums.

I did have one breaking change with tumbleweed, but then it warmed me and wouldn't let me proceed with the update until I had acknowledged that I would have to fix my openvpn (I think it was) config.

> Breaking package changes that was my fault since I didn't keep up with the forums.

That's explicitly part of the contract between users and maintainers you accept when running Arch and it has nothing to do with it being a rolling release. Many other rolling releases like Debian or OpenSUSE set completely different expectations to their users.

Yes of course. But that is not the picture painted by many online. How often haven't you read "Arch has been rock solid"?

This is not what the arch homepage says, which explicitly says that it is not the job of the distro to ensure compatibility between updates.

Indeed. "You should just run Arch" is giving "just rewrite everything in Rust" a run for it's money, especially since the "Mill will solve all of those pesky CS problems" folks have gone quiet.

In my experience Arch has been pretty solid indeed (not as solid as, say, Debian sid, but close enough), but that assumes that you do read the news pages before upgrading and that you know how to deal with AUR well. Otherwise it's not Arch's fault when it breaks :P

Just a for-the-record counterpoint:

I have a laptop that is running an Arch install that was first installed in 2011. It runs great. It has, to my memory, twice required manual intervention. (to be fair, it once required manual intervention when I moved the hard drive into an entirely new chassis, and once again when I migrated it from 32bit to 64bit, so 4 times total.)

And I have several other arch boxes that are less old but have had no trouble.

In fact, the distro that's given me the most trouble has been Fedora, but at least when its upgrades fail they now just roll back and make you try again...

Arch really wants you to keep up to date. Run those - Syu's. Often. Never more than a week. If you let it sit for months and months that's when things can get hairy.

I dumped Ubuntu for TW a couple of months back. Not that I'm stress testing it, but it's been very painless.

I've been a Tumbleweed user for a decade and never used Leap. If Leap users are worried by this I encourage them to try TW, because it's probably not as unstable as you imagine it is. In the worst case you have zypper snapshots to fall back to anyway.

Love TW.

I don't want to do >1 Gb updates ever so often. So I stick to Leap.

I "just" run a local mirror on my LAN that rsyncs to upstream every night. So it doesn't matter to me however many gigs it downloads, and whenever I decide to update all the machines on my LAN using that mirror it's fast regardless of how many gigs of updates there are.

If my understanding is right, OpenSUSE Tumbleweed isn't exactly a rolling release correct? It is creating a snapshot at regular intervals (weekly? Or monthly) and NOT updating packages which have updates.

This means irrespective of you having only updates for 100 packages, it will update all your 1500 packages (Or the number of packages that you have installed on the system).

Can someone confirm this? Because if this is true, that is such a waste.

That is not at all true, Tumbleweed often updates as often as daily and only the packages that need to be updated are updated outside of the rare case of a new glib version where everything has to rebuilt and all packages are indeed updated.

The reason TW has big 1500-package updates is not because of any snapshotting. It's because TW's automation defensively bumps the release number of reverse dependencies. So if libfoo is updated then all reverse dependencies of libfoo are also updated, regardless of whether the libfoo update was ABI-compatible or not.

In Alpine for example, the maintainers only bump rdepends when they think those need to be rebuilt, which sometimes leads to them underestimating and those unupdated rdepends end up breaking. TW avoids that but at the cost of a lot of "pointless" updates.

Thank you. That clears a lot of things.

Reply on news.ycombinator.com