<i> L'état actuel de la chose est impressionant d'optimisme: "en cours", "pour bientôt", "pas dur". <i>
Non, ce n'est pas particulièrement optimiste. Les choses dont je parle précédemment sont presque prêtes, et, si il y'a encore quelques mois on ne pouvait avancer de date pour leur intégration, il est évident que toutes ces avancées majeurs auront lieu au premier trimestre 2001, avant l'été - ou un peu pendant. Par exemple, le passage à la libio et la libc0.3 est prévu pour juste après le mariage de Jeff Bailey - :) - soit courant avril..
OSKit-Mach est depuis longtemps bootable, assez stable, 'tc.. Il lui manquait particulièrement un support console décent, qui avance à grands pas, et sera bientôt prêt de l'avis même de son créateur.. Pour ces projets, on peut clairement dire qu'ils seront bientôt prêts. Maintenant, il y'a d'autres objectifs à long terme qu'il sera plus dur d'atteindre: le port du Hurd sur L4 ne sera pas fait d'ici un bout de temps, sera dur, demandera énormément de travail. Il vient tout juste d'ailleurs de _vraiment_ commencer. (c'est ce genre de signes qui montre que le Hurd _avance_.. L4-Hurd existe depuis des années et des années, et commence _maintenant_, c'est qu'on est à une période clé..). De même, la réécriture de pfinet sera quelque chose de long, passionant, mais extrêmement difficile, et peu de gens dans le Hurd possède les compétences nécessaires - s'il y'en a. Donc, pour ça, je ne me hasarderai pas à donner une date..
Pour l'instant, je n'ai pas vu *un* problème technique de la vie de tous les jours ou du
monde de la production que Hurd puisse prétendre résoudre mieux que la concurrence.
"aussi bien" ne passe pas mieux. :o(
Reprenons mon "gros" post:
1) une disponibilité sans pareille, notamment en terme de local down time (entendez, quand la machine est éteinte, ou en tous caa pas utilisables en local), mais aussi en down time "traditionnel", c'est à dire, le moment où la machine est up & running, mais pas joignable depuis le Net, ou le LAN où elle est utile. La modularité du Hurd permet notamment d'avoir des pfinet en relai - c'est _possible_, pas _fait_ - qui éviteraient pas mal de problèmes..
2) Une sécurité bien plus avancée, via le système des jetons d'authentification, qui permettent d'avoir un réel unknown, et de n'avoir que les permissions nécessaires - et donc, les permissions root que quand c'est absolument nécessaire.
La possibilité d'avoir un login shell peut s'avérer aussi tout à fait intéressante, même en production..
le Hurd semble lui encore un peu en retard.
Ça ne veut strictement rien dire. Un projet en développement serait nécessairement en retard ? Je l'ai dit et répété - alors, merci de bien vouloir _lire_ avant de parler - le Hurd est un projet en cours de développement, qui n'est pas abouti, et on ne prétend pas que GNU soit capable de remplacer GNU/Linux dans la vie de tous les jours dans un futur très proche.
À croire que certains sont incapables de sortir de leur logique de consommateur, pour s'intéresser à des avancées technologiques d'importance même si elles ne sont pas prêtes à être utilisées couramment sur leur petite machine, pour rendre leur vie so coooool. Tu m'étonnes qu'on manque de feedback dans les logiciels libres..
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.
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.
C'est plus compliqué que ça. Linux est développé par un grand nombre de programmeur, dont Linus qui est "l'architecte"; dans le cas du Hurd "l'architecte" serait plutôt Marcus.
Pas tout à fait. Marcus Brinkmann est actuellement probablement le développeur principal du Hurd, celui
qui est le plus actif. Il a de plus le mérite d'être arrivé dans le monde du Hurd autour de '98-'99, à un moment où le Hurd était un projet plutôt inactif depuis plusieurs années - environ 7 ans -, et de l'avoir relancé à lui tout seul, en créant Debian GNU/Hurd, etc. Mais, les architectes principaux du Hurd sont Thomas Bushnell et Roland McGrath, les deux ayant été un temps employés par la Free Software Foundation, et le deuxième étant un grand personnage - comme dit précédemment, auteur de la GNU Libc, co-auteur de GNU Make, maintainer d'une partie de GNU Emacs, etc. Thomas ne participe plus aujourd'hui au Hurd que pour donner son avis, et parce qu'il connaît bien le sujet, quand même. Mais, il consacre son temps à la philosophie. :)
Roland participe encore aujourd'hui au Hurd, même s'il ne le peut pas très activement étant donné qu'il doit quand même vivre - par sa propre boîte, FrobTech.
Alors, donnez à la FSF pour qu'elle emploie Roland! :-)
Pour reprendre la deuxième partie, je suis tout à fait d'accord. Il faut noter de plus que la FSF n'a aidé le Hurd qu'à ses débuts, et qu'elle n'a pas été une grande aide du tout pendant pas mal d'années, le considérant comme un projet mort jusqu'il y'a peu de temps - à tort, je l'affirme, et en conséquence, ne donnant aucun moyens aux développeurs - développer un tel logiciel demande pas mal de moyens, car cela nécessite généralement plusieurs PC, des PCs très performants. Ainsi, il aurait été d'une grande aide qu'on ait accès plus tôt à plusieurs machines sous GNU via SSH, mais il a fallu attendre que l'université de Massachusetts
Lowells, où étudie Neal Walfield, donne deux/trois machines.. Espérons que l'annonce de RMS s'accompagnera des moyens qui seraient nécessaires pour avoir un système GNU parfaitement utilisable rapidement, notamment en terme d'emploi de personnes par la FSF.
Donc OSF Mach n'est pas GPL ? Ca veut dire que la FSF va utiliser un micro-noyau non libre ? Je ne comprends pas trop, quelqu'un peut m'expliquer ?
Relis donc mon post. Jamais nous n'utiliseront OSF Mach qu'à des fins de portages, et ce de façon tout à fait temporaire. Les seuls noyaux que le Hurd utilise officiellement, c'est GNU Mach, et sa variante utilisant les drivers du projet OSKit <http://www.cs.utah.edu/flux/oskit/>(...) , OSKit-Mach, qui est la seule version développée depuis quelques temps et qui avance vite - notamment au niveau du joli nouveau support console, avec support de l'internationalisation excellent, multi-head, splitvt, équivalent de screen -rx, etc..
Moi, personnellement, ce genre d'effet d'annonce me fait furieusement pensé à ... Mr Bill Gates. Juste pour que l'on s'interesse à son projet. Bon, je pousse un peu quand même, je le reconnais (=> -1).
Il faut voir aussi que son post a été détourné. Il n'a pas dit explicitement que GNU remplacerait GNU/Linux partout dans toutes les machines d'ici la fin de l'année. En revanche, il a annoncé une release de GNU, ce qui veut dire en réalité que la FSF prépare sa propre version du GNU, qui reprendra probablement beaucoup de Debian GNU/Hurd, mais qui sera indépendant de Debian.
Il me semble que ça méritait d'être annoncé, mais ne méritait peut-être pas toute la réutilisation qui en a été fait sur /. et ici même.
Le Hurd est actuellement porté sur x86 et sur PPC, comme cela a été dit plus tôt. Cependant, il faut savoir que le Hurd lui-même est extrêmement portable - le port PPC n'a nécessité que très très peu de modifications au Hurd lui-même - et qu'il suffit donc de porter le micro-noyau - Mach actuellement. Ce micro-noyau, sous la forme d'OSF Mach - identique à GNU Mach modulo quelques modifications mineures, a été porté sous de nombreuses plate-formes, que ce soit des ports officiels (DEC Alpha, m68k, etc.) ou des ports non officiels (plus récemment, MIPS, et plein d'autres architectures..).
Porter le Hurd n'est donc vraiment pas chose difficile, d'autant plus qu'il a toujours été conçu pour être tout à fait portable. Concernant les architectures sans MMU, je ne sais pas vraiment ce qu'il en est des ports Mach, donc je ne m'avancerais pas. D'autant plus que je connais pas trop ce genre d'architectures..
Concernant le temps réel, c'est quelque chose qui est assez naturel, bien que le Hurd n'ait pas été conçu pour être temps réel, et ne l'est pas à l'heure actuelle. Si tu veux parler de simples extensions temps réel comme celles définies par le standard POSIX, leur support est partiel, mais est complètement possible, et même, pas très dur à implémenter.
Pour ta dernière phrase, j'avoue que j'ai du mal à la comprendre. S'il s'agit de faire un « light Hurd » pour le faire tourner sur des architectures
matérielles disposant de peu de mémoire, oui, c'est tout à fait possible. Il est notamment tout à fait possible d'élaguer considérablement le Hurd, en ne compilant que les serveurs essentiels,
ce qui réduira sa taille de façon très importante très facilement. De plus, l'indépendance de chaque application permet de facilement remplacer les serveurs qui pourraient poser problème pour le portage sur ces « petites » machines par d'autres, ne fournissant qu'un subset basique de ce que l'application d'origine fournissait. C'est ce genre de flexibilité que permet une architecture à micro-noyau, et un système multi-serveurs comme le Hurd, justement ..
Ceci dit, je le répète, le Hurd n'est pas fini, et GNU n'est pas une alternative viable à GNU/Linux pour l'utilisation quotidienne, à l'heure actuelle. Non pas tellement par son manque de fonctionnalités - ça se rebouche très vite.. - mais pour des questions de stabilité - sachant que l'ensemble du feature set n'est pas encore tout à fait implémenté, la stabilité n'est pas _la_ considération principale - et de performances. (le Hurd n'est pas du tout optimisé, ni GNU Mach, et GNU Mach n'est probablement pas le meilleur choix pour les performances - bien qu'il présente de nom breux avantages).
Bon, encore un commentaire auquel j'avais déjà répondu, mais la réponse n'est pas apparue. :(
La compatibilité binaire est effectivement prévue, comme un objectif à long terme, mais n'y comptez pas dans le futur proche.
Mais je tiens à réagir sur ton affirmation disant que « Comme les 2 OS ne diffèrent pas de grand chose (le kernel et l'interface avec le kernel) ».
C'est complètement faux. FreeBSD et GNU/Linux ont bien plus de points communs que GNU. Ils sont tous deux extrêmement proche d'Unix, alors que GNU n'est pas à la base proche d'Unix - le Hurd et la GNU Libc s'efforcent juste de fournir une compatibilité POSIX.
En particulier, concernant le Hurd, nombre de notions classiques sous Unix n'existent plus:
* La notion de fichier en soi. Comme déjà dit dans mon commentaire précédent, le fichier n'est plus à la base qu'une interface permettant de joindre une application, et le système de fichiers n'est plus qu'un espace de nom pour obtenir des ports. Il est évident que le Hurd supporte néanmoins ext2fs, et UFS, et donc la notion de fichier tradionelle. Cependant, ça n'est pas un concept propre au Hurd, et les appels systèmes habituels de manipulation des fichiers ne sont que des interfaces de compatibilité - pour les basiques, réalisables via de simples RPC (Remote Procedure Call) à l'application qui écoute derrière, mais beaucoup plus difficilement pour certains autres, et en particulier, pour retourner des erreurs dans des cas précis définis par POSIX...
* Les notions traditionneles d'UGIDs (entendez, UID et GID). Le modèle « un programme, un (e)UID » est complètement cassé pour faire place au principe des jetons d'authentification (authentification tokens), modèle bien plus puissant, où l'on peut acquérir - via le serveur password - plus de droits dynamiquement - sans pour autant devenir root, vu que l'on peut avoir plusieurs jetons correspondant aux droits de plusieurs utilisateurs, en soustraire - jusqu'à ne plus en avoir du tout, permettant l'existence d'un _réel_ nobody - il est dit « unknown » - qui n'est __pas_ un utilisateur, et n'a à la base aucun droit - si ce n'est utiliser ce que l'application a créé avec des droits supérieurs auparavant bien entendu, sauf si l'administrateur lui en donne - il y'a maintenant plus seulement ugo, mais aussi ugok, pour unKnown. Cela est particulièrement intéressant concernant les applications devant ouvrir un port « sécurisé » - comme un FTPd - (< 1024), requierant les droits root: on lance l'application en root, on ouvre le socket, on bind, listen, et dès que tout cela est fini, on s'enlève tous les droits. Ainsi, une faille à ce niveau n'aurait _aucune_ conséquence, puisqu'il ne pourrait _rien_ faire.. Par la suite, il n'y a plus qu'à transmettre les données fournies par l'utilisateur au prompt de son client FTP au serveur password, l'authentifier, et le voilà avec ses propres droits d'utilisateur et pas plus, sans
aucune difficulté.
De même, ce concept de serveur auth à qui on demande l'autorisation avant de faire n'importe quelle opération permet d'implémenter facilement, de façon jolie, performante, et native, le système
des capabilities Linux - connu pour son inflexibilité, ce qui explique pourquoi il est si peu utilisé.. - et les prétendus systèmes révolutionnaires comme LIDS.
Par faute de temps je m'arrêterais là, mais il faut savoir qu'il y'a encore de nombreux exemples, et qu'au fur et à mesure, si la compatibilité POSIX devrait s'améliorer, le Hurd devra s'éloigner d'Unix, essayant de faire mieux pour tous les domaines - par exemple, concevoir un nouveau système d'init, pour remplacer les init SysV et BSD, qui ne sont pas des modèles de propreté et d'efficacité ANHA. Cependant, ça n'est pas spécifique au Hurd: c'est une idée générale derrière le GNU, et beaucoup des codes faits pour le Hurd sont en fait réutilisés dans les autres ports de la GNU Libc - pensons à argp, aux pthreads, au futur système d'init justement..
Ah oui, dernière chose: ta distinction entre userland et serverland n'a pas du tout lieu d'être. Les applications qui composent le Hurd - le micro-noyau ne faisant PAS partie du Hurd - sont des applications e-x-a-c-t-e-m-e-n-t c-o-m-m-e les autres, certaines ayant des rôles similaires à des applications que tu peux trouver sous GNU/Linux.
Commentaires, questions, tout cela est bienvenu, je me sens tout seul sans réponse. :)
Bon, avais répondu à ce comment, mais il semble avoir disparu totalement. Alors, j'y reréponds..
Comment je fais pour mes programmes threadés ?
Le Hurd lui-même est multi-threadé jusqu'à la moëlle. Il y'a donc bien gestion des threads. Il s'agit en fait des C-Threads, seule interface gérée par Mach pour ses threads kernel -- il avait été question d'un support des POSIX Threads, qui est évoqué dans les docs du CMU Mach, mais il semble n'avoir jamais vu le jour. Maintenant, il est vrai que rares sont les programmes qui utilisent les C-Threads, et qu'ils présentent des inconvénients majeurs par rapport aux pthreads..
Cependant, une implémentation des pthreads pour le Hurd, mais devant être un maximum portable - contrairement aux LinuxThreads de Xavier Leroy - est en cours de développement. (cf. <http://savannah.gnu.org/projects/pthreads/>(...)). Si elle n'est pas encore finie, elle réprésente un enjeu majeur selon tout le monde, et les meilleurs développeurs du Hurd y sont impliqués - Marcus Brinkmann, Roland McGrath (auteur de la GNU Libc, un des maintainers de GNU Emacs, co-auteur de GNU Make, un des deux concepteurs du Hurd...), ce qui pourrait amener une version stable avant l'été.
Ca gère mon SMP ?
En théorie, oui. Le SMP n'est pas la priorité du Hurd à l'heure actuelle, mais le support est bien présent, et il devrait le gérer à merveiller. Il reste un certain nombre de choses à faire pour qu'il exploite totalement ce SMP, mais ce ne sont pas des trucs vraiment difficiles à faire - même très faciles..
La NVidia, elle fonctionne ?
La NVidia, via le driver nv, oui. Si tu voulais parler des drivers NVidia propriétaires et du module Linux fourni, il est évident que non. Mais, c'est propriétaire ...
Et mon modem ADSL ?
Ça dépend. Le support USB n'est pas au programme. Concernant les modems ethernet utilisant PPPoE, le support PPPoE n'est pas encore fonctionnel, mais votre serviteur travaille actuellement sur un port de RP-PPPoE - comme cela a été fait pour FreeBSD, ce qui ne pose pas de problème majeur, le support PPP étant parfaitement fonctionnel.
Wala, wala, comment utiliser un troll pour présenter l'état actuel de la chose :-)
Tout ceci est vrai.J'ai moi-même tenu environ 6-7 semaines. Un bug de zmalloc - de GNU Mach, donc - fait qu'il est difficile de tenir plus que ça. En réalité, le Hurd pourrait tenir probablement bien plus longtemps, les limitations à ce niveau sont vraiment au niveau de GNU Mach, qui n'est que très peu développé, et délaissé depuis quelques temps pour OSKit Mach (<devin> j'estime que le passage à OSKit-Mach devrait se faire d'ici l'été, un peu après la libc0.3 - avec libio - et hopefully avec les pthreads </devin>). Il faut voir que GNU Mach n'est qu'un OSF Mach pour lequel la FSF a obtenu la permission de le mettre en GPL, et qui n'a été que peu modifié. - de façon quand même conséquente, mais bon.. Le rôle principale de GNU Mach était surtout de développer le Hurd. Pas de refaire un micro-noyau tout neuf, etc.. On verra ça avec L4, plutôt. :-)
Sinon, pour répondre au comment précédemment sur la FAQ: non, GNU n'est pas encore usable en production. Non, il n'est pas aujourd'hui envisageable de l'utiliser dans la vie de tous les jours à la place de GNU/Linux avec un gain; Il peut faire à peu près tout ce que fait GNU/Linux, le problème est qu'actuellement, il n'est pas du tout optimisé, et il y'a encore de nombreuses limitations et problèmes d'instabilité.
Pour commenter les déclarations de RMS: Il n'a pas rendu service, AMHA, au Hurd, en disant cela. Et les premiers surpris ont été les développeurs du Hurd. Marcus (Brinkmann, qui a relancé le développement du Hurd en '98-99 après environ 7 ans au ralenti, fondé Debian GNU/Hurd, etc.) a franchement fait la gueule quand il a vu la news sur /. et imaginé le nombre de conneries qui allait se dire :-) Tout ça pour dire: ne le prenez pas _trop_ au sérieux. Ça ne veut pas se dire qu'il faut se déinstéresser du Hurd: il mérite à mon avis qu'on y jette un oeil, et, c'est un projet qui a vraiment besoin de participants, et celà à tous les niveaux. En plus, on se sent vite important, et on est très encouragés :)
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..
Comme chacun l'aura remarqué, ce document n'est jamais qu'un gros troll des bois, resassant les arguments maintes fois répétés et maintes fois démentis concernant les micro-noyaux. En temps normal, j'appliquerais les principes des développeurs du Hurd: ne pas répondre à ce genre de propos qui ne font que prouver l'ignorance de l'auteur et se concentrer sur le code, pour montrer que le Hurd est viable. Mais puisque je suis là et que je pense que ce troll pourrait bien convaincre de nombreuses personnes...
MA> AT prêchait pour les micro-noyaux. LT était parti de Minix, mais AT considérait son "oeuvre" comme un jouet ou un vague support de cours.
Effectivement. AT est un chercheur. Il a donc fait Minix dans une optique de recherche. Le Hurd n'est pas fait par des chercheurs pour des chercheurs, et cherche à être la vraie alternative à Linux. D'ailleurs, Minix existait et tournait assez bien, quoi qu'on en dise.
MA> A une époque reculée, tout le monde était persuadé que la seule façon de faire un système portable était d'utiliser un micro-noyau.
MA> Linux et NetBSD ont prouvé le contraire.
A une époque reculée, on le pensait peut-être, je ne peux me prononcer au nom de ceux qui argumentaient pour les micro-noyaux alors que je marchais à peine. Il est clair que la théorie des micro-noyaux aide forcément à construire un système portable. (Le Hurd a récemment était porté sous PPC très facilement, à l'aide d'une version de OSF Mach précédemment portée sous PPC. On peut penser que par la suite, entre autre avec le passage à L4, le port vers d'autres architectures se fera très facilement, vu la taille de L4 et le fait qu'il existe déjà pour de nombreuses architectures). Cependant, aucune notion d'exception là-dedans. On peut très bien faire du code au maximum portable dans un noyau monolithique. Dire le contraire serait une aberration... Comme on peut faire du code non portable en utilisant un micro-noyau.
MA> * MkLinux va a peine plus vite que MacOS sur Power Mac.
Super. Et ensuite ? Prendre des exemples n'est pas combattre une théorie. Ensuite, il faut savoir que MkLinux est basé sur le noyau Mach, qui n'est certainement pas le plus rapide, en tant que noyau de première génération. (contrairement à L4..) De plus, il s'agit d'un mono-serveur, ce qui n'aide généralement pas pour les performances. A ce sujet, on pourra lire 'The Performances of µ-Kernel-based systems', disponible à l'adresse: http://os.inf.tu-dresden.de/pubs/sosp97/(...) (et bien entendu toutes les autres publications sur http://os.inf.tu-desden.de/L4/doc.html(...) ).
MA> * Hurd, est totalement instable, rame, et n'est justifié que par la haine de RMS envers Linux.
Il est évident que je ne peux pas laisser passer ça.. Tout d'abord, petite correction qui montre que l'auteur ne s'est même pas renseigné avant: on écrit le Hurd, et pas Hurd. Deuxièmement, l'argument d'instabilité est un peu ridicule.. Évidemment qu'il l'est. Le Hurd n'est pas abouti. Sa stabilité s'améliore de jour en jour, et devient de plus en plus utilisable. Il a des points faibles, qu'on connaît: pfinet, un mauvais hack de la pile TCP de Linux qui limite de façon considérable ses capacités réseau. (PPP est sur le point de fonctionner parfaitement cependant! :), le serveur ext2fs, et la VM de Gnumach. (qui a dit, Gnumach en général? :) zalloc en particulier.). Mais il n'est pas particulièrement instable, il peut déjà tenir un uptime de plus d'un mois, et pourrait bien plus s'il n'y avait pas ces problèmes de zalloc. (ce qui n'est pas un problème du Hurd, qui comme chacun sait est en théorie indépendant du micro-noyau.)
Quant à sa lenteur, elle est effective. Les performances représentent un sujet très difficile à traîter car sujet à de nombreux paramètres en particulier liés à l'implémentation. Juger les performances d'un système non abouti ne me semble pas être très représentatif. On pourra notamment citer Evolution, qui était *extrêmement* lent jusqu'il y'a peu et qui a, quoi qu'on en dise, améliorer grandement ses perfs. (no troll, please..). Il faut quand même savoir que:
1) Le Hurd n'est optimisé d'aucune façon. Les perfs n'ont pas été le but originel, et même si c'est un sujet que les développeurs gardent en tête lors du développement, ça n'est pas la préoccupation principale, et elle se concrétise plutôt par des comments sur ce qu'on devrait faire (et qui est faisable.. donc susceptible d'être fait dans le futur) que par du code, permettant ainsi de se concentrer plutôt sur le feature set.
2) Mach, même si ça n'est pas la seule raison de la lenteur du Hurd, n'est pas un modèle concernant les performances (je vous incite toujours à lire le papier ci-dessus...), et encore moins Gnumach.
Quant à RMS, je ne vois pas ce qu'il a à faire là-dedans. RMS ne suit plus le développement du Hurd depuis longtemps, et la FSF est peu au courant de ce qui s'y passe généralement.. (un sursaut soudain vient d'arriver, et on espère qu'on aura bientôt un nouveau développeur à plein temps..). RMS n'a aucune haine envers Linux, pour en avoir discuté avec lui, et pour avoir lu nombre de ses publications.. Il est effectivement en désaccord avec Linus, qui se soucie peu, à vrai dire, du côté philosophique du libre. Il me semble que le Hurd s'inscrit dans la logique du projet GNU: refaire un système du type Un*x, mais pas une simple réécriture libre d'Un*x, ce qu'est finalement, à la base, Linux (les améliorations se trouvant avant tout dans l'implémentation et non dans le design..). Je pense que le Hurd est viable, mais n'ai aucun moyen concret de le prouver tant que le Hurd n'est pas totalement abouti et ne représente pas une alternative viable à Linux sur le bureau et sur les serveurs. L'attitude à adopter me semblerait plutôt être: Let's code it and see if it can be as cool as they say. (ou, let them code it si vous n'avez aucune envie de vous plonger dedans..)
MA> * Spring, l'OS expérimental de Sun, est arrêté. Je ne crois pas qu'ils aient relaché les sources. Le labo qui l'a conçu s'est amusé un moment avec, ils ont tenté de
MA> * récupérer certaines idées dans SunOS 5, puis ils sont passés à autre chose.
Effectivement. Et ensuite ? Il me semble qu'il s'agissait plutôt d'un OS expérimental à des fins de recherche, qui n'avait d'autre but que d'être un lieu de test pour des fonctionnalités à implémenter dans l'OS qu'ils comptaient garder comme seul OS principal, SunOS. Je me garderais bien de tout commentaire, ne connaissant pas bien son design autrement..
MA> * WinNT, est loin de la maturité et se débarrassera probablement de l'aspect micro-noyau avant de se débarrasser de ses nombreuses bogues.
L'expérience, et Windows 2000, prouve que celà est faux. On notera d'ailleurs que (NO TROLL PLEASE) Windows 2000 est probablement le meilleur des Windows existants, et à ce que j'en ai entendu dire, plus fiable que ses prédécesseurs. Excusez-moi, mais un système à micro-noyau où au fur et à mesure on a implémenté le maximum dans le kernel space (je sens que je vais avoir le droit au pBpG), on peut difficilement prendre ça comme référence.. D'autant plus qu'on en a pas les sources, ce qui rend le jugement assez difficile.
MA> * DEC OSF/1 est maintenant un machin monolythique. On ne voit plus mentionné le micro-noyau dans leurs docs.
MA> En fait, ça ressemble furieusement à un SunOS 4, même si c'est (très) différent en interne.
Même chose: et alors ? Ils sont passés à autre chose, parce qu'ils avaient d'autres besoins, que Mach ne comblait finalement pas.. Ca n'est pas un argument concernant les micro-noyaux, que je sache. Si mes souvenirs sont bons, on m'a dit en cours de français qu'un exemple n'était pas un argument.
MA> * AIX aurait été micro-noyautesque en des temps trèèès anciens ?! Mais vu tout ce qui a été tartiné autour, personne n'a jamais vu le micro-noyau.
De même. Je ne connais pas le cas d'AIX, mais une chose courante est que les développeurs, après avoir eu de bonnes idées concernant le design, n'étant contrôlés par pas grand monde, se laissent aller à la facilité et mette tout ça de façon inorganisée un peu n'importe où, voire même dans le micro-noyau. Programmer un système à micro-noyau demande certainement de la rigueur, c'est sûr: il est tellement facile de faire un foutoir du genre monolithique tel que le décrit André Tanenbaum dès les premiers chapitres de tous ses livres sur les OS.
MA> * Dans Mach 4, ils ont remonté le réseau dans le micro-noyau pour des questions de perfos.
MA> C'était prohibitif -- une demie-douzaine de context switch sur chaque paquet (au bas mot), il y a de quoi mettre à genoux n'importe quelle bécane.
Tiens donc. Il m'avait toujours semblé, à la lecture des docs OSF/CMU (dès les docs de Mach3) que ç'avait été pour permettre d'avoir un système à plusieurs hosts/nodes, plusieurs Mach tournant.
Pour les context switches, l'argument est un peu vague. Où est la demi-douzaine? J'aimerais le savoir, à la vue de pfinet et, surtout, des projets qui ont été faits pour le remplacer.
MA> Fondamentalement, c'est une aberration. Quand on voit le nombre d'attaques ou de bogues qui tournent autour de TCP/IP,
MA> on se dit que la robustesse du micro-noyau en prend un vieux coup sous la ligne de flottaison.
J'avoue que j'ai du mal à comprendre, là. Avoir la gestion réseau (la pile TCP, etc..) dans le noyau est une aberration, parce qu'elle est susceptible de faire crasher l'intégralité du système ? On est bien d'accord, et c'est là un argument contre les noyaux monolithiques. De plus, il ne me semble pas que la gestion du réseau soit totalement implémentée dans Mach4. Et encore une fois, Mach n'est pas le seul micro-noyau. L4 serait un exemple plus intéressant d'un vrai µ-noyau.
MA> * Dans le dernier Mach OSF, certains envois de message ont été remplacés par des appels de procédures ;
MA> certains serveurs partagent dans le même espace d'adressage pour éviter les context switchs.
1) Oui, on limite au maximum les messages, puisque cela transite par le noyau. Et ensuite ?
2) Pardon ? un exemple plus précis ? Si l'on peut éviter des context switches, par des biais tout à fait sain, on le peut. Que je sache, ce que vous décrivez n'a pas été fait tel quel.
De plus, c'est un argum^Wexemple contre Mach. Pas contre la théorie des micro-noyaux.
MA> Admettons : on peut "valider" certains serveurs et les passer dans le noyau. Mais c'est se faire des noeuds au cerveau:
MA> quand tout sera "validé", on aura un OS monolythique pas forcément plus stable qu'un autre -- BSD au hasard.
Ca n'a jamais été le but des concepteurs de micro-noyau, et encore moins celui du Hurd. (par exemple). Le mouvement se fait dans le sens inverse, au fil du temps: mettre le maximum de choses dans l'user space pour n'avoir dans le kernel space qu'une IPC basique, et une gestion de la mém et des procs basiques (et un accès hard minimal, quand même..): c'est ce que fait L4, encore une fois.
MA> les micro-noyaux se rapprochent des OS monolythiques et les OS monolythiques intègrent des fonctions qui ressemblent à ce qu'on trouve sur les micro-noyaux.
MA> Par exemple, les "modules" et pilotes chargeables de Linux.
Dans le premier cas, je ne suis pas du tout d'accord, et l'évolution dans la recherche sur les micro-noyaux (et l'évolution du Hurd) montre le contraire, le mouvement kernel space->user space que je citais précédemment.
Dans l'autre sens, il est évident qu'on ne peut comparer les modules Linux et les serveurs du Hurd... Cependant, effectivement, cela a apporté une souplesse importante. (d'ailleurs, dans certaines versions récentes de Mach, ce système existe.) Il me semble que ça n'est jamais que ce qui se fait habituellement sous Linux, rajouter un truc, intéressant certes, par dessus, sans tout changer en profondeur. (faire un micro-noyau!) (pensez à ftpfs sous Linux...)
MA> Donc quelque part, tout ce travail n'a pas été inutile puisqu'il est récupéré dans les systèmes modernes.
Les systèmes modernes, comme le Hurd, comme QNX ? ;P
MA> Un projet comme Hurd est-il bien raisonnable ?
MA> Ne serait-ce pas "l'art pour l'art" ? Dans Computer power and human reason, Josef Weizenbaum dénonce the empire of instrumental reason.
MA> Nous y voila...
C'est ce que le Hurd tend à prouver: que les micro-noyaux ne sont pas une vue de l'esprit, un jouet de recherche sans intérêt pratique.. Il me semble clairement que le Hurd, qui est aujourd'hui
utilisable et existe réellement, le montre déjà. Et qu'il présente des intérêts, c'est indéniable: on peut déjà montrer les avantages du Hurd, au niveau sécu, au niveau shadowfs, etc..
MA> In fact, this made me think that the microkernel approach was essentially a dishonest approach aimed at receiving more dollars for research.
Effectivement, c'est un argument qu'il a maintes fois énoncé contre le Hurd par la suite: qu'il est trop théorique et pas assez pratique. A cette question, je pense qu'on ne peut que répondre: regardez. Il existe. Il marche. Il s'améliore.
Des gens le codent. Rendez-vous dans quelques années...
Voilà, that's all folks.
DISCLAIMER: aucune attaque contre l'auteur, qui est par ailleurs quelqu'un de compétent. Le document ne présente pas *aucun* intérêt, et on ne peut pas le comparer aux FUD habituels, faits par Microsoft, notamment. Mais les propos ne m'en semblent pas plus justifiés..
Effectivement, il est assez courant d'utiliser SSH2 sur une Sid (malheureusement ?:) Cependant, on ne peut pas dire que la Sid en elle-même contienne des paquets SSH2, puisque la licence a été jugée (à raison:), trop restrictive pour permettre une inclusion dans main.
Les paquets de SSH2 sont donc dans non-free, et de ce fait on ne peut pas dire qu'ils fassent partie de Debian... Souvenez-vous de la longue flamewar sur la suppression du répertoire non-free: non-free ne fait _pas_ partie de Debian, ce sont un ensemble de paquets généreusement hébergés par Debian (et généreusement maintenus par des développeurs Debian (ou par qa comme SSH2, bien sûr:)).
Bon, ok, j'avoue, c'est un peu du chipotage, mais bon, faut bien s'occuper quand on est malade :-)
Toujours est-il que ça montre encore une fois que les logiciels libres ne sont pas plus sujets aux alertes de sécurité, au contraire :-]
Je ne pense pas que l'ADSL ait de réelles consé quences sur les ventes de boîtes des distributions. Cela aurait plutôt des répercussions sur les ventes des CDs « GPL », à mon avis.
En effet, les acheteurs des boîtes, comme tu l'as dit toi-même, sont principalement des débutants à la recherche d'une sécurité, -- acheter une boîte faîte par une entreprise commerciale, ça sécurise tout de suite, quoi qu'on en dise -- d'un manuel, d'un support, etc... Ces gens-là à mon avis continueront d'acheter des boîtes, uniquement pour la sécurité et les quelques services donnés avec les CDs...
Il est possible que dans ton cas tu aies préféré le téléchargement d'une distribution à l'achat d'une boîte. Mais, cette démarche est plutôt celle d'un bidouilleur que celle d'un débutant complet -- qu'il devienne bidouilleur plus tard ou pas, là n'est pas le problème :-). Or, il me semble évident que GNU/Linux est destiné à une utilisation encore plus grand public qu'aujourd'hui. C'est pourquoi à mon avis les ventes de boîtes de distributions ne vont pas baisser, ou alors dans une moindre mesure, et ce seulement au début, car je crois au succès de GNU/Linux à long terme...
La réponse est probablement indiquée à droite de ton écran, si tant est que tu sois authentifié (pas testé en anonyme): N'aurais-tu pas atteint ta limite de vote pour aujourd'hui ?
(5 pour un débutant, plus ensuite [merci woof :)], 100 pour god [encore merci et *smoutch*]).
Effectivement, nos amis les alsaciens -- comme monsieur Yeiazel, d'origine -- l'ont avant les autres, comme déjà dit il y'a un certain temps
dans une news ayant le même sujet dans un "échange" entre Julien Blache et moi-même.
Mais notons que même moi, en région parisienne, je l'ai reçu aujourd'hui. (abonné). Donc il devrait être rapidement disponible dans ta crémerie, si tant est qu'elle soit bonne, bien entendu.
Ce que tu décris me paraît proche de l'idée du Free Software Bazaar, dont le principe est effectivement
de proposer une somme d'argent (souvent assez importante) contre l'ajout d'une fonctionnalité à un logiciel (libre),
la création d'un nouveau logiciel, (libre encore) etc.
Ce que Bernhard Herzog propose me semble plus proche Free Software (Gift) Exchange Registry (a.k.a FSEX),
à ceci près qu'ici le don serait pour des raisons précises.
(l'aider à pouvoir continuer à vivre en développant son prog...)
Et il remue le couteau dans la plaie en plus le
petit salopiaud! Mais vas-y vas-y rappelle-moi
ma hcp encore plus cassée que la tienne ou ta gueule d'ange aussi tant que tu y es ;-)
Tu sais quoi ?
*JE TE HAIS* *JE TE HAIS* *JE TE HAIS* *JE TE HAIS* et ce qu'il en découle.
Au passage, juste comme ça : j'utilise GNU/Linux depuis bien avant mes quinze ans, et je ne suis pas le seul, Arnaud Willem n'a même pas ses quinze ans ;-p
De même, mon père, dont je ne dévoilerai pas l'âge mais dont je peux dire qu'il est supérieur à 50 [;-)]
utilise GNU/Linux et ce depuis quelques années déjà...
Et d'après ce que j'ai lu récemment ici-même il n'est pas le seul quinquagénaire :-)
Quant à l'argument "hard compatible", il est complètement irrecevable: aujourd'hui la plupart du matos est reconnu sous GNU/Linux, et de même sous Windows, je pense que je n'ai pas besoin de le préciser...
Et pour finir, ta dernière remarque montre bien ta méconnaissance du monde Linux... Ou ton envie de troller. C'est pour ça que je laisserais d'autres s'échiner à y répondre, s'ils ont le courage...
(oh la zoulie mise en page... Bon, trop la flemme de revoir tout)
Premièrement, comme déjà dit, tous les articles de GLHMF sont désormais publiés sous licence FDL.
Effectivement, malgré cela, ils ne sont pas tous disponibles sur le site web _pour le moment_.
Mais je te rappelle que le webmaster, Denis Bodor, est également le rédacteur en chef du magazine, et l'auteur de pas mal d'articles dans chacun de ses numéros, et, accessoirement, le père de deux enfants. C'est donc un homme pour le moins débordé, et tu comprendras que le passage des articles en TexInfo et leur publication sur le web passe après ses gosses ou la parution des nouveaux numéros.
Enfin, je ne veux pas parler à sa place mais je pense qu'on peut lui pardonner, vu l'énorme boulot qu'il fait déjà.
Juste pour faire remarquer un problème d'expression que je retrouve dans pas mal d'endroit et qui pourrait bien être signe d'une incompréhension (pas forcément du posteur précédent):
« meme si SuSE n'est pas libre »
Premièrement, il est implicite qu'on parle de la distribution GNU/Linux fournie par SuSE (on n'a dans ce cas même plus à signaler que les versions GPL le sont, puisqu'il n'en existe malheureusement plus...). Comme le nom l'indique, il s'agit d'une distribution basée sur le noyau Linux, libre, et sur les outils GNU, libres eux aussi. Les packs contiennent effectivement des softs non libres, mais la plupart des packs fournis par les autres distribs en contiennent aussi, excepté, bien entendu, Debian. (puisque non-free ne fait _pas_ partie de Debian).
Il me semble que le reproche qu'on peut faire à SuSE est différent, et je pense que cela est à l'origine de cette expression "SuSE n'est pas libre" : les logiciels développés (exclusivement) par SuSE sont pour la plupart (peut-être un fait il exception, je n'en sais rien) propriétaires, bien que SuSE participe à de nombreux projets libres (XFree86, KDE, noyau IIRC, etc.). Cela me semble être un grief important, cependant à chacun de juger si cela lui importe. Il n'y a pas une distribution meilleure que les autres AMHA, il y'a un ensemble de distributions différentes qui ont chacune des qualités et des défauts. A chacun en fonction de ses goûts, de ses attentes et de l'utilisation qu'il en fera de choisir SA distribution, ou de la faire s'il est du type jamais content :-) (</violons).
Vala, j'avais dit que c'était tout et je ne m'arrête plus.
Enfin, je m'interroge sur la nature *réelle* du comment :
est-ce un fake, ce que le nombre d'ineptie et le dernier paragraphe
me fait penser, ou est-ce que l'auteur est vraiment aussi con qu'il y paraît ?
Internet en général et LinuxFr en particulier est assez sujet à ce genre d'interrogations :
on y rencontre tellement de sites, CV, qui ne sont pas des fakes
et qui pourtant pourraient très bien en être, qu'on finit par se méfier de tout.
Et puis, l'ironie passe très mal par écrit.
De toutes façons, le premier commentaire, s'il se voulait à caractère publicitaire, aurait plutôt l'effet contraire :-)
Ce genre de commentaire commence à m'agacer au plus haut point.
Je ne vois pas en quoi cette nouvelle aurait un caractère publicitaire. A moins qu'on considère que, comme à la télévision, le fait de mentionner un produit commercial serait de la publicité. Si l'on reprend la news depuis le début : que voit-on :
1) SuSE est la première à sortir une distribution de GNU/Linux finalisée sur la plate-forme Itanium, c'est vrai, et ça mérite d'être mentionné.(ça a plus d'intérêt si c'est le premier). Informatif.
2) Le reste est au présent simple, car description de faits réels, donc informatif aussi.
Cette news me semble purement informative. Encore une fois, si donner une information concernant un produit commercial est de la pub, alors LinuxFr sera grandement incomplet, puisqu'il ne parlera pas de ce qui se fait dans le monde Linux dans sa globalité.
Voilà, tout ce que j'avais à dire pour aujourd'hui.
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par Manuel Menal . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 4.
Non, ce n'est pas particulièrement optimiste. Les choses dont je parle précédemment sont presque prêtes, et, si il y'a encore quelques mois on ne pouvait avancer de date pour leur intégration, il est évident que toutes ces avancées majeurs auront lieu au premier trimestre 2001, avant l'été - ou un peu pendant. Par exemple, le passage à la libio et la libc0.3 est prévu pour juste après le mariage de Jeff Bailey - :) - soit courant avril..
OSKit-Mach est depuis longtemps bootable, assez stable, 'tc.. Il lui manquait particulièrement un support console décent, qui avance à grands pas, et sera bientôt prêt de l'avis même de son créateur.. Pour ces projets, on peut clairement dire qu'ils seront bientôt prêts. Maintenant, il y'a d'autres objectifs à long terme qu'il sera plus dur d'atteindre: le port du Hurd sur L4 ne sera pas fait d'ici un bout de temps, sera dur, demandera énormément de travail. Il vient tout juste d'ailleurs de _vraiment_ commencer. (c'est ce genre de signes qui montre que le Hurd _avance_.. L4-Hurd existe depuis des années et des années, et commence _maintenant_, c'est qu'on est à une période clé..). De même, la réécriture de pfinet sera quelque chose de long, passionant, mais extrêmement difficile, et peu de gens dans le Hurd possède les compétences nécessaires - s'il y'en a. Donc, pour ça, je ne me hasarderai pas à donner une date..
Pour l'instant, je n'ai pas vu *un* problème technique de la vie de tous les jours ou du
monde de la production que Hurd puisse prétendre résoudre mieux que la concurrence.
"aussi bien" ne passe pas mieux. :o(
Reprenons mon "gros" post:
1) une disponibilité sans pareille, notamment en terme de local down time (entendez, quand la machine est éteinte, ou en tous caa pas utilisables en local), mais aussi en down time "traditionnel", c'est à dire, le moment où la machine est up & running, mais pas joignable depuis le Net, ou le LAN où elle est utile. La modularité du Hurd permet notamment d'avoir des pfinet en relai - c'est _possible_, pas _fait_ - qui éviteraient pas mal de problèmes..
2) Une sécurité bien plus avancée, via le système des jetons d'authentification, qui permettent d'avoir un réel unknown, et de n'avoir que les permissions nécessaires - et donc, les permissions root que quand c'est absolument nécessaire.
La possibilité d'avoir un login shell peut s'avérer aussi tout à fait intéressante, même en production..
le Hurd semble lui encore un peu en retard.
Ça ne veut strictement rien dire. Un projet en développement serait nécessairement en retard ? Je l'ai dit et répété - alors, merci de bien vouloir _lire_ avant de parler - le Hurd est un projet en cours de développement, qui n'est pas abouti, et on ne prétend pas que GNU soit capable de remplacer GNU/Linux dans la vie de tous les jours dans un futur très proche.
À croire que certains sont incapables de sortir de leur logique de consommateur, pour s'intéresser à des avancées technologiques d'importance même si elles ne sont pas prêtes à être utilisées couramment sur leur petite machine, pour rendre leur vie so coooool. Tu m'étonnes qu'on manque de feedback dans les logiciels libres..
[^] # Re: RMS est mort, vive Linus
Posté par Manuel Menal . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 6.
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: Oui mais...
Posté par Manuel Menal . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 10.
Pas tout à fait. Marcus Brinkmann est actuellement probablement le développeur principal du Hurd, celui
qui est le plus actif. Il a de plus le mérite d'être arrivé dans le monde du Hurd autour de '98-'99, à un moment où le Hurd était un projet plutôt inactif depuis plusieurs années - environ 7 ans -, et de l'avoir relancé à lui tout seul, en créant Debian GNU/Hurd, etc. Mais, les architectes principaux du Hurd sont Thomas Bushnell et Roland McGrath, les deux ayant été un temps employés par la Free Software Foundation, et le deuxième étant un grand personnage - comme dit précédemment, auteur de la GNU Libc, co-auteur de GNU Make, maintainer d'une partie de GNU Emacs, etc. Thomas ne participe plus aujourd'hui au Hurd que pour donner son avis, et parce qu'il connaît bien le sujet, quand même. Mais, il consacre son temps à la philosophie. :)
Roland participe encore aujourd'hui au Hurd, même s'il ne le peut pas très activement étant donné qu'il doit quand même vivre - par sa propre boîte, FrobTech.
Alors, donnez à la FSF pour qu'elle emploie Roland! :-)
Pour reprendre la deuxième partie, je suis tout à fait d'accord. Il faut noter de plus que la FSF n'a aidé le Hurd qu'à ses débuts, et qu'elle n'a pas été une grande aide du tout pendant pas mal d'années, le considérant comme un projet mort jusqu'il y'a peu de temps - à tort, je l'affirme, et en conséquence, ne donnant aucun moyens aux développeurs - développer un tel logiciel demande pas mal de moyens, car cela nécessite généralement plusieurs PC, des PCs très performants. Ainsi, il aurait été d'une grande aide qu'on ait accès plus tôt à plusieurs machines sous GNU via SSH, mais il a fallu attendre que l'université de Massachusetts
Lowells, où étudie Neal Walfield, donne deux/trois machines.. Espérons que l'annonce de RMS s'accompagnera des moyens qui seraient nécessaires pour avoir un système GNU parfaitement utilisable rapidement, notamment en terme d'emploi de personnes par la FSF.
[^] # Re: Hurd, ça fonctionne ?
Posté par Manuel Menal . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 2.
Relis donc mon post. Jamais nous n'utiliseront OSF Mach qu'à des fins de portages, et ce de façon tout à fait temporaire. Les seuls noyaux que le Hurd utilise officiellement, c'est GNU Mach, et sa variante utilisant les drivers du projet OSKit <http://www.cs.utah.edu/flux/oskit/>(...) , OSKit-Mach, qui est la seule version développée depuis quelques temps et qui avance vite - notamment au niveau du joli nouveau support console, avec support de l'internationalisation excellent, multi-head, splitvt, équivalent de screen -rx, etc..
Moi, personnellement, ce genre d'effet d'annonce me fait furieusement pensé à ... Mr Bill Gates. Juste pour que l'on s'interesse à son projet. Bon, je pousse un peu quand même, je le reconnais (=> -1).
Il faut voir aussi que son post a été détourné. Il n'a pas dit explicitement que GNU remplacerait GNU/Linux partout dans toutes les machines d'ici la fin de l'année. En revanche, il a annoncé une release de GNU, ce qui veut dire en réalité que la FSF prépare sa propre version du GNU, qui reprendra probablement beaucoup de Debian GNU/Hurd, mais qui sera indépendant de Debian.
Il me semble que ça méritait d'être annoncé, mais ne méritait peut-être pas toute la réutilisation qui en a été fait sur /. et ici même.
[^] # Re: Oui mais...
Posté par Manuel Menal . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 4.
Le Hurd est actuellement porté sur x86 et sur PPC, comme cela a été dit plus tôt. Cependant, il faut savoir que le Hurd lui-même est extrêmement portable - le port PPC n'a nécessité que très très peu de modifications au Hurd lui-même - et qu'il suffit donc de porter le micro-noyau - Mach actuellement. Ce micro-noyau, sous la forme d'OSF Mach - identique à GNU Mach modulo quelques modifications mineures, a été porté sous de nombreuses plate-formes, que ce soit des ports officiels (DEC Alpha, m68k, etc.) ou des ports non officiels (plus récemment, MIPS, et plein d'autres architectures..).
Porter le Hurd n'est donc vraiment pas chose difficile, d'autant plus qu'il a toujours été conçu pour être tout à fait portable. Concernant les architectures sans MMU, je ne sais pas vraiment ce qu'il en est des ports Mach, donc je ne m'avancerais pas. D'autant plus que je connais pas trop ce genre d'architectures..
Concernant le temps réel, c'est quelque chose qui est assez naturel, bien que le Hurd n'ait pas été conçu pour être temps réel, et ne l'est pas à l'heure actuelle. Si tu veux parler de simples extensions temps réel comme celles définies par le standard POSIX, leur support est partiel, mais est complètement possible, et même, pas très dur à implémenter.
Pour ta dernière phrase, j'avoue que j'ai du mal à la comprendre. S'il s'agit de faire un « light Hurd » pour le faire tourner sur des architectures
matérielles disposant de peu de mémoire, oui, c'est tout à fait possible. Il est notamment tout à fait possible d'élaguer considérablement le Hurd, en ne compilant que les serveurs essentiels,
ce qui réduira sa taille de façon très importante très facilement. De plus, l'indépendance de chaque application permet de facilement remplacer les serveurs qui pourraient poser problème pour le portage sur ces « petites » machines par d'autres, ne fournissant qu'un subset basique de ce que l'application d'origine fournissait. C'est ce genre de flexibilité que permet une architecture à micro-noyau, et un système multi-serveurs comme le Hurd, justement ..
Ceci dit, je le répète, le Hurd n'est pas fini, et GNU n'est pas une alternative viable à GNU/Linux pour l'utilisation quotidienne, à l'heure actuelle. Non pas tellement par son manque de fonctionnalités - ça se rebouche très vite.. - mais pour des questions de stabilité - sachant que l'ensemble du feature set n'est pas encore tout à fait implémenté, la stabilité n'est pas _la_ considération principale - et de performances. (le Hurd n'est pas du tout optimisé, ni GNU Mach, et GNU Mach n'est probablement pas le meilleur choix pour les performances - bien qu'il présente de nom breux avantages).
[^] # Re: compatibilité binaire
Posté par Manuel Menal . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 10.
La compatibilité binaire est effectivement prévue, comme un objectif à long terme, mais n'y comptez pas dans le futur proche.
Mais je tiens à réagir sur ton affirmation disant que « Comme les 2 OS ne diffèrent pas de grand chose (le kernel et l'interface avec le kernel) ».
C'est complètement faux. FreeBSD et GNU/Linux ont bien plus de points communs que GNU. Ils sont tous deux extrêmement proche d'Unix, alors que GNU n'est pas à la base proche d'Unix - le Hurd et la GNU Libc s'efforcent juste de fournir une compatibilité POSIX.
En particulier, concernant le Hurd, nombre de notions classiques sous Unix n'existent plus:
* La notion de fichier en soi. Comme déjà dit dans mon commentaire précédent, le fichier n'est plus à la base qu'une interface permettant de joindre une application, et le système de fichiers n'est plus qu'un espace de nom pour obtenir des ports. Il est évident que le Hurd supporte néanmoins ext2fs, et UFS, et donc la notion de fichier tradionelle. Cependant, ça n'est pas un concept propre au Hurd, et les appels systèmes habituels de manipulation des fichiers ne sont que des interfaces de compatibilité - pour les basiques, réalisables via de simples RPC (Remote Procedure Call) à l'application qui écoute derrière, mais beaucoup plus difficilement pour certains autres, et en particulier, pour retourner des erreurs dans des cas précis définis par POSIX...
* Les notions traditionneles d'UGIDs (entendez, UID et GID). Le modèle « un programme, un (e)UID » est complètement cassé pour faire place au principe des jetons d'authentification (authentification tokens), modèle bien plus puissant, où l'on peut acquérir - via le serveur password - plus de droits dynamiquement - sans pour autant devenir root, vu que l'on peut avoir plusieurs jetons correspondant aux droits de plusieurs utilisateurs, en soustraire - jusqu'à ne plus en avoir du tout, permettant l'existence d'un _réel_ nobody - il est dit « unknown » - qui n'est __pas_ un utilisateur, et n'a à la base aucun droit - si ce n'est utiliser ce que l'application a créé avec des droits supérieurs auparavant bien entendu, sauf si l'administrateur lui en donne - il y'a maintenant plus seulement ugo, mais aussi ugok, pour unKnown. Cela est particulièrement intéressant concernant les applications devant ouvrir un port « sécurisé » - comme un FTPd - (< 1024), requierant les droits root: on lance l'application en root, on ouvre le socket, on bind, listen, et dès que tout cela est fini, on s'enlève tous les droits. Ainsi, une faille à ce niveau n'aurait _aucune_ conséquence, puisqu'il ne pourrait _rien_ faire.. Par la suite, il n'y a plus qu'à transmettre les données fournies par l'utilisateur au prompt de son client FTP au serveur password, l'authentifier, et le voilà avec ses propres droits d'utilisateur et pas plus, sans
aucune difficulté.
De même, ce concept de serveur auth à qui on demande l'autorisation avant de faire n'importe quelle opération permet d'implémenter facilement, de façon jolie, performante, et native, le système
des capabilities Linux - connu pour son inflexibilité, ce qui explique pourquoi il est si peu utilisé.. - et les prétendus systèmes révolutionnaires comme LIDS.
Par faute de temps je m'arrêterais là, mais il faut savoir qu'il y'a encore de nombreux exemples, et qu'au fur et à mesure, si la compatibilité POSIX devrait s'améliorer, le Hurd devra s'éloigner d'Unix, essayant de faire mieux pour tous les domaines - par exemple, concevoir un nouveau système d'init, pour remplacer les init SysV et BSD, qui ne sont pas des modèles de propreté et d'efficacité ANHA. Cependant, ça n'est pas spécifique au Hurd: c'est une idée générale derrière le GNU, et beaucoup des codes faits pour le Hurd sont en fait réutilisés dans les autres ports de la GNU Libc - pensons à argp, aux pthreads, au futur système d'init justement..
Ah oui, dernière chose: ta distinction entre userland et serverland n'a pas du tout lieu d'être. Les applications qui composent le Hurd - le micro-noyau ne faisant PAS partie du Hurd - sont des applications e-x-a-c-t-e-m-e-n-t c-o-m-m-e les autres, certaines ayant des rôles similaires à des applications que tu peux trouver sous GNU/Linux.
Commentaires, questions, tout cela est bienvenu, je me sens tout seul sans réponse. :)
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par Manuel Menal . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 8.
Comment je fais pour mes programmes threadés ?
Le Hurd lui-même est multi-threadé jusqu'à la moëlle. Il y'a donc bien gestion des threads. Il s'agit en fait des C-Threads, seule interface gérée par Mach pour ses threads kernel -- il avait été question d'un support des POSIX Threads, qui est évoqué dans les docs du CMU Mach, mais il semble n'avoir jamais vu le jour. Maintenant, il est vrai que rares sont les programmes qui utilisent les C-Threads, et qu'ils présentent des inconvénients majeurs par rapport aux pthreads..
Cependant, une implémentation des pthreads pour le Hurd, mais devant être un maximum portable - contrairement aux LinuxThreads de Xavier Leroy - est en cours de développement. (cf. <http://savannah.gnu.org/projects/pthreads/>(...)). Si elle n'est pas encore finie, elle réprésente un enjeu majeur selon tout le monde, et les meilleurs développeurs du Hurd y sont impliqués - Marcus Brinkmann, Roland McGrath (auteur de la GNU Libc, un des maintainers de GNU Emacs, co-auteur de GNU Make, un des deux concepteurs du Hurd...), ce qui pourrait amener une version stable avant l'été.
Ca gère mon SMP ?
En théorie, oui. Le SMP n'est pas la priorité du Hurd à l'heure actuelle, mais le support est bien présent, et il devrait le gérer à merveiller. Il reste un certain nombre de choses à faire pour qu'il exploite totalement ce SMP, mais ce ne sont pas des trucs vraiment difficiles à faire - même très faciles..
La NVidia, elle fonctionne ?
La NVidia, via le driver nv, oui. Si tu voulais parler des drivers NVidia propriétaires et du module Linux fourni, il est évident que non. Mais, c'est propriétaire ...
Et mon modem ADSL ?
Ça dépend. Le support USB n'est pas au programme. Concernant les modems ethernet utilisant PPPoE, le support PPPoE n'est pas encore fonctionnel, mais votre serviteur travaille actuellement sur un port de RP-PPPoE - comme cela a été fait pour FreeBSD, ce qui ne pose pas de problème majeur, le support PPP étant parfaitement fonctionnel.
Wala, wala, comment utiliser un troll pour présenter l'état actuel de la chose :-)
[^] # Re: Hurd, ça fonctionne ?
Posté par Manuel Menal . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 8.
Sinon, pour répondre au comment précédemment sur la FAQ: non, GNU n'est pas encore usable en production. Non, il n'est pas aujourd'hui envisageable de l'utiliser dans la vie de tous les jours à la place de GNU/Linux avec un gain; Il peut faire à peu près tout ce que fait GNU/Linux, le problème est qu'actuellement, il n'est pas du tout optimisé, et il y'a encore de nombreuses limitations et problèmes d'instabilité.
Pour commenter les déclarations de RMS: Il n'a pas rendu service, AMHA, au Hurd, en disant cela. Et les premiers surpris ont été les développeurs du Hurd. Marcus (Brinkmann, qui a relancé le développement du Hurd en '98-99 après environ 7 ans au ralenti, fondé Debian GNU/Hurd, etc.) a franchement fait la gueule quand il a vu la news sur /. et imaginé le nombre de conneries qui allait se dire :-) Tout ça pour dire: ne le prenez pas _trop_ au sérieux. Ça ne veut pas se dire qu'il faut se déinstéresser du Hurd: il mérite à mon avis qu'on y jette un oeil, et, c'est un projet qui a vraiment besoin de participants, et celà à tous les niveaux. En plus, on se sent vite important, et on est très encouragés :)
Moralité: Le Hurd? Engagez-vous, rengagez-vous!
[^] # Re: rms l'utilise deja ...
Posté par Manuel Menal . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 10.
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..
# Réponse au document: Les micronoyaux, c'est nul!
Posté par Manuel Menal . En réponse à la dépêche Comment WinXP est né. Évalué à 10.
MA> AT prêchait pour les micro-noyaux. LT était parti de Minix, mais AT considérait son "oeuvre" comme un jouet ou un vague support de cours.
Effectivement. AT est un chercheur. Il a donc fait Minix dans une optique de recherche. Le Hurd n'est pas fait par des chercheurs pour des chercheurs, et cherche à être la vraie alternative à Linux. D'ailleurs, Minix existait et tournait assez bien, quoi qu'on en dise.
MA> A une époque reculée, tout le monde était persuadé que la seule façon de faire un système portable était d'utiliser un micro-noyau.
MA> Linux et NetBSD ont prouvé le contraire.
A une époque reculée, on le pensait peut-être, je ne peux me prononcer au nom de ceux qui argumentaient pour les micro-noyaux alors que je marchais à peine. Il est clair que la théorie des micro-noyaux aide forcément à construire un système portable. (Le Hurd a récemment était porté sous PPC très facilement, à l'aide d'une version de OSF Mach précédemment portée sous PPC. On peut penser que par la suite, entre autre avec le passage à L4, le port vers d'autres architectures se fera très facilement, vu la taille de L4 et le fait qu'il existe déjà pour de nombreuses architectures). Cependant, aucune notion d'exception là-dedans. On peut très bien faire du code au maximum portable dans un noyau monolithique. Dire le contraire serait une aberration... Comme on peut faire du code non portable en utilisant un micro-noyau.
MA> * MkLinux va a peine plus vite que MacOS sur Power Mac.
Super. Et ensuite ? Prendre des exemples n'est pas combattre une théorie. Ensuite, il faut savoir que MkLinux est basé sur le noyau Mach, qui n'est certainement pas le plus rapide, en tant que noyau de première génération. (contrairement à L4..) De plus, il s'agit d'un mono-serveur, ce qui n'aide généralement pas pour les performances. A ce sujet, on pourra lire 'The Performances of µ-Kernel-based systems', disponible à l'adresse: http://os.inf.tu-dresden.de/pubs/sosp97/(...) (et bien entendu toutes les autres publications sur http://os.inf.tu-desden.de/L4/doc.html(...) ).
MA> * Hurd, est totalement instable, rame, et n'est justifié que par la haine de RMS envers Linux.
Il est évident que je ne peux pas laisser passer ça.. Tout d'abord, petite correction qui montre que l'auteur ne s'est même pas renseigné avant: on écrit le Hurd, et pas Hurd. Deuxièmement, l'argument d'instabilité est un peu ridicule.. Évidemment qu'il l'est. Le Hurd n'est pas abouti. Sa stabilité s'améliore de jour en jour, et devient de plus en plus utilisable. Il a des points faibles, qu'on connaît: pfinet, un mauvais hack de la pile TCP de Linux qui limite de façon considérable ses capacités réseau. (PPP est sur le point de fonctionner parfaitement cependant! :), le serveur ext2fs, et la VM de Gnumach. (qui a dit, Gnumach en général? :) zalloc en particulier.). Mais il n'est pas particulièrement instable, il peut déjà tenir un uptime de plus d'un mois, et pourrait bien plus s'il n'y avait pas ces problèmes de zalloc. (ce qui n'est pas un problème du Hurd, qui comme chacun sait est en théorie indépendant du micro-noyau.)
Quant à sa lenteur, elle est effective. Les performances représentent un sujet très difficile à traîter car sujet à de nombreux paramètres en particulier liés à l'implémentation. Juger les performances d'un système non abouti ne me semble pas être très représentatif. On pourra notamment citer Evolution, qui était *extrêmement* lent jusqu'il y'a peu et qui a, quoi qu'on en dise, améliorer grandement ses perfs. (no troll, please..). Il faut quand même savoir que:
1) Le Hurd n'est optimisé d'aucune façon. Les perfs n'ont pas été le but originel, et même si c'est un sujet que les développeurs gardent en tête lors du développement, ça n'est pas la préoccupation principale, et elle se concrétise plutôt par des comments sur ce qu'on devrait faire (et qui est faisable.. donc susceptible d'être fait dans le futur) que par du code, permettant ainsi de se concentrer plutôt sur le feature set.
2) Mach, même si ça n'est pas la seule raison de la lenteur du Hurd, n'est pas un modèle concernant les performances (je vous incite toujours à lire le papier ci-dessus...), et encore moins Gnumach.
Quant à RMS, je ne vois pas ce qu'il a à faire là-dedans. RMS ne suit plus le développement du Hurd depuis longtemps, et la FSF est peu au courant de ce qui s'y passe généralement.. (un sursaut soudain vient d'arriver, et on espère qu'on aura bientôt un nouveau développeur à plein temps..). RMS n'a aucune haine envers Linux, pour en avoir discuté avec lui, et pour avoir lu nombre de ses publications.. Il est effectivement en désaccord avec Linus, qui se soucie peu, à vrai dire, du côté philosophique du libre. Il me semble que le Hurd s'inscrit dans la logique du projet GNU: refaire un système du type Un*x, mais pas une simple réécriture libre d'Un*x, ce qu'est finalement, à la base, Linux (les améliorations se trouvant avant tout dans l'implémentation et non dans le design..). Je pense que le Hurd est viable, mais n'ai aucun moyen concret de le prouver tant que le Hurd n'est pas totalement abouti et ne représente pas une alternative viable à Linux sur le bureau et sur les serveurs. L'attitude à adopter me semblerait plutôt être: Let's code it and see if it can be as cool as they say. (ou, let them code it si vous n'avez aucune envie de vous plonger dedans..)
MA> * Spring, l'OS expérimental de Sun, est arrêté. Je ne crois pas qu'ils aient relaché les sources. Le labo qui l'a conçu s'est amusé un moment avec, ils ont tenté de
MA> * récupérer certaines idées dans SunOS 5, puis ils sont passés à autre chose.
Effectivement. Et ensuite ? Il me semble qu'il s'agissait plutôt d'un OS expérimental à des fins de recherche, qui n'avait d'autre but que d'être un lieu de test pour des fonctionnalités à implémenter dans l'OS qu'ils comptaient garder comme seul OS principal, SunOS. Je me garderais bien de tout commentaire, ne connaissant pas bien son design autrement..
MA> * WinNT, est loin de la maturité et se débarrassera probablement de l'aspect micro-noyau avant de se débarrasser de ses nombreuses bogues.
L'expérience, et Windows 2000, prouve que celà est faux. On notera d'ailleurs que (NO TROLL PLEASE) Windows 2000 est probablement le meilleur des Windows existants, et à ce que j'en ai entendu dire, plus fiable que ses prédécesseurs. Excusez-moi, mais un système à micro-noyau où au fur et à mesure on a implémenté le maximum dans le kernel space (je sens que je vais avoir le droit au pBpG), on peut difficilement prendre ça comme référence.. D'autant plus qu'on en a pas les sources, ce qui rend le jugement assez difficile.
MA> * DEC OSF/1 est maintenant un machin monolythique. On ne voit plus mentionné le micro-noyau dans leurs docs.
MA> En fait, ça ressemble furieusement à un SunOS 4, même si c'est (très) différent en interne.
Même chose: et alors ? Ils sont passés à autre chose, parce qu'ils avaient d'autres besoins, que Mach ne comblait finalement pas.. Ca n'est pas un argument concernant les micro-noyaux, que je sache. Si mes souvenirs sont bons, on m'a dit en cours de français qu'un exemple n'était pas un argument.
MA> * AIX aurait été micro-noyautesque en des temps trèèès anciens ?! Mais vu tout ce qui a été tartiné autour, personne n'a jamais vu le micro-noyau.
De même. Je ne connais pas le cas d'AIX, mais une chose courante est que les développeurs, après avoir eu de bonnes idées concernant le design, n'étant contrôlés par pas grand monde, se laissent aller à la facilité et mette tout ça de façon inorganisée un peu n'importe où, voire même dans le micro-noyau. Programmer un système à micro-noyau demande certainement de la rigueur, c'est sûr: il est tellement facile de faire un foutoir du genre monolithique tel que le décrit André Tanenbaum dès les premiers chapitres de tous ses livres sur les OS.
MA> * Dans Mach 4, ils ont remonté le réseau dans le micro-noyau pour des questions de perfos.
MA> C'était prohibitif -- une demie-douzaine de context switch sur chaque paquet (au bas mot), il y a de quoi mettre à genoux n'importe quelle bécane.
Tiens donc. Il m'avait toujours semblé, à la lecture des docs OSF/CMU (dès les docs de Mach3) que ç'avait été pour permettre d'avoir un système à plusieurs hosts/nodes, plusieurs Mach tournant.
Pour les context switches, l'argument est un peu vague. Où est la demi-douzaine? J'aimerais le savoir, à la vue de pfinet et, surtout, des projets qui ont été faits pour le remplacer.
MA> Fondamentalement, c'est une aberration. Quand on voit le nombre d'attaques ou de bogues qui tournent autour de TCP/IP,
MA> on se dit que la robustesse du micro-noyau en prend un vieux coup sous la ligne de flottaison.
J'avoue que j'ai du mal à comprendre, là. Avoir la gestion réseau (la pile TCP, etc..) dans le noyau est une aberration, parce qu'elle est susceptible de faire crasher l'intégralité du système ? On est bien d'accord, et c'est là un argument contre les noyaux monolithiques. De plus, il ne me semble pas que la gestion du réseau soit totalement implémentée dans Mach4. Et encore une fois, Mach n'est pas le seul micro-noyau. L4 serait un exemple plus intéressant d'un vrai µ-noyau.
MA> * Dans le dernier Mach OSF, certains envois de message ont été remplacés par des appels de procédures ;
MA> certains serveurs partagent dans le même espace d'adressage pour éviter les context switchs.
1) Oui, on limite au maximum les messages, puisque cela transite par le noyau. Et ensuite ?
2) Pardon ? un exemple plus précis ? Si l'on peut éviter des context switches, par des biais tout à fait sain, on le peut. Que je sache, ce que vous décrivez n'a pas été fait tel quel.
De plus, c'est un argum^Wexemple contre Mach. Pas contre la théorie des micro-noyaux.
MA> Admettons : on peut "valider" certains serveurs et les passer dans le noyau. Mais c'est se faire des noeuds au cerveau:
MA> quand tout sera "validé", on aura un OS monolythique pas forcément plus stable qu'un autre -- BSD au hasard.
Ca n'a jamais été le but des concepteurs de micro-noyau, et encore moins celui du Hurd. (par exemple). Le mouvement se fait dans le sens inverse, au fil du temps: mettre le maximum de choses dans l'user space pour n'avoir dans le kernel space qu'une IPC basique, et une gestion de la mém et des procs basiques (et un accès hard minimal, quand même..): c'est ce que fait L4, encore une fois.
MA> les micro-noyaux se rapprochent des OS monolythiques et les OS monolythiques intègrent des fonctions qui ressemblent à ce qu'on trouve sur les micro-noyaux.
MA> Par exemple, les "modules" et pilotes chargeables de Linux.
Dans le premier cas, je ne suis pas du tout d'accord, et l'évolution dans la recherche sur les micro-noyaux (et l'évolution du Hurd) montre le contraire, le mouvement kernel space->user space que je citais précédemment.
Dans l'autre sens, il est évident qu'on ne peut comparer les modules Linux et les serveurs du Hurd... Cependant, effectivement, cela a apporté une souplesse importante. (d'ailleurs, dans certaines versions récentes de Mach, ce système existe.) Il me semble que ça n'est jamais que ce qui se fait habituellement sous Linux, rajouter un truc, intéressant certes, par dessus, sans tout changer en profondeur. (faire un micro-noyau!) (pensez à ftpfs sous Linux...)
MA> Donc quelque part, tout ce travail n'a pas été inutile puisqu'il est récupéré dans les systèmes modernes.
Les systèmes modernes, comme le Hurd, comme QNX ? ;P
MA> Un projet comme Hurd est-il bien raisonnable ?
MA> Ne serait-ce pas "l'art pour l'art" ? Dans Computer power and human reason, Josef Weizenbaum dénonce the empire of instrumental reason.
MA> Nous y voila...
C'est ce que le Hurd tend à prouver: que les micro-noyaux ne sont pas une vue de l'esprit, un jouet de recherche sans intérêt pratique.. Il me semble clairement que le Hurd, qui est aujourd'hui
utilisable et existe réellement, le montre déjà. Et qu'il présente des intérêts, c'est indéniable: on peut déjà montrer les avantages du Hurd, au niveau sécu, au niveau shadowfs, etc..
MA> In fact, this made me think that the microkernel approach was essentially a dishonest approach aimed at receiving more dollars for research.
Effectivement, c'est un argument qu'il a maintes fois énoncé contre le Hurd par la suite: qu'il est trop théorique et pas assez pratique. A cette question, je pense qu'on ne peut que répondre: regardez. Il existe. Il marche. Il s'améliore.
Des gens le codent. Rendez-vous dans quelques années...
Voilà, that's all folks.
DISCLAIMER: aucune attaque contre l'auteur, qui est par ailleurs quelqu'un de compétent. Le document ne présente pas *aucun* intérêt, et on ne peut pas le comparer aux FUD habituels, faits par Microsoft, notamment. Mais les propos ne m'en semblent pas plus justifiés..
[^] # Re: Debian Sid
Posté par Manuel Menal . En réponse à la dépêche Faille dans OpenSSH 2.5.x et 2.9.x. Évalué à 1.
Le commentaire du dessus portait à confusion, SSH2 != OpenSSH2 dans mon esprit, donc bon...
Reste que de fait SSH2 n'est pas dans Debian :-)
[^] # Re: Debian Sid
Posté par Manuel Menal . En réponse à la dépêche Faille dans OpenSSH 2.5.x et 2.9.x. Évalué à 6.
Les paquets de SSH2 sont donc dans non-free, et de ce fait on ne peut pas dire qu'ils fassent partie de Debian... Souvenez-vous de la longue flamewar sur la suppression du répertoire non-free: non-free ne fait _pas_ partie de Debian, ce sont un ensemble de paquets généreusement hébergés par Debian (et généreusement maintenus par des développeurs Debian (ou par qa comme SSH2, bien sûr:)).
Bon, ok, j'avoue, c'est un peu du chipotage, mais bon, faut bien s'occuper quand on est malade :-)
Toujours est-il que ça montre encore une fois que les logiciels libres ne sont pas plus sujets aux alertes de sécurité, au contraire :-]
[^] # Re: Distribution "en boîte" et ADSL, c'est compatible?
Posté par Manuel Menal . En réponse à la dépêche Interview de Mandrake. Évalué à 10.
En effet, les acheteurs des boîtes, comme tu l'as dit toi-même, sont principalement des débutants à la recherche d'une sécurité, -- acheter une boîte faîte par une entreprise commerciale, ça sécurise tout de suite, quoi qu'on en dise -- d'un manuel, d'un support, etc... Ces gens-là à mon avis continueront d'acheter des boîtes, uniquement pour la sécurité et les quelques services donnés avec les CDs...
Il est possible que dans ton cas tu aies préféré le téléchargement d'une distribution à l'achat d'une boîte. Mais, cette démarche est plutôt celle d'un bidouilleur que celle d'un débutant complet -- qu'il devienne bidouilleur plus tard ou pas, là n'est pas le problème :-). Or, il me semble évident que GNU/Linux est destiné à une utilisation encore plus grand public qu'aujourd'hui. C'est pourquoi à mon avis les ventes de boîtes de distributions ne vont pas baisser, ou alors dans une moindre mesure, et ce seulement au début, car je crois au succès de GNU/Linux à long terme...
Vala.
[^] # Re: Hors sujet: à propos du système de vote
Posté par Manuel Menal . En réponse à la dépêche Polices anti-aliasées sous GTK+. Évalué à 0.
(5 pour un débutant, plus ensuite [merci woof :)], 100 pour god [encore merci et *smoutch*]).
[^] # Re: iNTROUVABLE SUR PARIS
Posté par Manuel Menal . En réponse à la dépêche Linuxmag dans les bacs. Évalué à 1.
dans une news ayant le même sujet dans un "échange" entre Julien Blache et moi-même.
Mais notons que même moi, en région parisienne, je l'ai reçu aujourd'hui. (abonné). Donc il devrait être rapidement disponible dans ta crémerie, si tant est qu'elle soit bonne, bien entendu.
[^] # Re: ... mais on peut faire plus efficace.
Posté par Manuel Menal . En réponse à la dépêche Aider financièrement.... Évalué à 2.
de proposer une somme d'argent (souvent assez importante) contre l'ajout d'une fonctionnalité à un logiciel (libre),
la création d'un nouveau logiciel, (libre encore) etc.
Il semble que le Free Software Bazaar ait disparu, http://visar.csustan.edu/bazaar/bazaar.html(...) étant 404 chez moi.
En revanche la traduction française de Nat Makarévitch (avec ou sans l'accent :-)
existe toujours à l'adresse http://www.linux-france.org/prj/fsb/(...) .
Ce que Bernhard Herzog propose me semble plus proche Free Software (Gift) Exchange Registry (a.k.a FSEX),
à ceci près qu'ici le don serait pour des raisons précises.
(l'aider à pouvoir continuer à vivre en développant son prog...)
My $0.2 cents.
[^] # Re: hmm
Posté par Manuel Menal . En réponse à la dépêche Contrôle du bootloader. Évalué à -1.
Une grosse merde ouais ;p
Pour ton lifting pas grave je te haïrai quand même, ne t'inquiète pas.
-1 aussi, vous ne pouvez toujours pas comprendre
(wooooooooo[...]oooof revient!)
[^] # Re: hmm
Posté par Manuel Menal . En réponse à la dépêche Contrôle du bootloader. Évalué à -1.
petit salopiaud! Mais vas-y vas-y rappelle-moi
ma hcp encore plus cassée que la tienne ou ta gueule d'ange aussi tant que tu y es ;-)
Tu sais quoi ?
*JE TE HAIS* *JE TE HAIS* *JE TE HAIS* *JE TE HAIS* et ce qu'il en découle.
[^] # Re: hmm
Posté par Manuel Menal . En réponse à la dépêche Contrôle du bootloader. Évalué à 1.
Au passage, juste comme ça : j'utilise GNU/Linux depuis bien avant mes quinze ans, et je ne suis pas le seul, Arnaud Willem n'a même pas ses quinze ans ;-p
De même, mon père, dont je ne dévoilerai pas l'âge mais dont je peux dire qu'il est supérieur à 50 [;-)]
utilise GNU/Linux et ce depuis quelques années déjà...
Et d'après ce que j'ai lu récemment ici-même il n'est pas le seul quinquagénaire :-)
Quant à l'argument "hard compatible", il est complètement irrecevable: aujourd'hui la plupart du matos est reconnu sous GNU/Linux, et de même sous Windows, je pense que je n'ai pas besoin de le préciser...
Et pour finir, ta dernière remarque montre bien ta méconnaissance du monde Linux... Ou ton envie de troller. C'est pour ça que je laisserais d'autres s'échiner à y répondre, s'ils ont le courage...
(oh la zoulie mise en page... Bon, trop la flemme de revoir tout)
[^] # Re: luxembourg sux
Posté par Manuel Menal . En réponse à la dépêche Linux Days 2001 - Luxembourg. Évalué à -1.
Hop, -1, mais j'assume quand même mes actes...
(pour 3 mois, *grmbl*)
[^] # Re: Génial c'est pas le cas de tout le monde ...
Posté par Manuel Menal . En réponse à la dépêche Articles Open Source. Évalué à 1.
Effectivement, malgré cela, ils ne sont pas tous disponibles sur le site web _pour le moment_.
Mais je te rappelle que le webmaster, Denis Bodor, est également le rédacteur en chef du magazine, et l'auteur de pas mal d'articles dans chacun de ses numéros, et, accessoirement, le père de deux enfants. C'est donc un homme pour le moins débordé, et tu comprendras que le passage des articles en TexInfo et leur publication sur le web passe après ses gosses ou la parution des nouveaux numéros.
Enfin, je ne veux pas parler à sa place mais je pense qu'on peut lui pardonner, vu l'énorme boulot qu'il fait déjà.
[^] # Re: Ne pas dramatiser ...
Posté par Manuel Menal . En réponse à la dépêche JSR47 vs. log4j ou les problèmes de la licence Sun sur le langage Java. Évalué à -1.
Voilà, aucun intérêt, comme le reste d'ailleurs :p
[^] # Re: « SuSE n'est pas libre »
Posté par Manuel Menal . En réponse à la dépêche SuSE annonce la disponibilité de SuSE 7.2 pour Itanium (Version commerciale). Évalué à 1.
« meme si SuSE n'est pas libre »
Premièrement, il est implicite qu'on parle de la distribution GNU/Linux fournie par SuSE (on n'a dans ce cas même plus à signaler que les versions GPL le sont, puisqu'il n'en existe malheureusement plus...). Comme le nom l'indique, il s'agit d'une distribution basée sur le noyau Linux, libre, et sur les outils GNU, libres eux aussi. Les packs contiennent effectivement des softs non libres, mais la plupart des packs fournis par les autres distribs en contiennent aussi, excepté, bien entendu, Debian. (puisque non-free ne fait _pas_ partie de Debian).
Il me semble que le reproche qu'on peut faire à SuSE est différent, et je pense que cela est à l'origine de cette expression "SuSE n'est pas libre" : les logiciels développés (exclusivement) par SuSE sont pour la plupart (peut-être un fait il exception, je n'en sais rien) propriétaires, bien que SuSE participe à de nombreux projets libres (XFree86, KDE, noyau IIRC, etc.). Cela me semble être un grief important, cependant à chacun de juger si cela lui importe. Il n'y a pas une distribution meilleure que les autres AMHA, il y'a un ensemble de distributions différentes qui ont chacune des qualités et des défauts. A chacun en fonction de ses goûts, de ses attentes et de l'utilisation qu'il en fera de choisir SA distribution, ou de la faire s'il est du type jamais content :-) (</violons).
Vala, j'avais dit que c'était tout et je ne m'arrête plus.
--
mmenal, qui ferme de suite son Moz
[^] # Re: Vive la pub sur linuxfr.org
Posté par Manuel Menal . En réponse à la dépêche SuSE annonce la disponibilité de SuSE 7.2 pour Itanium (Version commerciale). Évalué à 1.
Enfin, je m'interroge sur la nature *réelle* du comment :
est-ce un fake, ce que le nombre d'ineptie et le dernier paragraphe
me fait penser, ou est-ce que l'auteur est vraiment aussi con qu'il y paraît ?
Internet en général et LinuxFr en particulier est assez sujet à ce genre d'interrogations :
on y rencontre tellement de sites, CV, qui ne sont pas des fakes
et qui pourtant pourraient très bien en être, qu'on finit par se méfier de tout.
Et puis, l'ironie passe très mal par écrit.
De toutes façons, le premier commentaire, s'il se voulait à caractère publicitaire, aurait plutôt l'effet contraire :-)
[^] # Re: Vive la pub sur linuxfr.org
Posté par Manuel Menal . En réponse à la dépêche SuSE annonce la disponibilité de SuSE 7.2 pour Itanium (Version commerciale). Évalué à 1.
Je ne vois pas en quoi cette nouvelle aurait un caractère publicitaire. A moins qu'on considère que, comme à la télévision, le fait de mentionner un produit commercial serait de la publicité. Si l'on reprend la news depuis le début : que voit-on :
1) SuSE est la première à sortir une distribution de GNU/Linux finalisée sur la plate-forme Itanium, c'est vrai, et ça mérite d'être mentionné.(ça a plus d'intérêt si c'est le premier). Informatif.
2) Le reste est au présent simple, car description de faits réels, donc informatif aussi.
Cette news me semble purement informative. Encore une fois, si donner une information concernant un produit commercial est de la pub, alors LinuxFr sera grandement incomplet, puisqu'il ne parlera pas de ce qui se fait dans le monde Linux dans sa globalité.
Voilà, tout ce que j'avais à dire pour aujourd'hui.
--
Manuel Menal, via son Mozilla qui déconne