Distribution quotes of the week

[Posted July 19, 2017 by ris]

Doing live updates with rpm is a bit like doing maintenance on your car engine while driving down the freeway. Most of the time it's fine, and you feel awesome. 0.001% of the time you die in a huge fireball.

— Richard Hughes

At the time of writing, more than 10% of the web is powered by Debian. How many web sites would you have missed today without Debian? Debian is the operating system of choice on the international space station and countless universities, companies and public administrations rely on Debian to deliver services to millions of users around the world and beyond. Debian is a highly successful and is far more pervasive in our lives than people are aware of, even within the GNU/Linux community.

— Chris Lamb

Distribution quotes of the week

Posted Jul 21, 2017 21:42 UTC (Fri) by rc (subscriber, #108304) [Link] (11 responses)

> Doing live updates with rpm is a bit like doing maintenance on your car engine while driving down the freeway. Most of the time it's fine, and you feel awesome. 0.001% of the time you die in a huge fireball.

I get really tired of hearing this argument, especially since the consequences are more like getting a flat and safely pulling to the side of the road. The ability to change out the tire is dependent on the availability of the spare, tools available, and competency of the driver.

Unfortunately I don't have enough time to dig into the context of this quote as I would like, but it seems like some people worry about the wrong problems. Sure, the update isn't atomic but if I'm doing this on a live, production system then I accept that some HTTP request, for example, might mess up and need to be restarted by the client. Maybe the upgrade is botched completely, but that's why competent admins utilize application level redundancy.

This email was a reply to a reply of "How about reliable online updates of running applications as a benefit?". I've had very reliable updates on all my Debian-based systems pretty much all the time except when I'm doing something more complicated like using a third-party repo. Regardless, that's why we use application-level redundancy on all of our many services so that a failure isn't catastrophic. It's more like "oops, wonder why that happened. Let's figure that out and fix it before bringing the system online again and updating the next server. No rush, maybe next week.". Never once have I wished for something like Flatpak to make my updates more reliable. I can't even fathom worrying about reliable updates and I've spent many years working on thousands of Linux servers. Or is rpm really that bad that I should worry if I use an rpm-based system?

Distribution quotes of the week

Posted Jul 21, 2017 22:19 UTC (Fri) by smckay (guest, #103253) [Link]

This is not a server problem, it's a desktop problem. Everything is production, nothing is redundant, and breakage is always going to piss someone off.

Distribution quotes of the week

Posted Aug 7, 2017 12:39 UTC (Mon) by hadess (subscriber, #24252) [Link] (9 responses)

> Or is rpm really that bad that I should worry if I use an rpm-based system?

deb-based systems have the exact same problems. Anything unexpected in the middle of the update can kill the system. "Nobody would run apt-get upgrade through SSH". Well, nothing is stopping anyone from shooting themselves in the foot. It works "most of the time" and "if you know what you're doing". And if you're not a techie with "many years working on thousands of Linux servers" then you'd have no clue how to fix it, and go back to macOS or Windows.

You're a super-driver, fine, just don't tell people to do 200mph on their motorbikes in the city centre just because you've got the skills to.

Distribution quotes of the week

Posted Aug 7, 2017 13:21 UTC (Mon) by madscientist (subscriber, #16861) [Link] (4 responses)

Anyone who knows enough to be able to, or even to NEED to, run apt-get upgrade through SSH, is experienced enough to understand the possible risks.

The people who might be induced to flee back to MacOS or Windows by an upgrade failing are the people who are going to be using the GUI "software upgrader" box that shows up on their desktop, not SSH.

In any event, even MacOS and Windows users are quite smart enough to know that if you interrupt an upgrade, Bad Things can happen. They happen on MacOS and Windows, too. And iPhones, and Androids, and...

Distribution quotes of the week

Posted Aug 7, 2017 20:27 UTC (Mon) by paulj (subscriber, #341) [Link] (2 responses)

Surely anyone doing an upgrade over SSH is doing so with the upgrade running in screen/tmux?

FWIW, this advice applies equally to running upgrade from within a graphical login session.

Distribution quotes of the week

Posted Aug 8, 2017 2:21 UTC (Tue) by smckay (guest, #103253) [Link]

Eh I probably wouldn't bother. But our ace sysadmin has set things up so launching a VM into a role is trivial. Why be careful with your systems when you can shoot them in the head (almost) at will.

Distribution quotes of the week

Posted Aug 8, 2017 8:30 UTC (Tue) by hadess (subscriber, #24252) [Link]

> Surely anyone doing an upgrade over SSH is doing so with the upgrade running in screen/tmux?
> FWIW, this advice applies equally to running upgrade from within a graphical login session.

This is the sort of thing that one usually learns after they've broken a number of installations. The expectations that somebody would know every way things could go wrong, without said software, say, warning the users about it, really makes me think that I've replied in the "why didn't you read the unwritten best practices" section of the comments.

"Surely everyone doing 200mph in the city centre knows how to do somersaults over the handlebars of their bike".

Distribution quotes of the week

Posted Aug 8, 2017 8:34 UTC (Tue) by hadess (subscriber, #24252) [Link]

> Anyone who knows enough to be able to, or even to NEED to, run apt-get upgrade through SSH, is experienced enough to understand the possible risks.
> The people who might be induced to flee back to MacOS or Windows by an upgrade failing are the people who are going to be using the GUI "software upgrader" box that shows up on their desktop, not SSH.

False dichotomy. You can very well know about both those tools, and not know the effect of combining them. Every time you say that somebody should surely know something would cause breakage, you also confirm that we're right to reboot machines to do updates, because that's the only way to minimise breakage during upgrades.

Distribution quotes of the week

Posted Aug 8, 2017 15:42 UTC (Tue) by sourcejedi (guest, #45153) [Link] (3 responses)

AIUI the command-line tools for deb-based systems are designed to tell the user what to do after being interrupted. rpm isn't. When Fedora blew it up, it required manual instructions to type in and run a whole script, which I can't immediately find looking at the announcement thereof. And the announcement says the script was unreliable anyway, because there's no expectation that RPM scriptlets are written to be idempotent, unlike in Debian.

Not to make a judgement on whether the design _suceeds_, or whether there are gaping pitfalls in it that I haven't seen, but rpm is kind of ridiculous here. Our systems are supposed to survive the odd power failure nowadays.

https://lwn.net/Articles/702629/

Do you want to be KeyKOS, or Novell?

https://lists.inf.ethz.ch/pipermail/oberon/2010/005734.html

Distribution quotes of the week

Posted Aug 8, 2017 17:28 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

"AIUI the command-line tools for deb-based systems are designed to tell the user what to do after being interrupted. rpm isn't"

Can you be specific on what "deb based systems" tell users to do? Also you are comparing "deb based systems" with "rpm" which sounds like you are comparing some high level tool to a packing format. That isn't an equivalent comparison. RPM isn't designed to be interactive but higher level tools like rpmconf or yum or dnf certainly can and do offer suggestions.

Distribution quotes of the week

Posted Aug 10, 2017 7:33 UTC (Thu) by sourcejedi (guest, #45153) [Link] (1 responses)

According to my test notes in the linked thread (search my username), the next invocation of apt-get will tell you to run `apt-get -f install` if that is required.

You can also see advice to run `dpkg --configure -a`. I think I saw that as well. I don't know what the different circumstances are.

Hopefully both of these are suitable for incorporation into PK as well ala `pkcon repair`, and hence any support for that in the GUIs.

The situation I describe was when dnf was interrupted by a Fedora issue; it provided no such advice, _and according to Fedora's response there was no such automatic command available_.

rpm seems to manage not to advise the specific command which is sometimes necessary either (the rebuilddb one). https://gist.github.com/Paul92/10a7806ae43f5d9ac2ce3f9379...

I can't help thinking of the two LWN articles, which say the foundation that is rpm has not been well-maintained.

Distribution quotes of the week

Posted Aug 10, 2017 11:11 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

> According to my test notes in the linked thread (search my username), the next invocation of apt-get will tell you to run `apt-get -f install` if that is required.

So, this is apt-get offering you a suggestion. Nothing to do with deb. Such suggestions are offered by yum/dnf as well when it detects duplicate packages etc. Could the suggestions be extended to cover situations? Very likely, yes. It has nothing to do with the underlying format.

The other article covers recommended best practice which is to run upgrades in a screen multiplexer to reduce the risks from being interrupted. That is a good practice no matter what packaging format you use.