Ars Technica - Čeprav je Android zgrajen na Linuxovem jedru, sta si jedri precej različni. V primerjavi z Linuxom ima jedro za Android 32.000 vrstic dodatne kode in 1500 vrstic odstranjene kode. Nekaj kode je dopisal Google, druge prispevke so pripravili proizvajalci strojne opreme, denimo MediaTek in Qualcomm. Včasih je bilo stanje še hujše, saj je bilo dodatne kode 60.000 vrstic, a do cilja je še daleč. Google si je namreč zastavil cilj v prihodnosti Android spremeniti v modularno jedro, ki je v osnovi enako kot Linuxovo.
Tako so dejali na Linux Plumbers Conference, kjer je Google potrdil, da želijo jedri karseda zbližati. Na ta način bo razvoj enostavnejši, saj se trenutno potroši ogromno človeških ur na dodajanju kode v stabilno verzijo (merge), hkrati pa mora Google verzije Linuxovega jedra podpirati še šest let. Po drugi strani bi bilo poenotenje koristno tudi za telefone in računalnike z ARM-jevimi procesorji z Linuxom, ki bi dobili daljšo avtonomijo in nekaj zmogljivosti. Problem dodajanja funkcionalnosti proizvajalcev v jedro je Google odpravil s projektom Treble, ki je leta 2017 ločil gonilnike za posebno strojno opremo od preostalega dela Androida. To so uspeli doseči s stabilnim vmesnikom med Androidom in HAL-om (Hardware Abstraction Layer).
Prvi korak pri poenotenju bo vnos čim več sprememb v uradno Linuxovo verzijo. Tu gre dobro, saj je razlik z vsako verzijo manj. Googlu je že uspelo zagnati Android 10 z uradnim Linuxovim jedrom, čeprav vse funkcije ne delujejo. Sedaj bo Google poizkusil tudi v Linuxu uvesti nekaj podobnega projektu Treble, torej da bi zaprti gonilniki delovali kot nekakšni moduli brez sprememb v jedru. Skupnost Linuxa je načeloma proti stabilnemu vmesniku.
Samo prste vstran od Linux jedra grr. Sedaj se hocejo svoje zbiranje podatkov v linux jedro lepo pocasi kot se zaba kuha dodati. Ce pa ne to pa neke "nepogresljive" black box stvari dodati, ki jih bo dosti lenuhov potem uporabljalo, kot je npr. v N26 aplikaciji odvisnost od GCNja, kjer ne gre potrditi transakcije brez da dobis push message, ceprav jo imas na seznamu in bi BP bilo mimo tistega narejeno.
Torej bo v prihodnosti Android na nespremenjenem Linuxovem jedru (+ Android modulih). Ne vem zakaj niso to že od začetka imel to tako urejen. So šli spreminjat Linux jedro. Tako da v bistvu Android ni imel nikoli Linux jedra pač pa nečaka Linuxovemu jedru : ]
Torej bo v prihodnosti Android na nespremenjenem Linuxovem jedru (+ Android modulih). Ne vem zakaj niso to že od začetka imel to tako urejen. So šli spreminjat Linux jedro. Tako da v bistvu Android ni imel nikoli Linux jedra pač pa nečaka Linuxovemu jedru : ]
Linux jedro z dodatki je še vedno Linux jedro, pa dodatki morajo biti objavljeni pod GPL.
Source koda se pregleda in če je notri vohunska koda, vrže ven.
Saj to je namen vsega...
To me najbolj moti:
Sedaj bo Google poizkusil tudi v Linuxu uvesti nekaj podobnega projektu Treble, torej da bi zaprti gonilniki delovali kot nekakšni moduli brez sprememb v jedru.
Seveda ne, še vedno pa potrebuješ "zaprte gonilnike", ki ne bodo del jedra. To sicer že imaš, vmesnik za te "zaprte gonilnike" pa trenutno ponazorimo s tole shemo:
To je eno komplicirano področje, sploh iz vidika licenc. Vsa koda, ki se izvaja v kernelu mora biti odprta, to zahteva licenca. Zato že od nekdaj proizvajalci pišejo minimalistične Linux kernel module, ki interaktirajo z userspace kodo, ki pa so lahko zaprti.
Ampak to je že od začetka Androida, tako da zaprta koda ni nikoli bila problem za enotno jedro. Problem je, ker se je Google zelo agresivno lotil spreminjanja jedra in ni vključil skupnosti v dialog. Specifično so bili to dodatki kot alarm timer, wakelocks, binder... Da ne bomo še naprej mešali UI in kernela @WizardOfOz :)
To je eno komplicirano področje, sploh iz vidika licenc. Vsa koda, ki se izvaja v kernelu mora biti odprta, to zahteva licenca. Zato že od nekdaj proizvajalci pišejo minimalistične Linux kernel module, ki interaktirajo z userspace kodo, ki pa so lahko zaprti.
Ampak to je že od začetka Androida, tako da zaprta koda ni nikoli bila problem za enotno jedro. Problem je, ker se je Google zelo agresivno lotil spreminjanja jedra in ni vključil skupnosti v dialog. Specifično so bili to dodatki kot alarm timer, wakelocks, binder... Da ne bomo še naprej mešali UI in kernela @WizardOfOz :)
To iskanje workaround-ov okrog licenc je bilo vedno prisotno in vedno bo. Najti neko srednjo pot med open/close source bo po mojem precej težko. Po eni strani je dobro, da se omogoči kakšno izjemo, po drugi strani pa ni dobro da izjeme postanejo pravilo.
MS je to probal in neslavno popušil, google bo pa ravno tako. Ne moreš desktopov in telefonov mešat.
Kako to mosliš. Klicanje in prejemanje klicev je samo en app. Mobilni proci so nekako na nivoju uporabe nezahtevnih uporabnikov, pa še to dokler se poganjajo lokalno. Vse je samo v grafičnem vmesniku, v ozadju je totalno nepomembeno kaj in kako je narejeno. Seveda že za J vmesnik je potem eno ali drugo neuporabno.
France Rejects Genocide Accusations Against Israel in Gaza,
To accuse the Jewish state of genocide is to cross a moral threshold
Za povprečnega potrošnika je čisto vseeno, če se da odkleniti ali ne.
Hrabri mišek (od 2015 nova serija!) -> http://tinyurl.com/na7r54l
18. november 2011 - Umrl je Mark Hall, "oče" Hrabrega miška
RTVSLO: http://tinyurl.com/74r9n7j
V čem točno sploh govori novica? Saj Google že od začetka poskuša čim maj sprememb delati na jedru Linuxa, ker razvoj pač stane. Ampak razvoj jedra ni cigu migu čunga lunga in skrbniki jedra so (upravičeno) zelo konzervativni. Zato Google naredi fork (=Android) in notri našopa stvari, ki po mnenju upstreama še niso zrele za v mainline. Čez čas potem priteče večina vseeno tudi v jedro Linuxa. Ampak vedno bodo novi featurji, ki ne bodo dovolj zreli in vedno bo moral biti fork, ker je razvoj in ciljna publika Linuxa (strežniki, super računalniki, "mission critical resne stvari"™) čisto druga kot za Androida (v glavnem zabava).
PS: Izprijena se mi zdi marketinška fora, da Android valda ni Linux (čeprav ima samo 32K dodanih vrstic, ostalih 20M pa istih ). Tako kot Huawei razvija "svoj" operacijski sistem, potem pa vidiš, da vzamejo Linuxovo jedro in dodajo nov wayland vmesnik. Jao.
Ampak to je že od začetka Androida, tako da zaprta koda ni nikoli bila problem za enotno jedro. Problem je, ker se je Google zelo agresivno lotil spreminjanja jedra in ni vključil skupnosti v dialog. Specifično so bili to dodatki kot alarm timer, wakelocks, binder... Da ne bomo še naprej mešali UI in kernela @WizardOfOz :)
Dialog s communityem je vedno bil in dejansko lahko greš gledat zgodovino debat med Android ekipo (še za časa ko Android ni bil del Googla) in Linux jedrom okoli sprememb potrebnih za delovanje Androida. Flamewar je ustrezno epski :)
Na tisti točki pač niso uspeli najti skupne besede - Linuxaši takrat niso bili navdušeni nad spremembami jedra potrebnimi za low-power delovanje na telefonih in ogromnimi spremembami s strani Androida, Android pa ni bil navdušen nad čakanjem par let da se Linuxaši zmenijo za rešitev.
Torej bo v prihodnosti Android na nespremenjenem Linuxovem jedru (+ Android modulih). Ne vem zakaj niso to že od začetka imel to tako urejen. So šli spreminjat Linux jedro. Tako da v bistvu Android ni imel nikoli Linux jedra pač pa nečaka Linuxovemu jedru : ]
Kako bi pa ti to drugače uredil na napravi s 528MHz procesorjem in 192MB rama z majhno baterijo?
Skupnost Linuxa je načeloma proti stabilnemu vmesniku.
Kaj to pomeni?
To pomeni, da ne želijo vzdrževati kompatibilnosti starih modulov v novih verzijah.
Hvala.
Hrabri mišek (od 2015 nova serija!) -> http://tinyurl.com/na7r54l
18. november 2011 - Umrl je Mark Hall, "oče" Hrabrega miška
RTVSLO: http://tinyurl.com/74r9n7j
Torej bo v prihodnosti Android na nespremenjenem Linuxovem jedru (+ Android modulih). Ne vem zakaj niso to že od začetka imel to tako urejen. So šli spreminjat Linux jedro. Tako da v bistvu Android ni imel nikoli Linux jedra pač pa nečaka Linuxovemu jedru : ]
Kako bi pa ti to drugače uredil na napravi s 528MHz procesorjem in 192MB rama z majhno baterijo?
Zdaj se bodo oglasili staroste z "v mojih časih smo poganjali linux na 60 MHz procesorju in 8 MB RAM-a, pa je čisto v redu delalo!"
To je eno komplicirano področje, sploh iz vidika licenc. Vsa koda, ki se izvaja v kernelu mora biti odprta, to zahteva licenca. Zato že od nekdaj proizvajalci pišejo minimalistične Linux kernel module, ki interaktirajo z userspace kodo, ki pa so lahko zaprti.
To je precej daleč od resnice.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!
Samo prste vstran od Linux jedra grr. Sedaj se hocejo svoje zbiranje podatkov v linux jedro lepo pocasi kot se zaba kuha dodati. Ce pa ne to pa neke "nepogresljive" black box stvari dodati, ki jih bo dosti lenuhov potem uporabljalo, kot je npr. v N26 aplikaciji odvisnost od GCNja, kjer ne gre potrditi transakcije brez da dobis push message, ceprav jo imas na seznamu in bi BP bilo mimo tistega narejeno.
A mi lahko malce bolj razložiš tole zadevo z N26 in Push. Ker me zelo moti ta Push message in mi ni jasno zakaj moram vedno dvakrat potrditi isti drek.
Kar se mene tiče je tole načeloma dobrodošlo, problem je, da se s tem pristopom uspešno zapira lastniške gonilnike, namesto, da bi se jih odpiralo.
Drži, zato je pa tisti sredinec zgoraj. Lajšanje tega gre na roke korporacijam, kar samo po sebi ne bi bilo nič slabega, če bi korporacije spoštovale dogovore, pa jih ne.
Kar se mene tiče je tole načeloma dobrodošlo, problem je, da se s tem pristopom uspešno zapira lastniške gonilnike, namesto, da bi se jih odpiralo.
Drži, zato je pa tisti sredinec zgoraj. Lajšanje tega gre na roke korporacijam, kar samo po sebi ne bi bilo nič slabega, če bi korporacije spoštovale dogovore, pa jih ne.
Cel point software revolucije 21. stoletja je abstrakcija na abstrakcijo da lahko gre razvoj dalje, ker je prekompleksno vse skupaj, da bi bilo na istem nivoju direkt vidno. Linux kernel pa se kar upira stabilnemu HAL vmesniku že desetletja. 100krat lažje je narediti driver ki govori z HAL vmesnikom kot pa driver direktno hardkodirat v kodo kernela.
Skratka upam da končno rata da linux kernel končno dobi stabilni HAL (nestabilnega neuradnega sicer že ima in ga nekateri 3rd party driverji uporabljajo, zaradi nestabilnosti seveda pride do problemov). Stabilni uradni HAL če je dobro spisan ima tudi izolacijo za security če se kdo v varnost vtika.
Koliko trenutno zgleda bo Android sicer obdržal svoj HAL, Google bo delal s SoC vendorji za podporo tega HALa, navaden Linux pa bo ostal zadaj. Ker če gledaš design, bodo Android komponente in HW driverji šli ven z jedra v ločen layer.
Tavelika sprememba bo v tem, da bo manj vzdrževanja Android patchev ko se kernel posodobi, kar je ok za OEMe in Google, malo manj pa ok za Linux ker v vsakem primeru ne bo dobil BSPjev za laufanje brez Android stacka. Ampak kazanje sredincev pač redko rezultira v konstruktivnem sodelovanju.
Ja v osnovi je to ja, ampak HAL modul bo najbrž ločen, ni to cel Android komplet ali nič. Morda ga pograbi tudi kaka desktop linux distribucija ;) Morda Desktop Nvidia driver naredi dependancy na ta modul :)
In kmalu je čeprav ločena zadeva HAL de-facto del razvoja linux kernela, ker ga je treba vedno delujočega držati skozi verzije kernela.