Il y a aussi la possibilité de faire des vérifications sémantiques au niveau du bytecode. Si tu veux permettre à tes utilisateurs d'exécuter du code arbitraire venant de distributeurs tiers que tu ne contrôles pas, c'est quand même assez rassurant (même si ça ne suffit pas complètement), tu peux au moins préserver l'intégrité du système.
Le choix d'Apple c'est de prendre comme brique de base un langage non-sûr et donc difficile à sécuriser, et de mettre un rideau de fer entre les développeurs et l'utilisateur, en mettant en place un point centralisé de contrôle et de validation du code. Comme ça en plus des problématiques de sécurité ils peuvent forcer une consistence de l'interface, mais aussi éliminer des concurrents gênants et se laisser le monopole sur certaines applications. C'est gagnant pour eux et, il faut l'avouer, confortable pour l'utilisateur... tant qu'il n'essaie pas trop d'être indépendant, mais Apple sait se trouver un public de gens qui privilégient leur confort (comment ne pas écrire petit bourgeois en continuation naturelle de ma phrase ? ;)
Tant pis pour les développeurs qui veulent un peu de flexibilité, pour les applications qui veulent encourager le partage de code entre utilisateurs, les gens qui veulent apprendre à programmer et montrer leur appli à leurs amis sans payer la taxe... C'est un autre compromis, mais à choisir Java et un mobile qui chauffe ça ne me semble pas si mal.
On pourrait avoir le beurre et l'argent du beurre avec des outils de vérification statique sur des langages plus bas-niveau que Java, un bon sandboxing par défaut (par exemple NaCL et autres projets de LLVM aseptisé), et des modèles de sécurité robustes mais flexibles pour gérer le transfert de droit dans un contexte moins restrictif -- ce que permettraient la sécurité par capabilities par exemple, comme poussé par certains au sein de Googlet et ailleurs.
[^] # Re: pour moi
Posté par gasche . En réponse au journal Votre langage idéal ?. Évalué à 6.
Il y a aussi la possibilité de faire des vérifications sémantiques au niveau du bytecode. Si tu veux permettre à tes utilisateurs d'exécuter du code arbitraire venant de distributeurs tiers que tu ne contrôles pas, c'est quand même assez rassurant (même si ça ne suffit pas complètement), tu peux au moins préserver l'intégrité du système.
Le choix d'Apple c'est de prendre comme brique de base un langage non-sûr et donc difficile à sécuriser, et de mettre un rideau de fer entre les développeurs et l'utilisateur, en mettant en place un point centralisé de contrôle et de validation du code. Comme ça en plus des problématiques de sécurité ils peuvent forcer une consistence de l'interface, mais aussi éliminer des concurrents gênants et se laisser le monopole sur certaines applications. C'est gagnant pour eux et, il faut l'avouer, confortable pour l'utilisateur... tant qu'il n'essaie pas trop d'être indépendant, mais Apple sait se trouver un public de gens qui privilégient leur confort (comment ne pas écrire petit bourgeois en continuation naturelle de ma phrase ? ;)
Tant pis pour les développeurs qui veulent un peu de flexibilité, pour les applications qui veulent encourager le partage de code entre utilisateurs, les gens qui veulent apprendre à programmer et montrer leur appli à leurs amis sans payer la taxe... C'est un autre compromis, mais à choisir Java et un mobile qui chauffe ça ne me semble pas si mal.
On pourrait avoir le beurre et l'argent du beurre avec des outils de vérification statique sur des langages plus bas-niveau que Java, un bon sandboxing par défaut (par exemple NaCL et autres projets de LLVM aseptisé), et des modèles de sécurité robustes mais flexibles pour gérer le transfert de droit dans un contexte moins restrictif -- ce que permettraient la sécurité par capabilities par exemple, comme poussé par certains au sein de Googlet et ailleurs.