Avec de vrai OS, tu ne recompiles/cherche pas tes applications
Ah bon ? Alors ça sert à rien les sources !
L'environnement cloisonne... La bonne blague, on a pas les sources des JVM.
D'abord on a les sources. Sur le site de sun il faut s'enregistrer, puis accepter pleins de licences, et ... paf, les sources des jvm (de sun)
Après tu pourrais vouloir les sources d'autres jvm: sablevm, kaffe, kawa (GNU), et j'en oublie. J'ai même lu qu'il y en avait certaines d'écrites (presque entièrement, seulement, bien sûr) en java.
Il y a de tres grandes chances que les plantages de ces JVM sur du bytecode ecrit a la main permette de faire de joli virus
Déjà, une JVM, par défaut, vérifie le bytecode, lorsqu'il est chargé. Elle est, si je ne me trompe, capable de vérifier qu'il ne charge pas d'autres .class comme ça, discret, sans prévenir, qu'il ne fait pas de "pointeurs" (au sens bytecode du terme) pour examiner l'ensemble de la mémoire de l'environnement Java, et il doit y avoir d'autres vérifications.
Ensuite, l'utilisateur peut facilement régler la sécurité. Ex: une applet ne peut pas écrire sur le disque, et une appli locale, elle, le pourra. Et si ça plante... la réponse est peut-être insatisfaisante, mais: c'est un bug ! Si on en fait quelque chose de méchant, c'est un exploit. (Mis à part le fait que cela me paraisse irréaliste) il y a des exploits pour des trucs qui ne sont pas du java, même pas des trucs exécutables. On a vu des exploits HTML pour IE, ou encore:
Il pourrait aussi y avoir un root exploit dans libjpeg, tant qu'à faire. Mais ce qu'il faut se dire, c'est que l'environnement Java est open source, et à vraiment été conçu de manière à éviter ces écueils, et est une autre réponse aux problème de l'isolation que la méthode utilisateurs/process/protection mémoire (qui a aussi des trous)
Et bien si tu ne veux pas que ton appli ce crasch en moins d'1s parce qu'elle a bouffe trop de memoire, faut appeler manuellement le garbagge collector !
Mauvaise réponse. Il faut rajouter de la mémoire à la machine, ou bien en faire consommer moins à l'application. Quand ton appli se fait killer par le système, car il y a plus de mémoire, tu n'as pas de <magie>Garbage Collector</magie> à appeler
Jette un coup d'oeil aux algos de garbagge collector, tu verras il y a des tas de cas foireux qui peuvent poser probleme et ou ta memoire ne sera jamais libere...
Moui, ben jette un coup d 'oeil aux bons algos de garbage collector, et tu verras que il y a pas de problèmes. Notamment avec des cycles. C'est sûr qu'avec des cycles énormes... ça peut devenir un petit peu moins efficace, mais ils n'arrivent que rarement dans de vrais programmes; à tout casser, il y a une 20aine d'indirection pour faire le cycle.
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par alnicodon . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 1.
Ah bon ? Alors ça sert à rien les sources !
D'abord on a les sources. Sur le site de sun il faut s'enregistrer, puis accepter pleins de licences, et ... paf, les sources des jvm (de sun)
Après tu pourrais vouloir les sources d'autres jvm: sablevm, kaffe, kawa (GNU), et j'en oublie. J'ai même lu qu'il y en avait certaines d'écrites (presque entièrement, seulement, bien sûr) en java.
Déjà, une JVM, par défaut, vérifie le bytecode, lorsqu'il est chargé. Elle est, si je ne me trompe, capable de vérifier qu'il ne charge pas d'autres .class comme ça, discret, sans prévenir, qu'il ne fait pas de "pointeurs" (au sens bytecode du terme) pour examiner l'ensemble de la mémoire de l'environnement Java, et il doit y avoir d'autres vérifications.
Ensuite, l'utilisateur peut facilement régler la sécurité. Ex: une applet ne peut pas écrire sur le disque, et une appli locale, elle, le pourra. Et si ça plante... la réponse est peut-être insatisfaisante, mais: c'est un bug ! Si on en fait quelque chose de méchant, c'est un exploit. (Mis à part le fait que cela me paraisse irréaliste) il y a des exploits pour des trucs qui ne sont pas du java, même pas des trucs exécutables. On a vu des exploits HTML pour IE, ou encore:
http://www.us-cert.gov/cas/techalerts/TA04-099A.html(...)
Il pourrait aussi y avoir un root exploit dans libjpeg, tant qu'à faire. Mais ce qu'il faut se dire, c'est que l'environnement Java est open source, et à vraiment été conçu de manière à éviter ces écueils, et est une autre réponse aux problème de l'isolation que la méthode utilisateurs/process/protection mémoire (qui a aussi des trous)
Mauvaise réponse. Il faut rajouter de la mémoire à la machine, ou bien en faire consommer moins à l'application. Quand ton appli se fait killer par le système, car il y a plus de mémoire, tu n'as pas de <magie>Garbage Collector</magie> à appeler
Moui, ben jette un coup d 'oeil aux bons algos de garbage collector, et tu verras que il y a pas de problèmes. Notamment avec des cycles. C'est sûr qu'avec des cycles énormes... ça peut devenir un petit peu moins efficace, mais ils n'arrivent que rarement dans de vrais programmes; à tout casser, il y a une 20aine d'indirection pour faire le cycle.
A+