Linux-kysymyksiä & yleistä keskustelua Linuxista

[JiiPee]

Toiset halveksuu dnf:ää kun se on hidas apt:iin verrattuna.

Tämä vaan ei enää dnf5 myötä pitä paikkaansa.

root@fedora:~# time dnf -y upgrade
Updating and loading repositories:
 Fedora 42 openh264 (From Cisco) - x86_64                                                                                                   100% |   2.3 KiB/s | 989.0   B |  00m00s
 Remi's RPM repository - Fedora 42 - x86_64                                                                                                 100% |   1.3 KiB/s |   4.7 KiB |  00m04s
 Fedora 42 - x86_64 - Updates                                                                                                               100% |  70.3 KiB/s |  23.2 KiB |  00m00s
 Fedora 42 - x86_64                                                                                                                         100% |  66.4 KiB/s |  20.9 KiB |  00m00s
 Remi's Modular repository - Fedora 42 - x86_64                                                                                             100% |  13.3 KiB/s |   5.2 KiB |  00m00s
 RPM Fusion for Fedora 42 - Free                                                                                                            100% |  11.3 KiB/s |   8.8 KiB |  00m01s
 RPM Fusion for Fedora 42 - Free - Updates                                                                                                  100% |  13.0 KiB/s |   8.0 KiB |  00m01s
 RPM Fusion for Fedora 42 - Nonfree - Updates                                                                                               100% |  12.3 KiB/s |   8.2 KiB |  00m01s
 RPM Fusion for Fedora 42 - Nonfree                                                                                                         100% |  14.3 KiB/s |   9.0 KiB |  00m01s
 Remi's RPM repository - Fedora 42 - x86_64                                                                                                 100% | 356.9 KiB/s | 379.7 KiB |  00m01s
 Fedora 42 - x86_64 - Updates                                                                                                               100% |   2.1 MiB/s |   4.8 MiB |  00m02s
 Remi's Modular repository - Fedora 42 - x86_64                                                                                             100% | 147.1 KiB/s | 206.4 KiB |  00m01s
 RPM Fusion for Fedora 42 - Free                                                                                                            100% | 164.4 KiB/s | 175.1 KiB |  00m01s
 RPM Fusion for Fedora 42 - Free - Updates                                                                                                  100% |  19.9 KiB/s |  27.7 KiB |  00m01s
 RPM Fusion for Fedora 42 - Nonfree - Updates                                                                                               100% |  25.3 KiB/s |  26.3 KiB |  00m01s
 RPM Fusion for Fedora 42 - Nonfree                                                                                                         100% |  88.6 KiB/s |  98.8 KiB |  00m01s
Repositories loaded.
Package                                                       Arch         Version                                                     Repository                               Size
Removing:
 kernel                                                       x86_64       6.14.0-63.fc42                                              fedora                                0.0   B
 kernel-core                                                  x86_64       6.14.0-63.fc42                                              fedora                               75.5 MiB
 kernel-devel                                                 x86_64       6.14.0-63.fc42                                              fedora                               78.2 MiB
 kernel-modules                                               x86_64       6.14.0-63.fc42                                              fedora                               64.7 MiB
 kernel-modules-core                                          x86_64       6.14.0-63.fc42                                              fedora                               38.3 MiB
 kernel-modules-extra                                         x86_64       6.14.0-63.fc42                                              fedora                                2.6 MiB
Upgrading:
 akonadi-calendar                                             x86_64       25.04.0-1.fc42                                              updates                               3.7 MiB
   replacing akonadi-calendar                                 x86_64       24.12.3-1.fc42                                              fedora                                3.5 MiB
<-- SNIP -->
 xz-libs                                                      x86_64       1:5.8.1-2.fc42                                              updates                             217.8 KiB
   replacing xz-libs                                          x86_64       1:5.6.3-3.fc42                                              fedora                              218.3 KiB
Installing:
 kernel                                                       x86_64       6.14.4-300.fc42                                             updates                               0.0   B
 kernel-core                                                  x86_64       6.14.4-300.fc42                                             updates                              75.9 MiB
 kernel-devel                                                 x86_64       6.14.4-300.fc42                                             updates                              78.3 MiB
 kernel-modules                                               x86_64       6.14.4-300.fc42                                             updates                              65.1 MiB
 kernel-modules-core                                          x86_64       6.14.4-300.fc42                                             updates                              38.9 MiB
 kernel-modules-extra                                         x86_64       6.14.4-300.fc42                                             updates                               2.6 MiB
