GNU L'année 2010 du Hurd

Posté par (page perso) . Modéré par patrick_g.
59
7
fév.
2011
GNU
Eh oui, le Hurd est encore vivant ! Le Hurd est un projet de noyau pour le système GNU. Le but du projet est de créer un noyau viable, qui convienne pour tous les usages et donne aux utilisateurs autant de pouvoir que possible sur leur système.

D'un point de vue technique, il s'agit d'un système multi-serveur à base de micro-noyau : concrètement, cela veut dire que les services habituellement rendus par le noyau (systèmes de fichiers, réseau, pilotes...) sont implémentés dans des applications normales (en espace utilisateur) qui reposent sur un noyau minimal, GNU Mach.

GNU/Hurd n'est pas encore assez opérationnel pour devenir votre système d'exploitation de tous les jours. Mais il avance chaque année.

Quoi de neuf en 2010, donc ? Au menu : Xen, pilotes de périphériques en espace utilisateur, nouvel installateur pour Debian GNU/Hurd, Arch Hurd ou encore procfs.

Vous pouvez tester par vous-même facilement en utilisant Debian GNU/Hurd ou Arch Hurd, ou en téléchargeant l'image QEmu prête à l'emploi. Vous pouvez aussi consulter la liste des tâches à faire et la liste des bogues sur Savannah, ainsi que la page « Comment contribuer ? ». Quoi de neuf en 2010 ?

Samuel Thibault, notre touche-à-tout préféré, a intégré à la branche principale de GNU Mach le support Xen : vous pouvez dorénavant faire tourner GNU/Hurd comme domU (invité). Cette fonctionnalité est utilisée pour les serveurs de build de Debian GNU/Hurd (buildd), la plupart des machines GNU/Hurd accessibles publiquement et notre wiki.

Zheng Da a, quant à lui, travaillé à la création d'un nouveau système de pilotes de périphériques en user space, basé sur DDE (réalisé par l'équipe de Fiasco, l'implémentation de L4 de l'université de Dresde). Il permet de faire tourner les pilotes les plus récents de Linux comme des processus normaux. D'ores et déjà, de nombreuses cartes réseaux sont supportées. Pour d'autres types de pilotes, comme les contrôleurs de disques durs, il faudra continuer le travail. Le code de Zheng Da est disponible ici ; il n'est pas encore intégré directement au Hurd.

Comme les années passées, le Hurd a participé au Google Summer of Code :
  • Jérémie Koenig a travaillé sur un port du nouvel installateur Debian pour Debian GNU/Hurd. Jusqu'ici, les images de Debian GNU/Hurd utilisaient le vieil installateur Debian, tournant sous GNU/Linux. Cela simplifie grandement l'installation (plus besoin d'un redémarrage supplémentaire). Les nouvelles images sont disponibles ici. Philip Charles, qui maintenait ses images depuis bientôt 10 ans, en a profité pour prendre sa retraite ;

  • Le projet d'Emilio Pozuelo Monfort était de lancer les suites de test de plusieurs programmes (Python, Perl, coreutils...) pour découvrir et corriger les problèmes de compatibilité qui affectent de nombreux programmes sous GNU/Hurd. Son analyse a permis de découvrir de nombreux bogues dans le Hurd et de les corriger.
Jérémie Koenig a également écrit une nouvelle version de procfs (le système de fichier qui fournit /proc), plus robuste et efficace que la version précédente. Cela permet par exemple d'utiliser top sous GNU/Hurd.

D'autres traducteurs (gopherfs, netio, tarfs), écrits par des contributeurs externes, ont été corrigés par Manuel Menal et intégrés à Debian GNU/Hurd. Ce sont de bons exemples de l'extensibilité du Hurd, qui pourront servir de base pour ceux qui voudront créer d'autres traducteurs.

Du côté des distributions, Debian GNU/Hurd continue à avancer : près de 68 % de l'archive Debian est maintenant disponible pour GNU/Hurd. Pendant ce temps, une nouvelle distribution a été créée : Arch Hurd. Beaucoup de paquets sont déjà disponibles et un LiveCD est aussi disponible.

Ce n'est qu'un petit aperçu des avancées du Hurd en 2010. Pour en savoir plus, vous pouvez par exemple consulter les nouvelles publiées chaque mois sur le site du Hurd. En attendant, quelques réponses aux questions que vous vous posez peut-être.

Mach, L4, Coyotos... Est-il question de changer de micro-noyau ?

L'utilisation de Mach comme micro-noyau a fait l'objet de nombreuses critiques : Mach est un micro-noyau de première génération, assez ancien, alors qu'il existe aujourd'hui des micro-noyaux plus récents, encore plus minimalistes, tels que L4, EROS... Un projet de port du Hurd sur L4 a d'abord vu le jour dès 2000 et a pris de l'ampleur en 2005-2006 ; le projet a ensuite évolué vers Coyotos, dont l'interface semblait mieux répondre à certains objectifs du Hurd (en matière de confinement et de sécurité notamment). Ces efforts ont amené Neal H. Walfield et Marcus Brinkmann, deux des principaux auteurs du Hurd, à publier deux papiers de référence en 2007 :En 2008, Neal H. Walfield a commencé le développement de Viengoos, un autre micro-noyau. Viengoos n'a pas vocation à remplacer Mach : c'est un projet de recherche dont le but est d'expérimenter de nouvelles solutions aux problèmes que le Hurd actuel (voir notamment la critique plus haut) a soulevés. Ces solutions pourront ensuite servir à améliorer le Hurd et GNU Mach.

Depuis fin 2009, le projet Viengoos est inactif, du fait de l'indisponibilité de son auteur. Le développement du Hurd continue néanmoins sur Mach — et les idées développées dans la critique pourront être la base de nouveaux développements passionnants du Hurd.

Qu'est-ce qu'il manque au Hurd pour être totalement prêt ?

Bonne question ! De façon générale, il manque surtout à GNU/Hurd d'être aussi stable et performant que GNU/Linux. Il reste beaucoup de bogues à découvrir et corriger, beaucoup de code à optimiser, beaucoup de fonctionnalités à écrire. Tout cela avance, assez lentement, au rythme des disponibilités des uns et des autres.
Plus spécifiquement, des fonctionnalités majeures restent manquantes.

Les pilotes de périphériques actuels du Hurd sont très rudimentaires : il s'agit essentiellement de code de Linux 2.2 intégré rapidement à GNU/Hurd. Il n'y a pas de gestion de l'USB, pas de gestion du son, pas de gestion du SATA, pas de gestion du Wi-Fi (ou alors seulement en PCMCIA, de façon expérimentale). Le projet DDE (voir plus haut) devrait aider de ce point de vue !

Le portage de Xorg, s'il est fonctionnel, a encore quelques problèmes : pas d'accélération du tout (aucun support DRM ou KMS), pas de possibilité de passer de Xorg à la console et réciproquement.

Plusieurs applications importantes ne fonctionnent pas encore : Firefox, Emacs en mode graphique, certaines parties de GNOME (d'autres fonctionnent, comme Gnumeric, par exemple) ou KDE, mplayer, VLC...

Seul ext2 est géré ; un début de gestion d'ext3 existe, mais il n'a jamais été terminé. Certains bogues importants demeurent : le système réagit assez mal quand un système de fichiers est plein et quand la mémoire vive et le swap sont intégralement utilisés...
  • # Prems

    Posté par . Évalué à  -10 .

    Eh oui, le Hurd est encore vivant !

    Tu dis ça parce que tu es énervé.
  • # Minix

    Posté par (page perso) . Évalué à  5 .

    Une petite question pour toi Manuel. Quelles sont les différences entre Mach et Minix ? Il me semble, à lire les infos sur le site de Minix, que ce micro-noyau est plus avancé au point de vue fonctionnalités que Hurd/Mach.
    Pourquoi ne pas réutiliser Minix au lieu de Mach/L4/EROS/Coyotos..etc ?
    Le principal problème de ces projets c'est le manque dramatique de main-d'oeuvre. Choisir Minix cela veut dire regrouper les ressources. En plus Tanenbaum fait bosser ses étudiants dessus donc il y aura toujours une quantité minimale de devs susceptibles de contribuer.
    Ou alors Minix ne convient pas pour des raisons techniques ?
    • [^] # Re: Minix

      Posté par . Évalué à  8 .

      Euh, j'ai peut-être loupé quelque chose, mais la licence de Minix ne semble pas compatible avec la GPL. Un projet GNU pas sous GPL, j'imagine que c'est bloquant, non?
      • [^] # Re: Minix

        Posté par (page perso) . Évalué à  3 .

        Hum tu as raison ça doit bloquer la FSF. Ce serait techniquement possible (Minix est sous BSD) mais ils préfèrent évidemment n'avoir que des composants sous GPL (Mach a même été réécrit pour donner GNU Mach).
        • [^] # Re: Minix

          Posté par (page perso) . Évalué à  10 .

          GNU Mach n'a pas été réécrit — il est dérivé de Utah Mach (réalisé par l'université de l'Utah), lui même venant de CMU Mach (réalisé par la Carnegie-Mellon University, CMU).

          Le code venant de Utah Mach est toujours disponible sous une licence BSD classique. Le code ajouté dans GNU Mach est lui sous GPL : du coup, GNU Mach ne peut être distribué que selon les termes de la GPL (la licence GPL étant plus restrictive que la licence BSD).

          Il n'y aurait donc aucun problème à priori à réutiliser du code de Minix.
          • [^] # Re: Minix

            Posté par . Évalué à  3 .

            Je pense que le frein n'est pas au niveau de la licence mais plutôt dans l'estime des développeurs qui rechignent (globalement) à "repomper" le travail des autres intégralement.

            A part peut-être Apple....
      • [^] # Re: Minix

        Posté par . Évalué à  1 .

        Minix 3 est sous licence BSD.
    • [^] # Re: Minix

      Posté par (page perso) . Évalué à  7 .

      J'avais déjà répondu à cette question ici : http://linuxfr.org/comments/640713.html#640713

      Je pense que tout cela reste vrai. Andrew Tanenbaum n'a pas l'objectif de créer un système qui « dépasse » Unix, mais de faire un clone d'Unix avec une architecture différente : un micro-noyau et des serveurs multiples.

      Il y a sans doute des éléments intéressants à reprendre de Minix — tout comme DDE a été repris du travail sur L4, par exemple. Reprendre entièrement le micro-noyau de Minix nécessiterait une réécriture complète du Hurd, et probablement des modifications dans le code même de Minix : pas sûr que ça se fasse plus rapidement que continuer à débugger et améliorer GNU Mach.
      • [^] # Re: Minix

        Posté par (page perso) . Évalué à  2 .

        Minix, il me semble, essaie de mettre en avant la simplicité du code et du fonctionnement, afin de disposer d'un outil pour l'enseignement. Ce qui ne va pas toujours de pair avec les optimisations faites pour avec un OS efficace.
        • [^] # Re: Minix

          Posté par (page perso) . Évalué à  3 .

          Il est à noter par exemple que minix compte nécessite une IPC pour _chaque_ opération in/out, plutôt que laisser le processus faire ses in/out après demande ioperm().
        • [^] # Re: Minix

          Posté par (page perso) . Évalué à  2 .

          >>> Minix, il me semble, essaie de mettre en avant la simplicité du code et du fonctionnement, afin de disposer d'un outil pour l'enseignement.

          Je croyais que ça c'était pour Minix 1 et Minix 2 mais qu'à partir de MInix 3 le but était de proposer un vrai OS fonctionnel et plus simplement un OS simplifié destiné à l'enseignement ?
          • [^] # Re: Minix

            Posté par (page perso) . Évalué à  2 .

            Mais, jusqu'où acceptent-ils d'aller dans la complexification du code ?

            Peut-être que Tanenbaum continue avec Minix2 pour les cours, et que Minix3 vit sa vie de son côté.
            • [^] # Re: Minix

              Posté par . Évalué à  3 .

              J'avais regardé le code source de Minix 3 à l'époque de sa sortie. Le code est très simple à comprendre. Une des raisons est entre autre l'absence de multithreading. Officiellement c'était parce que « personne ne les utilise sérieusement et efficacement de toute manière ».

              Évidemment c'est une manière bien pratique de dire « nous n'avons pas eu le temps de les implémenter et ça va tout casser si c'est mal utilisé »... :-)
  • # wow

    Posté par (page perso) . Évalué à  -4 .

    \o/
    • [^] # Re: wow

      Posté par . Évalué à  4 .

      Les nouvelles hurd fusent.xml dans tous les sens. o/
    • [^] # Re: wow

      Posté par . Évalué à  5 .

      J'imagine que c'est la disponibilité d'un gopherfs sous Hurd qui t'excite tant ?
  • # Des bonnes nouvelles dans ce monde de brute

    Posté par . Évalué à  -7 .

    Oui, le fait que le HURD continue doucement son évolution est une excellente nouvelle.

    Le HURD est un système qui évolue sur du long terme. Pas comme certains qui sont toujours dans la course à la puissance (j'ai le plus grand nombre de lignes dans mon noyau), ou je sors une release deux fois plus vite que toi !!


    "Patience et longueur de temps font plus que force ni que release"
    • [^] # Re: Des bonnes nouvelles dans ce monde de brute

      Posté par (page perso) . Évalué à  10 .

      >>> Le HURD est un système qui évolue sur du long terme. Pas comme certains qui sont toujours dans la course à la puissance (j'ai le plus grand nombre de lignes dans mon noyau), ou je sors une release deux fois plus vite que toi !!

      Tu as lu le paragraphe qui liste tout ce qui manque dans Hurd ? Pas de SATA, pas de Wifi, pas d'USB...etc.
      Dire que c'est super, que ça évolue sur du long terme par rapport aux autres c'est un peu se foutre de la gueule du monde non ?
      • [^] # Re: Des bonnes nouvelles dans ce monde de brute

        Posté par . Évalué à  10 .

        Comme toutes les technologies dans l'informatique, ces connectiques vont disparaitre un jour ou l'autre. Le Hurd a juste de l'avance, c'est tout.

        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

      • [^] # Re: Des bonnes nouvelles dans ce monde de brute

        Posté par (page perso) . Évalué à  4 .

        Bien que ce ne soit pas précisé, je présume que IEEE 1394 (FireWire), n'est pas non plus supporté. Qu'en est-il des puces ethernet à 1000 Mb/s ?
        Pour les systèmes de fichier, ext3 n'est pas terminé alors que ext4 est maintenant la norme et que btrfs pointe son nez. Je pense que Hurd fera l'impasse sur Reiserfs.

        Hurd n'est pour l'instant qu'un laboratoire, une preuve de concept (anglais : Proof of concept) sans utilité pratique. Mais qui sait, dans quelques dizaines d'années, si Linux partait dans le mur, nous serons peut-être très heureux de trouver les bases pour lui construire un remplaçant à moins qu'un xxxBSD ne vienne lui couper l'herbe sous le pied.

        Les micro-noyaux sont intellectuellement très satisfaisants. Malheureusement, aucun n'a encore montré des performances convaincantes.
        • [^] # Re: Des bonnes nouvelles dans ce monde de brute

          Posté par . Évalué à  10 .

          prototype.

          de rien.

          Sedullus dux et princeps Lemovicum occiditur

          • [^] # Re: Des bonnes nouvelles dans ce monde de brute

            Posté par . Évalué à  2 .

            wikipedia : Un prototype désigne le premier, ou l'un des premiers exemplaires d'un produit industriel (voiture, avion…). Cet exemplaire permet de faire des tests afin de valider les choix de conception de l'ensemble.
            Le prototype précède les exemplaires de pré-série.

            Donc ce n'est pas du tout le cas présent. Mais je ne trouve pas de traduction satisfaisante...
        • [^] # Re: Des bonnes nouvelles dans ce monde de brute

          Posté par . Évalué à  6 .

          Les micro-noyaux sont intellectuellement très satisfaisants. Malheureusement, aucun n'a encore montré des performances convaincantes.
          Ah bon!?! J'ai cru que QNX ( http://en.wikipedia.org/wiki/QNX ), micro-noyau et temps réel était assez utilisé dans l'embarqué...

          Quelqu'un peu confirmer ou infirmer?

          En tout cas, je l'avais installé sur ma machine il y a un peu moins de 10 ans et j'avais été agréablement surpris de la chose.
      • [^] # Re: Des bonnes nouvelles dans ce monde de brute

        Posté par . Évalué à  1 .

        Doucement, doucement, oui, le hurd ne supporte pas les dernières techno de la mort qui tue. Mais cette course aux technos ne vaut la peine que si elle sert à quelque chose. Il faut déployer beaucoup d’énergie pour avoir un système qui supporte (le mot est bien choisie) tout ce fatra. Si le hurd avait les moyens en personnel, il y aurait pléthore d'offre, malheureusement, les moyens se comptent sur les doigts de la main (pas la mienne).
        Le nombre personne qui pense que le micro noyau est un bon concept est énorme, mais de là à passer à l'acte ... Le hurd souffre toujours d'un problème de documentation (ou est le "big picture", où se cache le "codez du hurd pour les nuls" ?).
        Cela fait tout de même plaisir de voir sur ce forum l'agitation pour un système qui n'est qu'un "proof of concept".
        Merci à tous pour ce travail qui ne restera pas sans suite, je fais partie de ceux qui veulent y croire. Dans ce monde où tout est à court (voire ultra court) terme, je suis heureux de voir l'évolution paisible de ce système.
        • [^] # Re: Des bonnes nouvelles dans ce monde de brute

          Posté par (page perso) . Évalué à  7 .

          Doucement, doucement, oui, le hurd ne supporte pas les dernières techno de la mort qui tue.

          SerialATA : 2001
          WiFi (802.11a) : 1999
          USB : 1997

          Je ne sais pas ce que tu entends par "dernière techno", mais on ne doit pas avoir la même définition, la mienne est plus dans le 21è siècle (10 ans déjà qu'on est au 21è siècle)
        • [^] # Re: Des bonnes nouvelles dans ce monde de brute

          Posté par . Évalué à  1 .

          où se cache le "codez du hurd pour les nuls" ?).

          Peut-être que cela pourrait t'aider (je ne pense pas que depuis 2007 les choses ont beaucoup changé à ce sujet):

          http://www.gnu.org/software/hurd/hacking-guide/hhg.html
        • [^] # Re: Des bonnes nouvelles dans ce monde de brute

          Posté par . Évalué à  6 .

          Si le hurd avait les moyens en personnel, il y aurait pléthore d'offre, malheureusement, les moyens se comptent sur les doigts de la main (pas la mienne).
          Oui, si le hurd supportait l'usb et le sata, le hurd supporterait l'usb et le sata.

          Apres qualifier ca de "dernieres techno de la mort", c'est un peu limite, je pense que pouvoir brancher une souris, un clavier et un disque dur, c'est pratique quand meme :)

          Le nombre personne qui pense que le micro noyau est un bon concept est énorme, mais de là à passer à l'acte
          Probablement la raison pour laquelle les 2 os majoritaire sont sur des kernels hybrides :)


          Cela fait tout de même plaisir de voir sur ce forum l'agitation pour un système qui n'est qu'un "proof of concept".
          Yep. Ce qui est dommage, c'est que ca fait 20 ans que c'est un proof of concept.

          Dans ce monde où tout est à court (voire ultra court) terme, je suis heureux de voir l'évolution paisible de ce système.
          Heuuu.... Ouais, enfin, ya un juste milieu quand meme, tu crois pas?

          If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

          • [^] # Re: Des bonnes nouvelles dans ce monde de brute

            Posté par . Évalué à  7 .

            Probablement la raison pour laquelle les 2 os majoritaire sont sur des kernels hybrides :)

            Mmmh... Tu parles de OS X et Windows ?

            Yep. Ce qui est dommage, c'est que ca fait 20 ans que c'est un proof of concept.

            Ça prouve que le concept est solide ! :-D
  • # Enfin des news

    Posté par . Évalué à  8 .

    Ça fait plaisir d'entendre un peu parler de ce bon vieux HURD. Je commençais à croire qu'il était mourant

    Serait-il possible de savoir pourquoi L4 n'a toujours pas remplacé mach? À moins que je n'ai pas saisit quelque chose...
    • [^] # Re: Enfin des news

      Posté par . Évalué à  1 .

      Hello,

      Ouais, ça fait vraiment plaisir de voir que ça avance.
      J'ai vraiment envie que GNU/Hurd remplace GNU/Linux, mais pour ça, il va falloir être patient.

      Merci à Manuel pour son avis objectif.

      Arkem, tout est écris dans la news, au sujet du port L4.

      Content de voir que tu continues à travailler un peu dessus, Manuel.

      +
      • [^] # Re: Enfin des news

        Posté par . Évalué à  6 .

        J'ai vraiment envie que GNU/Hurd remplace GNU/Linux

        Pourquoi ?
        • [^] # Re: Enfin des news

          Posté par . Évalué à  10 .

          Ben pour chasser tous les nouveaux qui ont Ubuntu, une femme et une souris.
        • [^] # Re: Enfin des news

          Posté par . Évalué à  4 .

          Parce que son architecture semble vraiment très puissante.

          Je n'ai pas l'intention de toller.
          Le noyau Linux me sert tous les jours et j'en suis très satisfait.

          Et puis, un peu de diversité dans les noyaux Libres ferait toujours plaisir.
          Ca ne serait pas intéressant, s'il y avait 3 ou 4 noyaux/µ-noyaux Libres 100% fonctionnels et performants ? n*plus de trolls !
          • [^] # Re: Enfin des news

            Posté par . Évalué à  2 .

            > Et puis, un peu de diversité dans les noyaux Libres ferait toujours plaisir.

            Dans les noyaux libres matures, tu as déjà Linux et les BSDs, c'est déjà pas mal!!

            Pense quand même que la critique numéro 1 envers Linux est toujours le manque de pilotes (*) ainsi que les applications (**), *pas* son architecture..
            Et quand je pense aux problèmes d'architecture sous Linux, je pense au manque de sandbox standard, d' "object capabilities", au débat X11/Wayland, tout ces problèmes n'étant pas vraiment résolu par Hurd..


            *: exemple: la 3D
            **: exemple: OOffice très "perfectible"
            • [^] # Re: Enfin des news

              Posté par (page perso) . Évalué à  2 .

              Les problèmes de sandbox et d'object capabilities sont au contraire au cœur même du Hurd, et plus encore au cœur du propos de la critique donnée en lien dans la dépêche.

              Voir par exemple la présentation du serveur d'authentification sur le site du Hurd : http://www.gnu.org/software/hurd/hurd/documentation/auth.htm(...)
            • [^] # Re: Enfin des news

              Posté par . Évalué à  2 .

              Le but quand même d'un micro-noyau, c'est quand même la fiabilité et la sécurité.
              Là où sous linux, ton driver doit être parfaitement écrit pour ne pas cracher ton noyau (ce qui a été contourné par l'inclusion des pilotes dans les sources du noyau pour contrôler la qualité), sur un micro-noyau, lorsque ton driver plante, il est redémarré et c'est reparti.

              Du coup tu peux accepter beaucoup plus de drivers codés avec les pieds (comme sous windows --car si sous windows seuls les drivers de qualité équivalente à ceux inclus dans le noyau linux étaient acceptés, ça serait un OS avec pas beaucoup de support matériel ;) --) sans compromettre ton système.
              • [^] # Re: Enfin des news

                Posté par . Évalué à  5 .

                sur un micro-noyau, lorsque ton driver plante, il est redémarré et c'est reparti

                Ah oui génial.
                Si relancer automatiquement un programme après un segfault permettait de corriger les bugs, ça se saurait.
                J'imagine le pilote de contrôleur disque qui se relance silencieusement après avoir planté, alors que des données ont été corrompues derrière...
                • [^] # Re: Enfin des news

                  Posté par (page perso) . Évalué à  4 .

                  J'imagine que c'est configurable et que ce que cosmocat avait en tête était plutôt le driver graphique où cela a un intérêt (et où la quantité de code et la rapidité du changement ne permet pas d'avoir une aussi bonne fiabilité que les pilotes de disques).

                  « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                • [^] # Re: Enfin des news

                  Posté par (page perso) . Évalué à  8 .

                  Personnellement, j'aimerais bien que quand le pilote du contrôleur USB se vautre lamentablement comme ça m'est encore arrivé sous Linux récemment, ça fasse pas un kernel oops pour me retrouver avec un système inutilisable quelques minutes après. Parce que bon, après tout, je préfère plus avoir accès à mon disque dur externe en USB qu'avoir tout mon système planté.

                  Idem, j'aurais bien aimé que mon système se vautre pas à chaque fois que j'utilisais mon modem interne en même temps que je jouais un mp3. Là aussi, je préfère que le driver son et/ou modem se vautre et basta.

                  Tout ça n'empêche pas qu'un plantage de pilote peut largement compromettre le reste du système - soit parce que c'est le pilote d'un élément critique, soit parce qu'il a les permissions super-utilisateur et peut donc faire beaucoup de conneries (problème de confinement imparfait).

                  Mais j'avoue que j'apprécie que quand le traducteur ext2fs se vautre, mon système parte pas avec. Ca rend les bugs du Hurd nettement plus supportables - et plus faciles à débugger. Bien sûr, je préfèrerais que ext2fs ne se vautre pas du tout : mais un système sans bug, ça n'existe pas, donc s'ils peuvent avoir le moins de conséquences possibles, je prends.
                  • [^] # Re: Enfin des news

                    Posté par (page perso) . Évalué à  2 .

                    ... quand le pilote du contrôleur USB se vautre lamentablement

                    Ca doit faire 6 ans que j'utilise Linux et je n'ai jamais eu de plantage lié à USB (pourtant j'ai branché plusieurs disques, souris, claviers, iPod, iPhone et autres gadgets).

                    j'apprécie que quand le traducteur ext2fs se vautre ...

                    J'ai déjà entendu parler de plantages ext2 ou ext3, mais après une très longue période (plusieurs mois). Je crois qu'une fois (je m'en souviens très mal), j'ai eu un plantage ext3, mais j'étais en train de bidouiller, voir chercher à faire planter ext3.

                    Bref : avoir un OS qui résiste aux plantages, c'est rigolo, mais en pratique (avec Linux), ça semble un peu inutile (pour les pilotes les plus courants dumoins).
                    • [^] # Re: Enfin des news

                      Posté par (page perso) . Évalué à  4 .

                      Tu as bien de la chance que ton USB ne se vautre pas. J'ai régulièrement des problème avec l'USB. D'autre part, quand j'allume ma lampe, ça perturbe un peu l'alimentation de mon disque externe, qui fait alors un reset... et crashe mon noyau au passage avec un déréférencement de NULL... Bien sûr qu'un système qui ne crashe pas c'est mieux. Mais ce n'est pas pour rien qu'à la base on a fait des séparations user/noyau, processus/processus, etc. Il est aussi à noter que beaucoup de bugs inexplicables et rarement corrigés dans Linux sont des problèmes de débordements entre un driver et autre chose...
                      • [^] # Re: Enfin des news

                        Posté par . Évalué à  3 .

                        D'autre part, quand j'allume ma lampe, ça perturbe un peu l'alimentation de mon disque externe, qui fait alors un reset...

                        Euh et c'est la faute de linux ca? Ca c'est un probleme de hardware. Tu peux faire programmer le meilleur systeme du monde si il y a des problemes de hardware il ne pourra pas y faire grand chose si ce n'est (eventuellement) se vautrer avec grace ou comme une loutre bourre.

                        Au passage n'utilise pas XFS avec ce genre de problemes sinon tu auras de tres mauvaise surprise...

                        Pour les bugs USB je n'en ai pas vu depuis longtemps en tout cas pas qui me fasse cracher le systeme. Au passage cela fait bien longtemps que je n'ai pas du plantage kernel et pourtant je suis un peu "bleeding edge" avec des drivers experimentaux xorg et un kernel 2.6.37 mais je n'utilise QUE des drivers du projet, je n'ai strictement rien "closed source" et cela aide pas mal je pense (ah si j'ai aussi une machine de qualite).
                        • [^] # Re: Enfin des news

                          Posté par . Évalué à  5 .

                          :)

                          D'abord tu dis "bla bla bla ... si le hard plante le soft n'y peut rien bla bla", puis "si tu as ce genre de problème hard, choisi plutôt tel soft", comme quoi la couche logicielle a son mot à dire là dedans...

                          D'ailleurs pour preuve les SGBD et les système de fichiers doivent prendre en compte des coupures de courant.

                          Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                          • [^] # Re: Enfin des news

                            Posté par . Évalué à  1 .

                            Amuse toi a utiliser le systeme de fichier XFS avec des possibilites de coupures de courrant. Je te souhaite bon courage car il est repute (et tester par moi meme) que si coupure de courrant avec ce systeme de fichier tu as de tres tres tres forte chance de ne plus avoir aucune possible de recuperation de tes donnees.

                            Oui cela arrive les crash hardware oui les drivers peuvent eventuellement minimiser les consequences mais cela n'empeche que tant que le probleme hardware sera la tout systme meme le plus robuste (style qnx) aura des problemes.
                            • [^] # Re: Enfin des news

                              Posté par . Évalué à  3 .

                              Je ne remet pas en question ton jugement sur la robustesse d'XFS.

                              Par contre pour te donner un nouvel exemple, j'ai eu il y a quelques temps une barette de mémoire qui était défaillante. GNU/Linux s'en sortait mieux que Windows pour ne pas planter lors de l'installation du système, mais si je me souviens bien, depuis la version 2.6.36 ou 2.6.37 Linux est capable de détecter les zones mémoires défectueuses et de les blacklister. Avec cette méthode il deviendrais carrément possible d'utiliser pour de bon ma barrette sans plantage.

                              Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                              • [^] # Re: Enfin des news

                                Posté par (page perso) . Évalué à  4 .

                                Linux est capable de détecter les zones mémoires défectueuses et de les blacklister. Avec cette méthode il deviendrais carrément possible d'utiliser pour de bon ma barrette sans plantage.

                                Il faut que le matériel le matériel le supporte et, en pratique, seulement le matériel destiné aux serveurs le permet.

                                « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                              • [^] # Re: Enfin des news

                                Posté par . Évalué à  2 .

                                Linux s'en sortait mieux que windows avec cette barrete mais avec un autre ou le probleme aurait ete de l'autre cote de la barrete cela aurait ete l'inverse. C'est un comportement connus.

                                Enfin tu ne me sortiras pas de l'idee que une alimentation disque dur foireuse c'est un chouilla different...

                                Pour info j'ai malheureusement connu les deux cas. Pour le DD cela n'etais pas l'alimentation mais le fait que en raison de la gravite il perdait contact avec la carte mere de temps en temps. Vu que le systeme etait principalement en memoire cela ne se voyait pas avant quelques temps et puis il pouvait de temps en temps avoir acces au DD et "ecrire" dessus. Je ne te raconte pas le merdier sur le DD et detectable juste petit a petit. Je ne vois pas comment le moindre systeme de plantage de drivers auraient pu gerer ce "probleme".

                                Niveau probleme hardware je pense en avoir fait pas mal et je pense aussi que globalement la qualite des OS (meme celui que je n'aime pas) est nettement mieux et je pense que c'est tres bien que Hurd s'occupe de ce genre de chose mais bon lorsque en contreparti tu n'as aucun systemes de fichiers journalise dessus cela semble un petit peu bizarre... Aujourd'hui en 2011, on parle encore de ext2 et uniquement ext2 pour ce systeme. Le systeme par defaut de linux aujourd'hui est ext4 et bientot cela sera probablement Btrfs. On parle de DEUX generations de differences avec un enorme travail jsutement fait sur la "securisation" des donnees. Alors ok le drivers peut crasher s'en emporter le systeme et les donnees dans quel etat elles sont?
                                • [^] # Re: Enfin des news

                                  Posté par . Évalué à  3 .

                                  Je n'étais pas dans le débat Hurd vs Linux, juste que le logiciel a une part très importante dans la fiabilité des systèmes. Comme tu le dis un FS transactionnel c'est pas mal pour gérer des déconnexions au pire moments.

                                  Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                                  • [^] # Re: Enfin des news

                                    Posté par . Évalué à  2 .

                                    Et moi je voulais pointer que tu pouvais faire ce que tu voulais avec certains problemes hardware (typiquement celui decrit dans le message auquel je repondais) c'est impossible a corriger car cela n'est pas corrigeable pas du soft. Limiter les problemes c'est bien, avoir la possibilite de redemarrer un driver qui a crasher tres bien mais bon il y a des trucs aussi important dans la fiabilite d'un systeme et personnellement pour moi il est plus important d'avoir une chance de recuperer mes donnees que d'avoir un systeme qui ne se vautre pas au prix d'un risque de corruption accrus de ces dernieres. Mais bon ma problematique n'est pas la meme que celle de mon voisin et je suis tout a fait conscient que pour d'autre personne le systeme est plus important. Tout depend des objectifs.
                                  • [^] # Re: Enfin des news

                                    Posté par . Évalué à  0 .

                                    Oui mais la fiabilité c'est surtout pas de relancer automatiquement un truc qui a planté.
                                    • [^] # Re: Enfin des news

                                      Posté par (page perso) . Évalué à  3 .

                                      Ça dépend surtout de quoi tu parles.

                                      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                                      • [^] # Re: Enfin des news

                                        Posté par . Évalué à  3 .

                                        La on parle du systeme de fichiers. Personnellement mais je sais que je suis bizarre, cela me foutrait les jetons de savoir que ext2 se relance de temps en temps.
                                        C'est peut etre tres utile pour un developpeur de systeme de fichier mais par contre pour un utilisateur lambda je ne suis pas convaincu et comme dit je prefere avoir un systeme qui plante mais un systeme de fichier beton mais la encore c'est un gout tres perso.
                                        • [^] # Re: Enfin des news

                                          Posté par (page perso) . Évalué à  2 .

                                          Ça dérive quand même des pilotes usb qui ne sont pas tous lié à un système de fichier.

                                          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                                      • [^] # Re: Enfin des news

                                        Posté par . Évalué à  1 .

                                        Ben non, ça dépend pas. Relancer le bidule, ça le rend peut-être moins malcommode pour l'utilisateur (qui sinon devrait le relancer à la main), mais ça ne le rend pas plus fiable. Pour le rendre plus fiable, il faudrait supprimer les plantages.
                        • [^] # Re: Enfin des news

                          Posté par (page perso) . Évalué à  4 .

                          > Euh et c'est la faute de linux ca?

                          Ce n'est pas parce que mon disque dur externe se débranche de manière inopinée que le noyau a le droit de crasher...
                          • [^] # Re: Enfin des news

                            Posté par (page perso) . Évalué à  2 .

                            Juste pour que ce soit bien clair: mon disque externe ne contenait que des données, aucun programme ou autre chose du genre dont le système aurait besoin. Juste ce qu'il se passe, c'est que la couche de gestion d'écriture disque ne gère pas le cas où l'utilisateur débranche un disque alors qu'il avait encore des choses à lire ou écrire dessus... Il n'y a pas de raison de ne pas pouvoir gérer ça au niveau logiciel, c'est juste un problème de gestion des requêtes en cours.
                            • [^] # Re: Enfin des news

                              Posté par . Évalué à  2 .

                              Euh je sais pas trop ce que ton disque dur fait mais il m'arrive (un peu trop souvent) d'avoir mon disque dur externe ou la cle usb "d'arracher" par des petites mains... Et bien je n'ai jamais vu le systeme crasher a cause de cela meme si il y a ecriture.

                              A vu de nez je dirais "Bug report" mais je soupconne que cette precision etait de trop n'est-ce pas?
                    • [^] # Re: Enfin des news

                      Posté par . Évalué à  4 .

                      Rien que pour les pilotes graphiques, ça peut être très intéressant. Des pilotes qui plantent au sortir de veille, c'est très courant (pour ma part, surtout avec les propriétaires).

                      Ça ne fait pas forcément planter le noyau, mais pour peu qu'on n'ait pas un autre PC à disposition, on perd tout moyen d'arrêter proprement le système et d'être sûr de ne rien perdre.
                      Pouvoir s'en sortir par un bête rechargement du module, ce serait super.

                      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                      • [^] # Re: Enfin des news

                        Posté par . Évalué à  1 .

                        Pouvoir s'en sortir par un bête rechargement du module, ce serait super.

                        Rechargement de module, generalement c'est pour les modules noyau, donc si ca plante et corrompt de la memoire en espace noyau, t'es mort de toute facon.

                        Avoir juste le minimum en espace noyau (moins de code == moins de bugs == moins de failles de secu == moins de possibilite de tout planter) et le gros du pilote en espace utilisateur permet par contre de s'en sortir juste en redemarrant le pilote.

                        Typiquement sur l'OS dominant, on trouve les pilotes de carte graphique et une partie des pilotes USB qui tournent en espace utilisateur et ca permet de resister fortement aux bugs dans les pilotes de CG (en plus de permettre les mises a jour a la volee sans perdre sa session, etc.).

                        Mais clairement pour l'instant, c'est pas du tout le chemin pris par Linux (on deplace les pilotes X en user-space vers le noyau - meme si l'architecture originale etait a chier et ne permettait pas le changement a chaud de toute facon).
      • [^] # Re: Enfin des news

        Posté par . Évalué à  6 .

        Le pourquoi du non passage a L4 n'est pas du tout explicite. Dire que Hurd avance c'est pas totalement faux mais bon il n'y a quasiment aucun changement dans sa possibilite d'utilisation aujourd'hui par rapport a il y a 5 ans. Meme le systeme de fichier est encore le venerable ext2... Aujourd'hui on parle de BTRFS, Ext4, ZFS, Hammer etc

        C'est un joli projet et je suis tres content qu'il ne soit pas mort et enterre mais bon que de travail il reste a faire.
        • [^] # Re: Enfin des news

          Posté par (page perso) . Évalué à  6 .

          Je pensais avoir été assez explicite, mais peut-être y a-t-il des précisions supplémentaires à apporter.

          L'idée du passage à L4 n'était pas juste de remplacer Mach par L4. D'abord, parce que L4 et Mach ne sont pas comparables : tout ce qui est implémenté dans Mach (la gestion de la mémoire, par exemple) ne l'est pas dans L4, qui fournit des fonctionnalités extrêmement minimales. Il s'agissait donc de réécrire, avec une nouvelle conception, des fonctions essentielles du noyau.

          En travaillant sur le port du Hurd sur L4, Neal Walfield et Marcus Brinkmann, notamment, ont mis en évidence des problèmes et des limites du Hurd et de Mach. C'est ce qu'ils présentent dans la critique (voir plus haut). Ils ont proposé des idées pour une nouvelle architecture qui tente de résoudre ces problèmes, dépassant le Hurd actuel (cf. le second papier plus haut).

          C'est ce sur quoi Neal Walfield a commencé à travailler dans Viengoos. Tout ça est du travail expérimental : on est dans le domaine de la recherche, pas juste de l'implémentation. Il y a des idées très intéressantes, mais ça n'est pas exactement fonctionnel, et ça n'a pas vocation à l'être dans le proche futur.

          L'intérêt d'un port du Hurd, dans sa conception actuelle, sur L4, n'est pas évident — et pas simple, d'ailleurs, les interfaces fournies par L4 étant assez différentes de celles de Mach. Le choix de la plupart des développeurs a été de continuer à travailler sur le Hurd sur Mach — quitte à reprendre des éléments qui viennent du monde L4, comme DDE (pilotes en espace utilisateur).

          Il est possible qu'à terme, un autre micro-noyau que GNU Mach soit utilisé — ou que GNU Mach soit simplement modifié. C'est un choix opérationnel (qu'est-ce qui est le plus efficace par rapport à nos objectifs ?).

          La FAQ traite d'ailleurs de ce point : http://www.gnu.org/software/hurd/hurd/faq/which_microkernel.(...)
          • [^] # Re: Enfin des news

            Posté par . Évalué à  2 .

            À propos de DDE, n'est-ce pas super couteux d'avoir des pilotes en espace utilisateur ? N'y a-t-il pas d'incessants passages noyau <--> utilisateur ?
            • [^] # Re: Enfin des news

              Posté par (page perso) . Évalué à  4 .

              Ils sont incessants, oui, mais ce n'est rien comparé à la lenteur d'un disque ou d'une carte réseau, même SSD. Il faut que ce soit bien pipeliné pour garder un bon débit, c'est tout.
  • # 2011, l'année sans vaporware

    Posté par (page perso) . Évalué à  10 .

    Debian 6 Squeeze est sortie.
    Duke Nukem Forever est annoncé pour Mai 2011.
    Le Hurd est utilisable.

    C'est la fin des vaporwares !

    Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

    • [^] # Re: 2011, l'année sans vaporware

      Posté par . Évalué à  5 .

      Tu oublis la sortie des EFL en V1.0, Ce n'est pas E17 mais quand même.


      Il reste ne manque plus qu'une avancé majeure du projet GNUStep pour faire de 2011 l'année sans vapoware.
      • [^] # Re: 2011, l'année sans vaporware

        Posté par . Évalué à  4 .

        La fête ne saurait être totalement réussie sans Perl 6 et LaTeX 3.
        • [^] # Re: 2011, l'année sans vaporware

          Posté par . Évalué à  8 .

          N'oublie pas Tex π, mais pas sûr qu'on l'ait un jour, celui-là.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: 2011, l'année sans vaporware

        Posté par . Évalué à  1 .

        A vrai dire, ça a l'air de pas mal avancer chez GNUStep aussi!
        D'après ce que j'ai vu au FOSDEM, ils ont même des thèmes "natifs" (gtk/windows), avec la possibilité de réintégrer la barre de menu dans l'application... Et ça avance bien aussi coté Objective-C (que ce soit coté llvm ou gcc)
        • [^] # Re: 2011, l'année sans vaporware

          Posté par . Évalué à  2 .

          Par contre, WindowMaker n'avance plus, il est arrivé.
          • [^] # Re: 2011, l'année sans vaporware

            Posté par . Évalué à  3 .

            Pub: pour ceux qui ne connaissent pas, Window Maker est un gestionnaire de fenêtres à la fois léger, complet (inutile d'ajouter un panneau, par exemple) et ergonomique. Il se configure en quelques clics, sans avoir à recourir à l'édition de fichiers texte.

            Il y a une branche non officielle de Window Maker qui continue à évoluer et a appliqué bon nombre des rustines éparses sur la Toile ou dans les paquets des distributions:

            http://repo.or.cz/w/wmaker-crm.git

            Les changements consistent principalement en des corrections de bogues, mais on trouve également quelques nouvelles fonctionnalités bienvenues comme un générateur automatique de menu ou la maximisation verticale d'une fenêtre sur une moitié d'écran (pratique pour ouvrir deux documents texte côte à côte).

            Les contributeurs réguliers ne sont que trois ou quatre, mais la liste de diffusion est réactive:

            http://news.gmane.org/gmane.compw.window-managers.windowmake(...)

            La branche officielle de Window Maker n'étant plus maintenue, Arch a d'ores et déjà sauté le pas et inclut cette version, gage de qualité.

            Window Maker ne se rendra jamais !
        • [^] # Re: 2011, l'année sans vaporware

          Posté par (page perso) . Évalué à  1 .

          Mouais, les thème sous gnustep(en anglais: vapoware), ça fait des année qu'on en parle aussi
  • # Mauvaise foi ?

    Posté par . Évalué à  3 .

    le système réagit assez mal quand un système de fichiers est plein et quand la mémoire vive et le swap sont intégralement utilisés...

    Moué, je me demande quel système réagit bien quand toute la mémoire et la swap sont occupées…

    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Mauvaise foi ?

      Posté par (page perso) . Évalué à  2 .

      C'est juste. Disons qu'il y a « mal réagir » et « mal réagir ». L'OOM Killer de Linux n'est pas la panacée, loin de là : il fonctionne souvent mal, et le système ne s'en remet pas toujours.

      Mais GNU/Hurd n'a pas actuellement de fonctionnalité similaire à l'OOM Killer, ou plus généralement de moyen de gérer cette situation. Il s'en sort donc plutôt moins bien que d'autres.

      La gestion de cette situation est complexe. Elle renvoie d'ailleurs à des questions traitées dans les deux articles de Neal Walfield et Marcus Brinkmann cités dans la dépêche, pour mieux identifier ce qui est prioritaire pour l'utilisateur et ce qui ne l'est pas.

      Disons qu'il ne s'agit pas tant de mauvaise foi que d'un appel à contributions :-)
      • [^] # Re: Mauvaise foi ?

        Posté par . Évalué à  2 .

        Bonjour, je voudrais poser une question naïve : quel niveau de difficulté/complexité serait de porter des fonctionnalités ou drivers de linux vers Mach/L4/... ? Je pense qu'il sera toujours trop difficile de dupliquer l'effort de code et écrire des drivers pour toutes les nouveautés supportées chaque mois par linux. Aussi, pour que HURD puisse devenir un noyau généralement utilisable, ce serait bien de disposer de quelque chose de similaire à ndiswrapper.
        • [^] # Re: Mauvaise foi ?

          Posté par . Évalué à  1 .

          Encore mieux, utiliser DKMS qui effectue déjà cette tâche sous Linux.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Mauvaise foi ?

          Posté par (page perso) . Évalué à  3 .

          Relis la partie DDE.
          • [^] # Re: Mauvaise foi ?

            Posté par . Évalué à  2 .

            Merci pour le pointeur, j'étais confus à cause de l'histoire sur les drivers de linux 2.2 ! J'espère que l'usb ou le sata arriveront bientôt, afin qu'il soit possible de tester sur une machine récente.
            • [^] # Re: Mauvaise foi ?

              Posté par . Évalué à  1 .

              Pour le tester, on peut aussi utiliser Qemu. Ça revient à télécharger une image et la lancer, aucune installation, et ça marche.
    • [^] # Re: Mauvaise foi ?

      Posté par . Évalué à  4 .

      Mon Amstrad 6128 réagissait très bien à l'époque.

      Bon faut dire qu'il n'avait ni disque dur, ni swap mais après on chipote... /o\
      • [^] # Re: Mauvaise foi ?

        Posté par . Évalué à  4 .

        Oué c'est sûr, même mon DOS 3.30 marchait bien sur ce point-là mais bon, je ne lui faisais pas faire la même chose (notamment pas de virtualisation, ce qui a le plus de chance de mettre mon OS à genou).

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Génération X

    Posté par (page perso) . Évalué à  1 .

    Ça vaut peut être pas le coup de se casser la tête à intégrer X vu que je me demande si X restera une fois la partie graphique extraite ou si il sera pas redispatché
    • [^] # Re: Génération X

      Posté par (page perso) . Évalué à  3 .

      Heu, X est déjà intégré. Les problèmes essentiels actuellement, c'est le passage de X vers du KMS et DRI obligatoires. Et quand bien même X serait remplacé par autre chose, le problème de portage de cet autre chose, c'est justement ces morceaux de drivers qui auront été redispatchés.
  • # Objectif du projet ?

    Posté par . Évalué à  1 .

    Est-ce que quelqu'un est capable de dire si l'objectif de GNU/Hurd est réellement de fournir un système utilisable ou s'il s'agit uniquement d'une plateforme d'expérimentation (comme j'ai pu le lire ici il y a un moment) ?

    Il y a déjà eu des déçus avec XUL Runner, alors autant éviter de nouvelles déceptions aux développeurs qui investiraient du temps sur GNU/Hurd.
    • [^] # Re: Objectif du projet ?

      Posté par (page perso) . Évalué à  5 .

      L'objectif reste d'avoir quelque chose d'utilisable. Il se trouve que quelques développeurs l'utilisent comme plate-forme d'expérimentation, et d'autres développent dedans notamment parce qu'il reste des choses pas trop dures à faire et qui permettent de se donner de l'expérience, cf le gsoc sur la gestion mémoire (au contraire de Linux, où c'est extrêmement difficile de travailler dans la gestion mémoire). Personnellement, des choses en-dehors du Hurd m'ont aidé pour développer des choses dans le Hurd, et des choses que j'ai développées dans le Hurd m'ont ensuite été utiles en tant que savoir-faire en-dehors du Hurd (bricoler dans la glibc, le support TLS, Xen, ...)
    • [^] # Re: Objectif du projet ?

      Posté par (page perso) . Évalué à  5 .

      a) Quel est le lien entre XULRunner et GNU/Hurd ? (C'est une vrai question.)

      b) C'est pénible cette manie de vouloir toujours trouver un objectif à tout. Peut êter que Hurd en a un, mais moi je pense que "parce qu'on peut" est une explication rationnelle et acceptable à l'existence d'un projet (enfin c'est comme ça que je justifie les heures que je mets dans des projets perso pour les abandonner peu après quand j'ai réussis à faire ce que je voulais et que ça ne m’intéresse plus). (C'est un demi-troll.)
      • [^] # Re: Objectif du projet ?

        Posté par (page perso) . Évalué à  6 .

        sans vouloir trop m'avancer :
        a) parce que XULRunner, projet magique de mozilla, l'avenir des RIA (sic) a juste disparu au profit de firefox et donc les développeurs qui ce sont investi dedans se retrouvent lésés (c'est caricatural, grossier, mais ça ressemble je pense)

        b) ben dans ce cas y'a un but : se faire plaisir. Et bien que relisant la question, je suis étonné du début de la réponse. Prend un bol d'air et ça devrait aller un peu mieux ;-)
        Mais la question a au contraire beaucoup de sens, étant donné que Hurd devait être _le_ système d'exploitation de GNU. Mais faute de moyen / résultat, ils se sont rabattu sur linux (en y rajoutant GNU devant...). Donc la question est pertinente. Hurd a-t-il toujours comme objectif l'initial de GNU c'est à dire la fourniture d'un OS libre pour tout le monde, ou est-ce juste un projet de recherche, passe-temps ou autre ?
        • [^] # Re: Objectif du projet ?

          Posté par (page perso) . Évalué à  3 .

          Que serait devenu le Hurd si Linus n'avait pas sorti son noyau en GPL?
          Finalement la poursuite du développement de ce projet et la seule solution pour répondre à cette question (l'autre étant 42).
          Avec des années de recul il est probable que la réponse soit: le projet GNU a eu très chaud.
          • [^] # Re: Objectif du projet ?

            Posté par . Évalué à  4 .

            Hurd/Emacs
          • [^] # Re: Objectif du projet ?

            Posté par . Évalué à  3 .

            Il ne faut pas oublier non plus que le travail sur le Hurd a été retardé car Mach, conçu et développé aux USA, était sur la liste des logiciels non exportables, et que la FSF a passé plusieurs années à attendre que Mach en soit retiré ("très bientôt").

            On peut s'interroger sur la pertinence de ce choix, bien sûr ; mais si le développement du Hurd avait pu commencer 3 ou 4 ans plus tôt, Linus n'aurait peut-être pas bricolé avec son 80386 : il aurait installé Hurd, comme tout le monde.
  • # Pourquoi GNU/Linux ?

    Posté par . Évalué à  -1 .

    "Il manque surtout à GNU/Hurd d'être aussi stable et performant que GNU/Linux."

    Depuis quand GNU/Linux est-il un noyau ? Je connais le noyau Linux, souvent utilisé dans des systèmes GNU/Linux/Xorg/whatelse, mais pas de noyau GNU/Linux.

    Ce terme serait-il du RMS mal digéré ?
    • [^] # Re: Pourquoi GNU/Linux ?

      Posté par (page perso) . Évalué à  5 .

      Non, je pensais bien à GNU/Hurd.

      GNU/Hurd n'est pas un noyau : c'est un système complet. Comme GNU/Linux.

      C'est l'ensemble du système qui reste relativement lent et instable. Une partie est liée à GNU Mach ou au Hurd — une partie est aussi liée au fait que certains logiciels n'ont pas été (complètement) portés, ou que des bugs apparaissent sous GNU/Hurd qui n'apparaissent pas sous GNU/Linux (le problème se retrouve aussi sur les *BSD, mais il y a plus de testeurs, donc ça arrive moins).
  • # Debian… et le reste ?

    Posté par . Évalué à  -1 .

    Il n'y a que Debian qui fasse une distribution de logiciels autour de GNU/Hurd ?
  • # À propos de l'image Qemu

    Posté par (page perso) . Évalué à  1 .

    Bonjour,

    cat README nous apprend que pour se loguer il faut utiliser la commande login ou ql.
    Mais quels sont les logins sur l'image pointée dans la dépèche?

    Merci!
  • # integration du code et binaire linux dans hurd?

    Posté par . Évalué à  1 .

    le truc qui manque le plus au projet gnu est un standard de compatibilité binaire, recompiler du code source non critique au niveau de la performance c'est un peu lourd.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.