Linux-kysymyksiä & yleistä keskustelua Linuxista

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

 

[Lammas]

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.

Sitten kun conda/mamba/miniforge tms. on asennettu ja aktivoitu, niin esim. suorittamalla

conda create -n jokunimi python=3.13
conda activate jokunimi

saat käyttöösi Python 3.13:n.

Tähän ympäristöön voit sitten asennella Python-paketteja haluamallasi menetelmillä. Voi esim. käyttää condaa, tai voi käyttää pipä jos haluaa (ei ehkä kannata sekoittaa eri menetelmiä kuitenkaan).

Conda tai sen sukulaiset ei tietenkään ole ainut vaihtoehto, mutta mainitsin sen aiemmin, koska se on mulle tutuin.

uv:ta olen kuullut kehuttavan, mutta en ole sitä vielä koskaan kokeillut. Poetryä kokeilin joskus kauan sitten ja se oli jotenkin epäselvä. Ehkä se on nykyään parempi.

 

[keskiverto]

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.

A. En tiedä. En halua tietää condasta yhtään enempää kuin on pakko.

B. "Paketinhallinta". Debianissa on paketinhallintatyökalu (apt?) joka osaa ladata verkon "repository:stä" paketti-tiedostoja ja avata niistä ohjelmien tiedostot "oikeaan paikkaan" (eli "asentaa"). Repossa ei kuitenkaan (yleensä) ole "kaikkia ohjemia" (esim. Pythonin moduleita), eikä "oikean paikan" sekaan sovi tiputtaa ties mitä ettei paketinhallinta tipu kartalta.

Virtuaaliympäristö (venv) on mielivaltainen paikka "muualla", jonne "PyPI-reposta" saa asennettua Python moduuleja. Se 'pip' on paketinhallintatyökalu, joka osaa ladata PyPI:stä ja ymmärtää "Python-paketteja" (jotka ovat eri muodossa kuin esim. .deb-paketit), muttei tiedä mitään distron paketinhallinnasta.
Venv:iä luodessa luova Python-binääri (joka on jostain aiemmin asennettu) lisää symlinkit itseensä, jotta ympäristössä "python" käyttää juuri sitä versiota.

Conda on myöskin paketinhallintatyökalu. Käyttisriippumaton, eli ei tiedä distron paketeista. Sillä on kai omat reponsa. Se asentaa sekä Pythonin että moduuleita ja kaiken virtuaaliympäristöihin. Eli: luo venv (ilman Pythonia), hae ja asenna sinne Python (tarvittaessa), hae ja asenna moduuleja (kuin pip). Käännetäänkö joitain binäärejä, vai onko condalla repossa joka paikkaan sopivia? En tiedä. Sen tiedän, että jokainen conda-ympäristö -- pienikin -- sisältää ziljoona tiedostoa, eli conda lataa/asentaa tuhottomasti "paketteja". Kyllä siihen määrään build-työkalutkin hukkuvat.

Jälkimmäisen seurauksena esim. CSC:n HPC-ympäristöön ei saa suoraan asentaa condalla mitään, vaan jokainen conda-asennus pitää tunkea (Apptainer) konttiin. Ympäristön Lustre-tiedostojärjestelmä ei tykkää järjettömästä määrästä pieniä tiedostoja (varsinkin jos jokainen käyttäjä asentaa jotain condalla).

 

[hrk]

Sitten kun conda/mamba/miniforge tms. on asennettu ja aktivoitu, niin esim. suorittamalla

conda create -n jokunimi python=3.13
conda activate jokunimi

saat käyttöösi Python 3.13:n.

Tähän ympäristöön voit sitten asennella Python-paketteja haluamallasi menetelmillä. Voi esim. käyttää condaa, tai voi käyttää pipä jos haluaa (ei ehkä kannata sekoittaa eri menetelmiä kuitenkaan).

Conda tai sen sukulaiset ei tietenkään ole ainut vaihtoehto, mutta mainitsin sen aiemmin, koska se on mulle tutuin.

uv:ta olen kuullut kehuttavan, mutta en ole sitä vielä koskaan kokeillut. Poetryä kokeilin joskus kauan sitten ja se oli jotenkin epäselvä. Ehkä se on nykyään parempi.

Huomasin että conda-tietämykseni on päässyt hieman vanhenemaan, joten asensin semmoisen ubuntuun. Ja kyllä sillä tosiaan Python-version vaihto vaikkapa versioon 3.14.2 sujuu aivan kuten tässä on sanottu. Siis joko valitsemalla environmenttia create-komennolla luotaessa, tai myöhemmin install-komennolla vanhan päälle. Mutta noin muuten meistä ei kyllä tullut ystäviä. Kun ei tämä ole mikään Python-foorumi, en jatka tästä pitempään. Mutta suosittelen kaikille condaa käyttäville tai sitä harkitseville vaihtoehtoihin tutustumista.

 

[takomo]

Kun ei tämä ole mikään Python-foorumi, en jatka tästä pitempään. Mutta suosittelen kaikille condaa käyttäville tai sitä harkitseville vaihtoehtoihin tutustumista.

On tämä sikäli Linux-relevanttia, että Linuxissa näihin Python-temppuratoihin pääsee/joutuu tutustumaan mutta ehkä jatkot sopivat paremmin ohjelmointi-alueelle Ohjelmointi, pelikehitys ja muu sovelluskehitys

Yleisesti Linux-relevanttia on kyllä se, jos nämä aiheuttavat jotain ongelmia kuten rikkovat distroa tai vaarantavat tietoturvaa.

 

[keskiverto]

Yleisesti Linux-relevanttia on kyllä se, jos nämä aiheuttavat jotain ongelmia kuten rikkovat distroa tai vaarantavat tietoturvaa.

Jossa on kaksi osaa:
* Distron normaalista (paketin)hallinnasta poikkeavien kokonaisuuksien asianmukainen asennus korruptoimatta "normaalia sisältöä".
(Kerran näin "ihan oikein" asennetun ylimääräisen, mutta käyttäjä lisäsi sen konffissa PATH:n alkuun. Sattui olemaan Python ja distron 'yum' vaati eri Pythonin.)

* Ylläpito. Distro toimittaa (oletettavasti) tietoturvapäivityksiä, jotka saa jollain helpolla/automaagisella "upgrade" toiminnolla.
Ylimääräiset pitää itse kuulostella ja kaivaa (kuten ensimmäisellä asennuksellakin). Jos se lähde on alun alkaenkaan luotettava.

 

[love_doctor]

Jossa on kaksi osaa:
* Distron normaalista (paketin)hallinnasta poikkeavien kokonaisuuksien asianmukainen asennus korruptoimatta "normaalia sisältöä".
(Kerran näin "ihan oikein" asennetun ylimääräisen, mutta käyttäjä lisäsi sen konffissa PATH:n alkuun. Sattui olemaan Python ja distron 'yum' vaati eri Pythonin.)

Pythonin kanssa se isoin haaste on siinä, että melkein joka distrossa on Pythonilla tehty "perusinfraa", joten tuo versio-ongelma on aika yleinen, jos alkaa devata tai ajaa distron ulkopuolisia ohjelmia. Jos sen oletuksena asennetun Pythonin paskoo, niin koko distro voi hajota siihen.

 

[hrk]

(Kerran näin "ihan oikein" asennetun ylimääräisen, mutta käyttäjä lisäsi sen konffissa PATH:n alkuun. Sattui olemaan Python ja distron 'yum' vaati eri Pythonin.)

Aika hölmöä jos se distron yum luottaa polkuun pythonia etsiessään. Pitäisihän sen tietää, missä oikea distron python asuu.

 

[keskiverto]

