A böngészőkön kívül is használható lesz a WebAssembly

A böngészőkön kívül is használható lesz a WebAssembly
2019-03-29T11:57:17+01:00
2019-04-05T00:58:17+02:00
2022-10-18T09:41:56+02:00
  • "Natívra forduló", csak épp siettem.
    Mutasd a teljes hozzászólást!
  • Amúgy a wasm lényege az újrafelhasználás lenne, létező natív kódok fordítása böngészőben futó változatra.

    Ilyen nincs. A natív kód attól natív kód, hogy közvetlenül a processzoron fut.
    Mutasd a teljes hozzászólást!
  • A wasm-on futó .NET neve Blazor. GitHub-on, meg a saját site-ján is találkozhatsz vele (talán blazor.net). Amúgy a wasm lényege az újrafelhasználás lenne, létező natív kódok fordítása böngészőben futó változatra.
    Mutasd a teljes hozzászólást!
  • engem csak a neve zavar egyébként.
    weben én még csak játékonál találkoztam vele.

    ha már próbálkoztál BÁRMILYEN alkalmazást fejleszteni WEBRE webassemblyben,
    akkor tudhatod hogy fölöslegesen bonyolult. gyorsabban lehet megtanulni a komplett
    angular-t, és ráadásul csak néhány böngésző támogatja (még akkor is ha ez a néhány
    böngésző történetesen a piac 90%-át teszi ki)

    valószínűleg "natív" alkalmazásokat egyszerűbb lesz fejleszteni (ott legalább a libc adott).
    csak ne állítsák be mint legújjabb hiperszuper mindentudó multiplatform kicsitsemtákolmány
    varázseszköz, amivel innentől kezdve minden problémád megoldódik.


    ja egyébként a JVM-et és a .NET Core runtimot is le lehetne fordítani WebAssembly-re.
    És akkor jó konkurense lehetne pl. a Dockernek, már ha külön mappát is kap
    a gép, amiben a cuccait tarthatja, és ezt a telepítéskor mondjuk egy zipből kicsomagolja.
    vagy virtuális merevlemez(linuxon azért nem nehéz megoldani, windows egy másik kérdés...)
    Mutasd a teljes hozzászólást!
  • de az openjdk elvileg GPL, nem?
    akkor pedig a GPL feltételei szerint arra használom amire akarom,
    csak GPL-ként kell továbbadni.
    vagy az android api nem GPL? mert én azt hidtem...
    Mutasd a teljes hozzászólást!
  • Akkor most mindenki nézzen utána a GraalVM-nek:

    Minden vagyam az oracle vm-jere epiteni hosszu tavu projektet, hogy aztan fizethessek orankent es cpu-nkent.
    Mutasd a teljes hozzászólást!
  • Akkor most mindenki nézzen utána a GraalVM-nek:

    GraalVM
    Mutasd a teljes hozzászólást!
  • Ha röviden össze karom foglalni, akkor amellett, hogy ez az első kompromisszummentes megoldás a több forrásnyelv - egy tárgykód - több platform, beleértve a webet problémára. Ráadásul a WASM már ott van a böngészőkben. Hamarosan a szervereken és desktop-on is ott lesz. Ez azért nagy szó szerintem. A korábbi megoldásoknak mind volt valami nyűgje.
    Mutasd a teljes hozzászólást!
  • Te most végülis mi mellett érvelsz?
    Az én állításom röviden összefoglalva annyi, hogy a WASM és a WASI évtizedes ötletek újabb megvalósítása, így világmegváltás nincs benne, és a konkrét tulajdonságai (köztük a futtatókörnyezet mérete és a sebesség) is összemérhetők lesznek a többi létező cuccéval.
    Mutasd a teljes hozzászólást!
  • Hogy épp melyik algoritmusnak kell majd a natív 64 bit azt elég nehéz megmondani. Nyilván pont akkor fog szembe jönni egy képfeldolgozó, tömörítő vagy csak egy random hash algoritmus, aminek kellene 64 bites uint, amikor a legkevésbé várnád. Vagy épp egy külső forrásból származó adatcsomagot kellene feldolgozni, ahol erősen építenek arra, hogy a 64 bit az 64 bit és nem 63. De egyáltalán, miért erőlteted ezt a JVM dolgot? Már rég nincs benne egy böngészőben sem. Igazából sosem vált webes szabvánnyá. Ugyanúgy, ahogy az ActiveX sincs benne a böngészőkben. Ugyanakkor a WASM nyílt webes szabvány lett. Lehet merengeni azon, hogy mi lett volna ha az ActiveX vagy a JVM elindul a nyílt szabvány felé vezető úton ... De eleve profitszerzésre találták ki őket, nem "dicsőségre" hajtottak. Egyáltalán nem akarták nyílt szabvánnyá tenni azokat a technológiákat. Abban igazad van, hogy ezt az egész koncepciót legalább 20 éve már kitalálták, csak mostanra lesz az egészből nyílt szabvány.

    A WASI sandbox én sem tudom milyen lesz. De továbbgondolva a dolgot, valamiféle VirtualBox, VMware , Docker jellegű dolog kell legyen belőle. Annyi különbséggel, hogy csak WASM + WASI kombót tud majd futtatni. Gondolom megkérdi majd, hogy milyen jogoat szeretne a program (Network, Filesystem, Display, Sound, Keyboard input, ...) te meg jóváhagyhatod. Valami ilyesmi jött le a leírásból. De igazából én is kíváncsi vagyok, hogy mi lesz az egészből...
    Mutasd a teljes hozzászólást!
  • Persze hallottam, de visszakérdeznék. Hallottál már a Google - Oracle perről az Androidban használt Java API kapcsán? Ha elkezdik majd vitatni, hogy az nem fair amit csinálsz, akkor mehetsz a bíróságra és mint a példa mutatja, akár el is veszítheted a pert. Nyílt szabvány használata esetén ilyen fel sem merül.

    Oracle America, Inc. v. Google, Inc. - Wikipedia
    Mutasd a teljes hozzászólást!
  • Persze elintézheted ennyivel, hogy minek 64 bit, elég legyen már 63 bit mindenkinek. Szerintem maradhatunk annyiban, hogy a JVM-nek vannak ilyen kis limitációi.

    Lehet ezen rugózni, persze. Ekkora számoknál én mondjuk bit-műveleteket szoktam csak használni, ott meg mindegy, hogy előjelesnek hiszi-e a gép, vagy sem. Vagy te tényleg for ciklussal szoktál 0-tól 9223372036854775807-ig számolni, mert tömbindexelésre kell? Korlátlan méretű számokkal való műveletvégzésre amúgy sem a natív típusok valók, és ezen a webassembly sem változtat.

    Oké hozzá lehet, de milyen limitációkkal? Ha lehet "tiszta" implementációt készíteni, miért kellene hackelgetni?

    Utánanéztél? A Wikipedia amúgy kicsit le van maradva, már a projekt neve is más, de nem merültem el a részletekben.

    A WASI egy direktben valamiféle int80 / int21 / syscall CPU utasítás helyettesítő akar lenni, amivel kihívsz valamilyen operációs rendszerbe vagy környezetbe ( böngészőbe) . Mindezt modulos felépítésben. Persze mondhatod, hogy ezeket az oprendszer hívásokat lehet Java API-val implementálni.

    A WASI közben sandboxról meg biztonságról is beszél. Ezt a csodavárás közben teljesen figyelmen kívül hagyod. A sandboxnak a világon mindent ellenőriznie kell, különben lőttek a biztonságnak.

    Amúgy nem veszekszünk, csak nem látom a hurráoptimizmus okát. Az egész történet a kizárólagosságról szól: a JavaScript 10-15 éves vergődés után úgy lett "legjobb" nyelv, hogy előbb minden mást ki kellett utálni mellőle, és a webassembly is csak erre a vívmányra épül. Hiszen alapvetően már a 20+ éves ActiveX ötlete is ugyanez volt, így elképesztő újszerűségről azért nem beszélnék. (Ez a bekezdés nyilván a böngészőben futó kódokról szólt, nem a WASI-ról).
    A weben terjengő sötétség meg kifejezetten bosszant, a "Mozilla tries to do Java as it should have been"-jellegű címek.
    Mutasd a teljes hozzászólást!
  • OpenJDK rol hallottal már?
    Mutasd a teljes hozzászólást!
  • Minden program alapköve, a 64-bites egész...

    Persze elintézheted ennyivel, hogy minek 64 bit, elég legyen már 63 bit mindenkinek. Szerintem maradhatunk annyiban, hogy a JVM-nek vannak ilyen kis limitációi.

    Mondjuk ha LLVM bitcode-ot lehet hozzá passzintani,

    Oké hozzá lehet, de milyen limitációkkal? Ha lehet "tiszta" implementációt készíteni, miért kellene hackelgetni?

    Szinte az egész JRE meg az API az.

    A WASI egy direktben valamiféle int80 / int21 / syscall CPU utasítás helyettesítő akar lenni, amivel kihívsz valamilyen operációs rendszerbe vagy környezetbe ( böngészőbe) . Mindezt modulos felépítésben. Persze mondhatod, hogy ezeket az oprendszer hívásokat lehet Java API-val implementálni.

    Amúgy nem állítom, hogy nem lehetne nagyon nagy részét megcsinálni ezeknek JVM-ben vagy akár módosításokkal mindent. Szerintem az Oracle szabadalom jogai korlátozzák leginkább az ilyen fejlesztéseket. Az Oracle-nek az tetszene nagyon, ha mindenki JVM-et használna ÉS fizetne utána valamilyen jogdíjat. A JVM ilyen szempontból inkább egy kereskedelmi termék, semmint valamiféle ingyen használható és módosítható szabvány. A
    Google - Oracle évekig elhúzódó jogi vitája a Java használat fölött mutatja, hogy nagyon nem érdemes hozzápiszkálni a Java ökoszisztémához. Ugyanakkor a WASM, ha kap garbage collection támogatást, akár tud majd Java-t is futtatni majd, hacsak be nem perel érte az Oracle.
    Mutasd a teljes hozzászólást!
  • de JVM-ben még az unsigned int64 is problémás.

    Minden program alapköve, a 64-bites egész...

    Emiatt nincs is ott a C/C++/Rust

    Mondjuk ha LLVM bitcode-ot lehet hozzá passzintani, akkor nem is kell. Hiszen C/C++-hoz ott a clang, Rust esetében meg ki se tudod kerülni.
    Amúgy Pascal meg pont van a felsorolásban, pedig az se kifejezett GC-s nyelv.

    a WASI-nak nincs is nagyon JVM-es megfelelője

    Szinte az egész JRE meg az API az. Ha párhuzamot akarsz vonni, a Hotspot és társai a processzor, a körítés meg az oprendszer. Az absztrakt és a virtuális ugye programozás közben is gyakran összeérnek...
    A webassembly egyszerűen jókor van jó helyen: a plugineket kiutálták a böngészőből, de kiderült, hogy mégis kéne valami, 'oszt ez lett. De ettől még nem lett csoda és ingyen sincs.
    Mutasd a teljes hozzászólást!
  • Valószínű lehet hackelgetni, de JVM-ben még az unsigned int64 is problémás. Alapvetően a Java nyelvre hegyezték ki, ami meg garbage collectoros. Emiatt nincs is ott a C/C++/Rust ... .El lehetne menni abba az irányba, hogy bővíteni a JVM utasítás készletét, de gondolom az Oracle miatt senki nem mer hozzápiszkálni.

    Leegyszerűsítve a WASM egy absztrakt processzor, a WASI meg egy absztrakt operációs rendszer. Na most a WASI-nak nincs is nagyon JVM-es megfelelője.
    Mutasd a teljes hozzászólást!
  • Valami nyelvfüggetlen JVM-ként lehet elképzelni.

    Ilyen van már, JVM-nek hívják: List of JVM languages - Wikipedia  - a legjobb, hogy a táblázat szerint van LLVM bitcode illesztés JVM-hez, márpedig a wasm cuccok is elsősorban LLVM-mel készülnek.
    Mutasd a teljes hozzászólást!
  • Valami nyelvfüggetlen JVM-ként lehet elképzelni. Most is lehet mindenre C-t fordítani, de mindenütt más lesz most a bináris, meg más runtime-hoz kell magad linkelni állandóan. Most majd lehet olyan OpenGL-t használó GUI-s programot is írna, ami ugyanúgy megy böngészőben, Linuxon meg Windowson és Mac-en, natív közeli sebességgel, változatlan bináris mellett. Legalábbis ez a terv, meglátjuk mi lesz belőle.
    Mutasd a teljes hozzászólást!
  • Erről a WASI-ról konkrét tapasztalata szerintem még senkinek nincs, mert még csak tervezik jelenleg.

    Ha engem kérdezel a várható jövőről, szerintem az lesz, hogy mindenki csomagolja magának a neki kellő modulokat, hisz azok nem túl nagyok. Modularitása miatt biztos kisebb lesz, mint a mostani Electron-os megközelítés, hogy becsomagolnak egy komplett böngészőt. Ha csak egy mini terminálos CLI programot kell írni, akkor csak valami terminál illesztő modult raknak majd hozzá. Ennél konkrétabb becslést most szerintem még nem lehet szerintem mondani.
    Mutasd a teljes hozzászólást!
  • Senkinek nincs szerintem WASM kódja, vagy ha van kézzel írott, akkor az minimálsi. A WASM egy célplatform fordítóprogramoknak. A WASM bináris JIT-el lesz futtatva a cél platformon. Ez a WASI direktben fog OpenGL, Vulkan vagy más API-okat hívogatni. Nyilván a legfontosabbak a Network, Filesystem stb.. lesz először. Mivel rengeteg program készült C/C++/Rust,Go stb. kódban, ezeknek egy nagy könnyebbség lehet.

    A WASM tervezett fejlődéséről itt egy jó összefoglaló:
    WebAssembly’s post-MVP future: A cartoon skill tree – Mozilla Hacks - the Web developer blog
    Mutasd a teljes hozzászólást!
  • Tehát akkor a JVM-et találjuk fel újra? Szerintem meg már most is lehet WASM-et böngészőn kivül használni mert minden nyelv (Go,Rust..) amiből lehet WASM-re forgatni képes bármelyik platformra futatható állományt késziteni.
    Mutasd a teljes hozzászólást!
  • Minden attól függ, hogy mire kell, és hogyan számolod:
    - egy futtatókörnyezet per gép (mint Java, .NET), vagy sem?
    - milyen körítés kell hozzá?
    Mert a platformfüggetlen, sandboxos, JIT-es virtuálisgépezés azért önmagában sincs teljesen ingyen, és minél többfelé kell kapcsolódnia, annál inkább csak nő (hiszen a virtuális környezet és valódi környezet közé mindenhova kell valamennyi illesztést pakolni - különösen ha a biztonságot is komolyan gondolod.
    PHP, nodejs, vagy akár Adobe AIR, mind-mind 15-35 megákról indulnak, a wasmtime se valószínű, hogy ez alá tud töpörödni. Mondjuk nekem tegnap szimplán csak nem fordult, szóval konkrét számot nem tudok mondani.
    Mutasd a teljes hozzászólást!
  • Eddig annyit ér, mint a DotNetCore 1.0.

    Ami nem kevés, a C# koderek sok-sok kódja és tapasztalata hasznosítható, újrafelhasználható, de tény, vannak problémák, pl. a GUI szintjén. :)

    Vagyis ez elsőre csak azoknak lesz jó, akiknek sok WASM kódjuk van böngészőbe és szeretnék kitágítani a használat körét. 



    Ebben kezdeni bármi újat lemaradásból indulást jelent a Java vagy C# világhoz képest.
    Mutasd a teljes hozzászólást!
  • Mondom, hogy félreérted. Ez az Electron, amiről beszélsz, az szól erről. A WASI + WASM-ben nincs se weblap, se webview se semmi.
    Mutasd a teljes hozzászólást!
  • De, behajítani egy webviewbe egy weblapot majd eladni appként az pontosan a lexikoni példája a tákolásnak.
    Becsomagolhatod ahogy akarod, tákolás marad.
    Mutasd a teljes hozzászólást!
  • Most nem tudod elindítani a .exe fájlodat a weben, csak desktop gépen. WASM + WASI erre is lehetőséget ad majd.
    Mutasd a teljes hozzászólást!
  • Valamit félreértesz, ez pont nem az a tákolós technológia.
    Mutasd a teljes hozzászólást!
  • Lassan el jutunk oda, hogy lesz egy .exe/.bin amit lehet futtatni, jah várj onnan indultunk :)
    Mutasd a teljes hozzászólást!
  • Attól, hogy a tákolást becsomagolod arany fóliával még tákolás marad.
    Mutasd a teljes hozzászólást!
  • Igen, mert a jelenlegi megoldás az, hogy egy komplett chrome-ot becsomagolnak és abban futtatják az alkalkmazást. Ez ugye az Electron amivel az Ethereum Wallet is készült. A webassembly is úgy nézett ki eddig, hogy a chrome vagy más böngésző, ami ugye tudja a webassemblyt abban futott minden. Ez a mostani WASI pont a böngészőt váltja ki egy vékony libc méretű modulra. Tehát nem program ( JS és/vagy WASM)+ böngésző lesz a végeredmény, hanem program ( WASM ) + WASI .
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd