Linux-kysymyksiä & yleistä keskustelua Linuxista

Tiedä noista, välillä jotain voi mennä rikki vaikka ei pitäisi.

Aikoinaan tein release upgraden useammalle Ubuntu-virtuaalikoneelle. Muut menivät ok läpi, yhdessä meni grub rikki päivityksen yhteydessä eikä enää suostunut buuttamaan. Onneksi oli snapshot tilanteesta ennen päivitystä jonka palauttamalla lähti taas buuttaamaan, sitten pari tuntia googlailua ja löytyi joskus samasta ongelmasta kärsineitä ja ohjeet komennoista mitä pitää antaa ENNEN release upgradea jotta ongelma ei toistu. Sillä meni sekin release upgrade läpi.

Itsellä on nykyisin myös rolling distro (OpenSUSE Tumbleweed) käytössä. Pari kertaa on päivityksen yhteydessä tullut varoitus konflikteista riippuvuuksien kanssa. En ole koskaan tohtinut koittaa onneani vaan olen canceloinut päivityksen siltä kertaa, odottanut muutaman päivän tai yhden viikon ja yrittänyt uudestaan. Silloin yleensä ei ole varoitusta enää tullut ja olen uskaltanut päivittää läpi, kai joku puuttuva riippuvuus on silloin päivittynyt ajan tasalle että on kaikki taas synkassa. Onneksi varoittelee.

OpenSUSE TW väitettiin jossain distro-vertailussa omaavan maineen "stabiilein rolling distro", en ota kantaa onko oikeastii näin ja mitä se todellisuudessa tarkoittaa.
 
Viimeksi muokattu:
Ei vaan aukea, miten pakettiriippuvuuksien rikkinäisyydestä päädytään bootloopiin. Archissa näkee ongelman pakettien päivittämisessä ennen kuin asentaa yhtään uutta ja poistaa vanhaa.
Muistelen itselläni olleen ongelma se, että jokin softa sai ison päivityksen ja vaati myös joltain riippuvuudelta uusista uusinta versiota. Siellä oli vain ne riippuvuuksien versionumerot pakettiin kirjoitettu väärin, ja se suostui asentumaan, vaikka siitä riippuvuudesta tarjoiltiin edelleen pykälän vanhempaa. Jos tuollainen osuu johonkin bootissa käynnistettävään serviceen, niin saattaa tosiaan estää bootin. Nykyään kaiketi Archilla on testaus paremmin hallussa, niin noita sattuu vähemmän.
 
Muistelen itselläni olleen ongelma se, että jokin softa sai ison päivityksen ja vaati myös joltain riippuvuudelta uusista uusinta versiota. Siellä oli vain ne riippuvuuksien versionumerot pakettiin kirjoitettu väärin, ja se suostui asentumaan, vaikka siitä riippuvuudesta tarjoiltiin edelleen pykälän vanhempaa. Jos tuollainen osuu johonkin bootissa käynnistettävään serviceen, niin saattaa tosiaan estää bootin. Nykyään kaiketi Archilla on testaus paremmin hallussa, niin noita sattuu vähemmän.
Joo siis Archilla on välillä isoja päivityksiä. Esim. firmware-paketit jaettiin jokin aika sitten ja vaati manuaalista poistoa ja asentamista. Libc-päivitys on isompi myös ja pätee muihinkin distroihin. Näissä vaan se, että jos pacman herjaa vähänkään jotain ongelmaa, onko pakko ajaa ne päivitykset? Se että paketeista tippuu uusia versioita pitkin päivää ei tarkoita että koko ajan pitää olla kaikki ajan tasalla.

