Bon, encore un commentaire auquel j'avais déjà répondu, mais la réponse n'est pas apparue. :(
La compatibilité binaire est effectivement prévue, comme un objectif à long terme, mais n'y comptez pas dans le futur proche.
Mais je tiens à réagir sur ton affirmation disant que « Comme les 2 OS ne diffèrent pas de grand chose (le kernel et l'interface avec le kernel) ».
C'est complètement faux. FreeBSD et GNU/Linux ont bien plus de points communs que GNU. Ils sont tous deux extrêmement proche d'Unix, alors que GNU n'est pas à la base proche d'Unix - le Hurd et la GNU Libc s'efforcent juste de fournir une compatibilité POSIX.
En particulier, concernant le Hurd, nombre de notions classiques sous Unix n'existent plus:
* La notion de fichier en soi. Comme déjà dit dans mon commentaire précédent, le fichier n'est plus à la base qu'une interface permettant de joindre une application, et le système de fichiers n'est plus qu'un espace de nom pour obtenir des ports. Il est évident que le Hurd supporte néanmoins ext2fs, et UFS, et donc la notion de fichier tradionelle. Cependant, ça n'est pas un concept propre au Hurd, et les appels systèmes habituels de manipulation des fichiers ne sont que des interfaces de compatibilité - pour les basiques, réalisables via de simples RPC (Remote Procedure Call) à l'application qui écoute derrière, mais beaucoup plus difficilement pour certains autres, et en particulier, pour retourner des erreurs dans des cas précis définis par POSIX...
* Les notions traditionneles d'UGIDs (entendez, UID et GID). Le modèle « un programme, un (e)UID » est complètement cassé pour faire place au principe des jetons d'authentification (authentification tokens), modèle bien plus puissant, où l'on peut acquérir - via le serveur password - plus de droits dynamiquement - sans pour autant devenir root, vu que l'on peut avoir plusieurs jetons correspondant aux droits de plusieurs utilisateurs, en soustraire - jusqu'à ne plus en avoir du tout, permettant l'existence d'un _réel_ nobody - il est dit « unknown » - qui n'est __pas_ un utilisateur, et n'a à la base aucun droit - si ce n'est utiliser ce que l'application a créé avec des droits supérieurs auparavant bien entendu, sauf si l'administrateur lui en donne - il y'a maintenant plus seulement ugo, mais aussi ugok, pour unKnown. Cela est particulièrement intéressant concernant les applications devant ouvrir un port « sécurisé » - comme un FTPd - (< 1024), requierant les droits root: on lance l'application en root, on ouvre le socket, on bind, listen, et dès que tout cela est fini, on s'enlève tous les droits. Ainsi, une faille à ce niveau n'aurait _aucune_ conséquence, puisqu'il ne pourrait _rien_ faire.. Par la suite, il n'y a plus qu'à transmettre les données fournies par l'utilisateur au prompt de son client FTP au serveur password, l'authentifier, et le voilà avec ses propres droits d'utilisateur et pas plus, sans
aucune difficulté.
De même, ce concept de serveur auth à qui on demande l'autorisation avant de faire n'importe quelle opération permet d'implémenter facilement, de façon jolie, performante, et native, le système
des capabilities Linux - connu pour son inflexibilité, ce qui explique pourquoi il est si peu utilisé.. - et les prétendus systèmes révolutionnaires comme LIDS.
Par faute de temps je m'arrêterais là, mais il faut savoir qu'il y'a encore de nombreux exemples, et qu'au fur et à mesure, si la compatibilité POSIX devrait s'améliorer, le Hurd devra s'éloigner d'Unix, essayant de faire mieux pour tous les domaines - par exemple, concevoir un nouveau système d'init, pour remplacer les init SysV et BSD, qui ne sont pas des modèles de propreté et d'efficacité ANHA. Cependant, ça n'est pas spécifique au Hurd: c'est une idée générale derrière le GNU, et beaucoup des codes faits pour le Hurd sont en fait réutilisés dans les autres ports de la GNU Libc - pensons à argp, aux pthreads, au futur système d'init justement..
Ah oui, dernière chose: ta distinction entre userland et serverland n'a pas du tout lieu d'être. Les applications qui composent le Hurd - le micro-noyau ne faisant PAS partie du Hurd - sont des applications e-x-a-c-t-e-m-e-n-t c-o-m-m-e les autres, certaines ayant des rôles similaires à des applications que tu peux trouver sous GNU/Linux.
Commentaires, questions, tout cela est bienvenu, je me sens tout seul sans réponse. :)
[^] # Re: compatibilité binaire
Posté par Manuel Menal . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 10.
La compatibilité binaire est effectivement prévue, comme un objectif à long terme, mais n'y comptez pas dans le futur proche.
Mais je tiens à réagir sur ton affirmation disant que « Comme les 2 OS ne diffèrent pas de grand chose (le kernel et l'interface avec le kernel) ».
C'est complètement faux. FreeBSD et GNU/Linux ont bien plus de points communs que GNU. Ils sont tous deux extrêmement proche d'Unix, alors que GNU n'est pas à la base proche d'Unix - le Hurd et la GNU Libc s'efforcent juste de fournir une compatibilité POSIX.
En particulier, concernant le Hurd, nombre de notions classiques sous Unix n'existent plus:
* La notion de fichier en soi. Comme déjà dit dans mon commentaire précédent, le fichier n'est plus à la base qu'une interface permettant de joindre une application, et le système de fichiers n'est plus qu'un espace de nom pour obtenir des ports. Il est évident que le Hurd supporte néanmoins ext2fs, et UFS, et donc la notion de fichier tradionelle. Cependant, ça n'est pas un concept propre au Hurd, et les appels systèmes habituels de manipulation des fichiers ne sont que des interfaces de compatibilité - pour les basiques, réalisables via de simples RPC (Remote Procedure Call) à l'application qui écoute derrière, mais beaucoup plus difficilement pour certains autres, et en particulier, pour retourner des erreurs dans des cas précis définis par POSIX...
* Les notions traditionneles d'UGIDs (entendez, UID et GID). Le modèle « un programme, un (e)UID » est complètement cassé pour faire place au principe des jetons d'authentification (authentification tokens), modèle bien plus puissant, où l'on peut acquérir - via le serveur password - plus de droits dynamiquement - sans pour autant devenir root, vu que l'on peut avoir plusieurs jetons correspondant aux droits de plusieurs utilisateurs, en soustraire - jusqu'à ne plus en avoir du tout, permettant l'existence d'un _réel_ nobody - il est dit « unknown » - qui n'est __pas_ un utilisateur, et n'a à la base aucun droit - si ce n'est utiliser ce que l'application a créé avec des droits supérieurs auparavant bien entendu, sauf si l'administrateur lui en donne - il y'a maintenant plus seulement ugo, mais aussi ugok, pour unKnown. Cela est particulièrement intéressant concernant les applications devant ouvrir un port « sécurisé » - comme un FTPd - (< 1024), requierant les droits root: on lance l'application en root, on ouvre le socket, on bind, listen, et dès que tout cela est fini, on s'enlève tous les droits. Ainsi, une faille à ce niveau n'aurait _aucune_ conséquence, puisqu'il ne pourrait _rien_ faire.. Par la suite, il n'y a plus qu'à transmettre les données fournies par l'utilisateur au prompt de son client FTP au serveur password, l'authentifier, et le voilà avec ses propres droits d'utilisateur et pas plus, sans
aucune difficulté.
De même, ce concept de serveur auth à qui on demande l'autorisation avant de faire n'importe quelle opération permet d'implémenter facilement, de façon jolie, performante, et native, le système
des capabilities Linux - connu pour son inflexibilité, ce qui explique pourquoi il est si peu utilisé.. - et les prétendus systèmes révolutionnaires comme LIDS.
Par faute de temps je m'arrêterais là, mais il faut savoir qu'il y'a encore de nombreux exemples, et qu'au fur et à mesure, si la compatibilité POSIX devrait s'améliorer, le Hurd devra s'éloigner d'Unix, essayant de faire mieux pour tous les domaines - par exemple, concevoir un nouveau système d'init, pour remplacer les init SysV et BSD, qui ne sont pas des modèles de propreté et d'efficacité ANHA. Cependant, ça n'est pas spécifique au Hurd: c'est une idée générale derrière le GNU, et beaucoup des codes faits pour le Hurd sont en fait réutilisés dans les autres ports de la GNU Libc - pensons à argp, aux pthreads, au futur système d'init justement..
Ah oui, dernière chose: ta distinction entre userland et serverland n'a pas du tout lieu d'être. Les applications qui composent le Hurd - le micro-noyau ne faisant PAS partie du Hurd - sont des applications e-x-a-c-t-e-m-e-n-t c-o-m-m-e les autres, certaines ayant des rôles similaires à des applications que tu peux trouver sous GNU/Linux.
Commentaires, questions, tout cela est bienvenu, je me sens tout seul sans réponse. :)