Przeglądarka internetowa na maszynie wirtualnej

KamilAdam napisał(a):

I te wszystkie pytania w kontekście tego że mamy już JVM i .NET a zaraz będziemy mieć WASMa na desktopach i serwerach bo ktoś wpadł na szalony pomysł że po co kompilować bitcode LLVM natywnie jak można kompilować do WASMa i uruchamiać WASMa.

Tu potrzeba zejść głębiej

No i poza tym pominąłeś jeszcze powrót do idei cienkiego klienta - robisz remote desktop na swój firmowy desktop z którego robisz remote na wewnętrzny serwer z którego otwierasz telnet na jakiś przedpotopowy mainframe. To jest dopiero izolacja!

loza_prowizoryczna napisał(a):

Wibowit napisał(a):

te pierwsze vmki nie oferują izolacji czy abstrakcji tego samego typu co te drugie.

Ale ty mi świata nie tłumacz, ty mi lepiej wytłumacz po co komuś w dzisiejszym świecie abstrakcja czegoś co w enterprise jedzie na jednej architekturze która jest obecnie standardem przemysłowym.

przecież java lata też na armach (głównie smartfony, ale też np chmury obliczeniowe) i innych architekturach. zresztą to czy lata na jednej czy milionie nie jest jedynym kryterium. jvm podczas ładowania bajtkodu weryfikuje jego poprawność, np. to czy każdy push ma popa, czy skoki są w dozwolone miejsca itd więcej szczegółów np tutaj: https://www.oracle.com/java/technologies/security-in-java.html w sekcji o weryfikowaniu bajtkodu. po zJITowaniu może wyjść kod np x86, który jest dużo trudniejszy do zweryfikowania niż oryginalny bajtkod (np. tak trudny, że praktycznie weryfikacja jest nieosiągalna), więc lepiej weryfikować na poziomie bajtkodu.

wasm też ma weryfikację poprawności, np:
https://developer.mozilla.org/en-US/docs/WebAssembly/Understanding_the_text_format#stack_machines

The WebAssembly validation rules ensure the stack matches exactly: if you declare a (result f32), then the stack must contain exactly one f32 at the end. If there is no result type, the stack must be empty.

.

loza_prowizoryczna napisał(a):

A tymi drugim to pies z kulawą by się nie interesował gdyby nie rozwój chmury i związane z tym wyzwania dot. izolacji czy uproszczenia deploymentu.

konteneryzacja i vmki to także świetny sposób, żeby nie śmiecić sobie bezpośrednio w sytemie.

izolacja między vmkami pozwala w miarę bezpiecznie odpalać potencjalny malware, jeśli używamy dobrze zabezpieczonych systemów typu https://www.qubes-os.org/ (zamierzam sobie kupić lapka na qubes os w niedalekiej przyszłości, ale nie wiem kiedy jeszcze).

loza_prowizoryczna napisał(a):

W końcu po coś ten tryb interpretera w tym JVM tam zostawili.

Tylko dowcip polaga na tym, że masz w pełni dynamiczny język, który działa sprawnie jak kompilowany - masz ciasteczko i jesz ciasteczko.

No i na koniec tego bezsensownego dylematu pozostaje kwestia: Dlaczego JVM a nie LLVM?

Nie ma to żadnego specjalnego uzasadnienia - od nastu lat jestem dżewowcem, (ostatnie lata scalowcem), znam język, znam biblioteki no i programy jakie zwykle do mnie trafiają to typowe backendy jakie się robi w javie i scali :-)
Co nie znaczy, że czasem nie robie w czymś innym (np. Haskell (fajnie) czy Golang (bardzo niefajnie)) oba w teorii mogą być kompilowane do llvm, ale nikt nawet o to nie spytał...

Wibowit napisał(a):

przecież java lata też na armach (głównie smartfony, ale też np chmury obliczeniowe) i innych architekturach. zresztą to czy lata na jednej czy milionie nie jest jedynym kryterium.

Inne języki też latają ale nie potrzebują abstrakcji na ISA, na smartfonach ta proteza Javy od dawna leci w trybie AOT bo w gugielu jednak rozumieją rzeczy. Kryterium jest: skoro mamy praktycznie jednolity standard przemysłowy jeśli chodzi o architekturą, znakomity framework do tworzenia wydajnych kompilatorów na nowe (np. RISC-V) to po cholerę utrzymywać narzut abstrakcji?

jvm podczas ładowania bajtkodu weryfikuje jego poprawność, np. to czy każdy push ma popa, czy skoki są w dozwolone miejsca itd więcej szczegółów np tutaj: https://www.oracle.com/java/technologies/security-in-java.html w sekcji o weryfikowaniu bajtkodu. po zJITowaniu może wyjść kod np x86, który jest dużo trudniejszy do zweryfikowania niż oryginalny bajtkod (np. tak trudny, że praktycznie weryfikacja jest nieosiągalna), więc lepiej weryfikować na poziomie bajtkodu.

To tłumaczy czemu jest tak wolna jak startuje (ach ten tryb interpretera) ;) To po pierwsze, po drugie - kto używa Oraclowej implementacji? A po trzecie - skoro tak to po co nam Rust?

konteneryzacja i vmki to także świetny sposób, żeby nie śmiecić sobie bezpośrednio w sytemie.

Konteneryzacja tak - w końcu NextStep je wdrożył i inni się przekonali. VMki? Wirtualizowałeś sobie kiedy dostęp do GPU który nie kosztuje tyle co dobry samochód na starcie?

izolacja między vmkami pozwala w miarę bezpiecznie odpalać potencjalny malware, jeśli używamy dobrze zabezpieczonych systemów typu https://www.qubes-os.org/ (zamierzam sobie kupić lapka na qubes os w niedalekiej przyszłości, ale nie wiem kiedy jeszcze).

