Linux-kysymyksiä & yleistä keskustelua Linuxista

[love_doctor]

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.

 

[JiiPee]

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.

 

[jokujossai]

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.

 

[Makis]

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.

 

[Barbarossa]

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.

 

[Mukava]

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.

 

[Barbarossa]

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...

 

[TemeV]

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

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.

 

[keskiverto]

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.

 

[TemeV]

Eikö 6.12:lla ole hiukan pidennetty tuki?

Ei taida olla siinäkään kuin pari vuotta. Sen jälkeen mm. distrojen ylläpitäjät niitä paikkailee.

 

[Barbarossa]

Ei taida olla siinäkään kuin pari vuotta. Sen jälkeen mm. distrojen ylläpitäjät niitä paikkailee.

6.12 tuki jatkuu CIP projektin kautta 10 vuotta "virallisen" tuen loppumisen päättymisestä.

 

[JiiPee]

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?

 

[Lammas]

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.

 

[Barbarossa]

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.

 

[jra72]

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?

 

[HendriXXX]

Zorin OS:ssa ainaki oli gesturet valmiina.. kaikki itselle tarpeelliset toimi suoraan noissa omissa vanhemmissa läppäreissä. Ja siis mulla se Core versio..

 

[Squirrel]

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ä.

 

[jra72]

Zorin OS:ssa ainaki oli gesturet valmiina.. kaikki itselle tarpeelliset toimi suoraan noissa omissa vanhemmissa läppäreissä. Ja siis mulla se Core versio..

Neva hööd tuollaisesta, mutta vaikuttaa mielenkiintoiselta. Voisi kenties kokeilla, kiitos!

 

[eMTB]

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

 

[JiiPee]

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.

Rootless mode

Run the Docker daemon as a non-root user (Rootless mode)

docs.docker.com

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ä.

 

[Eore]

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?

 

[keskiverto]

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.

 

[TemeV]

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

 

[jra72]

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

Joo on, mutta melko rajoitetusti näin OSX:stä siirtyvälle.

 

[Ezzy]

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ä.

 

[jra72]

Testaa piruuttas asentaa Fusuma tai Touchegg + touche konffaamiseen. Toimivuus riippunee pikkasen siitä onko Wayland vai X11 käytössä.

Kokeilin touchegg + touche, mutta jälkimmäinen ei edes käynnistynyt asennuksen jälkeen

 

[Barbarossa]

Vietä ihan vapaasti mutta kannattaa pysyä faktoissa.

Rootless mode

Run the Docker daemon as a non-root user (Rootless mode)

docs.docker.com

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.

 

[Makis]

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

No eihän sitä silloin ole pakko ajaa. Voit käynnistää sen kun tarvitset.

 

[Barbarossa]

No eihän sitä silloin ole pakko ajaa. Voit käynnistää sen kun tarvitset.

Ei tarvitse ei kun voi käyttää podmania.

 

[Squirrel]

Asensin tohon mun hälläväliä läppäriini uuden version linux mintistä; suurinpiirtein kaikki toimii mutta en saa käynnistymään konsolia/terminaalia. Google antaisi osviittaa että viittaisi johonkin pakettiin, mutta toisaalta miten sitä voisi "tutkia" kun terminaali ei aukea. Vai onko jollain antaa vinkkiä miten korjata? En ole vielä kokeillut käynnistyykö siten että bootatessa valitsee sen konsolin.

 

[Jaguafgeg]

Asensin tohon mun hälläväliä läppäriini uuden version linux mintistä; suurinpiirtein kaikki toimii mutta en saa käynnistymään konsolia/terminaalia. Google antaisi osviittaa että viittaisi johonkin pakettiin, mutta toisaalta miten sitä voisi "tutkia" kun terminaali ei aukea. Vai onko jollain antaa vinkkiä miten korjata? En ole vielä kokeillut käynnistyykö siten että bootatessa valitsee sen konsolin.

Onko tämä nyt ihan täysin pakasta vedetty asennus, ettei sen jälkeen ole tehty yhtään mitään muutoksia käyttäjän puolelta?

Kokeile tehdä koneelle uusi account ja testaa toimiiko terminaaliohjelman avaus siellä.

Edit: Mintin foorumeilla ilmeisesti tämänkaltaista ongelmaa voi esiintyä kielivalinta-asetusten takia, tarkista että onko suomi asennettuna kielten asetuksista.

 

[Squirrel]

Onko tämä nyt ihan täysin pakasta vedetty asennus, ettei sen jälkeen ole tehty yhtään mitään muutoksia käyttäjän puolelta?

Kokeile tehdä koneelle uusi account ja testaa toimiiko terminaaliohjelman avaus siellä.

Edit: Mintin foorumeilla ilmeisesti tämänkaltaista ongelmaa voi esiintyä kielivalinta-asetusten takia, tarkista että onko suomi asennettuna kielten asetuksista.

On juu pakasta, täytyy tsekata kielivalinta.

 

[Squirrel]

Kun asensin Suomen paketin niin alkoi toimimaan.

 

[love_doctor]

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ä.

Tuntuu että tässä menee pari asiaa sekaisin. Dockerilla on palvelinprosessimalli, mutta käyttäjän ei tarvi olla root vaan docker-ryhmässä. Jos jollain muulla tekniikalla ajaa ilman root-oikeuksia (siis user namespace), niin eihän sillä voi tehdä samoja asioita ellei jotain kautta anneta root-oikeuksia. Esim. volume-mountit nyt ei taida toimia. Riippuu ihan käyttötapauksen vaatimuksista, miten kannattaa ajaa.

 

[takomo]

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...

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.

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.

Onko nämä ongelmat niinkään Linuxin ongelmia vai pikemminkin Pythonin kehnoutta?
Mitä virkaa on ohjelmointikielellä, joka on niin nirppanokka, että kaikki särkyy, jos jostain palikasta ei olekaan uusin (tai jokin tietty) versio käytettävissä?

 

[Makis]

Taisi olla minulla kyse siitä, että modulien kirjoittajat käyttivät kielen uusia ominaisuuksia. Tuotahan ei mikään kieli voi estää muuten kuin lopettamalla uusien ominaisuuksien lisäämisen. Ei se taitaisi C++23:kaan kääntyä jossain 5 vuotta vanhassa kääntäjässä.

 

[ojisama]

Taisi olla minulla kyse siitä, että modulien kirjoittajat käyttivät kielen uusia ominaisuuksia. Tuotahan ei mikään kieli voi estää muuten kuin lopettamalla uusien ominaisuuksien lisäämisen. Ei se taitaisi C++23:kaan kääntyä jossain 5 vuotta vanhassa kääntäjässä.

Pythonilla on myös tuohon ratkaisu, venv, jolla palikat saa omat python ympäristönsä.

 

[Lammas]

Pythonilla on myös tuohon ratkaisu, venv, jolla palikat saa omat python ympäristönsä.

Tuo on vain osittainen ratkaisu, koska venvillä ei voi (ainakaan kovin helposti) vaikuttaa Pythonin versioon, vaan ainoastaan palikoiden versioihin. Eli jos käyttöjärjestlmän mukana tuleva Python on liian vanha, niin venv ei auta.

Conda, Miniforge yms. on käteviä jos pitää saada oma ympäristö tietyllä Python-versiolla.

 

[ojisama]

Tuo on vain osittainen ratkaisu, koska venvillä ei voi (ainakaan kovin helposti) vaikuttaa Pythonin versioon, vaan ainoastaan palikoiden versioihin. Eli jos käyttöjärjestlmän mukana tuleva Python on liian vanha, niin venv ei auta.

Conda, Miniforge yms. on käteviä jos pitää saada oma ympäristö tietyllä Python-versiolla.

Totta kyllä, että pitää olla ne python versiot asennettuna, mutta käänteisesti venville voi juurikin määrittää, että käytä tätä python versiota tämän palikan ympäristössä, kunhan se on jotenkin asennettu.

Ei tuo kaikkeen toki ideaalinen systeemi ole, ja kontteja suosin monesti.

 

[Makis]

No siis tietysti ongelma oli siinä että en saanut oikeaa versiota asennettua. Ja joku syy x että en edes saanut kääntymään uudempaa, varmaan lopulta olisi onnistunut mutta en työkoneeseen halunnut loputonta määrää uusia kirjastoja.

 

[Lammas]

No siis tietysti ongelma oli siinä että en saanut oikeaa versiota asennettua. Ja joku syy x että en edes saanut kääntymään uudempaa, varmaan lopulta olisi onnistunut mutta en työkoneeseen halunnut loputonta määrää uusia kirjastoja.

Kokeilitko Condaa tai jotain sen sukulaista? Mä olen noilla aina saanut haluamani Python-version asennettua. Dokumentaatiota saattaa vähän joutua lukemaan kun asentaa Condan ekaa kertaa, mutta sen jälkeen kun itse Conda on asennettu, niin uusien ympäristöjen tekeminen haluamallasi Python-versiolla on helppoa.

GitHub - conda-forge/miniforge: A conda-forge distribution.

A conda-forge distribution. Contribute to conda-forge/miniforge development by creating an account on GitHub.

github.com

 

[Barbarossa]

Tuntuu että tässä menee pari asiaa sekaisin. Dockerilla on palvelinprosessimalli, mutta käyttäjän ei tarvi olla root vaan docker-ryhmässä. Jos jollain muulla tekniikalla ajaa ilman root-oikeuksia (siis user namespace), niin eihän sillä voi tehdä samoja asioita ellei jotain kautta anneta root-oikeuksia. Esim. volume-mountit nyt ei taida toimia. Riippuu ihan käyttötapauksen vaatimuksista, miten kannattaa ajaa.

Tiedän että docker komentoja ajetaan normaalisti käyttäjänä joka on docker (tai vastaavassa) groupissa. Daemoni ajetaan silti oletuksena roottina ja jotkut asiat tehdään rootin oikeuksilla, tuon groupin kautta pääsee ainoastaan daemonin sockettiin käsiksi.

Hyvin on podmanilla toiminut volume mountitkin. Ja niinkuin olen tässä jankannut pitempään, minulla on toiminut kaikki, aivan kaikki, mitä olen podmanilla yrittänyt ajaa. Myös docker hubista otetut imaget.

Käyttäkää hyvänen aika dockeria jos siihen olette tyytyväisiä, minulle riittää tästä asiasta jankkaaminen.

 

[Makis]

Kokeilitko Condaa tai jotain sen sukulaista? Mä olen noilla aina saanut haluamani Python-version asennettua. Dokumentaatiota saattaa vähän joutua lukemaan kun asentaa Condan ekaa kertaa, mutta sen jälkeen kun itse Conda on asennettu, niin uusien ympäristöjen tekeminen haluamallasi Python-versiolla on helppoa.

GitHub - conda-forge/miniforge: A conda-forge distribution.

A conda-forge distribution. Contribute to conda-forge/miniforge development by creating an account on GitHub.

github.com

Miten tuo asentaa uudemman Pythonin? Sehän pitää kääntää, joten asentaako se johonkin sandboxiin kaikki tarvittavat työkalut? Vai tuleeko tuolta kaikki mahdolliset Python-versiot valmiiksi käännettynä? Entä wheelit?

Debianissa muuten Python-paketit pitää käytännössä asentaa virtuaaliympäristöön muutenkin.

 

[love_doctor]

Tiedän että docker komentoja ajetaan normaalisti käyttäjänä joka on docker (tai vastaavassa) groupissa. Daemoni ajetaan silti oletuksena roottina ja jotkut asiat tehdään rootin oikeuksilla, tuon groupin kautta pääsee ainoastaan daemonin sockettiin käsiksi.

Hyvin on podmanilla toiminut volume mountitkin. Ja niinkuin olen tässä jankannut pitempään, minulla on toiminut kaikki, aivan kaikki, mitä olen podmanilla yrittänyt ajaa. Myös docker hubista otetut imaget.

Käyttäkää hyvänen aika dockeria jos siihen olette tyytyväisiä, minulle riittää tästä asiasta jankkaaminen.

En ottanut kantaa tuohon, mitä konttitekniikkaa käyttää. Pätee nspawniin ja muihinkin. Lähinnä vaan että podmanin konteksti on user namespace, niin se pakosti rajaa asioita. Yksinkertaiset bind mountit käyttäjän jo näkemiin polkuihin toimivat ja overlayt saadaan kai fusella. Parempihan se aina on, jos samat asiat saa tehtyä ilman pääkäyttäjäoikeuksia.

 

[hrk]

Miten tuo asentaa uudemman Pythonin? Sehän pitää kääntää, joten asentaako se johonkin sandboxiin kaikki tarvittavat työkalut? Vai tuleeko tuolta kaikki mahdolliset Python-versiot valmiiksi käännettynä? Entä wheelit?

Debianissa muuten Python-paketit pitää käytännössä asentaa virtuaaliympäristöön muutenkin.

Yksinkertaisimmillaan Python-sovelluksen asennuspaketti on "wheel", joka sisältää pakattuna sovelluksen lähdekoodin, tiedon sovelluksen ulkoisista vaatimuksista ja tiedon sovelluksen mahdollisista entry pointeista. Ulkoisia vaatimuksia ovat mm. Pythonin ja systeemikirjaston versio sekä muut tarvittavat kirjastot ja niiden versiot.