Itsellä on kolmella koneella Arch ja samaa asennusta siirtänyt levyltä toisellekin kun tulee isompi
konepäivitys. Vanhin Arch-asennus oli ajalta ennen systemd:tä 2000-luvun lopulta. Jos vaikka vertaa Ubuntuun (ei LTS), Gentoohon, Debian unstableen, niin Arch ei ole erityisemmin erottunut bugiherkemmäksi. Testing-paketeissa on välillä rikkinäisiä riippuvuuksia, mutta niitä ei ole pakko käyttää. Joskus kehittäjien avaimet pitänyt hakea käsin uudestaan kun paketit eivät asennu. Archin kanssa on yllättävää, että 1-2 vuotta päivittämättäkin ollut distro vielä lähtenyt pacmanilla päivittymään, kun esim. Ubuntulla on tyypillistä, että teet 4-5 versiopäivitystä peräjälkeen eikä mitenkään voi hypätä aiempien yli ellei tee puhdasta asennusta.
 
Debianin kohdallahan on vitsailtu iät ja kaiket jotakuinkin: "Unstable means testing, Testing means stable and Stable means old".

Vähän noin sen ittekin olen mieltänyt.

Jos redhat puolelta ettii vastaavuutta niin RHEL 6.12 kerneli jota taitaa toi debian stable käyttää.
Fedora 43 vois vastata unstablee
Fedora rawhide taikka ELN sitten testing.

Kyllähän toi 6.12 kerneli jo aika hapan alkaa olla. Mutta yleensä se kerneli ei nyt niin suuri ongelma ole vaan noiden jäädytettyjen distrojen ongelma on ne muut kriittiset palikat kuten python ja php jotka niissä on monesti happamia jo siinä vaiheessa kun ne julkaistaan.

Joo siis Archilla on välillä isoja päivityksiä. Esim. firmware-paketit jaettiin jokin aika sitten ja vaati manuaalista poistoa ja asentamista. Libc-päivitys on isompi myös ja pätee muihinkin distroihin.

Mikä pätee? Ainakaan Fedoran kanssa ole tarttenu mitään manuaalisia poistoja tehdä enää vuosiin. 3rd party repoja kun on käytössä niin ne voi aiheuttaa välillä jotain että käsin joutuu poistamaan.

Ja jos vähänkin tuntee syvemmin distron toimintaa niin pystyy aika hyvin kyllä päättelemään että mitkä on ns. kriittisiä paketteja. Joskus on ollut tilanne että että ei riippuvuudet vaan resolvaa kun on joku muutos tehty ja vanha paketti vaatii jotakii riippuvuuksia ja uusi sitten toisia josta sitten jotenkin syntyy mahdoton tilanne. Ne on tullu juurikin ratkottua niin että miettiny onko se kriittinen, jos ei ole niin forcella vaan poistoon ja sitten kun muut on päivitelty niin asentaa takas.
Mutta ei ole tuommoistakaan tarttenu pitkään aikaan tehdä.
 
Töissä piti käyttää Bookwormia melkein vuoden loppuun kun yksi tietoturvakomponentti ei tukenut Trixietä. Voin sanoa että hiukan alkoi mm Pythonin kanssa olla jo tuskaa...
 
Töissä piti käyttää Bookwormia melkein vuoden loppuun kun yksi tietoturvakomponentti ei tukenut Trixietä. Voin sanoa että hiukan alkoi mm Pythonin kanssa olla jo tuskaa...
Jotenkin tämä nostaa muistoja esiin.. käytössä joku maailman paras proprietary tieto"turva" sötöstys joka toimii ainoastaan jollakin vanhalla distrolla ja sen takia pitää koko firman laahata muun maailman perässä. Ja kuitenkin se kasa paskaa parhaimmillaankin ainoastaan syö resursseja, mutta toisinaan myös rikkoo asioita tai pahempaa.

Vaan kun IT management haluaa ostaa vastuuvapautuksen käyttämällä näitä, sitten kun tuotosta leviää pitkin tuulettimia niin voidaan levitellä käsiä että hommattiin markkinoiden paras tietoturvapökäle, katsokaa nyt näitä prosyyrejä. Antakee bonuksia.
 