To jest ciekawe bo większość malware zazwyczaj się nie aktywuje jeśli wykryje że działa w środowisku zwirtualizowanym, po prostu takie środowiska służą zazwyczaj do obserwacji ich działania.

nie będę się kłócił o sens vmek, jita i tak dalej. java, c#, js, python, itp itd to platformy zarządzane działające w tybie interpretera i/lub jita i zdecydowana większość programistów na takie coś programuje.

loza_prowizoryczna napisał(a):

izolacja między vmkami pozwala w miarę bezpiecznie odpalać potencjalny malware, jeśli używamy dobrze zabezpieczonych systemów typu https://www.qubes-os.org/ (zamierzam sobie kupić lapka na qubes os w niedalekiej przyszłości, ale nie wiem kiedy jeszcze).

To jest ciekawe bo większość malware zazwyczaj się nie aktywuje jeśli wykryje że działa w środowisku zwirtualizowanym, po prostu takie środowiska służą zazwyczaj do obserwacji ich działania.

nie chodzi mi o obserwację malware, a raczej o np. używanie ruskich modów do starych gier, testowaniu programów do kompresji niewiadomego pochodzenia czy czytaniu pdfów i ogólnie oglądaniu multimediów (również niewiadomego pochodzenia).

ale jeśli chodzi o androida to jit powrócił:
https://medium.com/programming-lite/android-core-jvm-dvm-art-jit-aot-855039a9a8fa

Reintroducing of JIT with ART
Though ART improved app performance, there were some drawbacks of ART.

Drawbacks of ART
App Installation takes more time because of DEX bytecodes conversion into machine code during installation.
As the native machine code generated on installation is stored in internal storage, more internal storage is required.
To tackle these problems such as initial installation time and memory from Android Nougat JIT (Just In Time ) Compilation was reintroduced with code profiling along with AOT, and an interpreter in the ART thus making it hybrid. Using the Hybrid Runtime, there won’t be any compilation during install, and applications can be started right away, the bytecode is interpreted.
Now with ART and the new JIT the application installation is faster. The new JIT constantly does profiling and improves applications as they run.

jarekr000000 napisał(a):

Tylko dowcip polaga na tym, że masz w pełni dynamiczny język, który działa sprawnie jak kompilowany - masz ciasteczko i jesz ciasteczko.

A to są jeszcze jakieś nowoczesne runtime'y które nie utylizują JITa w ten czy inny sposób? Poza tym JVM do czasu invoke_dynamic i tak był nędzny w tym zakresie.

No i na koniec tego bezsensownego dylematu pozostaje kwestia: Dlaczego JVM a nie LLVM?

LLVM jest otwarte od samego początku i za jego rozwojem stoi Apple, JVM od wyroczni kosztuje krocie a jego otwarta wersja cierpi na komunizm (GPL).

Wibowit napisał(a):

nie będę się kłócił o sens vmek, jita i tak dalej. java, c#, js, python, itp itd to platformy zarządzane działające w tybie interpretera i/lub jita i zdecydowana większość programistów na takie coś programuje.

Brawo :)

nie chodzi mi o obserwację malware, a raczej o np. używanie ruskich modów do starych gier, testowaniu programów do kompresji niewiadomego pochodzenia czy czytaniu pdfów i ogólnie oglądaniu multimediów (również niewiadomego pochodzenia).

Do tego wystarczy stary dobry wyizolowany PC i odrobina zdrowego rozsądku. Wewnątrz to się mogą eksploitować aż osiągną samoświadomość.

loza_prowizoryczna napisał(a):

Wibowit napisał(a):

nie chodzi mi o obserwację malware, a raczej o np. używanie ruskich modów do starych gier, testowaniu programów do kompresji niewiadomego pochodzenia czy czytaniu pdfów i ogólnie oglądaniu multimediów (również niewiadomego pochodzenia).

Do tego wystarczy stary dobry wyizolowany PC i odrobina zdrowego rozsądku. Wewnątrz to się mogą eksploitować aż osiągną samoświadomość.

mam ten luksus, że stać mnie na gotowca, więc jak będę miał ochotę to kupię kompa obsługującego qubes os i nie będę musiał się zastanawiać o co ci dokładnie chodziło. qubes os ma za sobą wiele lat projektowania, cały zespół specjalistów, obszerną dokumentację opisującą różne modele zagrożeń i to jak qubes os sobie z nimi radzi, programy do bezpiecznej komunikacji między vmkami (włączając oczywiście komunikację między zainfekowaną vmką, a niezainfekowaną) i do wygodnego żonglowania dziesiątkami vmek (np. qubes os oferuje łatwe w użytku disposable vm) itp itd

Wibowit napisał(a):

mam ten luksus, że stać mnie na gotowca, więc jak będę miał ochotę to kupię kompa obsługującego qubes os i nie będę musiał się zastanawiać o co ci dokładnie chodziło.

No dobrze - ale co z wirtualizacją GPU? Ewentualnie GPU passthrough?

loza_prowizoryczna napisał(a):

No dobrze - ale co z wirtualizacją GPU? Ewentualnie GPU passthrough?

to będzie na innym kompie :)

generalnie mój plan jest taki, żeby:

• komp 1) użyć qubes os do potencjalnie agresywnego malware, czyli te ruskie mody do starych gier czy programy do kompresji danych niewiadomego pochodzenia, czy pdfy i multimedia niewiadomego pochodzenia - do żadnej z tych rzeczy nie potrzebuję akceleracji sprzętowej
• komp 2) do czegoś do czego mam chociaż trochę zaufania sklecę sobie jakieś zwykłe vmki (z pełnym przyspieszeniem sprzętowym) i być może przeniosę na nie parę trików z qubes os jeśli się nadadzą