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

 

[freelancer85]

Mites sais grub kakosen näkymään ulkoisessa näytössä suoraan kun käynnistää koneen. Kyseessä siis läppäri josta menee ulkoiseen näyttöön kuva hdmi piuhan kautta.

 

[Mukava]

Mites sais grub kakosen näkymään ulkoisessa näytössä suoraan kun käynnistää koneen. Kyseessä siis läppäri josta menee ulkoiseen näyttöön kuva hdmi piuhan kautta.

Millainen kone? Ainakin uudehkoilla AMD-koneilla taitaa olla niin ettei tuo ole tuettu, näin ainakin muistelen AMD:n linux ingenjöörin jossain Framework ketjussa todenneen.

 

[ississ]

Mites sais grub kakosen näkymään ulkoisessa näytössä suoraan kun käynnistää koneen. Kyseessä siis läppäri josta menee ulkoiseen näyttöön kuva hdmi piuhan kautta.

Riippuu koneesta, työ-dell ei näytä mitään missään ulkoisessa ennen kuin käyttis on valmis... tämä w11.
Jos bios-asetus löytyy tuolle niin saattaa saada toimimaan tai ei

 

[JiiPee]

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.

Miten sä ajattelit että vuoden 2017 rauta olisi nopeutunut vuonna 2025? Minähän kerroin että ajoin tuon Ryzen 7 1800X:llä joka on teholtaan selvästi jälessä tuota Intel 9900K jolla testit oli ajettu. 9900K julkaistu 2018 noiden kahden välillä about 1,5v eroa. Ja varsinkin single core tehossa jota tuossa pääasiassa tarvitaan on aika suuri ero.

 

[love_doctor]

Miten sä ajattelit että vuoden 2017 rauta olisi nopeutunut vuonna 2025? Minähän kerroin että ajoin tuon Ryzen 7 1800X:llä joka on teholtaan selvästi jälessä tuota Intel 9900K jolla testit oli ajettu. 9900K julkaistu 2018 noiden kahden välillä about 1,5v eroa. Ja varsinkin single core tehossa jota tuossa pääasiassa tarvitaan on aika suuri ero.

Tuossa välissä on tullut mm. spectre/metldown-mitigaatioita ja erilaisia kernelioptimointeja. Pakettien asentamisessa myös levy vaikuttaa jne., Tuskin kovin isoista eroista puhutaan, mutta nuo liikkuvat parametrit tekevät summittaiset vertailut aika turhiksi varsinkin jos kyse jostain < 6 sekunnin testistä. Tästä voi jatkaa jossain muualla - ihmettelen vaan, miten isolla tarmolla olet valmis puolustamaan ihan persiilleen tehtyä vertailua. Asia olisi paljon helpompi korjata ihan vaan testaamalla joku järkevämpi paketti.

 

[Eore]

Sampsakin laitttanut Linuxit tulille. Plug n play lähti pelit pyöriin. Not.

 

[Ezzy]

Aika evo saa olla ettei lähde toimimaan... Hyvä video kyllä muuten Tais mennä se ajuri takas noveauksi vahingossa järjestelmän päivityksen yhteydessä.

 

[Kaalip]

Sampsakin laitttanut Linuxit tulille. Plug n play lähti pelit pyöriin. Not.

Sinänsä hyvä video että sai ajattelemaan oman kuplan ulkopuolelta, en aikaisemmin tajunnutkaan että linuxin ja vieläpä mintin asentaminen voisi olla jollekulle noin vaikeaa.

 

[Hyrava]

Sinänsä hyvä video että sai ajattelemaan oman kuplan ulkopuolelta, en aikaisemmin tajunnutkaan että linuxin ja vieläpä mintin asentaminen voisi olla jollekulle noin vaikeaa.

Tuossa oli kyllä suuri osa sillä että asennusohjeessa ei ollut mainitaa tuosta "Enroll MOK" -jutusta eikä installerikaan siitä huomauttanut. Esimerkiksi Xubuntun installeri aikanaan itselläni huomautti lopuksi että bootin yhteydessä pitää syöttää Machine Owner Key jos SecureBoot on käytössä. Pelkästään tuolla olisi ratkennut esim tuo näyttisajuriongelma. Muutenkin tuntui että Sampsa ei oikein jaksanut keskittyä hommaan eikä oikein ajatuksella lukenut installerin tekstejä ja muutenkin oli ihan liikaa vauhtia päällä jos kerran "ensikertalaisena" ollaan asentamassa.

 

[Mizwita]

Sinänsä hyvä video että sai ajattelemaan oman kuplan ulkopuolelta, en aikaisemmin tajunnutkaan että linuxin ja vieläpä mintin asentaminen voisi olla jollekulle noin vaikeaa.

