IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

JavaScript Discussion :

Microsoft, Google et ARM viennent grossir les rangs de la Bytecode Alliance


Sujet :

JavaScript

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Rédacteur technique
    Inscrit en
    Mars 2017
    Messages
    1 177
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Madagascar

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2017
    Messages : 1 177
    Points : 78 774
    Points
    78 774
    Par défaut Microsoft, Google et ARM viennent grossir les rangs de la Bytecode Alliance
    Mozilla, Fastly, Intel et Red Hat lancent l’Alliance Bytecode, une initiative construite autour de WebAssembly
    Qui propose d’apporter plus de sécurité, d’ubiquité et d’interopérabilité sur le Web

    Dans un effort commun visant à faire de WebAssembly un runtime informatique multiplateforme, les entreprises Mozilla, Fastly, Intel et Red Hat ont annoncé le lancement de l’Alliance Bytecode. Cette initiative architecturée autour de WebAssembly est axée sur la fourniture d’un bytecode sécurisé par défaut qui peut être exécuté depuis un navigateur Web, un ordinateur de bureau ou une plateforme IoT/embarquée.

    Nom : bytecode_alliance_featured-image-600x330-490x270.jpg
Affichages : 13057
Taille : 19,6 Ko

    Pour rappel, WebAssembly a été présenté comme une architecture de jeu d’instructions virtuel avec de nombreux cas d’utilisation capable de prendre du code écrit dans des langages de programmation autres que JavaScript et d’exécuter ce code sur une plateforme spécifique – du moins à l’origine -, un navigateur en l’occurrence. Cette solution devrait également permettre aux applications complexes - telles que les jeux vidéo immersifs en 3D, le design informatisé ou l’édition d’images et de vidéos - de fonctionner de façon optimale sur les plateformes cibles. Grâce à WebAssembly, des développeurs seraient par exemple en mesure de coder leurs applications en C, C++ ou en Rust et de faire exécuter ces programmes à la vitesse native sur un navigateur Web, sans avoir à repasser par JavaScript avec les contraintes que cela impose.

    Selon les promoteurs l’initiative, la montée en puissance du Cloud et des périphériques IoT fait que les développeurs exécutent du code non fiable dans de nouveaux environnements, ce qui soulève de nouveaux problèmes, notamment en matière de sécurité et de portabilité. L’Alliance Bytecode devra fournir une base permettant aux développeurs d’exécuter en toute confiance du code non fiable sur n’importe quelle infrastructure, système d’exploitation et périphérique. Cette communauté open source se focalisera sur la mise en place d’un environnement d’exécution et de chaînes d’outils linguistiques associées – incluant cargo-wasi, wat et wasmparser – qui offrent sécurité, efficacité et modularité sur une large gamme d’architectures et de périphériques. Le projet devrait s’appuyer sur les normes existantes telles que WebAssembly et WebAssembly System Interface (WASI).

    Les nanoprocessus de WebAssembly

    WebAssembly peut fournir le type d’isolation qui permet d’exécuter en toute sécurité du code non fiable, grâce à une architecture similaire aux nombreux petits processus d’Unix, ou aux conteneurs et aux microservices. Toutefois, cet isolement est beaucoup plus léger et la communication entre les nanoprocessus de WebAssembly ne souffre d’aucune réduction de performance, au contraire. Cela signifie que vous pouvez les utiliser pour empaqueter une seule instance de module WebAssembly ou une petite collection d’instances de module qui veulent partager des choses comme la mémoire entre eux. De plus, vous n’avez pas besoin d’abandonner le langage de programmation, comme les signatures de fonctions et le contrôle de type statique.

    Nom : 04-01-process-vs-nanoprocess-500x382.png
Affichages : 2484
Taille : 51,2 Ko

    Cette propriété est due au fait que chaque module WebAssembly est sandboxé par défaut ainsi qu’à la particularité de l’architecture mémoire. En effet, chaque module WebAssembly n’a pas accès à la totalité de la mémoire dans son processus - uniquement au bloc de mémoire qui lui a été assigné et qui est isolé du reste du pool -. En parallèle, grâce à une fonctionnalité introduite en aout dernier sur WebAssembly - les types d’interfaces -, il est facile pour deux modules d’échanger des données, mais toujours de façon sécurisée et rapide, et le moteur de WebAssembly permet d’effectuer des copies directes au niveau de la mémoire. Ces opérations fonctionnent même si les deux modules ne sont pas compilés à partir du même langage.


    Malheureusement, la façon dont la plupart des systèmes d’exploitation gèrent l’accès au système de fichiers n’offre pas forcément un niveau de sécurité optimal et il ne suffit pas de prendre des précautions vis-à-vis de la gestion mémoire entre les modules WabAssembly pour que tout soit parfaitement sécurisé. Il faut aller encore plus loin et s’intéresser aux API et aux appels système qui intègrent « le concept de permission », de sorte qu’ils puissent octroyer différentes permissions à différents modules et différentes ressources. C’est là qu’intervient la fonctionnalité baptisée WASI (WebAssembly system interface) qui permet d’isoler ces différents modules les uns des autres, de leur octroyer avec précision des permissions bien spécifiques et de verrouiller le système.

    Malgré tout, le système n’est pas encore au point, les développeurs en charge du projet ayant eux-mêmes reconnu que pour l’instant, ils n’ont trouvé aucun moyen de faire passer les clés de contrôle du système par l’arbre des dépendances. À ce sujet, ils ont confié : « Nous avons besoin d’un moyen pour permettre aux modules parents de donner ces clés à leurs dépendances. De cette façon, ils peuvent donner à leurs dépendances exactement les clés dont ils ont besoin et aucune autre. Et puis, ces dépendances peuvent faire la même chose pour leurs enfants, jusqu’au bout de l’arbre ». Mais ils comptent bien s’attaquer à cet ultime défi. Sur le plan technique, ils prévoient d’utiliser une forme de virtualisation granulaire par module. L’idée est de fournir un écosystème WebAssembly sécurisé par défaut pour toutes les plateformes qui pourra protéger efficacement contre les codes malveillants ou les vulnérabilités inhérentes au code, par exemple.

    L’avis des promoteurs du projet

    Luke Wagner, un ingénieur chez Mozilla, a expliqué à ce propos : « Le standard WebAssembly est en train de transformer le Web et nous pensons qu’il peut jouer un rôle encore plus important au sein de l’écosystème des logiciels, en se développant au-delà des navigateurs. C’est un moment unique pour cette nouvelle technologie, car nous avons l’occasion de réparer ce qui est obsolète et d’établir, pour un développement natif, de nouvelles fondations sécurisées par défaut, mobiles et évolutives. Nous devons toutefois prendre des mesures réfléchies et à travers l’industrie pour nous assurer que ces mesures sont bien appliquées ».

    Nom : 654.png