Eihän noi jäädytetyt distrot oikeen sovellu mihinkään muuhun käyttöön kuin sellaiseen jossa tiedät että sulla on tää ohjelmakattaus ja muuta et tartte eikä myöskään uudet fyytsörit ala myöhemmin janottaa. Silloin on ihan ok käyttökohde. Jos taas et välttämättä tiedä että että mitä ohjelmia tulevaisuudessa tarttet niin aika huono valinta.

Muistan kun aikoinaan CentOS 7 yritin jotakin hommaa saada toimimaan ja ei siitä tullu mitään kun se vaati jonkun python palikan ja siitä palikasta ei niin vanhalle pythonille ollut versiota edes olemassa.

Noh kontitus toki tuo helpotusta tuohon tuskaan mutta toisaalta taas monimutkaistaa asioita ihan turhaan varsinkin jos sitä konttihärpäkettä ei tartte muuhun kuin siihen yhteen kikottimeen.
 
Fyytsöreistä puheenollen, osaako kukaan sanoa, miksi esim. Ubuntun uusin "normi"/LTS ei tue kirjautumista passkeyllä FreeIPA/IdM domainissa? Fedora on tukenu sitä jo versiosta 39 lähtien ja Ubuntullakin kaikki palikat on tukevasti jo tuen puolella.

Oon koittanu googlettaa ja kysellä tekoälyltä, mutta mitään ei oikein irtoa...
 
Eihän noi jäädytetyt distrot oikeen sovellu mihinkään muuhun käyttöön kuin sellaiseen jossa tiedät että sulla on tää ohjelmakattaus ja muuta et tartte eikä myöskään uudet fyytsörit ala myöhemmin janottaa. Silloin on ihan ok käyttökohde. Jos taas et välttämättä tiedä että että mitä ohjelmia tulevaisuudessa tarttet niin aika huono valinta.

Muistan kun aikoinaan CentOS 7 yritin jotakin hommaa saada toimimaan ja ei siitä tullu mitään kun se vaati jonkun python palikan ja siitä palikasta ei niin vanhalle pythonille ollut versiota edes olemassa.

Noh kontitus toki tuo helpotusta tuohon tuskaan mutta toisaalta taas monimutkaistaa asioita ihan turhaan varsinkin jos sitä konttihärpäkettä ei tartte muuhun kuin siihen yhteen kikottimeen.
Itse asiassa nykyään juurikin konttauksen, appimagen ja flatpakin vuoksi on jäädytetty distro toimii erinomaisesti.

Konffaat distron kerran kuntoon ja asennat sen jälkeen kaiken distron ulkopuolelta flatpakina tai konttina. Ei tarvitse jännittää että uutta softaa varten asentamasi python rikkoo distron mukana tulleen hp-toolboxin ja tulostus ei enää onnistu. Sitten kun työprojektien on vähän enemmän löysää voi ottaa aikaa LTS -> LTS päivitykseen.

Rolling distroon voisin siirtyä sitten kun tarjolla on täydellinen rollback regression sattuessa kohdalla. NixOS:saa ilmeisesti on, mutta sen käyttö vaatii toistaiseksi sen, että Nix:stä tekee oman elämäntavan. Mutta josko kohta NixOS:stä tulisi helppokäyttöisempi...
 
Mikä pätee? Ainakaan Fedoran kanssa ole tarttenu mitään manuaalisia poistoja tehdä enää vuosiin. 3rd party repoja kun on käytössä niin ne voi aiheuttaa välillä jotain että käsin joutuu poistamaan.
Siis muihinkin distroihin pätee, että libc on isompi päivitys ja sitä ei välttämättä huomaa edes jos ei ole rolling-release, kun ison päivityksen yhteydessä voi muutenkin kaikki muuttua.
 
Itse asiassa nykyään juurikin konttauksen, appimagen ja flatpakin vuoksi on jäädytetty distro toimii erinomaisesti.

