Gaël Le Mignot a écrit 812 commentaires

Honnêtement, la VM du noyau 2.4.18 est loin d'être terrible, -rmap (inclue dans les noyaux -ac et -mjc) est beaucoup plus fiable et performante (c'est en tout cas mon impression aussi bien à l'utilisation qu'à la lecture des ML)... Maintenant c'est vrai que changer de VM en plein milieu d'une branche stable (2.4.10) ça a multiplié le nombre de noyaux sortis rapidement pour corriger tout ça...

Sinon, pour Marcelo, il prend son temps et c'est pas plus mal... on est au 2.4.19-rc3, le 2.4.19 ne devrait donc pas trop tarder.

Non.
Enfin, j'aurais peut-être pu dire "En attendant le GNU Hurd".
On a "GNU/Hurd" ou "GNU" qui désigne le système d'exploitation GNU complet, et "le Hurd" ou "le GNU Hurd" (ou "le Troupeau") qui désigne uniquement les serveurs et bibliothèques qui composent le Hurd, mais pas le reste (pas le micro-noyau, ni la libc, ni les outils GNU, ...)

-1 HS

Je tiens à préciser qu'une version minimale de -rmap a été intégrée dans le noyau 2.5.27. -rmap est une nouvelle VM (Virtual Memory: gestion de la mémoire virtuelle, du swap, du cache disque, ...) créée par Rik Van Riel et qui utilise le principe du reverse mapping (au lieu d'avoir juste une liste de pages utilisées par chaque processus le noyau maintient aussi une liste des processus utilisant chacune des pages, ce qui lui permet de mieux "décider" quelle page garder et quelle page swapper).

Le mail présentant le patch "Minimal -rmap" ainsi que les possibilités futures du reverse mapping est sur http://www.uwsg.iu.edu/hypermail/linux/kernel/0207.2/0265.html(...)

PS: désolé, mais j'ai été mis au courant l'intégration de ce patch après avoir poster ma news

D'ailleurs d'autres photos de Hurdistes sont sur http://kilobug.free.fr/lsm(...) .