Jep! Periaatteessa Linuxin asentaminen tai käyttäminen ei ole lainkaan vaikeaa, mutta suurella osalla ei ole minkäänlaista kosketuspintaa muuhun kuin Windowsiin. Eli täähän oli oikein loistava video, kuvaa hyvin mihin sudenkuoppiin edelleen keskiverto pulliainen joutuu, kun linkkaria asentelee. Ei hyvä.

 

[Ezzy]

Jep! Periaatteessa Linuxin asentaminen tai käyttäminen ei ole lainkaan vaikeaa, mutta suurella osalla ei ole minkäänlaista kosketuspintaa muuhun kuin Windowsiin. Eli täähän oli oikein loistava video, kuvaa hyvin mihin sudenkuoppiin edelleen keskiverto pulliainen joutuu, kun linkkaria asentelee. Ei hyvä.

Jep. Ei noissa sais olla mitään mahdollisuuksia valita jotain muuta kuin käskettyä ja ohjeiden pitää olla selkeät. Toi welcome-ruutu on monissa tosi mainio uudistus.
ZorinOS:n installeri oli hyvä esimerkki smoothista ja se oli positiivinen ylläri. Muistaakseni Nobarassakaan ei ollut mitään ihmeellisyyksiä. Edellisestä asennuksesta on vaan hetki, niin ei muista.

 

[JiiPee]

Tuossa välissä on tullut mm. spectre/metldown-mitigaatioita ja erilaisia kernelioptimointeja. Pakettien asentamisessa myös levy vaikuttaa jne., Tuskin kovin isoista eroista puhutaan, mutta nuo liikkuvat parametrit tekevät summittaiset vertailut aika turhiksi varsinkin jos kyse jostain < 6 sekunnin testistä. Tästä voi jatkaa jossain muualla - ihmettelen vaan, miten isolla tarmolla olet valmis puolustamaan ihan persiilleen tehtyä vertailua. Asia olisi paljon helpompi korjata ihan vaan testaamalla joku järkevämpi paketti.

Koska sulla tuntuu olevan jotenkin hirveä tarve vähätellä sitä faktaa että natiivi c++ ohjelma on selvästi nopeampi kuin joku python purkka. Jos c++ käytöstä ei olisi mitään hyötyä niin kaikki ohjelmat pyörisi jollain purkalla.

 

[Mizwita]

Jep. Ei noissa sais olla mitään mahdollisuuksia valita jotain muuta kuin käskettyä ja ohjeiden pitää olla selkeät. Toi welcome-ruutu on monissa tosi mainio uudistus.
ZorinOS:n installeri oli hyvä esimerkki smoothista ja se oli positiivinen ylläri. Muistaakseni Nobarassakaan ei ollut mitään ihmeellisyyksiä. Edellisestä asennuksesta on vaan hetki, niin ei muista.

Zorin on kyllä hoitanut hommat hyvin, Sampsa vois ottaa revanssin jollain videolla siitä ja joku Fedorapohjainen, vaikka just Nobara. Yleisesti näiden distrojen fokus saisi olla vielä enemmän käyttäjäystävällinen kokemus, koska muuten massat ei sitä käytä, kynnys asennukselle on muutenkin jo korkealla. Onhan tässä vuosien varrella kuitenkin jo hyvää kehitystä tapahtunut, mutta nyt olis hyvä rako saada lisää käyttäjiä kun Windows kusee omiin muroihin minkä kerkeää. Se vaan ei tapahdu, jos suurin osa kohtaa ton videon kaltaisia vastoinkäymisiä.

 

[Admiral General Aladeen]

"Väärällä" näytönohjaimella saa kyllä uskomatonta murhetta aikaiseksi. Ei ole pitkä aika kun itse nVidian kortilla kokeilin Linuxia, oli ainakin Kubuntu ja Zorin, jos oikein muistan. Uskomatonta mitä paskaa, olikohan niin että Zorin ei bootannut kuin mustaan ruutuun tai jotain muuta yhtä simppeliä. Kubuntu kyllä lähti käyntiin, mutta rajua kaatuilua jatkuvasti kun yhtään rasitti.

Sitten kun rauta on yhteensopivaa, niin Linukka onkin kaikkein helpoin käyttis (siis ainakin peruskäyttöön), ei tarvii stressata asennuksia, kun kaikki tulee valmiina. Windowisissa kun pitää asennella vaikka mitä ajureita ja valmistajan omat turhakkeet, jotta edes saa pikanäppäimet toimimaan, niin Linux useimmiten toimii suoraan kertalaakista, ja löytyy valmiina Firefox, Office, Gimp jne. yleisimmin käytettyjä ohjelmia

 

[Hyrava]

