Hyviä lähteitä, mistä oppia Linux "application developer" -tasolla?
En halua tietää kernelistä juurikaan muuta kuin sen API:n. Onko se sitten pelkästää glibc?
Aloin lukemaan jo esim. .AppImage:jen tekemisestä. Aiemmin olen vain osannut kääntää Make:lla tai CMake:lla ohjelmia.
Aika epäselvä toive. Linux on suuri ja osaaminen riippuu tavoitteista, ja eri osa-alueita käsitellään varmasti eri lähteissä.
Oikeasti harvoin tarvitsee tietää mitään kernelistä tai sen rajapinnoista tai edes nimenomaan Linuxista, vaan järkevämpää on käyttää jotain sopivaa kirjastoa, jossa tietty asia on tehty helpoksi (ja ehkä usealle alustalle portattavaksi) ja harvinaisempia vaihtoehtoja karsittu.
Yksittäisiä työkaluja kuten AppImage voi opetella niiden omista ohjeista. AppImage ei ole Linux, ja kun mainitsit tämän yhdessä kernelin kanssa, on vielä vaikeampi arvata, mitä haluat oppia.
Ehkä kannattaa aloittaa Wikipediasta: https://en.m.wikipedia.org/wiki/
Entä onkohkan sellaisia kirjastoja, jotka toimivat kaikille seuraaville:
Ubuntu, Rocky Linux, CentOS ja Debian.
Vai onko GTK ainoa lippuni?
Se miksi aloitin kernelistä on, että uskoin, että tällaista frameworkia ei ole, joten tulisi tietää kerneliä sen verran, että voi paikata puuttuvat osat esim. Rocky:lla. Minulla ei ole kokemusta siitä, mutta usein pienemmät Linux-jakelut ovat niin köyhästi tuettuja, että niissä ainoa vakaasti toimiva non-C GUI-kirjasto voi olla Python GUI-kirjasto.
mavavilj kirjoitti:
Minulla ei ole kokemusta siitä, mutta usein pienemmät Linux-jakelut ovat niin köyhästi tuettuja, että niissä ainoa vakaasti toimiva non-C GUI-kirjasto voi olla Python GUI-kirjasto.
Miksi pitäisi olla "non-C" GUI-kirjasto? Kyllähän niitä C-kirjastoja voi käyttää muistakin ohjelmointikielistä.
Nuklear, SDL3 backend:illä toimii ihan kivasti useimpiin tarkoituksiin. Itselleni on plussaa, että ei tarvitse X-ikkunoita tai Waylandia (toki toimii hyvin niidenkin päällä) vaan toimii kms/drm ja gpu tuen kanssa minimaalisessa Linux asennuksessa.
jalski kirjoitti:
(20.04.2025 13:39:52): ”– –” Miksi pitäisi olla "non-C" GUI-kirjasto...
Koska C ei ole kovin RAD-kieli.
Joo no Nuklear, mutta mistä ne muut osat app-frameworkiin sitten?
EDIT: itseasiassa muistin, että aion alunperin käyttää selainta GUI:hin.
mavavilj kirjoitti:
Koska C ei ole kovin RAD-kieli.
Joo no Nuklear, mutta mistä ne muut osat app-frameworkiin sitten?
Kirjoitat itse? Eikös se ole sitä ohjelmointia?
jalski kirjoitti:
mavavilj kirjoitti:
Koska C ei ole kovin RAD-kieli.
Joo no Nuklear, mutta mistä ne muut osat app-frameworkiin sitten?
Kirjoitat itse? Eikös se ole sitä ohjelmointia?
No sitten varmaan pitäisi tietää siitä kernelistäkin.
mavavilj kirjoitti:
No sitten varmaan pitäisi tietää siitä kernelistäkin.
Ei kai perusohjelmointiin nyt sentään kernelitason tietämystä vaadita? Yleisesti ottaen riittää, kun löytää oikean kirjaston ja osaa dokumentaatiota vähän lukea.
AppImage:t on nimenomaan sitä ilmiötä vastaan, että jokainen päättää itse mitä miljoonasta kirjastosta käyttää.
"Valitse joku kirjasto" ei siis ole oikea vastaus.
Joo no, SDL on tietysti ihan ok. Unohdan, että se on olemassa.
mavavilj kirjoitti:
Entä onkohkan sellaisia kirjastoja, jotka toimivat kaikille seuraaville:
Ubuntu, Rocky Linux, CentOS ja Debian.
Häh? Eiköhän suurin osa (ajantasaisista ja yleisesti käytössä olevista) Linuxille tehdyistä kirjastoista toimi näillä kaikilla. Nyt taas et tarkentanut yhtään, minkä aiheen kirjastoja kaipaisit, joten vaikea antaa suosituksia.
Ja esim. juuri AppImage on yksi tapa paketoida omat kirjastot mukaan, jos ei halua kääntää ohjelmaa usealle jakelulle tai on muuten ongelmia versioiden kanssa.
mavavilj kirjoitti:
AppImage:t on nimenomaan sitä ilmiötä vastaan, että jokainen päättää itse mitä miljoonasta kirjastosta käyttää.
Eihän ohjelman käyttäjä voi valita, mitä kirjastoa käyttää. Ohjelmoija päättää, ja AppImage ei tätä kuviota muuta mitenkään.
Nämä jutut ovat niin outoja, että oletko itse asiassa ikinä koodannut mitään kirjastoa käyttävää koodia millään kielellä?
Metabolix kirjoitti:
Eihän ohjelman käyttäjä voi valita, mitä kirjastoa käyttää. Ohjelmoija päättää, ja AppImage ei tätä kuviota muuta mitenkään.
No joo paitsi, että AppImage:lle toimiva build chain tarkoittaa luultavasti myös, että vastaavaa build chainia käyttävät kirjastot portautuvat.