Kilpailua. Iso firma katsoisi mallilla “ok, tämä on olemassa niin kauan kuin isotaskuinen sijoittaja uskoo että siitä ehkä voi tulla isompaa ja sitten kun tulee, altering the deal iskee ja aletaan painaa rahaa”. Eli vaikka numeroina voi näyttää houkuttelevalta, harrastusprojekteja kummoisemmat projektit ajattelevat myös asioita niin kuin toimittajan luotettavuus ja taloudellinen asema. Halpa lisenssi muuttuu kaliiksi kun kesken isoa projektia käyttämäsi ratkaisu “katoaa”, ts. sitä ei enää kehitetä eikä tueta, kun pienellä startupilla loppui rahat.
Ja pienempiä ja vähemmän resursseja vieviä ratkaisuja on helppo esitellä jos ei tarvitse puhua ominaisuuksista. Muistinkäyttö on suoraan verrannollinen ominaisuuksiin. Arvaan lonkalta että QT osaa enemmän asioita. Kaikki asiat ovat pino tradeoffeja näissä.
En kyllä tuosta videosta juuri vertailua hyvistä ja huonoista puolista löytänyt, mikä on harmi koska aihe kiinnostaa.
En ole näissä asiantuntija, mutta luulen että oot tuossa oikeilla jäljillä sikäli, että ominaisuudet luonnollisesti turvottaa frameworkia/kirjastoa. Toteutuksen teknisillä ratkaisuillakin on kyllä merkitystä, jos ulos tulee suoraan natiivisti suoritettavaa koodia, lopputulos on todennäköisesti kevyempi resurssivaatimusten suhteen kuin jos sitä ajetaan esim. jonkun sortin virtuaalikoneessa, tai muuten ajetaan suoritettaessa tulkin tms läpi. Mutta toisaalta voi myös kysyä, että onko ylipäätään järkevää olettaa, ettei näillä monialustaratkaisuilla (QT, Flutter jne) tulisi rajat jossain vaiheessa vastaan kun mennään todella rajoittuneisiin alustoihin. On hyvin harvassa ne kirjastot joita käytetään älypuhelimissa ja tietokoneissa, ja jotka edelleen mahtuisi myös mikrokontrollereihin.
Eikös tässä Slint UI toolkitin osalta puhuta siitä, kuinka paljon konetehoa vaatii koodikirjaston käyttö koodin luomiseksi? Ei siis siitä, kuinka paljon laskentatehoa vaatii esim Slintillä tai Qt:llä koodattu riisikeitin.
Luulisin, että koodaamiseen käytettävän koneen laskentateho tai laskentatehon hinta on nykyisin aika harvoin mikään ongelma tai kustannustekijä?
Jos olen luulossani oikeassa, niin aika vähissä vaikutta Qt:n kilpailijat olevan. Jos viiden hengen startup on merkittävimpiä haastajia noin 700 henkeä työllistävälle Qt:lle. No kyllähän Eriksonillakin aikanaan naurettiin Nokian gsm puuhasteluille…
MCU osalta kirjoitteli muisti vaatimuksista kohdelaitteelle. Sen osalta Qt isona kirjastona, vaikka Stubertin sanoin loistavaa duunia tekivätkin MCU tuotteen kanssa, ei ole markkinoiden parhaita ratkaisuja mikrokontrollereille.
Koitan kaivaa sen jostain. En muista oliko se World Summit 22 Opening Speechissä vai Q4 tai Q3 konfficallissa. Olen tässä tunnin koittanut etsiä kyseistä kohtaa. Sinällään tällä ei ole mitään merkitystä, koska Qt on joka paikassa.
“Jos otetaan esimerkiksi Hyundai, tossa esimerkissä, Hyundai on hyvin tyypillinen tänä päivänä siellä tehdään Qt:lla melkein kaikki automerkit ja melkein kaikki näytöt.”
EDIT: Koreassa tuntuu olevan Qt:lla vahvoja asiakkuuksia, joista tulee rahaakin kassaan. LG & Hyundai lienevät molemmat ison potentiaalin asiakkuuksia, mutta arvelisin LG:n tuovan tänä päivänä jopa enemmän tuloja johtuen valtavista volyymeistä ja pidemmästä R&D yhteistyöstä.
Aiemmin Hyundailla ja Kialla käytetty vapaan lähdekoodin Qt:ta. Aiemmin olen ketjuun kaivanut heidän Gen5W infotainment open software noticen missä ilmoittavat Qt:n käyttämisestä LGPL-2.1 lisenssillä. Tässä pitkä kertomus, kun vuoden 2021 Hyudai Ioniqin infotainmentti hakkeroidaan osaavissa käsissä: Part1 Part2 Part3
Part 3:ssa kirjoittaja kertoo saaneensa järjestelmätiedoista selville, että käyttöliittymässä käytetty Qt 5.7 ja käykin sen lataamassa Qt:n sivuilta, että pääsee itse auton näytölle paketoimaan tuotoksensa koherenttiin pakettiin.
Olen käsittänyt, että nykyisin(mistä lähtien?) LG toimii Hyundain kumppanina infotainmenttien kanssa. Hyundai Group myös ilmoitti pari vuotta sitten ensin, että HUDit tullaan tekemään Qt:n kilpailijalla Distin GL Studiolla. Siitä muutama kuukausi eteenpäin tiedotettiin LG:n ja Hyundain Mobisin kehittävän GL Studiolla jatkossa Kia malleihin käyttöliittymät.
Miten sitten tiedottivat 2021 näin? Vai puuhutaanko nyt eri asioista?
Enkä millään jaksa uskoa, että Hyundai tekisi vaikkapa Ioniq5:een ja Kia EV6:een käyttöliittymät eri työkaluilla. Nehän on aivan samanlaiset. Siis nuo näytön grafiikat.
Sitten tosiaan näiden jälkeen saman vuoden elokuussa Qt tiedotti yhteistyöstä Hyundain kanssa. Tosin ei siinä tiedotteessa mitään asiakkuudesta suoraan puhuttu. Esimerkiksi hiljattain tiedotetussa GM:n yhteistyössä puhutaan suoraan solmitusta sopimuksesta.
Tuossa jälkimmäisessä DiSTIn tiedotteessa tosiaan kerrotaan tätä ratkaisua käytettävän KIA merkin malleissa vaikka luonnollisemmalta tuntuisi samaa ratkaisua käyttää myös sisarmalleissa kuten tähän asti tehty.
Ehkä on ehkä ei. Qt:lla liikevaihto tuloutuu sen verran laajalta asiakasryhmältä, että ei tuolla nyt kokonaisuuden kannalta ole varmaan lopulta suurtakaan väliä onko Hyundai vain Qt:n käyttäjä vai myös lisenssiasiakas. Toki hieman harhaanjohtavaa viestintää tuo on Qt:lta mikäli Hyundai on vain käyttäjä.
Nää on näitä. Tuntuu helvetin tärkeältä kaivaa milloin mistäkin tiedonmuruja vaikka lopulta sijoituskeissin kannalta näillä tiedonmurusilla ei ole isossa kuvassa kovin kummoista merkitystä.
En näe tässä mitään ristiriitaa, jos mittari- ja infotaiment-näyttö on toteutettu Qt:lla, niin HUD (= tuulilasinäyttö) voidaan niin haluttaessa toteuttaa muilla välineillä.
Toki tällöin Qt:n laariin kilahtaa lisenssituloja vain kahden näytön osalta per auto.
No jatketaan nyt sitten tätä. Samaa mieltä jos kyse olisi vain HUDeista, kuten ensimmäisen tiedotteen kohdalla puhutaan. Toisessa tiedotteessa puhutaankin jo yleisemmin infotainmentista.
Paitsi jos tässä tapauksessa Hyundai jatkaa vapaan lähdekoodin Qt:n käyttämistä.