Installing dependencies:
 gnome-online-accounts-libs                                   x86_64       3.54.2-5.fc42                                               updates                             734.4 KiB
 libktorrent                                                  x86_64       25.04.0-1.fc42                                              updates                               2.4 MiB
 python3-rapidfuzz                                            x86_64       3.11.0-3.fc42                                               fedora                               11.1 MiB

Transaction Summary:
 Installing:         9 packages
 Upgrading:        543 packages
 Replacing:        543 packages
 Removing:           6 packages

Total size of inbound packages is 1 GiB. Need to download 1 GiB.
After this operation, 58 MiB extra will be used (install 5 GiB, remove 5 GiB).
[  1/552] kernel-core-0:6.14.4-300.fc42.x86_64                                                                                              100% |   4.6 MiB/s |  19.0 MiB |  00m04s
[  2/552] kernel-devel-0:6.14.4-300.fc42.x86_64                                                                                             100% |   4.9 MiB/s |  21.4 MiB |  00m04s
<-- SNIP -->
[551/552] xz-libs-1:5.8.1-2.fc42.x86_64                                                                                                     100% | 543.2 KiB/s | 113.0 KiB |  00m00s
[552/552] xz-devel-1:5.8.1-2.fc42.x86_64                                                                                                    100% | 260.6 KiB/s |  67.0 KiB |  00m00s
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[552/552] Total                                                                                                                             100% |  18.5 MiB/s |   1.5 GiB |  01m22s
Running transaction
[   1/1103] Verify package files                                                                                                            100% | 170.0   B/s | 552.0   B |  00m03s
[   2/1103] Prepare transaction                                                                                                             100% | 616.0   B/s |   1.1 KiB |  00m02s
<-- SNIP -->
[ 551/1103] Upgrading libquadmath-devel-0:15.1.1-1.fc42.x86_64                                                                              100% |   4.6 MiB/s |  23.6 KiB |  00m00s
[ 552/1103] Upgrading gcc-plugin-annobin-0:15.1.1-1.fc42.x86_64                                                                             100% |   2.2 MiB/s |  58.6 KiB |  00m00s
[ 553/1103] Upgrading gcc-gnat-0:15.1.1-1.fc42.x86_64                                                                                       100% | 200.7 MiB/s |  58.8 MiB |  00m00s
[ 554/1103] Upgrading glibc-static-0:2.41-5.fc42.x86_64                                                                                     100% | 229.7 MiB/s |  11.5 MiB |  00m00s
[ 555/1103] Removing libvirt-0:11.0.0-1.fc42.x86_64                                                                                         100% |   7.5 KiB/s | 100.0   B |  00m00s
[ 556/1103] Removing libsane-hpaio-0:3.25.2-1.fc42.x86_64                                                                                   100% | 583.0   B/s |   7.0   B |  00m00s
<-- SNIP -->
[1103/1103] Removing libgcc-0:15.0.1-0.11.fc42.x86_64                                                                                       100% |   0.0   B/s |  11.0   B |  01m11s
Complete!

real    7m44.185s
user    3m0.100s
sys     1m15.480s
root@fedora:~#

reilut 550 pakettia päivitettiin latauksineen päivineen siis vajaassa 8min joka ei mielestäni ole kyllä hidasta. Se on kuitenkin reilut 71 paketti per minuutti vauhtia ja tuollainen yli 550 paketin päivitys ei ole sellainen joka tapahtuu joka päivityskerralla. Kyseessä oli VM joka ollut pois käytöstä useamman viikon.

Vanha python pohjainen dnf oli jokseenkin verkkainen.

 

[TemeV]

Tämä vaan ei enää dnf5 myötä pitä paikkaansa.

Niin joo, tuo pääsikin unohtumaan, että dnf nopeutui. En itse tuota oikein huomaa, kun päivittelen yleensä gui:n kautta. Siellä ne taustalla latailee ja asentuu, enkä jaksa päivystää kaunko se kestää. Tosin KDE:n discover ei taida edes käyttää dnf:ää, vaan packagekittiä, niin en tiedä vaikuttaako tuo päivitys siihen.

 

[keskiverto]

Fedora tarjoaa varsin toimivan päivityksen versiosta toiseen joka tarttee keväällä ja syksyllä tehdä niin en ongelmaa tuossa näe. Jostain 34 versiosta lähtien vaan päivittäny omaa asennusta ja hyvin on aina toiminut.

