vendredi 11 avril

Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Astuces :: Suivi :: RDF

Articles précédents : Articles

Liens connexes

La news sur Slashdot (721 hits)
L'interview de RMS (516 hits)
HurdFR (2115 hits)

Dépêche modérée par

Articles : GNU/Linux est mort, vive GNU !

Posté par virtux (page perso, ). Modéré le 13 mars 2002.

La FSF a annoncé qu'une version utilisable en production du Hurd sortirait dans le courant de l'année 2002.

Et Richard Stallman de rajouter dans une interview à PCWorld : "We actually have the GNU kernel working, and we can now produce the GNU system, as opposed to the GNU/Linux system that people have been using so far". (TdM: "Le kernel GNU fonctionne, et nous sommes maintenant en mesure de produire le système GNU, par opposition au système GNU/Linux que les gens utilisaient jusqu'à maintenant".)

La mort annoncée de GNU/Linux ?

Note du modérateur : j'ajoute les liens vers l'interview en question et vers Hurdfr.org. La news originale contenait un lien vers OSNews qui semble cassé, je le remplace par un lien vers Slashdot.

La news sur Slashdot (721 hits)
L'interview de RMS (516 hits)
HurdFR (2115 hits)

> Lire la dépêche (140 commentaires, moyenne: 4,9).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

Retour vers le futur

Posté par furai (page perso, ) le 13/03/2002 à 13:10. (lien). Évalué à 21.

The Hurd kernel of FSF's GNU system is more powerful than
Linux because it is designed using a microkernel instead of a
monolithic architecture, Stallman said.

C'est marrant, j'ai deja entendu ca :)

[^]Re: linux is obsolete

Posté par jm () le 13/03/2002 à 14:00. (lien). Évalué à 4.
tu veux dire ici:
http://alge.anart.no/linux/history/linux_is_obsolete.txt(...)

[^]Re: Retour vers le futur

Posté par Vanhu () le 13/03/2002 à 14:12. (lien). Évalué à 15.
Tout dépend de ce que l'on veut dire par "more powerful", mais d'un certain point de vue, un µnoyau est quand meme très intéressant !