Etenkin linuxeissa distron mukana tullutta Pythonia ja sen kirjastoja ei pidä muokata. Moni asia voi särkyä. Siksi jokainen distron ulkopuolinen Python-sovellus joko pitää laatia niin, että se ei tarvitse mitään distro-Pythoniin kuulumatonta, tai sitten sovellukselle pitää rakentaa oma Python-ympäristö ("venv"), joka "aktivoidaan" (pannaan polun alkuun) sovellusta käynnistettäessä.

Yksinkertaisin tapa wheel-paketoidun sovelluksen asentamiseen käyttää pipx-nimistä sovellusta, siis esim:

$ sudo apt install pipx
$ pipx install sovellus.paketti.whl

jolloin pipx tekee sovellukselle oman ympäristön, kopioi/linkittää sinne distro-Pythonin systeemikirjastoineen, imuroi tarvittavat lisukkeet ja virittää komennot sovelluksen entry pointeille. Tämä onnistuu jos ja vain jos sovellukselle kelpaa distro-Pythonin versio ja jos distro-Pythonin systeemikirjastosta ei puutu mitään sovelluksen tarvitsemaa.

Distrojen Python saattaa olla melko vanha, ja systeemikirjastosta on usein jätetty jotain "turhaa" joko erikseen asennettavaksi tai kokonaan pois. Distro-Python siis on vain distron omaan käyttöön.

Tätänykyä muodikkain Python-projektien hallintaväline on tuote nimeltä uv, jonka voi asentaa monin tavoin, esimerkiksi pipx-ohjelman avulla:

$ pipx install uv

Kun tämä on tehty, voi wheel-paketin asentaa näin:

$ uv tool install sovellus.paketti.whl

tai jopa

$ uv tool install --python 3.14 sovellus.paketti.whl

jolloin sovellukselle luodaan täydellinen distrosta riippumaton Python-ympäristö.

Lisätietoja:

docs.astral.sh/uv/

---

Jos Python-sovelluksen laatija on nähnyt hiukan enemmän vaivaa, hän on tietysti käärinyt sovelluksen AppImage-pakettiin. Se onnistuu varsin helposti esim. cx_freeze -nimisellä välineellä.

 

[love_doctor]

Distrojen Python saattaa olla melko vanha, ja systeemikirjastosta on usein jätetty jotain "turhaa" joko erikseen asennettavaksi tai kokonaan pois. Distro-Python siis on vain distron omaan käyttöön.

Tätänykyä muodikkain Python-projektien hallintaväline on tuote nimeltä uv, jonka voi asentaa monin tavoin, esimerkiksi pipx-ohjelman avulla:

Pythoniin löytyy monta muutakin paketinhallintaa, josta valita:

egg, fades, pactivate, pae, pdm, pip, pipenv, pip-run, pipsi, pipx, poetry, pyenv, pypi, setup.py, setuptools, uv, uvenv, uvx, virtualenv, wheel.

 

[Makis]

Et nyt edelleenkään vastannut kysymyksiin. Jos nyt oletetaan että muutkin on joskus tehneet jotain Pythonilla niin kysymys on edelleen se, että jos asennan Condan, niin miten se distron Pythonia uudempi Python sinne saadaan? Esimerkiksi tässä koneessa on nyt 3.13.5. Mitäs jos haluaisin käyttää uusinta, joka näyttää olevan 3.14.2, niin miten tuon saa Condaan?

 

[hrk]

Pythoniin löytyy monta muutakin paketinhallintaa, josta valita:

egg, fades, pactivate, pae, pdm, pip, pipenv, pip-run, pipsi, pipx, poetry, pyenv, pypi, setup.py, setuptools, uv, uvenv, uvx, virtualenv, wheel.

Niin? Nuo eivät ole mitenkään rinnastettavia.

 

[hrk]

Et nyt edelleenkään vastannut kysymyksiin. Jos nyt oletetaan että muutkin on joskus tehneet jotain Pythonilla niin kysymys on edelleen se, että jos asennan Condan, niin miten se distron Pythonia uudempi Python sinne saadaan? Esimerkiksi tässä koneessa on nyt 3.13.5. Mitäs jos haluaisin käyttää uusinta, joka näyttää olevan 3.14.2, niin miten tuon saa Condaan?

Asentamalla condaan conda install-komennolla jonkun condan tarjoamista python-versioista. Mutta miksi asentaisit condan? Siis jos vain Pythonista on kysymys? Eikö uv riitä? Tai esim. Poetry? Oletko käyttänyt condaa joskus johonkin?

 

[love_doctor]

Niin? Nuo eivät ole mitenkään rinnastettavia.

Juu, tiedän. Pointti oli lähinnä näyttää, että kun muilla kielillä tilanne on esim cmake tai meson, maven tai gradle, niin "helpolla" Pythonilla on tuo.