Tuossahan se heti tuli miksi nää kontti sun muut härpättimet on ärsyttäviä. Joka isompi distro kun haluaa tehdä jutut omalla tavalla, sitten kehitellään käytännössä päällekkäisiä ratkaisuja joissa erona on ainoastaan jokin typerä ideologia.

Ja juu redhat syyllistyy tähän kanssa ihan huolella. Niille ei docker jostain syystä kelvannut niin piti viritellä oma räpellys podman sitten joka on ainakin melkein yhteensopiva mutta ei kuitenkaan aina ihan aina ja tarjoaa sitten dockeriin nähden jotain aivan käsittämättömiä kummallisuuksia.

Eli taas tullaan siihen linuxin perisyntiin että on monia hyviä ideoita mutta ne ideat on sitten liian fragmentoituneita kun jokainen haluaa tehä omansa.
 
Ainakaan Fedoran kanssa ole tarttenu mitään manuaalisia poistoja tehdä enää vuosiin. 3rd party repoja kun on käytössä niin ne voi aiheuttaa välillä jotain että käsin joutuu poistamaan.
Fedora 43 päivityksen yhteydessä jouduin poistamaan wine:n ennen päivitystä. En selvittänyt tarkemmin, mistä johtui, koska helppo asentaa uudestaan päivityksen jälkeen. Fedora 43 yhteydessä myös pam_lastlog päivittyi pam_lastlog2, jonka seurauksena kirjautuminen saattoi hajota päivityksessä.

Ja juu redhat syyllistyy tähän kanssa ihan huolella. Niille ei docker jostain syystä kelvannut niin piti viritellä oma räpellys podman sitten joka on ainakin melkein yhteensopiva mutta ei kuitenkaan aina ihan aina ja tarjoaa sitten dockeriin nähden jotain aivan käsittämättömiä kummallisuuksia.
Itse olen pidemmän aikaa käyttänyt podmania enkä ole huomannut käsittämättömiä kummallisuuksia dockeriin verrattuna. Jotain ominaisuuksia puuttuu dockerista, esimerkiksi `--mount=type=image` ja quadlet, mutta varmasti myös dockerissa omat etunsa podmaniin verrattuna.
 
Tuli muuten hassu bugi kun vaihdoin tässä koneessa X11 + XFCE:n Waylandiin ja KDE Plasmaan: kirjautumisruutuun tuli sellainen juttu, että kun kirjoitan salasanan niin eka yritys ei kelpaa ikinä. Se ei ole vääräkään (tai ainakaan en saa ilmoitusta), mutta enter ei tee mitään. Pitää tyhjentää kenttä ja kirjoittaa salasana uudestaan. Eipä tuo iso ongelma ole, onpahan vain erikoinen.
 
Itse olen pidemmän aikaa käyttänyt podmania enkä ole huomannut käsittämättömiä kummallisuuksia dockeriin verrattuna. Jotain ominaisuuksia puuttuu dockerista, esimerkiksi `--mount=type=image` ja quadlet, mutta varmasti myös dockerissa omat etunsa podmaniin verrattuna.
Kyllä itselläkin tulee käytettyä podmania dockerin sijaan. Ei tarvitse mitään daemoneita pyörimässä ja rootless containerit toimivat tuosta vaan. Kaikki tähän mennessä tarvitsemani virallisesti dockerille tehdyt imaget ovat toimineet, muutamassa tapauksessa joutunut vähän komentorivinuppeja vääntelemään mutta yhtään ei ole jäänyt ajelematta sen takia etteivät olisi toimineet.
 
Tuli muuten hassu bugi kun vaihdoin tässä koneessa X11 + XFCE:n Waylandiin ja KDE Plasmaan: kirjautumisruutuun tuli sellainen juttu, että kun kirjoitan salasanan niin eka yritys ei kelpaa ikinä. Se ei ole vääräkään (tai ainakaan en saa ilmoitusta), mutta enter ei tee mitään. Pitää tyhjentää kenttä ja kirjoittaa salasana uudestaan. Eipä tuo iso ongelma ole, onpahan vain erikoinen.
Itselle käy tätä välillä SDDMn kanssa. Ei jatkuvasti mutta aina välillä.