> AmigaOS n'a rien d'un micro-kernel J'ai pas dit ça, j'ai dit qu'il en avait certains des aspects > car il a besoin de certaines choses qui sont rendues impossible en utilisant un micro-kernel "ideal". ah ? quoi ? > quand t'as un kernel-mode driver c'est parce que tu veux t'affranchir du cout de passage a travers des interfaces et laisser les drivers acceder directement a ce qu'il veut Même quand un morceau de code est exécuté dans le même espace d'addresse (insmod, dlopen, ...) pour des raisons de perfs (et là encore c'est discutable), _rien_ n'empêche de définir clairement des interfaces... je croyais que c'était l'avantage de l'OO et de l'encapsulation par exemple... > c'est un choix entre performance et portabilite de driver, MS a choisi performance et c'est pas forcement plus mal. Déjà c'est pas sûr du tout que cela coûte en performance (pour plus d'info: http://l4ka.org et les très bon articles comme "Towards real µ-kernels", "Microkernels can and must be small", "Acheiving fast IPC", "The performance of µ-kernel based systems", ...), on a fait beaucoup de progrès sur la vitesse des IPC depuis Mach, et Pistachio (aka L4 X.2) permet de faire de l'IPC 4x plus vite qu'un syscall classique (donc avoir des drivers en user-space _augmente_ la vitesse puisqu'un syscall est remplacé par un RPC). Et enfin, là on parle de standardiser les interfaces pour hooker un antivirus dans le filesystem ou pour graver un CD, pas des interfaces bas niveau, là on parle bien des interfaces entre la partie OS et les applications, et ça ça _doit_ être standardisé.

Qu'un antivirus ou qu'un graveur de CD soit mi-driver, c'est qu'il y a comme un pb AMHA.

> graveur de CD --> driver pour gerer le graveur mwarf, et donc tous les programmes ont besoin d'être patchés parce qu'ils utilisent le driver pour accéder au disque ou je ne sais pas quoi ? Bien sûr que les programmes _utilisent_ des drivers... Mais ça n'en est pas. > on attendra que Le Hurd fasse autre chose que rebooter pour voir si ca tient. Il fait déjà plein d'autres choses... > J'ai hate de te voir dans 10 ans une fois que tu auras vecu certaines experiences, bla bla bla... y'a pas que des "étudiants" ou des 15-25 ans qui bossent sur le Hurd et qui défendent les micro-noyaux (ou le C, ou les logiciels libres suivant le domaine où tu te places), alors ton vieil argument à base de "t'es un jeune étudiant, tu sais rien t'as tord", tu évites STP. > le micro-kernel dont parle tes cours de theorie n'est present dans aucun OS a grande distribution. Et MacOS X ? Y'a un micro-kernel Mach dedans. Et QNX ? Et AmigaOS ? Et même BeOS sur certains points de vue (pile tcp/ip en userspace) ? Aucun OS n'exploite à fond les possibilités des micro-noyaux comme le fera GNU, mais certains concepts des micro-noyaux sont présents dans certains OS. Et même sans avoir de micro-noyau, concevoir des interfaces stables et pérennes, c'est pas la fin du monde (même si ça demande de réfléchir avant de coder...)

Un graveur de CD c'est un driver ? Un anti-virus c'est un driver ? Et ça tourne en kernel-space aussi tout ça ? J'espère que non quand même... Au fait, c'est pas censé être un système à base micro-noyau 2000/XP ? Parce que si c'était vraiment le cas, même le firewall, même les drivers, ils devraient pas en avoir grand chose à faire du changement de version de l'OS... Parce que la notion de composants indépendant communiquant par des interfaces standardisées et fixes, je crois que ça vous a échappé là, c'est pourtant à la base de toute la théorie des micro-noyaux... C'est justement l'un des buts des micro-noyaux de pouvoir mettre à jour les composants séparéments...

Non, c'est toi qui n'a rien compris au fonctionnement du monde réel.

Compare les logiciels libres et les logiciels propriétaires niveau qualité, et dis-moi dans lesquels tu as le plus de bugfixes ou de patches soumis par des utilisateurs qui justement ne sont pas des développeurs à plein temps sur ces logiciels ? Je ne te parle pas de théorie là, je te demande juste de regarder ce qui ce passe dans la réalité.

Les constructeurs de voitures, justement, offrent des solutions similaires (ex Toyota)

Rien à voir. Ce n'est pas qu'une société te _propose_ de s'occuper de tout le pb, mais qu'elle t'_oblige_ à le faire. Ma toyota je peux la faire réparer chez le garagiste du coin (pan) et mon ordinateur IBM je peux aussi mettre un processeur acheté rue Montgallet si je le souhaite. Au final ça reste l'utilisateur qui est libre de prendre sa décision. Là non, il n'est pas _possible_ (et c'est illégal en plus) de faire corriger un bug par quelqu'un d'autre (ou de le faire soi-même).

Donc tous les logiciels libres sont une catastrophe, d'ailleurs on le voit, Linux ne boote pas, la libc GNU ne marche, gcc n'a jamais rien compilé, Mozilla ne permet pas de surfer, XFree n'affiche rien, Apache se vautre comme une otarie tout le temps, ...

et la marmotte ?

_Tu_ t'en fous. Moi, et tous les développeurs du Hurd, ça nous dérange de voir sans cesse le nom de notre projet mal écrit (ce n'est pas "HURD" mais "the Hurd"). Et le -1 était bien là pour dire "je sais que la plupart des gens s'en foutent, donc je mets -1, mais SVP arrêtez d'écorcher le nom de notre projet, merci"

-1 aussi

Non, puisque "Hurd" est une variation phonétique du mot "Herd" qui signifie "troupeau" ou "meute". La traduction complète de "the GNU Hurd" serait "le Troupeau de Gnous" mais on garde "GNU" et "Hurd" car ce sont des acronymes...