Eihän sellaista käyttistä ole olemassa joka olisi kaikille pakasta suoraan valmis. Jos joku sellaista kuvittelee niin elää harhoissa.

Fedora version N -> version N+1 on varmaan ongelmaton, kun kaikista asennetuista paketeista löytyy N+1:lle tehdyt versiot.

Siinä vaiheessa kun tarvittava ohjelmistokattaus on tosi kirjava, kauan sitten julkaistuista aktiivisesti kehittyviin, pelkistä binääreistä lähdekoodiversioihin, satunnaisella build-systeemillä tai ihan ilman, ja suurin osa ilman että sille olisi tehty paketteja millekkään distrolle, niin ei todellakaan tee mieli joka vuosi asentaa niitä uudestaan. Siis kaikkea muuta kuin pakasta.

 

[TemeV]

Fedora version N -> version N+1 on varmaan ongelmaton, kun kaikista asennetuista paketeista löytyy N+1:lle tehdyt versiot.

Siinä vaiheessa kun tarvittava ohjelmistokattaus on tosi kirjava, kauan sitten julkaistuista aktiivisesti kehittyviin, pelkistä binääreistä lähdekoodiversioihin, satunnaisella build-systeemillä tai ihan ilman, ja suurin osa ilman että sille olisi tehty paketteja millekkään distrolle, niin ei todellakaan tee mieli joka vuosi asentaa niitä uudestaan. Siis kaikkea muuta kuin pakasta.

Eikös tuollaiset erikoisemmat softat ja konfiguraatiot kannata ajella konteissa tai virtuaalikoneessa. Voi sitä konttia sitten roikuttaa mukana, riippumatta siitä miten päivittää käyttistä.

 

[love_doctor]

Tämä vaan ei enää dnf5 myötä pitä paikkaansa.

Näkemyshän pohjautuu mm. tähän, jonka mukaan DNF oli vertailun hitain. DNF5:n vakiona tarjoava F41 on ollut ulkona noin puoli vuotta, eli ei vielä kovin uusi juttu. Muitakin pakettimanagereita on kehitetty samalla. Esim. Archin Pacman vaikuttaisi nykyään hakevan tehokkaammin paketteja. Pythonia käyttävät ohjelmat ovat nopeutuneet muutenkin 1-2 vuoden sisään, kun pari uusinta Python-versiota kolmoshaarasta sisältävät merkittäviä suorituskykyoptimointeja.

reilut 550 pakettia päivitettiin latauksineen päivineen siis vajaassa 8min joka ei mielestäni ole kyllä hidasta. Se on kuitenkin reilut 71 paketti per minuutti vauhtia ja tuollainen yli 550 paketin päivitys ei ole sellainen joka tapahtuu joka päivityskerralla. Kyseessä oli VM joka ollut pois käytöstä useamman viikon.

Vanha python pohjainen dnf oli jokseenkin verkkainen.

Nämä tulokset eivät ole vertailukelpoisia eri koneilla.

 

[JiiPee]

Näkemyshän pohjautuu mm. tähän, jonka mukaan DNF oli vertailun hitain.

No en ihmettele koska se python pohjainen dnf4 todellakin oli hidas, joskus jopa ärsyttävän hidas. Sellasta fiilistä ei ole enää ollut dnf5 kanssa.

Ja sitten pitää toki aina muistaa että dnf5 ei tule koskaan olemaan nopeimpien paketti kikottimien tasolla koska dnf tarjoaa niin valtavasti metadataa joka jarruttaa menoa mutta tarjoaa toisaalta sitten sellaisia hyötyjä joita ne nopeammat eivät kykyne tarjoamaan.

Nämä tulokset eivät ole vertailukelpoisia eri koneilla.

No en tainnu missään sellaista edes väittää vaan heitin tuon esimerkkinä josta jokainen voi itte miettiä että onko tuo hidasta.

time dnf -y install ack
Updating and loading repositories:
Repositories loaded.
Package                                                      Arch          Version                                                       Repository                             Size
Installing:
 ack                                                         noarch        3.7.0-7.fc42                                                  fedora                            214.1 KiB
Installing dependencies:
 perl-File-Next                                              noarch        1.18-18.fc42                                                  fedora                             28.5 KiB

Transaction Summary:
 Installing:         2 packages

Total size of inbound packages is 109 KiB. Need to download 109 KiB.
After this operation, 243 KiB extra will be used (install 243 KiB, remove 0 B).
[1/2] perl-File-Next-0:1.18-18.fc42.noarch                                                                                                  100% | 133.3 KiB/s |  21.5 KiB |  00m00s
[2/2] ack-0:3.7.0-7.fc42.noarch                                                                                                             100% | 425.5 KiB/s |  87.6 KiB |  00m00s
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[2/2] Total                                                                                                                                 100% | 193.8 KiB/s | 109.1 KiB |  00m01s
Running transaction
[1/4] Verify package files                                                                                                                  100% |   2.0 KiB/s |   2.0   B |  00m00s
[2/4] Prepare transaction                                                                                                                   100% |   3.0   B/s |   2.0   B |  00m01s
[3/4] Installing perl-File-Next-0:1.18-18.fc42.noarch                                                                                       100% |  20.5 KiB/s |  29.5 KiB |  00m01s
[4/4] Installing ack-0:3.7.0-7.fc42.noarch                                                                                                  100% | 215.8 KiB/s | 219.1 KiB |  00m01s
Complete!

real    0m6.140s
user    0m2.982s
sys     0m1.646s

Tuossa nyt "just for lulz" tuosta mun kakkoskoneelta jossa rysen 7 1800X eli ei lähellekkään 9900K:n veroinen single core tehoissa jota tuossa pääasiassa tarttetaan ja meikän netti on 200M 4G eli ei gigaisen kuidun veroinen.

dnf4 25sec vs dnf5 6sec niin onhan tuossa nyt aika valtava kehitys tapahtunut.

qemu testiä en voi tehdä kun se on jo asennettuna ja käytössä koneessa.

 

[love_doctor]

No en tainnu missään sellaista edes väittää vaan heitin tuon esimerkkinä josta jokainen voi itte miettiä että onko tuo hidasta.

Eihän sitä pysty päättelemään kun koneiden nopeudet vaihtelevat samaa luokkaa kuin pakettimanagerien. Puhun hitaudesta tässä suhteellisessa mielessä. Joidenkin parin kilotavun leluohjelmien tapauksessa kaikki managerit ovat aika lailla nopeita kaikilla koneilla.

time dnf -y install ack

real    0m6.140s
user    0m2.982s
sys     0m1.646s

Tuossa nyt "just for lulz" tuosta mun kakkoskoneelta jossa rysen 7 1800X eli ei lähellekkään 9900K:n veroinen single core tehoissa jota tuossa pääasiassa tarttetaan ja meikän netti on 200M 4G eli ei gigaisen kuidun veroinen.

dnf4 25sec vs dnf5 6sec niin onhan tuossa nyt aika valtava kehitys tapahtunut.

qemu testiä en voi tehdä kun se on jo asennettuna ja käytössä koneessa.

Tuokin on huono testi, kun esim. Arch Linuxissa ack ei kuulu vakio- tai testing-paketteihin vaan pitää kääntää lähdekoodista. Jos haluat verrata distrojen välillä, niin joku esim. suosituimmasta 500 paketista toimii paljon paremmin. Ehkä sellainen operaatio, joka testaa myös riippuvuuksia ja useita paketteja. Debianissa popcontestin mukaan 'ack' on sijalla 10 408 eli monella alle 10 000 pakettia asentaneella puuttuu kokonaan. Esim. minulla on asennettuna vain reilu 2000 pakettia ja koneella tehdään kuitenkin kaikenlaista.

Kokeilin hyperfinellä kellottaa noiden kahden asennuksen. Archilla 5950X:llä:

Benchmark 1: pacman -U --noconfirm ack-3.8.2-1-any.pkg.tar.zst perl-file-next-1.18-7-any.pkg.tar.zst
Time (mean ± σ): 249.0 ms ± 1.9 ms [User: 151.3 ms, System: 99.5 ms]
Range (min … max): 246.0 ms … 251.8 ms 11 runs

Eli 0,25 sekuntia. Arch noin 25 kertaa nopeampi tässä.

 

[Barbarossa]

Kuinka usein niitä paketteja pitää vatkata että paketinhallinnan nopeus muodostuu jotenkin merkitykselliseksi asiaksi distron valitsemisen kannalta? Vai muuten vaan mittaillaan vehkeitä että mun distro asentaa tämänkin paketin nopeammin kuin sun?

Nimim. reilu pari sataa pakettia tuli viimeksi päivityksessä, otti n. kolme vuorokautta tuliterällä Ivy Bridge läppärillä. Varmasti jopa dnf4 olisi suoriutunut minuuteissa mutta en silti ole siihen Fedoraa laittamassa.

 