No onneksi SDDM:sitä päästään pian eroon kun Plasma 6.6 pitäisi alkaa käyttämään Plasma Login Manageria joka on 100% KDEn palikka ja integroitu Plasmaan.
 
Itselle käy tätä välillä SDDMn kanssa. Ei jatkuvasti mutta aina välillä.

No onneksi SDDM:sitä päästään pian eroon kun Plasma 6.6 pitäisi alkaa käyttämään Plasma Login Manageria joka on 100% KDEn palikka ja integroitu Plasmaan.
greetd + tuigreet, karu mutta eipähän ole liikaa riippuvuuksia...
 
greetd + tuigreet, karu mutta eipähän ole liikaa riippuvuuksia...
Boottaa tekstikonsoliin ja käynnistää DE:n sieltä. Vielä karumpi ja vähemmän riippuvuuksia :p

Tuo KDE:n uusi ratkaisuhan on apinoitu Gnomelta, missä se login-ruutu jo sisältää ison osan työpöytäympäristön riippuvuuksista. Toisaalta, sitä ei ole tarkoitettukaan itsenäiseksi palikaksi, vaan käytettäväksi plasman kanssa, niin kokonaisuutena riippuvuudet ei oikeastaan lisäänny.
 
Jos redhat puolelta ettii vastaavuutta niin RHEL 6.12 kerneli jota taitaa toi debian stable käyttää.
RHEL:iä on yhä (maksua vastaan) versiot 7, 8, 9 ja 10, joiden kerneleiden pohjana olivat 3.10.0, 4.18.0, 5.14.0 ja 6.12.0. Eikö 6.12:lla ole hiukan pidennetty tuki?
Lähinnä "Enterprise Linux":n idea on pistää palvelu pystyyn ja ajaa sitä sitten (vain tietoturvapäivitykset lisäten) vuosia (tai kymmen). Sillä tapaa "stable".

Ja juu redhat syyllistyy tähän kanssa ihan huolella. Niille ei docker jostain syystä kelvannut niin piti viritellä oma räpellys podman
Dockerilla kontin käynnistäminen tavallisena käyttäjänä oli mahdoton yhtälö. Jotain oli pakko räpeltää.

Siis muihinkin distroihin pätee, että libc on isompi päivitys ja sitä ei välttämättä huomaa edes jos ei ole rolling-release, kun ison päivityksen yhteydessä voi muutenkin kaikki muuttua.
Esim. RHEL listaa libc:n ja pari muuta pakettia, joiden päivitetyn version saa käyttöön helpoiten uudelleen käynnistyksellä: Identify packages that will require a system reboot after an update - Red Hat Customer Portal
Siksi heillä on työkalu helpottamaan huomaamista.
 
Kyllä itselläkin tulee käytettyä podmania dockerin sijaan. Ei tarvitse mitään daemoneita pyörimässä ja rootless containerit toimivat tuosta vaan. Kaikki tähän mennessä tarvitsemani virallisesti dockerille tehdyt imaget ovat toimineet, muutamassa tapauksessa joutunut vähän komentorivinuppeja vääntelemään mutta yhtään ei ole jäänyt ajelematta sen takia etteivät olisi toimineet.

Kyllä itteäni ainakin nyppii tuon podmanin kanssa se että koneen kun boottaat niin pitää käsinee kontteja alkaa käynnistellä. Dockerin kanssa asennat kontin ja sen jälkeen se vaan toimii. Boottaat koneen niin kontti käynnistyy dockerin käynnistymisen mukana.
Ja juu tiedän että saa ne bootissa käynnistymään mutta vaatii kohtuuttoman paljon värkkäämistä. Se nyt vielä jotenkin menis jos