Donc on dit bien "le Hurd" qui signifie "le Troupeau".

- Non, non, un pauvre fichier tout simple avec de la mise en forme simple que tu pouvais déjà faire avec Word 2.0 ça ne passe pas

- cf la compilation statique donc j'ai parlé à la fin, c'est pas l'idéal, mais c'est une solution possible

- appliquer un patch sur une ancienne version, ça dépend complètement de l'importance du patch. S'il s'agit d'une simple correction de bug mineur sans modification de la structure du programme ça s'applique très bien, sinon ça demande quelques heures de travail, pas plus (en général)

Enfin, visiblement tu n'as rien compris sur le fonctionnement du logiciel libre... justement ce ne sont _pas_ uniquement les "développeurs officiels" qui font des patchs. Et ça marche pour tous les projets, du kernel Linux à Mozilla en passant par GTK ou XFree. Mais n'importe qui, qui veut implémenter quelque chose, qui voit un bug, qui a envie de backporter une fonctionnalité, ...

Et le problème n'est pas de savoir si pratiquement c'est avantageux ou non, le problème est de savoir que tu _peux_ le faire, que tu n'es pas pieds et poings liés à une société, obligé d'accepter les nouvelles conditions et de payer les nouvelles licences.

Mettre à jour une version de ton noyau, ça ne coûte rien, tu l'as toujours avec les mêmes conditions (la GPL) que la 1.0, et tu peux voir quels ont été les changements. Donc ça n'est pas gênant de devoir le faire. Et puis, si pour une raison quelconque tu ne peux pas faire de mise à jour, tu _peux_ backporter, ça se fait quand le besoin existe (cf l'AGP et l'USB backportés sur le 2.2).

Mettre à jour un windows, ça veut dire payer, accepter de nouvelles conditions de plus en plus restrictives et mettant en danger la vie privée (NON, MS n'a _pas_ à savoir que j'ai décidé de changer de matos, ça ne les regarde pas), et accepter _toutes_ les modifications qui ont été faites sans même savoir en quoi elles consistent.

C'est cette relation de dépendance, être _forcé_ d'accepter les nouveaux termes de l'EULA, de repayer un prix qui n'est pas fixé, et d'être _totalement_ dépendant du bon vouloir d'une société qui est _extrêment_ dangereux et AMHA totalement inacceptable.

C'est comme si tu étais obligé de faire réparer ta voiture chez le constructeur de la voiture, en payant un prix qui n'a jamais été convenu lors de l'achat, et en étant obligé d'accepter toute nouvelle condition que le constructeur aurait envie de t'imposer. Il n'y a _aucun_ autre domaine ou le client est autant lié à une unique société, et c'est très dangereux.

- Va lire un fichier généré par Word XP avec 97, je t'assure que non, ça ne marche pas

- A une recompilation près, les programmes ne tournant pas sur une distribution même très vielle je n'en connait vraiment pas beaucoup... au pire il faut faire un bon vieux coup de linkage statique.

- Mises à jour de sécu: euh, Linux 2.0 date de 96 aussi et il est toujours maintenu... les backports de mise à jour de sécu sont aussi très très fréquente ailleurs, et au pire tu peux le faire toi même (tu lis le patch de sécu, tu regardes à quoi ça correspon dans ton "vieux" programme et tu fixes)... encore un avantage du libre.

Et même si c'était vrai, tu rends compte de l'immense différente entre "bon, nous on ne fait plus les mises à jour, mais vous avez le code et le code des patchs, si vous voulez le faire pas de problèmes, sinon vous toujours télécharger la nouvelle version librement" et "ouais, ben, votre système il est trop vieux, alors vous devez en acheter un autre, et accepter les nouvelles conditions que _nous_ décidons (genre activation, ...) sinon ben tant pis pour vous, vous avez pas le choix" ?

