Pinebook Pro ARM notebook za 199 dolarů

@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...

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.)

No je to tak... Tím nechci shazovat ARM, naopak doufám v lepší a hlavně nativní podporu.

No, ono je to s OpenJDK takové složitější. Nemám v tom úplně jasno (+ věnuji se pouze ARM32 Javě), ale JVM má zhruba následující konfigurace/porty:

• Zero (JDK12) - je to obecný interpreter, ale hodně pomalý. Je to výchozí volba pro (už) nepodporované platformy (např. procesory se starší ISA než ARMv7). Např. Debianí balíček pro armel je jenom Zero.
• ARM32 (JDK12) - Oraclí ARM port. Původně byl proprietární, ale byl uvolněn do OpenJDK 9. Myslím si, že to je víceméně následovník Embedded JDK. Oficiálně podporuje armv7 hardfloat a novější, neoficiálně funguje ještě i armv5 softfloat. Podporuje Client i Server JIT, Server je ale dostupný jen na armv7 armhf.
• ARM64 (JDK11) - Oraclí ARM64 port, součást předchozího portu. Taky byl uvolněn do JDK 9, ale byl časem odstraněn, protože AArch64-only port už tehdy v OpenJDK byl.
• AArch32 (větev JDK9) - Komunitní ARM port. Pamatuji si, že podporoval jenom armv7 a výš a nejspíš byl jenom ve vedlejším stromu. Byl nahrazen ARM32 portem.
• AArch64 (JDK12) - Komunitní ARM64 port, současná volba pro 64bitové ARMy.

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.