Skip to main content

Linux Magazine: Having Yum for Breakfast

Found that article from Linux Magazine titled Having Yum for Breakfast via Distrowatch. According to the test apt-deb easily beats yum. Any comments about result and factors that affect it? From what I understand, apt-deb is static by nature unlike yum (dynamic) which could probably explain faster transaction.

Update: Added author's blog related to the article.


Jef Spaleta said…
See if you can get the exact step-by-step methodology used in creating the benchmarks.

better yet see if you can get the full log of the screen session used to do create the data for the benchmarks.

There could be a flaw in the methodology that biases towards apt operation. Can't know if it was a fair test unless the specifics of how to run the test are made available for review.

duvworld said…
I think that article is some FUD on yum. In the comments the author (assuming that it is the writer) seems to point out that, these tests where not done on a network as noted here (the emphasis is mine)
"That’s true, but it’s rather hard to test, especially when connection speeds come into it and finding packages the same size. I think it’s safe to say that you’ll be downloading less by using the deltas than you would on Debian.

For these tests, all packages were pre-downloaded so bypass the network download issue."

I find that odd since, based on there functions, network downloads are what they do. Even with the localinstall flag, fetching from the internet is what they are designed for... so this review seem to be designed to do something that yum nor apt happened to be designed for?

I don't know, that seems odd... Maybe I am wrong?
Jef Spaleta said…

You are wrong, in a way. Network activity across the external internet can be subject to all sorts of different factors outside of your control. Such network activity would distort the timing benchmarks greatly.

Its actually far more scientific if you work from local caches of the repository metadata and the packages to avoid any external network activity during the benchmark tests. These tools do all their dep resolution transactions from local data stores regadless. Excluding the variability of network access is actually the most appropriate thing to do if your goal is to test transaction speed.

That being said, pulling packages and/or repository level metadata across the network has an objective cost in terms of user interaction perception, that is worth talking about, if you can adequately separate that out from other operations.

In fact my biggest concern is that the benchmark author did not adequately segregate network activity for repository metadata when doing the test.
To make sense of the benchmarks I need details of the methodology used to run the tests, so I can reproduce the tests for myself.

Jef: Good catch about the log. To answer the first paragraph, I cannot because of the lack of information of packages used for the test.

Also the way both yum and apt differ is due to the fact yum is designer for smooth transaction like for example: yum update is equivalent ot apt-get dist && apt-get update (I can't remember as I haven't used it for a while).

duvword: The author and writer is the same. He used to build Kororaa, a Gentoo based distribution, and mostly manually update package. I am updating the blog to add his blog so issues can be discussed.

Popular posts from this blog

Running amdgpu driver on AMD hybrid laptop

Running the ASUS X550ZE laptop on latest Linux kernel 4.9 series from Mystro256 Copr repository based on AMD contributor Alexander Deucher's freedesktop branch within Fedora Design Suite 25.

The hybrid support has improved now that the dedicated graphic card AMD R5 M230 Jet Pro (aka Hainan) is functional with enabled amdgpu module for both Sea Island (CIK) and South Island (SI) videocards thanks to the hard work from AMD developers. The latter was important in order to fully support all GCN (Graphics Core Next) chipsets as possible to allow future run on open source version of Vulkan, RADV (short for Radeon Vulkan).

The power manager is functional and further optimization will be required in term on parity with Microsoft Windows version. According to Freedesktop Radeon list almost all features are implemented into the driver, hybrid graphic cards run fine, only OpenGL needs more work. As the desktop ecosystem in the freedesktop environment modernize to support Wayland protocole, a…

Running Sapphire Pulse Radeon RX 560 4GB on Fedora 27 Beta

I bought a Sapphire PulseRadeon RX 560 4GB to replace the broken Nvidia GTX 460 v2 after a long years of service. It is then my first ever dedicated AMD based video-card for a desktop.

The boot sequence on Fedora 27 hit a problem: a plain blank screen suggesting the card is not yet supported. Looking at Phoronix website revealed one of possible requirement missed: LLVM 5.0 which is currently not available to Fedora repository save a failed built. I filed a bug report to address the issue. Hopefully that will land on time for the official release of Fedora 27.

Running Sapphire Radeon RX 560 on Fedora 27 beta (follow up)

Following the previous blog and some investigation, it turned out the kernel package from Mystro256 COPR repository based on agd5f kernel branch (one of AMD developers) resolves the blank screen issue. That could trigger a problem for users having a new AMD graphic hardware so perhaps a warning should be written on the release. Perhaps having one of contributors be part of kernel team bringing these improvement until those patches arrive to the mainline kernel for a better user experience.

Past the issue, the desktop experience with Radeon RX 560 was tremendously improved compared to the retired GTX 460 v2. Gnome on Wayland on Fedora runs smooth showing how far the open source amdgpu driver went through compared to previous years. That was also the opportunity to run a vulkan based smoke test demo on RADV, which is a counterpart of glxgears.

Overall the card is excellent once missing software are installed.