Non, c'est pire que ca, tu embarque le kernel de maniere caché dans ton programme sois disant nostub, enfin tu ne vois meme pas le kernel ni le fichier nostub, la totalité des lib dépendantes (et ce meme si elles sont deja isntallé dans ta TI) et le kernel est automatiquement installé et supprimé a l'execution/fin d'execution du container, et ce meme si un kernel est deja installé, et j'en passe.

Arvi89: le veritable probleme des container, à pars le fait qu'il sont une déduplication de l'OS deja installé (et demande des options que je refuse de mettre dans mon kernel car elle sont pour moi des problèmes de sécurité potentiels) c'est qu'ils sont la pour cacher la dette technique existante et surtout le fait que les technologies utilisé sont tous sauf au point, exemple: RubyOnRail.
Je ne connais pas assez Ruby en tant que language donc je ne peux pas juger de sa qualitée. Par contre j'ai assez d'experience opur savoir a quel point c'est la merde et que chaque mise a jour du language casse les version precedentes et demander de passer des heures/jours pour reparer une simple MaJ et refaire marcher un pauvre service web dépendant de Ruby, voir je n'ai jamais reussi a (re)faire marcher le service en question.

Les container on été créé en partit a cause de ca, plutôt que résoudre les problèmes on en cree un nouveau.

Sans compter qu'on a aucun veritable control sur ce qui est dans le container sous peine de le rendre non fonctionel. Si le fait qu'il utilise telle version de la lib X, ou que le service Y ne te conviens pas et est incompatible avec le service Z que tu utilise ailleurs en dehors de ce container, tu peux rien faire.

Bref, encore un truc que beaucoup de gents crient haut et fort que c'est super génial, et qui va rester dans les anales de l'informatique comme une des pires fausses bonnes idées, mais il va falloir des années pour que les gens comprennent..