Je ne pense pas que ce soit formulé ainsi. Il est *nécessaire* sur ce sujet d'avoir bien lu et assimilé http://wiki.fresco.org/index.cgi/FrescoVsX(...) . Je suis sûr que les gens de #fresco (@freenode) seront absolument ravis de recevoir un petit Np237 pour discuter avec toi et répondre à tes questions.
Je pense vraiment que c'est un argument n'en est pas un vrai. S'il est vrai qu'on peut préférer d'autres choix de design, le rejeter au nom de la BP purement et simplement est bête, et pas fondé. On ne peut pas reprocher au projet Fresco de ne pas avoir pensé à tous ces problèmes, de faire dans le vide, sans réfléchir. Il y'a un réel design dans le projet, des réels choix faits, qui se justifient et sont fondés en raison. Fresco est vraiment très intéressant à étudier, et si je ne me prononce pas quant à lui maintenant, c'est simplement parce que même en suivant le projet depuis longtemps, je ne pense pas avoir les connaissances nécessaires pour savoir s'il pourrait s'adapter et développer un un WS plus komjeve[tm], décrit sur http://linuxfr.org/comments/150869.html(...)
J'espère qu'en gars intelligent, tu essayeras aussi de te renseigner en profondeur.
Certes, mais ça ne représente quand même qu'une partie mineure :-)
Bon, pour revenir à des raisons sérieuses, voir http://wiki.fresco.org/index.cgi/NameChangeDescription(...) (modérateurs< il ne serait pas inutile de rajouter ça dans les URLs). Les raisons sont tout à fait valables et cohérentes, pour un projet qui se veut quelque chose de novateur et qui veut faire la bonne chose - même si je ne suis pas forcément d'accord sur les erreurs de conception, au moins les fondements me semblent bons.
Une tentative d'explication simple: as-tu essayé de trainer sur #berlin (OpenProjects à l'époque) une journée ou deux ? Le nombre de personnes confondant avec la ville de Berlin, demandant le rapport avec Berlin, critiquant le nom pour l'ambiguïté qu'il apporte était assez hallucinant, alors même que chaque utilisateur se faisait informer par ChanServ que ce channel était à propos du projet Berlin, et non de la ville de Berlin. Et à ma connaissance, les développeurs de Berlin en avaient _vraiment_ _vraiment_ marre, et on les comprend :-) Et puis, Fresco était un nom sympa.
Mais Fresco n'était pas l'ancien nom de Berlin. Fresco était un système dont a hérité Berlin.
Bon, pour ma part, si je trouve Berlin assez intéressant, il ne représente pas un idéal concernant le système de fenêtrage: je suis pour un nouveau WS tirant réellement partie d'une transparence réseau et d'IPC fournie par le système, ainsi qu'au niveau des drivers, une possibilité de gérer plus efficacement et de façon plus propre, quitte à sacrifier la portabilité - je souhaite avant tout avoir quelque chose fait correctement, de façon optimale, où la portabilité ne représente pas une contrainte limitant la qualité de la production, mais un plus si possible. De nombreuses recherches ont été faites là-dessus (on pense notamment à Nemesis[1], ou à Halo[2] et le système Angel[3], qui sont tous deux des systèmes très intéressants, bien que SAS), ou bien sûr au système de fenêtrage de QNX, qui reste cependant très primitif, et dont on ne sait que très peu de choses :-(
Une requête de juge d'instruction (dans la mesure à la police judiciaire ne se mutine pas) a toutes ces qualités. C'est bien évidement pas lui qui va dire s'il y a faute ou non (du moins c'est pas son rôle). A mon sens l'organisme existe déjà existe déjà (attention, obtenir la nomination d'un juge d'instruction n'est pas si simple).
Oui, bien sûr, j'y avais pensé. Mais comme tu dis, obtenir la nomination du juge n'est pas si simple - il faut déjà avoir des éléments dans le dossier. Ce qui n'est pas évident du tout du tout. Je parlais ici d'un organisme de contrôle qui n'agirait pas dans le cas où il y'a déjà soupçon, mais de façon générale, et qui contrôlerait régulièrement certaines entreprises en leur demandant leurs sources, et en vérifiant avec les sources autres qu'ils connaissent - notamment les sources libres, auxquels ils ont libre accès. Il ne s'agit pas réellement d'un organisme ayant à voir avec une procédure judiciaire, mais d'un organisme de contrôle.
Cette question de la responsabilité du logiciel libre, bien que franchement hors-sujet, est intéressante. Pour autant que je sache, les logiciels libres comme les logiciels propriétaires ont dans leurs licences (si quelqu'un a déjà eu le courage de lire un EULA jusqu'au bout ..) une clause concernant le fait que l'auteur se détache de toute responsabilité concernant un quelconque effect néfaste lié à l'utilisation de ce programme. Si celà ne supprime pas le problème du vice caché, j'avoue que je ne vois pas trop le problème que celà pose, dans l'absolu: n'importe qui peut voir qu'il y'a un problème, étant donné que le source est ouvert: le défaut est apparent, vous en êtes pour votre pomme, et l'auteur est tranquille. Et quand bien même les juges en décideraient différemment, à quoi pourrait être condamné l'auteur? Dans mes souvenirs, c'est le distributeur qui serait condamné à rembourser l'achat. Bref, c'est beaucoup moins important dans ce cas que dans le cas du logiciel propriétaire. À mon avis, en cas d'homicide, soit on peut prouver que c'était volontaire, et dans ce cas, les assurances vont jouer plein pot (\o_ kikoo christian), soit s'il s'agit d'un bug quelconque, et au pire, si les juges décident que le client n'était pas en mesure de le voir étant donné sa qualité (s'il n'est pas professionnel de l'informatique), la compagnie serait condamnée à quoi, rembourser?
Bon, faudra que je relise le code civil à ce sujet, tout n'est pas très très clair.
Bon, c'est évidemment un point que je n'avais pas soulevé plus ou moins volontairement, parce qu'il est général, et pas spécifique aux jeux.
Bien entendu, c'est le principal problème que je vois avec cette technique. Je ne pense pas qu'il existe de solution viable, en fait, à part avoir un organisme extérieur de contrôle qui serait en droit de vérifier pour à peu près chaque jeu les violations de licence - mais ce serait assez improbable qu'un tel organisme se mette en place, tout du moins rapidement, dans la mesure où il faut que la loi lui donne autorité pour que les entreprises daignent lui donner sans lui vendre.
En attendant, la technique couramment adoptée est de watermarker les sources. Ceci peut être de façon suffisamment discrète pour que ce ne soit pas repéré, à certains endroits. Bon, bien sûr, s'il s'agit de faire un easter egg énorme, ça sert pas à grand chose, je pense pas que les autres compagnies qui seraient assez connes pour copier/coller fassent recette :-) Mais la solution reste d'une fiabilité limitée.
Ceci dit, tu mentionnes de façon intéressante le codec XVid, où le problème, une fois identifié et médiatisé, a été corrigé, puisque le code source du logiciel a été diffusé par la suite sous une licence libre. Comme quoi, au final, on arrive bien à correction de la violation. Mais, il est vrai que le problème majeur reste l'identification du problème - sauf si, comme Flash ou autres merdes, ils sont assez cons pour ne pas changer les symboles et juste linker statiquement. :-)
Je pense qu'a priori, avec un watermarkage (oh! que c'est un joli mot :) assez discret - un tableau de données quelconques, aussi abscon que possible, avec quelques valeurs inutiles - on peut même jouer avec un peu de chance sur un petit dépassement induit par la taille des mots si c'est pas portable, pour ne pas éveiller les soupçons dus aux tailles :-) - mais qu'on peut repérer en dehors, et en assez grand nombre (sans faire le même à chaque fois, sinon on est mort), c'est viable. (ça, c'était une phrase. heureusement que personne n'est obligé de prononcer ce que j'écris. déjà, le lire.. :-)
En gros, ça reste jusque là ma solution préférée, dans la mesure où je ne peux pas accepter comme solution d'avoir un logiciel propriétaire « en attendant ». Ensuite, à chacun ses choix, du moment qu'ils sont faits en connaissance de cause.
C'est pas top, c'est sur... mais ca fait quand meme avancer un peu le choses non ? vaut mieux que certains le fasse dans cet esprit là, plutot que de continuer à breveter la moindre ligne de code 'révolutionnaire' ?
Bien sûr, je n'ai jamais dit le contraire: la solution que je propose est d'ailleurs un peu fondée (et non pas basée, si un modérateur passe par là, baser est un terme uniquement militaire qui ne s'applique pas ici) sur cette constatation, et aussi sur l'idée que c'est pour beaucoup par ce genre de solutions qu'on pourra familiariser le grand public, voire certaines entreprises au Libre et à ses avantages, à ses raisons. Dans un certain milieu de gens n'ayant pas vraiment de connaissances informatiques, mais juste l'obligation d'utiliser « l'outil informatique » - pensons au milieu enseignant, ou chez les cadres sup' - les gens sont déjà plus ou moins familiarisés avec le problème du logiciel propriétaire, même si c'est principalement autour du monopole de Microsoft qu'ils voient les problèmes. Aussi, il est vrai que quelques soient les moyens employés pour arriver au Libre, ils sont bons - l'important, c'est de convaincre ensuite qu'en plus de donner des trucs bien, c'est nécessaire et qu'il *faut* le Libre.
Bon, pour reprendre dans le sujet, il faut avouer que les jeux posent un réel problème en ce qui concerne le Libre, et que même parmi les convaincus, il y'a divergence. Il n'est pas évident de déterminer ce qui doit être couvert par une licence libre et ce qui relève de l'oeuvre d'art, et non de l'idée, de la connaissance, où le problème du partage du savoir et les problématiques que Stallman explique bien dans sa sempiternelle conférence avec l'exemple de Xerox ne se posent plus. Il paraît clair que le moteur du jeu *doit* être couvert par une licence libre, de la même façon que les autres logiciels. En revanche, autour, le flou existe, car tout n'est pas toujours bien séparé.
Depuis quelques années dans le monde du logiciel libre, on voit proliférer des logiciels couverts par la GPL, produits par des entreprises ou des universités dont on sait que la liberté n'est pas la priorité. En dehors du facteur réputation - qui revêt à mon avis une importance considérable dans le monde du libre, et continuera à l'avoir, j'ai constaté qu'au final, pas mal de ces gens pas franchement convaincus et intégristes du Libre choisissent cette licence pour son « copyleft » (je ne me risquerai à aucune traduction).
En effet, les objectifs sont les suivants: nous voulons avoir notre moteur libre - que ce soit pour la réputation, les avantages liés au développement, debugging, etc., ou parce qu'on est convaincu du libre (let's hope!) - mais nous voulons cependant le vendre à la concurrence, et qu'elle ne puisse pas le reprendre dans son jeu sans rien payer, et en faisant des modifications, etc. Et l'idée est: puisque le libre fait peur, et que la majorité des concurrents ne veulent pas dévoiler leurs sources, et encore moins les modifications qu'ils ont faites, on va passer le moteur sous licence GPL, comme ça les gens qui font des jeux libres pourront réutiliser le moteur, mais on pourra aussi réutiliser leurs modifications pour notre moteur, et les concurrents, qui veulent faire un jeu, eux, non-libre, ne voudront pas du moteur sous licence GPL, parce qu'il les obligerait à passer le leur sous cette licence - copyleft oblige. Et les créateurs du moteur étant les détenteurs du copyright, ils peuvent changer la licence: et donc, redistribuer le soft sous une licence autre, libre ou non, mais en tous cas non-copyleftée, "for a fee".
Je ne connais pas bien le monde du jeu - pas autat que kwyxz pour sûr - mais je sais que ce modèle là a été déjà adopté dans d'autres domaines: L4Ka, par exemple, l'utilise pour Hazelnut, et l'utilisera probablement pour Pistachio - http://www.l4ka.org(...)
Bon, encore une fois, IANAL, et je connais peu ce monde à part. Il doit y'avoir des failles. Je serais curieux de voir ce que des gens qui connaissent bien, kwyxz inclus, en pensent.
J'ai choisi de me moquer, parce qu'il y a franchement de quoi rire :)
PLONK. Vous venez d'entrer dans la liste des personnes à qui je dois foutre une bonne claque la prochaine fois que je les croise.
Et quand ont sait que ce cher RMS a fait chié le mainteneur de la libc pour qu'il dirige ses travaux vers cette espèce de jouet pour super geek qui n'est pas fait pour être en prod ni en 1.0 ni rien depuis plus de 10 ans... ça fait rire jaune. Mais bon, The RMS il forke pas la libc, il fait chier avec The Hurd.
PLONK. Vous venez de rejoindre Drepper dans ma liste de gens pratiquant le FUD à volonté, sauf qu'en plus, vous n'avez aucun élément pour savoir ce qui est vrai dans l'histoire, et ce qui ne l'est pas. Rappelons aussi que Ulrich Drepper n'est en aucun cas le maintainer de la GNU Libc toute entière, contrairement à ce qu'il croit être. Il est simplement, à la base, responsable du port Linux, ce qui est loin d'être la même chose. Et si RMS a pas mal de défauts, et notamment sur la façon dont il gère et pratique l'ingérance dans les projets GNU, Ulrich Drepper l'égale, si ce n'est le surpasse - crois-en l'expérience de quelqu'un ayant passé quelques jours à réparer les conneries de Drepper, pour qu'il affirme au bout que c'était moi qui les avait créées. Et à la base, il semble naturel que RMS demande au maintainer de la GNU C Library de se préoccuper de GNU, dans son ensemble, et pas seulement de le considérer comme la Linux C Library, comme il le fait _très_ souvent. Au fait, veux-tu qu'on compare l'état d'avancée de Linux 1.0 avec le Hurd de maintenant? Ça n'a à peu près rien à voir. On ne peut pas comparer "Waaa! Ce projet là, il en est à cinq versions de plus, il doit etre achtement achtement mieux!".
Dis, tu peux t'acheter un cerveau avant de revenir poster sur cette news s'il te plaît? Pour l'instant, non seulement
tu n'ajoutes aucune valeur aux commentaires présents - dont certains présentent plus d'intérêt que ce à quoi on pourrait s'attendre,
étant donné la nullité de l'article que la dépêche évoque - mais en plus, tu me mets les nerfs en pelote.
Si tu trouves que ça va pas assez vite, tu as plusieurs choix: 1) tu t'en fous, tu utilises autre chose, et tu te tais. 2) tu participes. En attendant..
Ok, donc, voila un screenshot avec mes boutons et des bordures assez epaisses.
Ok, je veux bien admettre que c'est _un peu_ épais. Rien de très flagrant, je trouve, et surtout, rien qui ne soit pas configurable, soit par l'application, soit par le thème, iirc. Donc..
Pour la zone de texte, je voyait pas les choses comme ca.
Je pensait plus a taper mon texte, et a pouvoir me deplacer a l'interieur comme je le fait avec ce commentaire que je tape.
en fait, mettre un retour chariot automatique, mais qui n'apparaisse pas dans les messages. C'est peut etre pas trés clair, mais, la ce commentaire, j'ai tout tapé sans appuyer sur entree. Pourtant Konqueror me met des retours a la ligne, et avec fleche haut, je remonte a la ligne du dessus.
OK, tu veux simplement du wrapping (ou de l'auto-fill, comme dirait mon Emacs. :). Bon, ça, c'est pas franchement lié à Gtk+, même pas du tout, c'est simplement un choix de Gaim. Si tu mattes 30s les sources, tu verras qu'il fait un:
gtk_text_set_word_wrap(GTK_TEXT(entry), TRUE);
et que donc tu vas avoir du wrapping pour les mots, mais pas pour les lignes. Un simple:
gtk_text_set_line_wrap(GTK_TEXT(entry), TRUE);
de plus changerait le comportement de ce point de vue. Mais encore une fois, il n'est pas dit que ça ne pose pas un problème quelconque à Gaim par la suite - je ne connais pas ce soft spécifique, à toi de demander aux auteurs (#gaim@freenode est très fréquenté).
Peut etre que Gtk2 le fait.
GtkText le faisait - bien heureusement! tu vois bien que tu peux le faire dans GEdit de Gnome 1, par exemple, donc, comme il s'agit du même widget tu peux le faire partout -, et, bien entendu, GtkTextView le fait - de façon même plus logique, puisque c'est géré via un enum, et puis, il est assez clair qu'il s'agit bien d'un changement de vue plutôt que de contenue, grâce à la séparation contents/view (GtkTextBuffer/GtkTextView).
En parlant de ca aussi, sur mon ordi, la molette de la souris tourne a l'envers sur les applis gtk ( 1.2 ).
Quand je roule vers l'avant, ben, Gimp ( par exemple ) me diminue la valeur du controle glissiere ( exemple selection rectangulaire , option, adoucir, le controle pour regler ca ).
Je t'assure que j'ai fait des efforts. J'ai demandé aux gens autour de moi, sur la tribune, sur IRC. Rien à faire, je ne comprends toujours pas ce que tu veux dire. Faudrait faire des efforts de clarté :)
Tu parle des gens qui utilisent des widgets non maintenus, mais, ca veut bien dire que les widgets d'avant étaient pourris.
Pourri, tout est relatif. Il me semble me souvenir qu'encore récemment, c'est à dire du Qt3, le widget texte de Qt était tout aussi pourri que celui de Gtk+1.2. Il y'a deux widgets qui n'assuraient vraiment pas dans Gtk+1.2, c'était GtkText, et GtkCList. GtkText parce qu'il était fait de façon très naïve, n'avait pas de bonnes performances, et ne supportait pas grand chose - ceci dit, il est à peine en dessous des widgets texte par défaut de la plupart des toolkits. d'ailleurs, beaucoup d'applications refont leur widget text quand ils veulent quelque chose de sympa. GtkCList parce qu'il avait pas mal de problèmes, qu'il était pas facile à utiliser, et un peu buggy - mais ça, ça se voyait pas trop. Ils n'étaient pas pour autant *pourris*.
Sachant que les problémes que j'ai soulevé sur gtk ont été réglés il y a longtemps dans qt, j'estime que qt avait quand même beaucoup d'avance sur gtk, qui , apparement, rattrape pas mal son retard.
Je n'ai pas sous la main les éléments de comparaison, mais, pour l'instant, tu ne fais qu'avancer sans prouver. Je ne suis pas persuadé que tout ce dont tu parles ait été fixé il y'a si longtemps dans Qt. Et, pour quelques uns, voire pas mal, des points que tu évoques, c'est lié à l'application, et vraiment pas à Gtk+.
Et avec un GtkListView, ou GtkTreeView, c'est par défaut, et à ma connaissance peu d'applis se gourrent. Y'a juste le Tree store dans gtk-demo où ça devrait pas être comme ça, mais ça n'est heureusement pas le cas partout, rien que dans MrProject ça ne l'est pas. Ces widgets sont décidément un vrai bonheur.
concernant les tonnes de bordures, j'ai pas utilisé de thémes particuliers.
et c'est vrai que j'ai pe exagéré la taille. mais, ca se voit mieux sur un petit ecran...
Franchement, même sur le thème par défaut, je ne vois pas ce que tu veux dire. Un screenshot serait bienvenu. Et pourtant il m'est arrivé de regarder - pas longtemps, je vous avoue :-) - un 14", avec des applications Gtk+, et ça ne m'a pas frappé *du tout*.
en fait, c'est le principe, c'est le gaspillage d'une 10aine de pixels.
je sais qu un théme peut améliorer ca. Sauf que , ca devrait etre bien par défaut.
Si tu veux, je ne vois pas où c'est comme ça, mais bon. De toutes façons, ça n'est pas réellement lié à Gtk+ mais à un thème par défaut. Si tu arrives à réellement identifier le problème, tu peux peut-être faire une wishlist - le bugreport est assez aisé avec Gnome/Gtk+, via bug-buddy.
Bien sur, si on veut faire mieux, on peut le faire. Tu est en train de me dire que on peut utiliser d'autres widgets plus puissants et voila ?
Euuh? Je suis en train de te dire qu'on peut utiliser la dernière version de Gtkl+, et que parler de Gtk+1.2, qui date quand même assez, ne sert plus à grand chose maintenant: il faut juste inciter les développeurs d'application à porter leurs apps vers Gtk+2. De toutes façons, ce port est vraiment agréable à faire et rend les choses plus claires, sans compter que les nouveaux widgets sont un bonheur à utiliser (en tant que programmeur comme en tant qu'utilisateur, cf. le widget texte et les list/trees).
Ben oui, mais par défaut ce n'est pas le cas.
Ben, si. Au cas particulier des sépérations, c'est le cas par défaut avec Gtk+2. Pour les boutons, je peux pas te répondre, je ne vois réellement pas de quoi tu parles. Pour les listes, pareil, ceux qui choisissent d'utiliser un widget qui n'est plus maintenu et qui disparaitra avec le temps, quand on estimera que les applications majeures sont passées aux nouveaux widgets.
Un autre exemple , gaim.
la zone de texte est en fait un controle sur une ligne...
donc, fleche haut ne remonte pas...
Bon, je viens d'installer le dernier gaim, pour voir. J'imagine que tu parles de la zone de texte dans la boîte conversation (i.e., celle que tu obtiens après avoir fait New Instant Message et entré le screenname de ton interlocuteur). Bon, mais je ne comprends pas beaucoup mieux ce que tu veux dire. Ils ont mis des callbacks sur activate et sur keypress_event, de telle façon qu'un « Entrée » envoie le message. Donc, ça ne peut être que sur une ligne, hein? Ah, quoique. Je sais pas si c'est voulu, mais je peux envoyer des messages de plusieurs lignes en tapant ^M (C-m) au lieu de Entrée, et donc, ensuite, je peux remonter, redescendre, avec les flèches du haut/bas, etc.
C'est parce que le logiciel est mal fait ?
Euh, à vue de nez, je pense que c'est parce qu'il s'agit d'IM et qu'ils veulent des messages courts. Je sais pas dans quelle mesure le protocole utilisé change quelque chose, peut-être même que (\r)\n est se séparateur, who knows.
Qu'est ce qu'une zone de texte a une ligne si ce n'est un controle multiligne d'une seule ligne ?
Uh? Alors là, je te suis pas du tout. Vazy, explique ce que tu voudrais que ça fasse et que ça ne fait pas actuellement, parce que je comprends vraiment pas.
Ca devrait etre plus cohérent au niveau de la bibli.
Je doute que la bibliothèque ait quoi que ce soit à voir avec ça. (hmm, d'autant plus que Gaim est pour Gtk+1.2, et utilise GtkText).
Et pour le coté non graphique de la boite de dialogue, c'est vrai que c'est bien mieux, mais c'est pour Gnome, donc a comparer avec celle de KDE, qui offre plus d'options...
Pas seulement, non. Ce sera changé aussi dans Gtk+, très probablement.
Bon, je réponds rapidement, et je précise avant que j'utilise comme thème Gtk+2 est ThinBright2, et Gtk+1.2 une variation de Funklor qui est en fait ThinBright2 pour Gtk+1.2.
Hé béh, faut que je dorme. Je cherche encore la logique de la phrase. Donc, je disais: « Bon, je réponds rapidement, et je précise avant que j'utilise comme thème Gtk+2 ThinBright2, et comme thème Gtk+1.2 une variation de Funklor qui correspond à l'équivalent de ThinBright2 pour Gtk+1.2 (qui utilises tous deux le theme engine thinice, qui roxoraïze). » Voilà voilà. Comme quoi, jamais faire de comment avant 3h du matin, et sans la dose d'alcool requise.
Bon, je réponds rapidement, et je précise avant que j'utilise comme thème Gtk+2 est ThinBright2, et Gtk+1.2 une variation de Funklor qui est en fait ThinBright2 pour Gtk+1.2.
prenons le dialogue pour enregister un fichier. dés qu'on change de repertoire, pouf le nom du fichier disparait.
Charmant, non ?
Gnii? Peux-tu expliciter ? Là, je vais dans mon menu Galeon (1.2.6, et c'est pareil avec sylpheed), j'ai comments_reply,10264,147999,1.html (le nom de la page, donc), dans le buffer, et si je clique sur un répertoire, il va dans ce répertoire conserve bien le nom du fichier dans la zone de texte. Tout ça en Sid, donc Gtk+ 1.2.10. Bien entendu, il va sans dire que le comportement est le même avec Gtk+ 2. Donc, je vois pas.
ensuite, que quelqu'un vienne me dire que c'est utile de mettre des kilometres de bordures autour des boutons...
Euuh, là, je te suis pas. C'est peut-être lié à ton thème, remarque. Auquel cas ça n'a pas grand chose à voir avec Gtk+, donc bon..
toujours dans la meme veine, le séparateur entre deux zones redimensionnables.
le truc ou il y a une zone minuscule pour faire glisser le separateur ( je sais, ca depends du theme ). ben, c'est nulle. sous qt, tu clique n'importe ou sur la barre et c'est bon ca glisse.
Bon, là, mon Sylpheed confirme effectivement que c'est vrai. Ceci dit, mon pan et mon gedit utilisant Gtk+2 me montrer que cela a été changé dans Gtk+2. Donc, il ne reste plus qu'à inciter les gens à passer leurs applications en Gtk+1.2. C'est sur la voie avec pas mal d'applis majeures, du genre Galeon.
on peut cliquer sur les boutons au dessu des listes, masi il ne se apsse rien. pour alors autoriser le click ? c'est ce qu'on appelle un mauvais feedback. On a l'impression que ca fait quelque chose, masi ca fait rien. Et le bouton passe en surbrillance quand on passe dessus, donnait l'impression qu'une action est possible...
Il s'agit d'une des erreurs de GtkCList. Ce widget est deprecated dans Gtk+2, mais encore utilisé par quelques applications qui en faisaient un usage intensif, et qui ne sont pas encore passées au nouveau widget, qui est incomparablement plus puissant, et considérablement mieux fait - mais peut-être un peu plus difficile d'accès. Bref, fixed.
voila, tout cela n'existe pas dans qt.
Si tu compares avec le dernier Qt, compare le dernier Gtk+. Et là, comme tu vois plus haut, ce que tu dis n'est plus valide.
pour moi, tant que gtk aura ces problémes, qt sera mieux. ( pour moi )
Parfait! Gtk+ est donc au moins aussi bien, là. (je ne joue qu'à ton propre jeu, en ne considérant pas le reste)
Moi, je le vois dans « Dépêches de seconde page », même si un court extrait est disponible en première page. Ceci dit, il était peut être en première page au moment du comment.
Ces deux logiciels sont d'ailleurs présentés par GnuWin II.
Une petite remarque, et elle est de taille: on parlait de logiciels libres. Si 7-Zip l'est (LGPL), Gsview ne l'est malheureusement pas:
NB: Je ne répondrai pas au premier commentaire que je trouve effectivement très con. Il ne faut pas confondre non plus mauvaise foi et difficultés d'argumentation claire et d'expression précise. Kilobug est de bonne fois: sinon, il ne se documenterait pas sur G++, les subtilités du C++, pour son boulot, et se contenterait de faire de la merde en disant « de toutes façons, c'est pas de ma faute, c'est du C++ ».
Quant au cours sur le TLB flush etc. (qui n'en était pas un, c'était extrêmement bref et récapiulatif), c'était simplement pour remettre les choses au clair, avec toi et les autres lecteurs ici. Et bien s'assurer qu'on parle de la même chose: tu emploies parfois des termes assez bizarres, et j'avoue que j'ai parfois été tenté d'aller chercher le de-yoda-ifier.
J'aime d'ailleurs cet article car il indique explicitement que la technique en question peut être portée sous Linux monolithique et permet d'avoir les mêmes performances. Comme par hasard, kilobug et toi ne mentionnez pas ce fait. Mauvaise foi ?
Non. C'est d'ailleurs assez étrange, parce que nous en parlions justement y'a pas plus d'une heure (devant une pizza :-p) avec Kilobug, et nous ne savions pourquoi l'astuce du 2^52 sur PPC n'était pas utilisée par Linux sur cette architecture, car elle est très simple à réaliser. Mais, je ne pensais pas, et je ne pense toujours pas, que ça ait eu un intérêt dans l'optique de notre conversation et pour ce que je voulais montrer.
Effectivement les noyaux monolithiques pourraient l'utiliser, mais ça n'empêche que les systèmes à base de micro-noyaux peuvent ne pas être moins performant, notamment grâce à cette technique. Attention à ne pas rentrer dans la simplification schématique: 1) les systèmes µk-based sont moins rapides avant 2) on améliore les performances des deux => les systèmes µk-based sont toujours moins rapides comparativement. Si par exemple les systèmes µk-based étaient simplement plus lents à cause des cont-sw, et qu'on supprimait les cont-sw, ça mettrait les deux systèmes sur un pied d'égalité a priori. Pas plus.
Quelques explications sur mon délire de noyau. Quand je parle de passer en mode noyau, je veux bien sûr parler de changement de privilège. Quand j'ai dit "dans le noyau", je voulais dire un accès à un des services externes au noyau (dans le cadre des µ-noyaux). Oui, je sais, ça peut paraître délirant, mais bon, je ne suis pas toujours très clair.
Je ne sais pas si c'est la fatigue ou la guinness, mais je ne comprends toujours pas mieux ce que tu veux dire, et tu as fait lamentablement segfaulter mon de-yoda-ifier.
Enfin, tu réponds à des choses qui ne sont pas de moi (genre bench neutre)
Effectivement, je n'aime pas faire de multiples commentaires juste pour le plaisir, je préfère tout grouper. Peut-être à tort, puisque ça a l'air d'en effrayer certains. Il est vrai que mon style n'est de loin pas des meilleurs.
sans expliquer pourquoi il y aurait moins de lock dans un système à µ-noyaux que dans un système monolithique.
Uh? C'est quand même un peu évident. Plus tu as une grosse application avec plein de trucs qui s'effectuent en même temps, s'agissant en plus d'un noyau avec des interrupt handlers, des possibilités d'être reveillé d'un peu partout, et tout ça, plus tu vas avoir besoin de locks, et de complications pour éviter que toutes les pièces se marchent dessus. Tous ces locks ne sont pas justifiés lorsqu'il s'agit de tâches différentes. (bien sûr, il y'a toujours besoin de locks, sur des container et autres, mais ça n'a rien à voir, et ce ne sont pas des big global locks manipulés plus que fréquemment)
Pour les longs commentaires, euh, je les tape dans mon galeon, ou dans mon emacs puis je les copie dans mon galeon. GNU Emacs + Galeon, le couple gagnant ! ;P
Et dire que j'ai cru un instant qu'il savait vraiment de quoi il parlait...
Il sait parfaitement de quoi il parle. Et ses goûts quant aux langages n'ont rien à voir avec ses connaissances techniques, qui concernant les micro-noyaux sont plus importantes que n'importe qui ici (pitet sauf moi, parce que c'est quand même moi qui l'ai convaincu ..). Les attaques personnelles de ce type sont plus que malsaines, elles m'écoeurent profondément.
J'ai relu tous les posts de Gaël ici (deux avis valent mieux qu'un), et je peux t'assurer qu'il n'est pas le seul qui aurait répondu comme ça. Peut-être effectivement est-ce dû à une mauvaise expression de ta part. Pour autant que je sache,
J'ai lu les docs L4 (avant de poster). Pour faire un IPC, on passe le thread en mode noyau (j'ai pas dit DANS LE NOYAU, j'ai dit en MODE NOYAU), exactement comme pour faire un appel système.
est un non-sens complet. On ne passe pas le thread en mode noyau. D'ailleurs, une définition correcte et assez précise du sens noyau, qui est la mienne (et ensuite celle de Kilobug), est qu'il consiste en tout ce qui tourne en mode « noyau ». On passe effectivement en mode noyau (instruction iret), mais tu changes pas les permissions d'un thread comme ça, hop. Il s'agit d'un CALL/SYSENTER (« inter-privilege-level far call », disent les docs Intel), puis d'un IRET/SYSEXIT. Effectivement, l'IPC entre tâches différentes se fait via un appel système avec L4 (et avec tout micro-noyau, en tous cas sur les architectures récentes et que je connais, avec MMU), il y'a donc le coût du changement de « privilege level » (relativement important sur un PIV, il faut l'avouer).
comment un IPC peut coûter moins cher qu'un appel système alors que l'IPC ajoute des instructions par rapport à l'appel système (on est d'accord, il y a très peu d'instructions en plus).
Si tu compares le nombre d'instructions, tu as en théorie raison. Cependant, ce que Kilobug t'a fait remarquer est que les mêmes instructions, les mêmes accès, faits dans des contextes différents n'a pas *du tout* le même poids. Le noyau est un énorme programme extrêmement complexe, où on doit lock'er de partout, etc. Le poids de ces locks est déjà un poids supplémentaire. L'empreinte sur le cache, étant donné que l'application est plus grosse, fait plus de choses, etc., est aussi considérablement plus importante. D'où encore pertes de performance. Or, il s'agit là d'un des facteurs *essentiels* vis-à-vis de ces dites performances. (Ceci dit, quand il s'agit du Hurd, on ne peut pas vraiment comparer, puisque le open() ne fait rien de comparable à ce que fait le open() de Linux.)
N'oublie pas qu'il s'agit de performances. On ne peut pas avoir une comparaison directe, fiable à 100%, manichéenne quand il s'agit de performances. Tel critère peut représenter une perte de performances, mais tel autre peut également, selon la façon dont s'est fait, selon les cas, etc., le compenser, voire plus. C'est pour ces raisons que Gaël a cité un certains nombres de choses qui peuvent te paraitre hors-sujet, mais qui pourtant ont un rôle prédominant quant aux performances. J'en profite d'ailleurs pour répondre à bknight, qui disait:
Le reste du débat micro noyau/monolithique m'apparaît de plus en plus comme une question de point de vue personnel. J'attends toujours un bench complètement neutre sur la chose.
La chose me paraît impossible. On ne peut pas faire des benchmarks sur des théories. Je peux te trouver des systèmes à base de micro-noyaux plus rapides que d'autres à base de noyaux monolithiques, et vice-versa. Il n'y a pas de bench parfait: même un bench du même code tournant sur un micro-noyau et sur un noyau monolithique serait absurde, parce que le code ne serait pas optimisé pour l'un ou l'autre (et d'ailleurs, par nature plutôt pour le second, puisqu'il s'agirait d'un serveur monolithique). C'est pour cela qu'il faut prendre les bench de L4Linux avec des pincettes. Et se souvenir que dans biens des cas MkLinux - « pendant » de L4Linux sur Mach - est bien souvent (tout le temps?) moins performant que le Hurd sur L4.
Les performances sont à traiter au cas par cas. Il semble logique, dans le cas d'un open(), qu'au final le coût soit à peu près le même: les pertes toutes relatives dues à l'IPC sont compensées par une moindre pollution des lignes de cache, etc. En revanche, dans le cas d'un write () où d'un appel plus complexe, l'utilisation de µk peut permettre d'utiliser des techniques plus performantes. Mais le µk en lui-même ne rendra pas les choses plus rapides, encore faut-il l'utiliser. C'est aussi pour ça que le Hurd est nouveau: certes les systèmes à base de micro-noyau ne sont pas nouveaux, mais aucun, sorti du domaine de la recherche, n'en tirait parti comme le Hurd, à ma connaissance, et encore moins comme il le fera quand le port sur L4 sera terminé.
Une petite remarque de forme. C'est gentil de toujours faire référence aux papiers sur L4, mais bon, je ne connais pas beaucoup de chercheurs qui crachent dans leur propre soupe.
Effectivement, cela est vrai. Mais il n'empêche que ce qu'il présente, ce sont avant tout des *faits*. Et à moins que tu me montres qu'ils sont faux, infondés, ou que sais-je, ce sont la base d'arguments valides. De même que je ne connais pas de papiers qui proposent des contre-arguments à L4, ou qui montrent que c'est faux, que c'est forcément plus lent avec L4. Le seul qui m'ait dit ça, c'est Rik (Van Riel), et bizarrement, il a toujours quelque chose de très urgent à faire dès qu'il s'agit de me montrer en quoi.
Mais qu'est-ce que tu racontes ? Comment fais tu un ipc sûr sans passer en mode noyau ?
Là, je voudrais nuancer légèrement. Tu ne peux pas faire d'IPC sûr sans passer par le mode noyau, effectivement, si on garde à l'esprit que IPC = « Inter Process Task ». En revanche, tu peux faire des RPCs locales, i.e., entre threads d'un même groupe, d'une même tâche, sans passer par le mode noyau. (et oui, c'est utile, je vous prie de se referrer au début et à l'ensemble de http://www.l4ka.org/publications/files/lazy-process-switching.ps(...) (oh! mon Dieu, encore une référence aux docs L4! Mais ce gars n'y connait rien! sauf que ce gars échange avec Horst Wenske (mais malheureusement pas avec le regretté Jochen Liedtke :-( ))). Ça s'appelle LIPC, et ça fait partie des services qu'un noyau et qu'un système d'exploitations peuvent fournir pour permettre d'avoir un ensemble plus rapide.
Euh, c'est une question piège ? Disons, un RPC ? Le problème, c'est que sauf erreur de ma part, ça fait un changement de contexte et que ça coute des ressources (par exemple tu dois avoir un risque de niquer le cache).
<tribune>Pas du tout, efface.</tribune> Cela fait un changement de contexte dans quelques cas très particuliers. Enfin, soyons clair. Cela fait un changement de contexte dans tous les cas: on change de tâche, on modifie deux/trois trucs. Mais c'est une hyperbole que dire que c'est peu coûteux. De plus, le cache primaire est indexé physiquement, donc cela ne coûte encore une fois que quelques cycles. Les coûts sont donc liés à, comme tu le dis, au « cache » (« niquer le cache », expression qui me plait décidément beaucoup). Plus exactement, au TLB. Liedtke décrit des mécanismes pour PowerPC et pour x86. L'idée pour x86 est assez simple: sur les 4GO d'espaces d'adressage, les tâches qui ne requièrent pas un espace d'adressage phénoménal (i.e., <500MB, si mes souvenirs sont bons, mais cela a pu changer et est peu ou pas décrit par Intel), donc la vaste majorité des tâches (en fait, toutes sauf 1 ou 2 sur la plupart des systèmes), n'ont pas accès aux 3GO d'address space normaux, mais seulement à une petite partie, de 500MB. Or il est tout à fait possible de multiplexer, de partager ces petits espaces d'adressages entre les gros, de 4GO. Dans la plupart des cas, un « changement de contexte » se fait entre deux tâches occupant des petits espaces d'adressage. Il n'y a donc pas de réel changement de page table, donc pas de TLB flush, donc pas un « réel » changement de contextes. En revanche, il est vrai que dans les cas où une petite tâche va faire une RPC à une tâche disposant d'un gros espace d'adressage n'étant pas celui en cours, ou encore dans le cas de communication entre « grosses » tâches, un TLB flush va être nécessité. Mais l'économie par rapport au context switch sur Linux, ou plein d'autres systèmes - Windows NT, pour autant que je sache - est monstrueuse. Pour PowerPC, c'est encore plus simple, et pour le coup il n'y a plus du tout de TLB flush, puisqu'il est très facile d'avoir un address space de 2^52 bytes, et donc d'« émuler » une TLB taggée sans ses inconvénients.
Tout ça pour dire que aujourd'hui je pense qu'aucun système à micro-noyau n'est aussi performant qu'un système "monolithique".
Ça ne veut pas dire grand chose, tu t'en rends compte ? GNU/Hurd est probablement plus rapide que certains systèmes d'exploitation basés sur des noyaux monolithiques. Qu'en revanche il n'existe pas de systèmes d'exploitation aussi versatile que GNU/Linux basé sur un micro-noyau qui soit aussi rapide que ce dernier, je te l'accorde. Mais encore une fois, ça ne constitue pas du tout une preuve. Il n'existe pas à ma connaissance de raisons pour lesquelles ça ne serait pas possible, et il existe même des raisons de penser qu'on pourrait faire un système d'exploitation à base de micro-noyau plus rapide. Si je n'en étais pas persuadé, je ne travaillerais pas sur le port du Hurd sur L4.
Pour finir, j'aimerais revenir sur le commentaire auquel je réponds directement. Je ne sais pas ce que tu essayais de prouver en rappelant les positions de Kilobug sur un tout autre sujet, à savoir le C vs. le C++. Je connais bien Kilobug, mieux que quiconque ici (et que la plupart ailleurs), et je suis d'ailleurs d'accord avec lui sur ce point: le C++ n'est pas un langage que j'aime, et je le trouve absolument dégueulasse. Est-ce que pour autant on doit m'enlever le droit de m'exprimer ? Est-ce que ça m'enlève tout crédit pour parler d'autre chose, et même de ça ? D'autant plus que Kilobug fait du C++ tous les jours (ach, 3j/sem maintenant), et que donc il ne parle pas sans savoir. Il est même probablement plus renseigné dessus que beaucoup de monde ici, puisqu'il lit énormément et est de bonne volonté à ce sujet. Bref, je trouve ces méthodes digne des plus grands boulets, des plus infâmes, que l'on peut malheureusement rencontrer sur DLFP. Plus que de casser la crédibilité de Kilobug, c'est la tienne que tu viens de casser à mes yeux et aux yeux de nombre d'autres.
Ceci dit, le débat purement technique sur les micro-noyaux m'intéresse, et je pense être pas trop mal renseigné sur le sujet. Donc, puisque cette news n'est plus depuis longtemps en page principale, je vous invite, tous, et en particulier toi et bknight (et puis jjb<, s'il veut :-), à continuer la discussion sur une ML, et même devant une guinness si vous habitez dans la région parisienne (oui, oui, un lait fraise pour kilobug :-).
Si, il l'est. D'abord, des crashes, ça arrive pour toutes les applications. Si par exemple il s'agit du serveur de fichiers servant pour une partition non-essentielle, comme /com, ou que sais-je, je pense qu'un administrateur système va préférer avoir un "down time" de /com qu'un down time général du serveur. Ne penses-tu pas ?
Ensuite, je te rappelle que ce ne sont pas que des parties essentielles qui se trouvent dans le noyau. Par exemple, le montage NFS du pauvre petit utilisateur à qui on a permis de se monter une partoche via NFS (déjà qu'il a fallu qu'il demande à root, parce qu'évidemment seul root peut faire ça, et à raison en ce qui concerne les systèmes à noyau monolithique[1]) doit-il permettre de faire tomber l'ensemble du système ? Je ne le pense *vraiment* pas.
Même chose pour un serveur essentiel pour fournir les tâches imparties à la box, mais pas essentiel au système, comme par exemple, la pile TCP/IP. Je sais pas pour vous, mais j'en ai quand même vu crasher après un slashdottage. D'ailleurs, c'est bien la pile TCP/IP de Linux 2.2.14, qui est la base de pfinet actuellement (en cours de redesign) qui avait crashé plusieurs fois lors d'un /.age d'un serveur web sous GNU/Hurd (et c'était, on l'a découvert ensuite, bien lié à un bug de cette pile, qui a été rapporté par la suite). La différence étant que sur un système basé sur un noyau monolithique, ça veut dire plantage général et redémarrage (donc downtime assez important), alors que sous GNU/Hurd, ça veut dire pile TCP/IP qui crashe et qui est redémarrée automatiquement dans la seconde qui suit. (donc, des conséquences mais bien moins importantes)
Pour prendre l'analogie avec la sécurité, le Hurd ne prétend pas résoudre les problèmes de sécurité. Il prétend fournir des mécanismes de sécurité qui permettent aux développeurs de minimiser les conséquences de tels problèmes[2]. De même, il ne prétend pas résoudre tous les problèmes de stabilité. Mais, partant du principe qu'a priori, un programme a toujours des bugs potentiels, surtout lorsqu'il s'agit de programmes relativement complexes comme ceux s'occupent d'un système de fichier, il prétend minimiser les conséquences de tels plantages.
Enfin, pour avoir suivi le développement de Linux depuis assez longtemps, et avoir eu moi-même quelques expériences avec, je sais que les bugs sont loin d'être tout le temps dans la partie où ils apparaissent. S'il est vrai qu'il a été nécessaire de « cloisonner » Linux, comme le disait JJB (encore un pote à JJB!), créer un énorme logiciel qui contient des tas de parties différentes amène naturellement plus de risques de se planter, en ne connaissant pas bien ce que fait telle autre partie, en se gourrant sur un lock, ou que sais-je. De plus, une inversion de paramètres est vite arrivé, et si les changement dans les interfaces externes de Linux sont déjà fréquents, les changements dans les interfaces internes sont plus que monnaie courante, causant donc de nouveaux problèmes potentiels. Comme le disait JJB, si Linux tient, c'est par le plus grand des miracles, et quelques fois ça fait quand même badaboom. Entendez-moi bien, je ne critique pas non plus les « irresponsables » développeurs de Linux, etc. : une grande partie du miracle grâce auxquels ces sources tiennent s'appelle Alan Cox, Linus Torvalds, Rik Van Riel, Harald Welte, et autres personnes extrêmement douées du genre. Mais je persiste à croire que si ces ressources étaient mises à disposition d'un projet ne posant pas ces problèmes de bases, elles seraient mieux utilisées. (NB: et Harald est pas très loin de penser la même chose :-)
Au fait, de façon évidente, si ces « processus » (processi? processus? (4ème F/M) processa? (3ème neutre) (latin roxor (lisp aussi))) sont appelés serveurs, c'est par analogie avec le fameux modèle client-serveur (qui a dit buzzword?). Je tiens également à revenir sur la composition d'un noyau monolithique. En tant que fourre-tout officiel de tout ce qui n'est pas « bibliothéquisifiable » (j'adore ce mot. pas vous? ah bon[3]), il n'est pas évident de définir ce qu'il contient dans un système « Unix » (non, nous ne reprendrons pas le troll, j'ai déjà donné mon point de vue). Mais il ne contient certainement pas que des parties essentielles au système: il contiendrait plutôt tout ce qui doit être commun à toutes les applications et peut poser un quelconque de sécurité, ou que sais-je. Plus récemment, la manie a été d'intégrer dans le noyau tout ce qui peut se rapprocher du « bas-niveau » (PPPoE, etc.). Il est donc loin d'autant moins évident de garantir la stabilité de ces parties non-essentielles, et il me semble dément qu'ils puissent faire tomber l'ensemble du système. Enfin, vous me direz, ça ne s'applique pas forcément aux serveurs de production. Mais je crois que la stabilité n'intéresse pas que ces premiers.
[1]: mon expérience de ce genre d'explications m'a montré que ce point là était en général un des moins bien compris, et que la question « Et pourquoi on pourrait pas monter des trucs en user sur mon Unix? Moi je peux avec users dans le fstab ! ». Répondons directement. Oui, on le peut: via le setuid root. Je pense que rien que l'invocation de cette fonctionnalité devrait faire frémir tous ceux qui se sont un jour préoccupé de sécurité. :-)
Sous Unix, si on autorise tous les utilisateurs à effectuer l'appel système `mount', rien ne les empêche de créer une image d'un système de fichiers reconnu par le noyau contenant des programmes « setuid root » (justement!) qui seraient alors intégrés tels quels dans le VFS, sans distinction d'utilisateur avec les autres partitions (il n'y a pas ce genre de notions avec Unix), permettant ainsi à n'importe quel utilisateur de devenir root. Sous GNU/Hurd en revanche, le « serveur » s'occupant du système de fichier (on parle de « traducteur » ou « translator » pour le Hurd, en raison de ses spécificités) est une application _comme_ _les_ _autres_, qui tourne en mode utilisateur avec les droits de l'utilisateur qui l'a lancé. Il ne peut donc *rien* faire de plus que cet utilisateur. Tiré d'un document écrit par Marc, Kilobug et moi-même:
(jvous jure, l'idée de pinger hurdfr.org était de KB :-p)
Même si c'est franchement hors-sujet, j'espère que cela aura su répondre aux interrogations de certains. (et puis même si vous vous posiez pas la question, vous savez maintenant! :-)
[2]: Je tiens à citer Wolfgang Jährling, qui commençait son (excellente) conférence sur les mécanismes d'authentification du Hurd, dont un court résumé est disponible sur http://www.gnu.org/software/hurd/auth.html(...) , par un retentissant « security is just a bad hack ». En effet, n'oublions pas que la vraie réponse à la sécurité est de rendre les gens bons, de telle façon que tout le monde reporte les problèmes de sécurité sans jamais les utiliser à des fins malhonnêtes - et que personne n'ait même de buts qui ne soient pas louables! Mais malheureusement, cette tâche est quelque peu difficile à accomplir en écrivant des logiciels. Nous sommes donc condamnés à se limiter à ce bad hack qu'est la « sécurité » :-)
[3]: j'espère que les amateurs auront reconnu une fine allusion à Renaud, et pourront donc me dire de quelle chanson je parle :-p
Il ne faut pas confondre marque déposée et définition. Et ceux qui détiennent la marque ne sont pas forcément ceux qui sont les plus habilités à donner une définition scientifiquement juste, en général au contraire.
Effectivement, l'Open Group apporte un début de réponse via la Single Unix Specification et Unix 98, mais elle définit principalement des interfaces (les outils, des APIs, etc.), et donc ce qu'est être compatible Unix, et non ce qu'est être un Unix.
Je me fous un peu de savoir si les détenteurs de la marque décident d'appeler Unix, ça, ça, et ça. S'ils donnent des justifications scientifiques, OK. Sinon, ça n'est que leur opinion, et s'il venait que ça coïncide avec la vérité, ça ne serait qu'un hasard, et donc je ne m'y fie pas. (\o/ Bachelard)
Et effectivement, les éléments que tu donnes sont des éléments de compatibilité Unix. C'est à mon avis une définition faussée de Unix, comme il est en général absurde de désigner un objet par son utilité et par ce avec quoi il est compatible. C'est ce par quoi je commençais mes posts.
Cela dit l'usage courant du mot "UNIX" n'est pas celui défini par le spécification mais recouvre
Je suis tout à fait d'accord. Mais l'usage courant ne fait pas la définition correcte, simplement aussi parce qu'elle est floue et ne tient pas compte des subtilités des appellations: la majorité ne les connait pas. Donc, se fier à la majorité pour donner un sens serait nocif. Et effectivement, encore une fois c'est là une question de compatibilité, et pas de nature, et ça me semble dommage. Tu te souviens peut-être, « Il ne te demande pas ce qui est beau, mais ce qu'est le beau. »
Effectivement, il n'y a pas, comme je l'ai dit, de définition précise d'Unix "officielle", tout du moins à ma connaissance. Mais, la définition pourrait être: avoir un design proche (à quelques détails près, mais reste à donner la signification de détail dans ce contexte, je vous l'accorde) de ce que Pike & Kernighan décrivent dans leurs livres et publications sur le sujet. Je pense pas qu'il soit possible facilement d'établir une liste de critères suffisants pour désigner un système Unix, mais il y'a certainement moyen de donner une liste *non-exhaustive* de conditions nécessaires, et dans ce cas il ne fait aucun doute que la présence d'un noyau monolithique en fait partie: c'est quand même la base des bases du design d'un OS, le choix entre monolithique, µk, layered, vertically-structured, SAS, exo, .. :-)
L'appellation Unix peut en effet paraitre abusive dans la mesure où Unix a longtemps désigné seulement le Unix Time-Sharing System. Bien que malheureusement je ne retrouve plus cette citation de Pike, encore une fois (oui, une autre), il disait lui-même cependant que le système originel devrait être appelé the Unix Time-Sharing System (ou UTSS), alors que la famille d'OS à laquelle il a donné naissance, et une définition vague, devrait être appelé Unix. Quand Pike parle d'Unix, il désigne une catégorie générique avec un design commun: on le voit bien dans son papier sur Plan9.
Cette coutume d'appeler par le nom de l'original est probablement un abus de langage, mais elle est très courante, et plus spécialement en informatique. Ainsi, on parle de Mach pour la famille des µk Mach (qui n'ont qu'un design et des interfaces en commun), on parle de L4 pour la famille des µk qui répondent à l'API/ABI L4, comme on parle de frigidère pour les réfrigérateurs :-) Beaucoup de solutions au problème de l'appellation de ces systèmes sont employés, on voit notamment: Un*x, Unix-like. Auquel on devrait rajouter: Unix-compatible. Mais, le -like est très vague: on ne précise pas le degré de ressemblance.
Je sais bien comment ils ont implémenté ça sur Windows NT (je suis, quand même :-). Mais, le fait qu'elle fournisse une couche Unix (plus qu'une couche de compatibilité, j'entends bien) ne fait qu'augmenter la ressemblance avec Unix par rapport à un système comme GNU/Hurd, et ne le rend pas un système qu'on pourrait dire « Unix »: il ne répond pas à au moins un critère, que j'ai énoncé, qui est fondamental si on regarde n'importe quel schéma d'Unix.
Concernant POSIX, il me semble avoir été clair sur l'égalité: OS whatever qui implémente POSIX = OS POSIX-compliant. Avoir des interfaces communes en grande partie avec POSIX (je ne dis pas être POSIX-compliant: de vieux Unix, qui sont incontestablement des Unix, ne respectent que peu POSIX) est probablement un des critères pour être Unix-compatible. C'est même un degré de compatibilité Unix. Mais en aucun cas une condition suffisante pour être un Unix.
Non, je ne suis absolument pas d'accord. Et ça reste en contradiction avec ce que j'ai dit: ça ne reste que fournir une interface de compatibilité POSIX par dessus autre chose, que ce soit via la C Library, une autre bibliothèque, ou un serveur de compatibilité. Encore une fois, ça reste définir un système non pas par sa nature, mais par son utilité et ce avec quoi il est compatible, ce qui est fondamentalement absurde.
Des systèmes qui n'ont rien d'Unix, comme Win2K, Plan9, etc., et que tu n'appellerais probablement pas Unix fournissent une interface de compatibilité POSIX de façon très similaire à ce que fait MacOS X. Je te rappelle que le serveur BSD, c'est pas comme si c'était un noyau en user space, c'est juste de la compatibilité.
La présence d'un noyau monolithique *est* une condition nécessaire (mais en aucun cas suffisante) à l'appartenance d'un système au groupe Unix. Un système qui n'a pas ça peut au maximum être désigné par compatible Unix (ce qui n'est pas péjoratif, loin de là).
En revanche, si MacOS X était *basé* sur 4.4BSD (qui là, pour le coup, est clairement défini par Marshall Kirk McKusick dans The Design and Implementation of the 4.4 BSD Operating System, il serait un Unix. Mais ça n'est *pas* le cas.
1) Depuis toujours. On ne peut pas désigner tout système qui fournit une interface de compatibilité Unix (on dira plutôt, POSIX) et fait tourner certains outils originellement développés pour Unix un système Unix - on ne peut pas désigner des objets par leur utilité, mais par ce qu'ils sont.
Il n'y a malheureusement pas de définition claire d'Unix faite par Rob Pike, ou Kernighan, à ma connaissance: il est défini en tant que dérivé du Unix Time-Sharing System (ou UNICS, si vous voulez). Mais, que ce soit dans The Unix Programming Environment, écrit par Rob Pike et Brian Kernighan, ou dans Advanced Programming in the Unix Environment (Stevens), il y'a tout un paragraphe sur le design d'UNIX, qui ne parle *pas* du Unix Time-Sharing System particulièrement, puisqu'il évoque les différentes branches dérivées, et un, si ce n'est *le* point essentiel est bien le noyau monolithique.
Remarque aussi que Rob Pike a, après Unix, créé Plan9, qui fournit une interface de compatibilité avec le premier, de la même façon que GNU/Hurd ou que Darwin (OK, pour Darwin c'est un peu différent puisque c'est avec un serveur dédié, comme avec le Mach Operating System), et qu'il l'oppose bien à Unix dans tous ses papiers: http://plan9.bell-labs.com/sys/doc/9.html(...) par exemple. Il parle aussi, dans une célèbre citation que je ne retrouve plus, de combien Unix sucks et Plan9 apporte plus.
Et, c'est bizarre de ta part. Windows 2000 (peut-être XP, je n'en sais rien) fournit entre autres une compatibilité POSIX, non ? Pourtant il est très différent d'Unix, et tu ne le considères pas, je suis sûr, comme un Unix!
Pour finir, il faut voir quand même que les interfaces POSIX sont très liées au design d'Unix, et qu'il est souvent très difficile de les respecter dans les moindres détails la norme POSIX, pour des systèmes dont le design est différent. Je ne suis pas d'ailleurs persuadé qu'il existe réellement de systèmes non-Unix qui *puissent* respecter parfaitement POSIX (attention: je sais qu'il n'existe probablement pas d'Unix qui respecte POSIX. Mais, il faut distinguer la possibilité de le faire de la réalisation technique). Donc encore une fois, UNIX est extrêmement lié au design à base de noyau monolithique, même dans ses interfaces (qui sont loin d'être optimales, d'ailleurs.)
(NB: c'est assez drôle d'avoir cette discussion dans ce sens, puisqu'il y'a quelques temps, c'était Kilobug qui était à ta place concernant le 1, et qui considérait que l'acronyme GNU's Not Unix était plus une blague, ce qu'il n'est pas.)
3) Effectivement, j'aurais aimé avoir plus d'explications sur ce fait. Que NTFS ait beaucoup d'inconvénients, je suis d'accord. Mais, d'après tout ce que j'ai pu lire sur NTFS (et j'ai essayé de me documenter, même si j'aurais aimé trouvé le fameux <l>Inside the Windows NT File System</u>, car je me refuse d'acheter chez Microsoft Press :-p). Je trouve très fair play de ta part de ne pas avoir lancé un troll sur ce sujet, d'ailleurs, qui n'aurait évidemment pas rétabli la vérité, puisqu'il serait venu de ta part.
[^] # Re: Fresco, aka
Posté par Manuel Menal . En réponse à la dépêche Fresco, aka "The GUI formerly known as Berlin". Évalué à 3.
Je pense vraiment que c'est un argument n'en est pas un vrai. S'il est vrai qu'on peut préférer d'autres choix de design, le rejeter au nom de la BP purement et simplement est bête, et pas fondé. On ne peut pas reprocher au projet Fresco de ne pas avoir pensé à tous ces problèmes, de faire dans le vide, sans réfléchir. Il y'a un réel design dans le projet, des réels choix faits, qui se justifient et sont fondés en raison. Fresco est vraiment très intéressant à étudier, et si je ne me prononce pas quant à lui maintenant, c'est simplement parce que même en suivant le projet depuis longtemps, je ne pense pas avoir les connaissances nécessaires pour savoir s'il pourrait s'adapter et développer un un WS plus komjeve[tm], décrit sur http://linuxfr.org/comments/150869.html(...)
J'espère qu'en gars intelligent, tu essayeras aussi de te renseigner en profondeur.
[^] # Re: Fresco, heu c'était pas déjà Fresco avant ?
Posté par Manuel Menal . En réponse à la dépêche Fresco, aka "The GUI formerly known as Berlin". Évalué à 2.
Bon, pour revenir à des raisons sérieuses, voir http://wiki.fresco.org/index.cgi/NameChangeDescription(...) (modérateurs< il ne serait pas inutile de rajouter ça dans les URLs). Les raisons sont tout à fait valables et cohérentes, pour un projet qui se veut quelque chose de novateur et qui veut faire la bonne chose - même si je ne suis pas forcément d'accord sur les erreurs de conception, au moins les fondements me semblent bons.
[^] # Re: Fresco, heu c'était pas déjà Fresco avant ?
Posté par Manuel Menal . En réponse à la dépêche Fresco, aka "The GUI formerly known as Berlin". Évalué à 10.
Mais Fresco n'était pas l'ancien nom de Berlin. Fresco était un système dont a hérité Berlin.
Bon, pour ma part, si je trouve Berlin assez intéressant, il ne représente pas un idéal concernant le système de fenêtrage: je suis pour un nouveau WS tirant réellement partie d'une transparence réseau et d'IPC fournie par le système, ainsi qu'au niveau des drivers, une possibilité de gérer plus efficacement et de façon plus propre, quitte à sacrifier la portabilité - je souhaite avant tout avoir quelque chose fait correctement, de façon optimale, où la portabilité ne représente pas une contrainte limitant la qualité de la production, mais un plus si possible. De nombreuses recherches ont été faites là-dessus (on pense notamment à Nemesis[1], ou à Halo[2] et le système Angel[3], qui sont tous deux des systèmes très intéressants, bien que SAS), ou bien sûr au système de fenêtrage de QNX, qui reste cependant très primitif, et dont on ne sait que très peu de choses :-(
[1]: http://nemesis.sourceforge.net(...)
[2]: http://citeseer.nj.nec.com/81555.html(...)
[3]: http://citeseer.nj.nec.com/wilkinson92angel.html(...)
[^] # Re: Copyleft
Posté par Manuel Menal . En réponse à la dépêche L'ouverture des sources, l'avenir du jeu. Évalué à 1.
Oui, bien sûr, j'y avais pensé. Mais comme tu dis, obtenir la nomination du juge n'est pas si simple - il faut déjà avoir des éléments dans le dossier. Ce qui n'est pas évident du tout du tout. Je parlais ici d'un organisme de contrôle qui n'agirait pas dans le cas où il y'a déjà soupçon, mais de façon générale, et qui contrôlerait régulièrement certaines entreprises en leur demandant leurs sources, et en vérifiant avec les sources autres qu'ils connaissent - notamment les sources libres, auxquels ils ont libre accès. Il ne s'agit pas réellement d'un organisme ayant à voir avec une procédure judiciaire, mais d'un organisme de contrôle.
Cette question de la responsabilité du logiciel libre, bien que franchement hors-sujet, est intéressante. Pour autant que je sache, les logiciels libres comme les logiciels propriétaires ont dans leurs licences (si quelqu'un a déjà eu le courage de lire un EULA jusqu'au bout ..) une clause concernant le fait que l'auteur se détache de toute responsabilité concernant un quelconque effect néfaste lié à l'utilisation de ce programme. Si celà ne supprime pas le problème du vice caché, j'avoue que je ne vois pas trop le problème que celà pose, dans l'absolu: n'importe qui peut voir qu'il y'a un problème, étant donné que le source est ouvert: le défaut est apparent, vous en êtes pour votre pomme, et l'auteur est tranquille. Et quand bien même les juges en décideraient différemment, à quoi pourrait être condamné l'auteur? Dans mes souvenirs, c'est le distributeur qui serait condamné à rembourser l'achat. Bref, c'est beaucoup moins important dans ce cas que dans le cas du logiciel propriétaire. À mon avis, en cas d'homicide, soit on peut prouver que c'était volontaire, et dans ce cas, les assurances vont jouer plein pot (\o_ kikoo christian), soit s'il s'agit d'un bug quelconque, et au pire, si les juges décident que le client n'était pas en mesure de le voir étant donné sa qualité (s'il n'est pas professionnel de l'informatique), la compagnie serait condamnée à quoi, rembourser?
Bon, faudra que je relise le code civil à ce sujet, tout n'est pas très très clair.
[^] # Re: Copyleft
Posté par Manuel Menal . En réponse à la dépêche L'ouverture des sources, l'avenir du jeu. Évalué à 2.
Bien entendu, c'est le principal problème que je vois avec cette technique. Je ne pense pas qu'il existe de solution viable, en fait, à part avoir un organisme extérieur de contrôle qui serait en droit de vérifier pour à peu près chaque jeu les violations de licence - mais ce serait assez improbable qu'un tel organisme se mette en place, tout du moins rapidement, dans la mesure où il faut que la loi lui donne autorité pour que les entreprises daignent lui donner sans lui vendre.
En attendant, la technique couramment adoptée est de watermarker les sources. Ceci peut être de façon suffisamment discrète pour que ce ne soit pas repéré, à certains endroits. Bon, bien sûr, s'il s'agit de faire un easter egg énorme, ça sert pas à grand chose, je pense pas que les autres compagnies qui seraient assez connes pour copier/coller fassent recette :-) Mais la solution reste d'une fiabilité limitée.
Ceci dit, tu mentionnes de façon intéressante le codec XVid, où le problème, une fois identifié et médiatisé, a été corrigé, puisque le code source du logiciel a été diffusé par la suite sous une licence libre. Comme quoi, au final, on arrive bien à correction de la violation. Mais, il est vrai que le problème majeur reste l'identification du problème - sauf si, comme Flash ou autres merdes, ils sont assez cons pour ne pas changer les symboles et juste linker statiquement. :-)
Je pense qu'a priori, avec un watermarkage (oh! que c'est un joli mot :) assez discret - un tableau de données quelconques, aussi abscon que possible, avec quelques valeurs inutiles - on peut même jouer avec un peu de chance sur un petit dépassement induit par la taille des mots si c'est pas portable, pour ne pas éveiller les soupçons dus aux tailles :-) - mais qu'on peut repérer en dehors, et en assez grand nombre (sans faire le même à chaque fois, sinon on est mort), c'est viable. (ça, c'était une phrase. heureusement que personne n'est obligé de prononcer ce que j'écris. déjà, le lire.. :-)
En gros, ça reste jusque là ma solution préférée, dans la mesure où je ne peux pas accepter comme solution d'avoir un logiciel propriétaire « en attendant ». Ensuite, à chacun ses choix, du moment qu'ils sont faits en connaissance de cause.
[^] # Re: Copyleft
Posté par Manuel Menal . En réponse à la dépêche L'ouverture des sources, l'avenir du jeu. Évalué à 1.
Bien sûr, je n'ai jamais dit le contraire: la solution que je propose est d'ailleurs un peu fondée (et non pas basée, si un modérateur passe par là, baser est un terme uniquement militaire qui ne s'applique pas ici) sur cette constatation, et aussi sur l'idée que c'est pour beaucoup par ce genre de solutions qu'on pourra familiariser le grand public, voire certaines entreprises au Libre et à ses avantages, à ses raisons. Dans un certain milieu de gens n'ayant pas vraiment de connaissances informatiques, mais juste l'obligation d'utiliser « l'outil informatique » - pensons au milieu enseignant, ou chez les cadres sup' - les gens sont déjà plus ou moins familiarisés avec le problème du logiciel propriétaire, même si c'est principalement autour du monopole de Microsoft qu'ils voient les problèmes. Aussi, il est vrai que quelques soient les moyens employés pour arriver au Libre, ils sont bons - l'important, c'est de convaincre ensuite qu'en plus de donner des trucs bien, c'est nécessaire et qu'il *faut* le Libre.
Bon, pour reprendre dans le sujet, il faut avouer que les jeux posent un réel problème en ce qui concerne le Libre, et que même parmi les convaincus, il y'a divergence. Il n'est pas évident de déterminer ce qui doit être couvert par une licence libre et ce qui relève de l'oeuvre d'art, et non de l'idée, de la connaissance, où le problème du partage du savoir et les problématiques que Stallman explique bien dans sa sempiternelle conférence avec l'exemple de Xerox ne se posent plus. Il paraît clair que le moteur du jeu *doit* être couvert par une licence libre, de la même façon que les autres logiciels. En revanche, autour, le flou existe, car tout n'est pas toujours bien séparé.
# Copyleft
Posté par Manuel Menal . En réponse à la dépêche L'ouverture des sources, l'avenir du jeu. Évalué à 3.
En effet, les objectifs sont les suivants: nous voulons avoir notre moteur libre - que ce soit pour la réputation, les avantages liés au développement, debugging, etc., ou parce qu'on est convaincu du libre (let's hope!) - mais nous voulons cependant le vendre à la concurrence, et qu'elle ne puisse pas le reprendre dans son jeu sans rien payer, et en faisant des modifications, etc. Et l'idée est: puisque le libre fait peur, et que la majorité des concurrents ne veulent pas dévoiler leurs sources, et encore moins les modifications qu'ils ont faites, on va passer le moteur sous licence GPL, comme ça les gens qui font des jeux libres pourront réutiliser le moteur, mais on pourra aussi réutiliser leurs modifications pour notre moteur, et les concurrents, qui veulent faire un jeu, eux, non-libre, ne voudront pas du moteur sous licence GPL, parce qu'il les obligerait à passer le leur sous cette licence - copyleft oblige. Et les créateurs du moteur étant les détenteurs du copyright, ils peuvent changer la licence: et donc, redistribuer le soft sous une licence autre, libre ou non, mais en tous cas non-copyleftée, "for a fee".
Je ne connais pas bien le monde du jeu - pas autat que kwyxz pour sûr - mais je sais que ce modèle là a été déjà adopté dans d'autres domaines: L4Ka, par exemple, l'utilise pour Hazelnut, et l'utilisera probablement pour Pistachio - http://www.l4ka.org(...)
Bon, encore une fois, IANAL, et je connais peu ce monde à part. Il doit y'avoir des failles. Je serais curieux de voir ce que des gens qui connaissent bien, kwyxz inclus, en pensent.
[^] # Re: ATTENTION: Rectifications
Posté par Manuel Menal . En réponse à la dépêche Sortie de GNU OS retardée. Évalué à 5.
[^] # Re: ATTENTION: Rectifications
Posté par Manuel Menal . En réponse à la dépêche Sortie de GNU OS retardée. Évalué à 1.
PLONK. Vous venez d'entrer dans mon killfile.
J'ai choisi de me moquer, parce qu'il y a franchement de quoi rire :)
PLONK. Vous venez d'entrer dans la liste des personnes à qui je dois foutre une bonne claque la prochaine fois que je les croise.
Et quand ont sait que ce cher RMS a fait chié le mainteneur de la libc pour qu'il dirige ses travaux vers cette espèce de jouet pour super geek qui n'est pas fait pour être en prod ni en 1.0 ni rien depuis plus de 10 ans... ça fait rire jaune. Mais bon, The RMS il forke pas la libc, il fait chier avec The Hurd.
PLONK. Vous venez de rejoindre Drepper dans ma liste de gens pratiquant le FUD à volonté, sauf qu'en plus, vous n'avez aucun élément pour savoir ce qui est vrai dans l'histoire, et ce qui ne l'est pas. Rappelons aussi que Ulrich Drepper n'est en aucun cas le maintainer de la GNU Libc toute entière, contrairement à ce qu'il croit être. Il est simplement, à la base, responsable du port Linux, ce qui est loin d'être la même chose. Et si RMS a pas mal de défauts, et notamment sur la façon dont il gère et pratique l'ingérance dans les projets GNU, Ulrich Drepper l'égale, si ce n'est le surpasse - crois-en l'expérience de quelqu'un ayant passé quelques jours à réparer les conneries de Drepper, pour qu'il affirme au bout que c'était moi qui les avait créées. Et à la base, il semble naturel que RMS demande au maintainer de la GNU C Library de se préoccuper de GNU, dans son ensemble, et pas seulement de le considérer comme la Linux C Library, comme il le fait _très_ souvent. Au fait, veux-tu qu'on compare l'état d'avancée de Linux 1.0 avec le Hurd de maintenant? Ça n'a à peu près rien à voir. On ne peut pas comparer "Waaa! Ce projet là, il en est à cinq versions de plus, il doit etre achtement achtement mieux!".
Get a brain.
[^] # Re: ATTENTION: Rectifications
Posté par Manuel Menal . En réponse à la dépêche Sortie de GNU OS retardée. Évalué à 2.
tu n'ajoutes aucune valeur aux commentaires présents - dont certains présentent plus d'intérêt que ce à quoi on pourrait s'attendre,
étant donné la nullité de l'article que la dépêche évoque - mais en plus, tu me mets les nerfs en pelote.
Si tu trouves que ça va pas assez vite, tu as plusieurs choix: 1) tu t'en fous, tu utilises autre chose, et tu te tais. 2) tu participes. En attendant..
Merci d'avance, et -1 (virtuel).
[^] # Re: Ca compile c'est déjà ça ...
Posté par Manuel Menal . En réponse à la dépêche OOo pour MacOS X : ça compile c'est déjà ça .... Évalué à 1.
Ok, je veux bien admettre que c'est _un peu_ épais. Rien de très flagrant, je trouve, et surtout, rien qui ne soit pas configurable, soit par l'application, soit par le thème, iirc. Donc..
Pour la zone de texte, je voyait pas les choses comme ca.
Je pensait plus a taper mon texte, et a pouvoir me deplacer a l'interieur comme je le fait avec ce commentaire que je tape.
en fait, mettre un retour chariot automatique, mais qui n'apparaisse pas dans les messages. C'est peut etre pas trés clair, mais, la ce commentaire, j'ai tout tapé sans appuyer sur entree. Pourtant Konqueror me met des retours a la ligne, et avec fleche haut, je remonte a la ligne du dessus.
OK, tu veux simplement du wrapping (ou de l'auto-fill, comme dirait mon Emacs. :). Bon, ça, c'est pas franchement lié à Gtk+, même pas du tout, c'est simplement un choix de Gaim. Si tu mattes 30s les sources, tu verras qu'il fait un:
gtk_text_set_word_wrap(GTK_TEXT(entry), TRUE);
et que donc tu vas avoir du wrapping pour les mots, mais pas pour les lignes. Un simple:
gtk_text_set_line_wrap(GTK_TEXT(entry), TRUE);
de plus changerait le comportement de ce point de vue. Mais encore une fois, il n'est pas dit que ça ne pose pas un problème quelconque à Gaim par la suite - je ne connais pas ce soft spécifique, à toi de demander aux auteurs (#gaim@freenode est très fréquenté).
Peut etre que Gtk2 le fait.
GtkText le faisait - bien heureusement! tu vois bien que tu peux le faire dans GEdit de Gnome 1, par exemple, donc, comme il s'agit du même widget tu peux le faire partout -, et, bien entendu, GtkTextView le fait - de façon même plus logique, puisque c'est géré via un enum, et puis, il est assez clair qu'il s'agit bien d'un changement de vue plutôt que de contenue, grâce à la séparation contents/view (GtkTextBuffer/GtkTextView).
En parlant de ca aussi, sur mon ordi, la molette de la souris tourne a l'envers sur les applis gtk ( 1.2 ).
Quand je roule vers l'avant, ben, Gimp ( par exemple ) me diminue la valeur du controle glissiere ( exemple selection rectangulaire , option, adoucir, le controle pour regler ca ).
Je t'assure que j'ai fait des efforts. J'ai demandé aux gens autour de moi, sur la tribune, sur IRC. Rien à faire, je ne comprends toujours pas ce que tu veux dire. Faudrait faire des efforts de clarté :)
Tu parle des gens qui utilisent des widgets non maintenus, mais, ca veut bien dire que les widgets d'avant étaient pourris.
Pourri, tout est relatif. Il me semble me souvenir qu'encore récemment, c'est à dire du Qt3, le widget texte de Qt était tout aussi pourri que celui de Gtk+1.2. Il y'a deux widgets qui n'assuraient vraiment pas dans Gtk+1.2, c'était GtkText, et GtkCList. GtkText parce qu'il était fait de façon très naïve, n'avait pas de bonnes performances, et ne supportait pas grand chose - ceci dit, il est à peine en dessous des widgets texte par défaut de la plupart des toolkits. d'ailleurs, beaucoup d'applications refont leur widget text quand ils veulent quelque chose de sympa. GtkCList parce qu'il avait pas mal de problèmes, qu'il était pas facile à utiliser, et un peu buggy - mais ça, ça se voyait pas trop. Ils n'étaient pas pour autant *pourris*.
Sachant que les problémes que j'ai soulevé sur gtk ont été réglés il y a longtemps dans qt, j'estime que qt avait quand même beaucoup d'avance sur gtk, qui , apparement, rattrape pas mal son retard.
Je n'ai pas sous la main les éléments de comparaison, mais, pour l'instant, tu ne fais qu'avancer sans prouver. Je ne suis pas persuadé que tout ce dont tu parles ait été fixé il y'a si longtemps dans Qt. Et, pour quelques uns, voire pas mal, des points que tu évoques, c'est lié à l'application, et vraiment pas à Gtk+.
[^] # Re: Ca compile c'est déjà ça ...
Posté par Manuel Menal . En réponse à la dépêche OOo pour MacOS X : ça compile c'est déjà ça .... Évalué à 1.
[^] # Re: Ca compile c'est déjà ça ...
Posté par Manuel Menal . En réponse à la dépêche OOo pour MacOS X : ça compile c'est déjà ça .... Évalué à 2.
et c'est vrai que j'ai pe exagéré la taille. mais, ca se voit mieux sur un petit ecran...
Franchement, même sur le thème par défaut, je ne vois pas ce que tu veux dire. Un screenshot serait bienvenu. Et pourtant il m'est arrivé de regarder - pas longtemps, je vous avoue :-) - un 14", avec des applications Gtk+, et ça ne m'a pas frappé *du tout*.
en fait, c'est le principe, c'est le gaspillage d'une 10aine de pixels.
je sais qu un théme peut améliorer ca. Sauf que , ca devrait etre bien par défaut.
Si tu veux, je ne vois pas où c'est comme ça, mais bon. De toutes façons, ça n'est pas réellement lié à Gtk+ mais à un thème par défaut. Si tu arrives à réellement identifier le problème, tu peux peut-être faire une wishlist - le bugreport est assez aisé avec Gnome/Gtk+, via bug-buddy.
Bien sur, si on veut faire mieux, on peut le faire. Tu est en train de me dire que on peut utiliser d'autres widgets plus puissants et voila ?
Euuh? Je suis en train de te dire qu'on peut utiliser la dernière version de Gtkl+, et que parler de Gtk+1.2, qui date quand même assez, ne sert plus à grand chose maintenant: il faut juste inciter les développeurs d'application à porter leurs apps vers Gtk+2. De toutes façons, ce port est vraiment agréable à faire et rend les choses plus claires, sans compter que les nouveaux widgets sont un bonheur à utiliser (en tant que programmeur comme en tant qu'utilisateur, cf. le widget texte et les list/trees).
Ben oui, mais par défaut ce n'est pas le cas.
Ben, si. Au cas particulier des sépérations, c'est le cas par défaut avec Gtk+2. Pour les boutons, je peux pas te répondre, je ne vois réellement pas de quoi tu parles. Pour les listes, pareil, ceux qui choisissent d'utiliser un widget qui n'est plus maintenu et qui disparaitra avec le temps, quand on estimera que les applications majeures sont passées aux nouveaux widgets.
Un autre exemple , gaim.
la zone de texte est en fait un controle sur une ligne...
donc, fleche haut ne remonte pas...
Bon, je viens d'installer le dernier gaim, pour voir. J'imagine que tu parles de la zone de texte dans la boîte conversation (i.e., celle que tu obtiens après avoir fait New Instant Message et entré le screenname de ton interlocuteur). Bon, mais je ne comprends pas beaucoup mieux ce que tu veux dire. Ils ont mis des callbacks sur activate et sur keypress_event, de telle façon qu'un « Entrée » envoie le message. Donc, ça ne peut être que sur une ligne, hein? Ah, quoique. Je sais pas si c'est voulu, mais je peux envoyer des messages de plusieurs lignes en tapant ^M (C-m) au lieu de Entrée, et donc, ensuite, je peux remonter, redescendre, avec les flèches du haut/bas, etc.
C'est parce que le logiciel est mal fait ?
Euh, à vue de nez, je pense que c'est parce qu'il s'agit d'IM et qu'ils veulent des messages courts. Je sais pas dans quelle mesure le protocole utilisé change quelque chose, peut-être même que (\r)\n est se séparateur, who knows.
Qu'est ce qu'une zone de texte a une ligne si ce n'est un controle multiligne d'une seule ligne ?
Uh? Alors là, je te suis pas du tout. Vazy, explique ce que tu voudrais que ça fasse et que ça ne fait pas actuellement, parce que je comprends vraiment pas.
Ca devrait etre plus cohérent au niveau de la bibli.
Je doute que la bibliothèque ait quoi que ce soit à voir avec ça. (hmm, d'autant plus que Gaim est pour Gtk+1.2, et utilise GtkText).
Et pour le coté non graphique de la boite de dialogue, c'est vrai que c'est bien mieux, mais c'est pour Gnome, donc a comparer avec celle de KDE, qui offre plus d'options...
Pas seulement, non. Ce sera changé aussi dans Gtk+, très probablement.
[^] # Re: Ca compile c'est déjà ça ...
Posté par Manuel Menal . En réponse à la dépêche OOo pour MacOS X : ça compile c'est déjà ça .... Évalué à 2.
Hé béh, faut que je dorme. Je cherche encore la logique de la phrase. Donc, je disais: « Bon, je réponds rapidement, et je précise avant que j'utilise comme thème Gtk+2 ThinBright2, et comme thème Gtk+1.2 une variation de Funklor qui correspond à l'équivalent de ThinBright2 pour Gtk+1.2 (qui utilises tous deux le theme engine thinice, qui roxoraïze). » Voilà voilà. Comme quoi, jamais faire de comment avant 3h du matin, et sans la dose d'alcool requise.
[^] # Re: Ca compile c'est déjà ça ...
Posté par Manuel Menal . En réponse à la dépêche OOo pour MacOS X : ça compile c'est déjà ça .... Évalué à 4.
prenons le dialogue pour enregister un fichier. dés qu'on change de repertoire, pouf le nom du fichier disparait.
Charmant, non ?
Gnii? Peux-tu expliciter ? Là, je vais dans mon menu Galeon (1.2.6, et c'est pareil avec sylpheed), j'ai comments_reply,10264,147999,1.html (le nom de la page, donc), dans le buffer, et si je clique sur un répertoire, il va dans ce répertoire conserve bien le nom du fichier dans la zone de texte. Tout ça en Sid, donc Gtk+ 1.2.10. Bien entendu, il va sans dire que le comportement est le même avec Gtk+ 2. Donc, je vois pas.
en plus, cette boite est graphique a souhait...
Là, on est d'accord. http://developer.gnome.org/news/summary/2002_October20-October26.ht(...) pour plus d'informations.
ensuite, que quelqu'un vienne me dire que c'est utile de mettre des kilometres de bordures autour des boutons...
Euuh, là, je te suis pas. C'est peut-être lié à ton thème, remarque. Auquel cas ça n'a pas grand chose à voir avec Gtk+, donc bon..
toujours dans la meme veine, le séparateur entre deux zones redimensionnables.
le truc ou il y a une zone minuscule pour faire glisser le separateur ( je sais, ca depends du theme ). ben, c'est nulle. sous qt, tu clique n'importe ou sur la barre et c'est bon ca glisse.
Bon, là, mon Sylpheed confirme effectivement que c'est vrai. Ceci dit, mon pan et mon gedit utilisant Gtk+2 me montrer que cela a été changé dans Gtk+2. Donc, il ne reste plus qu'à inciter les gens à passer leurs applications en Gtk+1.2. C'est sur la voie avec pas mal d'applis majeures, du genre Galeon.
on peut cliquer sur les boutons au dessu des listes, masi il ne se apsse rien. pour alors autoriser le click ? c'est ce qu'on appelle un mauvais feedback. On a l'impression que ca fait quelque chose, masi ca fait rien. Et le bouton passe en surbrillance quand on passe dessus, donnait l'impression qu'une action est possible...
Il s'agit d'une des erreurs de GtkCList. Ce widget est deprecated dans Gtk+2, mais encore utilisé par quelques applications qui en faisaient un usage intensif, et qui ne sont pas encore passées au nouveau widget, qui est incomparablement plus puissant, et considérablement mieux fait - mais peut-être un peu plus difficile d'accès. Bref, fixed.
voila, tout cela n'existe pas dans qt.
Si tu compares avec le dernier Qt, compare le dernier Gtk+. Et là, comme tu vois plus haut, ce que tu dis n'est plus valide.
pour moi, tant que gtk aura ces problémes, qt sera mieux. ( pour moi )
Parfait! Gtk+ est donc au moins aussi bien, là. (je ne joue qu'à ton propre jeu, en ne considérant pas le reste)
[^] # Re: Un homme sans passé
Posté par Manuel Menal . En réponse à la dépêche Un homme sans passé. Évalué à 0.
[^] # Re: Soft supplémentaires
Posté par Manuel Menal . En réponse à la dépêche Les logiciels grand public pour Windows: tour d'horizon. Évalué à 1.
Une petite remarque, et elle est de taille: on parlait de logiciels libres. Si 7-Zip l'est (LGPL), Gsview ne l'est malheureusement pas:
GSview is copyright by Ghostgum Software Pty Ltd. GSview is distributed with the Aladdin Free Public Licence.
( http://www.cs.wisc.edu/~ghost/gsview/Readme.htm(...) )
or,
The "Aladdin Free Public License"
Despite its name, this is not a free software license; it is far too restrictive.
( http://www.gnu.org/licenses/license-list.html#NonFreeSoftwareLicens(...) )
L'AFPL Ghostscript n'est pas plus libre: seul GNU Ghostscript l'est.
J'ai déjà envoyé un long mail avec quelques corrections à GnuWin II, dont celle-là.
[^] # Re: Troll launcher.
Posté par Manuel Menal . En réponse à la dépêche tutorial gnus. Évalué à 1.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Manuel Menal . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
Quant au cours sur le TLB flush etc. (qui n'en était pas un, c'était extrêmement bref et récapiulatif), c'était simplement pour remettre les choses au clair, avec toi et les autres lecteurs ici. Et bien s'assurer qu'on parle de la même chose: tu emploies parfois des termes assez bizarres, et j'avoue que j'ai parfois été tenté d'aller chercher le de-yoda-ifier.
J'aime d'ailleurs cet article car il indique explicitement que la technique en question peut être portée sous Linux monolithique et permet d'avoir les mêmes performances. Comme par hasard, kilobug et toi ne mentionnez pas ce fait. Mauvaise foi ?
Non. C'est d'ailleurs assez étrange, parce que nous en parlions justement y'a pas plus d'une heure (devant une pizza :-p) avec Kilobug, et nous ne savions pourquoi l'astuce du 2^52 sur PPC n'était pas utilisée par Linux sur cette architecture, car elle est très simple à réaliser. Mais, je ne pensais pas, et je ne pense toujours pas, que ça ait eu un intérêt dans l'optique de notre conversation et pour ce que je voulais montrer.
Effectivement les noyaux monolithiques pourraient l'utiliser, mais ça n'empêche que les systèmes à base de micro-noyaux peuvent ne pas être moins performant, notamment grâce à cette technique. Attention à ne pas rentrer dans la simplification schématique: 1) les systèmes µk-based sont moins rapides avant 2) on améliore les performances des deux => les systèmes µk-based sont toujours moins rapides comparativement. Si par exemple les systèmes µk-based étaient simplement plus lents à cause des cont-sw, et qu'on supprimait les cont-sw, ça mettrait les deux systèmes sur un pied d'égalité a priori. Pas plus.
Quelques explications sur mon délire de noyau. Quand je parle de passer en mode noyau, je veux bien sûr parler de changement de privilège. Quand j'ai dit "dans le noyau", je voulais dire un accès à un des services externes au noyau (dans le cadre des µ-noyaux). Oui, je sais, ça peut paraître délirant, mais bon, je ne suis pas toujours très clair.
Je ne sais pas si c'est la fatigue ou la guinness, mais je ne comprends toujours pas mieux ce que tu veux dire, et tu as fait lamentablement segfaulter mon de-yoda-ifier.
Enfin, tu réponds à des choses qui ne sont pas de moi (genre bench neutre)
Effectivement, je n'aime pas faire de multiples commentaires juste pour le plaisir, je préfère tout grouper. Peut-être à tort, puisque ça a l'air d'en effrayer certains. Il est vrai que mon style n'est de loin pas des meilleurs.
sans expliquer pourquoi il y aurait moins de lock dans un système à µ-noyaux que dans un système monolithique.
Uh? C'est quand même un peu évident. Plus tu as une grosse application avec plein de trucs qui s'effectuent en même temps, s'agissant en plus d'un noyau avec des interrupt handlers, des possibilités d'être reveillé d'un peu partout, et tout ça, plus tu vas avoir besoin de locks, et de complications pour éviter que toutes les pièces se marchent dessus. Tous ces locks ne sont pas justifiés lorsqu'il s'agit de tâches différentes. (bien sûr, il y'a toujours besoin de locks, sur des container et autres, mais ça n'a rien à voir, et ce ne sont pas des big global locks manipulés plus que fréquemment)
Pour les longs commentaires, euh, je les tape dans mon galeon, ou dans mon emacs puis je les copie dans mon galeon. GNU Emacs + Galeon, le couple gagnant ! ;P
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Manuel Menal . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
Il sait parfaitement de quoi il parle. Et ses goûts quant aux langages n'ont rien à voir avec ses connaissances techniques, qui concernant les micro-noyaux sont plus importantes que n'importe qui ici (pitet sauf moi, parce que c'est quand même moi qui l'ai convaincu ..). Les attaques personnelles de ce type sont plus que malsaines, elles m'écoeurent profondément.
J'ai relu tous les posts de Gaël ici (deux avis valent mieux qu'un), et je peux t'assurer qu'il n'est pas le seul qui aurait répondu comme ça. Peut-être effectivement est-ce dû à une mauvaise expression de ta part. Pour autant que je sache,
J'ai lu les docs L4 (avant de poster). Pour faire un IPC, on passe le thread en mode noyau (j'ai pas dit DANS LE NOYAU, j'ai dit en MODE NOYAU), exactement comme pour faire un appel système.
est un non-sens complet. On ne passe pas le thread en mode noyau. D'ailleurs, une définition correcte et assez précise du sens noyau, qui est la mienne (et ensuite celle de Kilobug), est qu'il consiste en tout ce qui tourne en mode « noyau ». On passe effectivement en mode noyau (instruction iret), mais tu changes pas les permissions d'un thread comme ça, hop. Il s'agit d'un CALL/SYSENTER (« inter-privilege-level far call », disent les docs Intel), puis d'un IRET/SYSEXIT. Effectivement, l'IPC entre tâches différentes se fait via un appel système avec L4 (et avec tout micro-noyau, en tous cas sur les architectures récentes et que je connais, avec MMU), il y'a donc le coût du changement de « privilege level » (relativement important sur un PIV, il faut l'avouer).
comment un IPC peut coûter moins cher qu'un appel système alors que l'IPC ajoute des instructions par rapport à l'appel système (on est d'accord, il y a très peu d'instructions en plus).
Si tu compares le nombre d'instructions, tu as en théorie raison. Cependant, ce que Kilobug t'a fait remarquer est que les mêmes instructions, les mêmes accès, faits dans des contextes différents n'a pas *du tout* le même poids. Le noyau est un énorme programme extrêmement complexe, où on doit lock'er de partout, etc. Le poids de ces locks est déjà un poids supplémentaire. L'empreinte sur le cache, étant donné que l'application est plus grosse, fait plus de choses, etc., est aussi considérablement plus importante. D'où encore pertes de performance. Or, il s'agit là d'un des facteurs *essentiels* vis-à-vis de ces dites performances. (Ceci dit, quand il s'agit du Hurd, on ne peut pas vraiment comparer, puisque le open() ne fait rien de comparable à ce que fait le open() de Linux.)
N'oublie pas qu'il s'agit de performances. On ne peut pas avoir une comparaison directe, fiable à 100%, manichéenne quand il s'agit de performances. Tel critère peut représenter une perte de performances, mais tel autre peut également, selon la façon dont s'est fait, selon les cas, etc., le compenser, voire plus. C'est pour ces raisons que Gaël a cité un certains nombres de choses qui peuvent te paraitre hors-sujet, mais qui pourtant ont un rôle prédominant quant aux performances. J'en profite d'ailleurs pour répondre à bknight, qui disait:
Le reste du débat micro noyau/monolithique m'apparaît de plus en plus comme une question de point de vue personnel. J'attends toujours un bench complètement neutre sur la chose.
La chose me paraît impossible. On ne peut pas faire des benchmarks sur des théories. Je peux te trouver des systèmes à base de micro-noyaux plus rapides que d'autres à base de noyaux monolithiques, et vice-versa. Il n'y a pas de bench parfait: même un bench du même code tournant sur un micro-noyau et sur un noyau monolithique serait absurde, parce que le code ne serait pas optimisé pour l'un ou l'autre (et d'ailleurs, par nature plutôt pour le second, puisqu'il s'agirait d'un serveur monolithique). C'est pour cela qu'il faut prendre les bench de L4Linux avec des pincettes. Et se souvenir que dans biens des cas MkLinux - « pendant » de L4Linux sur Mach - est bien souvent (tout le temps?) moins performant que le Hurd sur L4.
Les performances sont à traiter au cas par cas. Il semble logique, dans le cas d'un open(), qu'au final le coût soit à peu près le même: les pertes toutes relatives dues à l'IPC sont compensées par une moindre pollution des lignes de cache, etc. En revanche, dans le cas d'un write () où d'un appel plus complexe, l'utilisation de µk peut permettre d'utiliser des techniques plus performantes. Mais le µk en lui-même ne rendra pas les choses plus rapides, encore faut-il l'utiliser. C'est aussi pour ça que le Hurd est nouveau: certes les systèmes à base de micro-noyau ne sont pas nouveaux, mais aucun, sorti du domaine de la recherche, n'en tirait parti comme le Hurd, à ma connaissance, et encore moins comme il le fera quand le port sur L4 sera terminé.
Une petite remarque de forme. C'est gentil de toujours faire référence aux papiers sur L4, mais bon, je ne connais pas beaucoup de chercheurs qui crachent dans leur propre soupe.
Effectivement, cela est vrai. Mais il n'empêche que ce qu'il présente, ce sont avant tout des *faits*. Et à moins que tu me montres qu'ils sont faux, infondés, ou que sais-je, ce sont la base d'arguments valides. De même que je ne connais pas de papiers qui proposent des contre-arguments à L4, ou qui montrent que c'est faux, que c'est forcément plus lent avec L4. Le seul qui m'ait dit ça, c'est Rik (Van Riel), et bizarrement, il a toujours quelque chose de très urgent à faire dès qu'il s'agit de me montrer en quoi.
Mais qu'est-ce que tu racontes ? Comment fais tu un ipc sûr sans passer en mode noyau ?
Là, je voudrais nuancer légèrement. Tu ne peux pas faire d'IPC sûr sans passer par le mode noyau, effectivement, si on garde à l'esprit que IPC = « Inter Process Task ». En revanche, tu peux faire des RPCs locales, i.e., entre threads d'un même groupe, d'une même tâche, sans passer par le mode noyau. (et oui, c'est utile, je vous prie de se referrer au début et à l'ensemble de http://www.l4ka.org/publications/files/lazy-process-switching.ps(...) (oh! mon Dieu, encore une référence aux docs L4! Mais ce gars n'y connait rien! sauf que ce gars échange avec Horst Wenske (mais malheureusement pas avec le regretté Jochen Liedtke :-( ))). Ça s'appelle LIPC, et ça fait partie des services qu'un noyau et qu'un système d'exploitations peuvent fournir pour permettre d'avoir un ensemble plus rapide.
Euh, c'est une question piège ? Disons, un RPC ? Le problème, c'est que sauf erreur de ma part, ça fait un changement de contexte et que ça coute des ressources (par exemple tu dois avoir un risque de niquer le cache).
<tribune>Pas du tout, efface.</tribune> Cela fait un changement de contexte dans quelques cas très particuliers. Enfin, soyons clair. Cela fait un changement de contexte dans tous les cas: on change de tâche, on modifie deux/trois trucs. Mais c'est une hyperbole que dire que c'est peu coûteux. De plus, le cache primaire est indexé physiquement, donc cela ne coûte encore une fois que quelques cycles. Les coûts sont donc liés à, comme tu le dis, au « cache » (« niquer le cache », expression qui me plait décidément beaucoup). Plus exactement, au TLB. Liedtke décrit des mécanismes pour PowerPC et pour x86. L'idée pour x86 est assez simple: sur les 4GO d'espaces d'adressage, les tâches qui ne requièrent pas un espace d'adressage phénoménal (i.e., <500MB, si mes souvenirs sont bons, mais cela a pu changer et est peu ou pas décrit par Intel), donc la vaste majorité des tâches (en fait, toutes sauf 1 ou 2 sur la plupart des systèmes), n'ont pas accès aux 3GO d'address space normaux, mais seulement à une petite partie, de 500MB. Or il est tout à fait possible de multiplexer, de partager ces petits espaces d'adressages entre les gros, de 4GO. Dans la plupart des cas, un « changement de contexte » se fait entre deux tâches occupant des petits espaces d'adressage. Il n'y a donc pas de réel changement de page table, donc pas de TLB flush, donc pas un « réel » changement de contextes. En revanche, il est vrai que dans les cas où une petite tâche va faire une RPC à une tâche disposant d'un gros espace d'adressage n'étant pas celui en cours, ou encore dans le cas de communication entre « grosses » tâches, un TLB flush va être nécessité. Mais l'économie par rapport au context switch sur Linux, ou plein d'autres systèmes - Windows NT, pour autant que je sache - est monstrueuse. Pour PowerPC, c'est encore plus simple, et pour le coup il n'y a plus du tout de TLB flush, puisqu'il est très facile d'avoir un address space de 2^52 bytes, et donc d'« émuler » une TLB taggée sans ses inconvénients.
Tout ça pour dire que aujourd'hui je pense qu'aucun système à micro-noyau n'est aussi performant qu'un système "monolithique".
Ça ne veut pas dire grand chose, tu t'en rends compte ? GNU/Hurd est probablement plus rapide que certains systèmes d'exploitation basés sur des noyaux monolithiques. Qu'en revanche il n'existe pas de systèmes d'exploitation aussi versatile que GNU/Linux basé sur un micro-noyau qui soit aussi rapide que ce dernier, je te l'accorde. Mais encore une fois, ça ne constitue pas du tout une preuve. Il n'existe pas à ma connaissance de raisons pour lesquelles ça ne serait pas possible, et il existe même des raisons de penser qu'on pourrait faire un système d'exploitation à base de micro-noyau plus rapide. Si je n'en étais pas persuadé, je ne travaillerais pas sur le port du Hurd sur L4.
Pour finir, j'aimerais revenir sur le commentaire auquel je réponds directement. Je ne sais pas ce que tu essayais de prouver en rappelant les positions de Kilobug sur un tout autre sujet, à savoir le C vs. le C++. Je connais bien Kilobug, mieux que quiconque ici (et que la plupart ailleurs), et je suis d'ailleurs d'accord avec lui sur ce point: le C++ n'est pas un langage que j'aime, et je le trouve absolument dégueulasse. Est-ce que pour autant on doit m'enlever le droit de m'exprimer ? Est-ce que ça m'enlève tout crédit pour parler d'autre chose, et même de ça ? D'autant plus que Kilobug fait du C++ tous les jours (ach, 3j/sem maintenant), et que donc il ne parle pas sans savoir. Il est même probablement plus renseigné dessus que beaucoup de monde ici, puisqu'il lit énormément et est de bonne volonté à ce sujet. Bref, je trouve ces méthodes digne des plus grands boulets, des plus infâmes, que l'on peut malheureusement rencontrer sur DLFP. Plus que de casser la crédibilité de Kilobug, c'est la tienne que tu viens de casser à mes yeux et aux yeux de nombre d'autres.
Ceci dit, le débat purement technique sur les micro-noyaux m'intéresse, et je pense être pas trop mal renseigné sur le sujet. Donc, puisque cette news n'est plus depuis longtemps en page principale, je vous invite, tous, et en particulier toi et bknight (et puis jjb<, s'il veut :-), à continuer la discussion sur une ML, et même devant une guinness si vous habitez dans la région parisienne (oui, oui, un lait fraise pour kilobug :-).
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Manuel Menal . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
Ensuite, je te rappelle que ce ne sont pas que des parties essentielles qui se trouvent dans le noyau. Par exemple, le montage NFS du pauvre petit utilisateur à qui on a permis de se monter une partoche via NFS (déjà qu'il a fallu qu'il demande à root, parce qu'évidemment seul root peut faire ça, et à raison en ce qui concerne les systèmes à noyau monolithique[1]) doit-il permettre de faire tomber l'ensemble du système ? Je ne le pense *vraiment* pas.
Même chose pour un serveur essentiel pour fournir les tâches imparties à la box, mais pas essentiel au système, comme par exemple, la pile TCP/IP. Je sais pas pour vous, mais j'en ai quand même vu crasher après un slashdottage. D'ailleurs, c'est bien la pile TCP/IP de Linux 2.2.14, qui est la base de pfinet actuellement (en cours de redesign) qui avait crashé plusieurs fois lors d'un /.age d'un serveur web sous GNU/Hurd (et c'était, on l'a découvert ensuite, bien lié à un bug de cette pile, qui a été rapporté par la suite). La différence étant que sur un système basé sur un noyau monolithique, ça veut dire plantage général et redémarrage (donc downtime assez important), alors que sous GNU/Hurd, ça veut dire pile TCP/IP qui crashe et qui est redémarrée automatiquement dans la seconde qui suit. (donc, des conséquences mais bien moins importantes)
Pour prendre l'analogie avec la sécurité, le Hurd ne prétend pas résoudre les problèmes de sécurité. Il prétend fournir des mécanismes de sécurité qui permettent aux développeurs de minimiser les conséquences de tels problèmes[2]. De même, il ne prétend pas résoudre tous les problèmes de stabilité. Mais, partant du principe qu'a priori, un programme a toujours des bugs potentiels, surtout lorsqu'il s'agit de programmes relativement complexes comme ceux s'occupent d'un système de fichier, il prétend minimiser les conséquences de tels plantages.
Enfin, pour avoir suivi le développement de Linux depuis assez longtemps, et avoir eu moi-même quelques expériences avec, je sais que les bugs sont loin d'être tout le temps dans la partie où ils apparaissent. S'il est vrai qu'il a été nécessaire de « cloisonner » Linux, comme le disait JJB (encore un pote à JJB!), créer un énorme logiciel qui contient des tas de parties différentes amène naturellement plus de risques de se planter, en ne connaissant pas bien ce que fait telle autre partie, en se gourrant sur un lock, ou que sais-je. De plus, une inversion de paramètres est vite arrivé, et si les changement dans les interfaces externes de Linux sont déjà fréquents, les changements dans les interfaces internes sont plus que monnaie courante, causant donc de nouveaux problèmes potentiels. Comme le disait JJB, si Linux tient, c'est par le plus grand des miracles, et quelques fois ça fait quand même badaboom. Entendez-moi bien, je ne critique pas non plus les « irresponsables » développeurs de Linux, etc. : une grande partie du miracle grâce auxquels ces sources tiennent s'appelle Alan Cox, Linus Torvalds, Rik Van Riel, Harald Welte, et autres personnes extrêmement douées du genre. Mais je persiste à croire que si ces ressources étaient mises à disposition d'un projet ne posant pas ces problèmes de bases, elles seraient mieux utilisées. (NB: et Harald est pas très loin de penser la même chose :-)
Au fait, de façon évidente, si ces « processus » (processi? processus? (4ème F/M) processa? (3ème neutre) (latin roxor (lisp aussi))) sont appelés serveurs, c'est par analogie avec le fameux modèle client-serveur (qui a dit buzzword?). Je tiens également à revenir sur la composition d'un noyau monolithique. En tant que fourre-tout officiel de tout ce qui n'est pas « bibliothéquisifiable » (j'adore ce mot. pas vous? ah bon[3]), il n'est pas évident de définir ce qu'il contient dans un système « Unix » (non, nous ne reprendrons pas le troll, j'ai déjà donné mon point de vue). Mais il ne contient certainement pas que des parties essentielles au système: il contiendrait plutôt tout ce qui doit être commun à toutes les applications et peut poser un quelconque de sécurité, ou que sais-je. Plus récemment, la manie a été d'intégrer dans le noyau tout ce qui peut se rapprocher du « bas-niveau » (PPPoE, etc.). Il est donc loin d'autant moins évident de garantir la stabilité de ces parties non-essentielles, et il me semble dément qu'ils puissent faire tomber l'ensemble du système. Enfin, vous me direz, ça ne s'applique pas forcément aux serveurs de production. Mais je crois que la stabilité n'intéresse pas que ces premiers.
[1]: mon expérience de ce genre d'explications m'a montré que ce point là était en général un des moins bien compris, et que la question « Et pourquoi on pourrait pas monter des trucs en user sur mon Unix? Moi je peux avec users dans le fstab ! ». Répondons directement. Oui, on le peut: via le setuid root. Je pense que rien que l'invocation de cette fonctionnalité devrait faire frémir tous ceux qui se sont un jour préoccupé de sécurité. :-)
Sous Unix, si on autorise tous les utilisateurs à effectuer l'appel système `mount', rien ne les empêche de créer une image d'un système de fichiers reconnu par le noyau contenant des programmes « setuid root » (justement!) qui seraient alors intégrés tels quels dans le VFS, sans distinction d'utilisateur avec les autres partitions (il n'y a pas ce genre de notions avec Unix), permettant ainsi à n'importe quel utilisateur de devenir root. Sous GNU/Hurd en revanche, le « serveur » s'occupant du système de fichier (on parle de « traducteur » ou « translator » pour le Hurd, en raison de ses spécificités) est une application _comme_ _les_ _autres_, qui tourne en mode utilisateur avec les droits de l'utilisateur qui l'a lancé. Il ne peut donc *rien* faire de plus que cet utilisateur. Tiré d'un document écrit par Marc, Kilobug et moi-même:
(mmenal@drizzt, 25) ~ $ sudo chown mmenal /dev/hd0s3
(mmenal@drizzt, 26) ~ $ settrans -cgap foo /hurd/ext2fs -r /dev/hd0s3
(mmenal@drizzt, 27) ~ $ cd foo/bin
(mmenal@drizzt, 28) ~/foo/bin $ ls -l ping
-rwsr-xr-x 1 root root 15368 May 23 18:27 ping
(mmenal@drizzt, 29) ~/foo/bin $ ./ping hurdfr.org
bash: ./ping: Operation not permitted
(jvous jure, l'idée de pinger hurdfr.org était de KB :-p)
Même si c'est franchement hors-sujet, j'espère que cela aura su répondre aux interrogations de certains. (et puis même si vous vous posiez pas la question, vous savez maintenant! :-)
[2]: Je tiens à citer Wolfgang Jährling, qui commençait son (excellente) conférence sur les mécanismes d'authentification du Hurd, dont un court résumé est disponible sur http://www.gnu.org/software/hurd/auth.html(...) , par un retentissant « security is just a bad hack ». En effet, n'oublions pas que la vraie réponse à la sécurité est de rendre les gens bons, de telle façon que tout le monde reporte les problèmes de sécurité sans jamais les utiliser à des fins malhonnêtes - et que personne n'ait même de buts qui ne soient pas louables! Mais malheureusement, cette tâche est quelque peu difficile à accomplir en écrivant des logiciels. Nous sommes donc condamnés à se limiter à ce bad hack qu'est la « sécurité » :-)
[3]: j'espère que les amateurs auront reconnu une fine allusion à Renaud, et pourront donc me dire de quelle chanson je parle :-p
[^] # Re: Quelques remarques en vrac
Posté par Manuel Menal . En réponse à la dépêche MacOS X reçoit enfin un système de fichier journalisé. Évalué à 1.
Effectivement, l'Open Group apporte un début de réponse via la Single Unix Specification et Unix 98, mais elle définit principalement des interfaces (les outils, des APIs, etc.), et donc ce qu'est être compatible Unix, et non ce qu'est être un Unix.
Je me fous un peu de savoir si les détenteurs de la marque décident d'appeler Unix, ça, ça, et ça. S'ils donnent des justifications scientifiques, OK. Sinon, ça n'est que leur opinion, et s'il venait que ça coïncide avec la vérité, ça ne serait qu'un hasard, et donc je ne m'y fie pas. (\o/ Bachelard)
Et effectivement, les éléments que tu donnes sont des éléments de compatibilité Unix. C'est à mon avis une définition faussée de Unix, comme il est en général absurde de désigner un objet par son utilité et par ce avec quoi il est compatible. C'est ce par quoi je commençais mes posts.
Cela dit l'usage courant du mot "UNIX" n'est pas celui défini par le spécification mais recouvre
Je suis tout à fait d'accord. Mais l'usage courant ne fait pas la définition correcte, simplement aussi parce qu'elle est floue et ne tient pas compte des subtilités des appellations: la majorité ne les connait pas. Donc, se fier à la majorité pour donner un sens serait nocif. Et effectivement, encore une fois c'est là une question de compatibilité, et pas de nature, et ça me semble dommage. Tu te souviens peut-être, « Il ne te demande pas ce qui est beau, mais ce qu'est le beau. »
[^] # Re: Quelques remarques en vrac
Posté par Manuel Menal . En réponse à la dépêche MacOS X reçoit enfin un système de fichier journalisé. Évalué à 1.
Effectivement, il n'y a pas, comme je l'ai dit, de définition précise d'Unix "officielle", tout du moins à ma connaissance. Mais, la définition pourrait être: avoir un design proche (à quelques détails près, mais reste à donner la signification de détail dans ce contexte, je vous l'accorde) de ce que Pike & Kernighan décrivent dans leurs livres et publications sur le sujet. Je pense pas qu'il soit possible facilement d'établir une liste de critères suffisants pour désigner un système Unix, mais il y'a certainement moyen de donner une liste *non-exhaustive* de conditions nécessaires, et dans ce cas il ne fait aucun doute que la présence d'un noyau monolithique en fait partie: c'est quand même la base des bases du design d'un OS, le choix entre monolithique, µk, layered, vertically-structured, SAS, exo, .. :-)
L'appellation Unix peut en effet paraitre abusive dans la mesure où Unix a longtemps désigné seulement le Unix Time-Sharing System. Bien que malheureusement je ne retrouve plus cette citation de Pike, encore une fois (oui, une autre), il disait lui-même cependant que le système originel devrait être appelé the Unix Time-Sharing System (ou UTSS), alors que la famille d'OS à laquelle il a donné naissance, et une définition vague, devrait être appelé Unix. Quand Pike parle d'Unix, il désigne une catégorie générique avec un design commun: on le voit bien dans son papier sur Plan9.
Cette coutume d'appeler par le nom de l'original est probablement un abus de langage, mais elle est très courante, et plus spécialement en informatique. Ainsi, on parle de Mach pour la famille des µk Mach (qui n'ont qu'un design et des interfaces en commun), on parle de L4 pour la famille des µk qui répondent à l'API/ABI L4, comme on parle de frigidère pour les réfrigérateurs :-) Beaucoup de solutions au problème de l'appellation de ces systèmes sont employés, on voit notamment: Un*x, Unix-like. Auquel on devrait rajouter: Unix-compatible. Mais, le -like est très vague: on ne précise pas le degré de ressemblance.
Je sais bien comment ils ont implémenté ça sur Windows NT (je suis, quand même :-). Mais, le fait qu'elle fournisse une couche Unix (plus qu'une couche de compatibilité, j'entends bien) ne fait qu'augmenter la ressemblance avec Unix par rapport à un système comme GNU/Hurd, et ne le rend pas un système qu'on pourrait dire « Unix »: il ne répond pas à au moins un critère, que j'ai énoncé, qui est fondamental si on regarde n'importe quel schéma d'Unix.
Concernant POSIX, il me semble avoir été clair sur l'égalité: OS whatever qui implémente POSIX = OS POSIX-compliant. Avoir des interfaces communes en grande partie avec POSIX (je ne dis pas être POSIX-compliant: de vieux Unix, qui sont incontestablement des Unix, ne respectent que peu POSIX) est probablement un des critères pour être Unix-compatible. C'est même un degré de compatibilité Unix. Mais en aucun cas une condition suffisante pour être un Unix.
[^] # Re: Quelques remarques en vrac
Posté par Manuel Menal . En réponse à la dépêche MacOS X reçoit enfin un système de fichier journalisé. Évalué à 1.
Des systèmes qui n'ont rien d'Unix, comme Win2K, Plan9, etc., et que tu n'appellerais probablement pas Unix fournissent une interface de compatibilité POSIX de façon très similaire à ce que fait MacOS X. Je te rappelle que le serveur BSD, c'est pas comme si c'était un noyau en user space, c'est juste de la compatibilité.
La présence d'un noyau monolithique *est* une condition nécessaire (mais en aucun cas suffisante) à l'appartenance d'un système au groupe Unix. Un système qui n'a pas ça peut au maximum être désigné par compatible Unix (ce qui n'est pas péjoratif, loin de là).
En revanche, si MacOS X était *basé* sur 4.4BSD (qui là, pour le coup, est clairement défini par Marshall Kirk McKusick dans The Design and Implementation of the 4.4 BSD Operating System, il serait un Unix. Mais ça n'est *pas* le cas.
[^] # Re: Quelques remarques en vrac
Posté par Manuel Menal . En réponse à la dépêche MacOS X reçoit enfin un système de fichier journalisé. Évalué à 1.
1) Depuis toujours. On ne peut pas désigner tout système qui fournit une interface de compatibilité Unix (on dira plutôt, POSIX) et fait tourner certains outils originellement développés pour Unix un système Unix - on ne peut pas désigner des objets par leur utilité, mais par ce qu'ils sont.
Il n'y a malheureusement pas de définition claire d'Unix faite par Rob Pike, ou Kernighan, à ma connaissance: il est défini en tant que dérivé du Unix Time-Sharing System (ou UNICS, si vous voulez). Mais, que ce soit dans The Unix Programming Environment, écrit par Rob Pike et Brian Kernighan, ou dans Advanced Programming in the Unix Environment (Stevens), il y'a tout un paragraphe sur le design d'UNIX, qui ne parle *pas* du Unix Time-Sharing System particulièrement, puisqu'il évoque les différentes branches dérivées, et un, si ce n'est *le* point essentiel est bien le noyau monolithique.
Remarque aussi que Rob Pike a, après Unix, créé Plan9, qui fournit une interface de compatibilité avec le premier, de la même façon que GNU/Hurd ou que Darwin (OK, pour Darwin c'est un peu différent puisque c'est avec un serveur dédié, comme avec le Mach Operating System), et qu'il l'oppose bien à Unix dans tous ses papiers: http://plan9.bell-labs.com/sys/doc/9.html(...) par exemple. Il parle aussi, dans une célèbre citation que je ne retrouve plus, de combien Unix sucks et Plan9 apporte plus.
Et, c'est bizarre de ta part. Windows 2000 (peut-être XP, je n'en sais rien) fournit entre autres une compatibilité POSIX, non ? Pourtant il est très différent d'Unix, et tu ne le considères pas, je suis sûr, comme un Unix!
Pour finir, il faut voir quand même que les interfaces POSIX sont très liées au design d'Unix, et qu'il est souvent très difficile de les respecter dans les moindres détails la norme POSIX, pour des systèmes dont le design est différent. Je ne suis pas d'ailleurs persuadé qu'il existe réellement de systèmes non-Unix qui *puissent* respecter parfaitement POSIX (attention: je sais qu'il n'existe probablement pas d'Unix qui respecte POSIX. Mais, il faut distinguer la possibilité de le faire de la réalisation technique). Donc encore une fois, UNIX est extrêmement lié au design à base de noyau monolithique, même dans ses interfaces (qui sont loin d'être optimales, d'ailleurs.)
(NB: c'est assez drôle d'avoir cette discussion dans ce sens, puisqu'il y'a quelques temps, c'était Kilobug qui était à ta place concernant le 1, et qui considérait que l'acronyme GNU's Not Unix était plus une blague, ce qu'il n'est pas.)
3) Effectivement, j'aurais aimé avoir plus d'explications sur ce fait. Que NTFS ait beaucoup d'inconvénients, je suis d'accord. Mais, d'après tout ce que j'ai pu lire sur NTFS (et j'ai essayé de me documenter, même si j'aurais aimé trouvé le fameux <l>Inside the Windows NT File System</u>, car je me refuse d'acheter chez Microsoft Press :-p). Je trouve très fair play de ta part de ne pas avoir lancé un troll sur ce sujet, d'ailleurs, qui n'aurait évidemment pas rétabli la vérité, puisqu'il serait venu de ta part.
4) Toutafé d'accord.