[Hyrava]

Kuinka usein niitä paketteja pitää vatkata että paketinhallinnan nopeus muodostuu jotenkin merkitykselliseksi asiaksi distron valitsemisen kannalta? Vai muuten vaan mittaillaan vehkeitä että mun distro asentaa tämänkin paketin nopeammin kuin sun?

Nimim. reilu pari sataa pakettia tuli viimeksi päivityksessä, otti n. kolme vuorokautta tuliterällä Ivy Bridge läppärillä. Varmasti jopa dnf4 olisi suoriutunut minuuteissa mutta en silti ole siihen Fedoraa laittamassa.

Niinpä, itselläni ei ainakaan ole niin väliä kestääkö pakettien asentumiseen minuutti vai viisi, yleensä ei ole niin hoppu mihinkään.

Viime viikonloppunakin kun päivittelin yhden hupiläppärin taas ajantasalle kun konetta ei oltu käytetty pariin kuukauteen niin laitoin vain apt upgrade ja lähdin keittelemään kahvia. Kun kahvi oli valmis niin päivitykset olivat silläaikaa asentuneet.

Samoin kun omia virtuaalikoneita päivittelen niin avaan terminaalin, laitan päivitykset menemään ensimmäiseen, avaan toisen terminaalin ja laitan seuraavaan pannuun päivitykset jne. Sitten kun ensimmäisessä terminaalissa on valmista niin laitan siihen seuraavan koneen päivittymään jos vielä on päivittämättömiä. Siellä ne päivitykset itsekseen asentuvat, en mä niitä kovin tarkkaan ole jäänyt tuijottamaan ja odottamaan.

Toki jos ero olisi luokkaa toisella kestää minuutin ja toisella tunnin niin tuolla olisikin jo jotain väliä. Mieluummin silti valitsen distron jollain muulla perusteella kuin paketinhallinnan nopeudella.

 

[love_doctor]

Kuinka usein niitä paketteja pitää vatkata että paketinhallinnan nopeus muodostuu jotenkin merkitykselliseksi asiaksi distron valitsemisen kannalta? Vai muuten vaan mittaillaan vehkeitä että mun distro asentaa tämänkin paketin nopeammin kuin sun?

Nimim. reilu pari sataa pakettia tuli viimeksi päivityksessä, otti n. kolme vuorokautta tuliterällä Ivy Bridge läppärillä. Varmasti jopa dnf4 olisi suoriutunut minuuteissa mutta en silti ole siihen Fedoraa laittamassa.

Omassa kotikäytössä noin 20 vuotta sitten Gentoolla oli merkitystä optimoinneilla, kun koko systeemin kääntäminen kesti muistaakseni pari päivää. Portagesta tuli c:llä tehty versio, joka nopeutti tunteja. Myös pakettitietokannan sijoittaminen oikeanlaiselle levylle nopeutti huomattavasti. CI-putkessa virtuaalikoneiden rakentamisessa on myös iso merkitys, kestääkö koko distron kasaus vartin vai monta tuntia.

 

[Barbarossa]

Omassa kotikäytössä noin 20 vuotta sitten Gentoolla oli merkitystä optimoinneilla, kun koko systeemin kääntäminen kesti muistaakseni pari päivää. Portagesta tuli c:llä tehty versio, joka nopeutti tunteja. Myös pakettitietokannan sijoittaminen oikeanlaiselle levylle nopeutti huomattavasti. CI-putkessa virtuaalikoneiden rakentamisessa on myös iso merkitys, kestääkö koko distron kasaus vartin vai monta tuntia.

Joskus menneinä aikoina Portage rouskutteli hyvän aikaa ennenkuin mitään alkoi tapahtua ja pakettien tauhkatkin piti hakea erikseen ennenkuin pistettiin ramppa kalkattamaan. Siitä huolimatta nuo vaihtoehtoiset toteutukset eivät ole juuri muuta kuin sivumaininta historiassa, jos sitäkään.

Alun dependencyjen resolvaamisen ja buildijärjestyksen hiomisen jälkeen Portagelle jää suht vähän tekemistä, fetch pyörii taustalla taustalla samalla kun paketit kääntyy eikä tuotosten siirtäminen hiekkalaatikolta järjestelmään kovin raskasta ole. Python-toteutus ei ole vuosikausiin ollut pullonkaulana näissä, itse kääntämiseen Portagen nyplääminen ei oikein auta ja siihen se aika tuppaa palamaan.


Kaikissa CI/pilvihommissa ei ole sitä luksusta että käytettävä distro on valittavissa, silloin se ottaa minkä ottaa. Tähänkin tarpeeseen Fedorallakin oli minidnf erikseen, jotkut hätäisemmät kai sitä käytti työpöytäasennuksiinkin.

 

[JiiPee]

Eihän sitä pysty päättelemään kun koneiden nopeudet vaihtelevat samaa luokkaa kuin pakettimanagerien. Puhun hitaudesta tässä suhteellisessa mielessä. Joidenkin parin kilotavun leluohjelmien tapauksessa kaikki managerit ovat aika lailla nopeita kaikilla koneilla.

No eihän se nyt ole ollenkaan näin. Paketti manageri joka tsekkaa riippuuvuuksia on aina moninkerroin hitaampi kuin sellainen joka ei tsekkaa oikeastaan mitään vaan asentaa paketin joka sille käsketään asentamaan.
Ja varsinkin jonkun tollaisen hyvin pienen paketin kohdalla se tilanne on että SUURIN OSA ajasta vietetään siellä metadataa kolutessa. Joku 500 pakettia kun asennetaan niin se metadata kolutaan kerran jonka jälkeen vaan asennetaan jolloin suhteellinen nopeus on moninkertainen verrattuna siihen että ne samat 500 pakettia asennettaisiin yksi kerrallaan joka ikinen kerta metadata tsekaten.

Tuokin on huono testi, kun esim. Arch Linuxissa ack ei kuulu vakio- tai testing-paketteihin vaan pitää kääntää lähdekoodista.

No itsehän sinä tuon testin toit mukaan keskusteluun. Jos se on huono, niin miksi sen sitten sotkit tähän? Ja minä kuitenkin sinulle kerroin että testin tein selvästi HEIKOMMALLA koneella mitä orkkis testi oli tehty ja vertasin dnf4 <-> dnf5. EN ottanut mitään kantaa siihen että miten vertautuu vaikka apt.

Jos haluat verrata distrojen välillä, niin joku esim. suosituimmasta 500 paketista toimii paljon paremmin.

Ei mulla ole tarvista vertailla distrojen välillä kun tiedän että loppupelissä esim. dnf:n ja apt:n välillä ei isommassa kuvassa ole niin merkittävää eroa nopeudessa että se alkaisi omaan valintaan vaikuttamaan. Sanonut jo aiemmin mutta sanotaan nyt kerran vielä: python aikainen dnf4 oli jossain tilanteissa jopa häiritsevän hidas. HUOM jossain tilanteissa.

Eli 0,25 sekuntia. Arch noin 25 kertaa nopeampi tässä.

Huoh... on kait se kun vertaat omenoita mansikoihin. dnf tekee aika helvetin paljon muutakin kuin purkaa locaalin paketin joka tuossa sun esiamerkissä noin karkeasti tapahtui.
Lisäksi dnf EI varsinaisesti ole se joka tekee esim. fedorassa työn konepellin alla, vaan se dnf ohjaa rpm:ää joka lopulta asennuksen tekee. dnf automatisoi riippuvuuksien tarkistuksen ja pakettien latauksen.

Mulla oli aikoinaan fedorassa kolme eri paketinhallintaa käytössä: yum, apt ja smart. Noista smart oli ylivoimaisesti paras, kaikki kuitenkin loppupelissä käytti rpm:ää.

time rpm -U --noverify --nodeps ack-3.7.0-7.fc42.noarch.rpm

real    0m1.447s
user    0m1.109s
sys     0m0.232s

Toi vois olla aika lähellä tuota sun juttuas. Tuossa siis ack ladattu ensin ja sitten asennus suoraan rpm:llä.

Kuinka usein niitä paketteja pitää vatkata että paketinhallinnan nopeus muodostuu jotenkin merkitykselliseksi asiaksi distron valitsemisen kannalta? Vai muuten vaan mittaillaan vehkeitä että mun distro asentaa tämänkin paketin nopeammin kuin sun?

Tätä itsekin ihmettelen. Halusin vain oikoa sitä harhaluuloa että dnf olisi edelleen susihidas jota se ei ole enää.


EDIT: Lisätään nyt vielä se että kannattaa ihan omassa mielessä miettiä että miksi joku paketinhallinta vie ernemmän aikaa kuin toinen ja miksi x distron saa helposti solmuun kun taas distroa y ei saa rikki millään.
Vihjeenä: kannattaa miettiä miten niitä riippuvuuksia käsitellään, jos edes käsitellän.

 

