Et Richard Stallman de rajouter dans une interview à PCWorld : "We actually have the GNU kernel working, and we can now produce the GNU system, as opposed to the GNU/Linux system that people have been using so far". (TdM: "Le kernel GNU fonctionne, et nous sommes maintenant en mesure de produire le système GNU, par opposition au système GNU/Linux que les gens utilisaient jusqu'à maintenant".)
La mort annoncée de GNU/Linux ?
Note du modérateur : j'ajoute les liens vers l'interview en question et vers Hurdfr.org. La news originale contenait un lien vers OSNews qui semble cassé, je le remplace par un lien vers Slashdot.
Aller plus loin
- La news sur Slashdot (21 clics)
- L'interview de RMS (2 clics)
- HurdFR (6 clics)
# Retour vers le futur
Posté par furai (site web personnel) . Évalué à 10.
Linux because it is designed using a microkernel instead of a
monolithic architecture, Stallman said.
C'est marrant, j'ai deja entendu ca :)
[^] # Re: linux is obsolete
Posté par jm . Évalué à 4.
http://alge.anart.no/linux/history/linux_is_obsolete.txt(...)
[^] # Re: Retour vers le futur
Posté par Vanhu . Évalué à 10.
Sans vouloir relancer le tro^H^H débat, le noyau Linux se fait quand meme de plus en plus volumineux...
[^] # Re: Retour vers le futur
Posté par matiasf . Évalué à -10.
prend une distribution qui utilise un 1.2.x si c'est un critere important et que t'as pas 50 Euro pour 256 Mo.
Ca me souale ces gnagna gnagni... Ces gus jamais content alors qu'ils ont pour gratos le top (ou presque).
[^] # Re: Retour vers le futur
Posté par Benoit Rousseau . Évalué à -2.
Y a pas que les 'PC' qui font tourner Linux... Et puis on ne parle pas des applications autour de Linux qui sont lourdes : on parle du noyau...
[^] # Re: Retour vers le futur
Posté par bad sheep (site web personnel) . Évalué à 10.
[^] # Re: Retour vers le futur
Posté par Vanhu . Évalué à 0.
Note que j'aime bien emacs, et que ca serait pas mieux avec vi, mais la conception des µnoyaux découpe plus, et ne met normalement en mode noyau que le strict nécessaire, et ca, c'est a priori une bonne idée (d'un point de vue propreté / stabilité, pas forcément performances).
[^] # Retour vers le futur IV
Posté par Rafael Pinilla . Évalué à 8.
Il y a 10 ans, c'était l'arlésienne, la vaporware hypothétique de demain loin-là-bas...
On l'appellait pas encore "LE" hurd, mais simplement HURD. gcc, emacs, c'était pour les affranchis. Désormais, tout le monde les utilise, alors le monde est mûr pour HURD.
Le simple fait qu'il parvienne à éclore, c'est déjà la réalisation d'un rêve.
HURD et Linux ne sont pas ennemis mais frères, un peu différents, comme tous les frères qui ne sont pas jumeaux. HURD est plus vieux, encore immature, et Linux est le petit frère précoce qui n'en veut.
Celui qui prétend le contraire n'a quà répondre à la question suivante: Avec quoi fut compilé Linux le premier jour ? GCC.
Qu'est-ce que gcc ? La première fondation du GNU HURD.
Demain ne peut être que meilleur, car HURD est sur le point de naître. La liberté gagne la terre et vaincra
[^] # Re: Retour vers le futur
Posté par Cyril Chevrot . Évalué à 1.
[^] # Re: Retour vers le futur
Posté par Gaël Le Mignot . Évalué à 4.
Sauf que Linus a parfois des goûts très bizarres: un serveur Web dans le noyau, un changement de VM en plein milieu d'une branche stable, refus d'intégrer des patchs pour le PCI 64-bits ou les nouvelles normes ATA, intégration de ReiserFS dans le 2.4.1 qui devait ne contenir que des bugs fixes, ...
Je respecte beaucoup Linus et je trouve que globalement il fait du très bon boulot, mais il commet aussi parfois de grosses erreurs AMHA, et son obstination à dénigrer les micro-noyaux et le Hurd frise parfois le ridicule (par exemple sur le coup du MAP_COPY où il reproche à l'équipe du Hurd quelque chose qui est lié à GNU Mach et non au Hurd)
[^] # Re: Retour vers le futur
Posté par Vanhu . Évalué à 1.
[^] # Re: Retour vers le futur
Posté par Timbert Benoît . Évalué à -5.
Puissant => bouffe plus le CPU => plus lent ;)
[^] # Re: Retour vers le futur
Posté par Gaël Le Mignot . Évalué à 10.
[^] # Re: Retour vers le futur
Posté par Timbert Benoît . Évalué à 6.
Par contre sur une machine bien parallèlle, peut être que la tendance s'inverse.
Mais comme aujourd'hui la plupart des systèmes que l'on rencontre sont des PC ...
[^] # Re: Retour vers le futur
Posté par Gaël Le Mignot . Évalué à 10.
Actuellement le Hurd est plutôt lent car non optimisé (par contre les développeurs savent comment faire pour l'optimiser, ce n'est pas la priorité c'est tout) et qu'il utilise GNU Mach, qui n'est pas non plus un modèle de vélocité.
Mais à terme, lorsque le Hurd sera sur L4, la différence de vitesse entre GNU et GNU/Linux devrait être négligeable, surtout comparé à tout ce que GNU apporte (et à la puissance des machines qui s'accroit sans cesse, le CPU étant rarement le facteur limitant d'une machine)
[^] # Re: Retour vers le futur
Posté par Code34 (site web personnel) . Évalué à -1.
est ce que le modulaire et le monolythique sont aussi rapide ?
@++
Code34
[^] # Re: Retour vers le futur
Posté par Gaël Le Mignot . Évalué à 10.
D'un point de vue performances, il y a un très léger surcoût à utiliser des modules, de l'ordre de quelques cycles CPU par appel système se trouvant dans un module (la valeur exacte se trouve dans "Le noyau Linux" de chez O'Reilly, je pourrais regarder chez moi), mais concrètement c'est totalement négligeable (sachant qu'un kernel trap a déjà un coût moyen estimé d'environ 170 cycles, sans compter le traitement de l'appel système, les quelques cycles de plus ne sont vraiment pas importants).
[^] # Re: Retour vers le futur
Posté par Romuald Delavergne . Évalué à 1.
Donc si t'as pas besoin, tu prends pas.
Je pense que la taille du noyau n'est pas un critère puisque ce qui ne sera pas dans le noyau pour HURD, le sera dans un module en mode user.
[^] # Re: Retour vers le futur
Posté par Gaël Le Mignot . Évalué à 10.
Un programme sans bugs ça n'existe pas. Un plus un programme est gros, plus il a de risques d'être buggué (à toutes autres choses égales). Donc plus tu as de code qui s'exécute en mode noyau, plus tu as de bugs potentiels en mode noyau. Or, un bug d'un programme s'exécutant en mode noyau peut avoir des conséquences gravissimes, allant du plantage au trou de sécurité, en passant par la corruption de données, voir des dégâts sur le matériel dans des cas extrêmes.
Dans le cas du Hurd où on a une collection (un troupeau ;) ) de serveurs indépendants qui tournent en mode utilisateur, un bug dans l'un de ces serveurs a des conséquences beaucoup plus réduites sur le système en général. Sans compter que pour débugguer un module noyau c'est beaucoup plus compliqué qu'un serveur du Hurd, qui lui se débugue comme un programme normal avec gdb, la libefence et autres.
Mettre un "module" en mode noyau, c'est jouer avec le feu, c'est lier le sort du système entier au sort du programme, et c'est donc à éviter autant que possible.
[^] # Re: Retour vers le futur
Posté par Jul (site web personnel) . Évalué à -5.
Par exemple, faire un petit tableur en assembleur modulaire aura surement plus de bug qu'un intégré à la xxxxx office. Et la complexité vient avant tout de la conception.
Le débat est vieux d'au moins 10 ans:
http://www2.educ.umu.se/~bjorn/mhonarc-files/obsolete/msg00000.html(...)
Je ne dirais qu'une chose à propos de Linux :
et pourtant il tourne.
De toute façon, GNU n'est pas un logiciel, c'est au mieux une secte
[^] # Trop gros, passera
Posté par Gaël Le Mignot . Évalué à 2.
................_---________---__________.............................
...............|..........PLEASE.........}............................
...............|.........................}............................
............../....DO.NOT.FEED.THE.TROLL.\............................
..............\____....................__/............................
...................-------------------`...............................
...........................|#:|.......................................
...........................|#:|.......................................
...........................|#:|.......................................
........................\\\|#:|/./....................................
............~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~.......................
-1
[^] # la guerre des kernels
Posté par destroy . Évalué à 8.
Je vois cependant un avantage MAJEUR aux microkernels : rappelez des OS du style BE, dans le repertoire utilisateur, on peut charger ses modules, qui fonctionnement en mode utilisateur, j'avais adoré ca. si le module deconne, on efface.
C'est idéal pour tester une config pour eventuellement la valider et généraliser le module qu'on aura préalablement testé en faisant un simple copier-coller en root. Les utilisateurs pourront choisir les modules de leur choix et chaque utilisateur pourra avoir son hurd perso.
C'est quand même assez génial à mon avis.
Je vois un inconvénient, cependant. Si les modules utilisateurs sont trop nombreux, ils peuvent peut-être vite encombrer la ram, non ?
Si quelqu'un est plus éclairé que moi sur le sujet, j'aimerais bien qu'il m'explique.
Je pense donc que les microkernels c'est assez génial, je ne sais pas quels seront les inconvenients.... il n'y a rien a voir entre un petit BeOS et un gros serveur linux...
[^] # Re: la guerre des kernels
Posté par Gaël Le Mignot . Évalué à 6.
Si on ne fait pas attention, si, l'échange de messages entre les différents serveurs peut venir devenir très très couteux. Mais en prenant quelques précautions, en implémentant l'IPC de manière performante, ... on arrive à réduire grandement les pertes.
Si les modules utilisateurs sont trop nombreux, ils peuvent peut-être vite encombrer la ram, non ?
En théorie oui, sans doute, mais les serveurs sont des programmes normaux qui peuvent être swappés s'ils ne sont pas utilisés par exemple, et puis comparé aux couches types Gnome-VFS ou kioslave qui sont nécessaires sous Linux pour avoir des fonctionnalités équivalentes, ça me semble quand même beaucoup plus léger.
[^] # Re: Retour vers le futur
Posté par Sixtiz (site web personnel) . Évalué à 5.
Je suis d'accord mais si l'on veut comparer Linux et le Hurd, je suppose qu'il faut comparer la quantité totale de code, et si les deux sysèmes doivent remplir les memes fonction, ils doivent representer plus ou moins la meme quantite de code donc de bugs...
Alors il est vrai qu'un bug dans un des serveurs du Hurd ne compromet que ce serveur, pas le système entier, alors que pour le noyau Linux, c'est tout le systeme qui se vautre. Certes. Mais AMHA le probleme est peu different : dans tous les cas il faut corriger le bug ou le service en question ne marchera pas. Alors redemarrer juste le service au lieu du systeme entier, c'est pas la solution miracle. Et puis en ce qui me concerne, j'ai rencontré beaucoup plus de bugs dans les programmes user space (donc que l'on peut redemarrer simplement sans rebooter) sous Linux que de bugs liés au noyau lui-meme et aboutissant a un reboot violent, donc l'architecture actuelle de Linux et le fait qu'il tourne en mode noyau ne me parait pas etre un problème si sérieux, et le fait que le Hurd utilise des serveurs et pas le mode noyau ne me parait pas non plus etre l'arme supreme... Enfin bon je demande à tester :o)
[^] # RMS est mort, vive Linus
Posté par Cyril Chevrot . Évalué à -7.
Hurd = 10 ans de développement et toujours pas pret
Linux = Pret en moins d'1 an, fonctionnel en une poignée d'années
Le but d'un micro-noyau c'est surtout pour les développeurs, possibilité de développer des modules en mode utilisateur, possibilité d'avoir des systèmes de fichier en tournant en mode utilisateur, ...
Le problème c'est que si le passage de messages et la communication entre les processus rend le développement tellement compliqué qu'il multiplie le temps de développement par 10 je vois pas trop l'intéret pour les développeurs d'utiliser un m icro-noyau.
De plus rajouter des interfaces et des couches d'abstraction c'est peut-etre beau sur le papier, mais à chaque fois ca entraine des chutes de performance terribles. Certes il y aura toujours des articles pour dire que la perte de performance n'est pas si terrible que ca, mais il y a toujours des articles pour dire n'importe quoi. Il suffit de se baser sur certaines mesures précises pour prouver ce qu'on veut prouver. Personnellement Java => ajout d'un couche d'abstraction (vm) => super long. De meme le fait que X est un processus dans l'espace utilisateur est certe une très bonne chose niveau conception (et je pense que pour le coup on a eu raison) cependant, je trouve qu'un des seules avantages de windows sur Linux est justement d'etre plus rapide au niveau de l'affichage (car le système de fenêtrage et justement dans le noyau). Et pour les micros noyaux, c'est encore le meme probleme, belle conception en apparence => chute de performance. Les belles idées sur le papier on a vu ce que ca a donné avec le communiste et apparemment on peut généraliser à pas mal de domaine la leçon. Le seul micro noyau que j'ai utilisé pour l'instant est minix (qui est nettement plus long que linux), mais j'ai des copains qui ont utilisés Hurd et Mac OS X et il m'ont dit que les performances étaient moins bonne que sur les OS monolithiques.
De plus j'ai lu qq part que de toutes facon on n'avait de plus en plus de ressources processeurs et donc que les performances n'étaient pas si primordiales que ca. Cet argument est l'argument (récurrent) e plus débile de l'histroire de l'informatique. On aura _jamais_ trop de ressource et donc on se doit de concevoir les systèmes le plus efficacement possible.
Quand à la modularité, avec Linux on a la modularité au niveau du source. De plus les modules ne constituent pas du rafistolage mais plutot le juste milieu.
D'ou ma conclusion :
Hurd ne remplacera _jamais_ Linux car si Hurd devait triompher Hurd aurait _déjà_triompher. N'en déplaise à Stallman et à son égo surmesurer.
[^] # Re: RMS est mort, vive Linus
Posté par Gaël Le Mignot . Évalué à 8.
Ca c'est de l'argumentation ! Chapeau !
Hurd = 10 ans de développement et toujours pas pret
Le développement Hurd a été (presque) complètement stoppé pendant des années, c'est 1999 que Marcus l'a relancé.
Le problème c'est que si le passage de messages et la communication entre les processus rend le développement tellement compliqué qu'il multiplie le temps de développement par 10 je vois pas trop l'intéret pour les développeurs d'utiliser un micro-noyau.
Le passage de messages ne complique pas vraiment le développement, mais par contre le fait d'avoir des programmes en user-space normaux que l'on débugguer avec gdb, qui n'obligent pas à redémarrer la machine lors d'un segfault, ... augmente nettement la facilité de développement.
mais à chaque fois ca entraine des chutes de performance terribles.
Tu as lu les autres commentaires sur cette page ? Tu es allé voir les articles sur L4Linux, L4KA et les techniques d'optimisation de l'IPC ? Alors renseigne-toi avant de parler et de sortir des arguments bidons que tu as lu l'aveille sur /. Et crois-moi, je ne dis pas ça pour être méchant, vu que ce genre d'arguments je les sortais il y a quelques mois avant que je ne me renseigne vraiment sur la question (j'ai un peu honte de moi maintenant mais bon... errare humanum est)
mais j'ai des copains qui ont utilisés Hurd et Mac OS X et il m'ont dit que les performances étaient moins bonne que sur les OS monolithiques.
Encore une fois, lis ce qui a été dit ici. Le Hurd n'est pas optimisé pour l'instant. Les développeurs savent où sont les principales lacunes, savent comment y remédier, mais ce n'est pas la priorité. Pour Mac OS X c'est plus la couche Quark/Aqua qui rame que Darwin.
Quand à la modularité, avec Linux on a la modularité au niveau du source. De plus les modules ne constituent pas du rafistolage mais plutot le juste milieu.
Tu as lu tout ce que Manuel Menal et moi (entre autres) avons dit sur les possibilités du Hurd ? Comment tu fais le translator FTP + Hostmux sous Linux ? Ou le générateur de fortune ? Ou le serveur Apache qui n'a jamais besoin des droits root pou binder le port 80 ? Ou le serveur FTP non anonyme qui n'est pas suidé root ? Et le fait qu'un bug dans un module fasse cracher la totalité du système ? Alors relis tout ce qu'on a dit sur cette page avant de sortir des phrases toutes faites comme ça.
Hurd ne remplacera _jamais_ Linux car si Hurd devait triompher Hurd aurait _déjà_triompher. N'en déplaise à Stallman et à son égo surmesurer.
Le but du Hurd n'est pas de remplacer Linux, mais de proposer une alternative mieux conçue et plus puissante. Quand à la personnalité de RMS, déjà je ne suis pas du tout d'accord avec ton jugement sur lui, et en plus je ne vois pas ce qu'il a à voir que le Hurd.
[^] # Re: RMS est mort, vive Linus
Posté par Cyril Chevrot . Évalué à -1.
>>Les micros noyau, ca pue
>Ca c'est de l'argumentation ! Chapeau !
L'argumentation vient après. On t'a pas appris quand tu étais petit qu'il fallait commencer les paragraphes avec l'idée principale est l'argumenter après.
Le développement Hurd a été (presque)
complètement stoppé pendant des a
nnées, c'est 1999 que Marcus l'a relancé.
Justement ca montre bien que les micros noyaux rendent la conception plus difficile. Je ne pense pas que les développeurs HURD soient des brels, alors s'ils se sont découragés c'est bien que ca devait etre difficile.
Et crois-moi, je ne dis pas ça pour être méchant, vu que ce genre d'arguments je les sortais il y a quelques mois avant que je ne me renseigne vraiment sur la question (j'ai un peu honte de moi maintenant mais bon... errare humanum est)
Et oh, faut pas etre gentil comme ca, une réputation de trolleur ca ce travail ;)
Le Hurd n'est pas optimisé pour l'instant. Les développeurs savent où sont les principales lacunes, savent comment y remédier, mais ce n'est pas la priorité
La performance n'est pas une priorité, je crois réver. La performance devrait toujours etre une priorité.
Tu as lu tout ce que Manuel Menal et moi (entre autres) avons dit sur les possibilités du Hurd ? Comment tu fais le translator FTP + Hostmux sous Linux ? Ou le générateur de fortune ? Ou le serveur Apache qui n'a jamais besoin des droits root pou binder le port 80 ? Ou le serveur FTP non anonyme qui n'est pas suidé root ? Et le fait qu'un bug dans un module fasse cracher la totalité du système ? Alors relis tout ce qu'on a dit sur cette page avant de sortir des phrases toutes faites comme ça.
Ces fonctionnalités sont interessantes au niveau de la sécurité et du développement, mais bon je préfère un système ou l'on prend plus de risque et on l'on favorise avant tout les performances. De la même facon je préfère coder en C qu'en Java. Certes en java il y a un demi milliards de mécanismes pour prendre des précautions qui n'existe pas en C. Un code C a ainsi beaucoup plus de chance de planter à l'exécution qu'un code Java. Mais il est aussi beaucoup plus rapide (Je sais je n'aurais pas du prendre l'exemple de Java car la lenteur est principalement du à la vm, mais j'ai assez peu d'expérience avec le C++). Et les tests ca existent. La communauté Linux jouent sur la rapidité de développement et le feed back rapide des problèmes pour avoir un système sur et sécurisé. Je préfère cette approche que l'approche : on prend énormément de précaution et on optient une chute de performances.
Quand à la personnalité de RMS, déjà je ne suis pas du tout d'accord avec ton jugement sur lui, et en plus je ne vois pas ce qu'il a à voir que le Hurd.
Tu ne vois pas ce qu'il a avoir avec le Hurd !!!????!!?!. Le système GNU ca te dit qqchose ? Le Hurd est le noyau officiel du système, pas Linux. Et Stallman est bien verreux que Linux (ou Linus si tu préfère) lui ait piqué la chandelle : les messieurs tout le monde dans la rue connaissent moins stallman que Linus.
[^] # Re: RMS est mort, vive Linus
Posté par Gaël Le Mignot . Évalué à 2.
Non, c'est parce qu'il y avait déjà Linux et que la priorité n'était donc plus au niveau du "noyau".
La performance n'est pas une priorité, je crois réver.
Et ben non, quand tu développes un programme tu commences par le faire robuste et fiable, et après tu optimises. L'optimisation de l'implémentation n'est pas une priorité dans le début du développement d'un programme.
mais bon je préfère un système ou l'on prend plus de risque et on l'on favorise avant tout les performances.
T'es bouché ou tu le fais exprès ? La perte de performance peut être dimunée au point d'être négligeable ! Pendant que tu y es aussi on fait tourner en mode noyau sans protection mémoire ni rien pour économiser un peu de perf ? Et compare des choses qui sont comparables STP, un micro-noyau c'est beaucoup moins lourd et coûteux qu'une JVM et ça apporte beaucoup plus AMHA.
Tu ne vois pas ce qu'il a avoir avec le Hurd !!!??
Ce n'est pas RMS qui contrôlle le Hurd, qui prend les décisions de design ou autres. Il ne participe même au code IIRC. Quand a ton mépris pour RMS, ça ne concerne que toi et je ne partage pas du tout ton avis. Si tu n'as pas compris que les différents entre RMS et Linus sont plus idéologiques qu'autre chose (RMS défendant le logiciel libre pour des raisons éthiques, Linus ne s'intéressant qu'au côté technique), et bien c'est dommage.
[^] # Re: RMS est mort, vive Linus
Posté par Cyril Chevrot . Évalué à 1.
un micro-noyau c'est beaucoup moins lourd et coûteux qu'une JVM et ça apporte beaucoup plus AMHA.
C'est vrai. Mais le problème de base reste le meme : en ajoutant des couches logiciels on s'éloigne du hard et on perd en performance.
Si tu n'as pas compris que les différents entre RMS et Linus sont plus idéologiques qu'autre chose (RMS défendant le logiciel libre pour des raisons éthiques, Linus ne s'intéressant qu'au côté technique), et bien c'est dommage.
Bien sur que je connais les différents idéologique entre le mouvement Open Source et la FSF. Bien sur que je sais que les 9 clauses de l'OSD sont plus pragmatique qu'idéologique.
Maintenant les différents sont aussi technique. Linus n'aime pas emacs et Hurd. RMS aime les unoyaux, Linus ne les aime pas. Tu ne vas pas me dire qu'il ne s'agit pas de différent technique. D'une facon générale les différents entre les 2 sont avant tout basé sur une vision différente du monde : d'un coté il y a un pragmatique qui tire ces idées de l'expérience, de l'analyse du réel et de l'autre il y a un théoricien qui préfère les belles idées. Moi je me reconnais parfaitement dans la première vision du monde et pas du tout dans la deuxième. C'est mon droit maintenant tu es libres de penser différemment.
[^] # Re: RMS est mort, vive Linus
Posté par Gaël Le Mignot . Évalué à 2.
Mais on ajoute pas de couches logicielles... tu n'as pas compris ce qu'était un µ-noyau justement.
Linus n'aime pas emacs et Hurd. RMS aime les unoyaux, Linus ne les aime pas.
Emacs c'est un micro-noyau ? Et la marmotte ? Le rapport entre Emacs et le Hurd STP (à part que ce sont des projets GNU ?)
Et encore une fois je te répète que RMS n'a pas grand chose à voir avec le Hurd et qu'il ne contrôle pas du tout l'évolution du projet.
[^] # Re: RMS est mort, vive Linus
Posté par woof . Évalué à 0.
<donotfeedthetroll figlet="yes">
[^] # Re: RMS est mort, vive Linus
Posté par Pascal Havé . Évalué à 1.
Je vois personnellement Hurd, non pas prenant aujourd'hui la place de Linux , mais comme une expérience afin de créer un nouvel OS libre pour demain.
Sa structure micro-noyau, le freine aujourd'hui, mais tout évolue; avec la rapide évolution de la technologie (matériel et logiciel), peut on être sûr que Hurd ne peut avoir une place demain (sécurité, parallélisme, ...)
Toute expérience prend du temps (surtout quand on change d'avis en cours de route ;), commence par des essais (souvent non optimisés) et apporte des réponses différentes (j'adore la gestion des droits et le VFS sous Hurd).
Le premier système Unix fut écrit en assembleur puis réécrit en C, pour le rendre plus facile à dévolopper; le premier java était très lent, mais on est passé à l'air du JustInTime.
Oui, Linux est actuellement très défendu car c'est un peu grâce à lui que nous sommes ici, mais je pense que chacun peut avoir sa place, chacun peut surement quelque chose à l'autre.
[^] # Re: RMS est mort, vive Linus
Posté par rgardon . Évalué à 2.
bon j'ai coupe mais ca ne change rien. L'interet est aussi grand pour les utilisateurs : avec un micro noyau, on met ce qu'on veut autour, mais vraiment ce que l'on veut --> on peut a peu pres tout faire, et ce sur des configs tres modestes si on ne fait presque rien tourner autour du noyau.
>mais il y a toujours des articles pour dire >n'importe quoi
l'argument peut etre retourne : il y aura tjs des articles pour dire que ca ralentit tout mais...
>Les belles idées sur le papier on a vu ce que ca >a donné avec le communiste
bon la avis perso, vous auriez pu trouver une autre comparaison :)
>Il suffit de se baser sur certaines mesures >précises pour prouver ce qu'on veut prouver.
et plus loin
>mais j'ai des copains qui ont utilisés Hurd et >Mac OS X et il m'ont dit que...
J'ai appris a mes depends que se baser sur "ce que disent les copains" est *tres* mauvais. N'y voyez aucune agressivite de ma part, mais je ne pense pas que cet argument soit recevable.
>Hurd ne remplacera _jamais_ Linux car si Hurd >devait triompher Hurd aurait _déjà_triompher
Linux a mis plus de qqes annees a s'imposer en tant qu'alternative viable a tout le reste (enfin aux OS proprios), je ne pense donc pas que le Hurd puisse etre le sujet de telles pensees. Et surtout il ne me semble pas qu'il soit question que Hurd remplace Linux.
[^] # Re: RMS est mort, vive Linus
Posté par Cyril Chevrot . Évalué à 2.
>mais j'ai des copains qui ont utilisés Hurd et >Mac OS X et il m'ont dit que...
J'ai appris a mes depends que se baser sur "ce que disent les copains" est *tres* mauvais. N'y voyez aucune agressivite de ma part, mais je ne pense pas que cet argument soit recevable.
Je suis tout à fait d'accord. Personnellement tous mes jugements repose principalement sur _mon_ expérience. Je considère que l'expérience est au dessus de tout article, avis d'expert, avis de copain. Maintenant mieux vaut avoir l'information d'un copain que pas d'information du tout.
Et surtout il ne me semble pas qu'il soit question que Hurd remplace Linux.
Je n'ai rien contre le Hurd, ce qui m'énerve c'est le quasi mépris de Stallman envers Linux. Et le mépris de Linus envers le Hurd me direz vous ? Je vous l'accorde ca doit etre un truc de chef d'etre braqué. D'un autre coté faut bien qu'ils prennent des décisions. Et as nous de choisir notre camp.
[^] # Re: RMS est mort, vive Linus
Posté par Étienne . Évalué à 3.
Oui mais tant qu'on ne s'est pas fait son propre avis, ce n'est pas la peine de partager l'opinion de ses copains, sinon avec des avis de copains de copains ca peut aller loin.
D'un autre coté faut bien qu'ils prennent des décisions. Et as nous de choisir notre camp.
Il n'est pas question de choisir un camp, la communauté n'est pas en guerre. On a encore le droit de faire du multiboot Linux/Hurd/Bsd/Atheos et tout ce qu'on veut.
[^] # Re: RMS est mort, vive Linus
Posté par Manuel Menal . É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: RMS est mort, vive Linus
Posté par Cyril Chevrot . Évalué à 0.
Mon Dieu.. On en tient un beau
Merci
J'ai déjà répondu à ça, exactement le même titre
Ce n'était exactement le même titre, les micro-noyaux, ca pue, c'est plus percutant que les micro-noyaux, c'est nul.
qui n'a pas besoin d'être rebootée de façon régulière pour mise à jour du noyau
Je ne sais pas si tu es au courant mais Linux est de plus en plus utilisé par des personnes qui ne savent même pas ce qu'est un noyau. Avancé cet argument pour démontrer que le HURD n'est pas seulement destiné aux développeurs c'est vraiment nul.
De quelle couche d'abstraction parles-tu ? De quelle interface ? J'avoue ne pas comprendre à quoi tu fais référence.
Avec un noyau monolithique, un appel système va directement tapé dans le noyau.
Avec un micro-noyau, les appels systèmes sont implémentés au niveau des serveurs (1ère interface), les serveurs font appels aux services fournis par les taches d'entrées sorties (2 ème interface) et enfin les taches d'entrées sorties font appels au micro-noyau qui s'occupe de gérer les ressources et de passer les messages (3ème interface). Voila ce que j'appelle ajout de niveaux d'abstraction. (Enfin c'est ce qui se passe sous minix, je connais très mal HURD)
Cependant, Mach n'est pas un modèle de vélocité, et faire un système performant basé sur ce micro-noyau n'est pas évident.
Alors pourquoi l'utiliser s'il y a moyen de faire mieux ?
<i>
> Certes il y aura toujours des articles pour
> dire que la perte de performance n'est pas si
> terrible que ca, mais il y a toujours des
> articles pour dire n'importe quoi.
Argument frappant, je dois le dire.
<i>
Je confirme, et j'en suis fier ;)
> Il suffit de se baser sur certaines mesures
> précises pour prouver ce qu'on veut prouver.
Soit plus précis. Que proposerais-tu de tester que les réalisateurs du benchmark n'ont pas testés ?
Moi ce que je souhaiterais pour changer mon avis sur les micro-noyaux c'est que Hurd soit aussi rapide (au niveau de l'utilisation j'entends) que Linux et que ce soit une _priorité_.
Pourquoi viens-tu parler du Hurd, alors ? Tu n'es pas devin, ni moi.
Pipo Argument
Prédiction de l'avenir => Test sur la compréhension du présent. Il est toujours bon d'essayer de prévenir l'avenir. Les personnes qui prédisent très mal l'avenir sont des personnes qui ont une mauvaise compréhension du présent et inversement. Ainsi pour savoir si l'on a une bonne compréhension du présent, il est bon de faire des prédictions, de les retenir et de voir quand le futur devient présent si l'on avait raison ou non. Et si l'on avait tort ils est bon de se poser des questions
> N'en déplaise à Stallman et à son égo surmesurer.
Encore un non-argument, trollesque, sans _aucun_ intérêt
Si les trolls n'ont aucun intérêt, que fais-tu sur linuxfr ! Les trolls sont primordiales car ils permettent de se défouler ! Et se défouler c'est important, sinon comment expliquer le succès des doom-like, quake-like, des films violents et ... de linux (qui permet de se défouler sur microsoft)
nous sommes pas là pour juger des personnes, que tu ne connais pas personellement
Tu es le roi des arguments à la con à ce que je vois. Je ne connais pas personnellement les hommes politiques et cela ne m'empeche pas de les juger et ne m'empechera pas d'aller voter pour l'un d'eux aux prochaines élections. C'est meme mon devoir de citoyen.
[^] # Re: RMS est mort, vive Linus
Posté par - - . Évalué à -1.
vous ne répondez pas aux arguments techniques sur les possibilités de HURD que linux ne peut _pas_ reproduire.
vous melangez tout
vous ne repondez pas sur le fait que HURD permettrait de se passer de gnome-vfs ou les kioslave (et faire la même chose en plus rapide)
vous dites :
" Si les trolls n'ont aucun intérêt, que fais-tu sur linuxfr ! Les trolls sont primordiales car ils permettent de se défouler ! Et se défouler c'est important, sinon comment expliquer le succès des doom-like, quake-like, des films violents et ... de linux (qui permet de se défouler sur microsoft)"
je pense plutot que c'est vous qui avez rien à faire sur linuxfr. les trolls sont une pertes de temps. vous répondez, ecrivez a coté du sujet, vous servez à rien.
on se fiche que vous vous defouliez, linuxfr est un site d'informations et une place publique pour discuter autour de linux et les logiciels libres (et hurd s y inscrit)
manifestement il y a des gens ici qui connaissent bien mieux que vous linux ou hurd.
# La mort annoncée de GNU/Linux ?
Posté par Anonyme . Évalué à 10.
Et AMA, quoique puisse en dire RMS, Linux est bien trop populaire et implanté (même si, relativement à une certaine situation monopolistique, c'est faible) pour que GNU remplace GNU/Linux.
Les éditeurs ont déjà du mal à se tourner vers Linux, je vois pas pourquoi ils se tourneraient plus vers le Hurd et son µnoyau (en plus, je suis persuadé que cette histoire de µnoyau va faire peur).
Et qu'on ne me réponde pas que les drivers de linux seront portés, ça veut bien dire ce que ça veut dire : GNU aura encore besoin de Linux...
Le problème du Hurd, AMA, c'est qu'il arrive un peu trop tard (d'ailleurs, il est pas encore arrivé), au moment même où les gens se tournent de plus en plus vers les LL en général et vers GNU/Linux en particulier...
Enfin, on verra bien...
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par Rin Jin (site web personnel) . Évalué à 10.
Quand on regarde ce qui permets de faire tourner les logiciels GNU, on trouve déjà plus d'un noyeau (Linux évidement, Hurd mais aussi les BSD et peut-être d'autre unix que je ne connais pas).
Ce que j'apprécie dans Gnu, c'est le choix, alors un nouveau noyeau utilisable en production est pour moi une bonne nouvelle.
Dans un premier temps, je n'imagine pas Hurd inquiéter réellement les autres noyeau libre mis en place pour les raisons que tu donnes mais par la suite, si celui ci s'avére meilleurs dans certains domaines, pourquoi ne pas l'y mettre?
On continuera d'avoir le choix et celui-ci se sera étoffé, tant mieux.
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par ufoot (site web personnel) . Évalué à 10.
Je pense que le but est pas de "remplacer" definitivement Linux.
Peut-etre que la FSF se mettra a utiliser le Hurd et seulement le Hurd, mais c'est leur probleme et c'est tout naturel vu que le Hurd est leur projet.
Maintenant, beaucoup continueront a utiliser Linux, certains utiliseront Hurd, d'autres FreeBSD, et d'une maniere generale chacun fera ce qu'il voudra.
Perso je trouve ca bien qu'il y ait plein d'OS comme le Hurd, Atheos, etc...
Honnetement, je pense qu'une plate-forme comme le Hurd sera delaissee par les "editeurs" de logiciels proprietaires. Maintenant, je pense sincerement que la FSF s'en fiche un peu qu'Oracle porte ses produits pour Hurd. A moins qu'Oracle sorte ses produits sous une license libre evidemment 8-)
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par Gaël Le Mignot . Évalué à 10.
Par contre, il faut faire attention à ce que l'on dit: le Hurd n'est pas un OS, ce n'est même pas vraiment un noyau, c'est un ensemble de serveurs pour micro-noyau pouvant être utilisés (en conjonction avec un µ-k) pour remplacer un noyau monolithique dans un système (ici le système GNU).
GNU/Linux et GNU ne sont donc pas deux système complétement différents comme le sont GNU/Linux et FreeBSD par exemple.
Pour les applications propriétaires, si la compatibilité binaire entre GNU/Hurd et GNU/Linux n'existe pas actuellement, elle ne pose aucun problème théorique et sera implémentée dés que quelqu'un jugera bon de le faire (et l'intéret premier de ça n'est pas de faire tourner des applis propriétaires AMHA, mais de faciliter les dual-boots GNU/Linux-GNU/Hurd).
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par ufoot (site web personnel) . Évalué à 10.
C'est clair que si on pouvait partager un meme /usr/bin entre un systeme GNU/Linux et un GNU/Hurd, ca serait plutot pas mal...
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
A priori, cela ne me semble pas du tout impossible, et je le crois souhaitable.
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par Étienne . Évalué à 3.
pour /etc ca peut etre envisageable a la limite mais il y a le probleme des scripts d'init qui ne seront pas les meme, et la crontab qui doit faire appel exclusivement a des programmes disponibles sur les 2 systemes. D'ailleurs je ne suis pas sur qu'on ait le droit de monter /etc sur une partition differente de /.
pour /var, il faut malgre tout faire attention, on ne peut pas partager par exemple les fichiers syslog sinon ca devient vite la pagaille. Pour le mail /var/mail c'est une bonne idee
/proc n'est pas une partition du disque dur, c'est un repertoire qui contient des informations sur le systeme mais qui est gere par le noyau sans etre ecrit nul part.
/home se partage certainement tres bien si on a le meme systeme de fichier et que l'on fait attention a avoir les memes UID pour les memes utilisateurs.
Etienne
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Déjà c'est chiant de partager des binaires entre deux glibc différentes.
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par Gaël Le Mignot . Évalué à 10.
Ce sera fait d'ici quelques mois avec le passage à OSKit Mach. Sinon, l'un des gros avantages des µ-noyau (et de Mach) c'est qu'il possible d'implémenter énormément de drivers uniquement en user space.
Linux est bien trop populaire et implanté pour que GNU remplace GNU/Linux.
Le passage de GNU/Linux est presque transparent (ou le sera lorsque les problèmes du Hurd seront corrigés), et une immense majorité d'applications ne demandent qu'un portage minimal. En particulier avec la Debian GNU/Hurd (http://www.debian.org/ports/hurd/index(...)).
Les éditeurs ont déjà du mal à se tourner vers Linux, je vois pas pourquoi ils se tourneraient plus vers le Hurd et son µnoyau
Pour des raisons de sécurité ? De fiabilité (lorsque tout marchera bien) ? Pour tous les avantages qu'il apporte(ra) ?
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par Robert Palmer (site web personnel) . Évalué à 10.
C'est un peu un piqure de rappel que fait RMS aux développeurs et utilsateurs de LL. Mais ça ne changera rien aux destinés de Linux et du Hurd. Si ce dernier veut percer, c'est avant tout avec ses qualités techniques qu'il devra le faire. Pas parce que RMS le veut.
Mais bon, moi je suis favorable à la diversité alors bonne chance aux deux.
Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par Anonyme . Évalué à 3.
Cela dit, RMS ne présente pas les choses sous cette forme (encore heureux).
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par reno . Évalué à 3.
> plus vers le Hurd et son µnoyau (en plus, je suis
>persuadé que cette histoire de µnoyau va faire peur)
Je ne vois pas pourquoi tu penses que le micronoyau leur ferait peur!
Les éditeurs logiciels se fichent éperdument de savoir si le système d'exploitation utilise un micro-noyeau, un exo-kernel ou un pico-kernel ce qui les interesse c'est de pouvoir vendre leurs produits en quantité suffisante pour faire du bénéfice, un point c'est tout!
Ce qui AMHA n'est pas pres d'arriver pour GNU déja que pour Linux c'est pas (encore) le cas (ça dépend des domaines, bien sur).
# rms l'utilise deja ...
Posté par tfing . Évalué à 10.
si je me souviens bien, il avait dit lors de son speech du samedi matin au fosdem que depuis qq jours il utilisait le hurd sur son portable
alors si meme rms l'utilise depuis peu seulement, le public vise par une release cette annee ne peut-etre que des 100%-geeks
a part ca, ca fait quand meme plaisir d'entendre qu'un nouveau systeme devient utilisable et ca ne peut qu'amener des developpeurs a s'y interesser
ca serait bien que des gens qui l'utilise deja postent des commentaires pour faire un peu de propagande (j'ai pas dit pour troller ...)
[^] # Re: rms l'utilise deja ...
Posté par Infernal Quack (site web personnel) . Évalué à -5.
Beurk :(=
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: rms l'utilise deja ...
Posté par Sylvain Rampacek (site web personnel) . Évalué à 1.
Par ce que j'en ai entendu dire que des "on dit"...
Et surtout, qu'apporte-t-il de plus que le noyau Linux que l'on connait bien ?
[^] # Re: rms l'utilise deja ...
Posté par Benoit Rousseau . Évalué à 9.
Une fois le noyau installe, c'est assez facile d'ajouter des programmes : Debian/Hurd oblige...
Par contre on a pas pousse jusqu'a l'installation d'un serveur graphique...
http://www.hurdfr.org/Docs/Hurd_fr/Guide(...) avait ete notre guide...
[^] # Re: rms l'utilise deja ...
Posté par Manuel Menal . É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..
[^] # Enfin !
Posté par Pierre Tramo . Évalué à 5.
Enfin, un post constructif, qui apporte des réponses claires à des questions que je me posais depuis un moment, à savoir ce que le Hurd avait de si intéressant. Maintenant , j'ai un petit aperçu, qui me donne envie de voir un peu plus loin, si j'en ai le temps (ça, c'est pas gagné).
Merci Manuel, je préfère un commentaire comme cela dans les news, plutôt qu'un troll de plusieurs jours sur la tribune. Je comprends que les hurdistes s'offusquent des propos qui s'y tiennent, mais la tribune libre n'est décidément pas un espace de discussions très sérieux, ou est en tout cas inadapté à ce genre de sujet.
Petit bémol quand même : http://www.hurdfr.org(...) laisse vraiment un goût d'inachevé dans la bouche.
Trouvant ridicules les batailles de tribus dans la communauté des logiciels libres, je souhaite longue vie au hurd ! Et à sa cohabitation avec le système GNU/Linux.
(Là, j'espère pas avoir dit trop de bêtises sur les termes utilisés, style Le Hurd, ou GNU/Linux. De toute façon, j'en connais deux qui rectifieront. ;) )
[^] # Et la programmation parallèle ?
Posté par ceituna (site web personnel) . Évalué à 2.
Tout ceci me donne envie des poser quelques questions...
Si j'ai bien compris, au niveau du noyau, l'interaction par messages est grandement augmentée pour améliorer la modularité du système...
Or, maintenant que les réseaux Gbits se développent de + en +, ceci permettra-t'il d'avoir une gestion de l'OS répartie entre diverses machine ?
Pour prendre un exemple tout con sera-til possible de passer un message au serveur de passwords situé dans la machine C si le serveur X tourne su la mcahine B ?
Ceci ouvrirait de splendides possibilitées dans le clustering, mais ouvrirait aussi des problèmes de sécurité non négligeables !
Alors ?
# Un petit regret
Posté par ufoot (site web personnel) . Évalué à -10.
Bon, hum, desole...
[^] # Re: Un petit regret
Posté par Eric Leblond (site web personnel) . Évalué à -3.
Juste pour dire que tu as oublié http://www.gnusfr.org(...)
[^] # Re: Un petit regret
Posté par Pierre Tramo . Évalué à 0.
http://www.emacsfr.org(...)
<troll mode>( Même si, vi ça le fait plus quand même)</troll>
hop ! 2 centimes et -1.
[^] # Re: Un petit regret
Posté par Pascal Terjan (site web personnel) . Évalué à 6.
# Troll des cavernes
Posté par Eric Leblond (site web personnel) . Évalué à 7.
"A Freer Cousin"
"Distributions of GNU/Linux include commercially licensed software, and that diverts the user and developer community from the goal of freedom, according to Stallman."
Je ne vois pas en quoi le système GNU va changer la donne, il sera toujours possible de faire des distributions avec GNU et d'y mettre des applis commerciales. En fait, on dirait que Stallman veut faire un HurdBSD qui serait le vrai OS libre, et pas l'imitation à la sauce finlandaise.
[^] # Re: Troll des cavernes
Posté par Gaël Le Mignot . Évalué à 1.
Peut-être est-ce une réaction à l'utilisation de BitKeeper par Linus et une partie des développeurs du noyau ?
-1 ça n'apporte pas grand chose
[^] # Re: Troll des cavernes
Posté par feth . Évalué à 0.
Ca veut aussi dire que n'importe quel soft à la windows a plus d'affinités avec l'hurd qu'avec linux... (à mon avis à moi)
[^] # Re: Troll des cavernes
Posté par Eric Leblond (site web personnel) . Évalué à 2.
Donc si RMS a tort ici ce n'est pas dans l'avis qu'il a sur Hurd mais sur l'avis qu'il a sur le reste.
[^] # Re: Troll des cavernes
Posté par Gaël Le Mignot . Évalué à 9.
Donc oui, n'importe qui peut lancer un serveur, mais ce serveur ne pourra faire que ce que l'utilisateur peut faire. Typiquement pour un translator lancé sur une image ISO, il faut que l'utilisateur puisse lire l'image ISO et possède le répertoire où l'image va être montée.
[^] # Re: Troll des cavernes
Posté par Gaël Le Mignot . Évalué à 10.
Déjà on dit le Hurd, pas l'hurd, merci. Ensuite, le Hurd ne permet à l'utilisateur de se passer du root et ne nuit pas du tout à la sécurité, au contraire. Il permet à l'utilisateur de faire des choses qui ne nuisent pas à l'intégrité du système mais qui sont impossibles à faire avec un noyau monolithique.
Par exemple, avec Linux, si tu veux faire du ftpfs (monter un répertoire FTP dans ton VFS), il faut passer root, charger le module ftpfs, et introduire donc un nouveau programme, potentiellement buggué, dans le noyau. Avec le Hurd, tu lances un translator FTP, qui tourne sous ton identité, qui a tes privilèges, comme une application normale.
<i>n'importe quel soft à la windows a plus d'affinités avec l'hurd qu'avec linux.</i<
Que veux-tu dire par là ??
[^] # Re: Troll des cavernes
Posté par Pierre Tramonson . Évalué à 1.
[^] # Re: Troll des cavernes
Posté par feth . Évalué à 2.
ben quoi t'as vu l'hurd qu'il est ?
Il permet à l'utilisateur de faire des choses qui ne nuisent pas à l'intégrité du système mais qui sont impossibles à faire avec un noyau monolithique.
jamais dit le contraire !
Justement, comme linux interdit aux utilisateurs de monter ne serait-ce qu'un cdrom ou faire ce qu'ils veulent avec leur FS, ou se faire un tunnel ssh à eux, il n'est pas l'ami des sharewares ou applis gadgets.
En revanche, un système comme l'hurd (il va me mettre un [-] vous allez voir !) permet des backdoors qui ne mettent pas en danger la securite du système, seulement des données de l'utilisateur.
Evidemment, de telles backdoors ne proviendront pas du LL. Mais en donnant à l'utilisateur la possibilité de s'installer n'importe quoi, on fait de ce système le paradis du logiciel commercial investigateur de type .NET.
[^] # Re: Troll des cavernes
Posté par Étienne . Évalué à 2.
Sous Linux c'est la même chose. Si quelqu'un lance un programme qui crée une backdoor sous ton compte, tes données sont en péril. De même si quelqu'un lance un serveur sur le Hurd avec ton identité, tes données son en péril. Les serveurs du Hurd sont simplement des programmes qui communiquent avec le micronoyau.
Etienne
[^] # Re: Troll des cavernes
Posté par feth . Évalué à 7.
On a juste beaucoup plus de possibilités avec la hurd qu'avec linux (et c'est pour cela que la hurd est mieux).
[^] # Re: Troll des cavernes
Posté par Gaël Le Mignot . Évalué à 4.
Il est possible sous Linux de laisser un utilisateur monter des cd-roms avec l'option "user" du fstab, mais ça nécessite un mount suider-root, ... c'est pas génial génial niveau sécurité tout ça.
il va me mettre un [-] vous allez voir !
Je mets très rarement des -, et là je ne t'en ai pas mis.
un système comme l'hurd permet des backdoors
Pas plus que sous Linux. Dans les deux cas si tu lances un logiciel propriétaire (ou que tu n'as pas vérifié) toutes les données auxquelles tu peux accéder sont potentiellement en danger. Le Hurd ne compromet pas la sécurité à ce niveau là.
[^] # Re: Troll des cavernes
Posté par Anonyme . Évalué à -1.
[^] # Re: Troll des cavernes
Posté par Gaël Le Mignot . Évalué à 2.
man smbmount:
NOTE: smbmount calls smbmnt(8) to do the actual mount. You must make sure that smbmnt is in the path so that it can be found.
(kilobug@drizzt, 12) ~/download $ ls -l `which smbmnt`
-rwsr-xr-x 1 root root 429192 mar 5 23:24 /usr/bin/smbmnt
Qu'est-ce que tu disais à propos du suidé-root ?
[^] # Re: Troll des cavernes
Posté par Anonyme . Évalué à 1.
[^] # Re: Troll des cavernes
Posté par Sylvain Rampacek (site web personnel) . Évalué à -1.
Sur ma mandrake, je peux faire ça sur tous les systèmes de fichiers que j'ai décrit dans /etc/fstab...
[^] # Re: Troll des cavernes
Posté par feth . Évalué à -3.
[^] # Re: Troll des cavernes
Posté par Pierre Tramo (site web personnel) . Évalué à 4.
NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the Linux
kernel) is copyrighted by me and others who actually wrote it.
# La mort annoncée de GNU/Linux ?
Posté par matiasf . Évalué à 7.
Les annonces de RMS (que j'admire) n'y changeront rien.
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par Brice Favre (site web personnel) . Évalué à 7.
J'admire les convictions de RMS et respecte son choix. Avec GNU on est sûr d'avoir du 100% libre face au 100% propriétaire de MS.
Ce ne sera peut-être pas forcément à la pointe ni super fonctionnel mais ça existera en cas de problème. Les utilisateurs eux navigueront entre ces deux pôles selont les besoins.
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par Guy Decarpentrie . Évalué à 8.
La distribution GNU/Linux Debian n'est pas 100% libre ?
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par Jonathan Loriaux . Évalué à 1.
Les répertoires (nonfree et contrib) sont simplemment "tolérés" sur les sites ftp de Debian (et donc absents sur les Cdrom's officiels).
Bon, j'avoue que c'est un peu tiré par les cheveux mais "Officielement" il n'y a pas de logiciels à licence non libre dans GNU/Debian
-1,HS
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par Étienne . Évalué à 3.
Je vous accorde que c'est une pirouette mais la distribution Debian est 100% libre.
Etienne
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par Gaël Le Mignot . Évalué à 7.
Qu'est-ce qui te permet d'affirmer ça ? A court terme peut-être, mais à long terme je pense que c'est plutôt Linux qui aura du mal à ce maintenir au niveau du Hurd sur les possibilités, la sécurité, ...
Il suffit de voir comment on galère juste pour avoir du ftpfs sous Linux...
Ou bien explique moi comment tu fais un serveur FTP non-anonyme sans lui donner les droits root...
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par Guy Decarpentrie . Évalué à -5.
Moi ca me rappelle ce que j'ai lu à propos d'Unix, et de la multiplicité des versions qui a causé sa "perte"...
Trop d'OS tue l'OS...
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par vrm (site web personnel) . Évalué à 5.
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par Guy Decarpentrie . Évalué à -2.
Replonge dans toi dans l'histoire de l'informatique de ces 15 dernières années, et tu verras que s'il n'est pas mort, Unix a quand même bien souffert...
++
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par benja . Évalué à 1.
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par Gaël Le Mignot . Évalué à 7.
Arf :) je suis loin d'être l'expert sur le Hurd et les micro-noyaux ici, cela fait juste quelques mois que je m'intéresse au sujet et que je me docuemente, m'enfin bon....
Oui, GNU (GNU/Hurd si vous voulez) respectera les normes POSIX, tout en offrant d'avantages de possibilités, comme c'est toujours le cas dans le projet GNU. Bash est un shell POSIX avec des extensions, gcc 3.x est un compilateur C ISO 99 avec des extensions, ...
Maintenant à l'heure actuelle, l'intégralité de la norme POSIX ne doit pas encore être supportée par le Hurd (il manque les pthreads par exemple)
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par François Romieu (site web personnel) . Évalué à 4.
Ca gère mon SMP ?
La NVidia, elle fonctionne ?
Et mon modem ADSL ?
Je sens que je vais prendre un coup de vieux quand vont sortir les pilotes Fast-Ethernet en
user-space. Mon P133 aussi d'ailleurs.
> Pour des raisons de sécurité ? De fiabilité (lorsque tout marchera bien) ? Pour tous les avantages qu'il apporte(ra) ?
Est-ce que c'est fun ? Parce qu'avec Linus c'est fun.
RMS, le lisp, Emacs, Hurd...
Je crois que je commence à comprendre Al. Viro quand il se dit prêt à écrire sa libc.
Garçon, une vodka-Tranxen.
--
Ueimor
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par Manuel Menal . É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: La mort annoncée de GNU/Linux ?
Posté par François Romieu (site web personnel) . Évalué à 1.
Le Hurd dispose peut-être de codeurs de combat mais amtha tous les problèmes sont loins d'être
aussi simples qu'annoncé.
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(
Je ne suis pas sûr de bien savoir quels sont les objectifs du Hurd mais si gcc où Emacs pouvaient
prétendre innover d'une certaine manière, le Hurd semble lui encore un peu en retard.
Tant mieux, ca m'arrange de ne pas avoir à regarder tout de suite les sources :o)
--
Ueimor
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par Manuel Menal . É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: La mort annoncée de GNU/Linux ?
Posté par Anonyme . Évalué à 2.
Ben je vois pas ce qui empêche de créer un serveur ftp sur un port > 1024 et de creer des logins d'accès dans un système d'authentification quelconque (LDAP, SQL, fichier...)
Et si tu veux utiliser les comptes système, alors là, je m'insurge ! Il n'y a rien de pire pour la sécurité d'un système que de donner la possibilité à un utilisateur de lancer un service avec une authentification qui utilise les mots de passe dudit système.
La personne en question peut de ce fait TRÈS facilement récupérer les mots de passe des autres utilisateurs.
Très franchement, sur ce coup là, l'exemple est TRÈS mal choisi...
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par Gaël Le Mignot . Évalué à 2.
Sous GNU/Linux et tous les autres Unix, tu es obligé de lancer un serveur FTP avec les droits root pourqu'il puisse ensuite faire setuid() avec l'UID de celui qui vient de s'authentifier. Ton serveur FTP est donc un énorme trou de sécurité potentielle puisqu'il est root.
Sous GNU, tu dois toujours lancer ton serveur avec des droits spéciaux pour qu'il puisse faire un bind() sur le port 21. Mais ensuite il peut abandonner tout privilège, toute identité, et lorsque quelqu'un lui donnera un login/mdp il demandera alors des droits au serveur de mot de passes.
Dans les deux cas, seul l'admin (ou quelqu'un de privilégié) a pu lancer le serveur FTP sur le port 21, donc tu ne compromets pas du tout la sécurité de la manière dont tu parles. Mais par contre un trou dans ton serveur FTP n'aura que des conséquences mineures, et ne pourra jamais donner un shell root à un cracker.
Bien sur, un user normal peut lancer un serveur FTP de ce type sur un port > 1024, mais là c'est celui qui est suffisament inconscient pour donner son mdp dans de telles conditions qui commet une faute, et pas une erreur de conception du Hurd.
# Une distribution, deux noyaux, c'est comme ca que ca va finir
Posté par adolphos . Évalué à 2.
Sans vérifier, ca doit être compatible binaire Linux, puisque Linux utlise deja les outils GNU.
En tout cas, plus il y a de choix, mieux c'est.
Surtout si ze Hurd est/devient super super, Linux devrat lui aussi s'amméliorer encore plus.
C'est ou Hurdfr.org deja ?
[^] # Re: Une distribution, deux noyaux, c'est comme ca que ca va finir
Posté par Gaël Le Mignot . Évalué à 10.
Il y aussi d'autres choses qui sont légèrement différentes, par exemple LILO ne sait pas charger le Hurd, il faut utiliser Grub, le système de translator est légèrement différent du système de points de montages (avec les translators passifs par exemple il n'est pas nécessaire de relancer un mount /dev/hda2 /home à chaque boot, ...)
Mais il existe une Debian GNU/Linux Sid et une Debian GNU/Hurd qui sont assez proches et ont beaucoup d'applications en commun. Pour un utilisateur final, les différences sont peu visibles, si ce n'est que le Hurd offre plus de possibilités, et surtout de manière plus propre (plus de besoin d'une couche gnome-vfs ou kioslave pour acceder à un répertoire FTP ou un .tar de manière transparente, ...)
[^] # Re: Une distribution, deux noyaux, c'est comme ca que ca va finir
Posté par Euclide (site web personnel) . Évalué à 0.
Comme les 2 OS ne diffèrent pas de grand chose (le kernel et l'interface avec le kernel), ca ne doit pas etre trop dur non ?
En tout cas un freebsd et un GNU/linux ont moins en commun que les 2 versions du GNU
(sauf si certaines applis passent du userland linux au serverland (???) Hurd)
[^] # Re: compatibilité binaire
Posté par Manuel Menal . É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: Une distribution, deux noyaux, c'est comme ca que ca va finir
Posté par Anonyme . Évalué à 3.
Mouais, c'est un argument qui ne me convaint (c'est comme ça qu'on conjugue convaincre ?) pas...
Le seul inconvénient de gnome-vfs ou kioslave, c'est qu'ils sont 2 et que si on utilise à la fois une appli gnome et une appli kde qui utilisent ces fonctionnalités, on a des trucs qui font double emploi.
Mais en l'absence d'une solution technique à un problème, on va toujours se retrouver dans le même genre de cas, que ce soit facile ou pas à faire, il y aura toujours de multiples implémentations de la même chose...
Par ailleurs, gnome-vfs et kioslave étant en userspace, il n'y aurait pas de différence flagrante s'il existait des translators, si ce n'est l'organisation autour du µ-noyau.
[^] # Re: Une distribution, deux noyaux, c'est comme ca que ca va finir
Posté par Jacolin Robert . Évalué à -1.
Sans vérifier, Windows doit avoir une compatibilité binaire avec Linux, puisque on peut utiliser Gimp sous Windows.
Comment ca j'ai dit une connerie ?
Percision : il suffit de recompiler les outils GNU pour les faire fonctionner sur un OS ou un autre, tout simplement. Ce n'est pas pour ca qu'il y a compatibilité binaire.
Maintenant rien n'empêche que ce soit le cas, effectivement.
[^] # Re: Une distribution, deux noyaux, c'est comme ca que ca va finir
Posté par Tonnerre de LoZe . Évalué à -1.
[^] # Re: Une distribution, deux noyaux, c'est comme ca que ca va finir
Posté par wismerhill . Évalué à 1.
[^] # Re: Une distribution, deux noyaux, c'est comme ca que ca va finir
Posté par Jacolin Robert . Évalué à 3.
Sans vérifier, Windows doit avoir une compatibilité binaire avec Linux, puisque on peut utiliser Gimp sous Windows.
Comment ca j'ai dit une connerie ?
Percision : il suffit de recompiler les outils GNU pour les faire fonctionner sur un OS ou un autre, tout simplement. Ce n'est pas pour ca qu'il y a compatibilité binaire. C'est compatible source (si l'expression existe).
Maintenant rien n'empêche que ce soit le cas, effectivement.
[^] # Re: Une distribution, deux noyaux, c'est comme ca que ca va finir
Posté par nodens . Évalué à 6.
On dit : "Portable" :-)
[^] # Moi je croyais qu'il existé une norme Intel pour les Unix,
Posté par Tonnerre de LoZe . Évalué à 1.
Est-ce que j'ai révé ou quoi ?
[^] # Re: Moi je croyais qu'il existé une norme Intel pour les Unix,
Posté par Jean-Yves B. . Évalué à 3.
Le but était de faire tourner des binaires i386 pour SCO, XENIX et d'autres Unix dérivés de SVR3.
[^] # Re: Une distribution, deux noyaux, c'est comme ca que ca va finir
Posté par phq . Évalué à 3.
Une application linux native ne tournera pas aussi bien sous linux qu'en compatibilité binaire sous Hurd, puisqu'elle ne profitera pas de la conception µnoyau de GNU/Hurd. Si un serveur Hurd de compatibilité binaire linux doit exister un jour, il fera un boulot de porc.
Les applis linux native n'auront pas une performance optimale et on dira que Hurd c'est lent tout ca à cause d'une bande d'abrutis qui ont eu la flemme de recompiler leurs applis (il me semble que Hurd est conforme posix, ou du moins y est destiné, donc la compil ne doit pas poser de problème) ou qui ont envie (honte sur eux !!! :) d'utiliser du propriétaire linux avec Hurd.
alors bon, la compatibilité binaire, oui mais avec modération (vachement même !).
[^] # Re: Une distribution, deux noyaux, c'est comme ca que ca va finir
Posté par rgardon . Évalué à 4.
hum, je crois que tu as un peu inverse ce que tu voulais dire :)
Une appli tournera mieux sur le systeme vise que sur une "emulation" (je ne trouve que ce mot), ce qui semble logique...
# Différences
Posté par Euclide (site web personnel) . Évalué à 4.
la glib est changée mais garde la meme API du point de vue user je présume.
Xfree doit etre modifié pour les drivers (le DRI)
Les fs sont les memes a priori
Les executables peuvent rester au meme format aussi
L'init par contre, ca se passe comment ?
Certains utilitaires doivent etre changés, bien que ca dépende des détails d'implémentation de la l'interface (si le /proc est compatible ca peut aider)
Si les mainteneurs font bien leur travail, on devrait pouvoir passer d'un kernel a l'autre de maniere presque transparente ou est ce qu'il faudra maintenir 2 OS complets ?
[^] # Re: Différences
Posté par Gaël Le Mignot . Évalué à 10.
XFree doit être modifié pour le DRI uniquement, actuellement c'est simple: il n'y a pas de DRI sous GNU, il faut le désactiver.
Les FS peuvent être les mêmes ou bien ils peuvent être différents, pour l'instant la Debian GNU/Hurd utilise ext2fs par défaut. Un FS sous GNU ce n'est qu'un translator, un programme user-space normal, et il est donc possible d'en rajouter relativement simplement.
Les éxécutables sont en ELF, mais la compatibilité binaire ne fonctionne pas actuellement.
Pour l'init, ça dépend de la distrib je dirais... L'init n'est pas la même entre une Slackware te une Debian je crois, par exemple. Actuellement la Debian GNU/Hurd utilise une init System V comme la Debian GNU/Linux. Un nouveau système d'init est actuellement à l'étude.
Si les mainteneurs font bien leur travail, on devrait pouvoir passer d'un kernel a l'autre de maniere presque transparente ou est ce qu'il faudra maintenir 2 OS complets ?
Actuellement il faut des OS complets à cause du manque de compatibilité binaire, mais ce sont les mêmes programmes qui tournent sur les deux OS (en gros)
[^] # Curiosité
Posté par Jul (site web personnel) . Évalué à 1.
[^] # Re: Curiosité
Posté par aae . Évalué à 2.
sur le site hurdfr.org, on peut lire :
Actuellement, le Hurd tourne sur des machines IA32 (architecture x86). Le Hurd devrait, et probablement va, être porté sur d'autres architectures ou d'autre micronoyaux (voir OSKit-Mach et le projet L4).
[^] # Re: Curiosité
Posté par Gaël Le Mignot . Évalué à 3.
# utilisable ?
Posté par Éric (site web personnel) . Évalué à 10.
- 2.7. Pourquoi `/usr' est-il un lien symbolique vers `.'?
{MB} La distinction entre / et /usr a une justification historique, du temps où les systèmes Unix étaient amorcés à partir de deux bandes, une petite bande root et une plus grosse bande usr. Ajourd'hui, il est toujours pratique d'avoir des partitions séparées pour ces deux espaces. Hurd se débarasse de ces rebuts historiques, parce que nous pensons avoir trouvé une solution plus souple, les systèmes de fichiers cachés. Malheureusement shadowfs n'est pas encore implémenté.
Ok, ils ont trouvé une solution plus souple, mais qui n'est pas implémentée, donc pour l'instant on se trouve comme des cons non ?
- Vous utilisez le partage d'IRQ; GNU Mach ne supporte pas cela
Limite tout de meme. Je sais que sur un serveur le nombre de cartes est limitées mais bon ...
- 3.6. Puis-je utiliser des partitions de plus d'1 Go?
{NHW} Non, pas avant que libdiskfs soit réécrite et LFS implémenté. Des efforts sont faits en ce moment, cependant, ce n'est pas une priorité pour les développeurs.
Là c'est du foutage de gueule ...
Qu'un systeme tourne sur de partoches de 1Go je veux bien, mais de là à dire qu'il peut etre utilisable en prod ...
Bonne chance votre serveur avec des partitions de 1Go. Et si c'est pour un poste de loisir ne cherchez pas trop à y mettre films ou jeux.
Pas une priorité, suporter des disques de plus d'1 Go ..... arghhh, même dos il supporte 2Go non ?
- 3.7. De combien de swap ai-je besoin?
{NHW} Généralement, beaucoup ; dès qu'elle s'épuise, Mach panique. J'ai au moins 128Mo de ram et 256Mo de swap sur toutes mes machines Hurd.
Pas top non plus pour de la prod ca .... si un process part en boucle et fait de l'affectation de mémoire en boucle (oui, je sais ca n'est pas sencer arriver .. mais ca arrive tout de meme) c'est le systeme qui panique ... génial ... surtout que la partition de swap doit pas pouvoir etre de plus d'1 Go non plus ? si ? bon là je suis de mauvaise foi, on n'a qu'a en mettre plusieurs. Mais le kernel qui panique c'est moyen je trouve
Non, franchement, utilisable en prod ? soit ce doc date d'avant guerre (j'ai suivi un bete lien de debian/hurd ou de hurdfr, pas un truc trouvé au bout de 150 pages de recherche) soit c'est du foutage de gueule que de dire que c'est bientot utilisable en prod.
[^] # Re: utilisable ?
Posté par ufoot (site web personnel) . Évalué à 3.
2002 n'est pas fini, il reste grosso-modo 9 mois, j'appelle pas ca "bientot". Donc il leur reste du temps pour coder et tester j'imagine...
[^] # Re: utilisable ?
Posté par Sylvain Rampacek (site web personnel) . Évalué à 5.
Je trouve ça très très ambitieux...
Il restera des problèmes ! c'est certain !
Ne serait-ce que le système de partage IRQ... tous les tests qu'ils ont pu réalisé jusqu'à maintenant seront à refaire ! Absolument tous... !
Alors, pour le serveur de prod, je suis entièrement d'accord avec daGanf : c'est impossible dans un futur proche.
[^] # Re: utilisable ?
Posté par Gaël Le Mignot . Évalué à 7.
ShadowFS est implémenté maintenant je crois.
Limite tout de meme. Je sais que sur un serveur le nombre de cartes est limitées mais bon ...
Le Hurd va passer sur OSKit Mach d'ici peu.
Là c'est du foutage de gueule ...
Ce sera corrigé d'ici la fin de l'année, et ce n'est pas du "foutage de gueule" pour une version de développement. Et la limite n'est pas d'1 Go partout elle varie de 1 Go à 4 Go suivant les machines.
Pas top non plus pour de la prod ca ....
Idem, c'est une limitation de GNU Mach qui n'existe pas dans OSKit Mach, pas une limitation du Hurd.
# GNU/Linux vs GNU/*
Posté par pablo . Évalué à 3.
Je pense que Gnu/linux est effectivement en danger de mort, mais pour d'autres raisons, certaines grosses distribs proposent de plus en plus des packages proprietaires, ils pensent peut etre attirer de cette facons les gros poissons. Et si cette tendance se generalise, je pense qu'une grande partie de la communaute cherchera rapidement une solution de remplacement.
Mais bon, Gnu/linux a quand meme de beaux jours devant lui "because code matters most than commercial..."
[^] # Re: GNU/Linux vs GNU/*
Posté par Gaël Le Mignot . Évalué à 10.
Le Hurd n'est pas un remplacement de GNU/Linux, juste de Linux. Tous les outils (glibc, ld, gcc, XFree, emacs, ...) restent à peu près les mêmes.
Pour le moment, non, il n'est pas un candidat sérieux pour remplacer Linux sur les machines de prod. Pour le moment. RMS est optimiste et prévoit qu'il sera en 2002, pour ma part je dirais plutôt mi-2003, mais ni lui ni moi ne sommes des devins, ni même les mieux placés pour faire des prédictions.
[^] # Re: GNU/Linux vs GNU/*
Posté par matiasf . Évalué à -1.
Ou veux-tu en venir ?
[^] # Re: GNU/Linux vs GNU/*
Posté par pablo . Évalué à 1.
[^] # Re: GNU/Linux vs GNU/*
Posté par Jean . Évalué à 1.
[^] # Re: GNU/Linux vs GNU/*
Posté par Gaël Le Mignot . Évalué à 1.
-1 [jeretournesurlatribune]
[^] # Re: GNU/Linux vs GNU/*
Posté par Jean . Évalué à -1.
-1 troll gratuit [ilfaitchaudsurlatribune]
[^] # Re: GNU/Linux vs GNU/*
Posté par Timbert Benoît . Évalué à -1.
La Debian non plus (à moins que tu désinstalles X, LILO, et tout un tas de trucs... Serait-ce encore utilisable ?)
-1 Troll GPL
# Hurd, ça fonctionne ?
Posté par Jul (site web personnel) . Évalué à 1.
Perso, j'ai pas essayé. Mais je parie qu'il y en a pas mal d'autres qui n'ont pas essayé et qui peuvent m'assurer que c'est super parce que c'est du µK (je suppose que ca doit vouloir dire microkernel). Pfff encore du buzz. Et pour une fois c'est pas µ$ qui le fait.
If a camel is a horse designed by a committee, then a consensus forecast is a
camel's behind.
-- Edgar R. Fiedler
(repris des excellentes fortune BSD)
[^] # Re: Hurd, ça fonctionne ?
Posté par Jul (site web personnel) . Évalué à 2.
Ils l'ont fait exprès
<tt>
<_seb_> sammy; pas envie de rentrer dans des querelles d'OS à la con; une
becane, ca me sert à bosser. avec hurd, tu t'amuses.
- #francaise
<tt>
Au fait, j'aimerais vraiment connaître le meilleur uptime hurd.
[^] # Re: Hurd, ça fonctionne ?
Posté par Étienne . Évalué à 2.
http://www.vicenza.linux.it/~vicenza/mailing-list/lugvi-fans-200008(...)
un uptime de 8 jours.
et sur :
http://hurd.dyndns.org/age.html(...)
Il dit avoir eu un uptime maximum de 6 semaines.
Si tout ceci est vrai, je trouve ca pas mal pour un système en plein développement
[^] # Re: Hurd, ça fonctionne ?
Posté par Manuel Menal . É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: Hurd, ça fonctionne ?
Posté par Jacolin Robert . Évalué à -1.
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 ?
Tout ça pour dire: ne le prenez pas _trop_ au sérieux.
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).
[^] # Re: Hurd, ça fonctionne ?
Posté par Manuel Menal . É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: Hurd, ça fonctionne ?
Posté par Troy McClure (site web personnel) . Évalué à -1.
la version originale est "pas envie de rentrer dans des querelles d'OS à la con; une
becane, ca me sert à bosser. avec linux, tu t'amuses."
# Oui mais...
Posté par Yann KLIS (site web personnel) . Évalué à 1.
De plus, Linux commencent à avoir des extensions temps réels.
Qu'en est-il du Hurd ?
Est-ce que l'architecture µnoyau permet de s'en tirer avec une empreinte mémoire moins importante que Linux. Est-ce qu'on peut facilement tailler des croupières au Hurd pour le faire tourner sur un IPaQ ?
Si les réponses sont non, Linux à de très beaux jours devant lui...
[^] # Re: Oui mais...
Posté par Manuel Menal . É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: Oui mais...
Posté par Nico . Évalué à 1.
Nico - perdu -
[^] # Re: Oui mais...
Posté par Gaël Le Mignot . Évalué à 3.
Le Hurd est un ensemble de serveurs tournant par dessus un micro-noyau et proposant aux programmes des fonctionnalités équivalentes (ou supérieures) à celles fournies par les noyaux monolithiques comme Linux.
Un parralèle à Linux ?
Si on veut, disons qu'un micro-noyau (GNU Mach, OSKit Mach, ...) + le Hurd peut (pourra) remplacer Linux dans un système.
Il y a une différence fondamentale ?
Oui, plusieurs différences fondamentales, tout a déjà été expliqué plus haut par Manuel Menal et moi (entre autres), relis les commentaires.
C'est la FSF qui devellope HURD et Linus qui devellope Linux c'est ça ??
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.
Le Hurd est un projet GNU officiel, au même titre que GNU Emacs, gcc, la GNU libc ou GNU bash, mais il n'est pas développé directement par la FSF, mais plus par des contribueurs de part le monde, comme Linux ou les autres projets libres.
[^] # Re: Oui mais...
Posté par Manuel Menal . É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.
# Pourquoi ?
Posté par Pascal Schalck . Évalué à 1.
Pourquoi les opposer ?
L'émulation est bonne à prendre, on installera les 2 sur nos machines.
Bye
# n'en déplaise aux opposants du Hurd
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 1.
Je prendrais comme premier exemple BeOs (même si commercialement parlant ca a été un flop...)
Et en deuxieme exemple, l'un des plus stable et des plus performants (lui au moins sait faire du vai temps réèl) : QNX.
Ce système existe depuis le debut des années 80 et est beaucoup utilisé dans les systèmes embarqués, environnement qui necessite une stabilité à toute épreuve...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.