Google opět po měsíci zveřejnil statistiky zastoupení jednotlivých verzí Androidu. Přesněji těch instalací, které používají Google Play. S tím, jak se blíží vydání dalšího Androidu O, poslední Android 7 Nougat konečně pokořil hranici 10 %. Verze 7.0 a 7.1 dohromady běží na 11,5 % zařízení. Jinak se statistiky zásadněji nezměnily. Nejvíc asi stále překvapuje vysoké zastoupení Androidu 4.4 KitKat, který je téměř čtyři roky starý a stále běží na 17 % zařízení.
(Zdroj: Android Central)
To bude určite tým ako som si predvčerom preflashoval tablet z CyanogenMod na LineageOS s Android 7.1. Behá to celkom svižne aj na tak starom Železe (Google Nexus 7 2013). Otázka znie ako dlho. Root (sh) sa doinštaloval, google apky tiež. Behá to jedna báseň aj keď je to len nightly build.
alespon to ukazuje na podporu vyrobcu pro Android zarizeni. Jeste dnes jsou nejaka zarizeni s Androidem 4.4 v prodeji. Ja jsem mel tuto verzi na LG tabletu jeste nedavno take. LG vydalo za celou dobu snad jednu aktualizaci a dal je to nezajima.
Pokud mobily se vyvijeji - rozliseni displeje, ctecky prstu, fotoaparaty, pameti atd. pak tablety dnes skoro nikoho nezajimaji a ustrnuly ve vyvoji, dnesni tablet a lepsi tablety z doby 3 let zpet jsou prakticky srovnatelne, ten novy neprinasi vlastne nic noveho...
Ta tabletu mi ted bezi Lineage OS, funguje dobre az na jednu vec. MAC adresa wifi karty se meni s kazdym rebootem.
To, ze sa MAC adresa meni, je bonus. Existuju spehovacie aplikacie, ktore odchytavaju MAC adresy a netreba sa ani pripojit do Wifi, staci ju mat zapnutu a scanovat pasmo.
http://www.wired.co.uk/article/recycling-bins-are-watching-you
"Hundreds of thousands of pedestrians walking past 12 locations unknowingly had the unique MAC address of their smartphones recorded by Renew London.
Data including the "movement, type, direction, and speed of unique devices" was recorded from smartphones that had their Wi-Fi on."
Ale nikomu nic nebrani vydat aktualizovanou ROM a dosahnout plosne migrace z A4.4 na A7... alespon vidime jak jde vyrobcum jenom o jedno - prodat a zapomenout. A ze by tomu branili technicke pozadavky? To jsou pak neschopni vyvojari toho Androidu.. kdyz par let stary hardware nas nuti zahodit, protoze z pohledu UX se moc mezi verzema nezmenilo (fakt si nevybavuji nic konkretniho jak se ruzne verze androidu lisi - co ktera podporuje a co ne - krome obcasneho srani ze aplikace neni dostupna pro urcitou verzi).
Kéž by to bylo tak jednoduché. Problém je v tom, že pro novou verzi Androidu potřebuje výrobce nové drivery, které si ještě případně přizpůsobuje pro své zařízení. Mimo jiné se u toho mění Radio Interface Layer, který se stará o mobilní funkce celého zařízení. Pro výrobce to znamená spoustu práce: obstarat drivery, znovu implementovat veškeré své úpravy Androidu, všechno otestovat, dát firmware k testování operátorům (ti jinak update svým zákazníkům nepustí - třeba v US má většina zákazníků telefony v ceně tarifu), a pak teprve se update může dostat k vám. Navíc zákazník za telefon už zaplatil, a mezi výrobci zuří cenová válka, takže jakékoliv další výdaje jsou nežádoucí.
Google se to snaží řešit podobně jako MS: vytvořit stabilní rozhraní mezi drivery a zbytkem OS. Výrobce se pak může zabývat pouze přizpůsobením OS a aplikací, a drivery (minimálně nějakou dobu) nechat jak jsou. Také odpadá nutnost re-certifikace u operátorů. Bohužel to vede ke změně interfaců, takže upgrady s nižší pracností se budou týkat až nového Androidu O a dalších verzí. Navíc se dá čekat, že díky těm změnám bude upgrade ze staršího Androidu na Android O obtížnější. Další problém je v tom, že ani od Androidu O nebude upgrade pro výrobce telefonů úplně bezpracný, a je otázkou, jestli ho (přes sníženou pracnost) budou chtít nabízet. Google bohužel nad vlastním ekosystémem nemá kontrolu. A vlastně ho to ani nemusí tolik trápit, protože pro něj nehraje takovou roli, jestli vám servíruje inzeráty na telefonu s Androidem verze X nebo Y.
https://android-developers.googleblog.com/2017/05/here-comes-treble-modular-base-for.html
Takže ano, situace s aktualizacemi a upgrady Androidu je dost kritická. Na druhé straně ale jde o poměrně složitou problematiku, která bohužel nemá žádné triviální řešení, a hlavní hráči navíc mají dost omezenou motivaci s tím něco dělat.
Souhlas :/. Navíc bezpečnostní chyby ve starších verzích Androidu neopravuje ani Google. Výsledek je naprosto příšerný, protože desítky procent telefonů mají kritické bezpečnostní chyby. Ono je dobré si uvědomit, že pro velkou část světové populace je smartphone dost veliká investice, a tihle lidé si nemůžou dovolit měnit telefon každý rok nebo dva. A nemusíme chodit daleko. Například na nedaleké Ukrajině je průměrná hrubá mzda okolo 6000 Kč. Opakuji hrubého, a většina lidí (jako všude) bere méně než průměr. O Asii a Africe ani nemluvě.
"Google se to snaží řešit podobně jako MS: vytvořit stabilní rozhraní mezi drivery a zbytkem OS."
Tak ten byl dobrej. Zvlast v souvislosti s aktualni nekompatibilitou WDDM 2.2 se starsima verzema WDDM.
Kazdopadne problem neni v rozhrani, ale v tom, ze ovladace v Linuxu jsou soucasti jadra, a to ze novejsi Android vyzaduje vetsinou i novejsi Linux. Cili jediny, co je potreba pro novejsi Android je patchnuti a kompilace novejsiho Linuxu (samotny rozhrani API se meni malokdy). To samoosobe by nebyl velkej problem, kdyby nekteri vyrobci SOC dodavaly ovladace v nejaky rozumny podobe (aspon jako to dela AMD a NVIDIA) a ne jako hotovy zkompilovany jadro urcity verze, pricemz za novejsi jadro si samozrejme nechaj znova zaplatit.
Nejsem si uplne jistej, jestli na tom Google dokaze neco zmenit...
Ad v souvislosti s aktualni nekompatibilitou WDDM 2.2 se starsima verzema WDDM - ony se nějak změnily HW requirements? Pokud jsem si všiml, tak stačí video karta s podporou DX9 a WDDM 1.0, což jsou v principu drivery pro Windows Vista. Netvrdím že všechny nutně fungují, protože to záleží na tom, jak moc je výrobce HW zprasil.
https://www.microsoft.com/en-us/windows/windows-10-specifications
Ad popis problému - vizte co jsem linkoval: The core concept is to separate the vendor implementation — the device-specific, lower-level software written in large part by the silicon manufacturers — from the Android OS Framework. This is achieved by the introduction of a new vendor interface between the Android OS framework and the vendor implementation. Bohužel se zdá, že dokumentace není zatím k dispozici.
Ad jediny, co je potreba pro novejsi Android je patchnuti a kompilace novejsiho - ano, ale drivery v čistě binární podobě s novým kernelem nepůjdou, a pokud je výrobce dostane ve formě zdrojáku, tak do nich údajně zasahuje (takže musí portovat všechny své změny ze starší verze).
Ad Nejsem si uplne jistej, jestli na tom Google dokaze neco zmenit - ten přidaný layer by mohl pomoc, ale je otázka, jak to bude vypadat v praxi. Protože nevidím moc motivace pro Google, a ani pro výrobce telefonů, tak jsem poněkud skeptický.
K WDDM: evidentne ano, kdyz Intel oznamil, ze tablety s procesorama Atom s PowerVR grafikou (vicemene vsechny tablety uvedeny s W8) v posledni verzi W10 nepojedou.
Vyrobce telefonu do driveru nema duvod zasahovat. To je nesmysl. Vyrobce telefonu maximalne nahraje par svych aplikaci a mozna edituje nektery casti Androidu aby mu vnutil svuj look & feel.
Podivej se jak sou delany binarni drivery od AMD a NVIDIA. Neni to ideal, ale funguje to.
Ad Intel oznamil, ze tablety s procesorama Atom s PowerVR grafikou (vicemene vsechny tablety uvedeny s W8) v posledni verzi W10 nepojedou - dáte mi prosím link na to oznámení? Podle mě to znamená, že Intel tyhle grafiky už nebude podporovat. To ale neznamená, že by nutně nejely s Windows 10. Ty mají požadavek na funkční driver s WDDM 1.0+, a pokud je ten driver slušně napsaný, tak by měl jet.
Ad Vyrobce telefonu do driveru nema duvod zasahovat - je rozdíl mezi driverem chipsetu a driverem konkrétního zařízení, pokud nebudeme brát v úvahu referenční desky :). Vezměte si jako příklad kamery: každý výrobce telefonu provádí vlastní magii s výsledným obrazem (white balancing, ostření, kontrast, dneska i HDR, více snímků v jednom s odlišným ostřením nebo odlišnou intenzitou přisvětlení), a občas si třeba namontuje snímač o 90 stupňů otočený, protože mu tak lépe pasuje do fyzického designu.
https://developer.qualcomm.com/qfile/28820/lm80-p0436-9_sensors_porting_guide.pdf
Ad jak sou delany binarni drivery od AMD a NVIDIA. Neni to ideal, ale funguje to - ano, ani to nefunguje ideálně.
Nebudou fungovat:
https://answers.microsoft.com/en-us/windows/forum/windows_10-windows_install/intel-clover-trail-processors-are-not-supported-on/ed1823d3-c82c-4d7f-ba9d-43ecbcf526e9
Taky sem se divil. I proto ze jeden takovej tablet mam a dodnes tam Linux nefuguje AFAIK.
OK, ale pokud mam zvlast ovladace pro dalsi zarizeni a sam si je upravim, tak je pri updatu jadra uz pak upravovat znova nemusim. Staci je znova zkompilovat, coz je otazka par minut. Zvlast u kamery, kde se API menilo naposledy ve verzi 2.6
Osobne si myslim, ze vykonostne nekriticky drivery by klidne mohli byt v user space, podobne jako FUSE.
Zrovna u kamer se V4L2 meni porad - kazdy hw ma od vyrobce jiny kernel a kazdy jiny kernel chce trocha jine funkce... co jsme davneji delali s Androidem, tak tam byl stejne ovladac v userspace jako binarka, ktera nejak sahala na vse co takovou kameru zajistuje (od i2c do snimace a rizeni ostreni, az po isp blok v SoC). Vyrobci cipu (at uz SoC nebo snimacovych) nechtej implementovat otevrene ovladace protoze by pak vyzradili sve nejtajnejsi tajemstvi.. (jeste prisneji strezene nez u GPU), takze je s tim neskutecneho srani kdyz mate neco postavit.
V4L2 se nemeni. To by se pokazdy zmene musely prepisovat vsechny aplikace co ho popouzivaj. Jestli se menej jaderny funkce, ktery pouziva ovladac je vec jina, ale dost nepravdepodobna.
Drivery samotny nemaj s Androidem moc co delat. Android obsahuje pouze middleware, kterej dela rozhrani mezi aplikacema a Linuxovejma driverem. Pokud vyrobce dodava do Androidu i ten middleware, tak pak je to samozrejme problem toho vyrobce. Ale zas uz to nema nic spolecnyho s drivera, ktery pouzivaj standardni Linuxovy rozhrani, ktery se nemeni.
V4L2 ale neni jenom API mezi kernelem a driverama, na coz jste to tady zjednodusil. Je to i sada funkcni na spravu bufferu a jinych vnitrnosti v ramci driveru - a to se meni jako dost. Vzhledem k tomu ze my kamery delame a snazime se k nim mit ovladace v zdrojakove podobe tak o tom vim sve. Zatim mame 4 ruzne ovladace, pro 4 ruzne verze kernelu, pro jednu a tu samou kameru.
Ohledne Androidu - to co popisujete by byla idealni situace ale praxe je zcela jina, zrovna u kamer je to takovy bastl ze to svet nevidel - CameraAPI totiz resi krome zobrazovani a foceni taky nahravani a kompresi, takova telefonni kamera ani nemusi mit V4L2 rozhrani a nejcasteji to je nejaka binarka v userspace, navic rozdelena na dve casti, proprietarni demon a pak ty Androidi tridy co za to nejak tahaj, aby to delalo co ma.
Doporucuji vam se zabyvat trocha i praxi a vytvorit/udrzovat nejaky ovladac, pak nebudete perlit ve stylu "standardni Linuxovy rozhrani, ktery se nemeni" :)
V4L2 neni vubec API mezi kernelem a driverama. V4L2 je rozhrani mezi aplikacema a driverama. V4L2 vubec co dela driver nezajma. Ani jakakoli slozitejsi configurace toho zarizeni z aplikace nejde pres V4L2, ale treba pres I2C. Pokud nevis takovou zakladni vec, tak nevim co tam delas a co vlastne o tom vis. Driver komunikuje s HW pres standardni API pro danou sbernici pres kterou je zarizeni pripojeny Jakakoli zmena v takovym zakladnim API by znamenala prepis vsech ovladacu vyuzivajicich danou sbernici, coz je neco do ceho by se nikdo nechtel moc poustet.
CameraAPI zprostredkovava prave ten middleware o kterym mluvim, s driverama to ma spolecnyho jen to, ze to naky musi vyuzivat k pristupu k HW. Pripada mi, ze mas problem rozlisit co je driver a co middleware...
Prestante tvrdit nesmysly.
Do V4L2 patri vsechny ovladace pro video vstup/vystup, ktere sdili spolecne api smerem k userspace. A na strane vnitrni / kernelove / sdili hodne kodu, ktera se stara o nastavovani parametru, spravu bufferu a dma prenosu, tohle vnitrni api je smerem k ostatnim casti kernelu - jako je napr. sprava pameti, ktera je pak v ruznych verzich ruzna a vyzaduje upravy driveru, jinak ho neni mozne prelozit.
Napsal jste nekdy nejaky video driver? Tvoril jste nekdy nejake zarizeni na takto nizke urovni - od hardware az po standardni kompatibilitu? My ano. A existuje vedle nas nekolik konkurencnich firem, ktera se na to vykaslala a nabizi radeji sve vlastni a stabilni API, namisto idealnejsiho V4L2... proc asi, ze?
Takze mi prosim nevysvetlujte jak tomu vlastne nerozumime :-)
V4L2 je API, ne ovladac. Vis aspon co je to API? Strana vnitrni (ovladace) nema s V4L2 nic spolecnyho. Je treba si neplist pojmy s dojmy. Zmeny ve V4L2 jsou popsany tady: https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/hist-v4l2.html . Od dnes uz temer historicke verze 3.0 se az na par nepouzivanych veci jen pridavalo, takze na uz napsany ovladace to nema temer zadny vliv.
Děkuji za link. Působí to spíš jako bug driveru, než to že by drivery se starší verzí WDDM prostě nešly. Nakonec driver naběhne. MS to má v tomhle těžké, protože driver pro GPU poměrně vzácných Atomů Clover Trail by bylo velmi drahé napsat "doma", a Intel to má zřejmě na háku (zvlášť když MS pracuje na x86-kompatibilních zařízeních s ARMem).
Ovšem v blog postu k Insider Preview Build 14926 čtu: We fixed an issue where Windows icons and text are not rendered correctly on some devices with Intel Atom (Clovertrail) processors. Je to celkem starý build, a netuším jestli se změna dostala (nebo dostane) do Current Branch.
Drivery komentoval RDa, a podle všeho se v Androidu vyzná výrazně lépe, než já.
Ad vykonostne nekriticky drivery by klidne mohli byt v user space, podobne jako FUSE - to by mohly, ale je otázka, co na mobilu, coby zařízení s malou baterkou, malou RAM a slabým CPU, není výkonově kritické. Těch kandidátů asi moc nebude. Syscall je celkem drahý, a u komunikaci s HW stejně nakonec odvedete v kernel mode. Když máte driver v user space, tak to většinou vede na veliký počet syscalls, který zabije výkon. V případě mobilu pravda víc záleží na tom, že sežerete baterku.
No kdyz to ve starsich verzich WDDM slo a v ty nejnovejsi ne, tak bude asi problem v tom, ze se chovani toho ABI zmenilo. Zvlast kdyz to Microsoft dokazal opravit.
Intel by musel platit za vyvoj novyho driveru platit Imagination, k cemuz nema duvod kdyz uz ty procesory neprodava. Holt stejnej pripad jako u Androidu. A clovertraily nejsou zas tak vzacny. Kvuli/diky nim vicemene vubec Windows 8 vzniklo.
Kdyz Android opravdu chtel setrit na baterii, tak by musel hlavne zestihlit aplikace. Drivery sou to posledni co by melo vliv na baterii, RAM nebo CPU...
Pokud vystačíte s tak malým displayem, tak proč nepoužít rovnou telefon? Za mě to ale chce větší display, aby to mělo vůbec smysl. Ohledně aplikací: sice je jich plný Windows Store, ale upřímně na to čtení mailů, webu a ebooků jich moc nepotřebuji :). Hyper-V, MS SQL and VS na tabletu nepotřebuji, ale MS Office se hodí, a třeba MS OneNote je velmi praktický. Navíc když přijde email a potřebuji reagovat, nebo dokoukám na youtube a chci pracovat, tak si prostě připojím klávesnici, a mám zase "opravdový" počítač.
Mimochodem stroje 2-in-1 používám už dlouho, ale ještě ve Windows Vista to nebylo nic moc, protože systém prostě nebyl stavěný na dotekové ovládání. Ve Win8.x to bylo výrazně lepší, ale na desktopu to bylo s těmi Metro apps poněkud matoucí, zvlášť zpočátku ve Win 8. S Win10 se MS podle mě strefil, protože se opravdu dobře používají v obou režimech. Navíc se za tu dobu výrazně zlepšil HW, nové stroje jsou velmi výkonné, lehké a tenké. Srovnejte si třeba Surface Pro 2017 s iPadem Pro 12.9". Na tom iPadu přitom můžete běžet jen browser a pár nezajímavých aplikací, na práci je naprosto nepoužitelný. Na 2-in-1 můžete dělat všechno, od brouzdání youtube v tabletovém módu až po debugging aplikací ve VS, profesionální úpravy fotek ve Photoshopu, nebo střih videa v Adobe Premiere Pro. PC už dávno nejsou šedivé krabice z devadesátých let, ani těžké notebookové cihly ze začátku tohoto století. Navíc když sečtete cenu slušného notebooku a slušného tabletu, tak zjistíte, že ty 2-in-1 nejsou drahé.
To že něco funguje v OS verze X a nefunguje v OS verze X+1 ještě neznamená, že je chyba na straně OS. Typicky jde o to, že aplikace (nebo v tomto případě driver) spoléhá na nějaké nedokumentované chování systému, které se v další verzi OS změnilo. Jako příklady ze světa aplikací jsem v minulosti uváděl třeba vykrádání resources z knihoven shellu (ikony, animace), nebo v drsnějším případě připojení síťové jednotky tak že aplikace otevře shell, vybere položku, a v jejím kontextovém menu vydoluje "správnou" položku. Případně se aplikace spoléhají na
Intel by nemusel platit vývoj nového driveru, podle všeho by stačilo opravit ten stávající. Ale jak jsem psal, Intel to má zřejmě na háku. Jestli driver vyvíjí Imagination Technologies, tak bohužel nemůžou driver opravit bez Intelu, ani kdyby to MS zaplatil, protože práva na kód má nejspíš právě Intel.
Souhlas s tím, že zeštíhlení aplikací by rozhodně pomohlo. Drivery ale pochopitelně také mají vliv na baterii i CPU, zvlášť pokud byste je přesunul do user space a měly spoustu syscallů.
No nedokumentovane chovani systemu pouzivaj hlavne Microsofti aplikace. Ostatni o tom nedokumentovanym chovani se bez dokumentace nemaj moc moznost dozvedet, ze? :)
Intel by musel zaplatit za novou verzi driveru. Jestli Imagination opravi stavajici nebo bude updatovat na novejsi verzi WDDM uz se Intelu moc netyka. Ja z ty zpravy prave pochopil, ze Intel nema prava ani zdrojaky, jinak by ty drivery udelal sam. Ostatne to je i duvod proc nikdy nevznikla podpora pro Linux kterymu je jinak Intel dost naklonenej.
Nesouhlasim s tim, ze by syscally z user space mely nejakej zasadni vliv na vykon. Ostatne se staci podivat na jakejkoli system zalozenej na mikrokernelu, kde sou vsechny ovladace v user space (coz je podstata mikrokernelu). Ten rozdil je v radu jednotek procent. Dokonce si vybavuju, ze si tu pred par lety tvrdil, ze Windows jsou zalozeny na mikrokernelu :).
Ad nedokumentovane chovani systemu pouzivaj hlavne Microsofti aplikace - máte k tomu něco konkrétnějšího?
Ad Ostatni o tom nedokumentovanym chovani se bez dokumentace nemaj moc moznost dozvedet, ze? :) - nedokumentované chování systému autor aplikace nesmí používat, protože se může kdykoliv změnit. Pokud například u aplikace použijete animaci kopírování souboru z knihovny shellu, tak v příští verzi Windows tam ta animace nejspíš nebude; naopak v SDK je ta animace k dispozici, a můžete jí zahrnout do své aplikace. Podobně se nemůžete spoléhat na pořadí Window Messages, nedokumentované error codes, obsah systémových menu atd. Pravidelně k tomu linkuji některé až neuvěřitelné věci, které popisuje Raymond Chen. A samozřejmě autoři driverů mají občas podobný problém.
http://blogs.msdn.com/b/oldnewthing/archive/2005/10/26/485133.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2003/12/23/45481.aspx
http://technet.microsoft.com/en-us/magazine/2006.11.windowsconfidential.aspx
http://technet.microsoft.com/en-us/magazine/2006.10.windowsconfidential.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2005/09/01/459023.aspx
Ad Intel by musel zaplatit za novou verzi driveru - což Intel nechce udělat. Nevím jestli je důvodem to že se ty CPU už neprodávají. Spíš bych si tipnul, že když se MS rozhodl uvést zařízení s ARMem kompatibilní s x86, tak dělá naschvály.
Ad Nesouhlasim s tim, ze by syscally z user space mely nejakej zasadni vliv na vykon - syscall má typicky overhead 500-2000 taktů, a často vede ke změně kontextu, která je ještě dražší.
Ad se staci podivat na jakejkoli system zalozenej na mikrokernelu, kde sou vsechny ovladace v user space - a proč myslíte, že žádný mainstreamový OS není čistě mikrokernelový? :)
Ad Dokonce si vybavuju, ze si tu pred par lety tvrdil, ze Windows jsou zalozeny na mikrokernelu - ano, ovšem je to modifikovaný mikrokernel. Services jsou přesunuty do kernel mode právě proto, aby se minimalizoval počet syscalls. Koukněte se třeba na FUSE, tam může být propad výkonu až o 85% proti FS v kernel mode. Existují sice způsoby jak počet syscalls snížit, ale vždycky je to něco za něco.
OK, chapu. Mas na mysli teoretickej pripad, kdy by driver z nakyho neznamyho duvodu obchazel WDDM a pouzil primy volani naky jaderny funkce, kterou nahodou nekdo nekde objevil, ale neni dokumentovana a tedy ani zarucena kompatibilita. U aplikaci placanych na kolene bych to pochopil, ale u ovladacu mi to moc pravdepodobny neprijde.
Intel jasne dal celkem najevo, ze ARMovy zarizeni podporujici x86 instrukcni sadu si ji budou muset nechat licencovat, takze zkratka uplne neprijde. Samozrejme je to pro nej dalsi konkurence se, kterou musi pocitat. Nepodporou Clovertrailu na truc by poskodil pouze koncove zakazniky. Urcite ne Microsoft.
500-2000 taktu je pri dnesnich rychlostech znamena jednu microsekundu. To je pro treba vstupni zarizeni typu klavesnice ci dotykovej display naprosto zanedbalenej "cost".
Co si predstavujes pod pojmem "Mainstreamovy"? Je treba Blackberry mainstream?
Windows stejne jako macOS sice zacaly s microkernelem, ale jak na to nabalily balast vznik z toho v podstate monolitickej kernel.
Byl by nakej odkaz na porovnani vykonu FUSE vs jadernej modul stejnyho FS? Kdyz porovnam JFS s NTFS3g, tak je NTFS3g asi o 40% pomalejsi, ale neni to moc relevantni test vzhledem k tomu, ze to sou dost odlisny FS.
WDDM je interface mezi OS a video driverem, tj. říká co musí driver exportovat a co musí exportované funkce dělat. Driver je rozdělený na user mode display driver a (kernel mode) display miniport driver. Drivery obecně můžou volat cokoliv je v jejich prostředí k dispozici. Kernelový driver tedy může volat veškeré funkce Native API. Bug, který se neprojeví v OS verze X, ale projeví se ve verzi X+1, může mít dlouhou řadu podob. Může jít třeba o race condition, která začne projevovat až po změně kódu OS, protože se změnilo pořadí volání funkcí.
Ad Intel jasne dal celkem najevo, ze ARMovy zarizeni podporujici x86 instrukcni sadu si ji budou muset nechat licencovat - jenže tady půjde o SW implementaci, takže je otázka, jestli Intelu jeho patenty pomůžou.
Ad Nepodporou Clovertrailu na truc by poskodil pouze koncove zakazniky. Urcite ne Microsoft. - a na koho jste od začátku nadával, že ukončil podporu Clovertrailu? Na Intel ne :)
Ad 500-2000 taktu je pri dnesnich rychlostech znamena jednu microsekundu. To je pro treba vstupni zarizeni typu klavesnice ci dotykovej display naprosto zanedbalenej "cost". - ono to bude spíš několik mikrosekund. Navíc se koukněme na několik čísel. Co myslíte že se stane, když si na obrazovce nakreslíte prstem kolečko? Kdybyste sesbíral informaci o pozici 10x za vteřinu, měl byste z kolečka pěkný pětiúhelník :). Myši reportují při pohybu s frekvencí 125Hz a více, touch screeny co jsem hledal umí 200Hz a více.
Ad mikrokernel - čistě pro informaci jsem si otevřel Performance Monitor. Vytížení CPU pod 2%, průměrně 4700 interruptů za sekundu (maximum 22800). Pokud chcete mát drivery v user mode, tak máte trochu problém s tím, že nevoláte kernel vy, ale kernel vás, což je trochu náročnější. Daleko větší problém je ale v tom, že vás driver proces musí mít (z definice) oddělený kontext, a context switch je opět drahá operace. Nedej bože, abyste si musel předávat data a přepínat kontexty po cestě vícekrát (například mezi procesy block device, logical device, FS).
Nejde o to, že by to stroj výkonově nezvládl. On to zvládne, ale s daleko vyšším vytížením CPU, což je na mobilu recept na rychlé vyčerpání baterie. Aplikace jsou další věc, ale když pod zbytečně náročné aplikace dáte zbytečně náročný kernel, tak tomu fakt nepomůžete.
Ad Windows stejne jako macOS sice zacaly s microkernelem, ale jak na to nabalily balast vznik z toho v podstate monolitickej kernel - Windows NT nikdy nebyly čistě mikrokernelový systém. Například FS byly od začátku v kernel mode. Mikrokernel je u NT kernelu vidět spíš v oddělení komponent, které ovšem z důvodu výkonu běží v kernel mode; proto tomu MS říká modifikovaný mikrokernel. MacOS X je sice postavený nad modifikovaným Mach mikrokernelem, ale s ním v kernel model běží ještě modifikovaný BSD kernel, ze kterého kus odřízli, ve stylu Frankensteina ho svařili s tím Mach mikrokernelem, a vedle připsali driver framework (IOKit). Výsledkem je architektonicky vzato kočko-praso-pes.
Ad porovnani vykonu FUSE vs jadernej modul stejnyho FS - jj, třeba tady. Dovolím si citaci. Although micro-kernels implement file systems in user space, most file systems are part of monolithic kernels. Kernel implementations avoid the high message-passing overheads of microkernels and user-space daemons. ... We developed a simple pass-through stackable file system in FUSE and then evaluated its performance when layered on top of Ext4 compared to native Ext4. We used a wide variety of micro- and macro-workloads, and different hardware using basic and optimized configurations of FUSE. We found that depending on the workload and hardware, FUSE can perform as well as Ext4, but in the worst cases can be 3x slower. Podotýkám že nejtragičtější jsou výsledky nad malými 4kB soubory, kde to jaksi nejvíce visí na FUSE. Když se víc čeká na HW a skrz FUSE leze méně requestů, tak to není tak hrozné.
https://www.usenix.org/system/files/conference/fast17/fast17-vangoor.pdf
No a protoze Microsoft nedokaze udrzet stabilni prostredi ani uvnirt jedny major verze systemu, tak to pak takhle dopada. Ale to neni nic novyho.
Ta situace s x86 na ARMu je naprosto stejna jako u Transmety.
https://www.cnews.cz/x86-si-rozvracet-nedame-intel-hrozi-patentovymi-zalobami-za-emulaci-windows-na-armu/
Ano zlobim se na Microsoft, protoze ten rozbil kompatibilitu s hotovym driverem. Ale to je tak vsechno. Clovek se pouci, aby si daval pozor co od Intelu kupuje a Microsoft to nijak neposkodi... zhorsit povest jeste vic nak moc uz ani nejde... Ja osobne sem od Intelu uz zadnou podporu ani necekal, vzhledem k tomu jak na tenhle procesor kalej od zacatku.
ehm, i kdyby ten touch screen bezel 1000Hz furt ta jedna microsekunda zabere jen jedno promile z CPU casu.
Context switch se ale prece deje neustale, kdyz mame multitasking, ze jo? ;) Holt driver je u mikro kernelu standardni aplikace jako vsechny ostatni a musi se s tim pocitat uz od navrhu.
No jejikoz ty konponenty bezej v kernel modu, tak nemuze bejt rec o mikro kernelu :). To oddeleni je tak spis abstraktni. Evidentne v tomhle neni mezi Windows a macOS zadnej rozdil.
Ja mel na mysli benchmark mezi dvouma implementacema stejnyho FS. Tady je zas otazka jakej overhead ma ten jejich stackfs, kterej znasilnuje kernelovou implementaci ext4 aby bezela pod fuse.
Ad Microsoft nedokaze udrzet stabilni prostredi ani uvnirt jedny major verze systemu - všimněte si, že problém se týká jednoho driveru od Intelu. "Stabilní prostředí" je leda to, ve kterém se nic nemění. Ad absurdum byste mohl vinit OS, když aplikace spoléhá, že nějaká systémová binárka má velikost X bytů.
Ad situace s x86 na ARMu je naprosto stejna jako u Transmety - nemyslím. Společnost Transmeta dodávala čip, který emuloval x86. V případě ARMu by mělo jít o čistě SW emulaci, stejně jako v případě emulace x86 na Microsoft Virtual PC a RealPC pro Mac, FX!32 pro Alpha AXP, PowerVM Lx86 pro IBM RS/6000, QuickTransit pro PowerPC, Wabi pro Sun SPARC, nebo SoftPC pro SGI IRIX, Sun Solaris, HP-UX, IBM AIX, NeXT, Motorola 88000, DEC VAX/VMS a DEC ULTRIX. Nevím o tom, že by Intel v jakémkoliv z těchto případů x86 emulace autory (úspěšně) žaloval. Navíc kdyby to Intel udělal, tak by se velmi snadno mohlo stát, že dotlačí skupinu výrobců HW a MS ke společnému přechodu na ARM. Podobnou chybu totiž udělali už v IBM, když uvedli architekturu MCA (v rámci PS/2), a dali výrobcům prakticky likvidační podmínky pro licencování. MS a "Gang of Nine" se dohodli, požadavky IBM odmítli, a vytvořili EISA. V IBM tím definitivně ztratili vliv na výrobce PC, a za pár let přišli o trh.
Ad i kdyby ten touch screen bezel 1000Hz furt ta jedna microsekunda zabere jen jedno promile z CPU casu - když je těch mikrosekund hodně, jsou z nich milisekundy, a pak jejich desítky.
Ad Context switch se ale prece deje neustale - jistě, ale je to dost drahá operace. Pro ilustraci si představte vyhledání souboru v adresáři, který je uložený na disku v 10 blocích, se zanedbáním jakéhokoliv indexu (řekněme na FAT32). V případě WinNT zavoláte FindFirstFileEx, propadne to na syscall, tam řekněme na antivirus, filesystem, block device, driver HW, přečtou se nějaké bloky, a je to. Celkem jeden syscall. U mikrokernelového systému dojde k přepnutí kontextu v každém kroku, na starším HW vám to dokonce vybuší TLB. A navíc u toho dojde k hromadě syscallů. To vypadá spíš jako pokus o DoS, než jako použitelný OS.
Ad konponenty bezej v kernel modu, tak nemuze bejt rec o mikro kernelu :). To oddeleni je tak spis abstraktni - řekněme že v podání MS je "modifikovaný mikrokernel" modifikovaný tak, že přichází o jeden ze svých výrazných rysů, aby to nezabilo výkon. Jinak na MacOS kritizuji hlavně to frankensteinovské sešívání.
Ad Ja mel na mysli benchmark mezi dvouma implementacema stejnyho FS. Tady je zas otazka jakej overhead ma ten jejich stackfs, kterej znasilnuje kernelovou implementaci ext4 aby bezela pod fuse - mě to připadá popsané celkem jasně: We developed a simple pass-through stackable file system in FUSE and then evaluated its performance when layered on top of Ext4 compared to native Ext4. Takže jde o srovnání nativního ext4 s nativním ext4, nad kterým běží jednoduchý FUSE wrapper. Ten mají dále ještě ve variantách StackfsBase, a v poladěné variantě StackfsOpt, která používá nejnovější features FUSE. Za mě takové srovnání jasně ukazuje overhead, který FUSE přináší jen při prostém postavení nad kernelový FS.
Problem se netyka driveru od Intelu, ale driveru od Imagination. A Clovek by ocekaval, ze v jedny verzi Windows se nic menit nebude. Zvlast na tak nizky urovni.
x86 na ARMu.. Rek bych ze Intel bude mit "trochu" fundovanejsi nazor nez ty ;).
Psal sem o dobre navrzenym FS.
Ano, mikrosoft "modifikoval" mikrokernel na monolitickej kernel :). Stejne jako Apple.
Aha, takze ty nechapes, ze kdyz na jednom interfacu delas emulaci jinyho interfacu, ze ta emulace ma urcitej overhead?
Ad Problem se netyka driveru od Intelu, ale driveru od Imagination - driver dodává Intel, a jestli si ho píše doma, nebo si na to někoho najímá, to je v principu věc Intelu.
Ad Clovek by ocekaval, ze v jedny verzi Windows se nic menit nebude - jak jsem psal, pokud kód spoléhá na nedokumentované chování systému, tak se to může vymstít. V rámci jedné verze Windows se toho změní spousta. Dnešní Windows 10 s těmi původně uvedenými nejspíš nemají až na drivery shodnou ani jednu binárku.
Ad Rek bych ze Intel bude mit "trochu" fundovanejsi nazor nez ty ;) - Nové aplikace pro Windows jsou psané pro .NET nebo WinRT, a běží na ARMu stejně jako na Intelu. Intel má hlavně zájem neztratit tržní pozici. Jestli s patenty uspěje, to ukáže až případný soud :)
Ad Psal sem o dobre navrzenym FS - a jak to chcete mít oddělené moduly do procesů, abyste zároveň nemusel provádět hromadu syscallů a kontext switchů? Ono to moc nejde, což je právě důvod, proč se takový design v mainstreamových OS nepoužívá.
Ad mikrosoft "modifikoval" mikrokernel na monolitickej kernel - NT kernel je modularizovaný: drivery, Hardware Abstraction Layer, I/O Manager atd. Každý z těch modulů má stabilní ABI i API, a komunikují spolu jejich prostřednictvím. Mimochodem i drivery diskového řadiče a "root" FS se natahují dynamicky. NT mají typický mikrokernelový design, s tou modifikací, že servery běží v kernel mode. Když se podíváte na monolitický kernel, tak tam jsou drivery součástí kernelu; neexistuje žádná další vrstva pro abstrakci HW (natož aby šla vyměnit jako HAL v NT); memory manager, cache manager a file systémy tvoří prakticky nedílný celek v kódu, a jsou slinkované v rámci binárky kernelu; atd.
Ad takze ty nechapes, ze kdyz na jednom interfacu delas emulaci jinyho interfacu, ze ta emulace ma urcitej overhead - pánové poměrně změřili overhead FUSE nad kernelovým FS. Nad blokovým zařízením to bude podle všech předpokladů jen horší. Jestli máte lepší data než jsem linkoval, rád si je přečtu.
Intel ten driver ani psat nemuze, stejne jako vyrobci Androidich telefonu nemuzou psat vlastni drivery, pokud jim vyrobce nedoda dokumentaci, ale jen binarni drivery.
Coz je prave ten problem, ze Microsoft porad nesmyslne meni kod Windows i v ramci jedny verze. To je taky duvod proc jeste spousta lidi jede na XP. Protoze v tom uz se MS nevrta a tak je to daleko stabilnejsi.
Moc nechapu proc do diskuze o x86 emulaci na ARMu tahas .NET. Intel dnes uz nema zadnej trzni podil v oblasti kde kraluje ARM. Experiment zvanej Atom nevysel. Patenty si samozrejme chranit bude. Otazka je jestli vubec k nakymu soudu dojde. Treba se na licencovani domluvej i bez nej.
Vsechno jde kdyz se chce :). I na to hledani se da udelat funkce primo do FS a v konecnym dusledku tech syscallu muze byt i mnohem min nez u klasickyho FS.
"NT mají typický mikrokernelový design, s tou modifikací, že servery běží v kernel mode." :D To je jako, ze auto je typicky letadlo akorat s tim rozdilem ze nelita :)
Panove zmerili nakej overhead, ale jakou cast toho overheadu tvori FUSE a jakou ta jejich emulace FUSE rozhrani u kernelovyho FS, to muzem jen hadat. Nehlede na to ze ten FS neni optimalizovanej na pouziti v FUSE.
Ad Intel ten driver ani psat nemuze - to si Intel mohl (a měl) rozmyslet, než GPU od jiného výrobce přidal do pouzdra vlastního CPU.
Ad Microsoft porad nesmyslne meni kod Windows i v ramci jedny verze - nemyslím že nesmyslně. Jestli nejde jeden driver GPU, který zřejmě výrobce zmršil a odmítá ho opravit, tak bych z toho nečinil žádné dalekosáhlé závěry.
Ad 3 - .NETu je jedno jestli jede na x86, x64 nebo ARMu, takže Intel může taky splakat nad výdělkem. Souhlas že pokus jménem Atom nějak nevyšel. Ohledně těch patentů jsem sám zvědavý, jak to dopadne.
Ad I na to hledani se da udelat funkce primo do FS a v konecnym dusledku tech syscallu muze byt i mnohem min nez u klasickyho FS - no jednu cestu bych znal. Můžete ten filesystem, block device a driver HW zabalit do jednoho procesu, a nechte to v user mode. Tím odpadne context switch mezi těmi komponentami. Ale protože HW nemůže z user mode na HW, tak do spíš hoďte do kernel mode. Wow, jsme skoro u NT :). Věřte mi, že lidé jako Dave Cutler, Rich Page nebo Avie Tevanian dobře vědí co je mikrokernel, a dobře vědí, proč se rozhodli pro jiný design. Toho studenta co psal terminálový emulátor, a nějakým omylem skončil s kusem OS, s dovolením v souvislosti s designem radši zmiňovat nebudu :)
https://groups.google.com/group/comp.os.minix/msg/b813d52cbc5a044b?dmode=source
Ad filesystem, block device, driver HW :) - rozdíly v designu jsme se snažil poctivě popsat. A jak už jsem psal, čistých mikrokernelů u mainstreamových OS jaksi moc nenajdete. Přesně z těch důvodů, které jsem popisoval.
Ad Panove zmerili nakej overhead, ale jakou cast toho overheadu tvori FUSE a jakou ta jejich emulace FUSE rozhrani u kernelovyho FS, to muzem jen hadat. Nehlede na to ze ten FS neni optimalizovanej na pouziti v FUSE. - jakou emulaci FUSE rozhrani u kernelovyho FS máte na mysli? FUSE běží jako kernelový driver. Do stromu si přimontujete FUSE driver s nějakými parametry, a ten volá user-mode stackfs. Ten user-mode stackFS prostě provádí normální FS requesty, jako každý jiný proces. Navíc je tam jenom nějaký převod na async requesty a tuším cachování inodů, právě v rámci optimalizace. Vždyť se na to koukněte. Ale jak jsem psal: jestli máte lepší data, rád se kouknu.
https://github.com/sbu-fsl/fuse-stackfs/blob/master/StackFS_LowLevel/StackFS_LowLevel.c#L819
https://github.com/sbu-fsl/fuse-stackfs/blob/master/StackFS_LowLevel/StackFS_LowLevel.c#L868
"Věřte mi, že lidé jako Dave Cutler, Rich Page nebo Avie Tevanian dobře vědí co je mikrokernel, a dobře vědí, proč se rozhodli pro jiný design."
Ani jedno z tech jmen sem nikdy neslysel, takze jejich nazor me tak nak vubec nezajma. Kazdopadne je videt ze ty vubec netusis co je mikrokernel, a proc je QNX uz 35 let leader v mission critical aplikacich.
Uz sem se te jednou ptal co je podle tebe mainstream OS. Pokud jen Windows a Android, tak ten vzorek je tak statisticky malej, ze s toho fakt nejde delat zavery. Pokud bys chtel jen trochu rozsirit zaber, tak rychle narazis na QNX, ktery krome ruznych mision critical aplikaci bezi treba na telefonech Blackberry, kteri si majitele velmi chvalej a kterej ovsem umre stejne jako Windows Mobile na nedostatek aplikaci.
Ten stackfs je vicemene emulator FUSE filesystemu s tim, ze vola kernelovej fs. Vazne nevidis ten overhead, kterej vznika prekladem FUSE funkci na kernelovy funkce a prekladem kernelovych vystupu na FUSE vystupy? Zvlast kdyz tam z nakych duvodu maj jeste plno timeru, ktery to dal zbytecne zpomalujou?
Ad jedno z tech jmen sem nikdy neslysel - to byste možná měl. Například Dave Cutler je architektem a vývojářem RSX-11M, VAXELN, VMS a Windows NT.
Ad vubec netusis co je mikrokernel, a proc je QNX uz 35 let leader v mission critical aplikacich - poměrně dobře vím o čem je mikrokernel, a také vím, proč se nepoužívá v mainstreamových OS. Jedna věc je totiž robusnost nebo predikovatelná RT charakteristika OS, a druhá věc je celkový výkon.
Řekl bych to takhle: čím víc rozdělíte OS do navzájem oddělených procesů (serverů), tím častěji musíte tu bariéru mezi těmi procesy překračovat. A protože je to drahá operace, tak se to podepisuje na celkovém výkonu systému. To je prostá vlastnost toho oddělení procesů. Takže si při návrhu OS musíte vybrat, kolik výkonu na to obětujete.
Nebo úplně laicky: čím víc rozdělíte dům použitím (vynucených) zámků na dveřích, tím častěji budete muset provádět akci "vzít klíč, odemknout, projít a zase zamknout". Samozřejmě to má výhody, v téhle paralele bezpečnost. Jenže když nainstalujete zámek v restauraci mezi místností pro hosty a kuchyní, mezi sporákem a zbytkem kuchyně, a mezi kuchyní a chlaďákem atd., tak sice číšník nemůže manipulovat se sporákem ani ukrást maso z chlaďáku, ale bude to celé neskutečně pomalé, protože všichni stráví spoustu času odemykáním a zamykáním místo toho aby produktivně pracovali. Při návrhu si pak musíte vybrat, jak moc chcete oddělovat jednotlivé části těmi zámky: jak je pro vás důležitá ta bezpečnost, a kolik výkonu tomu obětujete. Lepší paralelu asi nenajdu.
To že architekti většiny mainstreamových OS nepoužili čistý mikrokernel není proto, že by nevěděli o čem to je. Naopak to dobře věděli a uvědomovali si výše popsaný kompromis. Proto se rozhodli oddělit bariérou OS od aplikací, i aplikace navzájem od sebe. Ale neoddělili od sebe bariérou komponenty OS, protože je to drahé, a nemá to dost velký přínos, který by tu cenu opodstatnil.
Ad co je podle tebe mainstream OS - třeba Windows, MacOS, Solaris, AIX, HP-UX, Linux.
Ad QNX, ktery krome ruznych mision critical aplikaci bezi treba na telefonech Blackberry - Blackberry 10 OS není mainstreamový OS. BTW jedním z problémů QNX byl (a nejspíš dále je) velmi slabý výkon networkingu, díky ceně context switchů a IPC. Řešením bylo sloučení prakticky celého networkingu do jednoho serveru, včetně driverů. Tím se sníží počet context switchů a není nutné používat IPC. Ovšem také přijdete o oddělení do více na sobě nezávislých serverů. To je svým způsobem podobné jako u NT (byť tam je to dovedené ještě dál).
http://www.qnx.com/developers/docs/6.5.0/topic/com.qnx.doc.neutrino_sys_arch/images/io-pkt_architecture.gif
Ad stackfs je vicemene emulator FUSE filesystemu s tim, ze vola kernelovej fs. Vazne nevidis ten overhead, kterej vznika prekladem FUSE funkci na kernelovy funkce a prekladem kernelovych vystupu na FUSE vystupy - pokud srovnáváte plný FS napsaný pro FUSE se stackfs, tak vlastní volání user mode části FS bude mít v obou případech stejný overhead. Co se bude lišit je počet dalších volání. Stackfs prostě jen zavolá funkci kernelového FS, což je jeden syscall. Plný FS pod FUSE musí udělat daleko víc operací: alokací, dealokací, zamykání, volání. A context switche, syscalls a IPC mají vysokou cenu a snižují výkon. Nevím co víc bych k tomu řekl.
Ad tam z nakych duvodu maj jeste plno timeru, ktery to dal zbytecne zpomalujou - podle autora je ve struktuře requestu pole pro timestamp, a ty funkce je jenom vyplňují, což není nijak náročné. Když chcete měřit výkon jednotlivých částí kódu, tak se bez nějaké podobné věci neobejdete.
Ad obskurni mrtvoly jako HP-UX a AIX a QNX - HP-UX a AIX (a Solaris) se používají tam, kde výkon platformy Intel nedostačuje. Faktem je, že takový aplikací je čím dál méně. QNX za mainstreamový OS nepovažuji.
Než začnete hájit drivery v user space a vůbec rozdělení OS do mnoha procesů, tak se zkuste zamyslet nad tím, co jsem vám psal. Pro začátek stačí ta paralela s domem s klíči. Víc k tomu asi také nemám co říct.
Ne, HP-UX a AIX se pouziva uz pouze ze setrvacnosti, kde se jeste nenasly penize na modernizaci SW. Solaris jedinej dokaze aspon trochu Linuxu v serverech konkurovat, ale i s tim to jde zvlast po koupi Oraclem z kopce. Oproti QNX, ktery vicemene nema zadnou nahradu, nemaj tyhle systemy zadnou budoucnost.
Samozrejme QNX je jen priklad mainstreamovayho mikrokernelovyho OS. Dalsi je treba FreeRTOS, kterej ma na mikroradicich postaveni asi jako Windows na desktopech.
"Než začnete hájit drivery v user space a vůbec rozdělení OS do mnoha procesů"
jak sem rikal vubec nechapes smysl mikrokernelu... Mikrokernel neni o nakym nasobnym zvysovani poctu procesu. Mikrokernel je o tom, ze v jadre je jen to nejnutnejsi minimum pro beh systemu. To znamena vicemene jen scheduler, memory management a IPC. To jestli vsecho ostatni, co je obvykle soucasti monolitickyho jadra, pobezi v jednom jednom procesu nebo v milionu procesu s tim nijak nesouvisi. Takze ta tvoje "paralela" je absolutne mimo.
Tak to řešení co si myslí Google, že bude řešením, z mého pohledu řešení je tak napůl. V podstatě Google otvírá svůj malý rybníček a střílí se dlouhodobě do nohy. Jediné skutečně správné řešení je začlenit ovladače do Linux kernelu. Zvládá to kde kdo a srovnat se s 63 či 70 dením cyklem není takový problém. Nové čipy se přece nevyvinou za 3 měsíce... různé přípravné práce se dají dělat roky dopředu. Navíc nejsem potom vázaný jen na Android.
Druhá možnost je podobně jako nVidia udržovat proprietární ovladač. Komplexitou je to rozhodně podobné, jako moderní SoC.
To, že výrobci udržují v podstatě totálně přepsaný kernel se speciálním schedulerem atd. atd. za to si můžou sami. Místo aby pracovali s komunitou a těžili z jejich práce, tak radši udržují jakýsi roky starý kernel, který už se po jejich změnách už Linuxu podobá jen tak z půlky. Další věc je, že kvalita toho kódu podle všeho není valná. Chápu, že je možné, že by jim v Linuxu některé prasárny neprošly tak lehce. Co si ale budeme povídat, Linux na více místech není žádný skvost, ale zásadní věci už několik let jsou více než solidní a rozhodně lépe podpororvané, než bastl nějakého výrobce z asie.
Ano, třeba Qualcomm vydává vlastní verze patchovaného Androidu pro referenční desky s jednotlivými chipsety pro každou verzi Androidu. Protože reálné zařízení není referenční deska, tak si výrobci implementují další úpravy. Pokud chce výrobce přejít z jedné verze Androidu na druhou, tak je to veliká spousta práce.
Pokud jde o sloučení těch změn do kernelu, tak tam je dost problémů. Na prvním místě spousta patchů do kernelu prostě nemusí projít, protože podle někoho nejsou potřeba, nebo se nelíbí, nebo řešení problému není obecné a liší se výrobce od výrobce. Na druhém místě z toho vyplývá problém kontroly. Pokud máte HW platformu a děláte k ní SW, tak nemůžete být závislý na tom, jestli vám vývojáři kernelu (kteří mají silně vyhraněné názory a mimo jiné si občas v komunikaci sprostě nadávají) vyjdou vstříc. Navíc vám vaší implementaci mohou v dalším buildu rozbít nebo odstranit. Když se vyskytnou problémy, tak prostě forknete kernel. Ušetříte si spoustu dohadování, a místo abyste musel roky tlačit zavedení nějakého obecnějšího řešení, tak prostě na svém uděláte to, co potřebujete.
Příklad: Qualcomm uvedl CPU big.LITTLE, se dvěma jádry A57 s vysokým výkonem, a čtyřmi jádry A53 s nízkým výkonem a nízkou spotřebou (a těch konfigurací existuje víc). Abyste běžel nekritické tasky na slabších jádrech s minimálním odběrem, a kritické tasky na silnějších jádrech, tak potřebujete na úrovni Androidu zjistit co je kritické (zobrazená aplikace, doteková gesta atd.), scheduler podle toho musí plánovat, a power management podle toho musí zapínat/vypínat jádra a upravovat jejich výkon. To není zrovna jednoduché. Samozřejmě by se to dalo řešit masivními změnami v kernelu, power managementu a Androidu. Například by šlo modularizovat scheduler (což by asi znamenalo spoustu refactoringu), a výrobce by dodal vlastní modul scheduleru, namísto toho aby musel forkovat a patchovat. Ale kernelové vývojáře zabývající se desktopovým a serverovým Linuxem to vůbec nezajímá, vyskytne se spousta dohadů, zformují se skupinky prosazující různá řešení které se budou hádat... Katastrofickými příklady ze světa Linuxu je (ne)zahrnutí Reiser4 do jádra, dekády trvající snaha nahradit X11 něčím civilizovanějším, atd. K tomu přičtěte odpor vývojářů k čemukoliv co není pod GPL, včetně názorů typu že kernelové moduly musí být vždy pod GPL, včetně například nVidia driverů, záměrnou absenci stabilního ABI atd. Takže nakonec forknete kernel i Android, uděláte co potřebujete (nejspíš to nebude obecné), a výrobci telefonů si zase forknou váš kód a poladí si co potřebují. Změny budou hotové k datu uvedení HW na trh, a ne o pár let později, kdy už budete potřebovat řešit úplně jiné věci.
Je to neštěstí, ale je to cena za vývoj stylem bazaar, kdy upstream developeři nemají odpovědnost vůči výrobcům HW, a vlastně ani vůči nikomu jinému. Kdybyste z toho chtěl ven, tak byste musel mít daleko víc vývojářů, a hlavně namísto chaosu nějaké rozumné řízení projektu - tedy cathedral, ne bazaar. Pak pochopitelně nastává otázka, kdo a jak by měl ten vývoj řídit, a jak financovat ty vývojáře.
Mimochodem všimněte si, že firmy, které vyvíjí stylem cathedral, tyhle problémy nemají. A nemusí to být nutně tak uzavřené jako u Applu. Třeba MS velmi živě komunikuje s výrobci polovodičů, výrobci finálního HW, vývojáři, a samozřejmě s uživateli, takže výsledná platforma je dlouhodobě stabilní, zároveň poměrně otevřená, a vyhovuje pro naprostou většinu nasazení. To je názor který vám nechci vnucovat, ale asi s shodneme, že to stojí za zamyšlení.
Ok, takze rootnem telefon, nainstalujem si tam nejaky night build operacneho systemu ktory neobsahuje google app store a nasledne si tam pridam google app store aby som mal zdroj relativne bezpecnych aplikacii.
To mi neznie ako masovo prevadzkovana kratochvila BFU uzivatela 3 roky stareho operatorom a vyrobcom opusteneho mobilu.
Root telefonu a Alternativni ROM jsou 2 rozdilne veci, Root potrebujes pokud chces prava Roota, pro alternativni ROM potrebujes pouze Unlock/Odemcenej telefon/bootloader... a pak:
1. nainstalujes si tam stable alternativni rom bez GooglePlay/Services/Apps(tedy bez veci co smirujou, bezej na pozadi apod)...
2. nainstalujes si F-Droid aplikaci, ktera obsahuje vyhradne OpenSource aplikace
https://f-droid.org/packages/
Teprve pokud pozadujes aplikace co jsou v GooglePlay tak si nainstalujes nejaky "Play Wraper", kdy budes moci ziskat takove aplikace, ale pritom ti nepobezej neustale sluzby Google (TAHLE VARIANTA NENI NUTNA, JEN POKUD NA TOM TY TRVAS a vetsina lidi co pouziva alternativni ROM + F-Droid ji nepouziva ;)
Pokud ses uzivatel co nezvladne par krokovej postup na unlock telefonu, flashnuti recovery, nahrani rom a instalaci f-droid, tak si uvedom ze jsi na root.cz a ne na materidouska.cz ci zive ;)
Souhlasím že alternativní ROM jsou pro starší telefony často jedinou cestou. Na druhé straně čím dál víc funkcionality se přesunuje do GMS, takže na AOSP je zastaralý dialer, kalendář, SMS klient, launcher atd. Navíc alternativní ROM nejsou zdaleka k dispozici pro všechny modely, a jejich kvalita bývá dost různá. Pokud je výsledkem celé akce to, že musíte dál "tunit", abyste měl spolehlivost a prostředí srovnatelné s recentními ROM od výrobců, tak je to dost problém.
Pokud jde o F-Droid, tak chápu že vám nabídka aplikací může vyhovovat, ale s takovým pohledem jste nepatrnou menšinou. Telefony jsou výrobek pro masy, a měly by tomu být přizpůsobené (což ty s Androidem minimálně z hlediska aktualizací nejsou). Za mě je důležité mít třeba kvalitní mapy s offline navigací a dopravními informacemi. Lepší navigace mají i statistiky průjezdnosti, takže vědí, že třída 5. května v Praze se v neděli ve 2 ráno dá projet rychle, kdežto v pondělí v 9 ráno to jde velmi pomalu, i když tam není hlášený incident. Další důležitou věcí je pro mě Outlook a Excel. Přitom nejde ani tak o moje preference, jako spíš o to, že F-Droid nabídkou neuspokojí skoro nikoho, s výjimkou pár lidí jako jste vy (no disrespect - máte plné právo mít vlastní preference).
ČLÁNKY DO MAILU
