Oui mais sachant qu'on parle d'un type d'erreur indépendant du programme en cours d'éxécution avec une probabilité de se produire constante au cours du temps.
Et, sachant qu'en plus les conséquences peuvent être identiques (plantage de la machine ou résultat innatendu mais indétectable) et cela que l'erreur se produise lorsque l'OS a la main ou lorsque c'est un programme utilisateur.
Bien entendu que la probabilité qu'une erreur se produise dans le programme qui a le plus souvent la main est plus grande et justement c'est la toute la problématique, car la question que je posais est une comparaison entre programme à service rendu équivalent : un programme éxécuté dans une VM recquierant plus de cycles qu'un programme natif, sa probabilité d'erreur augmente, est-ce que le jeu en vaut la chandelle ?
Le principe des VM étant, techniquement, plus sensible aux erreurs que le natif, pourquoi lorsque cela est possible, préférer un développement sur VM plutôt qu'en natif ?
Si la réponse est la portabilité multi-plateforme, on entre dans une logique de coût.
Si la réponse est la facilité de développement qu'offre ces environnement, on entre dans une logique de coût à nouveau.
Si la réponse est la pédagogie, on sort du champs d'actions des applications destinée utilisateur final.
Est-ce que la logique de coût est une motivation essentielle dans le libre ?
Est-ce que la logique de coût est prépondérante sur la sécurité ? (ouais, certes je connais hélàs la réponse...)
[^] # Re: Techniquement, pourquoi Mono
Posté par Badeu . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
Et, sachant qu'en plus les conséquences peuvent être identiques (plantage de la machine ou résultat innatendu mais indétectable) et cela que l'erreur se produise lorsque l'OS a la main ou lorsque c'est un programme utilisateur.
Bien entendu que la probabilité qu'une erreur se produise dans le programme qui a le plus souvent la main est plus grande et justement c'est la toute la problématique, car la question que je posais est une comparaison entre programme à service rendu équivalent : un programme éxécuté dans une VM recquierant plus de cycles qu'un programme natif, sa probabilité d'erreur augmente, est-ce que le jeu en vaut la chandelle ?
Le principe des VM étant, techniquement, plus sensible aux erreurs que le natif, pourquoi lorsque cela est possible, préférer un développement sur VM plutôt qu'en natif ?
Si la réponse est la portabilité multi-plateforme, on entre dans une logique de coût.
Si la réponse est la facilité de développement qu'offre ces environnement, on entre dans une logique de coût à nouveau.
Si la réponse est la pédagogie, on sort du champs d'actions des applications destinée utilisateur final.
Est-ce que la logique de coût est une motivation essentielle dans le libre ?
Est-ce que la logique de coût est prépondérante sur la sécurité ? (ouais, certes je connais hélàs la réponse...)