Zorin on kyllä hoitanut hommat hyvin, Sampsa vois ottaa revanssin jollain videolla siitä ja joku Fedorapohjainen, vaikka just Nobara. Yleisesti näiden distrojen fokus saisi olla vielä enemmän käyttäjäystävällinen kokemus, koska muuten massat ei sitä käytä, kynnys asennukselle on muutenkin jo korkealla. Onhan tässä vuosien varrella kuitenkin jo hyvää kehitystä tapahtunut, mutta nyt olis hyvä rako saada lisää käyttäjiä kun Windows kusee omiin muroihin minkä kerkeää. Se vaan ei tapahdu, jos suurin osa kohtaa ton videon kaltaisia vastoinkäymisiä.

Onhan tuo linuxin asentaminen helpottunut ihan pirusti jostakin noin 25v takaisesta kun ensimmäisiä kertoja linuxia kokeilin. Silloin asennus taisi olla kokonaan tekstitilassa ja asennusohjelma kyseli melkoisen kryptisiä asioita ilman minkäänlaisia selitteitä. Asennuksen jälkeenkään ei automaattisesti menty graafiseen tilaan vaan piti ensin kirjautua tekstitilassa ja käynnistää ikkunointiympäristö käsin.

Nykyään aika monessa jakelussa on ihan kohtalaisen selkeä ja opastava installeri joka suunnilleen kysyy basic-asetuksilla vain käyttäjänimen, salasanan ja minne asennetaan, ellei sitten itse halua hienosäätää asennusta. Toki edelleen on tuollaisia pieniä juttuja mitä tuossa Sampsan videollakin tuli vastaan joista voisi tehdä entistä selkeämpiä. Ja tietty jotkut ihan uudet laitteet (esim näytönohjaimet) eivät välttämättä ole oikein yhteensopivia, joskus kestää pitkäänkin että tulee kunnolliset ajurit. Tuo tietty on aika pitkälti valmistajista kiinni, jotkut valmistajat eivät oikein tunnu tukevan muita käyttiksiä kuin uusinta windowsia. Tai vastaavasti niinkuin itselläni, edellisessä tulostimessa loppui tuki olikohan Win7:n kohdalla eikä meinannut uudempiin saada millään toimimaan. Linuxeilla taas oli ihan plug'n'play (siihen asti kunnes tulostin lopullisesti hajosi).

 

[Ezzy]

Joskus 2006 tuli testattua kans about kaikkia ubuntuja ja oikeen mikään ei edes asentunut Rauta tais olla Nvidiaa tuolloin.

 

[bindi]

Hyvin asentui Ubuntu 6.06 A64 3000+ nvidia 6600 GT combolle, muistan että WoW pyöri paremmin Winellä kuin Windowsilla, koska OpenGL renderer. Olikohan luokkaa 100fps jos en väärin muista. Mutta siinä ei ollut hardware cursoria, niin kaikki pienetkin fps-dipit tuntuivat tosi ärsyttäviltä, ja yleisesti ottaen pelikokemus oli huonompi. Kyllä sitä silti pelasi. 12v jonneksi ihan hyvä saavutus, imo Apua kyllä sain silloiselta runescape-claanin linux-hörhöiltä :--D

 

[Mukava]

Eipä ole kyllä hirveästi tullut nvidian kanssa asennusongelmia kun auttanut muutamia asentamaan esim Bazziten. Tukee suoraan myös secure bootia, tosin pitää sen verran lukea ohjeita että tietää sen MOKn salasanan kun se sitä asennuksen jälkeisessä bootissa pyytää eli sen verran pitää asennusohjeita lukaista.

Lataa vain nvidia imagen ja asennuksen jälkeen kaikki on ns valmista ja pääsee suoraan pelailemaan Steamissa.

 

[dragon age]

Sampsalla asennus sujui tuosta vain. Itse kun yritin niin aluksi piti valita minkä Linux version valitsee, sitten kun valitsi Mintin, niin löytyi download torrent, mutta alapuolella luki, että kuka vain voi tuottaa feikkejä ISO levykuvia ja sitten luki jotain shasummia ja 256gpg ja jotain, että paikallisesti tallentaa ja sitten vielä tarkistaa tiedostot. Jotenkin lataaminen sitten lopulta onnistui, enää ei muista miten.

Toisaalta ei se Win 11 asennus sen yksinkertaisempaa ole, ensin löytyy Win 11 asennusavustaja ja sen alapuolella lukee ennen kuin ryhdyt käyttämään asennusavustajaa ja sen alapuolella lukee Win 11 asennustietovälineen luonti ja sen alapuolella lukee ennen kuin ryhdyt käyttämään tietovälineen luontityökalua ja sen alapuolella lukee lataa Win 11 näköistiedosto jne. jne.

 