Ja ei ole ittellä ollu myöskään mitenkään ruusuista noiden konttien toimiminen jotka on dockerille tehty alkujaan. Lähes asina on vähintään pitäny conffista jotakii muuttaa ja ei yks eika kaks kertaa kun on kontti lopettanu toimintanta kun bootin jälkeen on koittanu sitä ajella ylös.

Varmaan ihan kiva lelu jos sen kanssa jaksaa leikkiä mutta miksi kuluttaa moiseen aikaa kun on sellainenkin kontti ympäristö olemassa jossa homma vaan toimii?
 
Kyllä itteäni ainakin nyppii tuon podmanin kanssa se että koneen kun boottaat niin pitää käsinee kontteja alkaa käynnistellä. Dockerin kanssa asennat kontin ja sen jälkeen se vaan toimii. Boottaat koneen niin kontti käynnistyy dockerin käynnistymisen mukana.
Ja juu tiedän että saa ne bootissa käynnistymään mutta vaatii kohtuuttoman paljon värkkäämistä. Se nyt vielä jotenkin menis jos

Ja ei ole ittellä ollu myöskään mitenkään ruusuista noiden konttien toimiminen jotka on dockerille tehty alkujaan. Lähes asina on vähintään pitäny conffista jotakii muuttaa ja ei yks eika kaks kertaa kun on kontti lopettanu toimintanta kun bootin jälkeen on koittanu sitä ajella ylös.

Varmaan ihan kiva lelu jos sen kanssa jaksaa leikkiä mutta miksi kuluttaa moiseen aikaa kun on sellainenkin kontti ympäristö olemassa jossa homma vaan toimii?
Eihän dockerkaan defaulttina käynnistä kontteja bootin jälkeen? Näyttäisi siltä, että vipu automaattisen käynnistyksen enablointiin on täsmälleen sama dockerissa ja podmanissa, eli en näe mitään eroa tässä suhteessa, tosin en ole kyseistä ominaisuutta ikinä halunnut tai tarvinnut niin en tiedä.

Mä siirryin dockerista podmaniin joskus vuosi sitten, enkä muista kohdanneeni yhtään ongelmatilannetta, joka olisi ollut vältettävissä dockeria käyttämällä. Nvidian GPU:n enablointi tosin vaati hieman dokumentaation lukemista, koska se tapahtui vähän eri tavalla podmanilla.
 
Kyllä itteäni ainakin nyppii tuon podmanin kanssa se että koneen kun boottaat niin pitää käsinee kontteja alkaa käynnistellä. Dockerin kanssa asennat kontin ja sen jälkeen se vaan toimii. Boottaat koneen niin kontti käynnistyy dockerin käynnistymisen mukana.
Ja juu tiedän että saa ne bootissa käynnistymään mutta vaatii kohtuuttoman paljon värkkäämistä. Se nyt vielä jotenkin menis jos

Ja ei ole ittellä ollu myöskään mitenkään ruusuista noiden konttien toimiminen jotka on dockerille tehty alkujaan. Lähes asina on vähintään pitäny conffista jotakii muuttaa ja ei yks eika kaks kertaa kun on kontti lopettanu toimintanta kun bootin jälkeen on koittanu sitä ajella ylös.

Varmaan ihan kiva lelu jos sen kanssa jaksaa leikkiä mutta miksi kuluttaa moiseen aikaa kun on sellainenkin kontti ympäristö olemassa jossa homma vaan toimii?
Henkilökohtaisesti en todellakaan edes halua että mikään käynnistelee itsestään jotakin jossakin taustalla. Teen containereille aina systemd .service filet jotka niitä käynnistelee bootissa jos käynnistelee, oli sitten docker tai podman. Samalla tavalla kuin kaikelle muullekin. Tiedän aina mitä on ajossa ja mitä kautta se käynnistyy.

Mieluummin vietän muutaman minuutin sen imagen vipujen kanssa ja pari minuuttia .service filen tekemisessä kun pidän taustalla pyörimässä joutavaa ja 100% tarpeetonta daemonia jonka docker nyt sattuu vaatimaan koska syyt. Ja jolla kaikki pitää ajaa roottina. Ei sen enempää ole tarvinnut leikkiä, hyvin on asiansa ajanut.
 
