Journal Hurd, une si belle idée et pourtant.

Posté par  .
Étiquettes : aucune
0
24
oct.
2006
Non, Hurd n'a tjs pas avancé, Hurd est tjs pas stable, il a même l'air d'avoir de la peine à avancer.

Un journal ça sert à lancer une discussion donc pour ceux qui connaissent mieux le projet que moi, j'ai une question:
Pourquoi donc ce projet ne décolle-t-il pas?

Je vous rassure, je ne viens pas de découvrir le projet, mais qu'elle n'a pas été ma surprise quand j'ai vu que l'annonce par la FSF du lancement du projet datait de... 1991!!!

Le projet est vieux et pourtant aucune entreprise n'a osé se lancer dedans, personne n'en fait réelement quelque chose ,Debian n'est pas une entreprise, et si qqun veut en faire un business, qu'il me dise qui ca m'intéresse.

Le truc c'est que Hurd est vraiment une nouvelle idée. Mon problème avec tous les Unix like c'est qu'en fin de compte ils reprennent une idée vieille de 40 ans. Quand on regarde en arrière, on voit que les OS qui sont sur le marché ne sont en rien révolutionnaire.

La on a un système qui est stable par design ce qui veut dire que nous avons un système qui ne peut, théoriquement, pas complètement planté. On a également plus besoin de redémarrer, on peut utiliser plusieurs versions d'un même driver en même temps et le maintient du noyau est bien plus facile parce que la question est-ce qu'il faut oui ou non implémenter tel ou tel fonctionnalité n'existe pas vraiment. On arriverait dans la même situation que celle d'une distribution. Chacun développe sa partie, chacun est responsable de son code et tout le monde est content.

Conclusion, je n'ai ni les connaissances ni l'argent pour pouvoir réelement aider ce projet mais je crois qu'un système comme celui-là qui viendrait à être utilisable en production serait un gros coup de pouce pour l'open source car, pour la première fois depuis longtemps, l'open source aura devancer la concurrence.


