Re:

> On y retrouve la notion de "Copy on Write" : lors de la modification d'un fichier ce dernier est simplement copié à un autre endroit du système de fichiers et les nouvelles données seront enregistrées sur la copie au lieu de l'être sur l'original.

???
Si j'ai bien compris, lorsqu'il y a copie de fichier, en fait il n'y a pas copie physique du fichier (seulement deux façons d'accéder aux mêmes données). Lorsqu'il y a modification d'un fichier, sont enregistrés que les modifications (ce qui va être modifié est copié ; d'où le "Copy on Write").
Il y a aussi un ext3 CoW (qui permet entre autre de versionner un système de fichier), mais il ne marche pas comme tu le dis.

> Vérification du système de fichiers, avec le programme btrfsck, tolérante aux erreurs

C'est le minimum...

> On peut citer tout d'abord le fait que le mode setting, puisqu'il est unifié dans le noyau, se retrouve donc partagé entre tous les pilotes.

C'est un peu du pipo à mon avis. Avant tout était fait dans Xorg, donc c'était tout autant contralisé.
KMS est simplement plus propre d'un point de vu architecture (sécurité par exemple). C'est au noyau de configurer le matos.

> C'est la fin d'une multitude de lignes de codes redondantes au profit d'une seule implémentation plus robuste.

On évite la duplication du code côté client. Avant chaque client de carte graphique (Xorg, Xfree, etc) avait le driver. Maintenant ce n'est plus le cas (en parti).

> Enfin avec KMS le changement rapide d'utilisateur (fast user switching) est facilité puisqu'il n'y a plus besoin de changer de terminal virtuel

Sûr ?
A ma connaissance il y a toujours changement de terminal virtuel. Mais avec KMS ça se fait super rapidement (ce qui donne peut-être l'illusion qu'il n'y a pas de changement de terminal virtuel).

> Actuellement il n'y a que le pilote Intel qui fonctionne bien avec KMS

C'était vrai au tout début de KMS. Puis rien ne marchait avec KMS (Intel a fait de grosses modifications dans ses drivers). Puis il n'y avait que ATI qui marchait avec KMS (c'est le cas pour F10). Ajourd'hui ATI et NVidia (avec le driver Nouveau) marchent avec KMS. Intel marche à nouveau mais il reste beaucoup de bugs qui devraient être rapidement corrigés.

> Une alternative consiste à se baser non pas sur des labels, mais sur le chemin d'accès aux objets (par exemple /usr/sbin/httpd)

Juste pour information, car il semble que beaucoup l'ignorent, SeLinux affecte les labels de sécurité à la création des fichiers et ceci tient compte du chemin d'accès. Par contre la décision d'autoriser un accès ne tient pas compte du chemin d'accès (ce qui n'est pas un problème puisque le label de sécurité est définit en fonction du chemin).

> Si AppArmor n'est peut-être plus vraiment d'actualité

Diantre, il y a pourtant cette distribution hyper populaire qui l'avait adopté : Canonical.
Comme quoi, l'influence de Canonical...
Ben ça sera TOMOYO (ou autre) après AppArmor, mais pas SeLinux. Combien d'années vont se passer avant qu'il n'y ait pas que Red Hat qui propose un SeLinux (ou équivalent) satisfaisant...
C'est de la science fiction, et ça profite principalement, voire uniquement, qu'à Red Hat...

> les utilisateurs de Linux pourront donc comparer les approches et choisir le module qui leur conviendra le mieux.

C'est "tragique" de lire ça. Pourquoi ne pas donner le choix "compte utilisateur root + anti-virus (à la Windows)" comme choix à l'utilisateur...