qu'elles ne devraient jamais arriver,
D'où leur nom : exception :)
Adobe comme Sun passent leur temps à corriger des problèmes de sécurité sur leurs VM, on a gagné quoi exactement ?
Une nette amélioration par rapport aux ActiveX :)
et il y a, de fait, diverses possibilités d'interopérabilités.
Et à peu prêt autant d'impossibilité.
Je te parle d'interopérabilité outofthebox, de langages qui définissent et échange de la même manière leurs classes pour les rendre utilisables directement.
Quand je code en C# je dois pas me coltiner de bindings pour exposer mes classes aux développeurs VB.NET IronPython, Boo, C++/CLI. Ca marche, point. Une réelle interopérabilité.
Serait il possible qu'un attaquant, a partir de son code "non sur" arrive a phagocyter le code dis "sur" ?
Non, c'est "by design" qu'une VM comme Java ou .NET empêche celà.
C'est "by design" que du code natif laisse faire tout et n'importe quoi.
C'est pas pour rien qu'un OS est obligé pour contourner le problème de s'appuyer sur les rings matériels offerts par le processeur pour cloisonner les processus et donc gérer les droits utilisateurs.
Bref, l'os, étant une base commune, risque de concentrer plus de monde compétent, du fait qu'il touche plus de monde.
L'OS contient surtout une quantité hallucinante de code tournant dans un même espace mémoire. Une VM a un code extrêmement réduit, et la gestion de sécu, là où passe tout le code utilisateur et donc est la seule "véritable" faille de la VM, est une partie insignifiante de ce que représente tout le joli monde que l'on trouve dans le kernel.
De l'autre coté, la VM n'a pas pour but primaire d'assurer la sécu, mais d'executer les classes.
Un des buts d'une VM est d'abstraire le code machine qui n'offre de base aucune sécurité, pour justement proposer un modèle de machine (VM) entièrement contrôlable par l'environnement d'exécution. Bref, by design encore une fois, une VM est conçu pour avoir une maîtrise complète du code exécuté.
Un OS n'a que vaguement la main à travers les appels systèmes et s'appui sur le hardware in fine.
Suffit de voir des projets de recherche sur les OS comme Singularity qui propose un modèle de sécurité entièrement logiciel, uniquement possible parcque s'appuyant sur une VM qui défini un jeu d'instruction entièrement contrôlable par l'OS. http://en.wikipedia.org/wiki/Singularity_%28operating_system(...)
La plus grosse faille de sécu de ces VM, c'est là où elle appel du code natif. En dehors du coeur (JIT et runtime en soit), la gros trou est au niveau des bindings vers des libs natives (IHM ou autre).
C'est là que la VM n'a plus la main sur le code exécuté, et c'est là que ca peut devenir dangereux.
ça, un paquet de langages compilé natif le font
Les langages qui font ca sont obligés d'insérer des métadonnées dans l'exécutable, bref de définir un modèle d'information de plus haut niveau, une VM. C'est ce que fait C++, c'est ce que fait n'importe quelle VM qui propose l'introspection.
Si tu parles uniquement de code natif pur, la seule introspection possible concerne par définition le jeu d'instruction du processeur.
Si tu veux plus d'information, tu introduis une abstraction virtuelle.
Tous les OSes et les langages, que je connnais, fournissent ça.
Tu vois très bien ce que je veux dire.
les protected de c++ en sont un des nombreux exemples)
\o/ J'espère que tu coderas jamais une application C++ qui expose des données sensibles à l'extérieur.
Comme si le mot clé protected t'offrais une quelconque sécurité. Tu prends un pointeur et tu vas te balader n'importe où dans ton objet, le mot clé n'est qu'une vision du compilateur, à l'exécution il n'y a aucun contrôle.
Je ne connais pas un seul langage mainstream qui ne fournit pas cette compatibilité.
Quand je te dis compatibilité, c'est la possibilité de définir des classes réutilisables sans se soucier du langage qui va l'utiliser.
La seule convention qui existe, c'est les API plates à la C.
2 compilos C++ sont même pas foutus de se mettre d'accord sur une compatibilité alors tu me fais bien rire avec cette compatibilité entre les langages.
Est-ce que je peux réutiliser en C mes classes C++ sans me coltiner un outil ou une couche de glue avec laquelle je vais devoir faire gaffe ? non.
Est ce que je peux réutiliser en C mes objets ObjectiveC ou Python sans me coltiner une couche intermédiaire ? non.
Est ce que je peux réutiliser mes objets C# en IronPython ou en VB.NET sans me soucier de la façon dont ca va se passer ? oui.
Ada fait abstraction des threads OSes et est pourtant compilé.
ADA propose au sein de son langage une abstraction des threads, il défini une VM.
La question n'est pas de savoir si c'est compilé ou non (c'est un faux débat puisqu'un programme C# peut être compilé en code natif).
La question est de savoir si le langage s'appui directement sur les instructions machines où s'il forme un sur-ensemble constituant une machine virtuelle et permettant de partir du postulat que des services supplémentaires sont offerts.
Pas beaucoups plus que pour une machine réelle, les phases d'optimisations sont très rarement réversibles
Non non et non.
Le bytecode .NET ou Java défini une VM avec la notion de classe, de méthode, de paramètres, d'héritage, de types énumérés, etc.
Quand tu décompiles, tu retrouves tout ça, optimisation ou pas.
En C, tu te retrouves avec un binaire et des instructions machines. Tout ce que tu obtiens à la décompilation, c'est des instructions assembleur. Tu perds toutes tes classes ou autre information de plus haut niveau.
Ca ne perturbe pas un programme bien écrit.
Bref, ca n'offre aucune garantie.
* int reste 32 bits, donc ça ne change pas.
jor. la norme ne défini strictement rien.
c'est que ta version 32 bits couvent un bug/crash, à corriger.
Non, juste que le langage C n'offre aucune garantie de comportement d'une implémentation à l'autre.
Sans parler du fait que tu es obligé d'avoir 2 binaires (voir n si tu as n architecture).
La seule garantie d'une VM c'est de libérer la mémoire à la fin, comme en C.
Non non et non. En C je peux très bien me balader n'importe où avec mes pointeurs dans mon espace mémoire et aller faire tout un tas de conneries qui vont influencer (négativement) l'exécution de mon programme et ajouter pleins de bugs.
je te laisse imaginer tous les problèmes de sécu potentiels, à commencer par les célèbres débordement de tampon. Y'a des techniques pour limiter la casse au niveau OS (comme c'est le cas dans le dernier noyau linux), mais il n'y a aucune garantie offerte.
Une VM garantie tous les accès mémoires, garantie qu'il y a bien un objet au bout et que tu es bien autorisé à y accéder.
Une VM peut gérer des droits d'exécution sur un code tiers au sein du même processus grâce à ce cloisonnement et cette maîtrise du bytecode exécuté, un programme en C peut faire à peu prêt tout et n'importe quoi dans son espace utilisateur. C'est pas pour rien que toutes les applets web utilisent un modèle de VM (Java flash, etc.)
Oui, j'ai jamais compris le truc génial de la gestion laissée à la VM, je suis sans doute vieux jeu.
Certains disent que la gestion mémoire est tellement importante qu'il faut mieux la laisser au développeur.
D'autres disent que la gestion mémoire est tellement importante qu'il faut mieux laisser ce travail à une machine.
Concernant les autre point comme le 64 bits, cela se règle par recompilation.
Je recompile et tout marche comme par magie. La taille des pointeurs et la taille d'un int qui change, ca perturbe aucun programme en C, c'est bien connu. Y'a aucune règle à respecter pour ne pas avoir de problème c'est bien connu.
Tu réponds pas à tout le reste :
- introspection
- sandboxing
- gestion des exceptions (le C++ doit intégrer un morceau de runtime pour ca)
- protection contre les débordements (on parle de garantie, une lib n'offre pas de garantie)
- gestion mémoire (on parle de garantie, pas de l'utilisation parfaite et sans erreur d'une lib)
- déployer une applet web (recompiler dans le navigateur n'est pas une option).
- proposer pleins de langages interopérables
bon OK pour ces derniers, les implémentations restent du domaine de l'expérimental
IronPython est stable depuis un moment et déployé par Microsoft dans les outils de dev de Silverlight en association avec le DLR.
mais souvent les justifications sont fumeuses
Ben c'est quand même pratique pour des plateformes comme iPhone qui interdisent de faire du JIT.
T'en gagnes une seule, t'es bien obligé de laisser un return à la fin en cas d'exception. Ca change pas fondamentalement la lourdeur de la syntaxe exigée par Java. Sans parler du fait qu'elle est souvent oubliée et/ou mal écrite.
Imagine si tu dois utiliser 2 ressources, l'imbrication de try catch qu'il faut faire sans se louper...
Faudrait peut être revoir ta définition du FUD.
Le FUD c'est discréditer un produit et/ou un concurrent en cherchant à semer le doute et la confusion chez l'interlocuteur en faisant des supposition invérifiables ou en prétant des intentions négatives sur des événements futurs.
Le FUD en l'occurence dans ce débat, c'est Stallman qui le pratique. http://fr.wikipedia.org/wiki/FUD
Sachant qu'une VM n'est qu'une abstraction et que le bytecode peut être pré-compilé en code natif avant exécution (sans JIT donc), ca fou pas un peu en l'air tout ton raisonnement ?
Sachant qu'à code natif exécuté identique, le bytecode équivalent est plus court, le fichier support est donc plus petit et prends moins d'espace disque, n'y a-t-il pas moins de risque d'erreur lors des entrées/sorties disques à la lecture du bytecode par rapport à un binaire qui contient la même chose en natif ?
Quel est le plus probable ? Un problème d'entrée/sortie disque ou un problème bas niveau au moment de l'exécution par le processeur ?
Sachant qu'on peut faire un processeur qui exécute directement du bytecode sans passer par une couche intermédiaire, l'avantage apparent du code natif ne peut-il pas être contourné ?
Quel est le plus probable : un bug dans l'application où dans le processus d'exécution sous-jacent ?
Partant de là, faut-il mieux fournir un environnement d'exécution sécurisé quitte à ajouter une couche supplémentaire ou faire du natif pour limiter les risques liées à l'exécution des instructions ?
Comme toujours, il faut prioriser les risques et voir lesquels sont les plus pertinents à limiter en premier.
Résultat, il est nécessaire d’appeler manuellement le destructeur des objets
Non. Tu as besoin de le faire uniquement quand tu veux libéré instantanément la ressource. Dans les 3/4 des cas tu n'as pas besoin de le faire, sans parler du fait que la grande majorité des objets .NET n''implémentent pas IDisposable parcqu'ils n'ont pas besoin de le faire.
MS n’a pas voulu appeler le destructeur des objets lorsque leur compte de référence tombe à 0 et le fait dans le garbage collector
En même temps c'est le garbage collector qui compte les références donc bon...
MS a fait le choix de faire s'exécuter le garbage collector à des moments propices (moment où la machine est moins sollicité ou à des moments critiques : besoin d'espace mémoire), c'est un choix différent de qui se fait dans d'autres VM par exemple mais c'est je trouve relativement pertinent puisque celà limite l'impact sur les performances de l'application.
il est exécuter dans le contexte du garbage collector, ce qui empêche par exemple la libération les domaines d’application
Non,c'est un autre problème le CLR n'autorise pas de libérer de domaines d'application tout court, un manque fonctionnel. D'ailleur .NET 4 évolue et propose cette fonctionnalité.
Enfin l'interface IDisposable est là pour libérer des ressources qui ne sont pas gérées par le garbage collector mais des ressources natives ou des fichiers par exemple : bref c'est loin d'être le cas général pour les objets .NET.
Et franchement c'est loin d'être "technique" et compliqué de faire un :
using(var file = File.OpenText("/home/machin/truc.txt"))
{
utilisation
} // appel automatique de IDisposable
Je trouve le développement en .Net extrêmement technique comparé au développement Java
Alors que le problème est identique en Java... Explique moi le plus simple, le moins technique :
C'est pas de la technique objective ça ? http://jeff.ecchi.ca/blog/?p=874
Absolument pas. Tomboy a beaucoup plus de plugins à charger au démarrage que GNote.
Toujours ce syndrôme de la nouvelle application de la mort qui va beaucoup plus vite mais qui a 3 fois moins de fonctionnalité.
Après je ne doute pas qu'il y est un écart en faveur de GNote, mais quand ils auront exactement les mêmes fonctionnalité, l'écart sera à mon avis moins important.
Donc tous les langages ont exactement les mêmes protections, sont pareillement audité sur les problèmes de sécu , etc... ?
C'est là qu'un modèle de VM comme .NET est intéressant : le runtime s'occupe du bytecode, la sécurité est gérée au niveau du bytecode. Tu peux concevoir ton langage comme une loutre avec un compilo foireux dans ton coin, tant que tu ponds du bytecode valide, ca sera pas moins sécure qu'un compilo C# rodé par Microsoft pendant 10 ans.
Je parles de sécurité au sens attaque malveillante & co, pas sécurité au sens je me bouffe une castexception par le runtime parcque mon langage bidon à un typage foireux.
quid de l'accés à la mémoire ?
Ben c'est un des fondements de ce type de VM : la mémoire est intégralement gérée par la VM, la VM a le contrôle total sur l'ensemble des accès mémoire.
le principe de base d'autoriser ou non du code, alors que ca appartient aux mêmes segments mémoire etc... me semble quand même passablement risqué.
Ca reste le seul modèle réellement mis en place pour faire tourner des applet : .NET, Java ou encore Flash. Parcque de base on va pas s'amuser à lancer un processus pour chaque composant flash de la page web !
repose sur des couches qui ont été moins audité, et donc peut être moins sur
Pas convaincu que le coeur du CLR .NET soit moins audité que le kernel Linux, proportionnellement à la surface de code exposée j'entend. Le kernel, c'est un gros bousin monolithique ou tout et n'importe quoi tourne avec les droits admin. C'est pas tout à fait la même quantité de code (et donc de code risqué) mis en oeuvre.
t'embarque chroot dans un activeX ?
Tu parlais de portabilité y'a quelques lignes non ?
Justement, je lancçais une boutade, mais la question reste valable, comment fais-tu pour proposer un environnement d'exécution sécure pour des applets web, ce qui reste à l'heure actuel la principal source de code à la provenance inconnue qui s'exécute sur ton ordinateur.
Voila ma confiance dans le code de mono.
Certes, j'ai à peu prêt le même niveau de confiance que toi. Pour faire tourner des applis Gnome ca me gène absolument pas, pour faire tourner des applets web (style moonlight) je suis tout de suite plus parano. Mais en même temps c'est à peu prêt le même niveau de confiance que j'accorde à Gnash par exemple pour faire tourner du flash.
perfs pas génial, et surtout si l'utilisateur se vautre dans son appel, ca peut faire exploser son application comme une loutre.
Bref, c'est pas du tout pareil :)
Se faire entendre ca par une techno poussé par une boite qui supporte pas posix ...
y dit qui voit pas le rapport.
En fait, ce que t'es en train de faire, c'est de refuser qu'on puisse faire avec une VM de manière portable ce que toi tu fais avec un OS et des outils bien spécifiques. Si un OS peut le faire, une VM peut le faire, y'a rien de crade à ça.
Imagine toi le monde réel :
je dois coder une application pour un site web qui demande un certain nombre de droits pour s'exécuter sur la machine : accès webcam et un peu d'espace disque.
Tu choisis quelle techno ? t'embarque chroot dans un activeX ? Non sérieusement...
tu les executent pas dans les mêmes processus, c'est un peu la base normalement...
Ben quand tu tournes dans un espace totalement contrôlé comme un environnement d'exécution .NET ou Java, tu peux revoir tes bases et te dire qu'on peut se passer de la lourdeur des processus. Non parcque niveau perf, j'espère que tes plugins doivent pas trop fonctionner ensemble...
Attaque de la personne plutôt que de ses propos. Ca montre juste que t'es à court d'argument.
C'est pour ça que PBPG ne pourra jamais critiquer fondamentalement son employeur.
N'importe quoi. S'il ne le fait pas, c'est qu'il est engagé juridiquement par un contrat qui le lit à son employeur. Et c'est ce qui lui interdit de dénigrer son employeur. Essai tu vas voir, c'est autrement plus concrêt et vérifiable que la Dissonance cognitive.
Mais on s'en fout.
On s'en fou pas. Ca montre que techniquement il est autant acceptable d'utiliser une VM dans un cas comme dans l'autre.
De toute façon ces langages se basent sur des services offerts par une VM.
C'est quoi une VM pour toi ?
C'est une définition d'un jeu d'instruction définissant une machine qui n'existe pas physiquement mais qui n'est qu'une vue pour le développeur. C'est ce que propose le bytecode java, .NET ou les compilos comme GCC à travers leurs langages intermédiaires.
Cela dis il reste cette énorme lourdeur de traduction à la volé des instructions intermédiaires.
Cette énorme lourdeur ?
hem.
mono --aot program.exe
hop j'obtiens un exécutable en code natif que je peux exécuter, plus d'exécution du bytecode, magique non ?
C'est pas pour rien que mono est utilisable sur iPhone pour les techniques de JIT ne sont pas autorisées.
Le bytecode .NET a été conçu dès le départ pour être compilé à la volée ou bien avant.
Et même lorsqu'on demande pas explictement de le faire, l'environnement maintient un cache pour ne pas faire le JIT à chaque exécution.
On en est loin dans le cas de Perl, ou de python.
Jython, IronPython, tu connais ? La limite est vraiment devenu très flou...
Les PInvoke permettent de définir statiquement la signature d'une fonction native. Ca suppose un minimum de support dans le langage natif : métadonnées (pour préciser l'alignement et autres subtilité des structures C), pointeurs. C'est aussi toute l'infrastructure qu'il y a derrière pour réaliser concrètement l'appel.
Bref encore une fois ca apporte le côté typage (déclaration statique) que Python n'offre pas.
Dans ce cas ca veut dire que tu exécute un code dans un conteneur, non/faiblement audité avec des droits extrêmement étendu par rapport à ce que fait le code.
Tout à fait.
C'est le principe de fonctionnement des VM comme Java ou .NET, c'est pas pour rien qu'on parle de runtime : le code est entièrement contrôlé par l'environnement d'exécution, ce dernier a donc la possibilité de gérer ce que le code a le droit de faire ou non, et de manière beaucoup plus fine que l'OS (granularité jusqu'à la méthode).
Même chose si tu lance ton applet avec ou les bonnes règles selinux et/ou setuid=nobody
C'est gentil mais c'est pas portable.
Et puis je veux pouvoir le faire au niveau de mon application où je gère des plugins tierce-partie qui tourne dans le même processus que mon application.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
D'où leur nom : exception :)
Adobe comme Sun passent leur temps à corriger des problèmes de sécurité sur leurs VM, on a gagné quoi exactement ?
Une nette amélioration par rapport aux ActiveX :)
et il y a, de fait, diverses possibilités d'interopérabilités.
Et à peu prêt autant d'impossibilité.
Je te parle d'interopérabilité outofthebox, de langages qui définissent et échange de la même manière leurs classes pour les rendre utilisables directement.
Quand je code en C# je dois pas me coltiner de bindings pour exposer mes classes aux développeurs VB.NET IronPython, Boo, C++/CLI. Ca marche, point. Une réelle interopérabilité.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Non, c'est "by design" qu'une VM comme Java ou .NET empêche celà.
C'est "by design" que du code natif laisse faire tout et n'importe quoi.
C'est pas pour rien qu'un OS est obligé pour contourner le problème de s'appuyer sur les rings matériels offerts par le processeur pour cloisonner les processus et donc gérer les droits utilisateurs.
Bref, l'os, étant une base commune, risque de concentrer plus de monde compétent, du fait qu'il touche plus de monde.
L'OS contient surtout une quantité hallucinante de code tournant dans un même espace mémoire. Une VM a un code extrêmement réduit, et la gestion de sécu, là où passe tout le code utilisateur et donc est la seule "véritable" faille de la VM, est une partie insignifiante de ce que représente tout le joli monde que l'on trouve dans le kernel.
De l'autre coté, la VM n'a pas pour but primaire d'assurer la sécu, mais d'executer les classes.
Un des buts d'une VM est d'abstraire le code machine qui n'offre de base aucune sécurité, pour justement proposer un modèle de machine (VM) entièrement contrôlable par l'environnement d'exécution. Bref, by design encore une fois, une VM est conçu pour avoir une maîtrise complète du code exécuté.
Un OS n'a que vaguement la main à travers les appels systèmes et s'appui sur le hardware in fine.
Suffit de voir des projets de recherche sur les OS comme Singularity qui propose un modèle de sécurité entièrement logiciel, uniquement possible parcque s'appuyant sur une VM qui défini un jeu d'instruction entièrement contrôlable par l'OS.
http://en.wikipedia.org/wiki/Singularity_%28operating_system(...)
La plus grosse faille de sécu de ces VM, c'est là où elle appel du code natif. En dehors du coeur (JIT et runtime en soit), la gros trou est au niveau des bindings vers des libs natives (IHM ou autre).
C'est là que la VM n'a plus la main sur le code exécuté, et c'est là que ca peut devenir dangereux.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Les langages qui font ca sont obligés d'insérer des métadonnées dans l'exécutable, bref de définir un modèle d'information de plus haut niveau, une VM. C'est ce que fait C++, c'est ce que fait n'importe quelle VM qui propose l'introspection.
Si tu parles uniquement de code natif pur, la seule introspection possible concerne par définition le jeu d'instruction du processeur.
Si tu veux plus d'information, tu introduis une abstraction virtuelle.
Tous les OSes et les langages, que je connnais, fournissent ça.
Tu vois très bien ce que je veux dire.
les protected de c++ en sont un des nombreux exemples)
\o/ J'espère que tu coderas jamais une application C++ qui expose des données sensibles à l'extérieur.
Comme si le mot clé protected t'offrais une quelconque sécurité. Tu prends un pointeur et tu vas te balader n'importe où dans ton objet, le mot clé n'est qu'une vision du compilateur, à l'exécution il n'y a aucun contrôle.
Je ne connais pas un seul langage mainstream qui ne fournit pas cette compatibilité.
Quand je te dis compatibilité, c'est la possibilité de définir des classes réutilisables sans se soucier du langage qui va l'utiliser.
La seule convention qui existe, c'est les API plates à la C.
2 compilos C++ sont même pas foutus de se mettre d'accord sur une compatibilité alors tu me fais bien rire avec cette compatibilité entre les langages.
Est-ce que je peux réutiliser en C mes classes C++ sans me coltiner un outil ou une couche de glue avec laquelle je vais devoir faire gaffe ? non.
Est ce que je peux réutiliser en C mes objets ObjectiveC ou Python sans me coltiner une couche intermédiaire ? non.
Est ce que je peux réutiliser mes objets C# en IronPython ou en VB.NET sans me soucier de la façon dont ca va se passer ? oui.
Ada fait abstraction des threads OSes et est pourtant compilé.
ADA propose au sein de son langage une abstraction des threads, il défini une VM.
La question n'est pas de savoir si c'est compilé ou non (c'est un faux débat puisqu'un programme C# peut être compilé en code natif).
La question est de savoir si le langage s'appui directement sur les instructions machines où s'il forme un sur-ensemble constituant une machine virtuelle et permettant de partir du postulat que des services supplémentaires sont offerts.
Pas beaucoups plus que pour une machine réelle, les phases d'optimisations sont très rarement réversibles
Non non et non.
Le bytecode .NET ou Java défini une VM avec la notion de classe, de méthode, de paramètres, d'héritage, de types énumérés, etc.
Quand tu décompiles, tu retrouves tout ça, optimisation ou pas.
En C, tu te retrouves avec un binaire et des instructions machines. Tout ce que tu obtiens à la décompilation, c'est des instructions assembleur. Tu perds toutes tes classes ou autre information de plus haut niveau.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Bref, ca n'offre aucune garantie.
* int reste 32 bits, donc ça ne change pas.
jor. la norme ne défini strictement rien.
c'est que ta version 32 bits couvent un bug/crash, à corriger.
Non, juste que le langage C n'offre aucune garantie de comportement d'une implémentation à l'autre.
Sans parler du fait que tu es obligé d'avoir 2 binaires (voir n si tu as n architecture).
La seule garantie d'une VM c'est de libérer la mémoire à la fin, comme en C.
Non non et non. En C je peux très bien me balader n'importe où avec mes pointeurs dans mon espace mémoire et aller faire tout un tas de conneries qui vont influencer (négativement) l'exécution de mon programme et ajouter pleins de bugs.
je te laisse imaginer tous les problèmes de sécu potentiels, à commencer par les célèbres débordement de tampon. Y'a des techniques pour limiter la casse au niveau OS (comme c'est le cas dans le dernier noyau linux), mais il n'y a aucune garantie offerte.
Une VM garantie tous les accès mémoires, garantie qu'il y a bien un objet au bout et que tu es bien autorisé à y accéder.
Une VM peut gérer des droits d'exécution sur un code tiers au sein du même processus grâce à ce cloisonnement et cette maîtrise du bytecode exécuté, un programme en C peut faire à peu prêt tout et n'importe quoi dans son espace utilisateur. C'est pas pour rien que toutes les applets web utilisent un modèle de VM (Java flash, etc.)
Oui, j'ai jamais compris le truc génial de la gestion laissée à la VM, je suis sans doute vieux jeu.
Certains disent que la gestion mémoire est tellement importante qu'il faut mieux la laisser au développeur.
D'autres disent que la gestion mémoire est tellement importante qu'il faut mieux laisser ce travail à une machine.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
Je recompile et tout marche comme par magie. La taille des pointeurs et la taille d'un int qui change, ca perturbe aucun programme en C, c'est bien connu. Y'a aucune règle à respecter pour ne pas avoir de problème c'est bien connu.
Tu réponds pas à tout le reste :
- introspection
- sandboxing
- gestion des exceptions (le C++ doit intégrer un morceau de runtime pour ca)
- protection contre les débordements (on parle de garantie, une lib n'offre pas de garantie)
- gestion mémoire (on parle de garantie, pas de l'utilisation parfaite et sans erreur d'une lib)
- déployer une applet web (recompiler dans le navigateur n'est pas une option).
- proposer pleins de langages interopérables
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
IronPython est stable depuis un moment et déployé par Microsoft dans les outils de dev de Silverlight en association avec le DLR.
mais souvent les justifications sont fumeuses
Ben c'est quand même pratique pour des plateformes comme iPhone qui interdisent de faire du JIT.
[^] # Re: Un autre bonne raison de ne pas utiliser Mono
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
[^] # Re: Un autre bonne raison de ne pas utiliser Mono
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Imagine si tu dois utiliser 2 ressources, l'imbrication de try catch qu'il faut faire sans se louper...
[^] # Re: Un autre bonne raison de ne pas utiliser Mono
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
[^] # Re: Un autre bonne raison de ne pas utiliser Mono
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Le FUD c'est discréditer un produit et/ou un concurrent en cherchant à semer le doute et la confusion chez l'interlocuteur en faisant des supposition invérifiables ou en prétant des intentions négatives sur des événements futurs.
Le FUD en l'occurence dans ce débat, c'est Stallman qui le pratique.
http://fr.wikipedia.org/wiki/FUD
[^] # Re: Techniquement, pourquoi Mono
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
Sachant qu'à code natif exécuté identique, le bytecode équivalent est plus court, le fichier support est donc plus petit et prends moins d'espace disque, n'y a-t-il pas moins de risque d'erreur lors des entrées/sorties disques à la lecture du bytecode par rapport à un binaire qui contient la même chose en natif ?
Quel est le plus probable ? Un problème d'entrée/sortie disque ou un problème bas niveau au moment de l'exécution par le processeur ?
Sachant qu'on peut faire un processeur qui exécute directement du bytecode sans passer par une couche intermédiaire, l'avantage apparent du code natif ne peut-il pas être contourné ?
Quel est le plus probable : un bug dans l'application où dans le processus d'exécution sous-jacent ?
Partant de là, faut-il mieux fournir un environnement d'exécution sécurisé quitte à ajouter une couche supplémentaire ou faire du natif pour limiter les risques liées à l'exécution des instructions ?
Comme toujours, il faut prioriser les risques et voir lesquels sont les plus pertinents à limiter en premier.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
[^] # Re: Un autre bonne raison de ne pas utiliser Mono
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
Non. Tu as besoin de le faire uniquement quand tu veux libéré instantanément la ressource. Dans les 3/4 des cas tu n'as pas besoin de le faire, sans parler du fait que la grande majorité des objets .NET n''implémentent pas IDisposable parcqu'ils n'ont pas besoin de le faire.
MS n’a pas voulu appeler le destructeur des objets lorsque leur compte de référence tombe à 0 et le fait dans le garbage collector
En même temps c'est le garbage collector qui compte les références donc bon...
MS a fait le choix de faire s'exécuter le garbage collector à des moments propices (moment où la machine est moins sollicité ou à des moments critiques : besoin d'espace mémoire), c'est un choix différent de qui se fait dans d'autres VM par exemple mais c'est je trouve relativement pertinent puisque celà limite l'impact sur les performances de l'application.
il est exécuter dans le contexte du garbage collector, ce qui empêche par exemple la libération les domaines d’application
Non,c'est un autre problème le CLR n'autorise pas de libérer de domaines d'application tout court, un manque fonctionnel. D'ailleur .NET 4 évolue et propose cette fonctionnalité.
Enfin l'interface IDisposable est là pour libérer des ressources qui ne sont pas gérées par le garbage collector mais des ressources natives ou des fichiers par exemple : bref c'est loin d'être le cas général pour les objets .NET.
Et franchement c'est loin d'être "technique" et compliqué de faire un :
using(var file = File.OpenText("/home/machin/truc.txt"))
{
utilisation
} // appel automatique de IDisposable
Tu verras aussi qu'en C++/CLI le problème n'est pas présent, et pourtant c'est le même CLR "mal conçu" :
http://msdn.microsoft.com/fr-fr/library/ms177197.aspx
Je trouve le développement en .Net extrêmement technique comparé au développement Java
Alors que le problème est identique en Java... Explique moi le plus simple, le moins technique :
C++/CLI :
String^ ReadFirstLineFromFile( String^ path ) {
StreamReader r(path);
return r.ReadLine();
}
C# :
String ReadFirstLineFromFile( String path ) {
using ( StreamReader r = new StreamReader(path) ) {
return r.ReadLine();
}
}
Java :
String ReadFirstLineFromFile( String path ) {
StreamReader r = null;
String s = null;
try {
r = new StreamReader(path);
s = r.ReadLine();
} finally {
if ( r != null ) r.Dispose();
}
return s;
}
En Python, il me semble qu'il n'y a aucune garantie que le destructeur soit appelé quand l'interpréteur s'arrête, tu trouves ca mieux ?
En C++ tu trouves ca simple et pas technique ces méthodes virtuelles appelées dans un destructeur si on fait pas attention ?
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Absolument pas. Tomboy a beaucoup plus de plugins à charger au démarrage que GNote.
Toujours ce syndrôme de la nouvelle application de la mort qui va beaucoup plus vite mais qui a 3 fois moins de fonctionnalité.
Après je ne doute pas qu'il y est un écart en faveur de GNote, mais quand ils auront exactement les mêmes fonctionnalité, l'écart sera à mon avis moins important.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
C'est là qu'un modèle de VM comme .NET est intéressant : le runtime s'occupe du bytecode, la sécurité est gérée au niveau du bytecode. Tu peux concevoir ton langage comme une loutre avec un compilo foireux dans ton coin, tant que tu ponds du bytecode valide, ca sera pas moins sécure qu'un compilo C# rodé par Microsoft pendant 10 ans.
Je parles de sécurité au sens attaque malveillante & co, pas sécurité au sens je me bouffe une castexception par le runtime parcque mon langage bidon à un typage foireux.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Ben c'est un des fondements de ce type de VM : la mémoire est intégralement gérée par la VM, la VM a le contrôle total sur l'ensemble des accès mémoire.
le principe de base d'autoriser ou non du code, alors que ca appartient aux mêmes segments mémoire etc... me semble quand même passablement risqué.
Ca reste le seul modèle réellement mis en place pour faire tourner des applet : .NET, Java ou encore Flash. Parcque de base on va pas s'amuser à lancer un processus pour chaque composant flash de la page web !
repose sur des couches qui ont été moins audité, et donc peut être moins sur
Pas convaincu que le coeur du CLR .NET soit moins audité que le kernel Linux, proportionnellement à la surface de code exposée j'entend. Le kernel, c'est un gros bousin monolithique ou tout et n'importe quoi tourne avec les droits admin. C'est pas tout à fait la même quantité de code (et donc de code risqué) mis en oeuvre.
t'embarque chroot dans un activeX ?
Tu parlais de portabilité y'a quelques lignes non ?
Justement, je lancçais une boutade, mais la question reste valable, comment fais-tu pour proposer un environnement d'exécution sécure pour des applets web, ce qui reste à l'heure actuel la principal source de code à la provenance inconnue qui s'exécute sur ton ordinateur.
Voila ma confiance dans le code de mono.
Certes, j'ai à peu prêt le même niveau de confiance que toi. Pour faire tourner des applis Gnome ca me gène absolument pas, pour faire tourner des applets web (style moonlight) je suis tout de suite plus parano. Mais en même temps c'est à peu prêt le même niveau de confiance que j'accorde à Gnash par exemple pour faire tourner du flash.
[^] # Re: Drôle
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Bref, c'est pas du tout pareil :)
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
y dit qui voit pas le rapport.
En fait, ce que t'es en train de faire, c'est de refuser qu'on puisse faire avec une VM de manière portable ce que toi tu fais avec un OS et des outils bien spécifiques. Si un OS peut le faire, une VM peut le faire, y'a rien de crade à ça.
Imagine toi le monde réel :
je dois coder une application pour un site web qui demande un certain nombre de droits pour s'exécuter sur la machine : accès webcam et un peu d'espace disque.
Tu choisis quelle techno ? t'embarque chroot dans un activeX ? Non sérieusement...
tu les executent pas dans les mêmes processus, c'est un peu la base normalement...
Ben quand tu tournes dans un espace totalement contrôlé comme un environnement d'exécution .NET ou Java, tu peux revoir tes bases et te dire qu'on peut se passer de la lourdeur des processus. Non parcque niveau perf, j'espère que tes plugins doivent pas trop fonctionner ensemble...
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
C'est pour ça que PBPG ne pourra jamais critiquer fondamentalement son employeur.
N'importe quoi. S'il ne le fait pas, c'est qu'il est engagé juridiquement par un contrat qui le lit à son employeur. Et c'est ce qui lui interdit de dénigrer son employeur. Essai tu vas voir, c'est autrement plus concrêt et vérifiable que la Dissonance cognitive.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
On s'en fou pas. Ca montre que techniquement il est autant acceptable d'utiliser une VM dans un cas comme dans l'autre.
De toute façon ces langages se basent sur des services offerts par une VM.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
C'est une définition d'un jeu d'instruction définissant une machine qui n'existe pas physiquement mais qui n'est qu'une vue pour le développeur. C'est ce que propose le bytecode java, .NET ou les compilos comme GCC à travers leurs langages intermédiaires.
Cela dis il reste cette énorme lourdeur de traduction à la volé des instructions intermédiaires.
Cette énorme lourdeur ?
hem.
mono --aot program.exe
hop j'obtiens un exécutable en code natif que je peux exécuter, plus d'exécution du bytecode, magique non ?
C'est pas pour rien que mono est utilisable sur iPhone pour les techniques de JIT ne sont pas autorisées.
Le bytecode .NET a été conçu dès le départ pour être compilé à la volée ou bien avant.
Et même lorsqu'on demande pas explictement de le faire, l'environnement maintient un cache pour ne pas faire le JIT à chaque exécution.
On en est loin dans le cas de Perl, ou de python.
Jython, IronPython, tu connais ? La limite est vraiment devenu très flou...
[^] # Re: Drôle
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Bref encore une fois ca apporte le côté typage (déclaration statique) que Python n'offre pas.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
Tout à fait.
C'est le principe de fonctionnement des VM comme Java ou .NET, c'est pas pour rien qu'on parle de runtime : le code est entièrement contrôlé par l'environnement d'exécution, ce dernier a donc la possibilité de gérer ce que le code a le droit de faire ou non, et de manière beaucoup plus fine que l'OS (granularité jusqu'à la méthode).
Même chose si tu lance ton applet avec ou les bonnes règles selinux et/ou setuid=nobody
C'est gentil mais c'est pas portable.
Et puis je veux pouvoir le faire au niveau de mon application où je gère des plugins tierce-partie qui tourne dans le même processus que mon application.