Docela zajímavé, ale váhal bych s OS - na jednu stranu je dost Debian like OS schopných fungovat na ARM, ale s ne úplně ideálním stavem qty aplikací (balíčků).
Na stranu druhou tam lze hodit Android, který je přímo šitý na ARM a nabídka aplikací gigantická, odvrácenou stranou je zase šmírování a množství aplikací optimalizovaných pro ovládání přes matladlo.
Jaky problem mas s qty ARM balicku? S RPi/TinkerBoard/Odroid/ToshibaAC100 sem si niceho nevsiml...
Pořád je spousta SW nástrojů, které mají závislosti na předkompilovaných knihovnách pro x86/x64. A smutné je, že to jsou často součástí pro Javu.
Typickým příkladem je Wine. Takových aplikaci je mraky... Ovladače k tiskárnám... TeamViewer... Programovací nástroje MCU... Můžete se se mnou hádat, že ty aplikace přeci nainstalovat jdou a fungují. To ano, ale vše funguje jen díky závislosti na balíčku, který emuluje instrukční sadu i386.
@m7g takže z mého pohledu nic, co bych používal bez ohledu na to kde. Ale samozřejmě něčí potřeby mohou být jiné.
ad Wine:
https://wiki.winehq.org/ARM
https://wiki.winehq.org/Emulation
https://eltechs.com/product/exagear-desktop/
ad TeamViewer
- bud nad Wine viz vejs, nebo host:
https://www.teamviewer.com/en/download/linux/
https://download.teamviewer.com/download/linux/teamviewer-host_armhf.deb
nejde o to se hadat, to ze neco vyzaduje nejaky emulacni balicek navic je v principu stejne jako kdyz by vyzadoval navic nejakou knihovnu pro jine gpu...
nicmene stale si myslim ze "MeeGo - no future" pri zmince "ne úplně ideálním stavem qty aplikací (balíčků)" chtel rict ze je malo balicku a/nebo ze nejsou dostupne nektere zasadni, to ale neni pravda, pravda je samozrejme ze neni dostupne vse, ale u vetsiny nedosupnych jde o closedsource coz muze resit jen tvurce, ale take je pravda ze pro naprostou vetsinu GNU/Linux uzivatelu je pro ARM dostupnych naprosta vetsina balicku ktere na x86 pouzivaji, tedy muzou si na ARM zarizeni nahrat sve oblibene DE, do nej svuj oblibeny www prohlizec, prehravac medii, kancelarskej balik atd, s tim ze instalaci udelaji ve spravci balicku/software stejne jako na tom zarizeni x86, vyjimka je samozrejme (zatim) instalace vlastniho distra, ktere neni uplne universalni, ale o tom ten povzdech na zacatku vetve nebyl...
Před chvílí mě napadlo Spotify, tam by to ale mělo jít obejít přes prohlížeč s podporou Widevine.
Co se týče Javy, tak tam možná narážel na to, že JNI knihovny je potřeba mít i pro ARM. To by ale byl problém zase spíš u proprietárního SW, kde by to nešlo překompilovat.
Nejde jen o JNI, ale také o žalostný výkon OpenJDK na ARMu. Řešením může být placené a uzavřené Oracle JRE – pokud ovšem máte 64b OS.
(Píšu o Javě 11. Java 8 je na tom lépe z hlediska ceny a podpory 32bit OS, ale Oracle Java 8 je dnes už unsupported.)
http://openjdk.java.net/jeps/297
https://www.voxxed.com/2016/10/oracle-open-sourcing-jdk-9-arm-ports/
http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2017-February/000750.html
Zero má opravdu špatný výkon, ale to je dané tím, že to je C++-only interpret. Nemám žádná data pro srovnání, ale myslím si, že ARM32 a AArch64 JITy jsou relativně dobré. Cortex-A72 i Cortex-A53 jsou ARMv8, takže při použití 64bit OS by se na nich ideálně dal použít AArch64 port. Např. v Debianu je balíček a Azul má certifikované binárky.
Co se týče placené a uzavřené Javy, tak jsem zaznamenal spíše opačný směr. Více věcí se posouvá nad otevřené OpenJDK a o aktualizace starších se stará více komunita.
https://medium.com/@javachampions/java-is-still-free-c02aef8c9e04
Díky za upřesnění. Já se tomu poprvé věnoval někdy v době Javy asi 7 na Raspberry Pi. Tehdy byla situace s OpenJDK bídná. Byl tu ještě Shark založený na LLVM (koukám, že už je na smetišti dějin: https://openjdk.java.net/jeps/8189173 ), ale ani to nebyla žádná sláva. Byl tu ještě jakýsi alternativní Avian s omezenou funkčností. Sice mi přišel rychlejší, ale rychlost dost kolísala a dnes je abandoned.
Nedávno jsem se s někým bavil a z výsledků experimentů jsem usoudil, že vše zůstalo víceméně při starém, akorát Oracle JRE je už trochu zkrouhnuté. Nicméně možná zkoušeli armel a ne armhf, díky za tip.
to je ale podle me neco jineho, jednak by me take zajimalo konkretne co myslis aby se posoudila dulezitost ;-) ale hlavne "MeeGo - no future" psal o neidealnim mnozstvi balicku a to sem v praxi nenarazil ze by nebyl balicek pro ARM toho co pouzivam na x86, pred casem mi sice schazel Vivaldi, ale ten pro ARM uz nejakou dobu je :-)
Ja uz nejaky ten piatok pouzivam Linux na Gemini, co je podobne vykonny HW a mimo uplne krepeho defaultneho WM a pritomnosti systemd, ktory sposobuje obvykle problemy ako vsade inde som s tym spokojny. Tu a tam sa problem v obsolete aplikacii najde, ale zit sa s tym v pohode da.
Povodne som planoval Gemini pouzivat ako convertible prenosny / desktop replacement, ale trocha ma sklamal docking station. Tento Pinebook Pro je celkom chutny kus HW, ktory by zastal funkciu (statickeho) laptopu. V podstate identicky HW je namontovany v Samsung Chromebook Pro (ktory sa ale oficialne do europy nedovaza), takze kompatibilita s Androidom a Chrome OS bude dobra. Zaroven je podpora toho SoC v mainline kerneli.
Myslím, že daleko zajímavější zpráva od Pine je
https://liliputing.com/2019/01/pinephone-linux-smartphone-to-sell-for-149-dev-kits-coming-soon.html
Hlavní zdroj pro dění na FOSDEM 2019
https://forum.pine64.org/showthread.php?tid=7093