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.
Siinähän olisi sinulle hyvä harjoitusprojekti, että tekisit tuolla ajattelemallasi tavalla jonkin ohjelman ja jonkin kirjaston ja näkisit, onko ajatuksesi yhtään oikeilla jäljillä.
Metabolix kirjoitti:
...tekisit tuolla ajattelemallasi tavalla jonkin ohjelman ja jonkin kirjaston...
😉
mavavilj kirjoitti:
En halua tietää kernelistä juurikaan muuta kuin sen API:n.
Kerriskin The Linux Programming Interface julkaistiin 2010, mutta se on edelleen hyvä lähde.
Kirja vaatii ehkä enemmän ymmärrystä C:stä ja Linuxista kuin ketjun aloittajalla on, mutta suosittelen sitä kaikille muillekin.
jlaire kirjoitti:
(21.04.2025 20:06:47): ”– –” Kerriskin The Linux Programming Interface...
"Linux and UNIX system programming."
Minä en todellakaan tiedä, miksi haluat tietää kernelin rajapinnasta tai glibc:stä jos koodaat selainpohjaista GUI:ta. Lainasin tarkoituksella vain tuon yhden selkeän kysymyksen ja vastasin pelkästään siihen.
jlaire kirjoitti:
Minä en todellakaan tiedä, miksi haluat tietää kernelin rajapinnasta tai glibc:stä jos koodaat selainpohjaista GUI:ta. Lainasin tarkoituksella vain tuon yhden selkeän kysymyksen ja vastasin pelkästään siihen.
Samasta syystä kuin joku haluaa tehdä 60 fps Flutter-appin.
https://medium.com/@aldychris/flutter-and-kotlin-multiplatform-47d27ff08c1d
Selitätkö meille tyhmemmillekin mikä tämä syy on? Lyhyesti ja omin sanoin, ilman linkkejä.
Ja jos voit listata ne Linux- ja glibc-rajapinnat joita tällaista 60fps-GUI-sovelluskehitystä varten haluat opetella, saat varmasti sopivampia lähdesuosituksia.
jlaire kirjoitti:
Selitätkö meille tyhmemmillekin mikä tämä syy on? Lyhyesti ja omin sanoin, ilman linkkejä.
Ja jos voit listata ne Linux- ja glibc-rajapinnat joita tällaista 60fps-GUI-sovelluskehitystä varten haluat opetella, saat varmasti sopivampia lähdesuosituksia.
Vähintään samat asiat, mitä on JDK:ssa.
https://docs.oracle.com/en/java/javase/24/docs/
Okei. Kernelin API:sta tai glibc:stä ei valitettavasti löydy kaikkia JDK:n ominaisuuksia. Tarvitset selvästi lähteen, jossa selitetään ilman mitään esitietovaatimuksia sellaiset asiat kuten Linux, kerneli, käyttöjärjestelmä, kirjasto ja framework.
Jokin CS 101 tai "Linux for Dummies" tai Hello world -tason ohjelmointiopas voisi olla hyvä paikka aloittaa.
Maalaisjärjen käyttö keskustelussa ja avun kysymisessä olisi myös hyväksi. Jätät muiden tarkentavat kysymykset yleensä vastaamatta. Jos et osaa vastata, voisit selittää, mikä kohta on liian vaikea. Tarkennusten jatkuessa keskustelijat ymmärtävät toisiaan paremmin, kysymyspuu palaa lopulta takaisin juureen ja saadaan ehkä vastaus alkuperäiseen ongelmaan. Sinun ketjuissasi tyypillisesti hypitään aiheesta toiseen loputtomasti, kukaan ei ymmärrä puoliakaan sinun jutuistasi, ja vaikuttaa siltä että osaamistasosi pysyy paikallaan.
Löytyy välillisesti siten, että joku on ehkä toteuttanut ne johonkin kirjastoihin.
Eri asia on sitten, että mitkä kirjastot ovat riittävän standardinomaisia, vaikka ne eivät kuulu mihinkään määriteltyyn standardiin. JDK:ssa on omat puolensa.
Paljastan, että tämän takia Javaa itseasiassa suositellaan app-kieleksi joissain distroissa, koska kukaan ei tiedä yhtä standardia C-vaihtoehtoa. Tietääkseni Vala-kieli kehitettiin yritelmäksi ohittaa Java ja C#:
"The syntax of Vala is similar to C#, modified to better fit the GObject type system.[3]"
https://en.wikipedia.org/wiki/Vala_
Näin ollen lähtökohta on ehkä kuitenkin:
mavavilj kirjoitti:
Paljastan, että tämän takia Javaa itseasiassa suositellaan app-kieleksi joissain distroissa, koska kukaan ei tiedä yhtä standardia C-vaihtoehtoa.
Oho. Tämähän on jännittävää sisäpiiritietoa. :o
Entä sitten, jos kernelin sijaan lukisi suoraan GNOME:n dokumentaatiota?
https://apps.gnome.org/Builder/
En ole käyttänyt tätä, mutta se näyttää kuin Xcode:lta.
Sivulla https://apps.gnome.org/en/ on esimerkkejä, joissa on ilmiselvästi käytetty jotain ulkopuolisiakin kirjastoja.
Entä jos vaikka koodaisi jotain ja katsoisi, mitä välineitä siihen oikeasti tarvitsee?
Sinulla on aktiivinen foorumille kirjoittelun vuosi takana, ja jos siitä energiasta edes 10 prosenttia olisi mennyt näiden asioiden koodaamiseen ja kokeilemiseen, ei varmaan tarvitsisi kysyä näin huonosti fokusoituja kysymyksiä. Eli ihan sama, minkä kirjaston tai alustan nyt valitset, mutta pliis mene jo koodaamaan, niin opit jotain.
Tai jos oletkin jo koodannut jotain tänä aikana, laita ne koodit johonkin ja lähdetään sieltä purkamaan, mitä voisit tehdä toisin tai mikä asia selvästi vaatii opettelua.
Ensimmäiset 2 vuotta meni siihen, että piti ymmärtää, että miksi GNU/Linux on niin sotku. Sitten tuli AppImage:t, musl ja kiinnostaa enemmän jopa koodata jotain, koska kaikki koodi ei ole spagettia ja käytä jotain miljoonaa kirjastoa, jotka ovat osin päällekäisiä, kuten GNOME:n kontekstissa Qt vs GTK.
Liittyy: https://en.wikipedia.org/wiki/Criticism_of_Linux#Kernel_code_quality
Mutta jos kerran teet selainpohjaista gui:ta, et yhäkään avannut miksi sinun pitäisi kernelistä välittää. Aiotko tehdä jonkun selaimen joka porttautuu suoraan käyttöjärjestelmään, nettisivun sijaan?
Olisit varmasti tykännyt activeX-komponenteista, luojan kiitos tuki niille jo päättyi.
groovyb kirjoitti:
(22.04.2025 18:39:56): Mutta jos kerran teet selainpohjaista gui:ta...
Mistä se selain saa ne palvelut, kuten pääsyn Bluetooth-laitteeseen?
Toki tämä on jo toteutettu: https://developer.mozilla.org/en-US/docs/Web/API/Bluetooth
mavavilj kirjoitti:
Ensimmäiset 2 vuotta meni siihen, että piti ymmärtää, että miksi GNU/Linux on niin sotku.
Ihme, että olet pysynyt tietokoneen sisällä. Tarkista kiireesti, onko asuintalosi perustukset oikein valettu ja kapillaarikatko kunnossa. Eihän ohjelmoinnista tule muuten mitään. Sisäilman laatu ja radon kannattaa myös mitata, säteily voi haitata tietokoneen toimintaa ja sädesienen väitetyistä vaikutuksista voit googlata itse.
Eli pointti: keskityt asioihin, joilla ei ole mitään tekemistä sen kanssa, mitä sinun oikeasti kannattaisi tehdä edistyäksesi ohjelmoinnissa.
Kun minun tarkoitukseni ei ole ollut ohjelmoida, vaan ymmärtää ensin, mitä ratkaisuja minua edeltävät henkilöt ovat tehneet. Kuten lopulta esim., miksi emme nykyään käytä Common Lisp:iä.
Tässä kontekstissa sellainen on myös esim., että valitako GTK vai Qt.
mavavilj kirjoitti:
Kun minun tarkoitukseni ei ole ollut ohjelmoida, vaan ymmärtää ensin, mitä ratkaisuja minua edeltävät henkilöt ovat tehneet. Kuten lopulta esim., miksi emme nykyään käytä Common Lisp:iä.
Tässä kontekstissa sellainen on myös esim., että valitako GTK vai Qt.
Miksi ihmeessä tekisit verkkosivun kautta käytettävän palvelun gtk:lla tai Qt:lla? Eihän siinä ole edes mitään järjen hiventä koko ajatuksessa.
mavavilj kirjoitti:
Kuten lopulta esim., miksi emme nykyään käytä Common Lisp:iä.
Oletko löytänyt tähän vastauksen?
Mitä kaikkea olet lukenut? Minuakin kiinnostaa historia.
jlaire kirjoitti:
mavavilj kirjoitti:
Kuten lopulta esim., miksi emme nykyään käytä Common Lisp:iä.
Oletko löytänyt tähän vastauksen?
Mitä kaikkea olet lukenut? Minuakin kiinnostaa historia.
Minusta ne kaksi pääsyytä ovat:
* ei ollut riittävästi osaajia tekemään tehokkaita kääntäjiä
* ei ollut riittävästi markkinointia suhteessa johonkin toiseen teknologiaan
(* paikalla olevat ohjelmoijat osasivat ennestään C-tyylisiä kieliä, jonka takia he sanoivat, että "this feels too unfamiliar")
Kuitenkin, mikäli nämä olisivat onnistuneet, niin Common Lisp voisi olla paljon robustimpi kieli kuin C++ ja esim. Python. Se on yksi niitä harvinaisempia kieliä, millä on kuitenkin aika paljon potentiaalia: https://en.wikipedia.org/wiki/Common_Lisp#Applications
Miten tämä liittyy aiheeseen? No koska pitäisi ymmärtää, että voi tehdä samankaltaisia valintoja nyt kaikkien frameworkien suhteen.
mavavilj kirjoitti:
(22.04.2025 22:21:36): ”– –” Minusta ne kaksi pääsyytä ovat: ...
Taidat unohtaa sen tärkeimmän - Mikä on investoinnin panos ja mikä sen tuotto. Sekä löytyykö tekijöitä ylläpitämään jotta elinkaari ei olisi lyhyt. Marginaalituotteilla on marginaaliset käytöt markkinataloudessa.
groovyb kirjoitti:
(22.04.2025 22:34:38): ”– –” Taidat unohtaa sen tärkeimmän - Mikä on...
Nuo vastaavat juuri tuohon. Kysymys on siitä, miksi teoriassa hyvästä tulee marginaalinen käytännössä.
Nytkin osa on sitä mieltä, että desktop-sovelluksia kannattaisi tehdä Flutter:illa tai Electron:illa. No mitäs sitten, kun Dart on ihan marginaalikieli ja JS on ripulikieli? Mokaa ne isotkin, Dart:illa ei tosiaan ole mitään tulevaisuutta, vaikka sen piti olla JS killer tms.
Sitten kuitenkin, jos on tehty C++:lla, niin https://www.tomshardware.com/software/security-software/white-house-urges-developers-to-avoid-c-and-c-use-memory-safe-programming-languages
Olisi kiva valita ne kirjastot siten, ettei käteen jää jotain roskaa niin kuin näissä tapauksissa.
Väliäkö sillä, koska valitset sitten minkä tahansa tekniikan omaan tekeleesi, riittää että vain sinä osaat sitä tarvittaessa jatkokehittää ja ylläpitää.