Linux-kysymyksiä & yleistä keskustelua Linuxista

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

 

[_zimppa_]

Onko joku foorumin käyttäjistä saanut Ente Auth sovelluksen toimimaan MX Linuxissa.

Yritän siirtyä vaiheittain pois Windows-ympäristöstä kohti Linuxia ja se "oma" distro on hakusessa. Linux osaaminen on hyvin rajoittunutta (tai en nyt muutenkaan ole mikään ICT-velho) ja pohjautuu lähinnä youtube tutoriaaleihin sekä chatgpt tukeen.

Olen 2. läppärillä (Surface 3 pro) kokeillut Cachy OS, Kubuntu sekä Zorin OS:ää, ja pari päivää sitten asensin MX Linuxin (KDE) testiin. Edellisillä distroilla olen saanut Ente Auth-sovelluksen toimimaan mutta MX Linuxin kanssa on melkoisia haasteita. Kun sovelluksen käynnistää, avautuu se vain mustaan tyhjään ikkunaan. Olen googlen ja chatgpt:n avulla olen asentanut gnome keyring:in ja lukuisia muitakin terminaalikomentoja laittanut perään mutta silti käyttö jämähtää mustaan ruutuun.

 

[hrk]

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.

Kyllä Python 3 on nimenomaan taaksepäin yhteensopiva, eli se mikä toimii vanhassa, toimii myös uudessa. Pääsääntöisesti. Pakettihelvetti? Sä et vaan osaa. Se on opensourcea, testaa itse.

Kun Pythonilla tai millä tahansa tehtyä sovellusta jaetaan kehitysympäristönsä ulkopuolelle, niin "sonta" pitää tietysti paketoida asianmukaisesti. Linuxissa tarvittaessa jopa flatpakiksi/snapiksi/appimageksi, jolloin ei ulospäin lainkaan näy, että Pythonista on kysymys. Distron Pythonin varaan ei voi sovellusta rakentaa.

 

[Barbarossa]

Sä et vaan osaa. Se on opensourcea, testaa itse.

Hienosti osasit perustella

 

[JiiPee]

Kun Pythonilla tai millä tahansa tehtyä sovellusta jaetaan kehitysympäristönsä ulkopuolelle, niin "sonta" pitää tietysti paketoida asianmukaisesti. Linuxissa tarvittaessa jopa flatpakiksi/snapiksi/appimageksi, jolloin ei ulospäin lainkaan näy, että Pythonista on kysymys. Distron Pythonin varaan ei voi sovellusta rakentaa.

Kuvastaa hienosti millainen sontakasa koko python on.

 

