y dit qui voit pas le rapport.
Oh je sais pas, raler parce que une solution n'est pas interoperable, alors que la solution que tu propose est
1°) poussé par une boite essayant de tout faire pour lutter contre l'interopérabilité
2°) n'a absolument pas fait en sorte que leur système soit interopérable (c'est pas ms qui a codé une vm interoperable).
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.
Oula non.
1°) comme je l'ai dis : pour moi une vm n'apporte pas un "plus" de sécurité. Ca n'empeche pas de le faire, ni d'apporter une aide bienvenue dans l'administration (qui elle peut apporter un "plus" dans la sécurité, mais grace à l'administration).
2°) les arguments techniques interessant et que je ne connaissais ont été developpé (sécu sur la méthode ou sur le .jar/.class/.bidule), toutefois je trouve que même si ca apporte un plus par rapport à une application qui n'a pas ça, ca pose des problèmes
- quid de l'accés à la mémoire ? le suivi de la sécurité ? Comment ca a été audité ?
- 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é. C'est une question de risque, pas d'exploitation réelle là. Et puis je ne suis pas un expert, c'est pour ça que je dis "me semble" ;)
3°) repose sur des couches qui ont été moins audité, et donc peut être moins sur (bien entendu, cela dépend du code, de la portée , etc...)
Pour toute ces raisons je pense qu'il faut mieux revoir l'architecture d'un programme pour qu'il execute le code non sur dans des process ou autre séparé, plutot que de reposer aveuglement sur les protections apportées sur les VM.
t'embarque chroot dans un activeX ?
Tu parlais de portabilité y'a quelques lignes non ?
Ben quand tu tournes dans un espace totalement contrôlé comme un environnement d'exécution .NET ou Java
J'ai déjà lu le code mono. J'ai déjà trouvé des races conditions dedans.
Voila ma confiance dans le code de mono. Alors certes tu va me dire ca fait longtemps, et qu'un code comme ça a forcément des bugs, et que les races conditions sont très compliqué a débuggé (la preuve, pour corriger la deuxieme j'ai fait un gros hack immonde), mais désolé, cela a quand même entamé ma confiance dans mono, surtout sachant que c'est pas la plateforme officiel, donc sans doute moins audité.
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...
Ensuite faut savoir si tu veux faire de la sécurité, ou du developemment dans un délai X avec un objectif Y.
Les deux ne sont pas forcément possibles de façon optimale.
[^] # Re: Pourquoi Mono ?
Posté par briaeros007 . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Oh je sais pas, raler parce que une solution n'est pas interoperable, alors que la solution que tu propose est
1°) poussé par une boite essayant de tout faire pour lutter contre l'interopérabilité
2°) n'a absolument pas fait en sorte que leur système soit interopérable (c'est pas ms qui a codé une vm interoperable).
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.
Oula non.
1°) comme je l'ai dis : pour moi une vm n'apporte pas un "plus" de sécurité. Ca n'empeche pas de le faire, ni d'apporter une aide bienvenue dans l'administration (qui elle peut apporter un "plus" dans la sécurité, mais grace à l'administration).
2°) les arguments techniques interessant et que je ne connaissais ont été developpé (sécu sur la méthode ou sur le .jar/.class/.bidule), toutefois je trouve que même si ca apporte un plus par rapport à une application qui n'a pas ça, ca pose des problèmes
- quid de l'accés à la mémoire ? le suivi de la sécurité ? Comment ca a été audité ?
- 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é. C'est une question de risque, pas d'exploitation réelle là. Et puis je ne suis pas un expert, c'est pour ça que je dis "me semble" ;)
3°) repose sur des couches qui ont été moins audité, et donc peut être moins sur (bien entendu, cela dépend du code, de la portée , etc...)
Pour toute ces raisons je pense qu'il faut mieux revoir l'architecture d'un programme pour qu'il execute le code non sur dans des process ou autre séparé, plutot que de reposer aveuglement sur les protections apportées sur les VM.
t'embarque chroot dans un activeX ?
Tu parlais de portabilité y'a quelques lignes non ?
Ben quand tu tournes dans un espace totalement contrôlé comme un environnement d'exécution .NET ou Java
J'ai déjà lu le code mono. J'ai déjà trouvé des races conditions dedans.
Voila ma confiance dans le code de mono. Alors certes tu va me dire ca fait longtemps, et qu'un code comme ça a forcément des bugs, et que les races conditions sont très compliqué a débuggé (la preuve, pour corriger la deuxieme j'ai fait un gros hack immonde), mais désolé, cela a quand même entamé ma confiance dans mono, surtout sachant que c'est pas la plateforme officiel, donc sans doute moins audité.
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...
Ensuite faut savoir si tu veux faire de la sécurité, ou du developemment dans un délai X avec un objectif Y.
Les deux ne sont pas forcément possibles de façon optimale.