Aika hölmöä jos se distron yum luottaa polkuun pythonia etsiessään. Pitäisihän sen tietää, missä oikea distron python asuu.

Totta. Ehkei se ollutkaan polku, vaan jotain muuta -- esim. condan tekemä virtuaaliympäristö.
Arvelisin että distro oli el7 (RHEL tai CentOS). Katsotaanpa, mitä siinä perheessä tehdään:

[el7]# head -1 /usr/bin/yum
#!/usr/bin/python
[el8]# head -1 /usr/bin/dnf-3
#!/usr/libexec/platform-python
[el9]# head -1 /usr/bin/dnf-3
#!/usr/bin/python3.9
[el10]# head -1 /usr/bin/dnf-3
#! /usr/bin/python3 -s

Eivät luota polkuun, mutta el10:n kutsuu "python3", joka ainakin el8:ssa ja el9:ssä voi alternatives:in kautta linkkautua muuhun versioon kuin systeemin peruslieroon.

 

[terpaa]

Jos on Manjarosta kokemuksia ja siinä ollut ongelmia niin en sanoisi että Arch on huono, kuitenkin eri käyttis kyseessä. Vaikka onkin Arch pohjainen niin ei sillä oikeastaan ole mitään tekemistä Archin kanssa.

Manjaro:A Different Kind of Beast

wiki.manjaro.org

Manjaro oman kokemukseni perusteella toimii ihan vakaasti ja päivittyy nätisti. Vanhin asennus minulla on nyt 3v takaa ja kokoajan toiminut/päivittynyt ongelmitta.
Ongelmia varmaan saa aikaiseksi jos alkaa AUR paketteja asentelemaan. Kannattaa pysytellä ihan Manjaron omissa.

 

[Mukava]

Manjaro oman kokemukseni perusteella toimii ihan vakaasti ja päivittyy nätisti. Vanhin asennus minulla on nyt 3v takaa ja kokoajan toiminut/päivittynyt ongelmitta.
Ongelmia varmaan saa aikaiseksi jos alkaa AUR paketteja asentelemaan. Kannattaa pysytellä ihan Manjaron omissa.

Vielä parempi kun pysyy kokonaan erosta, Arch pohjalta kun löytyy paljon parempia variantteja joissa ei tarvitse miettiä koska unohtavat uusia SSL-sertit, tai milloin heidän "viikkoja" jäljessä tulevat paketit rikkovat jotain.

 

[terpaa]

Vielä parempi kun pysyy kokonaan erosta, Arch pohjalta kun löytyy paljon parempia variantteja joissa ei tarvitse miettiä koska unohtavat uusia SSL-sertit, tai milloin heidän "viikkoja" jäljessä tulevat paketit rikkovat jotain.

Itselleni muita ongelmia ole tullut kuin satunnaisesti discord joka oletus konffilla vaatii aina uusimman version että suostuu käynnistämään. Sitä voi joko korjata konffiin ettei pakota uusinta tai ajaa flatpakinä.
Cachyos minulla myös käytössä. Molemmissa puolensa. Ei se aina autuaaksi tee, että aivan uusimmat versiot käytössä sen sijaan että olisi vähän vanhemmat enemmän testatut.

 

[hrk]

Totta. Ehkei se ollutkaan polku, vaan jotain muuta -- esim. condan tekemä virtuaaliympäristö.
Arvelisin että distro oli el7 (RHEL tai CentOS). Katsotaanpa, mitä siinä perheessä tehdään:

[el7]# head -1 /usr/bin/yum
#!/usr/bin/python
[el8]# head -1 /usr/bin/dnf-3
#!/usr/libexec/platform-python
[el9]# head -1 /usr/bin/dnf-3
#!/usr/bin/python3.9
[el10]# head -1 /usr/bin/dnf-3
#! /usr/bin/python3 -s

