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.
D'ailleur on est sur LinuxFR, et F-Spot, Tomboy, GnomeDo, Banshee & co ont été codés avec mono uniquement à cause de la compatibilité avec .NET, tous ces logiciels tournant outofthebox sous Windows et n'ayant aucune dépendance à Gnome.
un petit bout de cython
C'est pas du Python, c'est un autre langage, même si la syntaxe est la même. Pérénité sur le long terme inconnue, portabilité limitée.
fait du cython et le probleme est "presque reglé".
Avec généricité & co ? Et tous les avantages que procurent le typage statique aux outils de développement (y'a pas que le compilateur : IDE, refactoring & co) ?
je ne pense pas que le passage de l'etape de "compilation/check des types" soit une securité.
c'est une sécurité. Certainement pas suffisante, mais ca en est une.
Les tests unitaires en sont une autre, les 2 sont complémentaires et l'un ne remplace sûrement pas l'autre.
Pour LINQ, c'est encore subjectif, mais en pratique c'est quelque chose qui se reecrit en python pur en peu de temps grace au generateurs et autres.
Tu comprends pas. LINQ, c'est de combiner tous les avantages d'un langage de requêtage comme SQL avec les avantages d'un langage typé statiquement.
En C# si j'écris :
var artists = from album in database.GetAlbums()
where album.Name.StartWith("The")
orderby album.Name
select album.Artist;
foreach(var artist in artists)
Console.WriteLine(artist.toto); //erreur, la propriété toto n'existe pas !
le compilateur fait de l'inférence de type et ma variable ids est une suite d'objets du même type que Artist. Le typage est conservé et si je manipule cette liste, le compilateur peut me renvoyer une belle erreur à la compilation, et pas durant l'exécution d'un hypothétique test unitaire.
De plus ca permet à mon IDE de me proposer instantanément la liste des propriétés de mon objet artist quand je tapes "artist.".
T'auras beau reproduire l'API en Python, comme tu peux le faire en C# ou Java d'ailleur, tu n'auras pas l'intérêt principal qui est l'intégration dans le système de typage.
ce n'est pas explicite et c'est trop magique
Quand t'as la complétion, c'est explicite. LINQ est intégralement codé en méthode d'extensions et tout le monde est content de pouvoir utiliser LINQ sur ses listes d'objets traditionnelles.
par contre c'est faisable en ruby, en python
Là encore, les méthodes d'extensions permettent avant tout de conserver le typage statique, ce qui n'est pas le cas en Ruby ou en Python.
cela existe aussi en python
Non, le service peut être rendu à l'aide d'autres outils ou langages comme cython ou JNI, mais ce n'est pas proposé par Python.
Ce qui fait la force de C#, c'est son côté tout terrain, qui fait qu'il n'est sûrement pas le meilleur dans un domaine, mais cela en fait souvent un bon compromis.
[^] # 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.
[^] # 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é à 1.
[^] # Re: Drôle
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
C'est pas du Python, c'est un autre langage, même si la syntaxe est la même. Pérénité sur le long terme inconnue, portabilité limitée.
fait du cython et le probleme est "presque reglé".
Avec généricité & co ? Et tous les avantages que procurent le typage statique aux outils de développement (y'a pas que le compilateur : IDE, refactoring & co) ?
je ne pense pas que le passage de l'etape de "compilation/check des types" soit une securité.
c'est une sécurité. Certainement pas suffisante, mais ca en est une.
Les tests unitaires en sont une autre, les 2 sont complémentaires et l'un ne remplace sûrement pas l'autre.
Pour LINQ, c'est encore subjectif, mais en pratique c'est quelque chose qui se reecrit en python pur en peu de temps grace au generateurs et autres.
Tu comprends pas. LINQ, c'est de combiner tous les avantages d'un langage de requêtage comme SQL avec les avantages d'un langage typé statiquement.
En C# si j'écris :
var artists = from album in database.GetAlbums()
where album.Name.StartWith("The")
orderby album.Name
select album.Artist;
foreach(var artist in artists)
Console.WriteLine(artist.toto); //erreur, la propriété toto n'existe pas !
le compilateur fait de l'inférence de type et ma variable ids est une suite d'objets du même type que Artist. Le typage est conservé et si je manipule cette liste, le compilateur peut me renvoyer une belle erreur à la compilation, et pas durant l'exécution d'un hypothétique test unitaire.
De plus ca permet à mon IDE de me proposer instantanément la liste des propriétés de mon objet artist quand je tapes "artist.".
T'auras beau reproduire l'API en Python, comme tu peux le faire en C# ou Java d'ailleur, tu n'auras pas l'intérêt principal qui est l'intégration dans le système de typage.
ce n'est pas explicite et c'est trop magique
Quand t'as la complétion, c'est explicite. LINQ est intégralement codé en méthode d'extensions et tout le monde est content de pouvoir utiliser LINQ sur ses listes d'objets traditionnelles.
par contre c'est faisable en ruby, en python
Là encore, les méthodes d'extensions permettent avant tout de conserver le typage statique, ce qui n'est pas le cas en Ruby ou en Python.
cela existe aussi en python
Non, le service peut être rendu à l'aide d'autres outils ou langages comme cython ou JNI, mais ce n'est pas proposé par Python.
Ce qui fait la force de C#, c'est son côté tout terrain, qui fait qu'il n'est sûrement pas le meilleur dans un domaine, mais cela en fait souvent un bon compromis.