Affichages : 2417
Taille : 17,4 Ko

    De son côté Mark Skarpness, vice-président de la division Architecture, Graphiques et Logiciels d’Intel a déclaré : « Intel rejoint l’Alliance Bytecode en tant que membre fondateur afin d’offrir à un large éventail d’applications et de serveurs de meilleures performances et une sécurité renforcée de l’environnement WebAssembly, en allant au-delà du navigateur. Les technologies de l’alliance Bytecode peuvent aider les développeurs à faire évoluer les logiciels en utilisant une multitude de langages et en s’appuyant sur toutes les capacités des plateformes de calcul de dernière génération ».

    Chris Wright, Senior Vice-President et Chief Technology Officer chez Red Hat, estime quant à lui que « les technologies Open Source jouent un rôle important dans la mise en place des fondations informatiques, du système d’exploitation au navigateur en passant par des clouds hybrides ouverts ». Il a ajouté : « Nous sommes heureux de participer avec nos partenaires à son évolution vers un projet mature et entièrement communautaire ».

    Nom : featured-image-500x250.png
Affichages : 2751
Taille : 60,1 Ko

    Un certain nombre de projets open source ont été apportés à ce projet par les différents membres. Il s’agit notamment de :
    • Wasmtime, un environnement d’exécution léger et performant pour WebAssembly et WASI ;
    • Lucet, un environnement d’exécution avec compilation hors ligne pour WebAssembly et WASI axé sur les applications à faible latence et à haute concurrence ;
    • WebAssembly Micro Runtime (WAMR), un environnement d’exécution WebAssembly basé sur un interpréteur pour les périphériques embarqués ;
    • Cranelift, un générateur de code multiplateforme qui met l’accent sur la sécurité et la performance, écrit en Rust.


    Source : Mozilla, Alliance ByteCode

    Et vous ?

    Que pensez-vous de cette initiative ?

    Voir aussi

    Le WebAssembly serait moins performant en terme de rapidité que le code natif, selon les résultats d'une étude
    50 % des sites web utilisent WebAssembly à des fins malveillantes, selon une étude de la Technische Universität Braunschweig
    RustPython, un interpréteur Python écrit en Rust et compatible avec WebAssembly, est disponible, pourrait-il rivaliser avec CPython ?
    Mozilla finance un portage de Julia en WebAssembly afin d'effectuer des calculs lourds au sein du navigateur
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre habitué
    Homme Profil pro
    WANT
    Inscrit en
    Juin 2011
    Messages
    45
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Finlande

    Informations professionnelles :
    Activité : WANT

    Informations forums :
    Inscription : Juin 2011
    Messages : 45
    Points : 170
    Points
    170
    Par défaut
    Avons nous rééllement besoin de web assembly ?

    Le WebAssembly serait moins performant en terme de rapidité que le code natif, selon les résultats d'une étude
    50 % des sites web utilisent WebAssembly à des fins malveillantes, selon une étude de la Technische Universität Braunschweig

  3. #3
    Expert confirmé

    Homme Profil pro
    Développeur .NET
    Inscrit en
    Novembre 2010
    Messages
    2 065
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Novembre 2010
    Messages : 2 065
    Points : 4 229
    Points
    4 229
    Par défaut
    Citation Envoyé par Bardotj Voir le message
    Avons nous rééllement besoin de web assembly ?

    Le WebAssembly serait moins performant en terme de rapidité que le code natif, selon les résultats d'une étude
    50 % des sites web utilisent WebAssembly à des fins malveillantes, selon une étude de la Technische Universität Braunschweig
    Le WebAssembly est plus performant que le javascript qui est utilisé avec Electron pour faire des applis bureau.
    Des virus sont fait en C ou C++, doit-on bannir ces langages pour autant.

    Pour les perfs on utilise un paquet de langage moins performant que le natif pour faire des applis de bureau, à part si le but est d'avoir l'appli la plus performante (style jeux AAA, montage photo/video ...).

  4. #4
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 552
    Points : 15 463
    Points
    15 463
    Par défaut
    Citation Envoyé par Bardotj Voir le message
    Avons nous rééllement besoin de web assembly ?
    Avons nous besoin d'un ordinateur ? Pour survivre, non. Pour programmer, oui.
    Avons nous besoin de WebAssembly ? Pour programmer, non. Pour avoir un bytecode efficace, securisé et adapté a de multiple langages, oui.

    Citation Envoyé par Bardotj Voir le message
    Le WebAssembly serait moins performant en terme de rapidité que le code natif, selon les résultats d'une étude
    Pas besoin de faire une étude pour savoir ça. WebAssembly est un bytecode adapté pour avoir de bonnes performances, particulièrement avec les langages stricts, mais il a des contraintes de sécurité qui font qu'il ne pourra pas à 100% au niveau du natif non sécurisé. Mais par rapport au JS les gains sont indéniables.
    Il faut aussi voir que les VM des navigateurs privilégient actuelement la vitesse de compilation aux performances. C'est logique pour le web où on ne veut pas attendre au chargement de la page. Mais pour une utilisation en tant qu'application lourde comme le prévoit la Bytecode Alliance, les performances seront certainement privilégiées.

    Citation Envoyé par Bardotj Voir le message
    50 % des sites web utilisent WebAssembly à des fins malveillantes, selon une étude de la Technische Universität Braunschweig
    Pour des choses qui seraient de toute façon faites en JavaScript si le WebAssembly n'existait.

  5. #5
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Mars 2013
    Messages
    8 383
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Mars 2013
    Messages : 8 383
    Points : 196 422
    Points
    196 422
    Par défaut Microsoft, Google et ARM viennent grossir les rangs de la Bytecode Alliance
    Microsoft, Google et ARM viennent grossir les rangs de la Bytecode Alliance
    pour faire avancer WebAssembly au-delà du navigateur

    Fin 2019, dans un effort commun visant à faire de WebAssembly un runtime informatique multiplateforme, les entreprises Mozilla, Fastly, Intel et Red Hat ont annoncé le lancement de la Bytecode Alliance. Cette initiative architecturée autour de WebAssembly est axée sur la fourniture d’un bytecode sécurisé par défaut qui peut être exécuté depuis un navigateur Web, un ordinateur de bureau ou une plateforme IoT/embarquée.

    Pour rappel, WebAssembly a été présenté comme une architecture de jeu d’instructions virtuel avec de nombreux cas d’utilisation capable de prendre du code écrit dans des langages de programmation autres que JavaScript et d’exécuter ce code sur une plateforme spécifique – du moins à l’origine -, un navigateur en l’occurrence. Cette solution devrait également permettre aux applications complexes – telles que les jeux vidéo immersifs en 3D, le design informatisé ou l’édition d’images et de vidéos – de fonctionner de façon optimale sur les plateformes cibles. Grâce à WebAssembly, des développeurs seraient par exemple en mesure de coder leurs applications en C, C++ ou en Rust et de faire exécuter ces programmes à la vitesse native sur un navigateur Web, sans avoir à repasser par JavaScript avec les contraintes que cela impose.

    Selon les promoteurs l’initiative, la montée en puissance du Cloud et des périphériques IdO fait que les développeurs exécutent du code non fiable dans de nouveaux environnements, ce qui soulève de nouveaux problèmes, notamment en matière de sécurité et de portabilité. La Bytecode Alliance devra fournir une base permettant aux développeurs d’exécuter en toute confiance du code non fiable sur n’importe quelle infrastructure, système d’exploitation et périphérique. Cette communauté open source se focalisera sur la mise en place d’un environnement d’exécution et de chaînes d’outils linguistiques associées – incluant cargo-wasi, wat et wasmparser – qui offrent sécurité, efficacité et modularité sur une large gamme d’architectures et de périphériques. Le projet devrait s’appuyer sur les normes existantes telles que WebAssembly et WebAssembly System Interface (WASI).

    Nom : byte.png