[Eore]

hieman hymyilyttää aikaisempi sarkastinen esimerkki internetin linux ”apt/dnf paras/paskaa” -keskustelusta. Täällähän se on menossa ihan livenä nyt Löytyi vielä se pakollinen gentoo-mieskin mukaan. Pakettien asennuksen keston vertailusta voidaankin siirtyä vertailemaan uptimejä niin selviää kuka on kovin nörtti.
Ajattelin viikonloppuna testailla cachyOS, jos tuon kanssa selviäsi ongelmitta.

 

[love_doctor]

Joskus menneinä aikoina Portage rouskutteli hyvän aikaa ennenkuin mitään alkoi tapahtua ja pakettien tauhkatkin piti hakea erikseen ennenkuin pistettiin ramppa kalkattamaan. Siitä huolimatta nuo vaihtoehtoiset toteutukset eivät ole juuri muuta kuin sivumaininta historiassa, jos sitäkään.

Muistelen, että silloin Portage ei osannut ainakaan vakiona hakea taustalla vaan piti käynnistää toinen instanssi hakemaan paketit ilman kääntämistä. Tuolla oli iso vaikutus hitaalla yhteydellä jos paketteja ei ollut ladannut ennakkoon ja käänsi koko systeemin. Configure cachella oli myös iso vaikutus, maken optimaalinen rinnakkaisuus oli jotain nprocin ja 2*nprocin välillä (jos omisti tuplaytimen / p4 ht:llä). Muistaakseni ebuildien säilöminen fragmentoitumattomaan reiser3-voluumiin myös säästi selvästi aikaa. Emergen c-porttaus oli myös selvästi nopeampi (en muista nyt nimeä). Sittemmin Gentoon riippuvuuksien hallinta on minusta monimutkaistunut. Toisaalta Python nopeutunut.

Alun dependencyjen resolvaamisen ja buildijärjestyksen hiomisen jälkeen Portagelle jää suht vähän tekemistä, fetch pyörii taustalla taustalla samalla kun paketit kääntyy eikä tuotosten siirtäminen hiekkalaatikolta järjestelmään kovin raskasta ole. Python-toteutus ei ole vuosikausiin ollut pullonkaulana näissä, itse kääntämiseen Portagen nyplääminen ei oikein auta ja siihen se aika tuppaa palamaan.

On sillä se merkitys, että joka paketin välissä perusjauhaminen voi kestää vaikka sekunnin tai kaksi kauemmin (*) ja sitä kautta esim. 3000 paketin tapauksessa voi tulla tunti lisäaikaa. Mutta siis aika ääritapauksesta on kyse. Toki noissa rolling-distroissa helposti tulee paljon asennettavaa, jos on hetken aikaa päivittämättä.

(*) jälleen esimerkki 20 vuoden takaa. Nyt Python + uusi kone voi toimia nopeammin.

No eihän se nyt ole ollenkaan näin. Paketti manageri joka tsekkaa riippuuvuuksia on aina moninkerroin hitaampi kuin sellainen joka ei tsekkaa oikeastaan mitään vaan asentaa paketin joka sille käsketään asentamaan.

Pacman katsoo kyllä aina että riippuvuudet löytyvät. Siinä on vaan paljon kevyempi tuo metadata, niin menee paljon nopeammin. En sano että tämä on parempi asia, mutta nopeampi takuulla.

Joku 500 pakettia kun asennetaan niin se metadata kolutaan kerran jonka jälkeen vaan asennetaan jolloin suhteellinen nopeus on moninkertainen verrattuna siihen että ne samat 500 pakettia asennettaisiin yksi kerrallaan joka ikinen kerta metadata tsekaten.

Jos paketinhallinnassa on mallinnettu monimutkaisia versioriippuvuuksia esim. epäyhtälöillä tai use-flageja, niin tuosta tulee monella paketilla matemaattisesti paljon hankalampi ongelma, kun pitää löytää sellainen kombo paketteja, joka suostuu asentumaan ja mahdollisesti pakittaa ja etsiä uusi kombo vipuja, joilla kääntyy.

No itsehän sinä tuon testin toit mukaan keskusteluun. Jos se on huono, niin miksi sen sitten sotkit tähän? Ja minä kuitenkin sinulle kerroin että testin tein selvästi HEIKOMMALLA koneella mitä orkkis testi oli tehty ja vertasin dnf4 <-> dnf5. EN ottanut mitään kantaa siihen että miten vertautuu vaikka apt.