Sans vouloir relancer le tro^H^H débat, le noyau Linux se fait quand meme de plus en plus volumineux...
- [+] [^]Re: Retour vers le futur
  
  Posté par matiasf () le 13/03/2002 à 14:40. (lien). Évalué à -14.
  > le noyau Linux se fait quand meme de plus en plus volumineux...
  
  prend une distribution qui utilise un 1.2.x si c'est un critere important et que t'as pas 50 Euro pour 256 Mo.
  
  Ca me souale ces gnagna gnagni... Ces gus jamais content alors qu'ils ont pour gratos le top (ou presque).
  - [+] [^]Re: Retour vers le futur
    
    Posté par Benoit Rousseau () le 13/03/2002 à 16:25. (lien). Évalué à -2.
    Et tu les place ou tes 256Mo sur ton grille pain ?
    
    Y a pas que les 'PC' qui font tourner Linux... Et puis on ne parle pas des applications autour de Linux qui sont lourdes : on parle du noyau...
    - [^]Re: Retour vers le futur
      
      Posté par bad sheep (page perso, ) le 13/03/2002 à 17:01. (lien). Évalué à 14.
      Evidemment, si tu prend le code source de linux avec les drivers de plein de périphériques, c'est énorme, mais le 2.4 prend moins de place qu'un 2.2 en mémoire... (avec les mêmes pilotes de périphériques...), de même, il est plutôt plus rapide... donc... je vois pas trop d'où vient le problème.
      - [^]Re: Retour vers le futur
        
        Posté par Vanhu () le 13/03/2002 à 18:43. (lien). Évalué à 0.
        Le probleme, c'est que si on suit la tendance actuelle, et en exagérant un peu, on va finir par se retrouver avec emacs dans le noyau !
        
        Note que j'aime bien emacs, et que ca serait pas mieux avec vi, mais la conception des µnoyaux découpe plus, et ne met normalement en mode noyau que le strict nécessaire, et ca, c'est a priori une bonne idée (d'un point de vue propreté / stabilité, pas forcément performances).
        
        [^]Retour vers le futur IV
        
        Posté par Rafael Pinilla () le 13/03/2002 à 21:54. (lien). Évalué à 8.
        Le HURD est bientôt là....
        Il y a 10 ans, c'était l'arlésienne, la vaporware hypothétique de demain loin-là-bas...
        On l'appellait pas encore "LE" hurd, mais simplement HURD. gcc, emacs, c'était pour les affranchis. Désormais, tout le monde les utilise, alors le monde est mûr pour HURD.
        
        Le simple fait qu'il parvienne à éclore, c'est déjà la réalisation d'un rêve.
        
        HURD et Linux ne sont pas ennemis mais frères, un peu différents, comme tous les frères qui ne sont pas jumeaux. HURD est plus vieux, encore immature, et Linux est le petit frère précoce qui n'en veut.
        
        Celui qui prétend le contraire n'a quà répondre à la question suivante: Avec quoi fut compilé Linux le premier jour ? GCC.
        Qu'est-ce que gcc ? La première fondation du GNU HURD.
        
        Demain ne peut être que meilleur, car HURD est sur le point de naître. La liberté gagne la terre et vaincra
        
        [^]Re: Retour vers le futur
        
        Posté par Cyril Chevrot () le 14/03/2002 à 15:44. (lien). Évalué à 1.
        Linus déteste emacs (et Stallman et et les unoyaux (donc Hurd) comme tout le monde sait), donc ca m'étonnerait vraiment que le noyau de Linux se mettent à ressembler à Emacs. Le noyau officiel est très nettement conservateur et seule les fonctionnalités que Linus trouve vraiment importantes sont ajoutées, contrairement à la branche maintenu par Alan Cox.
        
        [^]Re: Retour vers le futur
        
        Posté par Gaël Le Mignot (page perso, ) le 14/03/2002 à 16:58. (lien). Évalué à 4.
        Le noyau officiel est très nettement conservateur et seule les fonctionnalités que Linus trouve vraiment importantes sont ajoutées,
        
        Sauf que Linus a parfois des goûts très bizarres: un serveur Web dans le noyau, un changement de VM en plein milieu d'une branche stable, refus d'intégrer des patchs pour le PCI 64-bits ou les nouvelles normes ATA, intégration de ReiserFS dans le 2.4.1 qui devait ne contenir que des bugs fixes, ...
        
        Je respecte beaucoup Linus et je trouve que globalement il fait du très bon boulot, mais il commet aussi parfois de grosses erreurs AMHA, et son obstination à dénigrer les micro-noyaux et le Hurd frise parfois le ridicule (par exemple sur le coup du MAP_COPY où il reproche à l'équipe du Hurd quelque chose qui est lié à GNU Mach et non au Hurd)
  - [^]Re: Retour vers le futur
    
    Posté par Vanhu () le 13/03/2002 à 18:47. (lien). Évalué à 1.
    Euh, mettre 256Mo sur mon 486 qui fait Gateway ou sur mon Amiga 1200, c'est un peu plus cher que 50Euros, et un peu moins facile aussi.....

[+] [^]Re: Retour vers le futur

Posté par Timbert Benoît () le 13/03/2002 à 15:16. (lien). Évalué à -5.
The Hurd kernel of FSF's GNU system is more powerful than Linux because it is designed using a microkernel instead of a monolithic architecture, Stallman said.

Puissant => bouffe plus le CPU => plus lent ;)
- [^]Re: Retour vers le futur
  
  Posté par Gaël Le Mignot (page perso, ) le 13/03/2002 à 15:28. (lien). Évalué à 14.
  Lis les docs que l'on trouve sur http://www.l4ka.org/publications/(...) et en particulier http://os.inf.tu-dresden.de/pubs/sosp97/(...) et tu verras que les performances d'un système à base de micro-noyau ne sont pas nécessairement beaucoup plus faibles que celles des systèmes à base de noyau monolithique.
  - [^]Re: Retour vers le futur
    
    Posté par Timbert Benoît () le 13/03/2002 à 15:38. (lien). Évalué à 6.
    En l'occurence, pour l'instant, sur un système "monolithique" du genre PC, entre Linux et Hurd, pour l'instant y'a pas photo ...
    
    Par contre sur une machine bien parallèlle, peut être que la tendance s'inverse.
    
    Mais comme aujourd'hui la plupart des systèmes que l'on rencontre sont des PC ...
    - [^]Re: Retour vers le futur
      
      Posté par Gaël Le Mignot (page perso, ) le 13/03/2002 à 15:47. (lien). Évalué à 16.
      Euh... lis les articles justement. Un simple port brutal de Linux sur L4 ne donne que 5% de perte de performances, alors que ce port n'utilise pas les capacités particulières des micro-noyaux, et que ce test a été réalisé il y a longtemps et que beaucoup de progrès sur l'IPC ont été fait dans L4 depuis.
      
      Actuellement le Hurd est plutôt lent car non optimisé (par contre les développeurs savent comment faire pour l'optimiser, ce n'est pas la priorité c'est tout) et qu'il utilise GNU Mach, qui n'est pas non plus un modèle de vélocité.
      
      Mais à terme, lorsque le Hurd sera sur L4, la différence de vitesse entre GNU et GNU/Linux devrait être négligeable, surtout comparé à tout ce que GNU apporte (et à la puissance des machines qui s'accroit sans cesse, le CPU étant rarement le facteur limitant d'une machine)
      - [+] [^]Re: Retour vers le futur
        
        Posté par Code34 (page perso, ) le 13/03/2002 à 15:55. (lien). Évalué à -1.
        De plus, sur ce qui a été précisé au dessus , la plus part des kernels linux utilisé sont modulaires, et non monolythique ...
        
        est ce que le modulaire et le monolythique sont aussi rapide ?
        
        @++
        Code34
        
        [^]Re: Retour vers le futur
        
        Posté par Gaël Le Mignot (page perso, ) le 13/03/2002 à 16:02. (lien). Évalué à 28.
        Le noyau Linux est monolithique dans le sens où en mémoire le noyau est un seul gros programme qui tourne en mode noyau, et où un bug dans un module noyau peut avoir des conséquences sur tout le reste du noyau. Par contre c'est un noyau modulaire, puisqu'il est possible de charger/décharger des modules en cours d'exécution (Linux est donc monolithique modulaire).
        
        D'un point de vue performances, il y a un très léger surcoût à utiliser des modules, de l'ordre de quelques cycles CPU par appel système se trouvant dans un module (la valeur exacte se trouve dans "Le noyau Linux" de chez O'Reilly, je pourrais regarder chez moi), mais concrètement c'est totalement négligeable (sachant qu'un kernel trap a déjà un coût moyen estimé d'environ 170 cycles, sans compter le traitement de l'appel système, les quelques cycles de plus ne sont vraiment pas importants).

[^]Re: Retour vers le futur

Posté par Romuald Delavergne () le 13/03/2002 à 16:13. (lien). Évalué à 1.
Monolithique mais très modulaire !!
Donc si t'as pas besoin, tu prends pas.

Je pense que la taille du noyau n'est pas un critère puisque ce qui ne sera pas dans le noyau pour HURD, le sera dans un module en mode user.
- [^]Re: Retour vers le futur
  
  Posté par Gaël Le Mignot (page perso, ) le 13/03/2002 à 16:25. (lien). Évalué à 21.
  Oui, mais c'est une différence de taille.
  Un programme sans bugs ça n'existe pas. Un plus un programme est gros, plus il a de risques d'être buggué (à toutes autres choses égales). Donc plus tu as de code qui s'exécute en mode noyau, plus tu as de bugs potentiels en mode noyau. Or, un bug d'un programme s'exécutant en mode noyau peut avoir des conséquences gravissimes, allant du plantage au trou de sécurité, en passant par la corruption de données, voir des dégâts sur le matériel dans des cas extrêmes.
  
  Dans le cas du Hurd où on a une collection (un troupeau ;) ) de serveurs indépendants qui tournent en mode utilisateur, un bug dans l'un de ces serveurs a des conséquences beaucoup plus réduites sur le système en général. Sans compter que pour débugguer un module noyau c'est beaucoup plus compliqué qu'un serveur du Hurd, qui lui se débugue comme un programme normal avec gdb, la libefence et autres.
  
  Mettre un "module" en mode noyau, c'est jouer avec le feu, c'est lier le sort du système entier au sort du programme, et c'est donc à éviter autant que possible.
  - [+] [^]Re: Retour vers le futur
    
    Posté par Jul (page perso, ) le 13/03/2002 à 17:32. (lien). Évalué à -5.
    C'est pas vraiment fonction de la taille c'est fonction de la compléxité.
    Par exemple, faire un petit tableur en assembleur modulaire aura surement plus de bug qu'un intégré à la xxxxx office. Et la complexité vient avant tout de la conception.
    
    Le débat est vieux d'au moins 10 ans:
    http://www2.educ.umu.se/~bjorn/mhonarc-files/obsolete/msg00000.html(...)
    Je ne dirais qu'une chose à propos de Linux :
    et pourtant il tourne.
    
    De toute façon, GNU n'est pas un logiciel, c'est au mieux une secte
    - [^]Trop gros, passera
      
      Posté par Gaël Le Mignot (page perso, ) le 13/03/2002 à 17:36. (lien). Évalué à 2.
      De toute façon, GNU n'est pas un logiciel, c'est au mieux une secte
      
      ................_---________---__________............................. ...............|..........PLEASE.........}............................ ...............|.........................}............................ ............../....DO.NOT.FEED.THE.TROLL.\............................ ..............\____....................__/............................ ...................-------------------`............................... ...........................|#:|....................................... ...........................|#:|....................................... ...........................|#:|....................................... ........................\\\|#:|/./.................................... ............~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~.......................
      
      -1
  - [^]la guerre des kernels
    
    Posté par destroy (page perso, ) le 13/03/2002 à 22:10. (lien). Évalué à 8.
    Personnellement, du point de vue de la rapidité, je ne pense pas qu'il puisse y avoir une différence flagrante.
    
    Je vois cependant un avantage MAJEUR aux microkernels : rappelez des OS du style BE, dans le repertoire utilisateur, on peut charger ses modules, qui fonctionnement en mode utilisateur, j'avais adoré ca. si le module deconne, on efface.
    C'est idéal pour tester une config pour eventuellement la valider et généraliser le module qu'on aura préalablement testé en faisant un simple copier-coller en root. Les utilisateurs pourront choisir les modules de leur choix et chaque utilisateur pourra avoir son hurd perso.
    C'est quand même assez génial à mon avis.
    
    Je vois un inconvénient, cependant. Si les modules utilisateurs sont trop nombreux, ils peuvent peut-être vite encombrer la ram, non ?
    Si quelqu'un est plus éclairé que moi sur le sujet, j'aimerais bien qu'il m'explique.
    
    Je pense donc que les microkernels c'est assez génial, je ne sais pas quels seront les inconvenients.... il n'y a rien a voir entre un petit BeOS et un gros serveur linux...
    - [^]Re: la guerre des kernels
      
      Posté par Gaël Le Mignot (page perso, ) le 13/03/2002 à 22:23. (lien). Évalué à 6.
      Personnellement, du point de vue de la rapidité, je ne pense pas qu'il puisse y avoir une différence flagrante.
      
      Si on ne fait pas attention, si, l'échange de messages entre les différents serveurs peut venir devenir très très couteux. Mais en prenant quelques précautions, en implémentant l'IPC de manière performante, ... on arrive à réduire grandement les pertes.
      
      Si les modules utilisateurs sont trop nombreux, ils peuvent peut-être vite encombrer la ram, non ?
      
      En théorie oui, sans doute, mais les serveurs sont des programmes normaux qui peuvent être swappés s'ils ne sont pas utilisés par exemple, et puis comparé aux couches types Gnome-VFS ou kioslave qui sont nécessaires sous Linux pour avoir des fonctionnalités équivalentes, ça me semble quand même beaucoup plus léger.
  - [^]Re: Retour vers le futur
    
    Posté par Sixtiz (page perso, ) le 14/03/2002 à 01:35. (lien). Évalué à 5.
    "plus un programme est gros, plus il a de risques d'être buggué"
    
    Je suis d'accord mais si l'on veut comparer Linux et le Hurd, je suppose qu'il faut comparer la quantité totale de code, et si les deux sysèmes doivent remplir les memes fonction, ils doivent representer plus ou moins la meme quantite de code donc de bugs...
    
    Alors il est vrai qu'un bug dans un des serveurs du Hurd ne compromet que ce serveur, pas le système entier, alors que pour le noyau Linux, c'est tout le systeme qui se vautre. Certes. Mais AMHA le probleme est peu different : dans tous les cas il faut corriger le bug ou le service en question ne marchera pas. Alors redemarrer juste le service au lieu du systeme entier, c'est pas la solution miracle. Et puis en ce qui me concerne, j'ai rencontré beaucoup plus de bugs dans les programmes user space (donc que l'on peut redemarrer simplement sans rebooter) sous Linux que de bugs liés au noyau lui-meme et aboutissant a un reboot violent, donc l'architecture actuelle de Linux et le fait qu'il tourne en mode noyau ne me parait pas etre un problème si sérieux, et le fait que le Hurd utilise des serveurs et pas le mode noyau ne me parait pas non plus etre l'arme supreme... Enfin bon je demande à tester :o)

[+] [^]RMS est mort, vive Linus

Posté par Cyril Chevrot () le 14/03/2002 à 16:13. (lien). Évalué à -7.
Les micros noyau, ca pue
Hurd = 10 ans de développement et toujours pas pret
Linux = Pret en moins d'1 an, fonctionnel en une poignée d'années
Le but d'un micro-noyau c'est surtout pour les développeurs, possibilité de développer des modules en mode utilisateur, possibilité d'avoir des systèmes de fichier en tournant en mode utilisateur, ...
Le problème c'est que si le passage de messages et la communication entre les processus rend le développement tellement compliqué qu'il multiplie le temps de développement par 10 je vois pas trop l'intéret pour les développeurs d'utiliser un m icro-noyau.
De plus rajouter des interfaces et des couches d'abstraction c'est peut-etre beau sur le papier, mais à chaque fois ca entraine des chutes de performance terribles. Certes il y aura toujours des articles pour dire que la perte de performance n'est pas si terrible que ca, mais il y a toujours des articles pour dire n'importe quoi. Il suffit de se baser sur certaines mesures précises pour prouver ce qu'on veut prouver. Personnellement Java => ajout d'un couche d'abstraction (vm) => super long. De meme le fait que X est un processus dans l'espace utilisateur est certe une très bonne chose niveau conception (et je pense que pour le coup on a eu raison) cependant, je trouve qu'un des seules avantages de windows sur Linux est justement d'etre plus rapide au niveau de l'affichage (car le système de fenêtrage et justement dans le noyau). Et pour les micros noyaux, c'est encore le meme probleme, belle conception en apparence => chute de performance. Les belles idées sur le papier on a vu ce que ca a donné avec le communiste et apparemment on peut généraliser à pas mal de domaine la leçon. Le seul micro noyau que j'ai utilisé pour l'instant est minix (qui est nettement plus long que linux), mais j'ai des copains qui ont utilisés Hurd et Mac OS X et il m'ont dit que les performances étaient moins bonne que sur les OS monolithiques.
De plus j'ai lu qq part que de toutes facon on n'avait de plus en plus de ressources processeurs et donc que les performances n'étaient pas si primordiales que ca. Cet argument est l'argument (récurrent) e plus débile de l'histroire de l'informatique. On aura _jamais_ trop de ressource et donc on se doit de concevoir les systèmes le plus efficacement possible.
Quand à la modularité, avec Linux on a la modularité au niveau du source. De plus les modules ne constituent pas du rafistolage mais plutot le juste milieu.

D'ou ma conclusion :

Hurd ne remplacera _jamais_ Linux car si Hurd devait triompher Hurd aurait _déjà_triompher. N'en déplaise à Stallman et à son égo surmesurer.
- [^]Re: RMS est mort, vive Linus
  
  Posté par Gaël Le Mignot (page perso, ) le 14/03/2002 à 17:10. (lien). Évalué à 8.
  Les micros noyau, ca pue
  
  Ca c'est de l'argumentation ! Chapeau !
  
  Hurd = 10 ans de développement et toujours pas pret
  
  Le développement Hurd a été (presque) complètement stoppé pendant des années, c'est 1999 que Marcus l'a relancé.
  
  Le problème c'est que si le passage de messages et la communication entre les processus rend le développement tellement compliqué qu'il multiplie le temps de développement par 10 je vois pas trop l'intéret pour les développeurs d'utiliser un micro-noyau.
  
  Le passage de messages ne complique pas vraiment le développement, mais par contre le fait d'avoir des programmes en user-space normaux que l'on débugguer avec gdb, qui n'obligent pas à redémarrer la machine lors d'un segfault, ... augmente nettement la facilité de développement.
  
  mais à chaque fois ca entraine des chutes de performance terribles.
  
  Tu as lu les autres commentaires sur cette page ? Tu es allé voir les articles sur L4Linux, L4KA et les techniques d'optimisation de l'IPC ? Alors renseigne-toi avant de parler et de sortir des arguments bidons que tu as lu l'aveille sur /. Et crois-moi, je ne dis pas ça pour être méchant, vu que ce genre d'arguments je les sortais il y a quelques mois avant que je ne me renseigne vraiment sur la question (j'ai un peu honte de moi maintenant mais bon... errare humanum est)
  
  mais j'ai des copains qui ont utilisés Hurd et Mac OS X et il m'ont dit que les performances étaient moins bonne que sur les OS monolithiques.
  
  Encore une fois, lis ce qui a été dit ici. Le Hurd n'est pas optimisé pour l'instant. Les développeurs savent où sont les principales lacunes, savent comment y remédier, mais ce n'est pas la priorité. Pour Mac OS X c'est plus la couche Quark/Aqua qui rame que Darwin.
  
  Quand à la modularité, avec Linux on a la modularité au niveau du source. De plus les modules ne constituent pas du rafistolage mais plutot le juste milieu.
  
  Tu as lu tout ce que Manuel Menal et moi (entre autres) avons dit sur les possibilités du Hurd ? Comment tu fais le translator FTP + Hostmux sous Linux ? Ou le générateur de fortune ? Ou le serveur Apache qui n'a jamais besoin des droits root pou binder le port 80 ? Ou le serveur FTP non anonyme qui n'est pas suidé root ? Et le fait qu'un bug dans un module fasse cracher la totalité du système ? Alors relis tout ce qu'on a dit sur cette page avant de sortir des phrases toutes faites comme ça.
  
  Hurd ne remplacera _jamais_ Linux car si Hurd devait triompher Hurd aurait _déjà_triompher. N'en déplaise à Stallman et à son égo surmesurer.
  
  Le but du Hurd n'est pas de remplacer Linux, mais de proposer une alternative mieux conçue et plus puissante. Quand à la personnalité de RMS, déjà je ne suis pas du tout d'accord avec ton jugement sur lui, et en plus je ne vois pas ce qu'il a à voir que le Hurd.
  - [+] [^]Re: RMS est mort, vive Linus
    
    Posté par Cyril Chevrot () le 14/03/2002 à 18:45. (lien). Évalué à -1.
    
    >>Les micros noyau, ca pue
    >Ca c'est de l'argumentation ! Chapeau !
    
    L'argumentation vient après. On t'a pas appris quand tu étais petit qu'il fallait commencer les paragraphes avec l'idée principale est l'argumenter après.
    
    Le développement Hurd a été (presque)
    complètement stoppé pendant des a
    nnées, c'est 1999 que Marcus l'a relancé.
    
    Justement ca montre bien que les micros noyaux rendent la conception plus difficile. Je ne pense pas que les développeurs HURD soient des brels, alors s'ils se sont découragés c'est bien que ca devait etre difficile.
    
    Et crois-moi, je ne dis pas ça pour être méchant, vu que ce genre d'arguments je les sortais il y a quelques mois avant que je ne me renseigne vraiment sur la question (j'ai un peu honte de moi maintenant mais bon... errare humanum est)
    
    Et oh, faut pas etre gentil comme ca, une réputation de trolleur ca ce travail ;)
    
    Le Hurd n'est pas optimisé pour l'instant. Les développeurs savent où sont les principales lacunes, savent comment y remédier, mais ce n'est pas la priorité
    
    La performance n'est pas une priorité, je crois réver. La performance devrait toujours etre une priorité.
    
    Tu as lu tout ce que Manuel Menal et moi (entre autres) avons dit sur les possibilités du Hurd ? Comment tu fais le translator FTP + Hostmux sous Linux ? Ou le générateur de fortune ? Ou le serveur Apache qui n'a jamais besoin des droits root pou binder le port 80 ? Ou le serveur FTP non anonyme qui n'est pas suidé root ? Et le fait qu'un bug dans un module fasse cracher la totalité du système ? Alors relis tout ce qu'on a dit sur cette page avant de sortir des phrases toutes faites comme ça.
    
    Ces fonctionnalités sont interessantes au niveau de la sécurité et du développement, mais bon je préfère un système ou l'on prend plus de risque et on l'on favorise avant tout les performances. De la même facon je préfère coder en C qu'en Java. Certes en java il y a un demi milliards de mécanismes pour prendre des précautions qui n'existe pas en C. Un code C a ainsi beaucoup plus de chance de planter à l'exécution qu'un code Java. Mais il est aussi beaucoup plus rapide (Je sais je n'aurais pas du prendre l'exemple de Java car la lenteur est principalement du à la vm, mais j'ai assez peu d'expérience avec le C++). Et les tests ca existent. La communauté Linux jouent sur la rapidité de développement et le feed back rapide des problèmes pour avoir un système sur et sécurisé. Je préfère cette approche que l'approche : on prend énormément de précaution et on optient une chute de performances.
    
    Quand à la personnalité de RMS, déjà je ne suis pas du tout d'accord avec ton jugement sur lui, et en plus je ne vois pas ce qu'il a à voir que le Hurd.
    Tu ne vois pas ce qu'il a avoir avec le Hurd !!!????!!?!. Le système GNU ca te dit qqchose ? Le Hurd est le noyau officiel du système, pas Linux. Et Stallman est bien verreux que Linux (ou Linus si tu préfère) lui ait piqué la chandelle : les messieurs tout le monde dans la rue connaissent moins stallman que Linus.
    - [^]Re: RMS est mort, vive Linus
      
      Posté par Gaël Le Mignot (page perso, ) le 14/03/2002 à 19:08. (lien). Évalué à 2.
      Je ne pense pas que les développeurs HURD soient des brels, alors s'ils se sont découragés c'est bien que ca devait etre difficile.
      
      Non, c'est parce qu'il y avait déjà Linux et que la priorité n'était donc plus au niveau du "noyau".
      
      La performance n'est pas une priorité, je crois réver.
      
      Et ben non, quand tu développes un programme tu commences par le faire robuste et fiable, et après tu optimises. L'optimisation de l'implémentation n'est pas une priorité dans le début du développement d'un programme.
      
      mais bon je préfère un système ou l'on prend plus de risque et on l'on favorise avant tout les performances.
      
      T'es bouché ou tu le fais exprès ? La perte de performance peut être dimunée au point d'être négligeable ! Pendant que tu y es aussi on fait tourner en mode noyau sans protection mémoire ni rien pour économiser un peu de perf ? Et compare des choses qui sont comparables STP, un micro-noyau c'est beaucoup moins lourd et coûteux qu'une JVM et ça apporte beaucoup plus AMHA.
      
      Tu ne vois pas ce qu'il a avoir avec le Hurd !!!??
      
      Ce n'est pas RMS qui contrôlle le Hurd, qui prend les décisions de design ou autres. Il ne participe même au code IIRC. Quand a ton mépris pour RMS, ça ne concerne que toi et je ne partage pas du tout ton avis. Si tu n'as pas compris que les différents entre RMS et Linus sont plus idéologiques qu'autre chose (RMS défendant le logiciel libre pour des raisons éthiques, Linus ne s'intéressant qu'au côté technique), et bien c'est dommage.
      - [^]Re: RMS est mort, vive Linus
        
        Posté par Cyril Chevrot () le 14/03/2002 à 23:50. (lien). Évalué à 1.
        
        un micro-noyau c'est beaucoup moins lourd et coûteux qu'une JVM et ça apporte beaucoup plus AMHA.
        
        C'est vrai. Mais le problème de base reste le meme : en ajoutant des couches logiciels on s'éloigne du hard et on perd en performance.
        
        Si tu n'as pas compris que les différents entre RMS et Linus sont plus idéologiques qu'autre chose (RMS défendant le logiciel libre pour des raisons éthiques, Linus ne s'intéressant qu'au côté technique), et bien c'est dommage.
        
        Bien sur que je connais les différents idéologique entre le mouvement Open Source et la FSF. Bien sur que je sais que les 9 clauses de l'OSD sont plus pragmatique qu'idéologique.
        Maintenant les différents sont aussi technique. Linus n'aime pas emacs et Hurd. RMS aime les unoyaux, Linus ne les aime pas. Tu ne vas pas me dire qu'il ne s'agit pas de différent technique. D'une facon générale les différents entre les 2 sont avant tout basé sur une vision différente du monde : d'un coté il y a un pragmatique qui tire ces idées de l'expérience, de l'analyse du réel et de l'autre il y a un théoricien qui préfère les belles idées. Moi je me reconnais parfaitement dans la première vision du monde et pas du tout dans la deuxième. C'est mon droit maintenant tu es libres de penser différemment.
        
        [^]Re: RMS est mort, vive Linus
        
        Posté par Gaël Le Mignot (page perso, ) le 15/03/2002 à 15:48. (lien). Évalué à 2.
        Mais le problème de base reste le meme : en ajoutant des couches logiciels on s'éloigne du hard et on perd en performance.
        
        Mais on ajoute pas de couches logicielles... tu n'as pas compris ce qu'était un µ-noyau justement.
        
        Linus n'aime pas emacs et Hurd. RMS aime les unoyaux, Linus ne les aime pas.
        
        Emacs c'est un micro-noyau ? Et la marmotte ? Le rapport entre Emacs et le Hurd STP (à part que ce sont des projets GNU ?)
        
        Et encore une fois je te répète que RMS n'a pas grand chose à voir avec le Hurd et qu'il ne contrôle pas du tout l'évolution du projet.
        
        [^]Re: RMS est mort, vive Linus
        
        Posté par woof () le 15/03/2002 à 17:17. (lien). Évalué à 0.
        emacs n'est pas un micro noyau, mais un maxi-kernel =)
        
        <donotfeedthetroll figlet="yes">
- [^]Re: RMS est mort, vive Linus
  
  Posté par Pascal Havé () le 14/03/2002 à 17:20. (lien). Évalué à 1.
  Je ne suis absolument pas d'accord.
  Je vois personnellement Hurd, non pas prenant aujourd'hui la place de Linux , mais comme une expérience afin de créer un nouvel OS libre pour demain.
  Sa structure micro-noyau, le freine aujourd'hui, mais tout évolue; avec la rapide évolution de la technologie (matériel et logiciel), peut on être sûr que Hurd ne peut avoir une place demain (sécurité, parallélisme, ...)
  Toute expérience prend du temps (surtout quand on change d'avis en cours de route ;), commence par des essais (souvent non optimisés) et apporte des réponses différentes (j'adore la gestion des droits et le VFS sous Hurd).
  Le premier système Unix fut écrit en assembleur puis réécrit en C, pour le rendre plus facile à dévolopper; le premier java était très lent, mais on est passé à l'air du JustInTime.
  Oui, Linux est actuellement très défendu car c'est un peu grâce à lui que nous sommes ici, mais je pense que chacun peut avoir sa place, chacun peut surement quelque chose à l'autre.
- [^]Re: RMS est mort, vive Linus
  
  Posté par rgardon () le 14/03/2002 à 17:24. (lien). Évalué à 2.
  >Le but d'un micro-noyau c'est surtout pour les >développeurs [snip]
  
  bon j'ai coupe mais ca ne change rien. L'interet est aussi grand pour les utilisateurs : avec un micro noyau, on met ce qu'on veut autour, mais vraiment ce que l'on veut --> on peut a peu pres tout faire, et ce sur des configs tres modestes si on ne fait presque rien tourner autour du noyau.
  
  >mais il y a toujours des articles pour dire >n'importe quoi
  
  l'argument peut etre retourne : il y aura tjs des articles pour dire que ca ralentit tout mais...
  
  >Les belles idées sur le papier on a vu ce que ca >a donné avec le communiste
  
  bon la avis perso, vous auriez pu trouver une autre comparaison :)
  
  >Il suffit de se baser sur certaines mesures >précises pour prouver ce qu'on veut prouver.
  
  et plus loin
  
  >mais j'ai des copains qui ont utilisés Hurd et >Mac OS X et il m'ont dit que...
  
  J'ai appris a mes depends que se baser sur "ce que disent les copains" est *tres* mauvais. N'y voyez aucune agressivite de ma part, mais je ne pense pas que cet argument soit recevable.
  
  >Hurd ne remplacera _jamais_ Linux car si Hurd >devait triompher Hurd aurait _déjà_triompher
  
  Linux a mis plus de qqes annees a s'imposer en tant qu'alternative viable a tout le reste (enfin aux OS proprios), je ne pense donc pas que le Hurd puisse etre le sujet de telles pensees. Et surtout il ne me semble pas qu'il soit question que Hurd remplace Linux.
  - [^]Re: RMS est mort, vive Linus
    
    Posté par Cyril Chevrot () le 14/03/2002 à 18:58. (lien). Évalué à 2.
    
    >mais j'ai des copains qui ont utilisés Hurd et >Mac OS X et il m'ont dit que...
    
    J'ai appris a mes depends que se baser sur "ce que disent les copains" est *tres* mauvais. N'y voyez aucune agressivite de ma part, mais je ne pense pas que cet argument soit recevable.
    
    Je suis tout à fait d'accord. Personnellement tous mes jugements repose principalement sur _mon_ expérience. Je considère que l'expérience est au dessus de tout article, avis d'expert, avis de copain. Maintenant mieux vaut avoir l'information d'un copain que pas d'information du tout.
    
    Et surtout il ne me semble pas qu'il soit question que Hurd remplace Linux.
    
    Je n'ai rien contre le Hurd, ce qui m'énerve c'est le quasi mépris de Stallman envers Linux. Et le mépris de Linus envers le Hurd me direz vous ? Je vous l'accorde ca doit etre un truc de chef d'etre braqué. D'un autre coté faut bien qu'ils prennent des décisions. Et as nous de choisir notre camp.
    - [^]Re: RMS est mort, vive Linus
      
      Posté par Etienne () le 14/03/2002 à 19:11. (lien). Évalué à 3.
      Maintenant mieux vaut avoir l'information d'un copain que pas d'information du tout.
      Oui mais tant qu'on ne s'est pas fait son propre avis, ce n'est pas la peine de partager l'opinion de ses copains, sinon avec des avis de copains de copains ca peut aller loin.
      
      D'un autre coté faut bien qu'ils prennent des décisions. Et as nous de choisir notre camp.
      
      Il n'est pas question de choisir un camp, la communauté n'est pas en guerre. On a encore le droit de faire du multiboot Linux/Hurd/Bsd/Atheos et tout ce qu'on veut.
- [^]Re: RMS est mort, vive Linus
  
  Posté par Manuel Menal (page perso, ) le 14/03/2002 à 18:09. (lien). Évalué à 6.
  Mon Dieu.. On en tient un beau. Je me demandais quand ils allaient arriver, les gens qui, en dépit de tout ce qu'on peut leur répondre, tienne toujours le même discours, toujours le même, uniforme, sans rien.
  
  Les micros noyau, ca pue
  
  J'ai déjà répondu à ça, exactement le même titre. Je t'invite à consulter: http://linuxfr.org/comments/thread.php3?news_id=6461&com_id=889(...)
  et si tu as des arguments, de venir nous voir, sur #hurdfr sur OpenProjects, notamment.
  
  Hurd = 10 ans de développement et toujours pas pret
  
  Où ? Quand ? Le Hurd n'est pas activement développé depuis dix ans. Du tout. Son développement a commencé en '90, il est vrai. Mais, il est généralement admis que son développement a été arrêté pendant près de sept ans, pour n'être repris environ qu'en 99, et que de façon très progressive, le temps que le Hurd sorte de cette réputation de projet du passé dont tu es la preuve vivante qu'elle n'a pas cessé.
  
  Le but d'un micro-noyau c'est surtout pour les développeurs, possibilité de développer des modules en mode utilisateur, possibilité d'avoir des systèmes de fichier en tournant en mode utilisateur, ...
  
  De quoi ? Si le Hurd apporte de nombreux avantages aux développeurs, il me semble avoir suffisamment dit et montré comment une architecture basée sur un micro-noyau pouvait apporter nombre d'avantages à l'utilisateur, notamment en lui permettant d'avoir ses propres montages - notamment, NFS - très facilement, comment il pouvait, via un « addauth » acquérir facilement des droits plus élevés sans avoir le mot de passe root, etc. De plus, il me semble que c'est l'affaire de tous d'avoir une machine qui ne reboote pas pour un rien, une machine extrêmement sécurisée, qui n'a
  pas besoin d'être rebootée de façon régulière pour mise à jour du noyau, etc.
  
  Le problème c'est que si le passage de messages et la communication entre les processus rend le développement tellement compliqué qu'il multiplie le temps de développement par 10 je vois pas trop l'intéret pour les développeurs d'utiliser un m icro-noyau.
  
  As-tu déjà regardé une seule fois les sources d'un programme qui fait usage du système d'IPC que tu évoques ? Le développement de telles applications n'a _rien_ de complexe. Ce qui est complexe, en revanche, effectivement, c'est de repenser une architecture de fond en comble, d'essayer de faire tout de la meilleure façon possible plutôt que de le faire de façon à ce que ça marche maintenant, et qu'après, on se rende compte que c'est absolument immaintenable, inadaptable, et qu'il faut tout refaire un nombre impressionant de fois..
  
  Effectivement, le développement de Linux a été beaucoup plus facile, puisque, comme le disait très justement Linus il n'y a pas longtemps, Linux n'a pas de design, il se contente de reprendre tous les principes utilisés par Unix - dont l'utilité a certes été prouvée, mais 30 ans d'utilisation d'Unix a aussi montré que ce système avait un certaines nombres d'erreurs de conceptions, et qu'il n'était pas forcément adapté
  aux systèmes d'aujourd'hui de bien des manières. Mais, devrait-on pour autant se contenter de refaire à chaque fois la même chose, par des gens différents ? (avec la différence, certes, que Linux est un logiciel libre, ce qui était son avantage majeur.) L'évolution serait donc totalement condamnée dans le monde de l'informatique ? Je ne l'espère pas.
  
  De plus rajouter des interfaces et des couches d'abstraction c'est peut-etre beau sur le papier, mais à chaque fois ca entraine des chutes de performance terribles.
  
  De quelle couche d'abstraction parles-tu ? De quelle interface ? J'avoue ne pas comprendre à quoi tu fais référence. En revanche, pour aborder le thème de la performance des systèmes à base de micro-noyaux, il est claire qu'elle n'est pas évidente, étant donner qu'un système multi-serveurs à micro-noyau implique une multiplication des changements de contexte, et des appels noyaux concernant l'IPC. L'important est justement à ce niveau: pour qu'un système à base de micro-noyau soit rapide, au moins aussi rapide si ce n'est plus qu'un système à base de noyau monolithique, il faut que ces appels concernant l'IPC soient extrêmement lightweight, extrêmement rapides, et n'entraînes pas le même coût en performance qu'un appel système « traditionnel. ».
  Dans le cas de Mach, c'était déjà le cas: les appels à mach_msg étaient _extrêmement_ moins coûteux que les autres kernel traps. Cependant, Mach n'est pas un modèle de vélocité, et faire un système performant basé sur ce micro-noyau n'est pas évident. La rapidité, et la concision, ont été tdepuis le début le but du projet L4, comme je l'ai déjà dit. Ils y sont _vraiment_ parvenus, grâce à des moyens très intéressants et très savants, expliqués pour beaucoup sur http://www.l4ka.org/publications/(...) . De plus, une fois le problème de l'IPC réglé, l'architecture à base de micro-noyaux peut s'avérer plus performante qu'une architecture à base de noyaux monolithiques. En effet, nombre d'appels qui sont traditionellement des appels systèmes ne sont plus implémentés dans le noyau, mais dans la libc (C Library), et ne se servent que de RPC vers les programmes chargés de l'exécution réelle de tels appels. Ainsi, ils économisent le gros overhead produit par un appel système « traditionnel » dans un programme.. (qui n'est pas négligeable: vous êtes vous déjà interrogés sur le pourquoi de la stdio - bufferisée, donc - alors qu'on pourrait utiliser read() et write() - comme woof - ? Avez-vous déjà comparé les performances d'un programme effectuant des opérations d'I/O fréquentes utilisant read()/write() ou printf()/fgets() ?)
  
  ertes il y aura toujours des articles pour dire que la perte de performance n'est pas si terrible que ca, mais il y a toujours des articles pour dire n'importe quoi.
  
  Argument frappant, je dois le dire. Quand l'article, d'une dizaine de pages, te décris en détail les modifications effectuées sur Linux pour qu'il soit porté sur L4, ce qu'on a testé précisément - et pourquoi - et qu'il te donne les performances obtenues par différentes batteries de tests réalisées par des logiciels _indépendants_ des auteurs, et qui ont été choisis parmi les meilleurs, et qu'il se trouve que ce benchmark est très facilement reproductible, qu'il l'a été fait, et que les résultats ont toujours été dans le même ordre d'idée, voire même meilleurs que ceux proposés dans le document, je sais pas que demander de plus.. Si tous les benchmarks pouvaient être aussi clairs, impartials, ...
  D'autant plus que ce benchmark n'a pas été fait dans un but de FUD, puisqu'il ne s'agit pas pour l'équipe de L4Ka - des universitaires, principalement - de vendre leur produit, mais bien de tester leurs avancées _réelles_, pour eux-même, dans un but scientifique...
  
  Il suffit de se baser sur certaines mesures précises pour prouver ce qu'on veut prouver.
  
  Soit plus précis. Que proposerais-tu de tester que les réalisateurs du benchmark n'ont pas testés ? J'ai sous la main un L4Linux tout à fait disponible, et en mesure d'exécuter tout test que tu désirerais lui faire subir.
  
  Personnellement Java => ajout d'un couche d'abstraction (vm) => super long.
  
  Quel rapport ? Il n'y a pas de « couche d'abstraction », ou en tous pas à la base, dans le Hurd. Le micro-noyau n'est pas du tout une couche d'abstraction.
  
  cependant, je trouve qu'un des seules avantages de windows sur Linux est justement d'etre plus rapide au niveau de l'affichage (car le système de fenêtrage et justement dans le noyau).
  
  Cela reste à prouver.. De plus, de telles pratiques s'avèrent être, de fait, des pratiques courantes dans des énormes développements propriétaires comme l'est Windows, où les développeurs cèdent souvent à la facilité - car l'utilisation d'un « fourre-tout ·» reste toujours plus aisée dans un premier temps que la séparation laire, la modularité. Ainsi, le programmeur débutant a toujours tendance à faire un seul fichier source, une seule fonction, etc. La programation d'un système multi-serveurs à base de micro-noyau demande effectivement plus de rigueur.
  De plus, les principes des développeurs du Hurd - toujours au mieux, toujours différent - rendent effectivement le développement du Hurd un peu plus difficile. Mais je suis convaincu que, comme la séparation interface/reste, la séparation en modules, fonctions, etc., cette rigueur, difficile à acquérir au début, rend beaucoup de tâches pour la suite des choses beaucoup plus faciles.
  
  Notamment, le fait que toutes ces facilités ayant recours à des hacks x86-only - mais performants - aient été refusés de tout temps par les concepteurs du Hurd a permis à des gens de porter le Hurd sur PPC en à peine quelques jours et 2/3 modifications.. Comparez avec le temps qu'il a fallu pour un port de Linux sur PPC, et sur l'avancée de ce port.
  
  les belles idées sur le papier on a vu ce que ca a donné avec le communiste et apparemment on peut généraliser à pas mal de domaine la leçon.
  
  C'est cette partie qui me fait franchement penser qu'il s'agit d'un fake - voire d'un piège à Kilobug. Mais, ces arguments étant extrêmement classiques, je tiens à y répondre une fois pour toutes.
  
  Le seul micro noyau que j'ai utilisé pour l'instant est minix (qui est nettement plus long que linux), mais j'ai des copains qui ont utilisés Hurd et Mac OS X et il m'ont dit que les performances étaient moins bonne que sur les OS monolithiques.
  
  Le Hurd, basé sur GNU Mach, est aujourd'hui nettement moins performant que Linux, pour de multiples raisons. On ne peut pas comparer les performances d'un logiciel se voulant être à la base de systèmes utilisés partout dès maintenant, et un projet qui n'est pas abouti et dont le développement est loin d'être fini..
  
  De plus j'ai lu qq part que de toutes facon on n'avait de plus en plus de ressources processeurs et donc que les performances n'étaient pas si primordiales que ca. Cet argument est l'argument (récurrent) e plus débile de l'histroire de l'informatique. On aura _jamais_ trop de ressource et donc on se doit de concevoir les systèmes le plus efficacement possible.
  
  Ceux qui profèrent ce genre de non-sens sont des ânes. Mais, qu'est-ce que cela a à voir avec le sujet qui nous occupe ?
  
  Quand à la modularité, avec Linux on a la modularité au niveau du source. De plus les modules ne constituent pas du rafistolage mais plutot le juste milieu.
  
  Tu compares des choses qui n'ont rien à voir.. Ai-je cité, dans tous mes posts, des choses qui seraient faisables avec les modules Linux ? Je ne le pense sincèrement pas. Les modules ont été une grande avancée pour Linux, et ce sont de très bonnes choses. D'ailleurs, les modules chargeables dynamiquement existent également dans certaines versions de Mach - puisque traditionellement, les drivers matériels sont dans Mach et non en user space, bien que ce micro-noyau le permette - en offrant la possibilité d'envoyer des messages spéciaux au micro-noyau qui se chargent de les traduire en interruptions matérielles.
  
  Hurd ne remplacera _jamais_ Linux car si Hurd devait triompher Hurd aurait _déjà_triompher.
  
  Pourquoi viens-tu parler du Hurd, alors ? Tu n'es pas devin, ni moi. Je ne peux prévoir l'avenir du Hurd, l'avenir de GNU, ni l'avenir de GNU. Si tu veux montrer que le Hurd n'a aucun avenir, attends. Et s'il ne triomphe jamais, tu pourras jubiler en te disant « j'avais raison! ». En attendant, tu n'as pas de moyen de démontrer tes propos, si ce n'est d'attendre. Alors, je te propose que tu attendes en faisant autre chose, pendant qu'on continue notre projet. Et voyons bien ce qui arrivera.
  
  N'en déplaise à Stallman et à son égo surmesurer.
  
  Encore un non-argument, trollesque, sans _aucun_ intérêt - nous sommes pas là pour juger des personnes, que tu ne connais pas personellement, qui plus est. Et je ne pense pas que la mort du Hurd soit un tel drame pour Stallman: il l'a cru mort - Stallman suit peu le développement du Hurd, il faut l'avouer - pendant longtemps, et il a l'air de tenir le choc.
  - [^]Re: RMS est mort, vive Linus
    
    Posté par Cyril Chevrot () le 16/03/2002 à 15:14. (lien). Évalué à 0.
    Bon j'avais déjà répondu mais le message n'a pas été posté :((
    
    Mon Dieu.. On en tient un beau
    
    Merci
    
    J'ai déjà répondu à ça, exactement le même titre
    
    Ce n'était exactement le même titre, les micro-noyaux, ca pue, c'est plus percutant que les micro-noyaux, c'est nul.
    
    qui n'a pas besoin d'être rebootée de façon régulière pour mise à jour du noyau
    
    Je ne sais pas si tu es au courant mais Linux est de plus en plus utilisé par des personnes qui ne savent même pas ce qu'est un noyau. Avancé cet argument pour démontrer que le HURD n'est pas seulement destiné aux développeurs c'est vraiment nul.
    
    De quelle couche d'abstraction parles-tu ? De quelle interface ? J'avoue ne pas comprendre à quoi tu fais référence.
    
    Avec un noyau monolithique, un appel système va directement tapé dans le noyau.
    Avec un micro-noyau, les appels systèmes sont implémentés au niveau des serveurs (1ère interface), les serveurs font appels aux services fournis par les taches d'entrées sorties (2 ème interface) et enfin les taches d'entrées sorties font appels au micro-noyau qui s'occupe de gérer les ressources et de passer les messages (3ème interface). Voila ce que j'appelle ajout de niveaux d'abstraction. (Enfin c'est ce qui se passe sous minix, je connais très mal HURD)
    
    Cependant, Mach n'est pas un modèle de vélocité, et faire un système performant basé sur ce micro-noyau n'est pas évident.
    
    Alors pourquoi l'utiliser s'il y a moyen de faire mieux ?
    
    <i>
    > Certes il y aura toujours des articles pour
    > dire que la perte de performance n'est pas si
    > terrible que ca, mais il y a toujours des
    > articles pour dire n'importe quoi.
    
    Argument frappant, je dois le dire.
    <i>
    
    Je confirme, et j'en suis fier ;)
    
    > Il suffit de se baser sur certaines mesures
    > précises pour prouver ce qu'on veut prouver.
    
    Soit plus précis. Que proposerais-tu de tester que les réalisateurs du benchmark n'ont pas testés ?
    
    Moi ce que je souhaiterais pour changer mon avis sur les micro-noyaux c'est que Hurd soit aussi rapide (au niveau de l'utilisation j'entends) que Linux et que ce soit une _priorité_.
    
    Pourquoi viens-tu parler du Hurd, alors ? Tu n'es pas devin, ni moi.
    
    Pipo Argument
    
    Prédiction de l'avenir => Test sur la compréhension du présent. Il est toujours bon d'essayer de prévenir l'avenir. Les personnes qui prédisent très mal l'avenir sont des personnes qui ont une mauvaise compréhension du présent et inversement. Ainsi pour savoir si l'on a une bonne compréhension du présent, il est bon de faire des prédictions, de les retenir et de voir quand le futur devient présent si l'on avait raison ou non. Et si l'on avait tort ils est bon de se poser des questions
    
    > N'en déplaise à Stallman et à son égo surmesurer.
    
    Encore un non-argument, trollesque, sans _aucun_ intérêt
    
    Si les trolls n'ont aucun intérêt, que fais-tu sur linuxfr ! Les trolls sont primordiales car ils permettent de se défouler ! Et se défouler c'est important, sinon comment expliquer le succès des doom-like, quake-like, des films violents et ... de linux (qui permet de se défouler sur microsoft)
    
    nous sommes pas là pour juger des personnes, que tu ne connais pas personellement
    
    Tu es le roi des arguments à la con à ce que je vois. Je ne connais pas personnellement les hommes politiques et cela ne m'empeche pas de les juger et ne m'empechera pas d'aller voter pour l'un d'eux aux prochaines élections. C'est meme mon devoir de citoyen.
    - [+] [^]Re: RMS est mort, vive Linus
      
      Posté par Michel Galle () le 10/05/2002 à 13:59. (lien). Évalué à -1.
      mr , vous n'avez manifestement aucune connaissance objective sur HURD
      
      vous ne répondez pas aux arguments techniques sur les possibilités de HURD que linux ne peut _pas_ reproduire.
      
      vous melangez tout
      vous ne repondez pas sur le fait que HURD permettrait de se passer de gnome-vfs ou les kioslave (et faire la même chose en plus rapide)
      
      vous dites :
      " Si les trolls n'ont aucun intérêt, que fais-tu sur linuxfr ! Les trolls sont primordiales car ils permettent de se défouler ! Et se défouler c'est important, sinon comment expliquer le succès des doom-like, quake-like, des films violents et ... de linux (qui permet de se défouler sur microsoft)"
      
      je pense plutot que c'est vous qui avez rien à faire sur linuxfr. les trolls sont une pertes de temps. vous répondez, ecrivez a coté du sujet, vous servez à rien.
      
      on se fiche que vous vous defouliez, linuxfr est un site d'informations et une place publique pour discuter autour de linux et les logiciels libres (et hurd s y inscrit)
      manifestement il y a des gens ici qui connaissent bien mieux que vous linux ou hurd.

La mort annoncée de GNU/Linux ?

Posté par Anonyme () le 13/03/2002 à 13:14. (lien). Évalué à 36.

Pas vraiment pour tout de suite, non plus... pour commencer, il faut que le µnoyau sur lequel repose le Hurd supporte plus de matériel...

Et AMA, quoique puisse en dire RMS, Linux est bien trop populaire et implanté (même si, relativement à une certaine situation monopolistique, c'est faible) pour que GNU remplace GNU/Linux.

Les éditeurs ont déjà du mal à se tourner vers Linux, je vois pas pourquoi ils se tourneraient plus vers le Hurd et son µnoyau (en plus, je suis persuadé que cette histoire de µnoyau va faire peur).

Et qu'on ne me réponde pas que les drivers de linux seront portés, ça veut bien dire ce que ça veut dire : GNU aura encore besoin de Linux...

Le problème du Hurd, AMA, c'est qu'il arrive un peu trop tard (d'ailleurs, il est pas encore arrivé), au moment même où les gens se tournent de plus en plus vers les LL en général et vers GNU/Linux en particulier...

Enfin, on verra bien...

[^]Re: La mort annoncée de GNU/Linux ?

Posté par Rin Jin (page perso, ) le 13/03/2002 à 13:23. (lien). Évalué à 33.
Je ne suis pas totalement d'accord, le fait qu'un nouvel OS arrive est toujours, AMHA, une bonne chose. Je ne pense pas que l'on arrive à la disparition de Linux ou de Hurd et donc à un GNU uniforme.
Quand on regarde ce qui permets de faire tourner les logiciels GNU, on trouve déjà plus d'un noyeau (Linux évidement, Hurd mais aussi les BSD et peut-être d'autre unix que je ne connais pas).
Ce que j'apprécie dans Gnu, c'est le choix, alors un nouveau noyeau utilisable en production est pour moi une bonne nouvelle.
Dans un premier temps, je n'imagine pas Hurd inquiéter réellement les autres noyeau libre mis en place pour les raisons que tu donnes mais par la suite, si celui ci s'avére meilleurs dans certains domaines, pourquoi ne pas l'y mettre?
On continuera d'avoir le choix et celui-ci se sera étoffé, tant mieux.

--
"On obtient plus de chose en étant poli et armé qu'en étant juste poli" Al Capone

[^]Re: La mort annoncée de GNU/Linux ?

Posté par ufoot (page perso, ) le 13/03/2002 à 13:25. (lien). Évalué à 29.
Linux est bien trop populaire et implanté (même si, relativement à une certaine situation monopolistique, c'est faible) pour que GNU remplace GNU/Linux.
Je pense que le but est pas de "remplacer" definitivement Linux.

Peut-etre que la FSF se mettra a utiliser le Hurd et seulement le Hurd, mais c'est leur probleme et c'est tout naturel vu que le Hurd est leur projet.

Maintenant, beaucoup continueront a utiliser Linux, certains utiliseront Hurd, d'autres FreeBSD, et d'une maniere generale chacun fera ce qu'il voudra.

Perso je trouve ca bien qu'il y ait plein d'OS comme le Hurd, Atheos, etc...

Honnetement, je pense qu'une plate-forme comme le Hurd sera delaissee par les "editeurs" de logiciels proprietaires. Maintenant, je pense sincerement que la FSF s'en fiche un peu qu'Oracle porte ses produits pour Hurd. A moins qu'Oracle sorte ses produits sous une license libre evidemment 8-)
- [^]Re: La mort annoncée de GNU/Linux ?
  
  Posté par Gaël Le Mignot (page perso, ) le 13/03/2002 à 14:18. (lien). Évalué à 22.
  Je suis d'accord sur le fond: la diversité est une bonne chose.
  
  Par contre, il faut faire attention à ce que l'on dit: le Hurd n'est pas un OS, ce n'est même pas vraiment un noyau, c'est un ensemble de serveurs pour micro-noyau pouvant être utilisés (en conjonction avec un µ-k) pour remplacer un noyau monolithique dans un système (ici le système GNU).
  
  GNU/Linux et GNU ne sont donc pas deux système complétement différents comme le sont GNU/Linux et FreeBSD par exemple.
  
  Pour les applications propriétaires, si la compatibilité binaire entre GNU/Hurd et GNU/Linux n'existe pas actuellement, elle ne pose aucun problème théorique et sera implémentée dés que quelqu'un jugera bon de le faire (et l'intéret premier de ça n'est pas de faire tourner des applis propriétaires AMHA, mais de faciliter les dual-boots GNU/Linux-GNU/Hurd).
  - [^]Re: La mort annoncée de GNU/Linux ?
    
    Posté par ufoot (page perso, ) le 13/03/2002 à 14:34. (lien). Évalué à 12.
    > faciliter les dual-boots GNU/Linux-GNU/Hurd
    
    C'est clair que si on pouvait partager un meme /usr/bin entre un systeme GNU/Linux et un GNU/Hurd, ca serait plutot pas mal...
    - [^]Re: La mort annoncée de GNU/Linux ?
      
      Posté par Pierre Jarillon (page perso, ) le 13/03/2002 à 23:58. (lien). Évalué à 2.
      Pour /usr/bin c'est peu probable, mais poourquoi pas une utilisation commune de /etc /var /proc /home ?
      A priori, cela ne me semble pas du tout impossible, et je le crois souhaitable.
      - [^]Re: La mort annoncée de GNU/Linux ?
        
        Posté par Etienne () le 14/03/2002 à 08:43. (lien). Évalué à 3.
        mais poourquoi pas une utilisation commune de /etc /var /proc /home
        pour /etc ca peut etre envisageable a la limite mais il y a le probleme des scripts d'init qui ne seront pas les meme, et la crontab qui doit faire appel exclusivement a des programmes disponibles sur les 2 systemes. D'ailleurs je ne suis pas sur qu'on ait le droit de monter /etc sur une partition differente de /.
        pour /var, il faut malgre tout faire attention, on ne peut pas partager par exemple les fichiers syslog sinon ca devient vite la pagaille. Pour le mail /var/mail c'est une bonne idee
        /proc n'est pas une partition du disque dur, c'est un repertoire qui contient des informations sur le systeme mais qui est gere par le noyau sans etre ecrit nul part.
        /home se partage certainement tres bien si on a le meme systeme de fichier et que l'on fait attention a avoir les memes UID pour les memes utilisateurs.
        
        Etienne
      - [^]Re: La mort annoncée de GNU/Linux ?
        
        Posté par Benoît Sibaud (Jabber id, page perso, ) le 14/03/2002 à 08:45. (lien). Évalué à 3.
        Pour /etc, tu risques d'avoir des surprises lors des mises à jour. Genre ta Debian GNU/Linux a mis à jour /etc, et derrière ta Debian Hurd tente de faire la même chose. Le problème se pose aussi sur /var (création éventuelle de nouveaux répertoires/suppression des anciens), et sur /home : par exemple entre Gnome sur Potato et Gnome sur Woody, il faut faire une conversion via machinmetadb par exemple (donc avoir la conf correspondant aux version des logiciels installés). Bref à moins d'avoir une Debian GNU+GNU/Linux avec mise à jour des 2 simultanément, ça va poser des problèmes.
        
        Déjà c'est chiant de partager des binaires entre deux glibc différentes.

[^]Re: La mort annoncée de GNU/Linux ?

Posté par Gaël Le Mignot (page perso, ) le 13/03/2002 à 13:31. (lien). Évalué à 21.
il faut que le µnoyau sur lequel repose le Hurd supporte plus de matériel

Ce sera fait d'ici quelques mois avec le passage à OSKit Mach. Sinon, l'un des gros avantages des µ-noyau (et de Mach) c'est qu'il possible d'implémenter énormément de drivers uniquement en user space.

Linux est bien trop populaire et implanté pour que GNU remplace GNU/Linux.

Le passage de GNU/Linux est presque transparent (ou le sera lorsque les problèmes du Hurd seront corrigés), et une immense majorité d'applications ne demandent qu'un portage minimal. En particulier avec la Debian GNU/Hurd (http://www.debian.org/ports/hurd/index(...)).

Les éditeurs ont déjà du mal à se tourner vers Linux, je vois pas pourquoi ils se tourneraient plus vers le Hurd et son µnoyau

Pour des raisons de sécurité ? De fiabilité (lorsque tout marchera bien) ? Pour tous les avantages qu'il apporte(ra) ?

[^]Re: La mort annoncée de GNU/Linux ?

Posté par Robert Palmer (page perso, ) le 13/03/2002 à 13:37. (lien). Évalué à 16.
J'ai surtout l'impression que c'est un effet d'annonce. Un moyen pour dire : "Le Hurd existe bel et bien et avance, ainsi que GNU par la même occasion."

C'est un peu un piqure de rappel que fait RMS aux développeurs et utilsateurs de LL. Mais ça ne changera rien aux destinés de Linux et du Hurd. Si ce dernier veut percer, c'est avant tout avec ses qualités techniques qu'il devra le faire. Pas parce que RMS le veut.

Mais bon, moi je suis favorable à la diversité alors bonne chance aux deux.
- [^]Re: La mort annoncée de GNU/Linux ?
  
  Posté par Anonyme () le 14/03/2002 à 00:39. (lien). Évalué à 3.
  Je suis tout à fait d'accord, et je suis moi aussi pour la diversité, mais en fait, je réagissais au titre (certainement volontairement) provocateur.
  
  Cela dit, RMS ne présente pas les choses sous cette forme (encore heureux).

[^]Re: La mort annoncée de GNU/Linux ?

Posté par reno () le 13/03/2002 à 21:44. (lien). Évalué à 3.
> Les éditeurs ont déjà du mal à se tourner vers Linux, je vois pas pourquoi ils se tourneraient
> plus vers le Hurd et son µnoyau (en plus, je suis
>persuadé que cette histoire de µnoyau va faire peur)

Je ne vois pas pourquoi tu penses que le micronoyau leur ferait peur!
Les éditeurs logiciels se fichent éperdument de savoir si le système d'exploitation utilise un micro-noyeau, un exo-kernel ou un pico-kernel ce qui les interesse c'est de pouvoir vendre leurs produits en quantité suffisante pour faire du bénéfice, un point c'est tout!

Ce qui AMHA n'est pas pres d'arriver pour GNU déja que pour Linux c'est pas (encore) le cas (ça dépend des domaines, bien sur).

rms l'utilise deja ...

Posté par tfing () le 13/03/2002 à 13:16. (lien). Évalué à 23.

mais depuis peu seulement

si je me souviens bien, il avait dit lors de son speech du samedi matin au fosdem que depuis qq jours il utilisait le hurd sur son portable
alors si meme rms l'utilise depuis peu seulement, le public vise par une release cette annee ne peut-etre que des 100%-geeks

a part ca, ca fait quand meme plaisir d'entendre qu'un nouveau systeme devient utilisable et ca ne peut qu'amener des developpeurs a s'y interesser

ca serait bien que des gens qui l'utilise deja postent des commentaires pour faire un peu de propagande (j'ai pas dit pour troller ...)

[+] [^]Re: rms l'utilise deja ...

Posté par Infernal Quack (Jabber id, page perso, ) le 13/03/2002 à 13:32. (lien). Évalué à -5.
C'est déjà une très mauvaise nouvelle : ca veut dire que emacs tourne sur GNU.

Beurk :(=

[^]Re: rms l'utilise deja ...

Posté par Sylvain Rampacek (Jabber id, page perso, ) le 13/03/2002 à 13:42. (lien). Évalué à 1.
Quelqu'un aurait déjà testé ce noyau ?

Par ce que j'en ai entendu dire que des "on dit"...

Et surtout, qu'apporte-t-il de plus que le noyau Linux que l'on connait bien ?
- [^]Re: rms l'utilise deja ...
  
  Posté par Benoit Rousseau () le 13/03/2002 à 16:43. (lien). Évalué à 9.
  J'avais essaye l'an dernier de l'installer sur un vieux PC et ca avait ete une grosse galere parcequ'il n'avait pas d'acces internet et pas de lecteur CD...
  
  Une fois le noyau installe, c'est assez facile d'ajouter des programmes : Debian/Hurd oblige...
  
  Par contre on a pas pousse jusqu'a l'installation d'un serveur graphique...
  
  http://www.hurdfr.org/Docs/Hurd_fr/Guide(...) avait ete notre guide...
- [^]Re: rms l'utilise deja ...
  
  Posté par Manuel Menal (page perso, ) le 13/03/2002 à 22:51. (lien). Évalué à 45.
  Oui, j'ai « testé » le Hurd. Non, ce n'est pas un noyau. Au risque de passer pour un vieux radoteur, ce que je suis probablement, me direz-vous, « est noyau tout code qui tourne avec les permissions spéciales du proc' réservées au .. noyau, soit le fameux 0 sur processeurs Intel ». C'est ce qui différencie, d'ailleurs, le mode noyau du mode utilisateur. (kernel space.. user space). Tout le code du Hurd tourne en mode utilisateur. Il s'agit juste d'une série d'applications _normales_, n'ayant pas plus de permissions que les autres.
  
  Ces précisisons étant dîtes, répondons. Qu'apporte-t-il ? Il faudrait bien plus d'un commentaire pour répondre à cette question. (la partie de ma présentation sur le Hurd à ce sujet fait déjà plus de cinq pages, et j'en suis à juste un peu plus du tiers :). À la base, l'esprit du Hurd est l'esprit du GNU - ou ce qu'il devrait être: étudier et reprendre les logiciels existants, essaye d'en retirer les avantages et les limites, et essayer de les casser, en faisant au maximum novateur, au maximum repensé. Pas juste une réécriture. C'est là où le Hurd diffère de Linux: Linux n'est qu'une réécriture d'Unix, où les améliorations résident dans l'implémentation. Le Hurd est différent d'Unix, puisque GNU's not Unix.
  
  Les différences sont multiples. La première, et la principale, à laquelle on pense automatiquement est l'architecture d'un système GNU: au lieu d'un très gros programme - monolithique, donc - fournissant un tas de fonctionnalités dîtes de base pour un OS - là, la définition de ce qu'est un service de base n'est pas claire, puisque la seule vraiment rigoureuse serait de dire que c'est ceux fournit par le noyau Unix à la base - on a une serie de petits programmes indépendants, qui se chargent chacun d'une tâche - pfinet, pour tout ce qui est PF_INET (PF <=> Protocol Family, je vous laisse deviner pour INET), nfs pour le NFS, ext2fs pour ext2, password pour le serveur de passwords, etc, ces applications -- appelées serveurs -- communiquant entre elles via le micro-noyau. Ceci présente plusieurs avantages:
  
  * Une plus grande modularité, au sens où l'on peut bâtir facilement des systèmes extrêmement minimaux ne contenant que les quelques services de base - les quatre ou cinq serveurs nécessaires au Hurd.
  
  * Une plus grande stabilité. Entendons nous bien,
  le Hurd n'apporte pas la stabilité absolue, les programmeurs sont malgré tout humains. :). Cependant, ce que peut faire un OS-base, c'est de réduire la gravité de ces bugs afin qu'un problème dans une application puisse difficilement rendre l'ensemble du système totalement inutilisable.
  Il est clair que plus le programme est gros, plus il y'a de chance qu'un bug arrive. Ainsi, Linux devenant de plus en plus gros, il arrive, fréquemment - quasiment de plus en plus ;-) - qu'un bug dans une partie non-essentielle de Linux survienne, ce qui provoque, bien évidemment, un crash de l'ensemble du noyal. Sous le Hurd, dans la majorité des cas - c'est à dire, dans les cas où le bug survient sur un des serveurs n'étant pas essentiel a la « survie » du système - seule l'application responsable crashera, et ça n'ira pas plus loin. Par exemple, lorsque Jeff Bailey a mis, il y'a quelques temps de ça un serveur Web sous GNU, et l'a annoncé un peu partout, et que la nouvelle s'est retrouvée sur /., pfinet n'étant pas très solide, il n'a évident pas tenu la charge d'un slashdottage en règle.. (pensez bien, un truc comme ça). Dans le cas de Linux, cela aurait causé un crash du système et une non-disponibilité pendant quelques temps. Dans le cas du Hurd, il a suffit de relancer pfinet, et c'était reparti pour un tour. De plus, les opérations risquées peuvent facilement être faîtes dans un sub-Hurd, équivalent de UML - User-Mode Linux - qui est totalement naturel pour le Hurd, puisqu'il ne s'agit que de relancer des applications normales, et ne pose aucun problème -- contrairement à UML qui évolue lentement, nécessite des patches, et, du fait que Linux n'est pas prévu pour ça, pose pas mal de problèmes encore..
  
  * Une plus grande disponibilité, en partie pour les questions de stabilité décrites ci-dessus, et également parce qu'il est plutôt rare d'avoir à changer le noyau, et que le changement de presque tout le reste peut se faire « à chaud ». De plus, la flexibilité pourrait imaginer deux pfinet tournant en parallèle, l'un relayant l'autre dès que le premier a fini, ceci permettant d'éviter les déconnexions en cas de problème, et par exemple, d'effectuer un changement de pfinet sans aucune déconnexion. Ce n'est qu'un exemple: la flexibilité qu'apporte la modularité du Hurd peut autoriser _nombre_ de choses très intéressantes comme cela, qui n'ont pas toutes été implémentées à l'heure actuelle.
  
  * Enfin, il me semble que c'est quand même beaucoup plus beau, clean. Les rôles sont beaucoup mieux repartis, et chaque partie peut être facilement remplacée sans perturber les autres.
  
  Mais ce n'est pas tout. On ne peut limiter le Hurd a son architecture: elle n'est qu'un élément de la recherche du toujours mieux, toujours plus novateur. On citera par exemple:
  
  * Le principe des translators. Comme dit précédemment, les différentes applications - serveurs - du Hurd communiquent entre eux via un micro-noyau, actuellement, et encore pour un bon bout de temps, Mach. Le rôle de ce micro-noyau est de passer des messages - on dit qu'il est message-passing. Pour ce faire, il introduit le concept de ports. Un port est un canal unidirectionnel qui n'est matérialisé que par un droit sur ce port: un droit d'envoi, un droit « send-once » (envoi d'un seul message, utile pour les réponses vu que c'est unidirectionnel), et un droit de réception. (ce dernier n'étant bien entendu détenu que par une seule tâche..). C'est par le biais de ces ports que les applications communiquent entre elles, et par ce biais par exemple qu'une application du Hurd - ext2fs, par exemple - peut authentifier un utilisateur - via le serveur password, en lui envoyant un message, ou vérifier qu'il a le droit de faire telle ou telle opération -- en envoyant un message au serveur 'auth', etc... Le problème qui se pose alors, généralement, dans la conception de tel système est: comment une application - une tâche, au sens Mach - peut-elle obtenir un droit sur un port en direction de telle ou telle application ? Le moyen standard, et logique, est de faire un serveur de noms, exactement comme pour la résolution de noms via DNS. Vous m'accorderez cependant que c'est une solution relativement lourde, et peu élégante, puisqu'elle nécessite que chaque application s'enregistre au préalable, etc.. Dans le Hurd, l'idée est radicalement différente: on n'utilise plus un serveur de noms, mais on considère le file system comme un espace de nom! Ainsi, chaque fichier est attaché à une application, et écrire dans un fichier revient à envoyer un message à l'application qui écoute sur ce fichier. Pour un fichier « classique », il s'agira probablement d'un translator ext2fs - qui « écoute » sur tous les fichiers du système de fichiers montés, donc - qui agira à peu près comme
  la gestion des FS de Linux. Cependant, cela permet des choses qui sont très difficilement faisables sous GNU/Linux. L'exemple le plus courant est celui du translator - un translator est une application qui « écoute » sur un fichier - de fortunes: votre client mail ne supporte pas les signatures aléatoires, or, vous voulez mettre des fortunes dans votre signature ? Aucun problème! Il vous suffira d'avoir un translator 'fortune', qui écrira, par exemple, dans ~/.signature (~ <=> le home de l'utilisateur qui a lancé le translator), mettant à jour la fortune grâce à l'utilitaire fortune à chaque fois que le fichier est accédé. Et voilà, votre application supporte maintenant les signatures aléatoires! :-) Je voua laisse imaginer les autres applications du principe des translators..
  
  * La refonte du VFS - utilisant tout ce que permet la modularité du Hurd. Le nouveau VFS permet d'implémenter facilement - de façon stable, fonctionnelle - des systèmes de fichiers distribués (je pense principalement à ftpfs, qui permet de « monter » (si tant est que cela veuille dire quelque chose avec le Hurd) un FTP comme une partition), des nouveaux systèmes de fichiers - très intéressants.. - comme ShadowFS (cf. http://lists.debian.org/debian-hurd/1999/debian-hurd-199909/msg0004(...)),
  etc.
  
  Une application du concept des translators est montrée par le log suivant:
  
  mmenal@dryden:~$ settrans -c /home/mmenal/ftp/ /hurd/hostmux /hurd/ftpfs /
  mmenal@dryden:~$ cd /home/mmenal/ftp/ftp.fr.debian.org
  mmenal@dryden:~/ftp/ftp.fr.debian.org$ ls
  debian debian-cd debian-non-US
  mmenal@dryden:~/ftp/213.245.76.60$ cd /home/mmenal/ftp/213.245.76.60/debs/
  mmenal@dryden:~/ftp/213.245.76.60/debs$ ls
  libdianewcanvas0-dev_0.6.4-1_i386.deb libdianewcanvas0_0.6.4-1_i386.deb libglade2-dev_1.99.5-1_i386.deb libglade2_1.99.5-1_i386.deb sources
  
  Ainsi, on voit qu'on sort bien du concept classique des fichiers sous Unix, pour permettre au translator écoutant sur le répertoire /home/mmenal/ftp -- hostmux, pour host deMUXer -- de gérer comme il veut un accès à un fichier - en l'occurence, donc, en se connectant au ftp de même nom que le même fichier, et en le passant à ftpfs pour qu'il fasse son boulot à son tour.
  
  C'est-y pas magnifique? :)
  
  Enfin, le dernier avantage que je citerai est le système de sécurité. Pour résumer très brièvement (j'espère): on casse le modèle une application à un UID (et EUID, etc.). On considère ces « UIDs »
  comme des jetons t'autorisant à un certain nombres de choses -- disant au serveur auth que tu as le droit de faire, telle, telle, ou telle opération. Ainsi, la gestion des UGIDs ne se limite plus à quelques changements, mais arrive à une vraie gestion de collections de droits: on peut rajouter des droits (addauth, en s'authentifiant, en demandant au serveur password si l'authentification est bonne), en enlever. On note par exemple qu'il existe ainsi un _vrai_ cas où une application n'a plus de droit: le cas où elle ne possède plus aucun jeton. La possibilité d'ajouter simplement des droits - ce qui n'existe pas naturellement dans le cadre d'Unix - permet ainsi d'éviter beaucoup de passages en root, et de n'avoir que les permissions nécessaires à chaque opération, pour limiter au *maximum* les dégâts potentiels d'une faille.
  
  Bon, je pense que je vais m'arrêter là. Je suis désolé pour vous avoir encore donné un post immondede, indigeste, trop long, verbeux, et j'espère faire mieux en reprenant tout ça de façon bien organisée dans ma présentation à venir..
  - [^]Enfin !
    
    Posté par Pierre Tramo (page perso, ) le 14/03/2002 à 08:46. (lien). Évalué à 5.
    Oui, je dis bien, enfin !
    
    Enfin, un post constructif, qui apporte des réponses claires à des questions que je me posais depuis un moment, à savoir ce que le Hurd avait de si intéressant. Maintenant , j'ai un petit aperçu, qui me donne envie de voir un peu plus loin, si j'en ai le temps (ça, c'est pas gagné).
    
    Merci Manuel, je préfère un commentaire comme cela dans les news, plutôt qu'un troll de plusieurs jours sur la tribune. Je comprends que les hurdistes s'offusquent des propos qui s'y tiennent, mais la tribune libre n'est décidément pas un espace de discussions très sérieux, ou est en tout cas inadapté à ce genre de sujet.
    
    Petit bémol quand même : http://www.hurdfr.org(...) laisse vraiment un goût d'inachevé dans la bouche.
    
    Trouvant ridicules les batailles de tribus dans la communauté des logiciels libres, je souhaite longue vie au hurd ! Et à sa cohabitation avec le système GNU/Linux.
    
    (Là, j'espère pas avoir dit trop de bêtises sur les termes utilisés, style Le Hurd, ou GNU/Linux. De toute façon, j'en connais deux qui rectifieront. ;) )
    
    --
    C'est ce que je pensais, vous êtes un petit con monsieur. Une merde de plus dans une immensité de caca virtuel. Vous êtes la honte du net francophone vous et vos copains. (Phill)
  - [^]Et la programmation parallèle ?
    
    Posté par ceituna (page perso, ) le 16/03/2002 à 20:11. (lien). Évalué à 2.
    Enfin qqn qui connait un peu !
    
    Tout ceci me donne envie des poser quelques questions...
    
    Si j'ai bien compris, au niveau du noyau, l'interaction par messages est grandement augmentée pour améliorer la modularité du système...
    
    Or, maintenant que les réseaux Gbits se développent de + en +, ceci permettra-t'il d'avoir une gestion de l'OS répartie entre diverses machine ?
    
    Pour prendre un exemple tout con sera-til possible de passer un message au serveur de passwords situé dans la machine C si le serveur X tourne su la mcahine B ?
    
    Ceci ouvrirait de splendides possibilitées dans le clustering, mais ouvrirait aussi des problèmes de sécurité non négligeables !
    
    Alors ?

[+] Un petit regret

Posté par ufoot (page perso, ) le 13/03/2002 à 13:17. (lien). Évalué à -10.

C'est dommage, http://www.hurdfr.org(...) , malgre son nom, ne fonctionne meme pas sous daCode! C'est dommage avec http://www.linuxfr.org(...) et http://www.muttfr.org(...) on commencait a s'habituer...

Bon, hum, desole...

[+] [^]Re: Un petit regret

Posté par Eric Leblond (page perso, ) le 13/03/2002 à 13:24. (lien). Évalué à -3.
Je m'étais fait la même remarque !
Juste pour dire que tu as oublié http://www.gnusfr.org(...)
- [^]Re: Un petit regret
  
  Posté par Pierre Tramo (page perso, ) le 13/03/2002 à 13:30. (lien). Évalué à 0.
  Mais aussi :
  http://www.emacsfr.org(...)
  
  <troll mode>( Même si, vi ça le fait plus quand même)</troll>
  
  hop ! 2 centimes et -1.
  
  --
  C'est ce que je pensais, vous êtes un petit con monsieur. Une merde de plus dans une immensité de caca virtuel. Vous êtes la honte du net francophone vous et vos copains. (Phill)

[^]Re: Un petit regret

Posté par Pascal Terjan (Jabber id, page perso, ) le 13/03/2002 à 13:41. (lien). Évalué à 6.
Vu le nombre de news sur http://www.hurdfr.org/News(...) (1 ou 2 par mois pendant quelque temps puis aucune depuis le 17 Decembre 2001), je ne suis pas sur que daCode soit très utile...

Troll des cavernes

Posté par Eric Leblond (page perso, ) le 13/03/2002 à 13:18. (lien). Évalué à 7.

Juste pour relever une phrase et un titre :
"A Freer Cousin"

"Distributions of GNU/Linux include commercially licensed software, and that diverts the user and developer community from the goal of freedom, according to Stallman."

Je ne vois pas en quoi le système GNU va changer la donne, il sera toujours possible de faire des distributions avec GNU et d'y mettre des applis commerciales. En fait, on dirait que Stallman veut faire un HurdBSD qui serait le vrai OS libre, et pas l'imitation à la sauce finlandaise.

[^]Re: Troll des cavernes

Posté par Gaël Le Mignot (page perso, ) le 13/03/2002 à 13:35. (lien). Évalué à 1.
"A Freer Cousin"

Peut-être est-ce une réaction à l'utilisation de BitKeeper par Linus et une partie des développeurs du noyau ?

-1 ça n'apporte pas grand chose

[^]Re: Troll des cavernes

Posté par ptifeth (page perso, ) le 13/03/2002 à 13:42. (lien). Évalué à 0.
RMS a a mon avis d'autant plus tort que l'hurd permet à l'utilisateur de se passer du root, en gros si j'ai bien compris.
Ca veut aussi dire que n'importe quel soft à la windows a plus d'affinités avec l'hurd qu'avec linux... (à mon avis à moi)
- [^]Re: Troll des cavernes
  
  Posté par Eric Leblond (page perso, ) le 13/03/2002 à 14:28. (lien). Évalué à 2.
  Doucement tu vas un peu vite en besogne. Les serveurs dont parlent l'article sont un peu comme des modules, il faut avoir les droits requis pour les installer.
  Donc si RMS a tort ici ce n'est pas dans l'avis qu'il a sur Hurd mais sur l'avis qu'il a sur le reste.
  - [^]Re: Troll des cavernes
    
    Posté par Gaël Le Mignot (page perso, ) le 13/03/2002 à 14:36. (lien). Évalué à 9.
    Non, un serveur ce n'est pas du tout comme un module noyau. Un module noyau s'exécute en mode noyau sur le processeur et peut absolument tout faire, il est donc normal que seul root puisse en lancer. Un serveur du Hurd est un programme comme un autre, qui tourne avec l'indentité de l'utilisateur qui l'a lancé et ne peut rien faire de plus que ce que l'utilisateur a le droit de faire.
    
    Donc oui, n'importe qui peut lancer un serveur, mais ce serveur ne pourra faire que ce que l'utilisateur peut faire. Typiquement pour un translator lancé sur une image ISO, il faut que l'utilisateur puisse lire l'image ISO et possède le répertoire où l'image va être montée.
- [^]Re: Troll des cavernes
  
  Posté par Gaël Le Mignot (page perso, ) le 13/03/2002 à 14:29. (lien). Évalué à 16.
  l'hurd permet à l'utilisateur de se passer du root
  
  Déjà on dit le Hurd, pas l'hurd, merci. Ensuite, le Hurd ne permet à l'utilisateur de se passer du root et ne nuit pas du tout à la sécurité, au contraire. Il permet à l'utilisateur de faire des choses qui ne nuisent pas à l'intégrité du système mais qui sont impossibles à faire avec un noyau monolithique.
  
  Par exemple, avec Linux, si tu veux faire du ftpfs (monter un répertoire FTP dans ton VFS), il faut passer root, charger le module ftpfs, et introduire donc un nouveau programme, potentiellement buggué, dans le noyau. Avec le Hurd, tu lances un translator FTP, qui tourne sous ton identité, qui a tes privilèges, comme une application normale.
  
  <i>n'importe quel soft à la windows a plus d'affinités avec l'hurd qu'avec linux.</i<
  
  Que veux-tu dire par là ??
  - [^]Re: Troll des cavernes
    
    Posté par Pierre Tramonson () le 13/03/2002 à 15:02. (lien). Évalué à 1.
    En fait il voulait juste te provoquer parce qu'il trouvait que tu n'avais pas posté assez de commentaires dans cette nouvelle :)
  - [^]Re: Troll des cavernes
    
    Posté par ptifeth (page perso, ) le 13/03/2002 à 16:02. (lien). Évalué à 2.
    Déjà on dit le Hurd, pas l'hurd, merci.
    ben quoi t'as vu l'hurd qu'il est ?
    Il permet à l'utilisateur de faire des choses qui ne nuisent pas à l'intégrité du système mais qui sont impossibles à faire avec un noyau monolithique.
    jamais dit le contraire !
    Justement, comme linux int

Articles précédents : Articles

Liens connexes

Dépêche modérée par

Articles : GNU/Linux est mort, vive GNU !

Retour vers le futur

[^]Re: linux is obsolete

[^]Re: Retour vers le futur

[+] [^]Re: Retour vers le futur

[+] [^]Re: Retour vers le futur

[^]Re: Retour vers le futur

[^]Re: Retour vers le futur

[^]Retour vers le futur IV

[^]Re: Retour vers le futur

[^]Re: Retour vers le futur

[^]Re: Retour vers le futur

[+] [^]Re: Retour vers le futur

[^]Re: Retour vers le futur

[^]Re: Retour vers le futur

[^]Re: Retour vers le futur

[+] [^]Re: Retour vers le futur

[^]Re: Retour vers le futur

[^]Re: Retour vers le futur

[^]Re: Retour vers le futur

[+] [^]Re: Retour vers le futur

[^]Trop gros, passera

[^]la guerre des kernels

[^]Re: la guerre des kernels

[^]Re: Retour vers le futur

[+] [^]RMS est mort, vive Linus

[^]Re: RMS est mort, vive Linus

[+] [^]Re: RMS est mort, vive Linus

[^]Re: RMS est mort, vive Linus

[^]Re: RMS est mort, vive Linus

[^]Re: RMS est mort, vive Linus

[^]Re: RMS est mort, vive Linus

[^]Re: RMS est mort, vive Linus

[^]Re: RMS est mort, vive Linus

[^]Re: RMS est mort, vive Linus

[^]Re: RMS est mort, vive Linus

[^]Re: RMS est mort, vive Linus

[^]Re: RMS est mort, vive Linus

[+] [^]Re: RMS est mort, vive Linus

La mort annoncée de GNU/Linux ?

[^]Re: La mort annoncée de GNU/Linux ?

[^]Re: La mort annoncée de GNU/Linux ?

[^]Re: La mort annoncée de GNU/Linux ?

[^]Re: La mort annoncée de GNU/Linux ?

[^]Re: La mort annoncée de GNU/Linux ?

[^]Re: La mort annoncée de GNU/Linux ?

[^]Re: La mort annoncée de GNU/Linux ?

[^]Re: La mort annoncée de GNU/Linux ?

[^]Re: La mort annoncée de GNU/Linux ?

[^]Re: La mort annoncée de GNU/Linux ?

[^]Re: La mort annoncée de GNU/Linux ?

rms l'utilise deja ...

[+] [^]Re: rms l'utilise deja ...

[^]Re: rms l'utilise deja ...

[^]Re: rms l'utilise deja ...

[^]Re: rms l'utilise deja ...

[^]Enfin !

[^]Et la programmation parallèle ?

[+] Un petit regret

[+] [^]Re: Un petit regret

[^]Re: Un petit regret

[^]Re: Un petit regret

Troll des cavernes

[^]Re: Troll des cavernes

[^]Re: Troll des cavernes

[^]Re: Troll des cavernes

[^]Re: Troll des cavernes

[^]Re: Troll des cavernes

[^]Re: Troll des cavernes

[^]Re: Troll des cavernes