• [^] # Re: et le mien

    Posté par . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 2.

    C'est pourquoi, pour la portabilite, je conseille les slim binaries: il s'agit en fait
    d'arbres de syntaxes abstraites compresses, qui portent plus d'information, et
    sont plus denses que du code binaire compile pour une machine virtuelle.

    Ils sont donc plus petits et permettent une compilation plus optimisee; par contre le temps de compilation est plus long, donc ca ne convient pas bien pour l'embarque.

    Et utiliser l'OS pour chrooter toutes les applis, si c'est une solution viable. Enfin pas dit comme ca. Sous Linux/BSD ce genre de concept n'est pas vraiment bien integre (enfin avec SELinux ca s'arrange un peu), mais ca n'a rien de complique,
    c'est fait depuis les annees 70 dans les capability machines, ou plus modernement dans OS.

    L'idee c'est que plutot que de donner aux applications le droit de tout faire par defaut (open environnement), on leur donne le droit de ne rien faire, et on leur ajoute des droits au coup par coup. Du coup si on raisonne comme ca, faire du sandboxing c'est trivial: il suffit de donner peu d'acces aux services de l'OS, plutot que d'interdire plus.

    Merci pour le remoting; je vois pas trop l'interet par rapport a CORBA. En C++ on peut tout aussi bien cacher le fait qu'un appel de methode se fasse a distance qu'en C# a mon avis.

    Donc je me maintiens: les virtual machines, ca sert a rien (sauf dans qq cas, comme l'embarque). D'ailleurs si Microsoft ne faisait pas windowsCE /windowsphone/ou autre vision sur l'embarque, ils n'auraient surement pas fait .NET comme ca je pense.