DNF Seems To Be Working Well As Yum's Future Replacement

[DrYak]

Yes the dll issue was a bad example. But in the extreme case you will end with a separate environment for each different program. Doesn't sound that great either.

But there's rarely a better way to handle those extreme cases, short of managing to get the source (under NDA or whatever) and recompile it for your distro.
And in fact systemd proposal uses BTRFS "behind-the-scene". BTRFS has Copy-on-write, data-deduplication. In adition systemd is designed with the idea that USR can be hard-read-only (it could be burned on a DVD-ROM), and var and etc are completely optionnal and could be automatically generated on the fly to make a fresh chroot.
That means you only need to keep 1 copy /usr per different type of environment, not 1 for every single instance of software running into it.
(You need 1 copy of SteamOS for steam games. Maybe another 1 or 2 readhat for commercial software only available on that)

So in practice, it come with way much more cheaper hardware requirement that you could think of.

(All the steam games will share the same single steamOS instance in read-only mount,
and all the files wich are same or very similar will be deduped and share same extents on the disk between the steamOS usr and your OS' usr. So less pressure on your ram/buffer/cache than completely different system)

That is much cheap than the current way, where each "alien" software needs its whole bunch of separate ".so" files. (Skype needs to come packages with a bunch. Current incarnation of steam has a huge bunch of standard libraries, etc.)

(Add also the argument that the current situation for skype is only providing libraries for compatibility. With LXC-like Cgroup, such an approach could actually *isolate* securely skype: give it only access to its wayland surfaces and pulseaudio source/sinks, and that's it).

---

Also, for the crowd that only uses basic function of a system and never bother customising it (i.e.: people who only browse facebook/gmail/etc. and which basically have the same usage pattern like ChromeOS), that means that instead of installing upgrades package-by-packages, you could just stream a new /usr (and actually only stream the latest modification since your last sync, thanks to BTRFS' send/receive), which is going to be much faster.

Same for enterprise setting that deploy the same environment on all PCs - just to the actual RPMing/DEBing on the master copy and simply replicate the /usr on the rest of the enterprise.
Same for server farms / cluster nodes.
Same for a unified environment (the SteamOS copy that a potential systemd-powered steam could use)

Same for embed firmware upgrade (puts a lot less pressure on Flash than single package upgrading. A little bit lighter than whole-ROM reflashing)

Thanks to send/receive non-power user, or users to bored to care, can outsource the actual package management and only get upgraded images.
etc.

[log0]

..

Or you stick to stuff where you have access to the source code, and leave the blobs to blob OSes. I know might sound like a purist option, but avoids the crazy complexity this blob handling solutions introduce.

[DrYak]

Or you stick to stuff where you have access to the source code, and leave the blobs to blob OSes. I know might sound like a purist option, but avoids the crazy complexity this blob handling solutions introduce.

Sadly, not all of us have the leisure of this choice.
My main culprit are the horrible huge blob that some equipment manufacturer send with their lab equipment and that we need to somehow find a way to get running on our cluster.
I would definitely love to have access to the source (even under NDA) to make things simpler, but no, that not the way it works.


(Also, I enjoy injecting as much freesoftware as possible everywhere. SteamOS and Steam would bring more linux in the living room and on gaming console. I like the concept, even if it means some collaboration with a hugle closed source world)

[RahulSundaram]

IMO DNF still has far to many issues. like as noted on the phoronix, an i hit this problem myself. DNF doesnt handle importing RPMFUSION to good, where you must use YUM to do it.

This was fixed sometime ago

https://bugzilla.redhat.com/show_bug.cgi?id=1133830

I can confirm this

$ sudo rpm -e $(rpm -qa gpg-pub\*)
$ sudo dnf install ffmpeg
sudo dnf install ffmpeg
Dependencies resolved.
================================================== ==============================
Package Arch Version Repository Size
================================================== ==============================
Installing:
ffmpeg x86_64 2.3.3-3.fc21 rpmfusion-free-rawhide 1.5 M

Transaction Summary
================================================== ==============================
Install 1 Package

Total download size: 1.5 M
Installed size: 6.3 M
Is this ok [y/N]: y
Downloading Packages:
ffmpeg-2.3.3-3.fc21.x86_64.rpm 398 kB/s | 1.5 MB 00:03
warning: /var/cache/dnf/x86_64/21/rpmfusion-free-rawhide/packages/ffmpeg-2.3.3-3.fc21.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 6446d859: NOKEY
Importing GPG key 0xAE688223:
Userid : "RPM Fusion free repository for Fedora (20) <[email protected]>"
Fingerprint: 0017 DDFE FD13 2929 9D55 B1D3 963A 8848 AE68 8223
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-latest
Is this ok [y/N]: y
Key imported successfully
Importing GPG key 0x6446D859:
Userid : "RPM Fusion free repository for Fedora (21) <[email protected]>"
Fingerprint: E9AF 4932 31E2 DF6F FDFE 0852 3C83 7D0D 6446 D859
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-rawhide
Is this ok [y/N]: y
Key imported successfully
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Installing : ffmpeg-2.3.3-3.fc21.x86_64 1/1
Verifying : ffmpeg-2.3.3-3.fc21.x86_64 1/1

Installed:
ffmpeg.x86_64 2.3.3-3.fc21

[RahulSundaram]

On Fedora alpha I got DNF 0.6 and it's as stupid as yum.
I mean, on Ubuntu I do "apt-get show app-name" and it does just that, dnf however (dnf info app-name), just like yum, first downloads crap from the internet which makes it like 10-20 times slower than the Ubuntu alternative. And don't give me the shit that it only updates once in a while - it really downloads stuff at random times and it's a stupid default behavior to begin with.

Others have already suggested using -C but a related bug has been fixed recently to rely on the cache more for certain commands

https://github.com/rpm-software-management/dnf/commit/5b71de0f9a6845f4b9c5f5bc1de041b07408cffc

[nanonyme]

The use of Python has little to do with the performance issues. I mean, no question that it'd be a poor choice for CPU-intensive tasks, but when an application is doing large amounts of I/O, the speed of the language runtime tends to be drowned out by things like disk access speed and network bandwidth...

Well, large amount of time these days goes to calculating dependencies and applying deltas anyway

[RahulSundaram]

Well, large amount of time these days goes to calculating dependencies and applying deltas anyway

Sure but in those cases, Python is merely glue code calling c libraries and tools.

[nanonyme]

Sure but in those cases, Python is merely glue code calling c libraries and tools.

Pedantically so it is with networking. Python just happens to have better glue code for some things than others

[RahulSundaram]

Pedantically so it is with networking. Python just happens to have better glue code for some things than others

Sure. If written correctly, you would use Python for more high level tasks and if anything is truly performance sensitive and Python performance is a blocker, you could use something like C or C++ for those tasks. Some of those apps which used to do this have moved over to Go even to the surprise of Google but maturity of Python as a language and especially the library support is quite nice.