Dans un cas l'utilisateur est libre (de mettre à jour, de backporter, de payer quelqu'un pour backporter, ...) dans l'autre il est _forcé_ de mettre à jour selon les conditions fixées par une société (MS ou autre). C'est une dépendance qui est dangereuse et immorale.

Être attaché au logiciel libre et ne pas utiliser de logiciel propriétaire n'a rien à voir avec "jouer aux véritables" mais c'est tout simplement une histoire d'éthique et de morale.

Le logiciel propriétaire _est_ immoral et ne _doit_ pas être utilisé, c'est en tout cas mon point de vue et donc je n'en utilise pas. Ce n'est pas une histoire d'argent ou de "jouer au véritable".

Euh... Linux c'est pas un OS, c'est un noyau; et HURD ça n'existe pas. On a _le_ Hurd qui est un ensemble de serveur, mais là tu veux parler d'un OS donc GNU (ou GNU/Hurd).

-1 HS

Et les formats de fichiers (volontairement?) incompatibles ? Les programmes qui ne marchent que sur certaines versions de l'OS ? L'arrêt des mises à jour de sécurité sur les vieilles versions ? Ce ne sont pas des moyens d'_obliger_ les gens à effectuer des mises à jours (euh, pardon, à acheter une nouvelle license complète) ?

Si, le IIRC explique, je ne me rappelle plus exactement qui, ça devait donc être houplaboom je pense, en tout cas c'est l'un des devs mandrake qui sont souvent sur la tribune.

-1

J'ai dit j'ai _essayé_ cooker, pas je suis en cooker. Chez moi sur ma Debian je suis en Sid, je n'ai que _très_ rarement des pbs, cooker j'ai vite abandonné... et même sur la 8.2 j'ai sans doute autant de problèmes que sur ma Sid, avec beaucoup moins de packages, des versions plus vielles (et ne me parlez pas d'XFree, c'est un cas très spécial, puisque Debian ne se contente pas de packager XFree mais c'est eux qui font le portage sur beaucoup d'architectures... donc pour Debian intégrer XFree c'est pas juste compiler et packager, mais porter et tester ça sur les 11 architectures autres que i386-linux-gnu que la Sid supporte).