[Barbarossa]

Onhan se ikävää mutta ei varsinaisesti yllättävää, että open sourcea (ja myös asiakastaan) vihaavan rautavalmistajan tuotosten kanssa on ongelmia mutta ne pääsääntöisesti eivät ole "Linux"-ongelmia vaan Nvidia-ongelmia.


Mitä Secure Bootiin tulee, niin itse pitänyt parempana, joskin ehkä hiukan monimutkaisempana, lähestymistapana korvata valmistajan PK omalla avaimella, ja laittaa omat KEK ja allekirjoitusavaimet. Jos haluaa dual boottailla Secure Boot käytössä niin voi myös yhdistää olemassaolevat KEK ja db(x) listat näihin jolloin MS allekirjoitus- ja varmennusavaimet löytyvät ja Windowskin pysyy tyytyväisenä.

Mutta tällä tavoin ei uusia avaimia pysty ujuttamaan keittiön oven kautta ja Secure Boot muuttuu enemmän nimensä veroiseksi. Ja jos aikeissa on katkaista kaikki kahleet niin kaikki kolmannen osapuolen avaimet voi jättää pois jolloin kone boottaa ainoastaan sen minkä on omalla avaimellaan allekirjoittanut.

 

[Rajatila]

Sinänsä hyvä video että sai ajattelemaan oman kuplan ulkopuolelta, en aikaisemmin tajunnutkaan että linuxin ja vieläpä mintin asentaminen voisi olla jollekulle noin vaikeaa.

Minusta oli loistava video, kyllä itsekkin moneen kertaan joutunut toteamaan ettei linux ole "helppo" tavan pc käyttäjälle.
Käyttö onnistuneen asennuksen jälkeen ei nyt hirvittävästi poikkea windows maailmasta, sen jälkeen enemmän opettelua ja totuttelua.
Se mikä nykyään on hienoa ettei perus käyttäjän tarvitse enää koskea terminaaliin juurikaan, tietysti sen kanssa helpompi tehdä ohjeiden mukaan.

 

[Hyrava]

Minusta oli loistava video, kyllä itsekkin moneen kertaan joutunut toteamaan ettei linux ole "helppo" tavan pc käyttäjälle.
Käyttö onnistuneen asennuksen jälkeen ei nyt hirvittävästi poikkea windows maailmasta, sen jälkeen enemmän opettelua ja totuttelua.
Se mikä nykyään on hienoa ettei perus käyttäjän tarvitse enää koskea terminaaliin juurikaan, tietysti sen kanssa helpompi tehdä ohjeiden mukaan.

Tavallinen tallaaja ei tosiaan kovin monimutkaisia sovelluksia käytä, yleisimmäthän on selain ja jotkut toimisto-ohjelmat joiden käyttö ei juurikaan poikkea linuxin ja windowsin välillä. Tietty sitten pelaaminen on oma stoorinsa mutta jos ajattelee jotain 60-vuotiasta "pihtiputaan mummoa" niin aika pitkälti tietokoneen käyttö on selaimen käyttöä.

Ohjeet tosiaan pääsääntöisesti on terminaaliin, erilaisia graafisia käyttöliittymiä kun on erilaisia mutta tekstikomennot yleensä toimivat koneessa kuin koneessa. Windowsin "etu" on ollut että myös graafisen puolen ohjeita on ollut kattavasti mutta nyt alkaa silläkin puolella ohjeet happanemaan aina vaan nopeammin ja nopeammin kun windowsin ohjauspaneeli ja asetukset muuttuvat aina vaan tiheämpään tahtiin eri näköisiksi ja eri paikkoihin. Tuon on hyvin huomannut kun itselläni on pelikoneena Win11-kone ja sen kanssa kun on jotain joutunut ihmettelemään niin googlella löydetyt mutaman kuukauden vanhat ohjeetkin saattavat olla käyttökelvottomat kun M$ on suuressa viisaudessaan päättänyt siirtää jonkun asetuksen eri paikkaan ja/tai eri nimelle. Ennen windows-ohjeita pystyi kohtuuhelposti soveltamaan jopa monen version päähän mutta nykyään tuntuu että edes samassa versiossa asiat eivät pysy samassa paikassa.

 

[jak_pdgm]

Se mikä nykyään on hienoa ettei perus käyttäjän tarvitse enää koskea terminaaliin juurikaan, tietysti sen kanssa helpompi tehdä ohjeiden mukaan.

Totta, mutta tiedä sitten hyötyykö peruskäyttäjä joka ei halua koskea terminaaliin hirveästi linuxista, kun windowskaan ei ole enää sellainen kuin joskus 20v sitten ja sen kanssa pääsee joissain asioissa helpommalla.

Olettaen siis että peruskäyttäjällä on jo windows ja pitäisi jotenkin perustella miksi kannattaisi siirtyä linuxiin.

 

[tonttulainen]

Sinänsä hyvä video että sai ajattelemaan oman kuplan ulkopuolelta, en aikaisemmin tajunnutkaan että linuxin ja vieläpä mintin asentaminen voisi olla jollekulle noin vaikeaa.

Kyllä mä kehtaisin väittää että bout 10-15v sitten tuo Minttu oli jopa vähän selkeämpi asentaa. Tai mistäpä minä kun pistän 5v välein aina muutamaksi kuukaudeksi kerrallaan tuplabuutin kunnes jotain hajoaa peruuttamattomasti

Hienoja automaattiasennusohjelmia on toki joka suunnassa! Just tasapainoilen Fedoran ja Nobaran välillä että kummasta tulis winukalle korvaaja. Molemmat asentuu hienosti mutta menivät rikki kumpikin omalla tavallaan ekalla kierroksella. Fedoran kohdalla voidaan ehkä myöntää pientä käyttäjävirheen poikasta, mutta eikö näiden pitänyt olla sieltä vakaammasta ja käyttäjäystävällisemmästä päästä laittaa ajokuntoon?

 

[BongisKhan]

Minusta oli loistava video, kyllä itsekkin moneen kertaan joutunut toteamaan ettei linux ole "helppo" tavan pc käyttäjälle.
Käyttö onnistuneen asennuksen jälkeen ei nyt hirvittävästi poikkea windows maailmasta, sen jälkeen enemmän opettelua ja totuttelua.
Se mikä nykyään on hienoa ettei perus käyttäjän tarvitse enää koskea terminaaliin juurikaan, tietysti sen kanssa helpompi tehdä ohjeiden mukaan.

Periaatteessa peruskäyttö on nyky-linuxeissa erittäin suoraviivaista ja helppoa lähes kenelle tahansa ikinä tietokonetta käyttäneelle. Laittaa vaan Windows-ihmiselle Mintin ja Mäkki-ihmiselle PopOS ja mitään ihmeempää ongelmaa asioiden löytämisessä ja perussäädöissä ei pitäisi olla kenellekään suunnilleen täydellä pakalla pelaavalle ihmiselle.

Se, missä Linux edelleen kuitenkin feilaa ja mielestäni varsin isosti, on se että niin kauan kuin homma toimii, se toimii, mutta sitten jos/KUN jotain hajoaa, se vaatii usein vitullisen säädön ja useamman CLI-daivin, että saa asiat jälleen toimimaan. Tuntuu myös edelleen siltä, että Linuxilla varsinkin isommat käyttöjärjestelmäpäivitykset edelleen ihan säännönmukaisesti rikkoo asioita melkein joka kerta ja pitää taas säätää. Toki jos on fiksusti säädetty kokonaisuus ja /home/ omalla osiollaan jne. niin eipä se kokeneelle Linux-ihmiselle ole temppu eikä mikään asentaa vaikka koko käyttis uusiksi harva sen viikko, mutta kyllä se tavalliselle taatelintallaajalle vaan aika tekemätön paikka on.

Ei siis siinä, että Windowskaan olisi täydellinen ja varsinkin Win11 kanssa on nähty useampi suorastaan katastrofaalisen huono käyttispäivitys, mutta yleisesti ottaen näiden kanssa diilaaminen on kuitenkin aika paljon helpompaa peruskäyttäjälle ja asiat fiksataan Mikkisoftan toimesta suhteellisen nopeasti. Toki linux-puolella tätä riskiä voi minimoida LTS - versioita pyörittämällä.

Lähinnä tästä on itsellä ihan käytännön kokemusta, että joskus aikoinaan (myönnettäköön kuitenkin, että jo vuosia sitten) laitoin yhdelle sukulaiselle Linuxin juurikin tuollaiseen peruskäyttöön ja homma toimi pääosin hyvin, mutta käytännössä vähintään parin kuukauden välein piti käydä jotain fiksaamassa kun käyttis oli vaan "itsekseen" mennyt jollakin tapaa juntturaan. Jossain kohtaa heitin W10:n tulille kun kyllästyin lähitukena toimimiseen ja sen jälkeen ei ole tarvinnut käydä kertaakaan. Toki tässä on myös se vanha viisaus, että anna miehelle kala ja hän syö päivän, opeta hänet kalastamaan ja hän syö loppuelämänsä, mutta vaikeapa sitä on tietokoneista ja säätämisestä totaalisen kiinnostumattomalle ihmiselle ruveta asioita väkisellä opettamaan.