Eivät luota polkuun, mutta el10:n kutsuu "python3", joka ainakin el8:ssa ja el9:ssä voi alternatives:in kautta linkkautua muuhun versioon kuin systeemin peruslieroon.

Ihanko totta on olemassa /usr/bin/python ilman versionumeroa?

 

[jkaart]

Mikähän distro olisi paras raspberry pi 3:lle, jos käyttötarkoituksena on ajaa pelkkää python ohjelmaa ja sillä ohjata gpiota, mutta wlanin on toimittava myös?
Lähinnä, että onko paras vaan ajaa Raspbiania vai olisiko tähän käyttöön vielä "kevyempää" distroa olemassa?

 

[TemeV]

Mikähän distro olisi paras raspberry pi 3:lle, jos käyttötarkoituksena on ajaa pelkkää python ohjelmaa ja sillä ohjata gpiota, mutta wlanin on toimittava myös?
Lähinnä, että onko paras vaan ajaa Raspbiania vai olisiko tähän käyttöön vielä "kevyempää" distroa olemassa?

Miksipä sen pitäisi olla sen kevyempi, jos resurssit riittää sille sun sovellukselle. Voihan sieltä poistaa sen työpöytäympäristön, jos haluaa keventää. Saikohan sillä Raspberry Pi Os konfiguraattorillakin tehtyä imagen, jossa ei ole työpöytää.

 

[bindi]

Raspberry Pi OS Lite on Debian Headless. Yhtä lailla siinäkin toimii wlan, ei vaan voi konffata kliksuttelemalla.

Raspberry Pi Imagerillahan tuon voi konfiguroida etukäteen. Eli voi sittenkin konffata kliksuttelemalla

 

[jkaart]

Miksipä sen pitäisi olla sen kevyempi, jos resurssit riittää sille sun sovellukselle. Voihan sieltä poistaa sen työpöytäympäristön, jos haluaa keventää. Saikohan sillä Raspberry Pi Os konfiguraattorillakin tehtyä imagen, jossa ei ole työpöytää.

Laitoin testiin DietPi:n ja vaikuttaa näin ens alkuun ainakin aika hyvältä. Periaatteessa tarpeisiin riittäisi ehkä jopa rasperry pi pico, mutta tarve on soittaa audio streamia (web radiota) netistä sekä näyttää kellon aikaa 7 segmentti tai LCD näytöllä. Tuon radion ja ylipäätään äänen ulostulon kanssa saattas mennä aika työlääksi touhu.
Lopputuotos olisi web radiolla varustettu herätyskello.

 

[keskiverto]

Ihanko totta on olemassa /usr/bin/python ilman versionumeroa?

el7 -- RHEL 7 - julkaistiin 2014 (ja loppui 2024, paitsi erityisesti maksaville) ja sen systeemi-python perustui 2.7:ään. Kyllä sitä kutsuttiin yleensä symlinkillä "python", vaikka symlink "python2" ja binääri "python2.7" olivatkin olemassa.

Eikä tässä vielä kaikki. Sekä el9 että el10:een löytyy paketti 'python-unversioned-command', joka antaa symlinkin
/usr/bin/python -> ./python3

Eli kaikissa RHEL (paitsi 8) on (ainakin saatavilla) "/usr/bin/python".

 

[JiiPee]

el7 -- RHEL 7 - julkaistiin 2014 (ja loppui 2024, paitsi erityisesti maksaville) ja sen systeemi-python perustui 2.7:ään. Kyllä sitä kutsuttiin yleensä symlinkillä "python", vaikka symlink "python2" ja binääri "python2.7" olivatkin olemassa.

Eikä tässä vielä kaikki. Sekä el9 että el10:een löytyy paketti 'python-unversioned-command', joka antaa symlinkin
/usr/bin/python -> ./python3

Eli kaikissa RHEL (paitsi 8) on (ainakin saatavilla) "/usr/bin/python".

Toi on fedorassakin.

 

[Barbarossa]

