Je comprends ton argument. Effectivement, un des arguments principaux de l'intérêt du Hurd est ce qu'il permet aux utilisateurs non-privilégiés sur une machine. On retrouve là la préoccupation première du projet GNU (redonner la liberté à l'utilisateur). Cette préoccupation, au niveau technique, a probablement perdu de son sens dans les dix dernières années, avec le développement de l'informatique grand public. Je crois pourtant qu'elle est toujours d'actualité, et que par delà même cette préoccupation, le Hurd n'a jamais été autant d'actualité.
Le premier point sur lequel je voudrais insister est que c'est une vision extrêmement étriquée de l'informatique que de penser qu'aujourd'hui, chacun est son propre administrateur. Il reste beaucoup d'endroits où ce genre de solutions n'est pas souhaitable ou réalisable : dans les labos en général, où beaucoup d'utilisateurs ont besoin de ressources partagées (gros serveur de calcul, serveur d'applications), sans qu'il soit envisageable que le moindre thésard ait des droits privilégiés sur la machine. Réussir à lui donner suffisamment de droits pour qu'il puisse faire son travail de façon correcte sans pour autant lui donner de quoi compromettre la machine est un éternel travail d'équilibriste, et n'aboutit que très rarement à des solutions satisfaisantes. On remarque d'ailleurs que les solutions à base de sudo(8) (sur une seule commande, par groupe, ...) deviennent de plus en plus monnaie courante, et je pense que même si c'est bien pratique, tout le monde s'accordera à dire que c'est loin d'être satisfaisant. Le problème se pose encore plus dans le contexte éducatif, puisqu'on peut rarement considérer qu'on fait confiance aux étudiants (et on nous taperait sur les doigts encore plus si on le faisait que pour les thésards). Et ça n'est pas qu'une subsistance : avec le développement des connexions "haut débit", il est de plus en plus possible de donner accès à des ressources électroniques à distance, et l'arbitrage entre utilisabilité et sécurité devient plus important que jamais (si quelqu'un travaille en télétravail 3 jours par semaine, il faut que ce soit _très_ utilisable ; mais il faut en même temps faire _très_ attention point de vue sécurité).
Par ailleurs, je crois que toute l'innovation apportée pour permettre à des utilisateurs non privilégiés de faire toujours plus sans compromettre le système est encore très profitable même dans le cas de l'informatique personnelle. D'une part, si les utilisateurs peuvent faire plus c'est parce que de moins en moins de code nécessitent des privilèges noyau : d'autant moins de risque de faire planter totalement la machine, d'autant moins de risque de l'endommager, et d'autant moins de risque de permettre à un attaquant (et le problème des attaques à distance est plus que jamais le problème de l'informatique personnelle) de gagner des privilèges lui permettant des dégâts irréparables. D'autre part, ces possibilités résolvent bien des problèmes couramment rencontrés même sur des machines où le seul utilisateur est son administrateur. Je pense par exemple aux problèmes de droit que l'on rencontre quand on monte un FS : les droits qui se retrouvent à user:user et donc la moitié des choses qui marchent plus, les comportements tout bizarres pour les suid... Et je ne parle pas du fait qu'il faille rajouter une entrée dans le fstab à chaque fois qu'on veut pouvoir monter un truc en utilisateur normal (et l'utilisateur normal a plus envie de double-cliquer pour monter que faire un "sudo mount", si, si). Sous GNU/Hurd, absolument aucun problème : vous montez vos propres FS sans vous soucier du problème de droit et des problèmes de sécurité (tout utilisateur ayant des notions d'Unix verra sa barbe se hérisser en laissant un utilisateur monter un FS quelconque sans avoir pourtant de droits privilégiés, quand bien même ça ne serait que lui ;-). Tu apprécieras aussi choisir le comportement en cas de crash par utilisateur, grâce à la flexibilité des translators, et pas se retrouver que le ~ de ta petite soeur se retrouve faire 80G du fait des .core du dernier jeu que tu lui as installé qui plantait de partout. (OK, ulimit -c ça existe, mais la soeur risque d'être surprise si tu as eu l'idée de mettre un "suspend" par défaut en cas de crash, croyez moi ;-)
Et puis, c'est être extrêmement simpliste que de limiter les avantages du Hurd à ça. Les avantages du Hurd se posent par exemple en terme de flexibilité : amusez vous à faire un système de fichiers "virtuel" un peu original, comme un FS modélisant un annuaire LDAP (un ldapfs, quoi). Le peu de flexibilité qu'offre le VFS centralisé d'un Unix, la complexité du développement de telles choses en mode noyau vous apparaîtra évidente. Et pourtant, de plus en plus on essaye d'intégrer ce genre de webservices à l'OS. Par exemple, iDisk pour MacOS X ou les WebFolders pour Windows, qui utilisent tous deux WebDAV, permettent de fournir assez facilement à des utilisateurs leurs ~ à distance, sans les problèmes de FTP (passif/actif, galères de firewall, FTPS impossible si firewalls stateful, ...) et les galères de NFS/etc. Ceci n'existe pas sous GNU/Linux, où il faut se contenter de passer par Gnome-VFS ou KIO (ou par un module totalement instable et qui fait peur à voir). Ces besoins se font sentir dans le milieu professionnel depuis déjà plusieurs années, et pourtant toujours pas de solutions pour ce genre de services, ou alors complètement insatisfaisantes (aucune sécurité, aucune stabilité). Je crois qu'on touche là aux limites de la flexibilité d'Unix.
Le Hurd, c'est aussi un système de gestion des droits totalement différent. À l'heure de Kerberos et des ST un peu partout, il est hallucinant qu'un système comme GNU/Linux soit aussi limité en terme de gestion des droits. Tous les jours, dans mes développements internes, je vois de plus en plus le besoin d'un système où je pourrais, sur mon système, fournir un certificat, un couple (login, pass), ou un quelconque autre moyen d'authentification et obtenir un jeton me donnant des droits bien particuliers. Et cela au coeur du système, pas que pour les WebServices, pas en surcouche. Ma remarque sur le développement d'utilisation de sudo(8) de plus en plus massive est un signe de la nécessité d'une gestion des droits plus fine, je pense.
Le Hurd, c'est aussi la possibilité d'avoir des personnalités multiples. Il est tout à fait envisageable, dès maintenant, de programmer des serveurs "alternatifs" remplaçant des gros bouts du GNU/Hurd tel qu'on le connaît. Tant que ces serveurs respectent les interfaces clairement définies, chaque utilisateur pourra alors facilement lancer son propre "sous-système" avec les serveurs qui lui plaisent. Et ça ne sert pas que sur des grosses stations multi-utilisateur : il est tout à fait possible que je souhaite lancer un environnement particulier que pour une seule application, et pour tout le reste je veuille rester dans l'environnement POSIX standard.
Tu parlais de UML ou de Xen. Tout d'abord laisse moi te dire ma perplexité face à ce conseil. Il est -inimaginable- d'utiliser une telle solution en production. UML peut tout au mieux servir à réaliser des tests préliminaires dans un environnement non critique. 'préliminaires', parce qu'un environnement UML a de moins en moins à voir avec un environnement 'réel' à base de Linux : Linux n'est pas fait pour tourner en mode utilisateur, et de ce fait les modifications nécessaires sont énormes, et changent considérablement le comportement de l'application. Et 'non critique', parce que du fait de la complexité d'un tel travail, UML est extrêmement peu stable, et fait même très souvent planter le noyau principal lui-même (un comble !). Si pratique que cette bidouille puisse être, elle reste une bidouille et ne devrait pas avoir d'autre ambition que d'être réservée au développement Linux comme elle l'était à l'origine. Pour le Hurd, en revanche, c'est bien différent : tous les serveurs tournant en user space, faire tourner un deuxième "co-Hurd" ou "sous-Hurd" (les deux sont possibles, selon que l'un agit comme "proxy" de l'autre pour les ressources partagées ou qu'ils agissent en parallèle, avec des bouts communs) est quelque chose de naturel, et ça ne nécessite pas une version modifiée ou quoi que ce soit.
Je concluerai enfin sur ce qui est généralement ma première remarque quand on me demande les avantages du Hurd. Le Hurd est le coeur d'un système d'exploitation. Il ne fournit directement qu'extrêmement peu aux utilisateurs. Ce qu'il fournit, c'est des -possibilités- que les développeurs d'application utilisent ou non. GaGadget parlait de la possibilité d'avoir plusieurs VM, plusieurs schedulers en parallèle. Utilisé à bon escient, c'est là une possibilité d'optimisation fabuleuse : on sait pertinemment que tel comportement de VM est bien plus adapté à tel environnement que tel autre, et d'ailleurs tout le travail d'un développeur de VM sur des systèmes centralisés consiste à déterminer ce qu'on considère comme le "cas moyen", et ce qui est moins pire dans ce cas là. Sur un système décentralisé comme le Hurd sur L4, il est tout à fait possible d'avoir plusieurs VM en parallèle qui régissent différemment la mémoire qui leur est allouée. Et je ne parle pas des négociations de QoS que permettent une conception décentralisée, et fondée sur la communication entre processus, qui représentent des possibilités de 20 à 50% d'amélioration des performances sur des applications spécifiques, comme les serveurs de base de donneés, et encore plus sur le cas du multimedia. Si les développeurs utilisent ces possibilités (que ce soit la possibilité de remplacer des serveurs, la flexibilité du système d'authentification, les notifications, ou la négociation de QoS), alors toi, utilisateur, oui, tu verras les amélirations, et pas qu'un peu.
[^] # Re: Debian et L4
Posté par Manuel Menal . En réponse à la dépêche Interview de Richard Stallman sur KernelTrap. Évalué à 10.
Le premier point sur lequel je voudrais insister est que c'est une vision extrêmement étriquée de l'informatique que de penser qu'aujourd'hui, chacun est son propre administrateur. Il reste beaucoup d'endroits où ce genre de solutions n'est pas souhaitable ou réalisable : dans les labos en général, où beaucoup d'utilisateurs ont besoin de ressources partagées (gros serveur de calcul, serveur d'applications), sans qu'il soit envisageable que le moindre thésard ait des droits privilégiés sur la machine. Réussir à lui donner suffisamment de droits pour qu'il puisse faire son travail de façon correcte sans pour autant lui donner de quoi compromettre la machine est un éternel travail d'équilibriste, et n'aboutit que très rarement à des solutions satisfaisantes. On remarque d'ailleurs que les solutions à base de sudo(8) (sur une seule commande, par groupe, ...) deviennent de plus en plus monnaie courante, et je pense que même si c'est bien pratique, tout le monde s'accordera à dire que c'est loin d'être satisfaisant. Le problème se pose encore plus dans le contexte éducatif, puisqu'on peut rarement considérer qu'on fait confiance aux étudiants (et on nous taperait sur les doigts encore plus si on le faisait que pour les thésards). Et ça n'est pas qu'une subsistance : avec le développement des connexions "haut débit", il est de plus en plus possible de donner accès à des ressources électroniques à distance, et l'arbitrage entre utilisabilité et sécurité devient plus important que jamais (si quelqu'un travaille en télétravail 3 jours par semaine, il faut que ce soit _très_ utilisable ; mais il faut en même temps faire _très_ attention point de vue sécurité).
Par ailleurs, je crois que toute l'innovation apportée pour permettre à des utilisateurs non privilégiés de faire toujours plus sans compromettre le système est encore très profitable même dans le cas de l'informatique personnelle. D'une part, si les utilisateurs peuvent faire plus c'est parce que de moins en moins de code nécessitent des privilèges noyau : d'autant moins de risque de faire planter totalement la machine, d'autant moins de risque de l'endommager, et d'autant moins de risque de permettre à un attaquant (et le problème des attaques à distance est plus que jamais le problème de l'informatique personnelle) de gagner des privilèges lui permettant des dégâts irréparables. D'autre part, ces possibilités résolvent bien des problèmes couramment rencontrés même sur des machines où le seul utilisateur est son administrateur. Je pense par exemple aux problèmes de droit que l'on rencontre quand on monte un FS : les droits qui se retrouvent à user:user et donc la moitié des choses qui marchent plus, les comportements tout bizarres pour les suid... Et je ne parle pas du fait qu'il faille rajouter une entrée dans le fstab à chaque fois qu'on veut pouvoir monter un truc en utilisateur normal (et l'utilisateur normal a plus envie de double-cliquer pour monter que faire un "sudo mount", si, si). Sous GNU/Hurd, absolument aucun problème : vous montez vos propres FS sans vous soucier du problème de droit et des problèmes de sécurité (tout utilisateur ayant des notions d'Unix verra sa barbe se hérisser en laissant un utilisateur monter un FS quelconque sans avoir pourtant de droits privilégiés, quand bien même ça ne serait que lui ;-). Tu apprécieras aussi choisir le comportement en cas de crash par utilisateur, grâce à la flexibilité des translators, et pas se retrouver que le ~ de ta petite soeur se retrouve faire 80G du fait des .core du dernier jeu que tu lui as installé qui plantait de partout. (OK, ulimit -c ça existe, mais la soeur risque d'être surprise si tu as eu l'idée de mettre un "suspend" par défaut en cas de crash, croyez moi ;-)
Et puis, c'est être extrêmement simpliste que de limiter les avantages du Hurd à ça. Les avantages du Hurd se posent par exemple en terme de flexibilité : amusez vous à faire un système de fichiers "virtuel" un peu original, comme un FS modélisant un annuaire LDAP (un ldapfs, quoi). Le peu de flexibilité qu'offre le VFS centralisé d'un Unix, la complexité du développement de telles choses en mode noyau vous apparaîtra évidente. Et pourtant, de plus en plus on essaye d'intégrer ce genre de webservices à l'OS. Par exemple, iDisk pour MacOS X ou les WebFolders pour Windows, qui utilisent tous deux WebDAV, permettent de fournir assez facilement à des utilisateurs leurs ~ à distance, sans les problèmes de FTP (passif/actif, galères de firewall, FTPS impossible si firewalls stateful, ...) et les galères de NFS/etc. Ceci n'existe pas sous GNU/Linux, où il faut se contenter de passer par Gnome-VFS ou KIO (ou par un module totalement instable et qui fait peur à voir). Ces besoins se font sentir dans le milieu professionnel depuis déjà plusieurs années, et pourtant toujours pas de solutions pour ce genre de services, ou alors complètement insatisfaisantes (aucune sécurité, aucune stabilité). Je crois qu'on touche là aux limites de la flexibilité d'Unix.
Le Hurd, c'est aussi un système de gestion des droits totalement différent. À l'heure de Kerberos et des ST un peu partout, il est hallucinant qu'un système comme GNU/Linux soit aussi limité en terme de gestion des droits. Tous les jours, dans mes développements internes, je vois de plus en plus le besoin d'un système où je pourrais, sur mon système, fournir un certificat, un couple (login, pass), ou un quelconque autre moyen d'authentification et obtenir un jeton me donnant des droits bien particuliers. Et cela au coeur du système, pas que pour les WebServices, pas en surcouche. Ma remarque sur le développement d'utilisation de sudo(8) de plus en plus massive est un signe de la nécessité d'une gestion des droits plus fine, je pense.
Le Hurd, c'est aussi la possibilité d'avoir des personnalités multiples. Il est tout à fait envisageable, dès maintenant, de programmer des serveurs "alternatifs" remplaçant des gros bouts du GNU/Hurd tel qu'on le connaît. Tant que ces serveurs respectent les interfaces clairement définies, chaque utilisateur pourra alors facilement lancer son propre "sous-système" avec les serveurs qui lui plaisent. Et ça ne sert pas que sur des grosses stations multi-utilisateur : il est tout à fait possible que je souhaite lancer un environnement particulier que pour une seule application, et pour tout le reste je veuille rester dans l'environnement POSIX standard.
Tu parlais de UML ou de Xen. Tout d'abord laisse moi te dire ma perplexité face à ce conseil. Il est -inimaginable- d'utiliser une telle solution en production. UML peut tout au mieux servir à réaliser des tests préliminaires dans un environnement non critique. 'préliminaires', parce qu'un environnement UML a de moins en moins à voir avec un environnement 'réel' à base de Linux : Linux n'est pas fait pour tourner en mode utilisateur, et de ce fait les modifications nécessaires sont énormes, et changent considérablement le comportement de l'application. Et 'non critique', parce que du fait de la complexité d'un tel travail, UML est extrêmement peu stable, et fait même très souvent planter le noyau principal lui-même (un comble !). Si pratique que cette bidouille puisse être, elle reste une bidouille et ne devrait pas avoir d'autre ambition que d'être réservée au développement Linux comme elle l'était à l'origine. Pour le Hurd, en revanche, c'est bien différent : tous les serveurs tournant en user space, faire tourner un deuxième "co-Hurd" ou "sous-Hurd" (les deux sont possibles, selon que l'un agit comme "proxy" de l'autre pour les ressources partagées ou qu'ils agissent en parallèle, avec des bouts communs) est quelque chose de naturel, et ça ne nécessite pas une version modifiée ou quoi que ce soit.
Je concluerai enfin sur ce qui est généralement ma première remarque quand on me demande les avantages du Hurd. Le Hurd est le coeur d'un système d'exploitation. Il ne fournit directement qu'extrêmement peu aux utilisateurs. Ce qu'il fournit, c'est des -possibilités- que les développeurs d'application utilisent ou non. GaGadget parlait de la possibilité d'avoir plusieurs VM, plusieurs schedulers en parallèle. Utilisé à bon escient, c'est là une possibilité d'optimisation fabuleuse : on sait pertinemment que tel comportement de VM est bien plus adapté à tel environnement que tel autre, et d'ailleurs tout le travail d'un développeur de VM sur des systèmes centralisés consiste à déterminer ce qu'on considère comme le "cas moyen", et ce qui est moins pire dans ce cas là. Sur un système décentralisé comme le Hurd sur L4, il est tout à fait possible d'avoir plusieurs VM en parallèle qui régissent différemment la mémoire qui leur est allouée. Et je ne parle pas des négociations de QoS que permettent une conception décentralisée, et fondée sur la communication entre processus, qui représentent des possibilités de 20 à 50% d'amélioration des performances sur des applications spécifiques, comme les serveurs de base de donneés, et encore plus sur le cas du multimedia. Si les développeurs utilisent ces possibilités (que ce soit la possibilité de remplacer des serveurs, la flexibilité du système d'authentification, les notifications, ou la négociation de QoS), alors toi, utilisateur, oui, tu verras les amélirations, et pas qu'un peu.