Totta, mutta tiedä sitten hyötyykö peruskäyttäjä joka ei halua koskea terminaaliin hirveästi linuxista, kun windowskaan ei ole enää sellainen kuin joskus 20v sitten ja sen kanssa pääsee joissain asioissa helpommalla.

Olettaen siis että peruskäyttäjällä on jo windows ja pitäisi jotenkin perustella miksi kannattaisi siirtyä linuxiin.

No ensimmäisenä tulee ainakin ilmaisuus, avoimuus, yksityisyys ja tietoturvallisuus. Varsinkin nyt kun W10 tapetaan ja iso osa laitekannasta on MS:n TPM-sekoilun takia epäkuranttia W11:lle (toki tuon saa oikeasti ohitettua jos tietää mitä tekee), niin Linuxiin siirtyminen voi hyvinkin käydä järkeen monelle Pertti Peruskäyttäjälle, joka tarvitsee lähinnä koneen jolla pääsee nettiin.

 

[jak_pdgm]

No ensimmäisenä tulee ainakin ilmaisuus, avoimuus, yksityisyys ja tietoturvallisuus. Varsinkin nyt kun W10 tapetaan ja iso osa laitekannasta on MS:n TPM-sekoilun takia epäkuranttia W11:lle (toki tuon saa oikeasti ohitettua jos tietää mitä tekee), niin Linuxiin siirtyminen voi hyvinkin käydä järkeen monelle Pertti Peruskäyttäjälle, joka tarvitsee lähinnä koneen jolla pääsee nettiin.

W10 ja vanhojen koneiden suhteen kyllä. Mutta kiinnostaako pertti peruskäyttäjää ilmaisuus, avoimuus, yksityisyys ja tietoturva (mikä on käsittääkseni nykywindowseissa hyvällä tasolla) sen enempää kuin linuxin terminaalitkaan. Emt. itse voisin ihan hyvin käyttää windowsiakin, jos se ei olisi muuten niin persiistä esim. sen hiirivetoisuuden ja kunnollisen shellin sekä työkalujen puuttumisen takia, mitä wsl yrittää paikata.

Linuxissa tulee taas helposti omat ongelmansa, jos esim. suttuisemmat fontit matalan ppi:n näytöllä tai huonompi skaalaus sattuu häiritsemään.

 

[Rajatila]

W10 ja vanhojen koneiden suhteen kyllä. Mutta kiinnostaako pertti peruskäyttäjää ilmaisuus, avoimuus, yksityisyys ja tietoturva (mikä on käsittääkseni nykywindowseissa hyvällä tasolla) sen enempää kuin linuxin terminaalitkaan. Emt. itse voisin ihan hyvin käyttää windowsiakin, jos se ei olisi muuten niin persiistä esim. sen hiirivetoisuuden ja kunnollisen shellin sekä työkalujen puuttumisen takia, mit

Olen vuosikymmenien aikana asennellut muutamalle vanhemmalle ihmiselle linuxit koneisiin, juuri tietoturva syistä.
Ei tarvitse pelätä viruksia tai muita windowsin murheita.
Ovat olleet tyytyväisiä koneisiinsa kun toimivat ja pääsevät lukemaan uutiset ja maksamaan laskut verkkopankkiin.
Muutaman hassun kerran on mennyt päivityksessä rikki, mikä nyt ollut suurin murhe.

 

[Mizwita]

Sampsalla asennus sujui tuosta vain. Itse kun yritin niin aluksi piti valita minkä Linux version valitsee, sitten kun valitsi Mintin, niin löytyi download torrent, mutta alapuolella luki, että kuka vain voi tuottaa feikkejä ISO levykuvia ja sitten luki jotain shasummia ja 256gpg ja jotain, että paikallisesti tallentaa ja sitten vielä tarkistaa tiedostot. Jotenkin lataaminen sitten lopulta onnistui, enää ei muista miten.

Toisaalta ei se Win 11 asennus sen yksinkertaisempaa ole, ensin löytyy Win 11 asennusavustaja ja sen alapuolella lukee ennen kuin ryhdyt käyttämään asennusavustajaa ja sen alapuolella lukee Win 11 asennustietovälineen luonti ja sen alapuolella lukee ennen kuin ryhdyt käyttämään tietovälineen luontityökalua ja sen alapuolella lukee lataa Win 11 näköistiedosto jne. jne.

Pakollistahan noiden tarkistaminen ei ole, mutta kyllä Microsoftikin suosittelee sha256 tarkistamisen Windowsin osalta heidän lataussivullaan. Eikä turhaan, se on kuitenkin aika nopea ja helppo tarkistaa kun on sen kerran tehnyt.

Itse käyttöjärjestelmän asennuksen osalta uskallan väittää Linuxin olevan nykyään paljon helpompi. Viimeksi prosessi oli Windows osalta suurinpiirtein näin:

1. Lataa .iso tiedosto ja tarkista powershellillä sha256
2. Asenna media usb tikulle
3. Luo netissä unattended.xml tiedosto, jossa saa kaikki ms tyrkytykset ja härpäkeet pois päältä
4. Vie xml tiedosto asennusmedian juureen ja asenna

Vaihtoehtoisesti joutuu asennusvaiheessa suorittamaa päätteellä erilaisia komentoja, jotta ei tarvitse poistaa sovelluksia, heittää copilottia roskiin tai katselemaan candy crusheja start menussa.

Linuxilla saa myös sovellukset ja asetukset niille muutamalla komennolla, kun Windowsilla pitkään joutui selaimella lataamaan exet ja ronkkimaan asennukset käsin läpi yksi kerrallaan. Tosin nykyään winget on tuonut tähän parannusta.

 

[love_doctor]

Pakollistahan noiden tarkistaminen ei ole, mutta kyllä Microsoftikin suosittelee sha256 tarkistamisen Windowsin osalta heidän lataussivullaan. Eikä turhaan, se on kuitenkin aika nopea ja helppo tarkistaa kun on sen kerran tehnyt.

Tämähän se. Jos ei millään keinolla itse keksi miten sha256:n tarkistaa, niin voi olla ettei kannata itse vaan kannata asentaa käyttistä vaan palkkaa siihen vaikka jonkun kaverin. Tuohan on ihan oikea tietoturvariski. Esim. työympäristössä voit joutua oikeudelliseen vastuuseen eikä auta selittelyt paitsi jos on USA:n presidentti. Kotona jokainen saa asennella mitä haluaa, mutta tuskin kotonakaan on kivaa jos kaikki oman intiimit tiedostot vuotavat maailmalle tai koneen data tuhoutuu.

 

[timppeli]

Kun Windows 11 suostuu asentumaan vain tietyille prossuille, käskykannoille, pitää olla TPM2.0 jne. jne. ja kuulemma uhkaa tehdä 620 biljardista nykytietokoneesta rautaromua...
...välillä olen miettinyt mikä on niin vanha PC, tai mitkä ominaisuudet sellaisessa, ovat mitkä estävät juuri minkään nykyisin tuetun graafisella työpöydällä varustetun Linuxin asentamista?

Ei puhuta siitä että sitä olisi tahmeaa käyttää muistin vähyyden tai yksiytimisen prossun tai hitaan kovalevyn takia, vaan että esim. prossun käskykanta on vain niin vanha ettei edes Linux sitä enää sulata, tms.? Ymmärrän että tässäkin varmaan on suuri ero puhutaanko jostain viimeisimmästä Fedorasta vai 10 vuotta tuetusta vanhemmalla kernelillä olevasta LTS Debianista tai Rocky Linuxista. Vai onko, uusimmatkin kernelit ja kilkkeet toimivat vanhoissa koneissa siinä miten vanhemmatkin kernelit, ehkä muistia vaativat vähän lisää?

Lähinnä tulee mieleen että monet distrot toki ovat lopettaneet 32bittisten CPU:iden tukemisen, mutta ilmeisesti vielä joitakin sitkeitä sissejä on jotka tarjoavat jonkinlaista Linuxia sellaisillekin konevanhuksille.

Muutama vuosi sitten sain esim. erään ikivanhan yksiytimisellä 32-bittisellä ja 1GB RAM varustetun läppärin pyörimään Q4OS Linuxilla,, oli jopa toimiva työpöytä ja kaikki. Tarvitsin häthätää erillisen sisäisen ftp-palvelimen jonkun kytkimen tai reitittimen firmispäivityksiä varten ja se toimi siihen hyvin, ja mieluummin halusin siinä tapauksessa työpöydänkin. Siinä oli vielä sellainenkin kommerverkki että tuosta antiikkisesta läppäristä oli jo sisäinen 2,5" PATA HDD mennyt rikki ja turha yrittää löytää tilalle korvaajaa (se PATA...), joten asensin Q4OS Linuxin 8GB USB-muistitikulle, buuttasin siltä ja ajoin siitä käsin. USB muistitikku toimi ko. läppärin massamuistina sen aikaa.

Tuo Q4OS näyttäisi edelleen tukevan 32-bittisiä prossuja, ainakin 2028 asti mihin nykyisen version tuki jatkuu. Hyvä heille.

Q4OS - desktop operating system

q4os.org

Onko muita, esim. että uusin Fedora tai Ubuntu ei tue enää tietyn generaation ja sitä vanhempia CPU:ita?

 

[timppeli]