Voila voila, bonne lecture, bon commentaires

  • # Malheureusement...

    Posté par  . Évalué à 9.

    Conclusion, je n'ai ni les connaissances ni l'argent pour pouvoir réelement aider ce projet mais je crois qu'un système comme celui-là qui viendrait à être utilisable en production serait un gros coup de pouce pour l'open source car, pour la première fois depuis longtemps, l'open source aura devancer la concurrence.

    Ca ne serait rien de nouveau, cherches QNX sur Google et tu trouveras un OS qui fait deja quasiment tout cela si ce n'est tout, qui a plus de 10 ans, ... Il est notamment utilise pour certains composants de la navette spatiale, pour gerer des centrales atomiques, ... Bref, un sacre jouet.

    • [^] # Re: Malheureusement...

      Posté par  . Évalué à 8.

      QNX est (était?) vachement léger aussi, la démonstration de "Live-Disquette" à l'époque m'avait pas mal impressionné, une interface graphique, accès internet, browser, le tout sur une petite disquette..

      Aujourd'hui tu ne fais pas booter le noyau 2.6 sur cette même disquette :x

      • [^] # Re: Malheureusement...

        Posté par  . Évalué à 7.

        QNX est toujours (depuis 20 ans et pas 10).De plus en plus car étant au départ un peu plus "ouvert" que maintenant, il à même profité de Linux et bien mieux que "feu" Windriver, le Quick UniX.

        En effet, QNX est comme Hurd basé sur un microkernel, n'ent déplaise à Linus Torvald, je pense aussi que c'est l'avenir car bien mieux structuré qu'un monolithe kernelistique (ou un kernel monolite je sais plus) .
        Seulement voilà, QNX est pleinement POSIX certains s'amusent par exemple à recompiler The Gimp dessus pour le prouver... dans la version téléchargeable. Car il y a la version payante et elle l'est méchament : programmeur de systemes embarqués je me suis renseigné chez QNX pour connaitre le prix d'exploitation du bijou. Il faut savoir qu'en plus des royalties que l'on doit verser sur chaque vente, le prix des licences est exhorbitant.....en plus de la formation obligatoire (évidemment). Malgrè cela il reste, depuis longtemps, la rolls des OS, et non pas pour la killing démo sur la disquette.

        Alors pour revenir à The hurd : je le suit aussi depuis longtemps, et je regrette bien qu'il ne soit resté qu'à ce stade, je pense qu'un jour quelques personnes vont se réveiller et on aura alors tout d'un coup un envollée parceque ce sera le best mieux OS, et je vous promet
        de beaux trolls.....

      • [^] # Re: Malheureusement...

        Posté par  (site web personnel) . Évalué à 2.

        Aujourd'hui tu ne fais pas booter le noyau 2.6 sur cette même disquette :x

        Et si :-)

        J'avais fait un "live-floppy" autour d'un linux 2.6 :
        http://linuxfr.org/~ngc891/17088.html

        Pour le code :
        http://ngc891.blogdns.net/pub/projects/jnuxband/0.2/

        La première version utilisait un 2.6.9-rc2. Je vais peut-être m'y remettre, d'ailleurs.

    • [^] # Re: Malheureusement...

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      euh, quel rapport entre hurd et qnx ? la notion de micro noyau et d'unix ? ah ce moment là minix l'implémenté bien avant QNX mais si c'est certes pas le même état de maturité ...

      De plus QNX est propriétaire, ce qui en fait un "jouet" bien moins intéressant, si tu vois ce que je veux dire ... :p

      M.

    • [^] # Re: Malheureusement...

      Posté par  . Évalué à 1.

      et à la place de ce "jouet" qui contrôle des centrales atomiques et la navette spaciale, pourquoi est-ce que ce n'est pas Windows XP embedded qui a été préféré ?

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: Malheureusement...

        Posté par  (site web personnel) . Évalué à 7.

        Parce que c'est un OS temps réel "dur"?

        http://en.wikipedia.org/wiki/Hard_real-time

        • [^] # Re: Malheureusement...

          Posté par  . Évalué à 2.

          oui et ptetre aussi tout simplement parce que microsoft n'a pas envie de travailler dans cette branche...
          Leur boulot, c'est des os pour les particuliers et le desktop pour le business, pas des systemes ultracritique...

      • [^] # Re: Malheureusement...

        Posté par  (site web personnel) . Évalué à 3.

        sûrement à cause du manque de maniabilité de la souris avec les gants spatiaux en apesanteur ... et puis "Démarrer > Programmes > Atterrissage de la Navette" ... ça fait pas sérieux !

        ^_^

      • [^] # Re: Malheureusement...

        Posté par  (site web personnel) . Évalué à 3.

        Parce que XP n'existait pas à l'époque ;-)

        Par ailleurs, son support s'arrètera avant 2010 ;-(

        Bref, on n'aime ou on n'aime pas les centrales mais on n'aime pas XP !

      • [^] # Re: Malheureusement...

        Posté par  . Évalué à 2.

        Pour la meme raison qui fait que QNX est prefere a Linux.

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 1.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: Malheureusement...

            Posté par  . Évalué à -1.

            Moi je propose que tu lises les article que tu cites :

            Brack said the lab is not centrally managed and therefore lends itself well to using a mix of varied operating systems. Aside from Windows and several flavors of Linux, the lab also runs HP Unix, Mac OS and Solaris, he said.

            ...

            "Our personal view is that Linux, period, is only for the desktop. We don't run our main servers on Linux, because there are too many flaws in main Linux kernel," he said.

            Bref, ils ont du Windows, Linux, Mac, ... et ils n'utilisent Linux que comme Desktop et rien d'autre.

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 6.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: Malheureusement...

                Posté par  . Évalué à -3.

                tu bosses a la nasa toi?
                Marrant, je crois qu'il fallait etre intelligent pour rentrer la bas.
                Ou au moins avoir un cerveau

                Que tu fasses ton guignol sur MS je vuex bien (tu es paye pour)
                hehe, c'est toujours mieux que de faire le guignol contre ms gratuitement, hein.
                'fin j'dis ca...
                lui au moins, il argumente ces propos.
                Pis surtout, il passe pas son temps a regarder ce que font les mecs d'en fasse pour s'empresser d'aller pondre un journal sur windowsfr.org en disant "hé hé hé, zavez vu? en face c'est des cons"

                /me, chaud comme une baraque a frite pendant la canicule en ce moment.

              • [^] # Re: Malheureusement...

                Posté par  . Évalué à 1.

                Eh guignol, si l'article que TU cites dis l'inverse de ce que tu pretends j'y peux rien, choisis mieux tes articles.

                Je me doutes bien qu'ils ont des serveurs sous Linux qqe part comme a peu pres tous les environnements academiques/recherche, je m'amusais simplement a pointer le fait que l'article que tu donnes dis exactement l'inverse de ce que tu pretends.

    • [^] # Re: Malheureusement...

      Posté par  . Évalué à 3.

      Ce n'est pas tout à fait vrai. QNX et le Hurd n'ont pas les mêmes buts. Le Hurd vise principalement à donner plus de libertés techniques à l'utilisateur tout en donnant plus de sécurité au système. Il n'y a pas de translators dans QNX, ce qui limite beaucoup les droits d'un utilisateur.

  • # Pourquoi faire simple quand on peut faire compliqué ?

    Posté par  . Évalué à 6.

    "Pourquoi donc ce projet ne décolle-t-il pas?"

    Parce que ceux qui auraient le talent de le faire ne parviennent pas à se convaincre que ça leur serait utile à quoi que ce soit. J'avoue d'ailleurs à titre personnel ne toujours pas comprendre à quoi "me" servirait quelque chose de plus complexe qu'Unix.

    • [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?

      Posté par  . Évalué à 6.

      D'un autre côté, si on réagit tous comme toi, on fait brûler nos pc et on va chercher nos vieux amstrad dans nos greniers hein.

      • [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?

        Posté par  . Évalué à 5.

        D'un autre autre coté, il a raison.

        Unix marche pas trop mal, que se soit dans son parfum linux ou même (et surtout :)) BSD, donc je ne vois pas
        trop trop pourquoi il faudrait rediviser les "forces" en redevellopant tout les drivers
        et autre userland...

        • [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?

          Posté par  . Évalué à 1.

          Mais justement je trouve qu'on a besoin d'un système mieux qu'Unix auj.
          Les raisons sont:
          1.On entend de plus en plus que le noyau devient difficilement maintenable.
          2.Ca serait clairement un système qui pour les entreprises serait intéressant et pour les particuliers aurait l'avantage d'être plus flexible. Le truc c'est que je vois quelque chose avec un potentiel énorme.

          Disons que je vois dans Hurd le système d'exploitation le plus adapté à la communauté du libre car il est à l'image d'une communauté; un nombre incalculable de donneur de services de part le monde :)

          Je pense également que la raison pour laquelle personne ne s'est lancé là-dedans c'est que personne n'a encore essayé de se faire de l'argent dessus. Je ne sais même pas si dans les universités il y a des projets pour améliorer Hurd? Je sais que le noyau est développé par l'université du Michigan mais à part ça...

          • [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?

            Posté par  . Évalué à 5.


            Mais justement je trouve qu'on a besoin d'un système mieux qu'Unix auj.
            Les raisons sont:
            1.On entend de plus en plus que le noyau devient difficilement maintenable.
            2.Ca serait clairement un système qui pour les entreprises serait intéressant et pour les particuliers aurait l'avantage d'être plus flexible. Le truc c'est que je vois quelque chose avec un potentiel énorme.


            Je ne vois pas hurd decoller dans les 10 ans à venir.

            1°/ Le nombre de personne qui boss sur l'existant est tout bonnement inimaginable...!
            Je suis abonné à plusieur mailing NetBSD, le traffic y est de 100 ou 300 mails environ,
            post par jour, ce qui n'est rien du tout comparé à d'autre liste. Mais même la, le nombre
            de probleme soulevé et traité est enorme. Des truc inimaginable parfois... Sur des trucs
            dont je ne soupsonnais même pas l'existance, même si je suis relativement pauvre
            techniquement, des fois, vraiment, ça va chercher loin... Sur du materiel d'une diversité
            folle, même juste pour l'archi x86...
            Je veux dire par la, la somme de travail pour un projet "petit en communauté" comme NetBSD
            est IMMENSE.

            Alors imagine toi, trouver du jour au lendemain, des gens competent, qui n'ont pas
            peur de bosser "pour rien", créer un truc tout nouveau.

            C'est à dire sans support d'USB, sans support reseau, sans support de quasi
            rien du tout en fait. Donc sans utilisateur. Donc sans une tripoté de beta teseur acharné.
            Je pense que la masse nescessaire à tout ça est deja prise à plein d'autre chose.

            Non, franchement, je ne dis pas jamais, mais c'est pas avant un bon bout de temps
            que le hurd sera pret pour le lamba des informaticiens bidouilleurs. Alors imagine
            pour le monde de l'entreprise...!

            2°/ Tout ça pour quoi...? Pour pas grand chose en fait. Même si Linux le noyau etait 200%
            plus rapide, ton "systeme" ne serais pas 200% plus rapide. Ou alors chez hurd, ils vont
            tout réecrire, du ls à gcc en passant par X et apache...?

            Et même la, le jeu en vaudrait il la chandelle ?

            • [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?

              Posté par  (site web personnel) . Évalué à 6.

              L'intérêt de Hurd tiendrait-il dans une relative augmentation de vitesse par rapport à Linux?
              J'en doute, surtout que les micro-noyaux ont relativement mauvaise presse dans pas mal de situations par rapport à un bon vieux noyau monolithique.

              Ce que je vois de plus intéressant, c'est ce système de micro-noyau qui ne fait que l'essentiel, qui est donc théoriquement plus facile à maintenir, permettant à tout un chacun de rajouter des greffons dessus sans forcément compromettre la stabilité du système dans l'ensemble.

              Un système peut-être plus facile à appréhender intellectuellement qu'un Linux par exemple, où le ticket d'entrée pour maîtriser le noyau et tout ce qu'il met en jeu est relativement élevé.

              • [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?

                Posté par  . Évalué à 3.

                1.On entend de plus en plus que le noyau devient difficilement maintenable.

                puis,
                Ce que je vois de plus intéressant, c'est ce système de micro-noyau qui ne fait que l'essentiel, qui est donc théoriquement plus facile à maintenir


                de totue evidence, cette question est la plus importante a tes yeux, mais j'aimerai que tu soit plus explicite, ou est-ce qu'on entent de plus en plus que ce noyeau devient difficilement maintenable à la fin ?
                J'en ai jamais entendu parlé moi. et en tout cas pas par des personnes qui justement le maintiennent...
                T'as des infos a ce sujet ? ou des liens par exemple ?

          • [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?

            Posté par  (site web personnel) . Évalué à 3.

            Mais justement je trouve qu'on a besoin d'un système mieux qu'Unix auj.
            Les raisons sont:
            1.On entend de plus en plus que le noyau devient difficilement maintenable.

            De quel "noyau" ou variante d'Unix veux-tu parler?
            Linux? FreeBSD? NetBSD? OpenBSD? ... Minix?

            En ce qui concerne par exemple le dernier, j'ai quand même des doutes qu'on le qualifie de "difficilement maintenable" ;-).
            Ou alors faut se préparer à une belle "flamewar" avec Tanenbaum ;-).

          • [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?

            Posté par  (site web personnel) . Évalué à 2.

            la raison pour laquelle personne ne s'est lancé là-dedans c'est que personne n'a encore essayé de se faire de l'argent dessus.
            Le micro noyaux Mach+des bouts de BSD , y'a pas déja des gens qui ont essayé d'en fait un Unix user-friendly ?
            http://fr.wikipedia.org/wiki/XNU

      • [^] # Re: Pourquoi faire simple quand on peut faire compliqué ?

        Posté par  . Évalué à 1.

        Je n'irais pas jusque là : à titre tout à fait personnel et ça n'engage que moi, l'intérêt de savoir faire tourner quelque chose ressemblant à Unix sur un processeurs 32 bits économique doté d'une MMU m'a toujours semblé évident. Maintenant, si on me demande mon avis, je ne suis pas sûr que le x86 était le meilleur choix, mais bon : ça restait jouable. Après ça, quand on regarde le temps que passe un 32 bits à calculer des adresses dans les plages mémoire communément employées de nos jours, on se dit effectivement que s'il n'y a pas moyen de coder les applis qu'on a autrement qu'en consommant autant de mémoire, le 64 bits est certainement une bonne idée mais là, chuis largue.

  • # En même temps Linux...

    Posté par  (site web personnel) . Évalué à 10.

    Linux n'est plus monolithique comme à son début : grâce aux modules. On peut donc recharger une partie du noyau à chaud. Linux est très stable. Il y a 3/4 ans, ça m'arrivait de voir des "Kernel oops", mais maintenant plus jamais. Je parle d'un vrai plantage du noyau (quand il écrit tous les registres du CPU). Linux supporte tout et n'importe quoi niveau matériel (c'est plutôt le contraire pour Hurd). Linux est rapide et très largement testé sur des architectures minimalistes (sans MMU avec très peu de RAM) ou gigantesques (gros cluster / super-méga-gros calculateur). Beaucoup d'algorithmes du noyau sont vraiment très optimisés pour corriger un cas précis (monté en charge), mais finalement mis bout à bout, on sent la différence du côté utilisateur. La dernière grosse inovation que je lui connaissance est la possibilité de s'interrompre lui-même :-) (truc "préemptif" pour le multimédia).

    Si Hurd ne décolle pas, c'est sûrement qu'il n'y a pas assez de développeurs et qu'ils passent plus de temps dans des discussions interminables qu'à coder. Je sais pas, mais j'ai l'impression que tous les ans ils remettent tout à plat... Après avoir *enfin* réussi à se décider de quitter le micro-noyau Gnu Mach (qui était vraiment vieux, genre années 70 je crois) pour L4... ben ils parlent de quitter L4. Merdeu, il faudrait savoir ce que vous voulez :-)

    On parle souvent de Linux, mais l'autre noyau qui a l'air vraiment très intéressant, c'est celui de FreeBSD !
    http://linuxfr.org/~grom/22938.html

    Haypo

    • [^] # Re: En même temps Linux...

      Posté par  . Évalué à -4.

      linux plante toujours aussi lamentablement quand un dd (pas forcément celui systeme) a un probleme matos et qu'il fait un reset ...

      • [^] # Re: En même temps Linux...

        Posté par  . Évalué à 2.

        C'est faux : j'ai une machine pour regarder la TV (P120) que je boote, ça lance xawtv en plein écran, puis j'éteins le disque dur avec la clé de rack où il est. Et là je peux regarder la TV dans le silence absolu (pas de ventilos dans la machine). Et Linux m'a jamais planté dans cet état là, qui est assez bourrin.

        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

        • [^] # Re: En même temps Linux...

          Posté par  . Évalué à 2.

          8-0

          couillu l'caribou, couillu...

        • [^] # Re: En même temps Linux...

          Posté par  (site web personnel) . Évalué à 6.

          Ce serait pas moins bourrin et un peu plus "hardware-friendly" d'utiliser hdparm plutôt ? (simple question de curiosité hein)

          • [^] # Re: En même temps Linux...

            Posté par  . Évalué à 2.

            Oui mais non : un disque en veille consomme plus qu'un disque débranché ;-)

            Pour info, si ton pilote IDE est chargé comme comme un module, tu peux faiure du hot-plug IDE en déchargeant / rechargeant le pilote. Mais là, vaut mieux pas avoir / sur un disque IDE ;-)

            ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

        • [^] # Re: En même temps Linux...

          Posté par  . Évalué à 2.

          euh je parle d'un vrai reset, cad quand il a une belle erreur dma et qu'il était en train de faire une requete.
          Un dd ne reset pas comme ca pour faire plaisir.
          Et si c'est si faux que ca, (et je pose la question a TOUS les moinsseurs )
          Tu peux m'expliquer pourquoi :
          1°) j'ai paumé 10h ce samedi parce que j'avais un dd qui me faisais un reset quand on utilisait trop le dma, ce qui avait comme effet de freezer le noyau (meme si ce n'est pas le dd systeme)
          2°) pourquoi quand tu fais une requete nfs , que tu la monte sans option particulière, et que tu enleve le cable alors qu'une appli utilise le nfs, tu ne pourras plus rien faire avec ton appli (non meme pas la tuer)
          .Faudra attendre que le nfs envoie les données à l'appli pour que ca se remette a marcher.

          Et avant de me dire 'c'est faux c'est ton noyau qui est pas bon' j'ai essayé ce we avec un noyau 'classique' (le 2.6.12 venant de base avec ma deb) avec un 2.6.17 'vanilla' et un 2.6.18 - real time ...
          Ben les trois me pété dans les mains quand mon dd faisait son reset.

          Encore une fois un reset c'est un VRAI reset, au cours d'une requete, c'est pas arreté un disque quand on ne l'utilise pas (et pour cela hdparm -y ton_dd est préférable)

          Essaie de faire la meme chose en plein lancement de ton xawtv (avant qu'il soit en mémoire) et donne moi les nouvelles ;)

          • [^] # Re: En même temps Linux...

            Posté par  . Évalué à 1.

            et que tu enleve le cable alors qu'une appli utilise le nfs, tu ne pourras plus rien faire avec ton appli (non meme pas la tuer)

            ya pas un timeout ou equivalent dans les options de montage nfs?
            ca peut etre une piste, j'ai deja experimente ce genre de pb.

            Quand au fait de ne pouvoir tuer l'appli, j'ai eu la meme chose avec des dvds foireux (disque mort) ou un disque dur a la rue (taquet de secteurs deffectueux).
            Faut attendre un certain temps (long. surtout quand t'es comme n con devant la console a faire ctrl c ctrl c ctrl c kill -9 kill -9) pour qu'il accepte de killer.

          • [^] # Re: En même temps Linux... est un LL

            Posté par  (site web personnel) . Évalué à 2.

            Réponse classique à un problème complexe :
            Report the bug.

            Un bug reproductible, identifiable, qui embête le monde et qui fait planter tout, c'est à mon avis LA chose à faire quand ça arrive.

            Alors ça prend 10 minutes (voire plus), faut assurer un suivi derrière, mais ça peut aider des milliers (au moins :) de personnes derrière toi.

            À mon avis, c'est aussi à cause de ça que Hurd n'avance pas à la vitesse de croisière. Peu de contributeurs, peu d'utilisateurs, peu de feedbacks, peu d'amélioration, peu d'utilisateurs, peu de developpeurs, peu de fonctionalités, peu d'utilisateurs, peu de feedback, beaucoup de problèmes, peu d'utilisateurs ...

            Si ya bien une chose à faire pour faire avancer le Gnou, c'est d'en mettre un chez soi ...

            • [^] # Re: En même temps Linux... est un LL

              Posté par  . Évalué à 1.

              Je doute que ce probleme ne soit déja pas remonté
              Le problème est archi connu , c'est exactement le meme type de probleme qu'en nfs.
              La seule possibilitée serait de redémarrer le systeme dma - ou faire un watchdog sur les requetes dma - Loin d'etre simple, et surtout avec un surcout non négligeable.
              (et puis je t'avouerais qu'actuellement j'ai autre chose à faire que de faire un bug report, d'autant plus qu'il ne suffit pas de 'lancer gdb et récup la trace' vu qu'il n'y a PAS de trace, il ne peut plus faire d'i/o donc ...)
              Mais bon je regarderais ca un peu plus en détail t'inquiète ;)

              Pour kraman, oui il y a une option timeout en nfs, c'est pour ca que j'ai dis 'que tu la monte sans option particulière' ;)

              • [^] # Re: En même temps Linux... est un LL

                Posté par  . Évalué à 3.

                A mon avis, sans cette option (montage soft) le comportement de NFS est voulu (montage hard, par défaut).

                Tu peux retirer le câble, l'appli va bloquer, et quand tu rebrancheras elle reprendra au même endroit comme si de rien n'était. Ce qui peut-être utile dans certains cas.

                Si tu veux une erreur I/O et donc que l'appli s'arrête dès que la connexion est perdue il faut le demander explicitement au montage.

              • [^] # Je m'y colle...

                Posté par  . Évalué à 3.

                c'est pour ca que j'ai dis 'que tu la monte sans option particulière'

                Ben pourquoi tu ne l'utilise pas alors ?

                "Ouais, tu te rends compte, il a sauté sans son parachute, et ben à la fin son parachute ne s'est pas ouvert, il s'est crashé en bauté, c'est trop nul..." :)

                • [^] # Re: Je m'y colle...

                  Posté par  . Évalué à 2.

                  peut etre tout simplement pour montrer un cas facilement reproductible sur ce probleme , et un bon exemple du meme probleme que l'on peut avoir avec un dd, car 'l'option magique' de nfs n'existe pas dans le dma ?
                  peut etre tout simple que quand je monte un nfs en vitesse pour faire des tests j'ai autre chose a faire que me taper le man pour trouver 'la bonne option qui vas bien' ?

                  En outre je vois pas en quoi le fait d'etre médisant fait avancer le schimblick, mais visiblement faut etre agressif pour paraitre intelligent ...

      • [^] # Re: En même temps Linux...

        Posté par  . Évalué à 3.

        J'ai un disque dur qui plante sur mon serveur perso (il ne répond plus au bout d'un certain temps, genre deux semaines - je suis un malheureux early adopter d'un Diamond Max 10 couplé a du Nforce4).

        Et bien linux se porte comme un charme, bon certes tous les processus demandant un accès disque se bloquent en attente d'I/O (un brin emmerdant) mais a part ca tout fonctionne.

        • [^] # Re: En même temps Linux...

          Posté par  . Évalué à 2.

          sauf que quand il reset c'est du a une requete dma (chez moi en tout cas). Donc c'est le kernel qui attend les io la, pas que les applis ...

    • [^] # Re: En même temps Linux...

      Posté par  (site web personnel) . Évalué à 10.

      Linux est toujours monolithique en ce que tous les pilotes (entr autres) tournent en mode noyau. Donc plantage pilote => plantage kernel.

      • [^] # Re: En même temps Linux...

        Posté par  . Évalué à 1.

        Ca c'est ce que disent les gens qui disent ce que leur dit (to win the yes against the no :)

        En fait la plupart des bugs de modules sont invisibles pour l'utilisateur. C'est déjà assez rare que dans ce cas le module soit "planté" et de là à ce qu'il plante le reste du noyau y'a une marge. Attention je dis pas que c'est impossible, le driver ayant accès à tout l'espace d'adressage du noyau, il peut toujours tout faire merder.

        Par exemple j'ai un noyau patché avec le patch Realtime de Ingo Molnar, et mon driver de carte son le supporte pas au mieux. Assez souvent un bug du driver module doit me faire relancer mon application. De temps en temps, ma carte son n'est plus utilisable et je dois rebooter.

        A lire troll sur troll les gens ont un peu trop l'habitude de faire l'erreur de raisonnement:
        théoriquement ça peut planter => ça marche pas du tout

        Théoriquement, il y a une bonne probabilité pour qu'à chaque accès mémoire, tu doivent recharger une ligne de cache et perdre plus de temps que s'il n'y en avait pas. C'est vraiement de la merde les caches, on devrait les supprimer.

    • [^] # Re: En même temps Linux...

      Posté par  (site web personnel) . Évalué à 1.

      Attention quand même à ne pas trop simplifier. Les architectures micro-noyaux c'est pas simplement pour faire modulaire. Y'a des idées qui vont un peu plus loin. Certaines perspectives offertes par Hurd sont alléchantes et difficilement réalisables dans linux. En particulier, un des objectifs consiste à offrir le maximum de liberté aux utilisateurs sans risquer de dégrader la sécurité de l'ensemble (chaque user restant bien cloisonné).

      En même temps, l'un des trucs géniaux de Hurd était la possibilité à l'utilisateur de rajouter lui-même ses devices (genre FTPfs ou NFS). Avec fuse, Linux a comblé son retard "théorique" :-)

    • [^] # Re: En même temps Linux...

      Posté par  . Évalué à 1.

      et bien moi, j'ai régulièrement des plantages complet de ma machine avec le driver wifi rt61, plantage que je n'avais pas avant...

  • # Parallélisme, nouveau défi

    Posté par  (site web personnel) . Évalué à 3.

    Depuis quelques années, on assiste à la généralisation des puces multicoeur. En effet le nombre de transistors que les nouvelles finesse de gravure permettent de caser sur un bout de silicium impose aux fondeurs de mettre plusieurs processeurs par coeur, en ayant beaucoup trop pour faire un seul coeur qui serait extrêmement complexe et chauferait trop.

    Cela risque de se généraliser, dixit intel themselves (aller, au hasard : http://www.x86-secret.com/popups/articleswindow.php?id=125 ) avec des architectures masivement multicoeurs.

    Le problèm est que le niveau technique des programmeurs pour gérer le massivement multi thread ne va pas évoluer exponentiellement lui.

    Et les archi d'Os actuelles vont rapidement trouver leur limite (ceux qui me connaissent vont comprendre, "suivez mon regard", oui je sais, mais mon propos n'est pas de défendre ma crèmerie, simplement de faire un constat).
    Ils ont à mes yeux deux défauts :
    - Ils sont basés sur une architecture paginés, même pas segmentée, mais paginée. Hors une archi paginée tue le parrallélisme : elle oblige à passer très souvent par le noyau, avec tous les problèmes que cela comporte.
    - Ils sont essentiellement architecturés pour être procéduraux et ne permettent le fonctionnement de logiciel émergent (architecture Com/Dcom et maintenant .Net chez kro, et Kpart chez Kde) que par l'intermédiaire de bidouille plus ou moins "crade".


    Alors Hurd ? Ben j'y crois pas.
    Le problème du Hurd est que son micronoyau possède peu d'info, et qu'il a donc du mal à optimiser.
    Et en plus c'est encore écrit dans un langage à pointeur ce qui le rend amha trop complexe à gérer.

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Parallélisme, nouveau défi

      Posté par  (site web personnel) . Évalué à 4.

      Puisque tu ne dis pas, je me lance ;-)

      Il est clair que le Hurd est intéressant mais ne décolle pas. D'un autre coté, l'informatique a bien évolué depuis 15 ans. Quittes à faire autre chose, autant le faire dans un autre langage que le C qui montre quand même ses limites aujourd'hui.

      Pourquoi pas dans un langage à prototype qui parait très bien adaptés à la problèmatique. Pourquoi pas en Lisaac ?

      Bon, pour faire cela, il faudrait que l'INRIA joue pour une fois vraiment le jeu de l'opensource avec IsaacOS. L'INRIA a une carte à jouer, c'est à elle d'abattre son jeu si elle souhaite pouvoir un jour remplacer sur nos postes le système Linux. Mais qu'elle ne traine pas trop !

      • [^] # Re: Parallélisme, nouveau défi

        Posté par  . Évalué à 2.

        Alors je suis allé voir sur wikipedia pour IsaacOS.
        A lire le petit explicatif ça a l'air pas mal mais je ne suis pas sûr de comprendre comment ça marche. Si j'ai bien compris il n'y a pas de noyau mais il y a des objets qui cohabitent. Je ne comprends juste pas comment ça marche, c'est à dire qui décide quel est le niveau de sécurité de chaque objet? C'est un objet?

        Sinon c'est vrai c'est intéressant. Affaire à suivre également

        • [^] # Re: Parallélisme, nouveau défi

          Posté par  (site web personnel) . Évalué à 4.

          En gros, c'est un OS constitué d'objets indépendant capables de gérer un héritage dynamique. Tous les objets dialoguent par envoi de message. Tout objet est nommé dans le système.

          Ca veut dire que Inode peut hériter de Controleur_DD ou controleur_USB, comme ça quand tu fais des appels vers le parent, ça va au bon endroit.

          Le noyau est "émergent" : tu as quelques objets "noyau", le sheduler, le gestionnaire mémoire, et comme ils ont tendance à naturellement communiquer en permanence, ça forme un noyau.

          Pour la sécurité, pour le moment, il n'y en a pas. Ca sera aux futur devs de IsaacOs de se préoccuper de ce genre de chose.

          « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

        • [^] # Re: Parallélisme, nouveau défi

          Posté par  (site web personnel) . Évalué à 2.

          J'y pense : tu trouveras un papier synthétique sur ce qu'est IsaacOS : http://isaacos.loria.fr/papers/cfse4.pdf

          « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Parallélisme, nouveau défi

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        >Il est clair que le Hurd est intéressant mais ne décolle pas.
        moi je le vois évoluer tous les jours, dernièrement un dev à fait fonctionner du pcmcia et du wifi ....

        >Quittes à faire autre chose, autant le faire dans un autre langage que le C qui montre quand même ses limites aujourd'hui.

        tu peux expliquer ? que conseille tu comme langage pour programmer un OS ?

        >Pourquoi pas dans un langage à prototype qui parait très bien adaptés à la problèmatique. Pourquoi pas en Lisaac ?

        moi je veux bien, mais lisaac il fait comment pour écrire dans les regsitres de ton controlleur scsi ? je voudrais bien voir le code en lisaac qui fait ça ... et si c'est pour le faire direct et avoir un accès en ring 0, ça doit être beau... si c'est pas le cas il faut bien un noyau même petit ou simili pour faire l'interface sécursié entre le userland et le hardware ...

        alors issacos c'est bien joli mais moi hurd, je le démarre et je peux faire l'irc avec, isaacos, je demande à voir ... et puis hurd pêche par le nombre de dev mais même si isaacos est le truc conceptuel le meilleur du monde si les dev ne sont pas intéressés par le langage et par porter des applications dessus ça ne décollera pas plus voir même jamais ...

        M.

        • [^] # Re: Parallélisme, nouveau défi

          Posté par  (site web personnel) . Évalué à 3.

          moi je le vois évoluer tous les jours, dernièrement un dev à fait fonctionner du pcmcia et du wifi ....
          Heureusement, ça fait tou même 15 ans qu'il existe !

          tu peux expliquer ? que conseille tu comme langage pour programmer un OS ?
          Lisaac puisqu'il a été principalement conçu pour ça.

          http://isaacos.loria.fr/download/Lisaac_RM_02.pdf
          Page 48.

          En gros l'astuce consiste à inliner du C dans une section INTERRUPT (qui sera donc compilé en fonction), et quitte à inliner du C, inlinons directement de l'ASM.

          En particulier pour une interruption tu ouvres une section __BEGIN_INTERRUPT__

          Tout l'IsaacOs a été codé comme ça, et sont écris en Lisaac le driver du controleur disque, le driver vidéo, clavier, souris, etc...

          Pour ce qui concerne la sécurité, l'OS est conçu pour utiliser les 4 ring des processeurs intel, mais ça n'a pas été implémenté pour faciliter le port sur des processeurs sans ring.

          Tu trouveras toutes les explications ici :
          http://isaacos.loria.fr/papers/cfse.pdf

          alors issacos c'est bien joli mais moi hurd, je le démarre et je peux faire l'irc avec, isaacos, je demande à voir ... et puis hurd pêche par le nombre de dev mais même si isaacos est le truc conceptuel le meilleur du monde si les dev ne sont pas intéressés par le langage et par porter des applications dessus ça ne décollera pas plus voir même jamais ..
          Ce sont des OS qui n'ont pas du tout le même age, et le deuxième n'est pas encore libéré, rien n'est comparable.

          On en reparle dans deux ans !

          « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Parallélisme, nouveau défi

        Posté par  (site web personnel) . Évalué à 10.

        On a l'autorisation de libérer IsaacOS, mais le compilateur nouvelle version totalement réécrit allant arriver bientôt, on s'occupe d'abord de lui, pour ensuite veiller à ce que l'on réussisse à recompiler IsaacOS avec ce nouveau compilateur (syntaxe un peu changé, quelques subtilités dans le système de type aussi, etc...).

        Donc comme on aime faire bien les choses, on le fera quand le compilo fonctionnera bien, que la doc de la lib sera faite, et surtout qu'on réussira à faire tourner IsaacOS dans un qemu, le tout dans un distrib assurant au dev d'être à l'aise.

        Je suis contre (et Benoit aussi) le fait de lancer dans la nature un Os qui compile pas, avec une lib pas documentée, etc... Ca donnerait une très mauvaise image au projet qui raterait ainsi son décollage.

        Tout cela étant dit, je pense que ça sera prêt dans moins de 6 mois (j'espère) :)

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # lisaac

        Posté par  . Évalué à 2.

        je trouve qu'ils ont un choix de lunettes un peu restreint

    • [^] # Re: Parallélisme, nouveau défi

      Posté par  . Évalué à 2.

      Il y a sans doute quelque chose qui m'echappe, mais en quoi une architecture paginée tue le parellelisme, et quels sont les problèmes qui en découlent ?

      Amha :

      - C'est les architecture memoire des machines qui sont basées sur la pagination, l'os ne fait que s'adapter. La majorité des problèmes se trouvent au niveau hardware (synchronisation du/des cache(s))

      - La pagination permet d'offrir un espace d'adressage propre à chaque processus, et je vois mal comment faire du parrallèlisme sur sans cet espace d'adressage unique.

      - Quelque soit l'os (considéré comme preemptif), on passera toujours par le noyau pour gerer l'ordonnancement et la priorité des processus (c'est son role !), un ou n processeurs embarqués sur la machine ne changent rien à cet etat de fait. La contrainte introduit par la pagination sur l'os est le comportement à adopter en cas de defaut de page, et ça releve plus d'une insuffisance matérielle (pas assez de memoire) que d'un defaut de conception de l'os.

    • [^] # Re: Parallélisme, nouveau défi

      Posté par  (site web personnel) . Évalué à 3.

      Pour ce qui est du multi-coeur, j'ai vu l'autre jour un waffer expérimental de chez Intel : 80 coeurs, 1 terraflops sur une puce !

      Le temps que la R&D finisse tout ça et on aura ça dans nos machines. A priori, même pour les machines bas de gamme, ce sont les processeurs mono-coeur qui vont se faire rares d'ici quelques mois.

    • [^] # Re: Parallélisme, nouveau défi

      Posté par  . Évalué à 1.

      J'ai lu récemment le dernier troll Tanenbaum vs. Linus, et sur ce coup là, Linus a largement gagné :)

      Une bonne question aux aficionados des micronoyaux est "comment allez vous donner un accès matériel ala DRM/DRI aux applications ?"

  • # La cathédrale et le bazar

    Posté par  (site web personnel) . Évalué à 8.

    Je ne suis pas certain que GNU/Linux, soit le meilleur SE libre possible. Je ne suis même pas certain (voire plus haut) que le couple C/UNIX soit addapté aux évolutions du hardware et des moeurs (notamment en ce qui concerne les particuliers).

    Mais au delà de ces questions naturelles, il reste que Linux a su créer l'émulation nécessaire pour attirer, développeurs et utilisateurs et être aujourd'hui à même d'assurer des performances correctes et un excellent support du materiel.

    Cela Hurd n'a pas su le faire. Et tout projet Libre, aussi génial soit-il qui ne saura pas développer un minimum d'entousiasme sera fatalement condamné à rester dans sa tour d'ivoire.

    Lire ou relire la cathedrale et le bazar.
    http://www.linuxfr-france.org.invalid/article/these/cathedrale-bazar/c(...)

    • [^] # Refaisons le monde

      Posté par  . Évalué à -1.

      Intuitivement je me dis qu'un bon modèle d'OS de dans 30 ans sera une sur-couche a Unix.

      On est toujours obligé de créer des composants bas-niveau pour les assembler et en faire de plus haut niveau et ainsi de suite. Les systèmes me parraissent pas mal comme couche la plus basse. Evidemment, je parle là du noyau et des quelques outils annexes qui servent à le faire tourner.

      Les parties avec lequel on interragit en temps que end-user (X/Gnome) vont devoir évoluer et démultiplier leur nombre de couche avant d'arriver à une interractivité plus humaine.

  • # Et pourquoi pas !!!

    Posté par  . Évalué à 6.

    Oui hurd est un "vieux" système, oui, cela fait longtemps que ses développeurs réflechissent (pour ne pas dire se frite) a son évolution.
    Que voit on aujourd'hui, les même fonctionnalités qu'il y a plus de dix ans en informatique :
    - la gestion des I/O de plus en plus lourde (les gestionnaires de volumes logique au dessus des disques physique)
    - les machines avec plusieurs CPU (tient comme au temps des mainframe)
    - les hyperviseurs (encore comme au bon vieux temps des mainframe).

    Alors, hurd, vieux ? Cela ne veux rien dire, par contre, la souplesse apportées par hurd, sa "légèreté", sa petite empreinte mémoire (à comparer avec le monolitique mamouth noyau Linux.
    Oui il faudrait des développeurs, mais qui peut se lancer dans du développement de noyau ? Pas moi, et pas grand monde parmis les nombreux lecteurs de ce petit message. Pourquoi les entreprises privées, celle qui développe le noyau Linux ne s'y mettent-elles pas (precisément parcequ'elles ont choisit Linux). Reste la communauté, la vraie, qui pourrait faire émerger ce système que beaucoup de monde attend. Avec l'avénement des multi coeurs, de la virtualisation, Hurd a sa carte à jouer, ne voit on pas, parmis les plus gros calculateurs de cette planète, des machines qui fonctionne avec un micro-noyaux !!
    L'avenir est devant nous, et nous y tourneront le dos, à chaque fois que nous regarderont le passé. Ne tournons pas le dos à notre futur, et vive les micro-noyaux.

    • [^] # Re: Et pourquoi pas !!!

      Posté par  (site web personnel) . Évalué à 4.

      Je suis de ton avis : il ne faut pas repprocher à Hurd d'être vieux. Ce n'est pas un problème en soi.

      Maintenant, comme cela a été dit plus haut, le principal problème de Hurd (à mon avis) réside dans le fait qu'il n'arrivent pas à stabiliser leur couche basse. On ne peut pas attirer des bonnes volontés en disant qu'il faut développer Hurd sur gnu-mach mais que bientôt on passera à L4 ou autre. Je pense que les bonnes volontés ont besoin d'une certaine assurance que leur contribution n'est pas vouée à l'oubli. Surtout qu'en faisant ainsi, on divise l'équipe de dev en deux (ceux qui bossent sur L4 et ceux qui bossent sur gnu-mach), réduisant aussi la productivité globale.

      Personellement, le message que je lancerai à l'équipe de Hurd c'est de faire un choix et l'assumer (gnu-mach, l4, autre). Par assumer, j'entend éviter de parler d'un RetourAZero avant une version stable qui a ateint le point critique (cité plus haut) en terme de nombre d'adeptes.

      • [^] # Re: Et pourquoi pas !!!

        Posté par  . Évalué à 0.

        il ne faut pas repprocher à Hurd d'être vieux. Ce n'est pas un problème en soi.

        Non, ca c'est clair, c'est pas un probleme en soi.
        Le probleme c'est qu'en 15 ans on a toujours rien de stable ni d'utilisable...
        Et la, ben faut pas prendre les gens pour des lapins de 3 jours, ca va finir par se voir que ca aboutira jamais...

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 2.

        Ce commentaire a été supprimé par l’équipe de modération.

  • # Résultats de quelques investigations

    Posté par  (site web personnel) . Évalué à 6.

    Je me suis aussi interessé au hurd ces derniers temps, alors après enquète voila ce que j'en sais.

    Si le hurd n'a pas décollé, c'est entre autre parceque les développeurs trop peu nombreux avait un peu de mal à se fixer un roadmap, notamment avec l'histoire de mach, puis l4, l4.sec, l4-ng, etc. comme expliqué plus haut.

    Pour les cotés plus positif, je suis tombé sur hurdfr[1], qui à l'air carrément plus actif que le projet principal. Ils ont mis en place un wiki, ce fixe des objectifs, mettent en place une infrasturture pour soutenir le développement (mise à disposition de machine de test en ssh). Pour l'instant ils développent sous mach, et dans un avenir lointain il passeront peut être à l4-ng (si je me souviens bien), mais ce n'est vraiment pas à l'ordre du jour. Apparement sa code plus que ça ne parle...

    [1] http://hurdfr.org

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 2.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Résultats de quelques investigations

        Posté par  (site web personnel) . Évalué à 2.

        Il est clair que la virtualisation avec Xen, vserver... apporte aussi un autre type de solution que le Hurd mais finalement pas si éloigné.

        Par ailleurs, il faut savoir que la virtualisation résoud aussi un gros problème pour Microsoft vu que sous Windows, tout tourne en root. Avec la virtualisation, Microsoft a une bonne occasion de résoudre ce problème, un service = une machine virtuelle.

        Bref, les hyperviseurs ont une force de frappe d'un paquet de développeurs qui sont près à graver une partie de la solution dans le silicium.

        Encore une fois, c'est pas forcément le meilleur qui gagne mais ceux qui gagne montrent qu'ils arrivent à s'adapter.

  • # En fait Hurd est loin d'être tout seul....

    Posté par  . Évalué à 1.

    J'ai fait un peu de recherche sur internet, surtout sur Wikipedia, à propos de Hurd et aussi de Tenenbaum. Et d'après ce que j'ai pu y trouver, il y a plusieurs projets qui utilisent le micro kernel L4.
    Pour les liens:
    L4AK Project: http://www.l4ka.org/
    DROPS: http://os.inf.tu-dresden.de/drops/ ils ont plusieurs projets

    http://l4hq.org/ Et pour avoir des infos sur les différents projets:

    Tout ça pour vous dire que je ne soupçonnait pas du tout qu'il y avait autant de projets pour des micro noyaux. ça va m'en faire de la lecture... et moi qui ai encore des examens... Bon ben ça sera pour après :)

    Mais ces sites me font penser que Hurd, contrairement à ce que je pensais avant et ce qui a été écrit ici, est loin d'être tout seul. Maintenant on entend surtout parler de Hurd mais je me demande s'il n'y a pas d'autres projets qui ne sont pas plus avancés/mieux foutus.

    Pour lancer un nouveau OS, il faudra tout d'abord arriver à s'affirmer comme serveur fiable, et cela a l'air d'être le cas aux USA vu que leur système de votation a tourné sur un OS avec micro kernel et ensuite le reste viendra.

    Bon ben moi je vous laisse, j'ai un examen de prog demain et si je veux en plus lire tout ca...

    • [^] # Re: En fait Hurd est loin d'être tout seul....

      Posté par  . Évalué à 1.

      Pour lancer un nouveau OS, il faudra tout d'abord arriver à s'affirmer comme serveur fiable
      hehe
      je savais pas que macosx, XP ou vista etaient consideres comme des serveurs fiables... :-)

      sinon, c'est quoi une votation? le fait de votater?

      • [^] # Re: En fait Hurd est loin d'être tout seul....

        Posté par  . Évalué à 1.

        Heu WindowsXP a fait de gros effort pour sa stabilité par rapport à tous les autres Windows qui sont venus avant. Mac OSX est un système très stable. Il est basé sur *BSD(Darwin).

        Et Non c'est pas une votation, c'est ce qu'on appelle une reconnaissance du marché. Linux est devenu "fiable" non au moment où le système était stable mais au moment où les décideurs ont cru en ce système. Bref pour lancer un nouveau SE, il faut que les gens qui ont plein d'argent et bien ils aient confiance. Quand une grosse société se dit:"allez, on migre tout notre système vers un nouveau système", il faut qu'il y ait une garantie.

        Voili voilou

        • [^] # Re: En fait Hurd est loin d'être tout seul....

          Posté par  . Évalué à 1.

          oui, ils sont stables.

          Et pourtant, tu connais beaucoup de serveur (de prod, hein, je te parle pas de jean kevin en deug mias dans la cite U de bures sur yvette) sous windows XP ou macos?

          • [^] # Re: En fait Hurd est loin d'être tout seul....

            Posté par  (site web personnel) . Évalué à 2.

            Dans la famille Windows, le SE destinné aux serveurs se nomme Windows 2003 server et est decliné en plusieurs "éditions". Et pas mal de monde s'en sert un peu partout..

            \_o<

          • [^] # Re: En fait Hurd est loin d'être tout seul....

            Posté par  . Évalué à 1.

            Pour ce qui est des serveurs il y a plein de serveurs sous Windows 2003 Server et il y en a aussi sous OSX server.

            Je ne vois pas tellement où tu veux en venir...

            • [^] # Re: En fait Hurd est loin d'être tout seul....

              Posté par  . Évalué à 1.

              la ou je veux en venir c'est la :
              Pour lancer un nouveau OS, il faudra tout d'abord arriver à s'affirmer comme serveur fiable

              pour autant que j'en sache, 2003 server est sorti apres que XP se soit impose, et macos server doit avori une part de marche egale a celle de linux sur le desktop chez microsoft (1 psote, celui de pbpg :-D )

              'fin bref, je vois pas d'ou sort cette affirmation, mise a part d'un chapeau...

          • [^] # Re: En fait Hurd est loin d'être tout seul....

            Posté par  (site web personnel) . Évalué à 3.

            Ce n'est pas parce qu'on n'aime pas Windows qu'il faut dire des bêtises. Soyons objectif, des serveurs sous Windows, il y en a des quantités et qui marchent bien.

            Cela dit, si je peux éviter, j'évite...

      • [^] # Re: En fait Hurd est loin d'être tout seul....

        Posté par  (site web personnel) . Évalué à 1.

        je savais pas que macosx, XP ou vista etaient consideres comme des serveurs fiables..
        Y'en a qui s'amusent avec des Xserve et Mac OSX server, tu crois qu'ils vont s'en sortir ?
        http://serverlogistics.com/hosting.php
        C'est plus au niveau de ce que ça leur coûte sur le matos et les licences, que je m'inquièterai de la fiabilité des boites qui utilisent ce genre de solutions.

  • # Wikipedia enlarge your point of view

    Posté par  (site web personnel) . Évalué à 2.

    Un petit commentaire, juste pour citer une page de Wikipedia : http://en.wikipedia.org/wiki/Category:Free_software_operatin(...)

    Elle liste un certain nombre (voire un nombre certain pour reprendre un jeu de mots bien connu) d'OS libres. Cela permet de se rendre compte que Linux n'est pas la seule alternative.
    A lire absolument par tous les curieux.

  • # Re: Hurd, une si belle idée et pourtant.

    Posté par  . Évalué à 5.

    > Le projet est vieux et pourtant aucune entreprise n'a osé se lancer dedans

    C'est difficile aujourd'hui, pour une entreprise, d'investir dans la R&D de systèmes d'exploitation. Quand on regarde de près, tous les systèmes actuellement majeurs dans l'industrie sont nés dans des universités (BSD, Mach, même Linux). ce n'est qu'une fois le développement initial terminé qu'ils deviennent rentables, et que les entreprises s'y intéressent. Il y a bien sûr des exceptions.

    Pour autant, Hurd n'est pas vieux, il est même trop jeune, puisque les nouveaux concepts n'ont pas encore pu être véritablement éprouvés (et en réalité, on s'est aperçu de quelques défauts très difficiles à corriger dans le Hurd actuel).

    > La on a un système qui est stable par design ce qui veut dire que nous avons un système qui ne peut, théoriquement, pas complètement planté.

    Non, ça c'est une légende urbaine... Un micronoyau, ça ne fait pas tout. Dès qu'un serveur critique comme le serveur qui s'occupe de l'émulation POSIX ou le serveur d'authentification des messages tombe, tout tombe. Simplement ces serveurs sont isolés, et en général pas trop gros, donc facilement auditables.

    > On a également plus besoin de redémarrer,

    Plus ou moins. Mis à part les pilotes matériels, on peut en effet tout manipuler sans redémarrage complet du système. Mais je ne considère pas ça comme un véritable avantage du Hurd, simplement un effet secondaire d'une conception de qualité.

    > un système comme celui-là qui viendrait à être utilisable en production serait un gros coup de pouce pour l'open source

    Le Hurd n'est pas prêt pour la production. Quand bien même la couche basse serait stable, il y a toujours des problèmes de gestion de ressources qui n'en font pas encore un bon système pour la production (on n'est pas loin, mais ça demande une reconception).

    Le principal problème, c'est trop de bugs. Il y a également quelques incompatibilités très gênantes avec POSIX. Et trop peu de bons développeurs pour arranger le coup (les bons bossent surtout sur une reconception nécéssaire du Hurd en ce moment). Mais ça va venir ... :-)

Suivre le flux des commentaires

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