Nyt pitkästä aikaa ensimmäinen oma läppäri ja ensimmäinen pc läppäri, samassa paketissa siis. Päätin kokeilla ubuntua (gnome) ja kubuntua (kde). Gnome oli ruma ku mikä (esim. näytön skaalaaminen ihan kauheaa), ja kde:ssa ei ilmeisesti saa trackpad gestureita toimimaan kovinkaan helpolla. En edes ehtinyt gestureihin asti gnomen kanssa. Ei vaikuta yhtään helpommalta kuin viimeksi 20 vuotta sitten. Pitääkö tämä paikkansa vielä herran vuonna 2026 vai enkö vain osaa hakea ratkaisua?
 
Zorin OS:ssa ainaki oli gesturet valmiina.. kaikki itselle tarpeelliset toimi suoraan noissa omissa vanhemmissa läppäreissä. Ja siis mulla se Core versio..
 
Iltasanomissa oli vähän aikaa sitten otsikko "suosittu linux pilalla" tms. ja sen verta tuo antoi lukea että viittasivat juurikin uuteen (K)Ubuntuun, niin osaako joku kertoa mitä uudistus on tullut joka joidenkin mielestä nyt on pilannut tuotteen? Itse oon luopunut buntusta vaihtui Minttiin jo noin vuosi sitten niin en tiedä.
 
Iltasanomissa oli vähän aikaa sitten otsikko "suosittu linux pilalla" tms. ja sen verta tuo antoi lukea että viittasivat juurikin uuteen (K)Ubuntuun, niin osaako joku kertoa mitä uudistus on tullut joka joidenkin mielestä nyt on pilannut tuotteen? Itse oon luopunut buntusta vaihtui Minttiin jo noin vuosi sitten niin en tiedä.
Varmaan jotain niitä tiedonkeruu hommia
 
Mieluummin vietän muutaman minuutin sen imagen vipujen kanssa ja pari minuuttia .service filen tekemisessä kun pidän taustalla pyörimässä joutavaa ja 100% tarpeetonta daemonia jonka docker nyt sattuu vaatimaan koska syyt. Ja jolla kaikki pitää ajaa roottina. Ei sen enempää ole tarvinnut leikkiä, hyvin on asiansa ajanut.

Vietä ihan vapaasti mutta kannattaa pysyä faktoissa.


Jos se roottina ajo on niin iso mörkö niin on siihen ratkaisu. Eihän tuossa roottina ajossa oikeastaan ole muuta ongelmaa kuin se että ajelet jotakii webbihärveliä siinä dockerissa joka itsessään käskyttää sitä dockeria. Se on täyttä typeryyttä.
 
Ensimmäinen probleema Cachy OS kanssa tuli vastaan. Jostain syystä kone ei osannut avata .tga tiedostoja lainkaan. Vakiona Gwenview ja kokeilin myös kahdella muulla softalla. Ainoastaan GIMP osasi avata tiedostot normaalisti. Googlettelujen perusteella löytyi joku vanha keskustelu, jossa ratkaisu oli poistaa libqtga.so niminen tiedosto /usr/lib/qt6/plugins/imageformats/ hakemistosta. Uhkarohkeana kokeilin vaikka ei ollut hajuakaan mitä teen, mutta tuolla alkoi toimimaan. Osaako joku selittää mitä tässä käytännössä tehtiin? :D
 
Eihän tuossa roottina ajossa oikeastaan ole muuta ongelmaa kuin se että
tavallisille käyttäjille ei niitä root-oikeuksia anneta. Eikä admin aja niitä käyttäjien "ohjelmia".

Kyllä itselläkin tulee käytettyä podmania dockerin sijaan. Ei tarvitse mitään daemoneita pyörimässä
Miksi on sellainen muistikuva, että podman komennot käynnistäisivät taustaprosessin? Vähän kuin käyttäjälle tehty daemon. Taitaa kyllä kuolla session mukana (jollei systemd:lle kerro jotain).