Totta, mutta tiedä sitten hyötyykö peruskäyttäjä joka ei halua koskea terminaaliin hirveästi linuxista, kun windowskaan ei ole enää sellainen kuin joskus 20v sitten ja sen kanssa pääsee joissain asioissa helpommalla.

Olettaen siis että peruskäyttäjällä on jo windows ja pitäisi jotenkin perustella miksi kannattaisi siirtyä linuxiin.

Tutuille peruskäyttäjille suosittelen Linuxia vaihtoehdoksi jos kaikki ehdot täyttyvät:
1. eivät halua ostaa uutta konetta
2. nykyinen kone ei suostu ajamaan Windows 11 tai on sille tai jopa 10:lle liian tahmainen, esim. 4GB RAM tms.
3. ei ole käytössä erikoissoftia vaan peruskäyttöä selaimella, ehkä meilit Thunderbirdillä, LibreOffice riittää MS Officen korvaajaksi jne.
4. jos jotain Windows-softaa haluavat ehdottomasti käyttää, olen melko varma että se toimii ok WINE kautta.

Toki noissa tapauksissa lupaudun heidän ilmaiseksi tai puoli-ilmaiseksi IT-tuekseen, ainakin sen verran että saadaan sopiva Linux asennettua tarvittavine ohjelmineen, ja vähän käyttökoulutusta, ja tarvittaessa tulen hätiin jos tarvitsee jotain konffailla tai tulee ongelmia.

En oleta että he lähtisivät ominpäin asentelemaan Linuxia, saa toki yrittää eikä se sen vaikeampaa ole kuin Windowsin asentaminen, monesti jopa helpompaa kun ei tarvitse miettiä minkä Windows-version "saa" asentaa (Home Pro Single jne.) eikä tarvitse miettiä aktivoituuko se ilmaiseksi vai ei.

 

[TemeV]

...välillä olen miettinyt mikä on niin vanha PC, tai mitkä ominaisuudet sellaisessa, ovat mitkä estävät juuri minkään nykyisin tuetun graafisella työpöydällä varustetun Linuxin asentamista?

Kernelistä tiputettiin hiljattain tuki 486 ja 586:lle Linux-kysymyksiä & yleistä keskustelua Linuxista Eli ainakaan tuolle raudalle ei joidenkin vuosien päästä löydy enää uutta kerneliä. Tosin LTS-kernelit, joista tuki edelleen löytyy, on tuettuna pitkälle 30-lukua, joten ei tässä nyt välitöntä hätää ole tuonkaan raudan kanssa.
Tuohon 32-bittisyyteen se raja käytännössä alkaa muodostua. 5 vuoden päästä saattaa olla jo vaikeuksia löytää 32 bittistä jakelua.

 

[timppeli]

Kernelistä tiputettiin hiljattain tuki 486 ja 586:lle Linux-kysymyksiä & yleistä keskustelua Linuxista Eli ainakaan tuolle raudalle ei joidenkin vuosien päästä löydy enää uutta kerneliä. Tosin LTS-kernelit, joista tuki edelleen löytyy, on tuettuna pitkälle 30-lukua, joten ei tässä nyt välitöntä hätää ole tuonkaan raudan kanssa.
Tuohon 32-bittisyyteen se raja käytännössä alkaa muodostua. 5 vuoden päästä saattaa olla jo vaikeuksia löytää 32 bittistä jakelua.

Ok, tosi vanhoihin Linuxeja voi siis edelleen asennella, ja aika harvoin enää törmää vielä toimivaan 32-bittiseen PC:hen. Aika usein mulle se viitsiikö jollekin vanhalle PC:lle keksiä uusiokäyttöä Linuxin avulla vaikuttaa muistin määrä. Vähimmällä muistilla pyörii yksi 3GB RAM eMachines läppäri mulla, Linux Mint.

Kun taas kohistaan kuinka paljon PC:eitä muuttuu "romuraudaksi" Windows 11 takia, mulle kelpaisi muutama puoli-ilmainen vanha läppäri yms., asennan Linuxin ja käytän mihin käytän. Tosin jotkut firmat yrittävät myydä tällaisia läppäreitä edelleen käytettyinä Windows 11-läppäreinä, Windows 11 on asennettu epävirallisesti ja saa miettiä asentuuko seuraava feature-päivitys vai ei jne.?

EDIT: Vielä tarkennus, asettavatko DE:t (desktop environments) jotain rajoituksia millä raudalla/näyttöpiirillä suostuvat pyörimään, vai pyöriikö viimeisin XFCE tai KDE tai Gnome tai mikälien suunnilleen millä tahansa raudalla, millä itse Linux kernel suostuu pyörimään? Vai meneekö tässä ehkä joku raja että joku Wayland toimii vain tietynlaisella raudalla jne.?