MS syötti WIN8:n kanssa todella massiivisella voimalla linuxsin lapaan, mutta ei siitä valitettavasti mitään seurannut. Jos eivät tee applea ja riko voimakkaasti taaksepäin yhteensopivuutta, niin ei auta linuxsia mihinkään suuntaan.
Linuxissa on menossa aika massiivinen siirtymä edelleen työpöytäpuolella:
X:stä edelleen tehdään siirtymää Waylandiin ja Wayland ei ole "
valmis". Esimerkiksi Zoom ei Gnomessa (joka edustaa Wayland-kokemuksen "huippua") pysty merkkaamaan, mitä ikkunaa jaetaan toisin kuin X:ssä. Jakaminen menee ihan sokkona.
HDR-tuki ja
näytön kalibrointi & väriprofiilit uupuvat.
Login managerien tilanne on myös masentava - SDDM ja LightDM kehittyvät hitaasti (SDDM:stä ei ole
~2,5 vuoteen julkaistu uutta versiota ja julkaistu versio ei tue Waylandia). GDM ei
anna logata sisään multiseat-kokoonpanossa kuin yhteen Wayland-sessioon. Kaikki bugit eivät tietenkään kosketa kaikkia, mutta tämä siirtymä haittaa vielä monia. Osalla vielä myös "rootless X" puuttuu. Tl;dr: suunnilleen kaikki käyttäjät haluavat toimivan työpöydän, graafisen alan ammattilaiset ja pelaajat erityisominaisuuksia.
Näytönohjainten ajureissa on vielä menossa siirtymä KMS-ajureihin. Loppuvuoden distroissa ehkä näkee, että vanhan APIn mukaisia ja heikosti ylläpidettyjä ajureita
pudotetaan pois. Vanhat ajurit välkyttävät kuvaa bootissa ja ovat isompi tietoturvariski. Hieman tähän liittyen VT-tuki pitäisi uudistaa loppuun niin, että RT-kernelin patchit saisi kokonaan mainlineen ja VT:n säikeistettyä. Mielellään VT:hen pitäisi saada myös kunnon seat-tuki. Tl;dr: RT-tuki on olennainen esim. DAW-käytössä ja muu buginen legacy-paskakoodi lisää ylläpitoa ja tietoturvauhkia.
Äänissa Pipewire-siirtymä on vielä vaiheessa. Tilanne on jo aika hyvä, mutta ihan
Pulseaudion perusmoduuleiden toiminnallisuuksia vielä portataan Pipewireen. Tl;dr: Pipewiren riittävä kypsyysaste on olennainen esim. pelaamisessa ja DAW-käytössä.
3D-puolellakin on siirtymää OpenGL:stä Vulkaniin vielä menossa. AMD:llä on
useampia kilpailevia ajureita joita ei ole vielä saatu virtaviivaistettua. OpenGL saattaa myös pudota pois uusista ohjaimista jossain kohtaa ja Zink-kehitystyö on vielä vaiheessa. Tl;dr: tilanne on kai suht. hyvä, mutta pelaajille tehokkaammat ajurit ovat eduksi.
Selaimissa Firefox on hitaampi, mutta Chrome ei tue vielä ymmärrykseni mukaan
rautakiihdytystä videoiden purkuun toisin kuin Firefox. Sama WebGL/WebGPU-tuen kanssa. Tl;dr: videopurku ja tehokas GPU-tuki on tärkeä läppärien akkukeston ja modernien sivujen tuen kannalta.
Vielä voisi mainita vaikka Winen - nyt Winessä on menty
kohti suuntaa, jossa voisi ajaa 32-bittisiä ohjelmia 64-bittisessä Winessä. Edelleen kerneliin tarvitaan 32-bit tukea ja 32-bit multilib-tukea, jotta Wine toimisi. Steam-clientti on 32-bittinen. Siirtymä 64-bittiseen onkin pääosin valmis, mutta joitain tällaisia poikkeuksia löytyy vielä. Tl;dr: pelaaminen on monelle tärkeää ja legacy-koodi tässä lisää ylläpitotyötä.
Sitten on yleisiä ongelmia kuten esim. heikko säikeistys erinäisissä ohjelmissa. Esimerkkinä vaikka Kdenlive, joka ei hyödy 16- tai 32-ytimisestä koneesta ja tehokkaasta GPU:sta vaan kaikilla asetuksilla jää vajaakäytölle. Eri sovellusalueiden perusoperaatioita kuten kuvien muuntamisia on monesti tehokkaampi ajaa komentorivillä GNU parallelin kautta kuin graafisesti ohjelmilla, jotka ajavat kaiken yhdessä säikeessä. Tl;dr: ammattikäyttäjät haluavat työasemastaan maksimaalisen tehon irti, mielellään GUI:n kautta.
Debian stablessa taitaa vielä olla systemd-siirtymäkin vaiheessa siten, että skriptit päivittävät rinnalla täysin redundanttia sysvinit-skriptipinoa. Tl;dr: ei-autistit eivät kaipaa init-systeemien välisiä ideologisia sotia.
Devaustyökaluissa pitäisi päästä eroon antiikkisista työkaluista kuten GNU Autohell -työkaluista, joiden konffaamiseen tarvitaan tekniikan tohtorin sekä it-arkeologin paperit. Monien näiden vanhojen työkalujen paskanhajua keventää hieman se, että kyseiset työkalut ja ohjelmointikäytännöt ovat jo tukevasti kivettyneet yksi tai kaksi vuosituhatta sitten.
Kaikki eivät näe tätä ongelmaksi, mutta nyt kun Microsoft ja Google ovat
tiedostaneet matalan tason muistiturvattomat kielet ongelmaksi ja myös Herb Sutterille on kerrottu, että
jotain tarttis tehdä, Gnomen C/Vala-säädöt ja C++/MOC/Qt-pohjaiset legacy-pinot pitäisi saada modernisoitua myös jollain aikavälillä bugien minimoimiseksi ja kehitysvauhdin boostaamiseksi. Mitä sitten tilalle - en osaa suoralta kädeltä sanoa, mutta asiaa pitäisi alkaa tunnustella. SDDM:n kehitysvauhti näyttää aika hyvin, miten luotaantyöntäviä nuo legacy-kieliset ovat vapaaehtoisille.