Et GNU/Hurd il en est où exactement. Parce que c'est pas avec le peu de informations/articles que l'on peut lire qu'on peut réellement suivre son développement.
C'est une question très difficile, j'imagine que tu en es conscient. GNU/Hurd en est où : il est relativement stable (à part sur les machines sur lesquelles le micro-noyau utilisé par le Hurd, GNU Mach, a des problèmes chroniques de stabilité) ; je l'ai moi-même utilisé comme seul système (GNU/Linux voulait plus s'installer ! :-) pendant près de deux mois, et aucun crash dans l'utilisation habituelle du système. (quand on commence à bidouiller pas mal avec proc, des translators, etc., là, les risques augmentent considérablement). Il est en tous cas très utilisable, du moins en console : la nouvelle console du Hurd, écrite par Marcus, supporte tout ce dont on peut souhaiter ou presque : le charset qu'on veut, y compris UTF-(8|16), la possibilité de détacher et réattacher ailleurs un vt (comme dans screen, sauf que c'est natif), la possibilité de multiplexer une console (pratique pour partager un terminal, faire des démos, ...), a plusieurs clients (VGA pour la console "native", mais aussi ncursesw, ce qui permet de rattacher sa console dans un xterm :-), même le beep, et bientôt des screensavers. ;-) Elle est très stable et facile à utiliser. De plus, grâce à Marco, on a un support XKB pour cette console qui permet d'utiliser n'importe quel keymap supporté par XFree86. Il mérite d'être testé !
La plupart des outils de base sont portés ; pour la plupart du reste, une recompilation suffit, ou alors une simple correction de bug dans le programme (genre, utilisation de MAXPATHLEN ou PATH_MAX inconditionnellement, ce qui n'est pas conforme à POSIX, utilisation de sys_errlist[], noms de fichiers teminant par /, ...) pour laquelle il suffira de demander un chtit peu d'aide à un membre d'HurdFr (par exemple). Seuls des grosses, grosses applications, comme Gnome ou KDE posent réellement problème, parce qu'ils utilisent des fonctionnalités (filelocks, par exemple) pas encore supportées par GNU/Hurd. La mémoire partagée SysV peut aussi manquer mais je ne peux pas citer d'application qui en dépende, de tête (The Gimp l'utilise mais marche sans). XFree86 est bien entendu porté mais il souffre de bugs embêtants : outre qu'il souffre des problèmes de lenteur de GNU/Hurd (notamment, les accès disques sont extrêmement lents), un bug empêche par exemple d'utiliser un clavier français en utilisateur normal. Le support des pthreads est encore assez jeune et quoi qu'a priori assez stable, plus de tests intensifs pourrait lui faire du bien :-)
Quant au support matériel de GNU/Hurd : il faut savoir que les pilotes de périphériques de GNU/Hurd sont aujourd'hui dans le micro-noyau, GNU Mach. La version "stable" actuelle est la 1.3 ; elle contient des pilotes périphériques issus de Linux 2.0.39, pour un certain nombre (via-rhine, rtl8139, ne2k) mis à jour. Alfred est en train de travailler pour intégrer à la prochaine version de GNU Mach 1.x les pilotes écrits par Donald Becker (dont sont issus les pilotes Linux, mais ce ne sont pas les mêmes, du fait de vieux conflits entre Becker et d'autres développeurs Linux) pour les cartes ethernet. Certains adaptateurs SCSI sont supportés. Plus de détails sur http://savannah.nongnu.org/cgi-bin/viewcvs/*checkout*/thug/thug/gnu(...) ; à noter qu'une version 2 de GNU Mach est en passe de voir le jour. La différence fondamentale est qu'elle utilise une bibliothèque externe pour les pilotes de périphérique, nommée OSKit, qui lui a des pilotes de périphériques de Linux 2.2.12, un code plus clair et documenté, un support PCMCIA, etc. Il lui manque cependant un support générique pour le port série (la seule chose pour lequel l'actuel marche, c'est le gdb à distance via port série, ce qui est déjà fondamental :-), un support PS/2, et surtout que les gens testent GNU/Hurd (notamment la console de Marcus dans tous ses recoins, XFree86, ...) avec.
Bon.. c'est à peu près tout pour l'état actuel de GNU/Hurd. Maintenant, les perspectives : le développeur principal du Hurd, Marcus Brinkmann, ainsi que pas mal d'autres travaillent actuelle sur le port du Hurd sur un autre micro-noyau, L4 - en l'occurrence, son implémentation par L4Ka, L4Ka::Pistachio. Les raisons sont multiples : GNU Mach est un micro-noyau de première génération ; ça veut dire qu'il fournit déjà par lui-même un grand nombre de services qui pourraient être mis dans l'espace utilisateur, par exemple, les pilotes de périphérique, la VM (Mach contient la partie de la VM qui décide de quelle page doit être virée de la mémoire et quelle page reste ; la partie concernant "où vont-elles ?" est réalisée en espace utilisateur, via les memory objects. c'est comme ça que fonctionnent les systèmes de fichiers, grosso modo), le scheduling, etc. L4, lui, ne fournit que les mécanismes de base qui nécessitent d'avoir des permissions spéciales (celles du noyau) : un appel système pour l'IPC le plus simple, la création d'espaces d'adressages, de threads, le changement des registres de base, le map en mémoire, et quelques petites autres choses. Pour Pistachio sur x86, je crois qu'on en est à 13 appels système, pas plus. L4, contrairement à Mach, est conçu avec comme objectif premier les performances. Pour les gens intéressés par des détails, je peux détailler, mais http://l4ka.org(...) le peut encore plus :-) (rubrique publications, notamment). Le port avance. Ca nécessite énormément de travail, sur les choses de base : VM, pilotes de périphériques, etc., nécessitent d'être bien pensés, bien conçus, de façon modulaire et performante. Beaucoup de travail est fait sur les spécifications en même temps que sur le code. Il n'est vraiment pas si difficile de participer : il faut juste lire les docs, essayer de comprendre, poser des questions (plein!), essayer de repérer les inconsistences, les trucs sur lesquels on pourrait bosser, et se jeter dedans.
Bien entendu, ça ne sera pas fini demain. Mais plus y aura de gens, plus ça ira vite. :)
A une époque pas si éloignée je m'étais interessé au GNU/Hurd mais depuis j'avoue avoir un peu baissé les bras parce que d'une part GNU/Linux est vraiment sensationnel et d'autre part, j'ai pas l'impression qu'il y ait un véritable engouement autour de GNU/Hurd. Je me trompe peut-être mais les hacker du Hurd devraient essayés de plus communiquer autour de leur projet sinon personne ne risque de s'y interessé (et c'est bien dommage).
Il est assez difficile de demander de communiquer à des gens qui sont déjà surchargés par la masse de travail à faire. Ils font l'effort, à chaque nouvelle /. (ou pour nous, francophones, chaque nouvelle DLFP :-) d'informer, de répondre, de rétablir la vérité, mais rien que ça demande énormément de temps, et ça n'est pas exactement le boulot le plus gratifiant et réjouissant intellectuellement. Quant à l'engouement, je serais pas aussi catégorique que toi. Beaucoup de gens s'y intéressent. Beaucoup de gens sont enthousiasmés. En revanche, il est assez difficile de leur faire franchir le pas de la contribution, parce que ça pourrait toujours un peu compliqué, un peu trop bas niveau, un peu trop réfléchi. Il faut le répéter : le développement du Hurd est accessible par tout le monde ayant des connaissances de développement en C. Le principe des translators, ça n'est pas dur à comprendre, c'est encore moins dur à coder. Prendre un bug au hasard, et se lancer à sa quête, c'est pas très difficile, et des gens, sur #hurdfr, sur #hurd, sur bug-hurd, sont prêts à vous aider. La plupart des threads sont des échanges entre Roland, Marcus, Thomas (trois développeurs principaux du Hurd, le premier et le dernier étant les auteurs originels) et des gens qui veulent corriger un bug.
D'autre part avec le peu de ressources françaises dans le domaine, il est d'autant plus difficile pour un non-anglophone de se documenter sur le sujet.
Ca, je veux bien le croire. Un gros travail de traduction avait été fait par HurdFr, mais la plupart ne sont aujourd'hui plus à jour. Ce serait génial que quelqu'un s'y remette ; ça non plus, ça n'est pas dur, tout le monde est prêt à aider (moi le premier), et c'est très instructif.
Voilà. Sinon ben j'ai toujours une machine sous le GNU/Hurd qui tourne même si je ne m'en sers pas vraiment, ça fonctionne bien (quoique un peu lent).
Si ça te dit, je pensais faire, quand on aura rétabli http://hurdfr.org(...) un RR sur un sous-domaine (du style, ssh.hurdfr.org) pour qu'un maximum de gens puisse avoir accès à une machine GNU/Hurd. J'en ai déjà 2/3 derrière, ce serait sympa si la tienne venait se rajouter (quelle connex', d'ailleurs ?). Pas besoin qu'elle soit allumée 24/24 7/7, vu que ce serait un RR.
[^] # Re: Login du mois : GNU/Hurd K5
Posté par Manuel Menal . En réponse à la dépêche Revue de presse - Mars 2004. Évalué à 10.
C'est une question très difficile, j'imagine que tu en es conscient. GNU/Hurd en est où : il est relativement stable (à part sur les machines sur lesquelles le micro-noyau utilisé par le Hurd, GNU Mach, a des problèmes chroniques de stabilité) ; je l'ai moi-même utilisé comme seul système (GNU/Linux voulait plus s'installer ! :-) pendant près de deux mois, et aucun crash dans l'utilisation habituelle du système. (quand on commence à bidouiller pas mal avec proc, des translators, etc., là, les risques augmentent considérablement). Il est en tous cas très utilisable, du moins en console : la nouvelle console du Hurd, écrite par Marcus, supporte tout ce dont on peut souhaiter ou presque : le charset qu'on veut, y compris UTF-(8|16), la possibilité de détacher et réattacher ailleurs un vt (comme dans screen, sauf que c'est natif), la possibilité de multiplexer une console (pratique pour partager un terminal, faire des démos, ...), a plusieurs clients (VGA pour la console "native", mais aussi ncursesw, ce qui permet de rattacher sa console dans un xterm :-), même le beep, et bientôt des screensavers. ;-) Elle est très stable et facile à utiliser. De plus, grâce à Marco, on a un support XKB pour cette console qui permet d'utiliser n'importe quel keymap supporté par XFree86. Il mérite d'être testé !
La plupart des outils de base sont portés ; pour la plupart du reste, une recompilation suffit, ou alors une simple correction de bug dans le programme (genre, utilisation de MAXPATHLEN ou PATH_MAX inconditionnellement, ce qui n'est pas conforme à POSIX, utilisation de sys_errlist[], noms de fichiers teminant par /, ...) pour laquelle il suffira de demander un chtit peu d'aide à un membre d'HurdFr (par exemple). Seuls des grosses, grosses applications, comme Gnome ou KDE posent réellement problème, parce qu'ils utilisent des fonctionnalités (filelocks, par exemple) pas encore supportées par GNU/Hurd. La mémoire partagée SysV peut aussi manquer mais je ne peux pas citer d'application qui en dépende, de tête (The Gimp l'utilise mais marche sans). XFree86 est bien entendu porté mais il souffre de bugs embêtants : outre qu'il souffre des problèmes de lenteur de GNU/Hurd (notamment, les accès disques sont extrêmement lents), un bug empêche par exemple d'utiliser un clavier français en utilisateur normal. Le support des pthreads est encore assez jeune et quoi qu'a priori assez stable, plus de tests intensifs pourrait lui faire du bien :-)
Quant au support matériel de GNU/Hurd : il faut savoir que les pilotes de périphériques de GNU/Hurd sont aujourd'hui dans le micro-noyau, GNU Mach. La version "stable" actuelle est la 1.3 ; elle contient des pilotes périphériques issus de Linux 2.0.39, pour un certain nombre (via-rhine, rtl8139, ne2k) mis à jour. Alfred est en train de travailler pour intégrer à la prochaine version de GNU Mach 1.x les pilotes écrits par Donald Becker (dont sont issus les pilotes Linux, mais ce ne sont pas les mêmes, du fait de vieux conflits entre Becker et d'autres développeurs Linux) pour les cartes ethernet. Certains adaptateurs SCSI sont supportés. Plus de détails sur http://savannah.nongnu.org/cgi-bin/viewcvs/*checkout*/thug/thug/gnu(...) ; à noter qu'une version 2 de GNU Mach est en passe de voir le jour. La différence fondamentale est qu'elle utilise une bibliothèque externe pour les pilotes de périphérique, nommée OSKit, qui lui a des pilotes de périphériques de Linux 2.2.12, un code plus clair et documenté, un support PCMCIA, etc. Il lui manque cependant un support générique pour le port série (la seule chose pour lequel l'actuel marche, c'est le gdb à distance via port série, ce qui est déjà fondamental :-), un support PS/2, et surtout que les gens testent GNU/Hurd (notamment la console de Marcus dans tous ses recoins, XFree86, ...) avec.
Bon.. c'est à peu près tout pour l'état actuel de GNU/Hurd. Maintenant, les perspectives : le développeur principal du Hurd, Marcus Brinkmann, ainsi que pas mal d'autres travaillent actuelle sur le port du Hurd sur un autre micro-noyau, L4 - en l'occurrence, son implémentation par L4Ka, L4Ka::Pistachio. Les raisons sont multiples : GNU Mach est un micro-noyau de première génération ; ça veut dire qu'il fournit déjà par lui-même un grand nombre de services qui pourraient être mis dans l'espace utilisateur, par exemple, les pilotes de périphérique, la VM (Mach contient la partie de la VM qui décide de quelle page doit être virée de la mémoire et quelle page reste ; la partie concernant "où vont-elles ?" est réalisée en espace utilisateur, via les memory objects. c'est comme ça que fonctionnent les systèmes de fichiers, grosso modo), le scheduling, etc. L4, lui, ne fournit que les mécanismes de base qui nécessitent d'avoir des permissions spéciales (celles du noyau) : un appel système pour l'IPC le plus simple, la création d'espaces d'adressages, de threads, le changement des registres de base, le map en mémoire, et quelques petites autres choses. Pour Pistachio sur x86, je crois qu'on en est à 13 appels système, pas plus. L4, contrairement à Mach, est conçu avec comme objectif premier les performances. Pour les gens intéressés par des détails, je peux détailler, mais http://l4ka.org(...) le peut encore plus :-) (rubrique publications, notamment). Le port avance. Ca nécessite énormément de travail, sur les choses de base : VM, pilotes de périphériques, etc., nécessitent d'être bien pensés, bien conçus, de façon modulaire et performante. Beaucoup de travail est fait sur les spécifications en même temps que sur le code. Il n'est vraiment pas si difficile de participer : il faut juste lire les docs, essayer de comprendre, poser des questions (plein!), essayer de repérer les inconsistences, les trucs sur lesquels on pourrait bosser, et se jeter dedans.
Bien entendu, ça ne sera pas fini demain. Mais plus y aura de gens, plus ça ira vite. :)
A une époque pas si éloignée je m'étais interessé au GNU/Hurd mais depuis j'avoue avoir un peu baissé les bras parce que d'une part GNU/Linux est vraiment sensationnel et d'autre part, j'ai pas l'impression qu'il y ait un véritable engouement autour de GNU/Hurd. Je me trompe peut-être mais les hacker du Hurd devraient essayés de plus communiquer autour de leur projet sinon personne ne risque de s'y interessé (et c'est bien dommage).
Il est assez difficile de demander de communiquer à des gens qui sont déjà surchargés par la masse de travail à faire. Ils font l'effort, à chaque nouvelle /. (ou pour nous, francophones, chaque nouvelle DLFP :-) d'informer, de répondre, de rétablir la vérité, mais rien que ça demande énormément de temps, et ça n'est pas exactement le boulot le plus gratifiant et réjouissant intellectuellement. Quant à l'engouement, je serais pas aussi catégorique que toi. Beaucoup de gens s'y intéressent. Beaucoup de gens sont enthousiasmés. En revanche, il est assez difficile de leur faire franchir le pas de la contribution, parce que ça pourrait toujours un peu compliqué, un peu trop bas niveau, un peu trop réfléchi. Il faut le répéter : le développement du Hurd est accessible par tout le monde ayant des connaissances de développement en C. Le principe des translators, ça n'est pas dur à comprendre, c'est encore moins dur à coder. Prendre un bug au hasard, et se lancer à sa quête, c'est pas très difficile, et des gens, sur #hurdfr, sur #hurd, sur bug-hurd, sont prêts à vous aider. La plupart des threads sont des échanges entre Roland, Marcus, Thomas (trois développeurs principaux du Hurd, le premier et le dernier étant les auteurs originels) et des gens qui veulent corriger un bug.
D'autre part avec le peu de ressources françaises dans le domaine, il est d'autant plus difficile pour un non-anglophone de se documenter sur le sujet.
Ca, je veux bien le croire. Un gros travail de traduction avait été fait par HurdFr, mais la plupart ne sont aujourd'hui plus à jour. Ce serait génial que quelqu'un s'y remette ; ça non plus, ça n'est pas dur, tout le monde est prêt à aider (moi le premier), et c'est très instructif.
Voilà. Sinon ben j'ai toujours une machine sous le GNU/Hurd qui tourne même si je ne m'en sers pas vraiment, ça fonctionne bien (quoique un peu lent).
Si ça te dit, je pensais faire, quand on aura rétabli http://hurdfr.org(...) un RR sur un sous-domaine (du style, ssh.hurdfr.org) pour qu'un maximum de gens puisse avoir accès à une machine GNU/Hurd. J'en ai déjà 2/3 derrière, ce serait sympa si la tienne venait se rajouter (quelle connex', d'ailleurs ?). Pas besoin qu'elle soit allumée 24/24 7/7, vu que ce serait un RR.