HappyPeng a écrit 324 commentaires

Bonne opération commerciale pour Mandrake en effet. Encore quelques forums et leurs actionnaires pourront récolter leurs bénéfices.

J'aurais préféré Knoppix sur l'ordinateur et aussi Knoppix sur la table.

Dans ce cas, il semblerait que les fans de BeOS eux-mêmes ne parviennent pas à se mettre d'accord sur le type de kernel qu'ils utilisent. En tout cas, si BeOS était basé sur un microkernel, OpenBeOS lui ne le sera pas ; une telle régression serait plutôt triste.

Les fonctionnalités prétenduement approchées par Linux n'approchent même pas celles offertes par le Hurd ... UML provoque une augmentation de la TCB, ce qui a des implications en matière de sécurité - on pourrait dire la même chose de BSD Jail ou autre «hacks» sur des Unix-like monolithiques ; les modules tournent toujours en kernel space et donc ne peuvent être «bidouillés» de façon secure ou stable, etc.
Bref, vous l'avez dit, les avantages théoriques d'un Hurd abouti ne sont plus a démontrer ; par conséquent, une fois cela dit, il est sûr et certain que ses développeurs n'abandonneront pas en chemin, puisqu'aucun autre projet libre ne semble vouloir atteindre ces objectifs.
Et je suis à 200% pour : dans ce domaine, tellement d'OS stables existent que l'on ne peut aller en avant qu'avec beaucoup de travail et de remises en question, c'est-à-dire beaucoup de temps, et je suis toujours persuadé qu'il faut chercher à aller en avant au lieu de vouloir rester sur une solution pour toujours. Oui, Linux est stable, Linux est améliorable. Mais même si le Hurd arrive dans 10 ans, Linux ne sera jamais ce que pourra être le Hurd s'il conserve le design traditionnel Unix-like monolithique.

Quand a GNUstep ... Autre débat qui mériterait d'être engagé, auquel je pourrais prendre part avec le plus grand intérêt :-)

Il ne s'agit pas d'avoir les possibilités de détruire son système (comme en étant root) mais d'avoir infiniement plus de possibilités tout en n'ayant pas celle de détruire le système. Notamment les différentes personnalités, la possibilité de tester différents composants du système en parallèle et de choisir ces composants, mais également des applications plus simples comme simplement des ftpfs et autres sshfs propres, maintenables et utilisables.
Les applications sont également importantes en ce qui concerne la sécurité, non seulement dans le nouveau système de permissions mais également dans la possibilité de lancer plusieurs instances du système d'exploitation ou de parts du système d'exploitation en parallèle (fonctions qu'UML ne pourra jamais remplir).

Il est donc simpliste de dire que le Hurd est inutile puisque chacun peut aujourd'hui être root - si être root était l'idéal d'utilisation d'un système, pourquoi tous les GNU/Linuxiens ne tourneraient-ils pas que en root ? Et après tout ils peuvent augmenter leurs privilèges avec chmod.
Nous parlons avec le Hurd d'une extension des possibilités pour l'utilisateur avec une amélioration et non une déterioration de la sécurité et de l'utilisabilité.

En ce qui concerne l'impact sur les performances, nous ne pouvons pas savoir à l'heure actuelle ce qu'il sera (inutile de parler de mach) ; mais le projet L4Ka::Pistachio (http://www.lk4a.org(...)) semble sur ce plan plus que prometteur, et ses concepteurs semblent penser qu'il sera possible d'avoir un système multiserveur aussi voir plus performant qu'un système monolithique.

le Hurd suit une voie qui n'a jamais été vraiment empruntée (sauf peut-être par BeOS, et encore)

Je rectifie (avant que ce cher mmu_man ne le fasse :-) : le noyau de BeOS a bel et bien un design monolithique modulaire tel Linux. Aucun rapport avec le Hurd.

Ma question était purement oratoire et n'attendait aucune réponse : en effet même si des différences existent entre Linux et Darwin, les différences de possibilités dues au design sont quasi inexistantes. Par conséquent le Darwin n'est en aucun cas un Hurd stable ou performant.

Mon post visait à dire qu'il n'y a absolument aucune comparaison faisable entre Darwin et le Hurd, parce que leur architecture n'a rien en commun (et les possibilités qu'ils pourraient apporter non plus).

Darwin est plus rapide que le Hurd sur mach ne l'est, et c'est bien évidemment le cas de Linux. Maintenant, quelles sont les possibilités fondamentales de Darwin que ne possède pas Linux ?

A noter que R. Stallman a dit récemment que si linux avait marché à l'époque de la décision de continuer hurd comme il fonctionne actuellement, ils auraient vraisemblablement arrété

Le développement du Hurd a été repris assez récemment, alors que Linux fonctionnait déjà, sur demande non de Richard M. Stallman qui semblait s'être plus ou moins résigné mais des développeurs du Hurd eux-mêmes.

Contrairement à ce que pourraient croire certains, il s'agit bel et bien de construire un système d'exploitation et non de poursuivre une pseudo-guerre GNU/Linus.