Se on huono esimerkki, mutta artikkelin tekijä oli tehnyt kotiläksyt ja verrannut itse ja julkaissut datan. Jos 2019 kesti Fedoralla 25 sekuntia ja nyt sinulla reilu 6 sekuntia, niin on ihan mahdoton tietää, johtuuko se koneiden nopeutumisesta vai pakettimanagerin. Tarkoitan vaan että tuo yksi datapiste ei auta.

Huoh... on kait se kun vertaat omenoita mansikoihin. dnf tekee aika helvetin paljon muutakin kuin purkaa locaalin paketin joka tuossa sun esiamerkissä noin karkeasti tapahtui.

Ymmärrätkö etten pysty tekemään vastaavaa esimerkkiä perustamatta omaa pacman-mirroria, kun ko. pakettia ei saa ilman manuaalista kääntämistä asennettua ko. distroon? Tuossa kääntämisessä menee täällä 35 sekuntia. Koitin jo sanoa, että tuo on todella huono esimerkki, kun se pakottaa yhden suosituimmista distroista kääntämään paketin virallisten repojen ulkopuolelta. Tässä olisi nopeasti helppo listata vaikka 2000 muuta pakettia, jotka löytyvät top10 distroista vakiona.

time rpm -U --noverify --nodeps ack-3.7.0-7.fc42.noarch.rpm

real    0m1.447s
user    0m1.109s
sys     0m0.232s

Toi vois olla aika lähellä tuota sun juttuas. Tuossa siis ack ladattu ensin ja sitten asennus suoraan rpm:llä.

Kun ei ole. Pacman ei asenna edes lokaalisti paketteja, jos riippuvuudet menevät rikki. Jos riippuvuudet löytyvät netistä, niin se tarjoutuu asentamaan, mutta jos ei löydy (esim. AUR-paketti), niin asennus epäonnistuu. Asennus myös vertaa esim. tiedostolistoja ja tietenkin paketin integriteetin ongelma voidaan huomata. Otan nyt tuon esimerkin ajon tilanteessa, kun perl-file-next puuttuu:

$ sudo pacman -U ack-3.8.2-1-any.pkg.tar.zst
ladataan paketteja...
selvitetään riippuvuuksia...
varoitus: pakettia 'perl-file-next' ei voida selvittää; se on paketin 'ack' riippuvuus
:: Seuraavaa pakettia ei voida päivittää selvittämättömien riippuvuuksien vuoksi:
      ack
:: Haluatko ohittaa yllä olevan paketin päivittämisen? [k/E]

edit: Se mitä tuossa jää pois on sha256-summien tarkistus. Senkin voi erikseen tehdä käskyllä 'paccheck --sha256sum' asennetuille paketeille. En nyt heti löytänyt, saisiko sen -U -käskyllä vakiona päälle. Tässä omalla koneella tuon ack-paketin osalta sen sha256-tarkistus kestää 0,012s eli tuo yhteisaika kasvaa noin 260 millisekuntiin. Testasin myös ihan huvikseni lisäämällä/poistamalla manuaalisesti paketista tiedostoja ja tämä tuli esiin asennettaessa. Paccheck huomasi kun korruptoin paketin binäärin.

 

[keskiverto]

Eikös tuollaiset erikoisemmat softat ja konfiguraatiot kannata ajella konteissa tai virtuaalikoneessa. Voi sitä konttia sitten roikuttaa mukana, riippumatta siitä miten päivittää käyttistä.

Jos niitä ei ole kontteina, varsinkaan apptainer/podman-versioina, joita tavallisetkin käyttäjät saavat ajaa?

 

[Barbarossa]

Jos niitä ei ole kontteina, varsinkaan apptainer/podman-versioina, joita tavallisetkin käyttäjät saavat ajaa?

Tekee sellaisen? Ainakaan minua ei kiinnosta tippaakaan paskoa järjestelmää satunnaisella irtoroinalla, jos jonkun kikkulan käytöltä en voi välttyä enkä sitä saa paketinhallinnan piirin edes esim. itse kasatuilla paketeilla niin sitten kasaan sille kontin, chroot ympäristön tai jotakin muuta vastaavaa hiekkalaatikoksi.

 

[Ezzy]

21-Way Intel Core / AMD Ryzen Linux Laptop Comparison On Ubuntu 25.04 Review - Phoronix

www.phoronix.com