Vlákno názorů k článku Hazard s bezpečností: levné Motoroly nikdy nedostanou novější Android od msx. - Ten otvorený BL využije tak 5 % ľudí...

Ten otvorený BL využije tak 5 % ľudí v lepšom prípade. Podľa mňa to nie je riešenie. Riešenie je lepší HW od výrobcu hneď od začiatku.

V jakém smysl lepší, respektive abych se ptal správně, co přesně si mám představit pod pojmem "lepší hardware"? Baterie, součástková základna, použitý SoC, RAM, ...?

Nemůžete rozumně očekávat, že každý telefon vybavíte tím nejlepším a nejvýkonnějším na trhu a nějakým zázrakem vykouzlíte nízkou cenu. Dumping + dotace vynásobené bulharskou konstantou, jinak to nepůjde.

Levnější SoC disponují dostatečnou rezervou pro nenáročné uživatele, kam přirozeně nižší třída cílí a s relativně malou pamětí se dá též spokojeně fungovat 3-5 let, tedy i ten levný telefon má dostatečný potenciál k tomu, aby svému majiteli přinesl úžitek po dobu 5 let. Nepočítá se s ničím náročným, tak proč do toho cpát drahé SoC a kupu paměti, která vlastně není potřeba.

RE: Lepší HW.

Nějak se nám ta realita posouvá...
Win98 běžely s 16MB RAM
Linux kolem roku 2000 s 32MB RAM
Win 2000 a XP 64MB (jednojádrový 32bit CPU 133 / 266 MHz)

Co takového spešl ten mobil s CPU cca 2000x výkonnějším se 125x větší RAMkou (proti roku 2000), co s tím HW dělá? Krmí nějaké šílené neefektivní mezivrstvy typu Java / JavaScript?

Jen pro připomenutí. Na těch kompech kolem roku 2000 šlo spustit tisíce aplikací včetně 3D her a webu.

Fakt něco rozumného opravňuje tyhle krabičky, aby žraly výkon jak prokopnuté?
Fakt by mě to zajímalo, kde se ten výkon ztrácí.

(Uživatel darovaného šmatlafounu s Android 8.0.0. jádro 4.4. sestavené 2018)

Na druhú stranu tie systémy z toho obdobia boli bezpečnostne totálne inde, mnoho nových kryptoštandardov a podobných vecí nepoznalo, nové TLS? Heslá išli cez nešifrované HTTP po Internete, čitateľné v plain text. Tie systémy taktiež boli pripojené l CRT monitorom s rozlíšením do 640p a 24 FPS, a môžem pokračovať.... o plynulosti Win98 pomlčím, najmä vtedy ľudia mali trpezlivosť aby čakali aj desiatky sekúnd až minúty na otvorenie aplikácie či nejaké úkony.

v skutočnosti kde sa ten výkon stráca nie je čisto "blame Java or JavaScript". A propo, JavaScript dokáže fungovať aj pri stovkách kB až jednotkách MB, nepotrebuje 300MB. To si zamienaš jazyk a špecifický runtime jazyka ako napríklad aplikácie typu Electron.

Nanapadlo by mě šifrování používat jako argument, kde se ztrácí 2000x větší výkon, obzvláště, když na to máme v CPU a TPU specifické instrukce.

640x480 a 24 FPS používal v roce 2000 kdo?
Ti co si nechali monochromatické monitory z XTček z roku 1992?

Takový Sony GDM-FW900 měl v roce 2001 cca o 1 200 000 pixelů víc, než mám teď na počítači, ze kterého píšu.

Win98SE se dal hodně dobře poladit a pak téměř nepadal.
Upravil jsem instalačku, překopal v registrech několik desítek parametrů, vypnul většinu nepotřebných služeb, vyměnil některé .dll knihovny (například tu co integrovala IE) a celý OS včetně driverů měl méně než 50MB.
Na Pentiích MMX 133MHz se 40MB RAM, 2GB HDD to startovalo <12 Sec od BIOSu až na plochu, s čímž jsem měl pak paradoxně chvíli problémy u spanning tree, protože OS nastartoval a síť ještě nebyla připravená.

Provozoval jsem na tom cca 300 výukových programů, >500 vybraných her, >80 editorů a obslužných programů. Většina padání se dala, třeba s pomocí sysinternals oddebugovat a vyřešit. Někdy zabrala jiná verze .dll, někdy úprava registrů, někdy zabrala až IDA Pro.

Jasně, postupně jak přicházely náročnější programy, tak byly nenažranější, ale Win98 jsem vydržel mít v ostrém nasazení cca do roku 2010.

Takže někde se ten 2000x větší výkon ztrácí ještě dřív, než spustím nějakou Elektronovou aplikaci.

On je možná maximální výkon 2000x větší, ale je stále těžší se k tomu maximálnímu výkonu dostat.

Jak to nejde zparalelizovat na hromadu jader, výkon jde brutálně dolů.
Jak to nejde "zparalelizovat" v rámci jednoho vlákna, aby to vytížilo pipeliny(ne jednu, je jich několik paralelně), výkon jde taky dolů.
Cena za page fault nebo cache miss v ticích procesoru je stále vyšší a vyšší. Rychlost paměti prostě neroste tak rychle a navíc jí využíváme víc a víc.
Špatně predikovaná větev taky stojí víc a víc.

Pak to dopadá, že teoreticky neefektivní O(N) algoritmus běhá kolečka kolem "lepšího" O(logN), protože procesor zvládne kopec práce jen když je jednoduše a předvídatelně strukturovaná.