[kaakau<"'\\/>]

Onko joku foorumin käyttäjistä saanut Ente Auth sovelluksen toimimaan MX Linuxissa.

Yritän siirtyä vaiheittain pois Windows-ympäristöstä kohti Linuxia ja se "oma" distro on hakusessa. Linux osaaminen on hyvin rajoittunutta (tai en nyt muutenkaan ole mikään ICT-velho) ja pohjautuu lähinnä youtube tutoriaaleihin sekä chatgpt tukeen.

Olen 2. läppärillä (Surface 3 pro) kokeillut Cachy OS, Kubuntu sekä Zorin OS:ää, ja pari päivää sitten asensin MX Linuxin (KDE) testiin. Edellisillä distroilla olen saanut Ente Auth-sovelluksen toimimaan mutta MX Linuxin kanssa on melkoisia haasteita. Kun sovelluksen käynnistää, avautuu se vain mustaan tyhjään ikkunaan. Olen googlen ja chatgpt:n avulla olen asentanut gnome keyring:in ja lukuisia muitakin terminaalikomentoja laittanut perään mutta silti käyttö jämähtää mustaan ruutuun.

Oletko koittanut käynnistää terminaalista? Siinä voisi näkyä jotain virheitä. Ja vilkaiset näkyykö journalctl-komennolla jotain siihen liittyvää.

 

[Makis]

Kyllä Python 3 on nimenomaan taaksepäin yhteensopiva, eli se mikä toimii vanhassa, toimii myös uudessa. Pääsääntöisesti. Pakettihelvetti? Sä et vaan osaa. Se on opensourcea, testaa itse.

Nimenomaan puheenaolleessa tapauksessa ei ollut. Kakkosen skriptit toimii heikonlaisesti Python3:ssa. Ja tuohan se hidasti vuosikausia kolmosen käyttöönottoa kun skriptit piti kirjoittaa uusiksi.

 

[love_doctor]

Nimenomaan puheenaolleessa tapauksessa ei ollut. Kakkosen skriptit toimii heikonlaisesti Python3:ssa. Ja tuohan se hidasti vuosikausia kolmosen käyttöönottoa kun skriptit piti kirjoittaa uusiksi.

Python 2.7 on eniten noista vanhoista yhteensopiva 3:n kanssa. On mahdollista siis kirjoittaa sellaista koodia, joka toimii molemmissa. Mutta, se ehdottomasti vaatii koodin kirjoittamista Python3-tietoisesti. Esim. sulut printin jälkeen. Ilman sulkuja toimii vain kakkosessa ja ei ollenkaan kolmosessa. Tuo sulkujen käyttö ei ole mitenkään idiomaattista Python2:ssa. Haskellissakin voi laittaa sulkuja funktion parametrin ympärille, mutta ei kukaan sellaista tee.

Silloin kun kolmoseen oltiin siirtymässä, osa ei ollut vielä päivittänyt koodiaan 2.7-aikaankaan ja aika paljon paketteja yksinkertaisesti ei toiminut. Esim. jotkin tavutasolla binääridatan käsittelyt. Ja tosiaan syntaksin osalta tarvii tehdä aika monta muutosta, vaikka niihinkin on työkaluja.

Tämähän on ihan eri tavalla yhteensopivaa kuin vaikka Javassa. Javassa menee niin, että jos on ikivanhalle Javalle tehty ohjelma, niin se toimii uusimmallakin Javalla hyvin todennäköisesti. Jossain tapauksessa vaikkapa 30 vuotta vanha koodi ei käänny uusimmalla Javalla, mutta jos sen on kääntänyt vanhemmalla kääntäjällä joskus, se tavukoodi toimii. Esim. kun Java 5:een tuli geneerisyys, edelleen vanha ei-geneerinen koodikin kääntyy 2026 Javalla, vaikkakin varoituksien kanssa. Tuosta geneerisyyden lisäämisestäkin on jo 20 vuotta aikaa.

 

[hrk]

Nimenomaan puheenaolleessa tapauksessa ei ollut. Kakkosen skriptit toimii heikonlaisesti Python3:ssa. Ja tuohan se hidasti vuosikausia kolmosen käyttöönottoa kun skriptit piti kirjoittaa uusiksi.

Kyllä, mutta Python kolmosen (minor) versiot pyritään pitämään taaksepäin yhteensopivina, siis keskenään. Pääsääntöisesti, mikä tarkoittaa että poikkeuksia on, mistä seuraa, että linuxien skripteissään käyttämät distro-pythonit ovat aina hiukan vanhoja.

 

[Makis]

Python 2.7 on eniten noista vanhoista yhteensopiva 3:n kanssa. On mahdollista siis kirjoittaa sellaista koodia, joka toimii molemmissa. Mutta, se ehdottomasti vaatii koodin kirjoittamista Python3-tietoisesti. Esim. sulut printin jälkeen. Ilman sulkuja toimii vain kakkosessa ja ei ollenkaan kolmosessa. Tuo sulkujen käyttö ei ole mitenkään idiomaattista Python2:ssa. Haskellissakin voi laittaa sulkuja funktion parametrin ympärille, mutta ei kukaan sellaista tee.

Ongelma ei siis ollut uudet skriptit vaan se jo silloin iso kasa koodia joka oli kirjoitettu ennen 3-aikaa. Oli paljon koodia, jota ei vaan kannattanut alkaa kirjoittamaan uusiksi vain jotta sitä voi ajaa kolmosella. Guidokin on myöntänyt että siirtymä kesti paljon pidempään kuin he arvioivat.

 

[_zimppa_]

Oletko koittanut käynnistää terminaalista? Siinä voisi näkyä jotain virheitä. Ja vilkaiset näkyykö journalctl-komennolla jotain siihen liittyvää.

Asensin flatpak version terminaalissa ja kokeilin käynnistää sovelluksen terminaalissa. "Vastauksena" tulee pari sivua pitkä virheilmoitusten sekamelska (näin maallikon silmin) ja itse sovellus käynnistyy mustassa ikkunassa. Netissä on kyllä kirjoituksia, että ollut linuxisa ongelmia mutta itse en niistä ole ollut tietoinen, koska aikaisemmissa distroissa on se asentunut ilman ogelmia.

Edit: Kokeilin vielä AppImage -versio yhtä huonolla menestyksellä. Chatgpt totesi (virheilmoituksen nähtyään), että kannattaa odottaa softan päivitystä, koska monilla on samoja ongelmia (myös muissakin distroissa) ja käyttää Ente Auth:n webversiota.

 

[keskiverto]

Sekaannusten välttämiseksi tarvitaan järkevä nimeämispolitiikka.

Eikä järkevä, "future-proof" ja yhtenäinen nimeäminen ole helppoa.

"Käyttäjän" kannalta on helpompaa kun on yksi (versioton) nimi paketilla ja komennolla. Esim. "php" tai "python". Tästä tietenkin paketinhallinnassa seuraa, ettei systeemiin asennu kuin yksi versio kerrallaan. Jos/kun distro päivittää paketin versiota, kaikki siitä komponentista riippuvat ohjelmat täytyy tarkastaa muutosten varalta.

Distro pystyy asentamaan useamman version jos niillä on omat nimet, mutta sitten käyttäjien täytyy oppia enemmän. Tosin se #!/usr/bin/python3.8 skriptissä olisi selkeämpi jälkikäteenkin.

Toinen lähestymistapa on asentaa "hyötyohjelmat" erilleen systeemistä. Silloin kukin voi käyttää samaa nimeämistä. Virtuaaliympäristöt ja kontit ovat tapoja tehdä tämä. Enää jää keksittäväksi helpoin tapa viitata tiettyyn versioon. HPC-ympäristöissä se on ollut yleensä Environment Modules.

 

[JiiPee]

Distro pystyy asentamaan useamman version jos niillä on omat nimet, mutta sitten käyttäjien täytyy oppia enemmän. Tosin se #!/usr/bin/python3.8 skriptissä olisi selkeämpi jälkikäteenkin.

Tuossa ei omasta mielestä ole mitään järkeä, ellei sitten se purkka ole sellainen että se toimii ainoastaan sillä yhdellä ainoalla jööti versiolla. Mutta jos se purkka toimii käytännössä millä tahansa kolmos sarjan jöötillä niin kyllä se ihan pelkkä python taikka python3 on mielestäni se parempi vaihtoehto. Toi että aletaan jokin tietty versio laittamaan purkkaan aiheuttaa sen että sitten asennellaan ihan turhaan eri versioita jöötistä vaikka sillä yhdelläkin versiolla tulisi toimeen. Kuten tuossa jo aiemmin mainittiin niin kolmos jöötin kanssa tilanne on parantunut kun pääsääntöisesti on alespäin yhteensopiva.

 

[keskiverto]

Vaihda esimerkissä sanan "python" tilalle joku muu, vähemmän eestaas yhteensopiva. Eihän me tässä nyt keskitytä mihinkään tiettyyn ohjelmaan/kirjastoon.

 

[Ezzy]

Satuin törmäämään hyvään listaan erilaisia terminaali-sovelluksia, tai siis lähinnä terminaaliversioita vaikka mistä softista (Spotify, Discord, Youtube jne.) ja kirjasto-projekteja niiden kehittelyyn jne.: GitHub - rothgar/awesome-tuis: List of projects that provide terminal user interfaces

 

[Matkatavara]

Asensin flatpak version terminaalissa ja kokeilin käynnistää sovelluksen terminaalissa. "Vastauksena" tulee pari sivua pitkä virheilmoitusten sekamelska (näin maallikon silmin) ja itse sovellus käynnistyy mustassa ikkunassa. Netissä on kyllä kirjoituksia, että ollut linuxisa ongelmia mutta itse en niistä ole ollut tietoinen, koska aikaisemmissa distroissa on se asentunut ilman ogelmia.

Edit: Kokeilin vielä AppImage -versio yhtä huonolla menestyksellä. Chatgpt totesi (virheilmoituksen nähtyään), että kannattaa odottaa softan päivitystä, koska monilla on samoja ongelmia (myös muissakin distroissa) ja käyttää Ente Auth:n webversiota.

En ole varma vaikuttaako Flatpack tai AppImage ohjelmissa, mutta uusimmassa MX Linux 25 versiossa on 23 versiosta poiketen erikseen systemd ja sysvinit eri imagena. Testauksessa olevassa 25.1 versiossa pitäisi olla mahdollista valita käynnistyksen yhteydessä kumpaa haluaa käyttää. Ilmeisesti pieni osa ohjelmistoista olettaa käytössä olevan systemd ja eivät välttämättä toimi jos sysvinit on käytössä.

 

[oho_hups]

Jagged Alliance 3 ja Wayland ei oikein tunnu tulevan toimeen keskenään.

Koko näytöllä FPS kyykkää merkittävästi aina kun hiiren kursoria liikuttaa, pitäessä hiiren paikallaan ja käyttäen vaikkapa näppäimistön painikkeita kameran liikuttamiseen ongelmia ei ole. V-sync päällä FPS puolittuu 60-> 30 kursorin liikutuksella, V-sync pois päältä FPS pysyy tasaisena +100fps mutta silminnähden se ei pidä paikkaansa sillä kuva selvästi tökkii kursoria liikuttaessa siinä määrin että tekee lähes kelvottoman pelata.

Ikkunatilassa ei tee mieli pelata, sillä olen tottunut liikuttamaan ylhäältä päin kuvattujen pelien kameraa viemällä kursori näytön reunaan. Tämä ei tietysti ole ikkunatilassa oikeastaan mahdollista.

Kirjautuessa sisään X11 istuntoon ongelmaa ei esiinny, joten siitä päättelin että tämä on nyt joku Waylandiin liittyvä juttu.

Joten mistä ongelma Waylandin kanssa johtuu ja mitenköhän sen korjaisin?
Tai vaihtoehtoisesti jotain helpohkoa niksiä miten saan juuri Jagged Alliancen käynnistymään X11 kautta vaikka on kirjautuneen Wayland istuntoon?

Näyttiksenä RX9700XTX
Ubuntu 24.04, 6.8.0-90-generic
Resoluutio 3840x2160, Ubuntun näyttöasetuksista skaalaus 200% oli päällä mutta ei vaikutusta onko 100% vai 200%
Ei vaikutusta onko toinen näyttö kytkettynä kiinni vai ei.
Steamin "-fullscreen" käynnistyskomennolla ei vaikutusta.
Protontricksin avulla vääntelin erilaisia näyttöön ja resoluution liittyviä asetuksia, sekä myös eri Windows versioita, näilläkään ei vaikutusta.

Jos se liittyy asiaan millään tavalla, niin mainitsen vielä että kun käynnistän pelin niin peli avautuu siten että pelin reunalla näkyy Windowsin ikkunan reunat(eli siis oikeassa yläkulmassa pienennä, suurenna/palauta, sulje painikkeet jne.) Pelin asetuksista kääntämällä ensin pelin ikkunatilaan ja takaisin koko näytön tilaan peli näyttää menevän oikein koko näytölle.

 

[HendriXXX]

Ubuntu 24.04 version Gnome/mutter/wayland combossa on tympeitä bugeja tällä hetkellä, itse vasta niitä pähkäilin. X11 käyttämällä niitä ei esiintyny. Asensin sitten plasma-desktopin minimi asennuksena, ni kaikki ropleemat katosi ku mutteria ei ole, eli siihen taisi liittyä ne. Nyt ne DE:t on rinnakkain vielä. Toistensa softat piilotettu GitHub - benklop/hideapps scriptillä.. muutamia tosin ostin takaisin käyttöön plasman puolella ku en jaksanu ettiä kden vastaavia.

 

[Ezzy]

Jagged Alliance 3 ja Wayland ei oikein tunnu tulevan toimeen keskenään.

Koko näytöllä FPS kyykkää merkittävästi aina kun hiiren kursoria liikuttaa, pitäessä hiiren paikallaan ja käyttäen vaikkapa näppäimistön painikkeita kameran liikuttamiseen ongelmia ei ole. V-sync päällä FPS puolittuu 60-> 30 kursorin liikutuksella, V-sync pois päältä FPS pysyy tasaisena +100fps mutta silminnähden se ei pidä paikkaansa sillä kuva selvästi tökkii kursoria liikuttaessa siinä määrin että tekee lähes kelvottoman pelata.

Ikkunatilassa ei tee mieli pelata, sillä olen tottunut liikuttamaan ylhäältä päin kuvattujen pelien kameraa viemällä kursori näytön reunaan. Tämä ei tietysti ole ikkunatilassa oikeastaan mahdollista.

Kirjautuessa sisään X11 istuntoon ongelmaa ei esiinny, joten siitä päättelin että tämä on nyt joku Waylandiin liittyvä juttu.

Joten mistä ongelma Waylandin kanssa johtuu ja mitenköhän sen korjaisin?
Tai vaihtoehtoisesti jotain helpohkoa niksiä miten saan juuri Jagged Alliancen käynnistymään X11 kautta vaikka on kirjautuneen Wayland istuntoon?

Näyttiksenä RX9700XTX
Ubuntu 24.04, 6.8.0-90-generic
Resoluutio 3840x2160, Ubuntun näyttöasetuksista skaalaus 200% oli päällä mutta ei vaikutusta onko 100% vai 200%
Ei vaikutusta onko toinen näyttö kytkettynä kiinni vai ei.
Steamin "-fullscreen" käynnistyskomennolla ei vaikutusta.
Protontricksin avulla vääntelin erilaisia näyttöön ja resoluution liittyviä asetuksia, sekä myös eri Windows versioita, näilläkään ei vaikutusta.

Onko sulla siis Wayland Protonista päällä Proton-GE:ssä vai käytätkö normaalia XWaylandia?

 

[Jaguafgeg]

Nyt tuli Vulkan working groupilta uusi versio Vulkan specseistä, jossa mm. VK_EXT_descriptor_heap

VK_EXT_descriptor_heap(3) :: Vulkan Documentation Project

docs.vulkan.org

Change log for January 23, 2026 Vulkan 1.4.340 spec update: · KhronosGroup/Vulkan-Docs@87e6442

Github Issues * Fix copy/paste error in WSI chapter (public PR 2643). * Adjust XML dependency for VK_KHR_swapchain_maintenance1 (public PR 2646). Internal Issues * Fix <<fragmentdens...

github.com

Ja Nvidia julkaisi Vulkan Beta -ajurit jossa mm. VK_EXT_descriptor_heap tuettuna

Vulkan Driver Support

Get the latest Vulkan 1.4 general release drivers and developer beta drivers.

developer.nvidia.com

Tämän julkaisun myötä stäckissä kehittäjät ovat alkaneet laittaa tavaraa yleiseen jakoon
DXVK pull request

Descriptor Heaps by doitsujin · Pull Request #5465 · doitsujin/dxvk

Adds yet another binding model implementation based on VK_EXT_descriptor_heap and enables it by default. Obviously this is going to need support from both Wine and graphics drivers, but if everythi...

github.com

vkd3d-proton vaatii isompia muutoksia koodissa niin sieltä ei vielä ole mitään tullut ulos.

Ja mikä tästä tekee mielenkiintoisen niin tämä ruljanssi on d3d12 -> vulkan käännöstä avittamaan pääasiassa nvidian ja intelin näytönohjaimilla, pelistä riippuen tehoja voi mennä hukkaan kun käännöstä ei ole ennen saatu tehtyä optimaalisella tavalla.
Nähtäväksi jää paljonko tämän jälkeen on tehoeroa natiivina windowsissa ajettuihin peleihin, ja kehitys loppukäyttäjille valmiiksi paketiksi kestänee vielä jonkun viikon.

 

[oho_hups]

Onko sulla siis Wayland Protonista päällä Proton-GE:ssä vai käytätkö normaalia XWaylandia?

Normaalisti XWayland.
Mutta kysymyksesi innoittamana ehdin tulla jo tuosta toiveikkaaksi. Latasin viimeisimmän Proton-GE ja käynnistysasetuksiin "PROTON_ENABLE_WAYLAND=1 %command%"
No eipä se silläkään toiminut, edelleen FPS romahtaa kun hiirtä liikuttaa.

 

[Bugtastic]

Normaalisti XWayland.
Mutta kysymyksesi innoittamana ehdin tulla jo tuosta toiveikkaaksi. Latasin viimeisimmän Proton-GE ja käynnistysasetuksiin "PROTON_ENABLE_WAYLAND=1 %command%"
No eipä se silläkään toiminut, edelleen FPS romahtaa kun hiirtä liikuttaa.

Oletko tutkinut mitä temppuja muut ovat tehneet ja raportoineet ProtonDB:hen?

https://www.protondb.com/app/1084160

 

[oho_hups]

Oletko tutkinut mitä temppuja muut ovat tehneet ja raportoineet ProtonDB:hen?

https://www.protondb.com/app/1084160

Noniin, tuoltahan löytyi viesti parin vuoden takaa

gamescope -W 3840 -H 2160 -r 100--rt --steam --fullscreen -- %command%

Ja sillä rupesi homma toimimaan!!

 

[Dudem]

Siirretty paikallisen AI:n kokoonpanot keskusteluun.

Eli tekisi tässä jossain kohtaa mieli vähän omalla koneella testata paikallisia tekoäly härväilyitä (esim. kuvien ja koodin luontia) ja näytönohjaimena on Intelin ARC B580 jolla sinänsä pitäisi asiat onnistua, ei ehkä ihan niin kätevästi kuin esim. Nvidialla ja AMD:lla mutta kuitenkin. Jäin pohtimaan hyötyisinkö jos laittaisin lisäksi koneeseen toiseksi näytönohjaimeksi vanhan GTX 1660 Superin (PCIe 3.0 x4 väylään, nykyisessä B550 emolevyssä löytyy 2 kpl x16 väyliä, mutta vain toinen on sähköisesti täysi x16, se ensimmäinen) ja saako näitä edes yhteistyöhön? ARC hoitaisi tekoälyt ja 1660 taas sitten muut asiat konetta käytettäessä. Tällä hetkellä käytössä on Fedora 43 + KDE, mutta mitä on tullut luettua jokusen verran asiasta, niin ymmärtääkseni Ubuntulla tekoäly + ARC-näytönohjaimet on se parempi/paras vaihtoehto.

Muut komponentit: CPU on R5 5600, 16 Gb 3200MHz muistia ja KC3000 1Tb NVMe massamuistia, tarvittaessa tökkään toisen samanlaisen 1 Tb:n NVMe:n koneeseen jos tarvetta lisätilalle tulee. Ja Corsairin RM750x virtalähde.