Affichages : 14384
Taille : 45,6 Ko

    De nouveaux arrivants

    De nouveaux noms ont rejoint l'Alliance. Outre Microsoft, les nouveaux membres sont: Arm, DFINITY Foundation, Embark Studios, Google, Shopify et University of California San Diego.

    Dans une déclaration, Bobby Holley, ingénieur distingué chez Mozilla et membre du conseil d'administration de Bytecode Alliance, a décrit le développement logiciel aujourd'hui comme un ensemble de compromis difficiles. « Si vous voulez construire quelque chose de grand, il n’est pas réaliste de créer chaque composant à partir de zéro », a déclaré Holley. « Mais le fait de s'appuyer sur une chaîne d'approvisionnement complexe de composants provenant d'autres parties permet à un défaut n'importe où dans cette chaîne de compromettre la sécurité et la stabilité de l'ensemble du programme. Mozilla a aidé à créer WebAssembly pour permettre au Web de se développer au-delà de JavaScript et d'exécuter plus de types de logiciels à des vitesses plus rapides. Mais au fil de sa maturation, il est devenu clair que les propriétés techniques de WebAssembly – en particulier l'isolation de la mémoire – avaient également le potentiel de transformer le développement logiciel au-delà du navigateur. Plusieurs autres organisations partageaient ce point de vue et nous nous sommes réunis pour lancer la Bytecode Alliance en tant que partenariat industriel informel à la fin de 2019 ».

    « Des outils comme les conteneurs peuvent fournir un certain degré d'isolation, mais ils ajoutent des frais généraux substantiels et sont peu pratiques à utiliser avec la granularité par fournisseur. Et toutes ces dynamiques renforcent les avantages des grandes entreprises qui disposent des ressources nécessaires pour gérer et auditer soigneusement leurs chaînes d'approvisionnement ».

    La Bytecode Alliance considère WebAssembly comme un moyen de rendre le code composable, sûr et rapide sans sacrifices. Dans un communiqué, elle a déclaré :

    « Ces organisations partagent la vision d’un écosystème WebAssembly qui corrige les fissures dans les fondations logicielles d’aujourd’hui qui empêchent l’industrie et ses chaînes d’approvisionnement logicielles d'aller vers un avenir sécurisé, performant, multiplateforme et multiappareil. Les membres de la Bytecode Alliance estiment qu'une collaboration multipartite efficace est essentielle pour réaliser cette vision des fondations logicielles qui permettent à la sécurité, à l'efficacité et à la modularité de coexister sur la plus large gamme de dispositifs et d'architectures.

    « La Bytecode Alliance, fondée en 2019, a contribué à attirer l'attention sur les faiblesses inhérentes aux modèles prédominants de création de logiciels, qui reposent fortement sur la composition de milliers de modules tiers sans frontières de sécurité entre eux. Ces faiblesses dans la chaîne d'approvisionnement des logiciels ont historiquement été déterminantes pour violer les systèmes gouvernementaux, les services d'infrastructure critiques et un grand nombre d'entreprises, ainsi que pour voler les informations personnelles de centaines de millions, voire de milliards de personnes. La résolution de ces défis exigera des efforts dans de nombreuses industries. Avec un modèle de gouvernance ouvert et une liste croissante d'organisations membres, la Bytecode Alliance intensifiera ses efforts pour apporter des solutions à cet espace à l'appui de sa mission.

    « Les organisations passionnées par la contribution à cette mission et la construction de nouvelles fondations plus sûres pour le cloud, la périphérie, l'Internet des objets et de nombreux autres environnements et plateformes sont invitées à postuler pour devenir membres. Les demandes d'adhésion seront examinées sur une base continue, mais celles soumises dans un proche avenir auront la possibilité de participer aux élections du conseil d'administration au second semestre 2021 ».

    Les membres fondateurs ont partagé un tas d'outils WASM avec Bytecode Alliance, y compris des environnements d'exécution, des composants d'exécution et autres.

    Maintenant avec Microsoft, Google et Mozilla à bord, la Bytecode Alliance bénéficie du soutien de trois des quatre principaux fournisseurs de navigateurs. L'éditeur de Safari Apple est le seul fournisseur majeur de navigateurs qui est absent. Avec un soutien plus large, l'alliance se donne une meilleure chance de survie à long terme.

    « WebAssembly et la nouvelle spécification WebAssembly System Interface (WASI) permettent aux solutions cloud natives de devenir plus sécurisées par défaut et aident à résoudre les problèmes informatiques dans une variété d'environnements », a déclaré Ralph Squillace, directeur principal du programme Microsoft d'Azure Core Upstream et membre du conseil d'administration de Bytecode Alliance.

    WASI est une interface système pour WebAssembly qui permet au code en dehors d'un navigateur de communiquer avec plusieurs systèmes d'exploitation.

    Le travail de Microsoft sur WebAssembly inclut sa sortie de Blazor WebAssembly, qui permet aux développeurs C# et .NET de créer des applications qui s'exécutent dans le navigateur avec WebAssembly, mais fonctionnent comme une application de bureau native, également appelée Progressive Web Apps.

    Blazor WebAssembly est l'une des quatre versions du projet Blazor de Microsoft, qui comprend le rendu Blazor Server pris en charge pour les applications Web, un moteur de rendu Electron et les liaisons expérimentales Mobile Blazor récemment publiées pour la création d'applications iOS et Android natives en utilisant C# et .NET au lieu de JavaScript. .

    Sources : Bytecode Alliance, Mozilla

    Voir aussi :

    Wasmer : un runtime open source pour l'exécution de WebAssembly sur un serveur, tout en prenant en charge l'API Wasm-C
    Node.js 14 est disponible avec un support expérimental de WebAssembly System Interface (WASI), la fonctionnalité "rapport de diagnostic" est maintenant stable
    Zig 0.6.0 est disponible, le langage de programmation polyvalent prend en charge LLVM 10, WebAssembly, Windows et bien d'autres
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  6. #6
    Membre extrêmement actif
    Avatar de Madmac
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2004
    Messages
    1 685
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Alimentation

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 685
    Points : 1 376
    Points
    1 376
    Billets dans le blog
    7
    Par défaut Activex II
    Maintenant même Linux pourra compter des Bitcoins sans votre autorisation. Super!

    Ils pourraient obtenir les mêmes avantages en imitant le modèle des JARs de Java. Mais non, ils ont besoin de nouvelles failles de sécurité si les gens abandonnent Intel en masse.

  7. #7
    Invité
    Invité(e)
    Par défaut
    Le point faible du web, c'est JavaScript. Or avec WebAssembly, il n'est à ma connaissance pas possible d'interagir avec le navigateur sans passer par un bout de code JavaScript.

  8. #8
    Membre à l'essai
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Novembre 2017
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Novembre 2017
    Messages : 7
    Points : 21
    Points
    21
    Par défaut
    C'est assez déprimant quand tu tombes sur un article cool, sur une technologie cool qui a un potentiel assez énorme, et qu'en dessous, il y a deux commentaires archi négatifs et ce sans justifications valables...

    Il faut savoir que Java et .NET, qui sont les deux grosses références en terme d'exécution au travers de bytecode, n'ont jamais réussi à fédérer plus de communautés que la leur.
    Avec WASM, on peut dire qu'il y a eu un engouement certain de la part d'à peu près toute les communautés, y compris chez ces deux compères (la liste des projets de compilation vers WASM).

    Déjà à la base le projet est assez génial puisque qu'il permet à n'importe quel langage de pouvoir rivaliser avec JavaScript et sa fullstack.
    Les aficionado du C++ pourront donc utiliser leur langage de prédilection pour exécuter du code côté client.
    Du coup, même ceux qui haïssent JavaScript, devraient être content : ils n'ont plus besoin de l'utiliser pour monter une application web !

    Et maintenant, c'est encore mieux, puisque les enseignements appris chèrement avec l'évolution des usages du web, dont WASM hérite vont pouvoir déborder du web et en faire profiter le développement "natif".
    (En plus de pouvoir faire communiquer deux langages différents de manière plus simples et efficace et ce, peu importe la plateforme.

    Franchement, le potentiel est là et vu les efforts investis on peut espérer de belles choses à l'avenir !
    Enfin bref, ça vaut vraiment pas le coup de venir rager

  9. #9
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 552
    Points : 15 463
    Points
    15 463
    Par défaut
    Citation Envoyé par Jeff_67 Voir le message
    Le point faible du web, c'est JavaScript. Or avec WebAssembly, il n'est à ma connaissance pas possible d'interagir avec le navigateur sans passer par un bout de code JavaScript.
    Pour le moment juste une petite partie des API Web est disponible directement (principalement Canevas et webgl), mais a terme toute les API du navigateur devraient être accessibles sans passer par JavaScript. Le souci pour le moment c'est que la plupart des API comme le DOM utilisent des objets qui sont managé par le Garbage Collector du navigateur. Donc avant de les rendre disponible, il faut rendre WASM capable d'interagir avec le GC ce qui nécessite encore des travaux

  10. #10
    Membre émérite
    Profil pro
    retraité
    Inscrit en
    Décembre 2010
    Messages
    804
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : retraité

    Informations forums :
    Inscription : Décembre 2010
    Messages : 804
    Points : 2 299
    Points
    2 299
    Par défaut
    En gros c'est du "ByteCode" qui est exécuté. Par contre la vitesse native, non, ça ne pourra jamais aller aussi vite que des instructions assembleur. Sauf si bien sûr le byte code est retraduit en instruction assembleur avant .
    Je suppose que c'est cela qui est fait, du moins ce que je ferais moi, un code intermédiaire comme celui qui sort de LLVM, puis une traduction de cet assembleur universel vers l'assembleur de la cible.

    Par contre s'il y a GC on aura forcément des pertes par rapport à une application pure C/C++/Rust par exemple.

  11. #11
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Captain Spic Voir le message
    les enseignements appris chèrement avec l'évolution des usages du web, dont WASM hérite vont pouvoir déborder du web et en faire profiter le développement "natif".
    Quels enseignements par exemple ?
    J'ai plutôt l'impression que le web frontend a perdu du temps à refaire ce qui existait déjà dans le natif.

  12. #12
    Membre extrêmement actif
    Avatar de Madmac
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2004
    Messages
    1 685
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Alimentation

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 685
    Points : 1 376
    Points
    1 376
    Billets dans le blog
    7
    Par défaut
    Citation Envoyé par Captain Spic Voir le message
    C'est assez déprimant quand tu tombes sur un article cool, sur une technologie cool qui a un potentiel assez énorme, et qu'en dessous, il y a deux commentaires archi négatifs et ce sans justifications valables...

    Il faut savoir que Java et .NET, qui sont les deux grosses références en terme d'exécution au travers de bytecode, n'ont jamais réussi à fédérer plus de communautés que la leur.
    Avec WASM, on peut dire qu'il y a eu un engouement certain de la part d'à peu près toute les communautés, y compris chez ces deux compères (la liste des projets de compilation vers WASM).
    - Parce que le passé est garant de l'avenir. Si Microsoft est impliqué, tu peux est certain que cela va finir en eau de boudin. Microsoft est sectaire. Tu ne peux développer en .NET pour Linux parce que Microsoft interdit la reproduction du Interface graphique de NET. avec Mono. NET pourrait exister sous Mac et Linux, mais Microsoft refuse obstinément.

    - ActiveX offrait encore plus d'avantage,car il produisait du natif. Mais les utilisateurs se sont mit à refuser en masse, car la technologie était une énorme porte d'entrée pour les virus. Et en dépit du fait que Microsoft contrôlait à 100% le OS et ActiveX, Microsoft n'a jamais réussi à sécuriser cette technologie

    enfin

    Faire une véritable application coté client avec un truc comme JRuby ou JPython te permet des interface plus sophistiqué et plus sécuritaire. Et ne demande pas beaucoup plus d'effort quand on maîtrise déjà Ruby ou Python. Et en bonus, tu cache un maximum d'information sur le serveur. Difficile de faire une attaque lorsque l'on ignore l'adresse du serveur....

  13. #13
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 552
    Points : 15 463
    Points
    15 463
    Par défaut
    Citation Envoyé par archqt Voir le message
    En gros c'est du "ByteCode" qui est exécuté. Par contre la vitesse native, non, ça ne pourra jamais aller aussi vite que des instructions assembleur. Sauf si bien sûr le byte code est retraduit en instruction assembleur avant .
    Je suppose que c'est cela qui est fait, du moins ce que je ferais moi, un code intermédiaire comme celui qui sort de LLVM, puis une traduction de cet assembleur universel vers l'assembleur de la cible.

    Par contre s'il y a GC on aura forcément des pertes par rapport à une application pure C/C++/Rust par exemple.
    Justement, un gros avantage de WASM par rapport à JavaScript, c'est qu'il n'impose pas de notions de haut niveau comme un GC ou un typage dynamique. Un WASM produit à partir d'un langages de type C, C++ ou Rust peut donc théoriquement être compilé en quelque-chose de relativement similaire.
    Dans la pratique il y a quand même des écarts dus à certaines contraintes de sécurité, indispensables pour des code tiers téléchargés à la volée (protection contre les buffer overflow et les failles de type spectre notamment). De plus les compilateurs WASM, vont généralement, dans un premier temps, ne pas optimiser autant qu'ils le pourraient pour privilégier la vitesse de compilation et donc leur permettre de démarrer l’exécution quasi immédiatement, ce qui est généralement ce que l'on attend dans un contexte web. Seul les codes relativement couteux en temps d’exécution seront recompilés avec les meilleures optimisations.

    Le fonctionnement général du Wasm est en effet comparable au LLVM IR. Avec son projet pNaCL, Google souhaitait d'utiliser directement le LLVM IR comme bytecode, Mozilla de son coté, avec asm.js, proposait d'utiliser un sous-ensemble de JavaScript. Wasm est né de la mise en commun de leurs idées d'une manière plus propre, avec bytecode spécifiquement conçu pour être adapté aux contraintes du Web. Comparé à ces représentations intermédiaires, il est plus indépendant de la plateforme, plus compact a télécharger, plus rapide a compiler, plus sécurisé.


    Citation Envoyé par SimonDecoline Voir le message
    Quels enseignements par exemple ?
    J'ai plutôt l'impression que le web frontend a perdu du temps à refaire ce qui existait déjà dans le natif.
    En effet, mais dans le cadre d'une exécution dans le navigateur il y a des contraintes de portabilité et de sécurité qui sont ignorées par les développeurs natif, d'où la catastrophe ActiveX.
    Les Applets ont été la première tentative de résoudre le problème d'exécution dans le navigateur mais elle ont échoué pour des raisons à la fois techniques, et politiques. Techniquement, ça imposait une architecture trop contraignante, trop liée au langage Java lui même, pas assez orienté vers les performances. Politiquement, Java n'a jamais cherché a être une norme du web, c'est resté un produit appartenant à Sun, mal intégré. L'opposition a peine cachée de Microsoft n'a rien arrangé.
    Il y a eu d'autres tentatives, comme Flash, Active X, NaCL, asm.js,... qui péchaient toutes plus ou moins a différents niveaux : intégration, portabilité, sécurité, ... pour la simple et bonne raison que c'était des initiatives poussées par des acteurs externes qui fournissaient une solution taillée pour leur propres objectifs et pas le Web en général.

    Webassembly est vraiment une action commune des principaux acteurs du Web, bâtie sur l'expérience de ces projets et qui vise a traiter au mieux les besoin d'un bytecode du Web et qui a été penser pour traiter au mieux à la fois les problématiques de performance, de portabilité, de sécurité et d'intégration a l'écosystème Web.

  14. #14
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Uther Voir le message
    En effet, mais dans le cadre d'une exécution dans le navigateur il y a des contraintes de portabilité et de sécurité qui sont ignorées par les développeurs natif, d'où la catastrophe ActiveX.
    ...
    Webassembly est vraiment une action commune des principaux acteurs du Web, bâtie sur l'expérience de ces projets et qui vise a traiter au mieux les besoin d'un bytecode du Web et qui a été penser pour traiter au mieux à la fois les problématiques de performance, de portabilité, de sécurité et d'intégration a l'écosystème Web.
    Oui d'accord mais tout ça, ça reste spécifique au web/navigateur. Ma question était sur les "enseignements du web frontend qui vont faire profiter le dev natif".

  15. #15
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 552
    Points : 15 463
    Points
    15 463
    Par défaut
    Citation Envoyé par Madmac Voir le message
    - Parce que le passé est garant de l'avenir.
    C'est juste une jolie phrase taillée pour la philosophie de comptoir, mais dans la pratique sans aucun fondement. En réalité, le passé est rarement le garant de l'avenir, car les situations ne se représentent quasiment jamais deux fois a l'identique. C'est particulièrement vrai dans le cas qui nous concerne.

    Citation Envoyé par Madmac Voir le message
    Si Microsoft est impliqué, tu peux est certain que cela va finir en eau de boudin. Microsoft est sectaire.
    La situation actuelle de WASM n'a pas grand chose a voir avec l'époque de Active X dans le navigateur. Les technologies sont sensiblement différentes et surtout, Microsoft n'est pas maitre a bord, c'est juste un membre parmi d'autre. De plus et il n'a pas de position particulièrement dominante, sur le domaine visé par Wasi (serveur et IOT), il est même plutôt un outsider. Même au niveau du contrôle des techno Web, il s'est fait voler sa position par Google.

    Citation Envoyé par SimonDecoline Voir le message
    Oui d'accord mais tout ça, ça reste spécifique au web/navigateur. Ma question était sur les "enseignements du web frontend qui vont faire profiter le dev natif".
    En effet, sous cet angle là, l'intérêt est carrément discutable : le natif à déjà récupéré depuis longtemps ce qu'il avait à récupérer du front (xaml, styles,... ), il n'y a pas vraiment besoin de Wasm pour ça.
    L'interet de Wasm hors du web, c'est plutôt pour avoir un système de sandbox plus léger qu'avec la virtualisation ou un conteneur.

  16. #16
    Membre extrêmement actif
    Avatar de Madmac
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2004
    Messages
    1 685
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Alimentation

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 685
    Points : 1 376
    Points
    1 376
    Billets dans le blog
    7
    Par défaut
    Citation Envoyé par Uther Voir le message
    C'est juste une jolie phrase taillée pour la philosophie de comptoir, mais dans la pratique sans aucun fondement. En réalité, le passé est rarement le garant de l'avenir, car les situations ne se représentent quasiment jamais deux fois a l'identique. C'est particulièrement vrai dans le cas qui nous concerne.
    Pas du tout

    par exemple
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    begin
    File.open("./planets.ini").each { |planetname| planets_temp.append( planetname) }
    rescue SystemCallError => e
       print "Error: ./planets.ini missing, loading default values."
    end
    Ce code fonctionne sous Mac et Linux, mais pas sous Microsoft. Vois-tu voir pourquoi? Et leur foutu terminal qui ne comprend pas NCurses.


    Citation Envoyé par Uther Voir le message
    La situation actuelle de WASM n'a pas grand chose a voir avec l'époque de Active X dans le navigateur. Les technologies sont sensiblement différentes et surtout, Microsoft n'est pas maitre a bord, c'est juste un membre parmi d'autre. De plus et il n'a pas de position particulièrement dominante, sur le domaine visé par Wasi (serveur et IOT), il est même plutôt un outsider. Même au niveau du contrôle des techno Web, il s'est fait voler sa position par Google.
    La similarité est qu'ils vont pouvoir écrire autre chose que des cookies sur ton disque . Et cela représente un énorme problème. Et mème Microsoft n'est qu'un joueur parmi les autres, je n'ai qu'à penser à Explorer pour imaginer les milles et une façon d'empoisonner ce projet.

    Citation Envoyé par Uther Voir le message
    En effet, sous cet angle là, l'intérêt est carrément discutable : le natif à déjà récupéré depuis longtemps ce qu'il avait à récupérer du front (xaml, styles,... ), il n'y a pas vraiment besoin de Wasm pour ça.
    L'interet de Wasm hors du web, c'est plutôt pour avoir un système de sandbox plus léger qu'avec la virtualisation ou un conteneur.
    Là j'ai du mal à te suivre. Pour le moment Wasm se limite à Javascript. Alors un navigateur suffit. Et coté serveur Node te permet tester ton code.

  17. #17
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 552
    Points : 15 463
    Points
    15 463
    Par défaut
    Citation Envoyé par Madmac Voir le message
    Ce code fonctionne sous Mac et Linux, mais pas sous Microsoft. Vois-tu voir pourquoi? Et leur foutu terminal qui ne comprend pas NCurses.
    C'est un peu hors sujet, là. Mais si tu veux dire que, tous les outils ne sont pas toujours 100% multi plateformes, en effet c'est vrai, et Microsoft et loin d'être le seul coupable dans le domaine. Le fait qu'ils collaborent à WebAssembly et WASI, qui sont des technologies qui visent justement à améliorer l'interopérabilité, c'est justement plutôt un bonne nouvelle.
    L'époque ou Microsoft essayait d’écraser de son poids les efforts de standardisation est révolue depuis longtemps. Même s'ils le voulaient ils ne sont plus en position de force pour le faire.

    Citation Envoyé par Madmac Voir le message
    La similarité est qu'ils vont pouvoir écrire autre chose que des cookies sur ton disque . Et cela représente un énorme problème. Et mème Microsoft n'est qu'un joueur parmi les autres, je n'ai qu'à penser à Explorer pour imaginer les milles et une façon d'empoisonner ce projet.
    ...
    Là j'ai du mal à te suivre. Pour le moment Wasm se limite à Javascript. Alors un navigateur suffit. Et coté serveur Node te permet tester ton code.
    Je pense que tu as mal compris ce que sont WebAssembly et WASI.
    WASM est un bytecode générique qui peut théoriquement être produit a partir de n'importe quel langage, avec des performance potentiellement proche du natif.

    Le premier usage historique de WebAssembly est, comme son nom l'indique, dans le cadre du navigateur Web. Pour cet usage, il n'aura accès qu'aux API Web existantes et rien de plus. Donc il n'apporte aucune nouvelle possibilité technique au navigateur par rapport JavaScript. Il permettra juste d'être plus performant et d'utiliser d'autres langages de manière plus propre.

    Le but de la Bytecode alliance, dont parle l'article, est de développer WASI, une API qui permettra l'usage du Bytecode WebAssembly sans navigateur. Le but premier est de pouvoir mettre en place un système de sandbox pour des environnement de type serveur, plutôt qu'un système de conteneur ou de virtualisation. Mais dans ce cas là, malgré son nom, WebAssembly n'a plus aucun lien avec le navigateur. WASI sera une API adaptée aux besoin d'un ordinateur complet qui sera utilisable dans des machines virtuelles dédiés. Elle ne sera jamais intégrée aux navigateurs.

    La seule chose en commun entre une appli WebAssembly sur navigateur et une appli WASI, c'est le format du bytecode.

  18. #18
    Membre extrêmement actif
    Avatar de Madmac
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2004
    Messages
    1 685
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Alimentation

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 685
    Points : 1 376
    Points
    1 376
    Billets dans le blog
    7
    Par défaut
    Citation Envoyé par Uther Voir le message
    C'est un peu hors sujet, là. Mais si tu veux dire que, tous les outils ne sont pas toujours 100% multi plateformes, en effet c'est vrai, et Microsoft et loin d'être le seul coupable dans le domaine. Le fait qu'ils collaborent à WebAssembly et WASI, qui sont des technologies qui visent justement à améliorer l'interopérabilité, c'est justement plutôt un bonne nouvelle.
    L'époque ou Microsoft essayait d’écraser de son poids les efforts de standardisation est révolue depuis longtemps. Même s'ils le voulaient ils ne sont plus en position de force pour le faire.
    .
    J'ai pas cet impression Windows 10 a bloqué l'utilisation de GUI comme QT et autre GUI qui était horizontalement compatible. La situation a changer pour eux. Mais pas la culture d'entreprise.

    Citation Envoyé par Uther Voir le message
    Je pense que tu as mal compris ce que sont WebAssembly et WASI.
    .
    Non je connais très bien les base du concept et les avantages, j'ai même fait un compilateur utilisant des opcodes. Ce n'est pas un nouveau concept, c'est le recyclage du modèle de USCD Pascal: http://pascal.hansotten.com/ucsd-p-system/ . Cela existait à l'époque du Commode64 et de l'AppleII! Et le langage Crystal utilise un modèle semblable. J'imagine que si cela ce concrétise ce sera le premier langage à offrir la compilation.

    Mais j'ai l'impression que cette ligne a échapper à ton attention:

    La Bytecode Alliance devra fournir une base permettant aux développeurs d’exécuter en toute confiance du code non fiable sur n’importe quelle infrastructure, système d’exploitation et périphérique. Cette communauté open source se focalisera sur la mise en place d’un environnement d’exécution et de chaînes d’outils linguistiques associées – incluant cargo-wasi, wat et wasmparser – qui offrent sécurité, efficacité et modularité sur une large gamme d’architectures et de périphériques. Le projet devrait s’appuyer sur les normes existantes telles que WebAssembly et WebAssembly System Interface (WASI)
    Donc l'exécution du code peut avoir lieu à l'extérieur d'un navigateur! Cela va beaucoup plus loin que les JAR de Java. Il y a plus de bac à sable! À moins qu'il n'existe pas de fonction permettant l'écriture sur le disque, cela va être un énorme problème de sécurité.

  19. #19
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 552
    Points : 15 463
    Points
    15 463
    Par défaut
    J'ai très bien lu, mais si tu sembles savoir ce qu'est un bytecode, je confirme que tu n'as visiblement pas bien saisi pas la portée de WASI.

    C'est pas seulement que l’exécution du code pourra avoir lieu en dehors du navigateur, mais quelle le devra. WASI ne sera jamais implémenté dans les navigateurs. Elle ne sera accessible qu'à des VM exécutées comme des applications standalone, à la manière qu'une application Java, Python, ...

  20. #20
    Membre extrêmement actif
    Avatar de Madmac
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2004
    Messages
    1 685
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Alimentation

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 685
    Points : 1 376
    Points
    1 376
    Billets dans le blog
    7
    Par défaut
    Citation Envoyé par Uther Voir le message
    J'ai très bien lu, mais si tu sembles savoir ce qu'est un bytecode, je confirme que tu n'as visiblement pas bien saisi pas la portée de WASI.

    C'est pas seulement que l’exécution du code pourra avoir lieu en dehors du navigateur, mais quelle le devra. WASI ne sera jamais implémenté dans les navigateurs. Elle ne sera accessible qu'à des VM exécutées comme des applications standalone, à la manière qu'une application Java, Python, ...
    Ok, là je comprend. Je vois pas vraiment l'intérêt de faire à distance ce que peut-être fait sur son propre ordinateur. J'imaginais quelque chose comme les JARS de Java. Je ne crois pas que cela va révolutionner le monde de l’informatique.

Discussions similaires

  1. [REd Hat]Script ne se lance pas par Crontab
    Par lg022 dans le forum Administration système
    Réponses: 5
    Dernier message: 29/01/2014, 13h08
  2. Red Hat lance une version preview de sa distribution OpenStack
    Par tarikbenmerar dans le forum Actualités
    Réponses: 0
    Dernier message: 14/08/2012, 13h53
  3. RED HAT : impossible de déasctiver une interface
    Par ducho dans le forum Réseau
    Réponses: 2
    Dernier message: 25/10/2007, 11h36
  4. [REDHAT] Installation red hat 9.2
    Par hirochirak dans le forum RedHat / CentOS / Fedora
    Réponses: 8
    Dernier message: 19/03/2004, 13h10
  5. [Kylix] pb installation kylix 3 / Red Hat 8
    Par ms91fr dans le forum EDI
    Réponses: 1
    Dernier message: 11/12/2002, 02h28

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo