dnf has recently added automatic restart support of systemd system services (and soon user services). It's opt-in per package, but expect things to restart more in the future.
Restart is fine. It only takes a fraction of a second.
But APT doesn't do restarts. It stops services and doesn't start them back up until it's finished with all the other packages. This can take a few minutes if there are kernel updates that trigger multiple initramfs rebuilds, or indefinitely long if the update process throws up a dialog to confirm something.
OP makes it clear why this is happening. Packages have no concept of an upgrade, so APT stops services before removing the old version, and starts them back up after installing the new version.
dnf has support for using the CoW support of Btrfs to make all the disk I/O more efficient. Might be why you're seeing dnf being more efficient, because my somewhat outdated experience is totally opposite.
YUM/DNF (and RPM itself) are very different beasts from what they used to be some time in the past. For some reason, updating repository metadata is still slow compared to APT, but installing packages is speedy enough. However, in terms of features it's just... better.
Two things that I especially appreciate:
I can install things without knowing the package names, eg. "dnf install /usr/bin/foot 'perl(XML::Tiny)' 'pkgconfig(bwayland-client)' libaudit.so.1" will just work.
These are especially useful when packaging stuff yourself because you can use these indirect references in your dependency list so it doesn't matter which package actually provides them.
I can also "sync" my system to a set of repositories with distro-sync, downgrading and/or replacing packages as necessary. I've had a few times with Ubuntu that I wished APT had this.
I also like that it does not have debconf. I don't have much love for debconf.
As I understand it the CoW support is for (optionally) taking filesystem snapshots before/after applying package upgrades, I don't think it inherently makes disk I/O more efficient. There are some other neat tricks that dnf does though. For example, in my experience dnf/rpm are smarter in the case where N packages need to run the same post-install step and run it once instead of apt/dpkg which might run it N times (examples: updating the man database, updating icon caches, updating ldconfig cache). And as the article points out, rpm packages are smarter about skipping post-install steps altogether for package updates.
In general it's my impression that dnf/rpm have been much more actively developed in the past few years than apt/dpkg. Depending on how long it's been since you last used it, they've made changes to the manifest format, the internal rpm database format, and rewritten a lot of parts of dnf in C for speed, and all of these have made a huge impact on the speed and usability of dnf.
Vipps is Norways leading mobile wallet. We're looking for a candidate to our Payment Engineering division with extensive relational database experience. We mainly use Go, MSSQL and Azure. Learn more at: https://www.finn.no/job/fulltime/ad.html?finnkode=186256251
Ah, sorry, Swipp was the Danish MobilePay competitor that died due to Danske Bank's disgustingly unfair play (they were part of the Swipp group, but started MobilePay development in the background and launched before Swipp did). I was of course referring to Swish.
MobilePay passed 3 million users in 2016 (out of ~7 million people). I don't have any updated statistics.
Anyway, with your added numbers, it is quite clear that at least in Scandinavia, person to person transfers are very common.
Vipps AS | Backend Developer | Oslo, Norway | ONSITE
In Vipps we’re on a mission to make life easier for people and businesses through smart payments. Every day we are solving real life problems for our 2.7 million users and 50.000 merchants.
We started with simplifying peer-to-peer payments, where we replaced your account number with your phone number. Now we are working on drastically simplify the way people and businesses do payments. We have lots to do and are looking for a talented Backend Developer to join us.
Our various backend systems are currently written in Java and Go. They run in container services on the public cloud. We store the majority of our data in traditional relational databases. We strive to use the best tool for the job without getting religious in our technical choices. We care more about your general development skills than experience with any particular language or framework.