Ihanko totta on olemassa /usr/bin/python ilman versionumeroa?

Miksi ei olisi? Aika useinhan se on symlinkki siihen distron oletuspythoniin, joko suoraan tai jonkun wrapperin kautta, tyyliin alternatives tai python-exec. Varsinkin nyt kun 2.7 on jo ollut useamman vuoden vainaa, viimeinkin, niin python3 on aika tarpeeton jäänne historiasta.

 

[hrk]

Miksi ei olisi? Aika useinhan se on symlinkki siihen distron oletuspythoniin, joko suoraan tai jonkun wrapperin kautta, tyyliin alternatives tai python-exec. Varsinkin nyt kun 2.7 on jo ollut useamman vuoden vainaa, viimeinkin, niin python3 on aika tarpeeton jäänne historiasta.

Pitäisin kiinni periaatteesta, että systeemin python, joita voi olla useita eri versioita, on vain systeemiä varten. Jos käyttäjä haluaa tehdä omia python-skriptejä, hän voi luoda itselleen venvin, jossa tulkin nimi on oletusarvoisesti pelkkä python. Eli siis varaisin python-nimen tarkoittamaan sellaista pythonia, jota saa vapaasti käyttää ja muokata.

Debian-sukuisissa distroissa pelin henki on juuri tämä. Talon puolesta ei ole tarjolla komentoa "python".

 

[keskiverto]

Debian-sukuisissa distroissa pelin henki on juuri tämä. Talon puolesta ei ole tarjolla komentoa "python".

RHEL 8 kävi vielä pidemmällä. Oletuksena asentuu vain /usr/libexec/platform-python ja käyttäjille ei mitään.
Halutessa saa paketeista komennot python3.6 (->/usr/libexec/platform-python), python2.7, python3.8, python3.9, python3.11 ja python3.12.
"python3" taitaa linkata viimeksi asennettuun python3.x versioon.

Tuo oli selkeä, mutta eipä jatku (RHEL 9/10).

 

[Barbarossa]

Pitäisin kiinni periaatteesta, että systeemin python, joita voi olla useita eri versioita, on vain systeemiä varten. Jos käyttäjä haluaa tehdä omia python-skriptejä, hän voi luoda itselleen venvin, jossa tulkin nimi on oletusarvoisesti pelkkä python. Eli siis varaisin python-nimen tarkoittamaan sellaista pythonia, jota saa vapaasti käyttää ja muokata.

Debian-sukuisissa distroissa pelin henki on juuri tämä. Talon puolesta ei ole tarjolla komentoa "python".

Minusta /usr/bin hakemisto ei ylipäätään ole tarkoitettu käyttäjän omille virityksille. Se mitä sinne laitetaan, on järjestelmän tavaraa. Eli /usr/bin/python aivan pätevä symlink oletuspythonille.

Itseasiassa FHS:n mukaisesti /usr/bin/python tulisi olla olemassa mikäli Python-tulkki on asennettuna.

 

[hrk]

Minusta /usr/bin hakemisto ei ylipäätään ole tarkoitettu käyttäjän omille virityksille. Se mitä sinne laitetaan, on järjestelmän tavaraa. Eli /usr/bin/python aivan pätevä symlink oletuspythonille.

Niin tietysti.

Itseasiassa FHS:n mukaisesti /usr/bin/python tulisi olla olemassa mikäli Python-tulkki on asennettuna.

Siis jotta distron paketoidut skriptit toimisivat. Käytännössä kuitenkin kaikki skriptit nykyään käyttävät muotoa python3, joka on edelleen symlinkattu varsinaiseen python-tulkkiin, joka edessäni olevassa Ubuntussa näyttää olevan python3.13, eli jo hiukan ikääntynyt.