Et je signalais surtout que la mise à jour fonctionne mal (à cause des limites d'rpm justement) et que la Debian contient beaucoup plus d'applications que les autres distributions contrairement à ce que certains avaient l'air de dire.

> Cette supériorité puante qu'ont certains debiannistes primaires

Et toi respecte la netiquette STP "keep personal critics to private media".

Et évite de parler de quelqu'un que tu ne connais pas, merci.

J'utilise une mandrake au boulot, je suis en 8.2, j'ai essayé cooker, et entre les fois où urpmi se vautre comme une otarie bourrée, les fois où il met 5 minutes (réellement, montre en main) pour calculer les dépendances (limitation due au système RPM d'après houplaboom et yugz IIRC) et le nombre de paquets que je suis obligé d'alienisé depuis ma debian parce qu'ils ne sont pas dans la mandrake (rpncalc, wmakerconf, ...) je peux te dire que vraiment, une Debian et une Mandrake ça n'a _rien_ à voir, et uniquement sur le système de paquets...

Et puis des mises à jour slink => woody ou potato => sid (équiavlent mdk 8.0 => 8.2) j'en ai fait un paquet sans problèmes, même une mdk 8.1 => 8.2 j'ai du de la casse.

Et ne va pas prétendre que Hurd est utilisable dans l'état actuel des choses.

1/ on dit _le_ Hurd
2/ le Hurd c'est pas un OS, et donc il ne sera jamais utilisable seul
3/ si tu parles du système GNU (GNU Mach + le GNU Hurd + la GNU libc + ...) oui, il est utilisable. Il est encore en développement, pas adapté à un serveur, mais il fonctionne et est utilisable.

D'une part, dans le propos de TSelek, j'avais compris «GNU» au sens «le projet GNU», pas «le système GNU».

Sauf que le système GNU est la raison d'être du projet GNU. Les outils GNU ont été réalisé pour servir de composant au système GNU et pour permettre de le développer... donc le projet GNU et le système GNU sont plus deux faces d'un même objet que deux choses différentes, et parler de l'un c'est parler de l'autre.

D'autre part, j'insiste, un système qui n'existe que sur le papier n'est pas révolutionnaire à mon avis.

Sauf qu'il n'est pas seulement sur le papier, et que ce dont j'ai parlé ça existe déjà. Ce qui manque c'est du test, de l'optimisation, du débuggage, et des fonctionalités, mais l'architecture du système existe et fonctionne à l'heure actuelle, et les possibilités dont je parlais ne sont pas hypothétiques mais réelles.

Quant le Hurd sera une réalité, je changerai peut-être d'avis.

http://www.debian.org/ports/hurd/(...)

D'autre part je vois pas pourquoi un langage de haut niveau produirait des exécutables plus grs que les autre surtout si il y a du matos pour les faire tourner en hard.

Et déplacer le problème vers le hard ? Vachement intelligent... Ca fait 20 ans qu'on est conscient que le RISC est plus adapté que le CISC, que l'on sait que le hard doit en faire le moins possible justement, que l'on déplace tout vers le soft (que ce soit avec des firmwares intégrés ou autre), et tu veux revenir en arrière ? C'est complétement stupide. Le hard c'est le plus critique, ce qui _doit_ absolument être exempt de bugs, il doit donc en faire le moins possible.

C'est comme quand on fait un OS: le noyau, la partie la plus critique, complexe à changer, où un problème peut avoir des conséquences désastreuses, _doit_ être le plus petit possible pour tout ce qui est sécurité.

Inégré une VM Java ou Caml au matos, c'est complètement stupide, c'est aller à l'encontre de tous les progrès et de toutes les recherches faites ces dernières années sur le fonctionnement des systèmes.

Relis donc un peu le chapitre sur la sécurité dans le Tanenbaum (ou tout autre bouquin sérieux sur la conception d'un système) par exemple "The only way to build a secure system is to keep it simple". Plus tu compliques le noyau d'un système, et a fortiori le matos, plus tu t'exposes à de graves problèmes.

Alors au lieu de t'énerver, d'insulter les gens et de te discréditer ainsi, essaie plutôt de réfléchir vraiment à comment concevoir un système fiable, et cesse de te fixer sur les langages de programmation qui ne sont qu'une _toute_ petite partie du problème.

> Quant à GNU, j'avoue ne pas trouver en quoi il serait révolutionnaire.

Tu connais un OS à base de micro-noyau multi-serveurs qui soit réellement utilisable, toi ? T'appelle pas ça révolutionnaire ?

Tu connais un OS où si la pile TCP/IP ou le programme gérant un filesystem segfault il est relancé de manière de transparente dés la prochaine tentative d'utilisation ? Un OS où même un serveur ssh ou ftp peut s'exécuter sans avoir _aucun_ droit avant qu'on ne lui fournisse le login et le mot de passe ?

Tu connais un OS ou des utilisateurs normaux peuvent modifier la structure du VFS sans mettre en danger la sécurité ? Un OS où n'importe qui peut écrire de nouveaux composants insérables dans ce VFS sans aucun privilège (comme un translator fortune, un ftpfs ou un tarfs) ? Un OS où tu peux associer des pagers différents à chaque application ? Où tu peux créer un environement virtuel complet, dans lequel tu peux être virtuellement root, sans mettre en danger la sécurité du reste ?

Alors, avant de juger qu'un OS n'est pas révolutionnaire, regarde ce qu'est GNU, comment il est conçu et ce qu'il permet(tera) de faire.

Si tu bidouille la pile, tu pète l'ABI et c'est la merde.

C'est sûr que dans les autres langages tu n'as _jamais_ de problème d'ABI...

c'est la misère à compiler du C

Beaucoup moins que du C++ ou du Java... et même par rapport à du caml, c'est beaucoup plus simple à compiler efficacement.