gasche a écrit 1151 commentaires

Je raisonne en terme de surface d'attaque et de capacité du code qui fait cette surface à nous donner confiance en l'absence de failles dans le futur (sur une certaine période de temps). Android et iOS ont une bonne compartementalisation, sans doute comparables à ce qu'un très bon administrateur peut faire avec les approches de Mandatory Access Control sur des machines Linux (SELinux bien configuré par exemple), mais leur surface d'attaque pour la décompartementalisation (la complexité du système qu'il suffit de pervertir pour échapper à son compartiment) reste très importante. Après je connais mal la structure de leurs kernels; je sais que Darwin est parti d'une architecture Mach, avec surface réduite, mais j'imagine que c'est un modèle hybride qui a beaucoup augmenté depuis.

En comparaison, QubesOS repose sur Xen, qui n'est pas parfait mais dont la surface est énormément plus petite. Pour la sécurité du code qui fait cette surface, j'ai l'impression que ça a longtemps été "pas mal mais sans plus", et que ça va en s'améliorant. Il y a des hyperviseurs plus sûrs, mais qui ne permettent pas de faire tourner un systèmes comme Qubes confortablement aujourd'hui.

(Il y a pas mal de données sur les plateformes existantes et leurs frais sur le wiki de Snowdrift.coop, voir en particulier leur liste de plateformes de dons réguliers.)

Je suis sensible à la question des frais prélevés par les plateformes de financement participatif. Les frais prélevés sont souvent bien supérieurs à ceux qu'on accepterait de payer comme frais bancaires par exemple. Si je choisis de faire confiance à un projet et lui donner mon argent, mais je ne fais pas forcément assez confiance à la plateforme pour lui donner une partie de cet argent.

Est-ce que vous pourriez, sur les pages où vous indiquez les différentes options pour vous soutenir, indiquer les frais de chacune de ces plateformes ? Je viens de regarder, cela semble être 5% pour Patreon et 8% pour Tipeee—Tipeee a fait disparaître la page lisible qui explique leurs frais et c'est assez douteux de leur part.

Avez-vous envisagé d'utiliser des plateformes avec moins de frais, comme Liberapay récemment présentée ici ?

Quand on fait un crowdfunding ponctuel, avoir une plateforme connue est important pour la visibilité. Pour du financement participatif sur le long terme, je pense que votre propre communication aura nettement plus d'impact que la (maigre) visibilité sur la plateforme, et en plus ça concerne un public plus impliqué pour qui le fait de "ne pas avoir besoin de s'inscrire à un nouveau truc" peut jouer moins. Enfin, vous recevez de l'argent tous les mois, donc si une plateforme plus petite/fragile coule dans deux ans, ce n'est pas un drame. Je ne vois pas de raison de ne pas multiplier les options.

Par ailleurs, un truc à garder en tête en regardant Cargo par exemple (ou la commande go), c'est que ça propose une expérience plus agréable en enlevant souvent des fonctionnalités. Par exemple, faire du préprocessing de sources Rust avec Cargo, c'est très difficile.

La communauté compense en mettant le plus de méta-programmation possible directement dans le langage, ce qui est une bonne chose pour certaines fonctionnalités (les macros propres, c'est utile et puissant, les tests unitaires bien intégrés, etc.) mais reste beaucoup moins flexible qu'un langage utilisant un outil de build "généraliste" (qui permet de rajouter des règles localement) comme Make ou ocamlbuild.

Par exemple, je ne crois pas qu'il y ait un générateur de parseur en Rust qui s'intègre bien avec le système de Build. lalrop recode la gestion des timestamps etc. de son côté, et copie les fichiers générés dans le répertoire de développement.

Ça va sûrement s'améliorer avec le temps, mais il faut aussi voir que l'approche monolithique a aussi des coûts qu'on ne voit pas forcément tout de suite.

Qu'est-ce qui empêcherait de reproduire cet effort pour y ajouter l'outil de build ? Le support financier de JaneStreet ? Un consensus technique ?

Ce n'est pas clair, pour moi, que l'outil de build soit la source du problème. En supposant par exemple que OASIS permette de faire parfaitement abstraction du build (ce qui est au moins vrai pour les programmes "simples" que peuvent écrire les débutants qui découvrent le langage), il te reste à faire au moins un _oasis, un opam et un .merlin pour te lancer dans ton projet, et sans doute (ce n'est pas forcément indispensable) un Makefile par-dessus tout ça.

Il y a des langages qui ont un système monolithique qui fait tout : l'installation des dépendances, la configuration, le build, la discussion avec les IDEs, le packaging, etc. Mais d'une part, ça fait un goulot d'étranglement sur le langage (plus difficile d'étudier des alternatives etc.), d'autre part en suivant le principe Unix on aurait envie de comprendre comment découper ce mastodonte en des outils plus simples et indépendants, qui collaborent de façon flexible mais sans ajouter trop de complexité. Mais quelles frontières tracer, comment partager les responsabilités ? Aujourd'hui on n'a sans doute pas trouvé les bons contours en OCaml, parce que le mélange ajoute trop de complexité.

Edward Yang, un membre actif de la communauté Haskell, s'est aussi intéressé à cette question dans son billet The convergence of compilers, build systems and package managers.

Je connais les gens qui ont conçus le MOOC et je serait content de leur faire un retour utile sur ce qui t'a posé problème, si tu ne l'as pas déjà fait par d'autres canaux. N'hésite pas à donner plus de détails en réponse ou à m'envoyer un mail si tu préfères (gasche dot dylc chez gmail).

Tout de même si un site déclare utiliser "Private Bin", il est relativement simple de vérifier que le code, correspond bien au code source de "Private Bin".

Non. Ce n'est pas simple du tout et tu as montré dans ton message seulement quelques des raisons pour lesquelles c'est très difficile.

Ensuite la sécurité est toujours une question relative,

L'important c'est de donner toutes les informations nécessaires pour comprendre précisément quelle est la sécurité apportée par l'outil, de quoi il protège et de quoi il ne protège pas, pour que chacun puisse prendre une décision informée en fonction de son usage et ses besoins.

Le site de PrivateBin le fait bien (je pense qu'un outil qui se dirait "sécurisé" mais saurait pas faire ce travail d'information ne serait sans doute pas digne de confiance), mais la dépêche introduit des approximations qui font passer de "simplifié mais juste" à "fausses garanties de sécurité", ce que je me permettais de signaler.

Pas plus que d'utiliser gcc ou clang avec un makefile et les autotools.

Je dirais que justement, c'est bien ça le problème.

Le fonctionnement du compilateur OCaml a été calqué sur celui des compilateurs C, donc des gens qui sont à l'aise avec C ne voient pas forcément le problème—mais la plupart des autres langages ont des outils plus agréables. Quand on est à l'aise avec autotools on n'est pas forcément représentatif de la population des développeurs et développeuses.

Des choses comme ça ont quand même été bien explorées : ocamlbuild se configure en OCaml (mais pas seulement) et apporte des concepts pour décrire le build, solvuu repose sur ocamlbuild mais la description de projet se fait totalement en OCaml, et omake est justement un outil de build avec son langage à part.

Tu parles de ocamlopt -build ..., mais ça suppose faire rentrer une notion de "build" complexe dans le compilateur, qui aujourd'hui ne fait que des builds simples, de supposer qu'il va distinguer ce qui a déjà été buildé et ce qu'il faut rebuilder, etc. C'est une possibilité, et ça pourrait simplifier beaucoup les choses (en limitant les "couches" différentes), mais pour l'instant les gens ont toujours voulu garder la séparation des responsabilités, et avoir un outil de build séparé du compilateur.

Merci pour ton journal (et désolé pour le plombage de moral dans la dépêche). Je ne connaissais pas starterkit, c'est un bon conseil à donner aux débutants, et sa doc est agréable pour se lancer aussi.

Pour répondre à ta question, moi je suis un vieux OCamleux donc j'ai grandi avec les choses d'avants et je me mets aux nouveaux trucs seulement petit à petit. En général pour un nouveau projet je me fais un .merlin et opam à la main (pro tip pour installer les dépendances d'un projet qui vient avec son opam local: opam pin leprojet . --no-action ; opam install --deps-only leprojet), et j'écris mon propre Makefile qui appelle OCamlbuild en dessus.

Les gens plus modernes commencent avec OASIS directement, et c'est un chouette outil, mais j'ai toujours un peu peur d'avoir à travers trois niveaux d'abstractions: make (pour diriger la fête, par habitude et convention), oasis derrière, et enfin ocamlbuild (ou omake pour les gens qui préfèrent).

Un truc dont je suis bien conscient et, je pense, tout le monde dans la communauté OCaml, c'est que ce n'est pas vraiment agréable comme expérience pour les débutants. Pour chaque besoin il y a trois outils différents, aucun qui ne fait vraiment le consensus (à part opam pour le package management), et des couches de trucs les uns par-dessus les autres. Tout le monde essaie d'améliorer ça et de rendre l'environnement plus agréable pour les nouveaux (et pour les autres aussi), mais ça demande un travail énorme, vraiment considérable, de progresser juste un peu là-dessus. On ne s'en rend pas forcément compte de l'extérieur mais, de base, créer des outils agréables c'est vraiment difficile, et en plus, créer des outils agréables et qui s'intègrent bien à l'existant que les habitués connaissent déjà, c'est encore plus dur.

(Je comprends les gens de Reason qui ont décidé de repartir de zéro au niveau de l'écosystème, même si je pense qu'un effort équivalent pour travailler avec les gens existants peut avoir au final plus d'impact.)

Je suis développeur aussi et je sais faire la différence entre "la question la plus importante du monde pour trois râleurs ou râleuses qui ne se remettent jamais en question" et "la communauté montre un intérêt fort pour un sujet mais la hiérarchie préfère mettre la tête dans le sable".

Le ticket avait 25 commentaires quand il a été fermé, il en accumulé plus de 100 supplémentaires pendant les quatre mois de silence de la part de Gitlab. Je t'invite à aller chercher sur le traqueur de tickets de Gitlab CE pour d'autres tickets qui auraient plus de 100 commentaires, il n'y en a quasiment jamais (un "très gros" ticket c'est 30, 50, 80 commentaires max), je n'en connais qu'un seul ("Issue Boards") qui soit plus gros, à 208 commentaires. On ne peut pas tout déduire d'un nombre de commentaire, mais c'est clair que cette question avait un intérêt fort pour une base d'utilisateurs importante, et que Gitlab en était conscient—et qu'ils avaient pourtant choisis de ne pas réagir ou répondre aux arguments qui étaient avancés.

Je suis d'accord sur le fait que critiquer les gens en public, quand ils font par ailleurs souvent du bon boulot, ce n'est pas agréable. C'était justement tout le but de mon commentaire initial que de montrer que c'est une technique désagréable, à utiliser avec une grande modération, mais qui peut parfois (malheureusement ?) être efficace aussi.

Alors est-ce vraiment 100% sécurisé ? Oui, et non. Comme expliqué sur la page d'accueil du projet, PrivateBin ne protège pas d'abus de la part des administrateur⋅ice⋅s gérant le service, qui pourraient − volontairement ou sous la menace − distribuer un bout de JavaScript exposant les clefs des documents auxquels vous accédez.

Il n'y a pas que les administrateurs à qui il faut faire confiance. Une attaque peut venir de n'importe qui dans la chaîne de communication entre le client et le serveur. Si on utilise HTTPS on est mieux protégé des "attaques au milieu", mais seulement "mieux" : on est protégé d'un attaquant avec peu de moyens, mais pas d'un attaquant puissant, par exemple un état (hélas les gens ayant intérêt à détruire la sécurité sont parfois des états). Des certificats HTTPS trafiqués ont été utilisés pour monter des attaques dans la vraie vie (c'est le problème de notre chaîne de confiance actuelle qui est assez fragile). Le site web le dit aussi clairement—il ne parle pas que des attaques au niveau du serveur.

Ça reste donc nettement moins sécurisé qu'une application dont le code client est bien stocké côté client—ou au moins authentifié côté client, mais donc dans tous les cas avec les mêmes problématiques de mise à jour intentionnelle, etc. que dans un logiciel client classique.

Merci. Il est en fait apparu indirectement dans la discussion, où Éloi Rivard a dit:

I am part of a very small company (actually, we are 2 people) and $40/user/year is not something we can afford. Our clients have averagely several accounts, so they can report bugs. It would quickly make the EE price expensive.

Cependant c'est plutôt un commentaire général sur le soucis de la mesure du nombre d'utilisateur (et le modèle de choix des prix des hébergeurs payants) qu'un argument spécifique à Pages, donc je n'ai pas jugé bon de développer spécifiquement sur ce ticket.

Je crois que c'est un peu plus subtil que ça.

D'une part, un des cas d'usages est une personne qui est sur Github.com ou sur Gitlab.com, qui utilise leur option Pages pour son blog perso, et qui décide de passer en auto-hébergé. Elle peut s'attendre à pouvoir conserver la même méthode—la disponibilité de cette méthode peut même influencer son choix de logiciel à auto-héberger.

Ensuite, il y a une ambiguité quand on dit "fait sens pour une organisation de 100 personnes", est-ce qu'on parle d'une instance de Gitlab avec 100 utilisateurs, ou alors d'organisations de gens travaillant ensemble de façon ciblée ? (Chez Github c'est clair, "organisation" c'est la personne morale 'foo' github.com/foo; chez Gitlab c'est moins clair, ils utilisent plutôt "Groupes" pour ce concept). Si les développeurs de Framasoft utilise un Gitlab perso pour gérer le code leurs projets, c'est très clairement une organisation (de moins de 100 personnes). Si on parle de Framagit, est-ce que c'est "une organisation" ? Je suis prêt à faire le choix le plus restrictif: j'imagine qu'ils pensent aux instances de plus de 100 utilisateurs¹.

Enfin, il y a plein de groupes de gens de par le monde qui font de l'auto-hébergement mutualisé : un groupe de gens qui se connaissent et qui se partagent les coûts et l'effort d'entretien d'un serveur web, éventuellement d'un serveur mail, etc. On est tous d'accord je pense sur le fait que c'est un excellent modèle. Ces groupes peuvent tout à fait avoir l'usage de Pages (cf. premier point: héberger les pages web d'un projet dans le Pages de la forge correspondante c'est naturel, serveur dynamique à côté ou pas), et font dans leur grande majorité moins de 100 personnes—j'appartiens moi-même à deux groupes différents d'une dizaine de personnes chacuns (mais aucun n'héberge d'instance gitlab). Et ce cas d'usage montre bien que l'intérêt de la feature ne dépend pas du tout du nombre d'utilisateurs de l'instance.

¹: Il y a un truc très pervers avec les modèles commerciaux des forges fondés sur le nombre d'utilisateurs, et que j'ai mis du temps à réaliser. Ça marche bien pour des structures qui ont des dépôts à l'équipe de développement fermée, ou carrément des dépôts privés. Mais ça ne marche pas du tout pour du développement coopératif libre, à moins d'implémenter la fédération d'instances. Je m'explique : si tu mets un projet disponible sur Gitlab (auto-hébergé ou gitlab.com ou gitlab.inria.fr), tu veux que les gens puissent t'envoyer des propositions de changements (pull/merge requests). Mais aujourd'hui pour envoyer une proposition de changement, il faut un compte sur l'instance de la personne. Du coup si tu as un projet qui a du succès sur une instance gitlab, tu n'as aucun contrôle sur le nombre d'utilisateurs qui vont s'inscrire dessus pour t'envoyer une petite contribution—et tu as envie que ce nombre soit grand. Si tu paies ton hébergement au nombre d'utilisateurs, ou de manière générale si les gens qui développent le logiciel catégorisent les instances en "nombre d'utilisateurs inscrits", ça ne colle pas du tout. Ça aurait du sens si tu avais de la fédération, si pouvais envoyer une proposition de changement d'une instance de Gitlab à une autre. Je pense maintenant qu'il est important d'implémenter ce genre de fonctionnalités. (Le mieux serait d'avoir un format qui marche avec toute forge git, par exemple en utilisant le format de git format-patch, que github par exemple sait très bien produire en sortie (github.com/foo/bar/pull/123.patch).)

Mon analyse de la situation est un peu différente. Je trouve assez difficile d'argumenter que Gitlab Pages n'a d'intérêt que pour les organisations de plus de 100 utilisateurs—puisque Github pages est utilisé par de nombreuses personnes de façon purement individuelle, et qu'au contraire les grosses organisations ont plus souvent des sites webs dédiés et non-statiques. N'importe quelle instance Gitlab, quelle que soit sa taille, bénéficie du fait d'avoir des pages statiques pour chaque utilisateur et pour chaque projet.

Je veux bien croire qu'au moment où cette décision a été prise, elle n'avait pas été beaucoup réfléchie (c'était juste un petit ticket). Mais je pense que la longue liste de personnes qui sont venues dire qu'elles en auraient l'usage à titre individuel aurait du rendre clair assez vite que la justification de départ était à revoir. Ça n'a pas été fait pendant quatre mois; juste après la fermeture du ticket, Drew a commenté

It's unfortunate that the decision doesn't seem to engage with the specific counterarguments.

C'était très vrai, et ça l'est resté pendant quatre mois. Aucun signe que les développeurs Gitlab, indépendamment de leur envie de changer ou pas de décision, reconnaissaient que la justification devait être approfondie. C'est ça, pour moi, l'immobilisme.

Étant frustré par l'immobilité de Gitlab sur cette discussion, j'avais adopté une technique dont je trouve l'efficacité assez frustrante voire agaçante : faire des reproches en public pour faire de la question non seulement une question de fond, mais aussi une question de réputation. Les gens qui sont sur Twitter font ça très bien, on entend beaucoup d'histoires de gens qui contactent un service client, aucun résultat probant, et qui se mettent à râler sur Twitter et là tout de suite on leur donne satisfaction. C'est triste, mais souvent le fait qu'on expose un problème à un endroit où il touche la réputation de l'autre permet de le résoudre beaucoup plus rapidement.

Concrètement, c'était un message Google Plus, dans la communauté Gitlab (donc visible par les gens auprès de qui Gitlab veut faire de la publicité : cette communauté fait partie de la stratégie de communication) pour râler sur l'absence totale de réponse de Gitlab sur l'issue. Quatre jour à près, une personne de Gitlab répondait qu'ils allaient y re-réfléchir. Je ne connais pas assez leur processus décisionnel pour dire que "c'est ça" qui a débloqué la situation, mais c'est clair que ça a joué—la personne le dit lui-même.

Il faut faire attention à ne pas trop utiliser cette technique, je pense. Quand on force des gens à réagir à quelque chose, ça peut être aux dépends d'un autre sujet sur lesquels ils travaillaient qui était aussi ou plus important. En plus ça nécessite forcément de rentrer un peu dans le lard (si on écrit une demande gentille et implicite, ça ne fait pas pression), et donc ce n'est pas une bonne manière d'entretenir des relations productives sur le long terme.

Je ressors de cette expérience (et d'autres un peu du même genre) avec un sentiment mitigé sur ce modèle d'"Open Core" où tout le monde danse d'un pied sur l'autre pour savoir ce qui va être libre et ce qui ne va pas l'être, et où on sent que parfois il y a une barrière à l'amélioration de la solution libre à cause de l'offre propriétaire qui l'accompagne. J'aime mieux les modèles par souscriptions, comme LWN.net.

C'est une bonne remarque, on en a déjà discuté dans un journal précédent et dans les commentaires ci-dessus, avec en particulier cette réponse éclairante.

J'observe les résultats: une partie des personnes qui ont lu ton journal ont fait un contresens, ils en ont compris quelque chose qui est assez éloigné de la réalité. Ça veut dire qu'il y a sans doute quelque chose de pas clair dans ta présentation.

Je trouve que le paragraphe

Pour lui, le ou les mainteneurs principaux sont chargés de la bonne application des règles établies par le groupe. Cela évite de chercher tout le temps le consensus. Si un patch respecte les règles il est accepté. Si non, il est refusé. On évite ainsi les discussions stériles.

est très bien (même si tu aurais pu creuser un peu sur la question de quelles sont ces "règles") mais, comme le précise kantien ci-dessus, j'imagine que la partie

Par conséquent, lorsqu'on réalise un projet communautaire, toute contribution est bonne à prendre. Il nous invite à donc à être laxiste sur les conditions d'acceptation d'un patch.

peut induire en erreur.

Après, ce n'est pas un drame. Mais quand quelqu'un me dit "j'ai lu le billet X et dedans il est expliqué que le mainteneur de ZeroMQ accepte tous les patchs, c'est radicalement à l'opposé de ce qu'on fait dans le projet GIMP", je suis bien obligé de dire que ce que la personne a compris de X ne correspond pas à la réalité. J'aurais pu dire "tu as mal compris X" au lieu de "X ne décrit pas bien la réalité", mais je pense que les torts sont, comme souvent, partagés.

https://github.com/linuxfrorg/linuxfr.org/pull/207

Je pense que non. Peu de projets utilisent des fonctionnalités non-standard de gcc. Par contre beaucoup de projets sont codés en langage C qui ne respecte pas vraiment les règles sémantiques imposées par le standard, et sont donc à la merci d'un changement d'avis du compilateur sur la façon de compiler telle ou telle entorse aux règles. Quand on passe d'un compilateur à l'autre (ou d'une version à une autre du même compilateur, parfois) on se retrouve avec des choses qui marchaient avant et qui échouent à la compilation, ou qui font n'importe quoi à l'exécution. Je pense que ce genre de problèmes de portabilité, lié à la fragilité du langage C, est majoritaire.

Ah, l'unicode et wc -c. Je me suis fait avoir.

On peut enlever cette limite arbitraire, non ? Si le but est de protéger du flood, on peut mettre une limite beaucoup plus haute (par exemple 2¹⁵ au lieu de 2^9). que les gens ne rencontre pas naturellement en écrivant un message.

P.S.: Merci pour cette réponse rapide et informative.

J'ai cherché à comprendre où cette limitation à 512 caractères était implémentée dans le code. Je n'ai pas trouvé pour l'instant, la seule chose qui s'en rapproche c'est une possible troncation à 500 caractères dans app/models/board.rb. Cette limitation a été implémentée par Bruno Michel en 2010 dans 127c5a799802c2c7c74666ac61bc795c6607b4ff, mais je ne comprends pas si c'est vraiment une troncation à 500 caractères (ça ne semble pas être le cas pour le message que j'ai vu, puisqu'il a gardé ses 512 premières caractères).

L'idée je crois c'est de réussir à formaliser l'attente sur les contributions, de façon à ce que la décision d'acceptation des patches devienne la plus mécanique possible, pour simplifier le travail du mainteneur—et aussi, passer mieux à l'échelle, et le rendre plus facilement remplaçable ou faisable en groupe. C'est assez intéressant, mais ça demande aussi beaucoup de travail de spécification/clarification et une très bonne connaissance du projet.

Il s'agit plutôt d'une méthodologie de travail du mainteneur que d'un choix sur l'axe entre exigence et permissivité. Je ne crois pas que Gimp (ou que les projets sur lesquels je travaille moi-même) aient adopté cette méthodologie pour l'instant—même si je me rends bien compte que j'ai bien des critères en tête que j'applique de façon relativement uniforme sur les petites contributions peu invasives.

Je me suis un peu renseigné sur la position du dev ZeroMQ sur ce sujet je pense qu'elle est beaucoup plus fine que le "laisser faire" dont tu parles—le journal ne lui rend pas vraiment justice sur ce point. Regarde le document Collective Code Construction Contract par exemple. L'idée globalement est que chaque projet devrait décider un ensemble de critères pour les patch proposés, qui puissent être jugés objectivement (par une personne qui connaît bien le code), et ensuite que le travail du mainteneur devrait se limiter à vérifier que les critères ont été appliqués, et si oui inclure le patch.

C'est vachement plus fin que "j'accepte si ça marche". Par exemple deux des règles proposées sont:

The user or Contributor should write the issue by describing the problem they face or observe.
The user or Contributor should seek consensus on the accuracy of their observation, and the value of solving the problem.

La sécurité des distributions Linux est cassée aujourd'hui, car la surface d'attaque est beaucoup trop importante à tous les niveaux, et parce que les applications ne sont pas conçues en respectant le principe de moindre autorité (Least Authority, Least Privilege). On utilise, en essence, des architectures obsolètes du point de vue de la sécurité. (Les mondes fermés de Windows et iOS essaient de faire un peu mieux.)

Qubes OS a le potential d'apporter beaucoup plus de sécurité, en changeant radicalement la donne par une nouvelle architecture logicielle beaucoup mieux compartimentée. La surface d'attaque de Qubes OS est bien moindre—essentiellement Xen et un peu de code spécifique. Aujourd'hui c'est le seul système d'exploitation libre et utilisable qui soit un peu sécurisé. (J'ai entendu parler de Subgraph OS mais pas encore regardé les détails, et FreeBSD fait de bons progrès du point de vue de Capsicum au fil des releases.)

Bien sûr Qubes OS n'apporte qu'une sécurité de compartementalisation entre les composants: chaque AppVM derrière est aussi peu sécurisée que le système qu'elle fait tourner, c'est-à-dire pas beaucoup. Il faut aussi qu'on fasse tous un effort pour avoir des userspaces plus sécurisés, à la fois en faisant des progrès incrémentaux (le Linux kernel hardening project est un bon pas en avant pour les gens qui ne sont pas sous PaX) et des progrès sur la conception de fond (Capsicum, sandboxing, etc.).