Debian luopui versionumerottomasta python-linkistä versiossa 11, vuonna 2021. RHEL teki saman versiossa 8 jo vuonna 2019, tosin tuossa versiossa ei varsinaista pythonia asennettu oletusarvoisesti lainkaan, sensijaan oli, ehkä on vieläkin, erityinen "platform-python" sisäiseen käyttöön, ei lainkaan huono idea. Jos siis numeroimattomia python-linkkejä vielä jossain näkyy, niin se on paikallisten ylläpitäjien syytä.

Python ei ole mikään unix/linux "subsystem", vaan laajalti käytetty ohjelmointijärjestelmä, joka elää ja kehittyy linux-distrosta riippumatta. Jos ja kun linuxia käytetään python-sovellusten kehittämiseen, halutaan tietenkin käyttää ajanmukaista Python-versiota ja ajanmukaisia kirjastoja, sellaisiakin, joita distron python ei lainkaan tunne. Sekaannusten välttämiseksi tarvitaan järkevä nimeämispolitiikka.

 

[love_doctor]

Laitoin testiin DietPi:n ja vaikuttaa näin ens alkuun ainakin aika hyvältä. Periaatteessa tarpeisiin riittäisi ehkä jopa rasperry pi pico, mutta tarve on soittaa audio streamia (web radiota) netistä sekä näyttää kellon aikaa 7 segmentti tai LCD näytöllä. Tuon radion ja ylipäätään äänen ulostulon kanssa saattas mennä aika työlääksi touhu.
Lopputuotos olisi web radiolla varustettu herätyskello.

DietPi on tähän oikea vastaus. On todella kevyt rpi tradingin bloattidistroihin verrattuna. Huomaa ihan (h)top-käskyllä kun prosessilista mahtuu vga-näytölle.

 

[oho_hups]

Olisi pari probleemaa joissa kaipaisin apua, toisaalta ongelmat saattavat ehkä liittyä toisiinsa.

Tietokoneeni jää satunnaisesti käynnistäessä jumiin seuraavaan kohtaan:

Normaalisti tuon alimmaisen tekstin jälkeen näyttö menee sekunniksi pimeäksi ja resoluutio vaikuttaisi vaihtuvan, ilmeisesti amdgpu ajuri latautuu päälle?
Mutta miksi se latautuu välillä mutta toisinaan taas ei lataudu? Jos on joku bitti poikittain jossain niin maalaisjärjellä ajateltuna toimisi samalla tavalla jokaisella käynnistyskerralla?
Arvioisin että puolet käynnistyskerroista tuo jää jumiin tuohon kohtaan.

No sitten päästään siihen yllä mainitsemaani toiseen ongelmaan.
Ajattelin että jos pistän tietokoneeni vain aina suspend tilaan enkä sammuta sitä niin ongelmahan on sillä ratkaistu.
Mutta suspendista tietokonetta herättäessä näyttöön tulee "no signal" ja sitten muuttuu takaisin mustaksi ja sellaisena pysyy. Tämä tosin tapahtuu joka kerta eikä siinä ole samaa ilmiötä että välillä jäisi näyttö pimeäksi ja välillä ei.

Molemmat ongelmista tosiaan ehkä vaikuttaisi liittyvän siihen että jotain häsmäkkää amdgpu ajurissa. En tosin itse osaa lähteä asiaa ratkomaan joten apua kaipaisin.

AMD 7900XTX
7800X3D
Asus B650-PLUS, viimeisin bios päivitys asennettuna.
Ubuntu 24.04.1 LTS
Kernel 6.8.0-45

Tämä ongelma ratkesi.

Hiustenkuivaajaa virtalähteen kylkeen 30 sekkaa ja sitten käyntiin.
Tarvis varmaan asentaa joku lohkolämmitin.

 

[love_doctor]

Miksi ei olisi? Aika useinhan se on symlinkki siihen distron oletuspythoniin, joko suoraan tai jonkun wrapperin kautta, tyyliin alternatives tai python-exec. Varsinkin nyt kun 2.7 on jo ollut useamman vuoden vainaa, viimeinkin, niin python3 on aika tarpeeton jäänne historiasta.