Apptainer (aka Singularity) ei aja taustalla mitään.
 
kde:ssa ei ilmeisesti saa trackpad gestureita toimimaan kovinkaan helpolla.
Onhan siinä gestureita vakiona, mutta konffeja niille ei tosiaan näytä olevan. Aika hassua, että noita ei pysty säätämään, kun muuten KDE:ssa on säätöjä vähän kaikkeen
 
Nyt pitkästä aikaa ensimmäinen oma läppäri ja ensimmäinen pc läppäri, samassa paketissa siis. Päätin kokeilla ubuntua (gnome) ja kubuntua (kde). Gnome oli ruma ku mikä (esim. näytön skaalaaminen ihan kauheaa), ja kde:ssa ei ilmeisesti saa trackpad gestureita toimimaan kovinkaan helpolla. En edes ehtinyt gestureihin asti gnomen kanssa. Ei vaikuta yhtään helpommalta kuin viimeksi 20 vuotta sitten. Pitääkö tämä paikkansa vielä herran vuonna 2026 vai enkö vain osaa hakea ratkaisua?
Testaa piruuttas asentaa Fusuma tai Touchegg + touche konffaamiseen. Toimivuus riippunee pikkasen siitä onko Wayland vai X11 käytössä.
 
Vietä ihan vapaasti mutta kannattaa pysyä faktoissa.


Jos se roottina ajo on niin iso mörkö niin on siihen ratkaisu. Eihän tuossa roottina ajossa oikeastaan ole muuta ongelmaa kuin se että ajelet jotakii webbihärveliä siinä dockerissa joka itsessään käskyttää sitä dockeria. Se on täyttä typeryyttä.
Aivan totta, voihan sitä docker daemonia ajella myös ei-roottina. Mutta ei se allergia tule pelkästää siitä rootista, vaan koko hölmöstä arkkitehtuurista joka pyörii daemonin ympärillä( ja oletuksena on roottina). Se että sen saa purkattua pyörimään jotain käyttäjänä ei siitä sen siistimpää tee.

En halua sitä daemonia pyörimään nurkissa silloin kun ei ole ensimmäistäkään konttia ajossa, roottina tai käyttäjänä.


Miksi on sellainen muistikuva, että podman komennot käynnistäisivät taustaprosessin? Vähän kuin käyttäjälle tehty daemon. Taitaa kyllä kuolla session mukana (jollei systemd:lle kerro jotain).
Onhan siinä joitakin taustaprosesseja, mutta ne käynnistetään containerin myötä ja kun containeri sammuu niin niitäkään ei enää tarvita. Kaikki pyörii oletuksena käyttäjän prosesseissa. Dockerissa taas se kokoajan pyörivä daemoni pyörittää koko sirkusta, käskyttää runtimeä ja pystyttää containerit jne. Ilman sitä ei yksinkertaisesti ole koko dockeria.

En edes yritä väittää että podman olisi täydellinen ratkaisu, mutta koska tarvitsee containereita ajella muttei kiinnosta harrastaa niitä sen enempää niin se on toistaiseksi ollut pienimmän riesan tie.

Apptainer (aka Singularity) ei aja taustalla mitään.
En ole kovin syvällisesti tutustunut, ymmärtääkseni tarkoitettu vähän erilaisiin käyttötapauksiin kuin docker/podman eikä aivan yhtä drop-in korvaaja dockerille. Eli vaatisi sitä harrastuneisuutta jota ei ole.

Mieluiten joku mahdollisimman kevyt ratkaisu, tyyliin systemd-nspawn mutta sitäkin varten pitäisi löytyä kiinnostusta.
 

Statistiikka

Viestiketjuista
296 764
Viestejä
5 063 857
Jäsenet
81 218
Uusin jäsen
Gako55

Hinta.fi

Back
Ylös Bottom