Pour la question de l'interface des drivers, elle demande au préalable l'adoption d'un micro-noyau moderne tel l4, car pour l'instant GNU mach contient l'ensemble des drivers, qui tournent en kernel mode, et ne sont même pas chargeables par des modules. Par conséquent une telle interface existera dès lors que le Hurd tournera sur l4, car les drivers seront alors en userspace et donc une telle interface sera nécessaire - et comme les drivers sont nécessaires pour que le Hurd puisse tourner, tout ne dépend que de l'avancement du Hurd sur l4.

Je crois que vous devriez plutôt poser la question à quelqu'un que nous connaissons sur IRC et qui s'intéresse beaucoup au DDF (Device Driver Framework) du Hurd sur l4. :-)

Je ne suis pas non plus convaincu que les translators soient ce qui est revolutionnaire dans le hurd.

Les translators sont ce qu'il y a de plus révolutionnaire dans le Hurd parce que ce sont eux qui permettent tout ce que le Hurd peut apporter de révolutionnaire. Ce sont eux qui donnent toute la modularité à l'OS, et si l'on y réfléchit, les possibilités sont virtuellement infinies. (Ce qu'on pourrait faire avec un Hurd achevé n'aurait absolument aucune commune mesure avec ce que l'on pourrait faire avec un Darwin ou un Linux.)

(Bien entendu, les possibilités apportés par une telle architecture ne doivent pas être confondues avec les possibilités apportées par l'implémentation actuelle qui est très largement inachevée.)

En bref, j'invite tous ceux que ça intéresse à se documenter, voir à venir poser des questions sur IRC (#hurdfr@freenode, no troll).

Il me semblait que Keith Packard était à l'origine de XServer ...

Le développement de Darwin va en effet plus vite, et Darwin tourne en effet sur le micro-noyau mach, mais la comparaison s'arrête ici.

http://www.gnu.org/software/hurd/hurd-talk.html#mul(...)
http://www.gnu.org/software/hurd/hurd-paper.html(...)
http://www.gnu.org/software/hurd/faq.fr.html#q2-1(...)

Manifestement, au moins une distribution n'est pas d'accord avec vos choix.

$ apt-cache search kmail
kmail - KDE Email client

$ apt-cache search knode
knode - KDE news reader

Ceci dit pour le reste, puisqu'on a des outils pour compiler un CVS Gnome ...

Pour Gnome, c'est avant tout une différence d'organisation. Les "paquets" KDE dont vous parlez (kdebase, kdemultimedia, etc.) me semblent bien plus ressembler à des métapaquets, et ils sont tels quels dans le CVS.

Gnome a une organisation plus classique, chaque projet composant a son propre module CVS, et des outils de compilation tels garnome ou jhbuild fournissent le moyen de compiler aisément l'ensemble.

J'apporte ces précisions avant tout parce que vous ne pouvez vous empêcher quelque soit le prétexte de dénigrer Gnome :-)

Pourquoi, vous préfereriez une boîte de message à la KDE, Ces modifications ne seront prises en compte que pour les applications nouvellement lancées ?

Voilà où il venait en venir, le vilain méchant trolleur.

oafd n'existe plus avec Gnome 2. Vous venez de vous trahir, ça finit par se voir que vous n'avez jamais testé cet environnement de bureau :-)

Epiphany, projet membre du desktop Gnome, utilise Gecko. Gtkhtml n'est pas utilisé dans les mêmes buts, et n'a donc pour l'instant pas la nécessité d'un interpréteur JavaScript, AFAIK.

Ce sont plusieurs fichiers binaires, il me semble pas plus de quelques-uns (deux pour la machine, un par utilisateur, non ?), non modifiables directement lorsque Windows refuse de démarrer. Et la base de registre Windows est incapable de faire ce que gconf fait de base : prise en compte des modifications en direct, sans redémarrer l'application (ni l'OS :-).

s/aucun/peu/, et pour le reste on vous le répète depuis des heures.

Parce que vos affirmations reposent sur un autre mensonge : kcontrol est simple d'utilisation.

Arrêtez de jouer le power-user à deux balles, regardez ces interfaces, réfléchissez un peu et revenez en parler après vous être calmé.

Je vous ai dit qu'il n'y avait pas énormément de choses dans ces interfaces, et on vous a dit et répété pourquoi.

Ça me paraissait évident que les supporters / développeurs d'applis Gnome n'allaient pas réagir par un "Oh oui super, allons tout de suite corriger les bugs de KDE et ils feront de même lorsqu'il s'agira de Gnome" ... soyons un peu réalistes :-)

Ceci dit ces prétendues divisions sont surtout pour moi la principale force de la communauté : liberté de choix, liberté de faire ce que l'on veut.

Les interfaces de configuration Gnome (nous ne parlons pas de gconf ici) sont incomparablement plus simples car moins surchargées que celles de KDE, et donc accessibles aux débutants.

Tu ne peux rien casser de plus avec gconf-editor qu'avec le kcontrol de KDE,
et gconf-editor est simple et efficace.

Ensuite, dans les deux cas une configuration par défaut, utilisable, est proposée.

Seulement là où Gnome propose quelques options simples et accessibles pour paramétrer son environnement, vous nous dites "kcontrol est trop complexe, vous n'avez qu'à pas y aller si vous êtes débutant" ? C'est ridicule, et ça n'est qu'un argument en défaveur de KDE ; car les interfaces de configuration Gnome existent et elles sont simples.

Enfin, gconf n'a que très peu en commun avec regedit, vous seriez aimable d'utiliser les bons termes.