Muistan kun muutamia vuosia sitten Archissa ilmeni ongelmia, kun 'python' alkoi viitata kolmoseen, niin moni skripti hajosi. Kun selvittelin asiaa, monessa paikassa vastaus oli että lopeta paskadistrojen (=Arch) käyttö ja python 2.x 4ever!!11. Joidenkin arduino/esp/arm sdk-juttujen yms. asentelu oli ihan perseestä kun osa skripteistä halusi python 3:n ja osa python 2:n ja vain python 2:lla toimi molemmat skriptit. Esim. Calibren kehittäjä julisti 2016, että aikoo ylläpitää omaa forkkia python 2:sta, jos python 3 joskus tulee yleistymään. Voi noita aikoja. Onneksi nyt aika moni denialistikin on hyväksynyt maailman kehittymisen.

 

[Barbarossa]

Tämä ongelma ratkesi.

Hiustenkuivaajaa virtalähteen kylkeen 30 sekkaa ja sitten käyntiin.
Tarvis varmaan asentaa joku lohkolämmitin.

Alkaa virtalähde tekemään kuolemaa, vähän erikoisemmalla tavalla vaan ilmeisesti.

Minulla oli joskus pari vuosikymmentä sitten koneessa virtalähde finaalissa, jos koneen sammutti niin se ei enää lähtenyt käyntiin. Piti napata virtalähteen kytkimestä virta pois vartiksi, sen jälkeen konejumalan loitsuja messuten suorittaa Käynnistyksen Rituaali, kytkimestä virta päälle ja välittömästi painaa myös virtanappia. Jos konejumala oli armollinen, käynnistyi kone. Jos ei, niin viipymättä kytkimestä taas virta pois, takaisin päälle ja virtanappia uudestaan. Muutaman toiston jälkeen yleensä lähti päälle.

Köyhällä opiskelijalla ei ollut varaa uusia sitä...

 

[Barbarossa]

Muistan kun muutamia vuosia sitten Archissa ilmeni ongelmia, kun 'python' alkoi viitata kolmoseen, niin moni skripti hajosi. Kun selvittelin asiaa, monessa paikassa vastaus oli että lopeta paskadistrojen (=Arch) käyttö ja python 2.x 4ever!!11. Joidenkin arduino/esp/arm sdk-juttujen yms. asentelu oli ihan perseestä kun osa skripteistä halusi python 3:n ja osa python 2:n ja vain python 2:lla toimi molemmat skriptit. Esim. Calibren kehittäjä julisti 2016, että aikoo ylläpitää omaa forkkia python 2:sta, jos python 3 joskus tulee yleistymään. Voi noita aikoja. Onneksi nyt aika moni denialistikin on hyväksynyt maailman kehittymisen.

Vähäsen takia kai se python3 tulikin, mutta varsinainen syypäähän oli python kun siinä ei ollut mitään taaksepäinyhteensopivuutta. Ja on edelleenkin kun samaa lahjaa saadaan nauttia näinäkin päivinä kun ei edes minor versiot ole yhteensopivia keskenään. Puhumattakaan pythonin pakettihelvetistä.

Henk koht ärsyttää että tällaisella purkkascriptitulkilla on alettu tekemään oikeita sovelluksiakin. Calibre on hyvä esimerkki jengatornista johon sen käyttö johtaa, kaikki python-sonta ja niiden tarvitsemat kirjastot pitää paketoida samaan läjään.

Muistan kyllä tuon Kovid Goyalin mahtipontisen julistuksen, se ainoastaan vahvisti jo aiemmin sällin kommenttien lukemisen synnyttämää kuvaa kroonista ureakefaliaa ja turvonnutta omakuvaa potevasta tapauksesta. Ei tainnut kuitenkaan paukut riittää kun myöhemmin vähin äänin tehtiin migraatio python3:een.