Je réponds au commentaire deux niveaux au dessus en reprenant celui-là. Désolé pour la confusion que cela entraîne ;-)
Concernant la place, à peu près équivalente à une Debian GNU/Linux. Le système de base tient sur 31Mo compressé (le mini-CD de K8 fait 33Mo). Évidemment, en général, quand on utilise GNU/Hurd c'est pour tester, et que ce soit pour du packaging ou du développement à tous niveaux, il faut compter de la place pour /src. ;-)
Comme je le disais, 71% de l'archive Debian fonctionne. Le reste nécessite généralement des patchs assez simples liés à des problèmes connus (MAXPATHLEN/PATH_MAX, MAXHOSTNAMELEN, NCARGS). En revanche, les gros morceaux que sont Gnome, KDE ou OpenOffice.Org ne fonctionnent pas, pour des raisons diverses : certaines parties dépendent inconditionnellement de la mémoire partagée SysV (shmget(2), mais c'est rare), certaines ont besoin des file locks (flockfile(3), c'est le cas notamment de GConf), etc. Bref, tout un tas de petits trucs qui manquent et qui empêchent le port de "grosses" applications où la probabilité qu'elles soient utilisées augmente. Il n'y a plus aucun problème avec les threads depuis que les pthreads sont parfaitement supportés, grâce à Neal H. Walfield. (enfin, parfois il y a une différence d'interprétation de POSIX entre NPTL/LinuxThreads et la libpthread du Hurd, mais c'est rare)
Lors de nos démonstrations, on utilise généralement WindowMaker, rxvt, gqview, mplayer en aalib. Ce genre de choses ne nous crée que rarement des surprises. Mais il ne faut pas rêver, d'abord c'est assez lent, et ça ne marche pas toujours. M'enfin, les visiteurs de Solutions Linux ont pu le voir marcher assez bien en général. ;-)
Concernant la portabilité, seul IA-32 est supporté pour GNU/Hurd sur Mach. Il faut bien comprendre que le but de cette branche actuellement est de faire qu'un max de gens testent et portent les paquets, etc., etc. IA-32 étant utilisé par le plus de gens, il est logique de la supporter en priorité - et nous n'avons pas les moyens de supporter hurd-ppc, hurd-ia64 ou que sais-je. Pour les courageux - voire téméraires -, le Hurd devrait tourner sur toutes les machines supportées par une implémentation de Mach respectant les interfaces de CMU Mach 3.0 (donc, compatible GNU Mach). Des implémentations existent sur Alpha, Sparc, Sparc64, PowerPC (oldworld seulement). Bon courage ;-)
Le Hurd sur L4 en revanche est développé avec la portabilité en tête, principalement sur PowerPC. L4Ka::Pistachio (l'implémentation de L4 qu'on utilise) lui-même tourne sur un grand nombre d'architectures (Alpha, AMD64, ARM, IA32, IA64, MIPS, PPC32, PPC64, cf. http://www.l4ka.org/projects/pistachio/(...) pour plus d'informations). Il est bien évident que GNU/Hurd a pour ambition d'être un système versatile, flexible, pouvant s'adapter du système "embarqué" relativement évolué (avec MMU, sans quoi ça n'a plus grand sens, donc on est sur de l'embarqué style ordinateur de bord, frigos ;-) aux grosses machines ayant besoin de virtualisation, de domaines, toussa. Et puis, la portabilité était un argument de vente majeur des micro-noyaux, montrons que tout n'était pas faux ;-)
[^] # Re: Compléments
Posté par Manuel Menal . En réponse à la dépêche Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4. Évalué à 10.
Concernant la place, à peu près équivalente à une Debian GNU/Linux. Le système de base tient sur 31Mo compressé (le mini-CD de K8 fait 33Mo). Évidemment, en général, quand on utilise GNU/Hurd c'est pour tester, et que ce soit pour du packaging ou du développement à tous niveaux, il faut compter de la place pour /src. ;-)
Comme je le disais, 71% de l'archive Debian fonctionne. Le reste nécessite généralement des patchs assez simples liés à des problèmes connus (MAXPATHLEN/PATH_MAX, MAXHOSTNAMELEN, NCARGS). En revanche, les gros morceaux que sont Gnome, KDE ou OpenOffice.Org ne fonctionnent pas, pour des raisons diverses : certaines parties dépendent inconditionnellement de la mémoire partagée SysV (shmget(2), mais c'est rare), certaines ont besoin des file locks (flockfile(3), c'est le cas notamment de GConf), etc. Bref, tout un tas de petits trucs qui manquent et qui empêchent le port de "grosses" applications où la probabilité qu'elles soient utilisées augmente. Il n'y a plus aucun problème avec les threads depuis que les pthreads sont parfaitement supportés, grâce à Neal H. Walfield. (enfin, parfois il y a une différence d'interprétation de POSIX entre NPTL/LinuxThreads et la libpthread du Hurd, mais c'est rare)
Lors de nos démonstrations, on utilise généralement WindowMaker, rxvt, gqview, mplayer en aalib. Ce genre de choses ne nous crée que rarement des surprises. Mais il ne faut pas rêver, d'abord c'est assez lent, et ça ne marche pas toujours. M'enfin, les visiteurs de Solutions Linux ont pu le voir marcher assez bien en général. ;-)
Concernant la portabilité, seul IA-32 est supporté pour GNU/Hurd sur Mach. Il faut bien comprendre que le but de cette branche actuellement est de faire qu'un max de gens testent et portent les paquets, etc., etc. IA-32 étant utilisé par le plus de gens, il est logique de la supporter en priorité - et nous n'avons pas les moyens de supporter hurd-ppc, hurd-ia64 ou que sais-je. Pour les courageux - voire téméraires -, le Hurd devrait tourner sur toutes les machines supportées par une implémentation de Mach respectant les interfaces de CMU Mach 3.0 (donc, compatible GNU Mach). Des implémentations existent sur Alpha, Sparc, Sparc64, PowerPC (oldworld seulement). Bon courage ;-)
Le Hurd sur L4 en revanche est développé avec la portabilité en tête, principalement sur PowerPC. L4Ka::Pistachio (l'implémentation de L4 qu'on utilise) lui-même tourne sur un grand nombre d'architectures (Alpha, AMD64, ARM, IA32, IA64, MIPS, PPC32, PPC64, cf. http://www.l4ka.org/projects/pistachio/(...) pour plus d'informations). Il est bien évident que GNU/Hurd a pour ambition d'être un système versatile, flexible, pouvant s'adapter du système "embarqué" relativement évolué (avec MMU, sans quoi ça n'a plus grand sens, donc on est sur de l'embarqué style ordinateur de bord, frigos ;-) aux grosses machines ayant besoin de virtualisation, de domaines, toussa. Et puis, la portabilité était un argument de vente majeur des micro-noyaux, montrons que tout n'était pas faux ;-)