Complétons ce que dit Olivier sur une note un peu plus optimiste :
Comme ça a déjà été discuté ici, il y a quelques temps Neal H. Walfield, un des développeurs principaux du Hurd (même s'il se consacre en ce moment à ses études plus qu'à l'informatique), a passé l'été à l'université de Karlsruhe, en compagnie de l'équipe L4Ka qui développe l'implémentation L4 la plus neuve et intéressante du moment (à mon avis), L4Ka::Pistachio. Il a pu, d'après ses discussions et ses tentatives de code, estimer le travail à faire et fournir pas mal d'éléments de réflexions, ainsi que code. Il a notamment réalisé un travail capital en documentant et concevant entièrement le nouveau système de VMM pour le Hurd sur L4 (qui est, soit dit en passant, une petite merveille. :)
Ce travail réalisé par Neal, de rapprochement entre les deux équipes (consacré par une réunion L4Ka/principaux développeurs du Hurd au CCC en décembre d'après), a permis de convaincre les principaux développeurs - Marcus, Neal, Marco, Roland, ... - de la nécessité et de l'intérêt du port du Hurd sur L4. À partir de là, tout s'enchaîne : aujourd'hui, la plupart des développeurs du Hurd se concentrent sur le port L4, qui dispose d'un CVS, qui n'est pas vide comme suggeré ci-dessus (hurd-l4 sur le CVS habituel du Hurd, à la place de hurd.) Il est bien évident qu'autant de travail prendra du temps, et des personnes. Il faut que chacun des développeurs se familiarise avec les nouveaux concepts à traîter, avec les nouveaux problèmes rencontrés, et propose des solutions efficaces et flexibles. Loin d'être évident, donc, et pas aussi rapide que de coder, une nouvelle console, un nouveau ftpfs, etc. :)
Quant à la portabilité : à vrai dire, le Hurd en l'état devrait déjà être très portable. Un port sur PowerPC a été réalisé par Peter Bruin, utilisant le port de CMU Mach sur PPC. OSF/CMU Mach - sensiblement identiques à GNU Mach - étant portés sur nombre d'architectures (Sparc, Alpha, M68K, PowerPC, x86, j'en passe, et des meilleures). Le principal problème : il n'existe pas de bootloader adapté (i.e., respectant le standard multiboot) sur ces architectures. (balo, hein :) C'est pour cette raison que certains développeurs se concentrent aujourd'hui sur la nouvelle version de Grub (codename: PUPA, disponible en Sid pour les Debianeux), bien avancée, et hautement portable, avant de se reconcentrer sur le Hurd sur L4 en lui-même. (c'est le cas de Marco Gerards, pour ceux qui suivent les listes et se demandaient où il est passé :)
Bien entendu, le port sur L4 permettra d'avoir une plus grande portabilité, dans la mesure où L4Ka::Pistachio (l'implémentation utilisée) est porté sur nombre d'architectures (IA-32, IA-64, PowerPC, Alpha, MIPS, et d'autres sont en cours), et surtout activement utilisé et testé par d'autres projets. Avoir une base stable, ça aide. :-)
Ça n'aura, pour l'instant, rien à voir - et c'est pour celà qu'il ne s'agit pas d'ISOs officielles Debian GNU/Hurd disponibles sur le site de Debian comme les autres.
C'est en cela qu'il faut saluer le travail réalisé par Philip Charles, qui contribue activement à GNU/Hurd à sa manière et avec son temps et ses compétences, en collectant les paquets, la documentation, en tentant - avec l'aide de Jeff Bailey - de faire fonctionner les outils Debian (deboostrap, ...) avec GNU/Hurd. En effet, beaucoup de paquets centraux - on pense notamment à XFree86 - dans Debian GNU/Hurd nécessite aujourd'hui des petites manips, des petits hacks pour compiler ; ils ne peuvent donc pas faire partie de l'archive officielle Debian (qui requiert que les paquets s'autocompilent, et tend à éviter les uploads de paquets binaires). Ces paquets sont disponibles sur d'autres sources - principalement ftp://ftp.gnuab.org(...) mais aussi d'autres. Il faut donc les collecter, les tester, vérifier qu'ils s'intégrent bien. De plus, l'autobuilder fonctionnant plutôt .. aléatoirement, et quand il y a Jeff à côté (en attendant mieux), la plupart sont compilés à la main, et uploadés sur des sites comme gnuab.
De plus, Debian GNU/Hurd utilise aujourd'hui un système basé sur Linux pour son installation ; c'est plutôt compliqué et « tricky », ça nécessite pas mal de maintenances - il n'y a qu'à voir le numéro de ces ISOs : K5, il y a eu K-A+1== 11 révisions portant sur la structure même des CDs (changement d'organisation, mais surtout couramment changement sur la procédure même d'installation).
Voili voilà, donc, ça ne marchera pas. Et au passage, merci à Philip Charles pour ce travail de titan qui facilite grandement l'installation de Debian GNU/Hurd. (ah, et puis, on écrit Jigdo si je ne m'abuse :)
Un point particulier rend la licence non-libre, à mes yeux, et à ceux de la FSF. C'est le point 2.1.d.
(d) You must make Source Code of all Your Externally Deployed Modifications publicly available under the terms of this License, including the license grants set forth in Section 3 below, for as long as you Deploy the Covered Code or twelve (12) months from the date of initial Deployment, whichever is longer. You should preferably distribute the Source Code of Your Deployed Modifications electronically (e.g. download from a web site); and
D'après les définitions de la première section, l'utilisation du logiciel dans un contexte professionnel non-R&D est une forme de "Deployment"; il est donc interdit de faire des modifications dans son coin du logiciel, de l'utiliser dans sa boîte, sans distribuer ces modifications. On a là une violation évidente, me semble-t-il, du fameux « privacy right » énoncé sur http://www.gnu.org/philosophy/free-sw.fr.html(...) ainsi :
Vous devez aussi avoir la liberté de faire des modifications et de les utiliser à titre personnel dans votre travail ou vos loisirs, sans en mentionner l'existence. Si vous publiez vos modifications, vous n'êtes pas obligé de prévenir quelqu'un de particulier ou de le faire d'une manière particulière.
Cette licence me semble donc poser le même problème que l'APSL sous laquelle est distribué Darwin, le coeur de MacOS X. Revenons cependant (dans le même post, je m'en excuse) sur ce que Daganf disait plus haut:
(c) You agree not use any information derived from Your use and review of the Covered Code, including but not limited to any algorithms or inventions that may be contained in the Covered Code, for the purpose of asserting any of Your patent rights, or assisting a third party to assert any of its patent rights, against Licensor or any Contributor.
Je ne vois effectivement pas, comme Boa treize, Arachne et Philippe Plantier ce qui peut vous paraître incompatible avec les définitions du libre de la FSF ou de Debian (les fameuses DFSG) dans ce point. Il ne s'applique de toutes façons pas en Europe, et j'espère que cette situation durera. Et dans tous les cas, il oblige juste la personne voulant attaquer en justice le "Licensor" à fonder ses arguments sur d'autres choses que du code obtenu via cette licence. Rien de particulièrement choquant ici : de toutes façons, la question des brevets dans les licences est un casse-tête sans fin auquel ni la FSF, ni Debian, ni l'OSI n'ont clairement répondu, et il vaudrait mieux ignorer tout article concernant les brevets si l'on souhaite déterminer s'il s'agit d'une licence de logiciel libre ou non.
Quant au point signalé par Branden, je ne suis sincèrement pas convaincu. Surtout que je ne suis pas sûr que cet article change quoi que ce soit quant aux problèmes d'exports : elle me semble juste un moyen pour Real de se protéger nettement des interprétations douteuses ou limite des lois sur l'export telles qu'elles existent aux États-Unis.
Disclaimer: IANAL (I Am Not A Lawyer). Je suis ce genre d'affaires depuis pas mal d'années, mais plein de choses m'échappent et j'en apprends chaque fois un peu plus.
Classique avertissement, IANAL (I Am Not A Lawyer). Tout d'abord, je dois dire que je suis choqué de voir s'enchaîner en fin de ton commentaire ces deux phrases :
Tu peux considérer que le côté libre, Open Source, ou quoi que ce soit de la licence t'importe peu - je le réprouve, mais je le conçois et l'accepte. En revanche, sans avoir pris connaissance de la licence tu ne peux toujours pas savoir si elle est acceptable à tes yeux ou non : et je doute que toute licence le soit à tes yeux - une licence qui autoriserait les auteurs de WineX à vérifier les logiciels que tu utilises avec, pour vérifier si tu as les licences, te semblerait probablement inacceptable. De plus, tu ne peux même pas savoir si un tel produit est simplement _légal_, s'il ne viole pas des licences. Et ça n'est pas du tout évident, étant donné que Wine est maintenant sous licence LGPL, licence qui ne permet pas l'inclusion du code dans un projet à la licence incompatible.
MSVCRT Runtime library Copyright(c) 1999 Microsoft Corp.
.. ce qui n'est plus mentionné dans les fichiers de licence, etc., dans le CVS - logique, je doute que ces deux entreprises fournissent les sources, ou en tous cas les sources sous une licence permettant la redistribution. Voir <http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/winex/win(...)
Où l'on apprend ensuite que les parties Copyright Transgaming sont couvertes pas l'AFPL (Aladdin Free Public License). Il faut savoir que cette licence est non-libre, comme évoqué sur <http://www.gnu.org/licenses/license-list.html(...)
Ils semblent adopter concernant le code source originel de Wine une attitude double : d'abord, les composants qu'ils reprennent pour inclure directement dans le source de WineX semblent être issus des versions de Wine publiées sous licence X11 (licence qui permet ceci). Cependant, ils utilisent les versions de Wine publiées sous licence LGPL pour les "DLLs", qui seront alors sous forme de bibliothèque, et avec lesquelles ils pourront donc lier librement. Il reste à vérifier par quelqu'un utilisant, connaissant, WineX que (1) ils n'utilisent ces portions de code que dans les DLLs (2) ils ne font que de l'édition de lien dynamique (dynamic linking?) et non statique avec ces DLLs.
Voili, voila, my 2 cents. Je n'ai donc pas trouvé d'illégalité à vue de nez - mais il est clair que le logiciel est tout sauf libre.
Tout à fait d'accord dans l'ensemble, et merci pour ce joli résumé.
La GPL implique d'être en mesure de fournir les sources du soft. Ceci ne risque t'il pas de poser des problèmes pratiques ?
Bien entendu. D'un point de vue légal, c'est une obligation. D'un point de vue pratique, ça n'est pas bien dûr à réaliser - peu de gens, en pratique, demandent (malheureusement?) le code source des logiciels, il suffit donc pour la bibliothèque de graver quelques CDs de sources, ou même simplement d'ajouter dans les CDs les sources s'il reste suffisamment de place sur le support. Je ne pense pas que ce soit un obstacle, concrètement.
La GPL autorise les modifications sur le soft. Est il acceptable, dans le cadre d'un prêt au public, que l'oeuvre prétée soit rendue altérée ?
Il y'a, lors du prêt de logiciel un contrat implicite entre le prêtant, la bibliothèque et l'emprunteur. Il suffit de préciser dans ces conditions qu'on considère que le support et l'information sur ce support doivent être retournés exactement dans l'état où ils ont été empruntés. Ceci n'est en aucun cas incompatible avec la GPL, qui ne précise évidemment rien quant au support : l'auteur pourra toujours redistribuer une version modifiée. J'espère cependant que les bibliothécaires en charge seront assez intelligents et ouverts pour considérer l'intégration du logiciel modifié s'il en vaut la peine. Il va sans dire cependant que pratiquement, il est impensable de prêter des logiciels sur un support RW dans une bibliothèque.. la seule restriction qu'imposera la GPL, c'est qu'il n'existe aucune protection contre la copie sur ce support.
Il n'y a, à mon avis, dans la GPL, rien qui soit incompatible avec le prêt en bibliothèque. Il est cependant vrai qu'il existe dans le cas des logiciels un contrat spécifique qui n'existe pas dans le cas des livres - qui sont directement couverts par la législation sur le droit d'auteur (les mentions "Tous droits réservé", etc. ne doivent être que des rappels), législation qui concerne tout le monde, que vous l'ayez explicitement accepté ou pas (nul n'est censé ignorer la loi). Cette différence obligera l'étude au cas par cas des licences - on pense notamment à une licence qui obligerait toute personne possédant une version modifiée d'un logiciel à la signaler à l'auteur originel si celà n'a pas été déjà fait (avec un moyen de quelconque de vérifier que ça n'a pas déjà été fait). Les bibliothèques peuvent difficilement se permettre de vérifier que tous les logiciels n'ont pas été modifiés (quelqu'un qui subtilise le CD et le remplace par un autre, etc.). Donc, dans la légalité pure (on doute bien sûr qu'un créateur de logiciel attaque une bibliothèque pour ça, mais nous ne sommes plus à une absurdité près dans le domaine de la PI), une bibliothèque ne devrait pas accepter de tels logiciels - qui ne seraient pas bien sûr, des logiciels libres, mais seraient en revanche Open Source (voir le privacy right dans mon commentaire plus haut), puisqu'elle n'est pas en mesure d'appliquer la licence.
Reste à déterminer s'il pourrait exister une licence libre incompatible avec le prêt en bibliothèque. Si oui, il faudrait certainement qu'un organisme se charge de cette vérification. Difficile à réaliser.. mais espérons !
Il faut de plus savoir que le CRDP de Poitou-Charentes fournit en accompagnement de BCDI des « mémofiches » (<http://www.crdp-poitiers.cndp.fr/igdoc/memof.htm(...)il existe déjà un certain nombre de services payants autour de BCDI rendrait son passage sous une licence libre encore plus facile. Difficile cependant de faire entendre sa voix.
Soyons justement précis et concis - le second n'étant pas si naturel chez moi. :)
L'Open Source et les logiciels libres sont issus de deux mouvements ayant des objectifs communs, mais des visions radicalement différentes ; ils sont complémentaires en ce sens qu'ils insistent sur deux facettes de ce qu'on a perdu avec la propriétarisation des logiciels, avec le développement de ce qu'on appelera « l'industrie du logiciel ».
Le mouvement Open Source défend une certaine vision du logiciel qui est fondée sur des raisons « pragmatiques » : ils soutiennent, et tentent de prouver, que le fait de pouvoir lire, redistribuer et modifier le code source d'un logiciel permet la création de logiciels plus performants, plus évolués, plus sûrs et ceci plus rapidement. Ils insistent donc sur le côté pratique, méthodologique, un peu comme le feraient les fameuses méthodes de développement à la eXtreme programming (beuark). Et de ceci résulte une définition, qui est l'Open Source Definition. Cette définition a été écrite par Bruce Perens en '97, issue des « Debian Free Software Guidelines » qu'il a lui-même écrits. C'est dire si elle entretient des liens étroits avec le logiciel libre. Bruce Perens lui-même, a d'ailleurs plus tard déclaré qu'il préférait le terme logiciel libre - voir <http://www.fsfeurope.org/documents/whyfs.en.html(...)
Le mouvement du logiciel libre défend lui une toute autre vision du logiciel, une vision dont la base même est incrite dans le terme : la liberté. Il se veut défenseur de la liberté de chacun, d'une liberté d'accès à la connaissance, défenseur de valeurs de partage et d'enrichissement - l'action qui résumerait la mieux, à mon avis, cette vision est la demande de classement des logiciels libres comme patrimoine de l'Humanité <http://www.fsfeurope.org/projects/mankind/mankind.fr.html(...)Vous devez aussi avoir la liberté de faire des modifications [...] manière particulière), qui fait que l'APSL (Apple Public Source License, la licence sous laquelle est distribué Darwin, le coeur de MacOS X) est une licence Open Source, mais pas une licence libre.
Les différences entre l'Open Source et le Logiciel Libre, d'un point de vue strictement « légal » sont minimes ; très peu de licences sont Open Source et non libre, et aucune, à ma connaissance, n'est l'inverse. Et souvent, ça n'est pas tellement par différence de définition qu'une licence est acceptée par l'OSI et pas par la FSF, mais par une différence d'interprétation d'un point de licence. La différence de vision entraîne cependant ce qui crée la majeur partie des critiques et flamefests autour de la GPL: le copyleft. Dans l'optique du logiciel libre (mettons, dans l'optique de <http://mmenal.nerim.net/quest(...)http://www.fsf.org/copyleft/copyleft.fr.html(...)m a dreamer .. »).
Pas bien important tout ça. Enfin, pour le sous-bock, pour un first de maintenant, c'est bofissime. Et pour le Flam's, c'est pas mal pour des bouffes exceptionnelles (la bouffe LinuxFR du 29 septembre 2001), mais je vote [CONTRE] pour le first.
Pour les cartes graphiques, il s'agit de porter XFree, donc les drivers sont ceux de XFree pour l'instant (4.1 actuellement, le 4.3 est en cours de portage).
Sauf dans l'optique d'un système de fenêtrage conçu proprement pour utiliser les spécificités d'un système multi-serveurs à micro-noyau de seconde génération comme GNU/Hurd sur L4.. :-) Ce qui offre des possibilités infinies, notamment permettrait une gestion clean et efficiente des drivers - il utiliserait pas son propre système de pilotes, mais bien le framework fourni par le système.
Pour le reste, on utilise actuellement OSKit, donc les drivers de Linux 2.2 ou FreeBSD jenesaispluscombien.
On n'utilise en fait que les pilotes de Linux 2.2.12, mais il serait hypothétiquement possible d'utiliser les pilotes de FreeBSD v2.1.7.1 (hé, ça explique peut-être qu'on les utilise pas, pour ceux qui suivent le développement de FreeBSD.. bien qu'il soit infiniment plus agréable d'utiliser, lire, développer des pilotes pour FreeBSD que pour Linux, à mon humble "avis").
A terme, on aura des drivers en user-space sur L4, et il faudra probablement réécrire pas mal de choses.
Voire, tout. Il faut bien comprendre que la portabilité inter-systèmes, dans l'esprit du GNU Manifesto (et plus spécifiquement dans mon esprit (: ) est une bonne chose, mais ne doit se faire en aucun cas au détriment du reste - c'est à dire, si faire le logiciel comme on pense que ça doit être fait implique utiliser des spécificités de GNU, il faut le faire (et si ça implique utiliser des spécificités d'autres systèmes, il faut les implémenter sous GNU :-). Or, utiliser des pilotes de périphériques conçus, par exemple, pour Linux, entraînera forcément une perte de performances, qui ne sera pas compensée, étant donné qu'ils ne tireront pas partie des avantages offerts par L4 et le Hurd. On pense notamment au fait que les pilotes de périphériques écrits pour Linux sont conçus pour avoir une mémoire « wired », inamovible (imaginez le bordel avec un kernel dont la mémoire est pageable (: ), alors que les pilotes en espace utilisateur peuvent - et devraient, à mon avis - être conçus pour tirer parti du fait que la mémoire puisse être « paged out » en cas d'utilisation intensive de la mémoire par d'autres applications. Voire, même, pour certains périphériques très particuliers, avoir un schéma de gestion de la mémoire plus complexe qui permettrait une certaine perte pendant les périodes de charge mémoire très forte, sans que pour autant le système sature d'autant plus.
Bien entendu, celà n'est qu'une question d'implémentation, et Linux nous apportera beaucoup dans la mesure où les pilotes pourront servir de spécifications, spécifications en plus déjà mises en applications, donc où l'on pourra voir les workarounds de Linux aux différents bugs des différents modèles de la carte trucmuche, etc. Que du bon en perspective ;-)
Euh, en fait, c'est selon la façon dont ça s'enchaîne dans la phrase. Si l'URL peut s'intégrer dans la phrase dans un rôle grammatical déterminé, alors je l'y mets, simplement. Par exemple, dans « Allez voir http://mmenal.nerim.net/quest(...) », l'URL sert de COD de "voir", alors, je l'y mets. Si en revanche l'URL est l'adresse correspondant à quelque chose qui est dans la phrase « Mon commentaire précédent[0] », je mets un renvoi.
Bon. Je le fais pas d'habitude, mais là, je comprends pas. Comment on peut voter - à ces post ? J'informe juste à propos de GOCR, ClaraOCR, et du travail que je fais - je précise juste ce qu'il contient, comment il est fait, ses limites, etc. Juste qu'il n'existe pas réellement de solution d'OCR libre utilisant des mécanismes plus « classiques » (rien de plus classique que ce que j'utilise.). Le [-] me dépasse un peu ici .. à moins que vous, messieurs, ayiez une réelle critique à opposer, auquel cas je vous prie de bien vouloir vous sentir abilité à la formuler clairement dans une réponse à mes posts.
Bon, ceci dit, ce sont bien les conneries du système des XPs qui sont en jeu ici. Dommage simplement que, malgré des propositions concrètes, il n'y ait pas eu de discussions et de réflexion à ce propos. (et le "envoie un patch" est un peu facile)
Oh, et, en attendant, toute idée est extrêmement bien venue, je ne suis pas un expert en la matière, loin de là, mes connaissances se limitent à celles que j'ai acquises en lisant des cours à droite à gauche sur tous les sujets. J'ai citeseer (<http://citeseer.nj.nec.com(...)autre. Alors.. :-)
Non. J'y ai bien pensé, j'ai bien suivi Amygdala, et j'ai lu le code activement. Je fus très intéressé, je le serai sans doute dans le futur : le premier problème est, j'aurais sans aucun doute (et j'ai eu, ça n'a pas manqué) à changer le code de mon RN, et pour ça, il faut que je sois parfaitement à l'aise avec le source. Le code d'Amygdala n'est pas illisible comme l'est beaucoup de code dans ce domaine, mais il est en C++, qui n'est pas tout à fait un langage que j'apprécie.
Je me voyais mal me piquer des crises de nerf sur du C++ :-) D'autant plus que bon, de toutes façons, il aurait fallu que je fasse des bindings, le reste de mon programme étant en C. (allez, j'avoue, y'aura du Guile pour les scripts d'extension .. :-) Bref, trop de boulot. J'ai donc fait ma propre implémentation (à partir d'anciens exercices à moi) assez simple, d'un réseau de neurones. Il est assez performant, bien que très simple. Assez adaptable, puisqu'il lit tout dans un fichier (dont je devrais changer le format, je pense (peut-être du XML, pour faire `in' ? :-) ), mais c'est vrai qu'il pourrait être plus performant. Je le retravaillerais avec l'aide d'Amygdala, et si un jour quelqu'un fait de bons bindings pour Amygdala en C, alors .. je céderai, et jetterai mon petit kibi de lignes de codes, et mon réseau entraîné à bloc pour être aussi performant que voulu le jour de la soutenance, à la poubelle. :-)
À vrai dire, le seul bout de code repris et pas complètement réécrit est pour Hough; à part l'import PGM ASCII, pour lequel je me suis inspiré de The Gimp. Hmm, il serait bien d'avoir une bibliothèque qui puisse m'ouvrir n'importe quelle image et me la filer dans un format qui me conviendrait .. Si quelqu'un a déjà testé, ou a des préférences, etc., you're welcome !
Misère, et pas le moindre petit morceau de source à grignoter... :-]°
Même Kilobug a été prié de rm -Rf'er le code que j'avais laissé sur son laptop pour l'occas' de la soutenance .. :-) Pour l'instant, ça serait pas grand chose, de toutes façons, et surtout inutilisable. Allez, patientez et laissez moi coder.
J'en profite pour répondre à Pierre :
Linus a dit : release often ! Je crois qu'il a raison et tu seras peut être étonné d'avoir de l'aide !
Oui, mais en l'espèce, faudra attendre que (1) ça ait un bon potentiel (2) ça soit légalement distribuable (je suis pas développeur mplayer.). Ce que Linus a oublié de préciser, c'est que le moment où l'on met les sources en ligne pour la première fois joue un rôle absolument essentiel dans la survie ou non du projet : tout, dans la communauté du libre, passe par la réputation, et si le projet fait bonne impression, ça va vite. Sinon, ça pèse contre lui bien longtemps. Donc, voilà, quoi.
Pour les performances, comme généralement en OCR, elles dépendent énormément de la qualité de ce que tu scannes, et surtourt de son adéquation avec les outils et l'expérience des outils utilisés par le logiciel d'OCR.
GOCR a des performances tout à fait correctes sur un texte imprimé assez clairement et numérisé sans trop de parasites. Il a peu ou pas de post-traitement, il utilise des outils purement "mécaniques" (d'autres diront "algorithmiques") relevant à peine de ce qu'on appelle l'IA, et a des capacités d'apprentissage à peu près inexistantes. Ça reste cependant, à ce jour, l'outil d'OCR le plus efficace sous GNU/Linux, les fondements, plus anciens, d'un GNU OCR étant été oubliés de tous, et aujourd'hui plutôt .. à revoir de fond en comble.
Clara est aussi assez étrange. Il s'agit effectivement d'un projet pour apprendre, et le moins qu'on puisse dire est qu'il ne suit pas des règles courantes. Même à l'utilisation, ça se révèle plutôt .. déroutant :-) Cependant, c'est assez intéressant puisqu'on voit bien les phases de "blobification", etc. etc.
J'ai pour ma part été amené à réaliser un logiciel d'OCR plus « classique » pour GNU/Linux, utilisant simplement quelques procédés simples de pré-traitement - gradient et transformée de Hough, convolve - un réseau de neurones (avec possibilité d'apprentissage supervisé donc, mais aussi non-supervisé au dessus d'un certain seuil de confiance), et une vérification de post-traitement basique de l'ordre du dictionary search, pour l'instant. J'y travaille toujours dans mon temps libre - ce projet a été réalisé pour les Travaux Personnels Encadrés de Terminale scientifique, et aujourd'hui il n'est pas vraiment utilisable par quelqu'un d'autre que moi, parce que je fais mes fichiers de description du RN et de l'activation (y'a possibilité de persistence du RN, donc d'apprentissage par une application externe, mais aussi de persistence des niveaux d'activation) à la main, et de toutes façons il ne sera pas distribué tant que je n'aurai pas clairement établi l'origine de bouts de code repris pour Hough. De toutes façons, je travaille sur des mécanismes de post-traitement plus « intelligents », sur une interface graphique agréable et instructive, et je passe pas mal de temps à faire des tests pour voir ce qui pourrait améliorer en règle générale.
De façon générale, il est aujourd'hui plus performant, avec mon réseau de neurones, que gocr et que clara, et s'adapte très bien au changement de polices. Mais je ne parle pas de reconnaissance d'écriture manuscrite, c'est un _tout_ autre problème.
Enfin, just my 2 cents, et je ferai une news quand il sera prêt pour son first time. :-)
Personnellement, j'utilise le terme gnunux qui est sympathique et se prononce assez facilement :)
Plutôt sympathique. À la manière d'Opalpag, quoi :-)
Pour la petite histoire, LiGNUx avait été effectivement proposé, par RMS. Il avait l'avantage d'être marrant, et de conserver les noms entiers des deux forces en présence ; bon, pour des raisons évidentes (et pour des raisons plus mauvaises, que je dénonçais plus haut), les développeurs de Linux n'étaient pas très chauds :-)
Enfin, dans tous les cas, je maintiens que GNU/Linux est un terme acceptable, Linux ne l'est pas. Ensuite, d'autres termes peuvent exister, je n'ai aucun moyen de prouver l'unicité, ni même que GNU/Linux soit le meilleur terme, d'un point de vue esthétique, prononçabilité, etc. etc. ; j'avoue que Gnunux est plutôt sympa, doit y'avoir des variations pas mal :-) Opalpag semble correct puisqu'il fait référence à un terme correct, GNU/Linux. Maintenant, va falloir un comité de standardisation et de vocabulaire du LL ;-)
Le fait que l'on puisse faire tout ce que l'on veut avec du Logiciel Libre, dans la limite de ses capacités bien sur, n'est pas nouveau.
Ça n'était point mon propos. Mon propos était de dire : il faut trouver un terme qui identifie un système bien particulier, qui est le tien, qui est le mien, mais qui n'a que très très peu à voir avec d'autres systèmes exploitant Linux. Linux n'est pas satisfaisant, pour deux raisons principales :
La première, c'est l'ambiguïté que celà crée. Je ne pense pas qu'il soit bon, dans le cas de nommage d'un logiciel, de quelque chose de concret, d'employer un terme pour quelque chose et quelque chose d'autre - c'est peut être une pensée orientée par les maths, ou par ma vigoureuse opposition à la surcharge ;-) Dans tous les cas, je trouve ça assez mauvais, parce que je peux critiquer Linux, mes critiques ne s'appliqueront pas à l'ensemble que j'appelle GNU/Linux.
Même si l'on admettait que l'on peut appeler le tout par la partie (oui, référence évidente), ce que je trouve tout à fait inadmissible dans le cas présent, le nom « Linux » désignerait « l'ensemble des systèmes utilisant Linux. » ; même dans cette hypothèse, le terme ne serait pas assez spécifique pour désigner un système, mais un ensemble de systèmes. Et pour le coup, appeler un ensemble par un de ses éléments me paraît encore plus injustifiable - et menant à la confusion.
Cela ne m'empeche pas de considérer que le système d'exploitation historique qui s'est concu autour du noyau Linux a pour nom le plus évident Linux, et pas GNU/Linux.
Mais, d'où vient l'évidence ? L'évidence est plutôt dans ta façon de faire que dans une réalité objective. Pour autant que je m'efforce d'observer une réalité objective, je vois une réalité historique qui est: "GNU a développé un certain nombres d'outils formant la base d'un système d'exploitation. Linus a, bien plus tard, développé un noyau, Linux, sur lequel ces outils furent portés. Le nom le plus logique serait une fusion des deux : LiGNUx ? Pas façile à dire. GNU/Linux? Bien, ça me paraît correct."
Après, RMS et ses partisans
Ah, je suis un partisan de RMS ? :-) Intéressant :-) Je peux partager un certain nombre d'opinions avec RMS, on peut avoir des vues convergentes sur un nombre important de sujet, je peux avoir un respect pour lui en tant qu'homme comme en tant que chercheur (hé, le dependency-directed backtrack, quand même), mais je ne me considère pas comme un partisan de RMS - je ne suis partisan de personne. Attention aux termes, dans une discussion sur des termes :-)
.. peuvent donner tout un tas d'arguments, mais je me poserais toujours la question : et pourquoi pas BSD ? et pourquoi pas tous les autres logiciels libres ? Au final, et pourquoi pas "Logiciels Libres & Co / Linux" ?
Sincèrement, je me demande parfois si en fait, la majorité des gens n'ont pas des réponses préparées dans leur tête qu'ils vont donner même si elles n'ont aucun sens vu les éléments donnés dans le message auxquels ils répondent. C'est assez impressionnant. D'aucuns attribueront ça à la lecture globale, lecture absolument inappropriée au débat, et pourtant habituelle, encore plus sur le Web. Dans tous les cas, la réponse à ta question est plus haut. Et dans le mail que je citais. Question de déterminant : ça, c'est la partie que je développais dans le mail cité. Question ensuite de spécificité : "GNU/Linux" est assez large et pourtant assez spécifique pour regrouper tout ce qu'une personne de bonne foi, et avec des connaissances correctes, regrouperait dans la même "classe" naturellement, mais pas plus. "Logiciels Libres & Co / Linux" signfierait : "tout système dont Linux constitue la base et qui utilise des logiciels libres & co" ; comme plus haut, trop générique. BSD/GNU/XFree86/Samba/Quesaisje/Linux, lui, serait trop spécifiquer pour désigner un système, mais plus une catégorie d'installations, un ensemble d'installations (voir la différence système/installation dans le premier mail).
Oh, au fait, l'URL donnée quand on clique sur ton nom ne marche pas : tu as dû oublier de marquer le 'http://'(...) ou quelque chose du genre, et les templates de LinuxFR ne doivent pas savoir gérer ça.
Pourtant ce sont deux outils GNU. Autant je trouve que Linux est un nom plus juste que GNU/Linux pour désigner le système d'exploitation basé sur le noyau Linux, autant je pense qu'il faut rendre à César ce qui est à César (enfin, à RMS... ;-)
Note qui'il y'a une contradiction évidente dans ta phrase : tout d'abord, tu admets l'unicité d'un système d'exploitation utilisant Linux : or, peut-on réellement et sérieusement dire qu'un système utilsant Linux, busybox, une libc minimalle (diet-libc, ou une des autres), est le même qu'un système utilisant Linux, les outils GNU, la GNU C Library, etc. ? Le problème ici, c'est que l'on admet que le système le plus courant est le seul : c'est bien évidemment faux. Bien que Linux ne soit pas le plus adaptable des noyaux, il existe des systèmes utilisant Linux dans l'embarqué, et ces systèmes n'ont décidément *rien* à voir avec le tien - celui que j'appelle GNU/Linux. Tu serais mis devant, tu ne verrais pas la ressemblance ..
Le problème que soulève cette non-unicité des systèmes d'exploitations utilisant Linux est celui classique du nommage : il faut trouver un compromis entre une appellation suffisamment large pour accepter toute la variété des systèmes qu'on rapprocherait naturellement comme étant « les mêmes » (on dira, la variabilité intra-classe), et suffisamment spécifique pour permette de différencier deux systèmes précisément, si l'expérience de notre jugement nous dirait qu'ils sont des systèmes différents - et deux systèmes utilisant Linux peuvent l'être (séparabilité des classes, donc.). Linux ne permet pas une séparabilité des classes.
GNU/KDE/Gnome/Samba/Apache/Linux et autres aberrations maintes fois proposées - encore récemment par Tim O'Reilly - par des gens n'ayant pas compris les vrais raisons de la critique de Linux comme nom du système dans son ensemble - ne permettent *absolument* pas d'avoir une variabilité intra-classe suffisante : elle permet en revanche d'avoir un compromis suffisamment précis pour désigner sa propre installation du système d'exploitation, et encore. Et comme je le disais dans une news précédente[0], je préférerais alors utiliser "Ma Debian GNU/Linux", qui me semble là, tout à fait correct.
D'oh, je sais à peine pourquoi je réponds. Si, en fait, je le sais : parce que c'est malheureusement ce genre de propos qu'on entends le plus, et qui sont peut-être les plus difficiles à combattre. Tellement dommage que tant d'histoire nous apprenne si peu, et qu'on revienne encore plus aujourd'hui à « du pratique, du concret, le reste ça sert à rien ! ».
Les trucs de théoricien à la noix ne sont pas faits pour rien. Ils ne sont pas faits pour faire beau. Il y'a des gens qui réfléchissent - si, si, ça peut te sembler difficile à concevoir, mais même toi, tu en es capable, au fond, et qui le fond pour le bien de tous. L'informatique est une science, et certains essayent de la construire. Je crois avoir employé beaucoup de temps à montrer, dans mes différents commentaires, dans ceux que j'ai cités, et dans bien d'autres endroits, à montrer en quoi ces choses, difficiles à appréhender il est vrai - et donc facilement critiquées, à la façon post-moderniste, mais pourtant si magiques, apportent énormément à tous les niveaux, à tout le monde, à toutes les utilisations - et c'est ça, l'adaptabilité de GNU/Hurd. Une question, une critique fondée en raison serait intéressante - mais pour celà, il va falloir lire, argumenter, reprendre. Pas se contenter de vagues allusions entendues, réferrant à un faux - je l'espère - consensus comme quoi « tout ce qui est théorie est inutile. »
Concernant les benchmarks, je m'étonnais déjà que personne ne l'ait mentionné. Ça a été suffisamment développé ailleurs[0], je ne pense pas que ça mérite de l'être encore sans aucune question précise. Si critique ou question il y a, cependant, je serais ravi de te répondre. Mais pour celà, il faudra garder en tête le maître mot : argumentation.
Bon, c'est une question bien difficile, et que je ne trouve pas d'une pertinence extrême, en réalité. Je m'étais pourtant tenté à quelques éléments de réponse dans une précédente nouvelle ici-même, sur le sujet, intitulée de façon très ... polémique « GNU/Linux est mort, vive GNU ! » [0] .
Je compléterai - je ne pense pas l'avoir assez dit dans ces précédents commentaires, depuis lesquels ma façon de voir les choses et, surtout, de les expliquer a pas mal changé - en insistant sur le fait qu'on parle ici de deux variantes du système GNU[1], donc la comparaison au niveau de l'utilisateur final est quelque peu biaisée : la base du système d'exploitation n'a qu'une influence indirecte - ce qui ne signifie pas qu'elle n'est pas capitale - sur ce que voit, peut faire, et fait un utilisateur « de base ». Les repercussions sont quand même très importantes : la stabilité - un utilisateur de base ne voit peut-être pas que c'est le driver à deux balles de son périphérique quelconque à deux balles qui crashe, mais le crash, il le sent :-) ; la rapidité - la flexibilité entraîne une amélioration de la rapidité et de la « légèreté » importante; on pense notamment à la possibilité d'échanges de contrats concernant les ressources systèmes, comme dans le cas du VMM du Hurd pour L4[2] ; la sécurité - le système complètement modulaire, adaptable à tout type de sécurité (les « authentication tokens » sont génériques, ils peuvent s'appliquer aux capabilities, aux UIDs, mais aussi à une gestion des droits beaucoup plus fine) permet de limiter les dégâts occasionnés par un trou de sécurité.
Tous ces points, je les ai développés ailleurs et en d'autres temps ; je suis ouvert à toutes questions, ici ou ailleurs (le temps se resserre ici, sur DLFP coulent les news et nos questions). Au hasard, sur la ML HurdFr[3] :-)
Le GNU/Linux est considéré comme un noyau monolithique. Mais alors peut on encore parler de système de noyau en bloc, à partir du moyen où l'utilisation des modules kernels reduisent le role du kernel à un simple "gestionnaire" de modules externes ?
Oui, définitivement, oui. Tu dois remarquer toi-même, dans ta phrase, une contradiction flagrante : tu parles de module noyau. Tu es bien conscient que ces modules n'ont aucune autonomie, et qu'il s'agit juste de bouts de code qui seront ajoutés ou enlevés dynamiquement - c'est le principe des LKM. Ces bouts de code, une fois intégrés, font partie du noyau au même titre que ceux qui n'auront pas été chargés dynamiquement. Alors, le noyau n'est plus un gestionnaire de modules externes, puisqu'il comporte les parties qui étaient dans les modules. La modularité qu'implique l'utilisation de LKMs - très intéressante, cependant - n'est qu'une astuce pratique pour facilité la vie des utilisateurs : elle ne constitue en aucun cas une modularité de design, en aucun cas une modularité « logique » : si tu dois faire un schéma des différentes fonctions de l'OS, et par qui elles sont assurées, tu devras toujours faire un schéma avec un énorme (puisqu'il contiendra plein de cases avec ce qu'il fait, donc pas au sens de l'espace disque) noyal au milieu : un noyal monolithique.
Il faut bien aussi voir que s'il est difficile de discriminer parfaitement un micro-noyau d'un noyau monolithique, c'est parce qu'il s'agit également d'une question d'esprit, d'évolution, de volonté dans la conception du noyau, et pas seulement qu'une question des fonctionnalités que l'on peut avoir en espace utilisateur et superviseur (et en aucun cas, une question de taille). Mach, par exemple, bien que fournissant la majeure partie de son VMM en kernel space (toute la partie concernant la décision de quelles pages est swapped ou swapped in se trouve dans le noyau), fournit un certain mouvement vers l'espace utilisateur en fournissant le principe de memory objects et de backing store, délégant la responsabilité du choix du traitement de ces pages swapped out à un pager (page fault handler), qui sera chargé de les restituer quand y'en aura besoin (en cas de page fault). C'est, en fait, sur ce principe que sont implémentés les systèmes de fichier en espace utilisateur - et on imagine l'avantage qu'une telle approche fournit par rapport à des systèmes distribués, avec une mémoire distribuée, par exemple. Ces innovations, cette optique, plus le fait qu'une grande partie soit déjà délocalisée, en fait vraiment un micro-noyau. Ce qu'on ne peut pas dire de Linux. Linux, lui, a pour optique, de l'avis même de Linus Torvalds, une optique qui n'est pas celle du design, mais celle d'un pragmatisme technique. Ainsi, le cas de la VMM est intéressant : si l'on prend par exemple la VM rmap, on ne peut dire qu'elle n'est pas designée : elle est réfléchie, pensée, structurée, articulé autour d'un principe de reverse-mapping qui se justifie totalement, et le fait est que techniquement, c'est, à mon avis, une excellente VM.
En revanche, a-t-elle un vrai design de structure ? De la même façon que Linux, je ne le pense pas : il s'agit simplement d'une entité monolithique, ou tout est ensemble, les fonctions pas ou peu séparées logiquement, juste un programme, comme ça. Le cas de Mach évoqué ci-dessus montre un réel effort de design, puisqu'il y'a une séparation logique entre le "Who?" et le "Where?", permettant déjà une modularité et une adaptabilité qui change la vie. Voilà, ce que veut dire la modularité, et le design du Hurd. C'est encore plus vrai dans le cas de la VMM qui a été concue pour le Hurd sur L4[0].
Peut on encore parler de noyau monolithique à partir du moment où le plantage d'un module n'entraine pas l'arret complet du système ?
Euuuuh, ce ne serait plus des modules, mais des entités séparées. Ce qui n'est pas le cas actuellement. Je le dis et le répète : ce qui change dans un module, c'est la façon d'arriver dans le kernel, et le fait qu'on puisse le virer puis le remettre dynamiquement. C'est uniquement une facilité technique. Ils ont donc exactement les mêmes droits que ceux qui sont déjà dans le noyau. Ils peuvent provoquer l'arrêt complet du système, le plantage complet du noyau. Pensons par exemple aux drivers (libres) du winmodem du portable de Kilobug qui plantent quand on joue un ogg en se connectant :-)
La multiplication des systèmes d'exploitation "libres" (xBSD, Linux, Hurd), et je ne parle pas des multiples distributions linux ou version xBSD, ne risque t-il pas d'amener un peu plus de confusion chez les utilsateurs des dits systèmes, alors qu'une certaine cohésion commence (enfin) à se faire jour autour de GNU/Linux ?
C'est réellement une fausse question. Le problème est, il faut que les utilisateurs aient une vue d'ensemble assez globale du paysage disponible. Celà ne veut pas dire, des préjugés à deux balles qu'ils répandent sur les newsgroups du genre « Nunux c'est pour les débutants, ensuite c'est BSD pour les vrais proZ, etc. ». Ça veut dire avoir quelques éléments de base théorique, qui vont permettre de dire « Bon, voilà, les deux sont des trucs qui sont de la même famille, compatibles, y'a les mêmes logiciels dessus, c'est donc ce qui est très bas niveau qui change, genre tout ce qui va concerner le matos, etc. ». Ça va pas très loin, ça nécessite pas grand chose, mais ce serait heureux qu'un utilisateur basique sache un minimum d'informatique. Comment ça, utopiste ? (:
Si l'on ne parle pas d'opposition, alors j'ai un peu de mal à comprendre la complémentarité entre les deux systèmes. Existe t-il un système "libre" plus performant que l'autre (vitesse, éxécution des programmes, gestion de la MC, gestion des périphériques), de telle manière que le système le plus rapide pourrait servir pour "des expérimentations" et l'autre pour une production en entreprise ?
Si l'on ne parle pas d'opposition, c'est plus pour éviter le sous-entendu de rejet mutuel et de non communication entre les deux mondes. Linux, de par son excellence technique, a beaucoup à nous apprendre. Le Hurd pourrait apprendre pas mal de choses aux développeurs Linux. Pour l'instant, il n'y a pas « compétition » : les développeurs de GNU/Hurd utilisent GNU/Linux pour travailler, et l'un sert à l'autre. Il sert aussi à l'autre dans la mesure où il permet la promotion du libre, et le développement de logiciels libres, qui marcheront ensuite sous GNU/Hurd. Cependant, il ne faut pas se leurrer : GNU/Linux et GNU/Hurd se veulent des systèmes adaptables à à peu près toutes les possibilités - GNU/Hurd surtout, bien entendu ;-) Ils s'adressent donc au même public : tous ! Ensuite, le minoritaire pourra être utilisé pour des tâches où les avantages de l'autre ne comptent pas vraiment - changer le coeur d'un OS change beaucoup de choses, mais il ne peut pas tout.
Cette dernière question est la suite logique de la troisième, à savoir : Ces deux systèmes (diamétralement) opposées dans leur conception de base, peuvent ils etre compatibles au niveau des binaires, comme cela existe avec les Unix commerciaux et le GNU/linux avec le module IBCS ?
Oui, ils peuvent l'être, moyennant un effort. GNU/Hurd fournit une couche de compatibilité POSIX dans la GNU C Library, dans une certaine mesure il fournit aussi une compatibilité plus spécifiquement Linux et avec le port Linux de la GNU C Library, bien qu'à l'origine, il ait plus tendance à se rapprocher de BSD au niveau de ses interfaces - origines de Mach obligent, on retrouve les slices, la gestion des interruptions (niveaux de priorités, soft interrupts en « couches », ...). Il suffirait de presque rien, peut-être quelques symboles de plus, pour que te je dise : il y'a compatibilité binaire. (comment ça, c'est mauvais ?! :-). Cependant, je ne pense pas que ce soit une priorité, pour moi comme pour tous les développeurs de GNU/Hurd. Il me semble que la compatibilité sources devrait être assez, et qu'une compatibilité binaire ne peut engendre qu'une série de problèmes qui n'ont que peu d'intérêts. Ah, à moins que vous vouliez parler de logiciels propriétaires .. auquel cas vous oubliez qu'on parle ici du système GNU, l'officiel, le seul système d'ailleurs (« There is no system but GNU »), et que la possibilité du propriétaire ne rentrera aucunement dans nos priorités.
Bon, j'en profite pour répondre à l'ensemble du thread.
-Il y a sur savanah un projet l4hurd consacré au port de Hurd sur micronoyau L4. C'est tellement actif que ça a l'air abandonné depuis 6 mois? Quelqu'un a des infos sur ce projet ?
Les problèmes d'organisation à L4Hurd .. :-) Bien difficile à expliquer. En fait, à l'origine, L4Hurd - c'est le nom qu'on donne habituellement au port du Hurd sur L4, n'y voyez aucun caractère officiel ou logique, il a juste le mérite de ne comporter aucune ambiguïté - est en fait un projet discuté depuis d'assez nombreuses années. La mailing list l4-hurd a été créée en octobre 2000, si mes souvenirs sont bons, et à l'époque, c'était Yoshinori K. Okuji, qui avait participé à pas mal de choses concernant le Hurd et GNU Mach, et qui est l'auteur de Grub, qui voulait le démarrer. Farid Hajji, à l'époque, voulait également participer au port. Les deux sont des gens que je respecte, ayant un niveau de connaissances techniques générales, et sur le Hurd et Mach en particulier, qui dépasse la plupart des gens - qui dépasse le mien, sans hésiter, même si on finit par atteindre des niveaux similaires. Mais, ils n'ont pas la même vision, je pense, que Thomas, Marcus ou Neal, du développement, et étaient plus dans une approche pragmatique de perfection technique quant aux rouages internes. Ainsi, une VMM à peu près « monolithique » (bien qu'en user space) qui reprendrait les bases de UVM (la VM de NetBSD (les médisants (et les épitéens) disent que c'est la seule chose de bien dans NetBSD .. :-> (et les intelligents que lisp ownaize)) avait été prévue. Ce port se fondait sur la version des API précédente, qui a abouti à Hazelnut, dernière implémentation de L4 sortie du projet L4Ka. Mais, rien de concret n'a *vraiment* été fait, Okuji et Farid ayant très peu de temps.
Là-dessus est arrivé Neal H. Walfield, développeur du Hurd depuis environ 1999, qui a eu la chance de rencontrer, lors du 18C3 (18ème Chaos Communication Congress (où Neal avait donnée une conf sur le Hurd dont on peut trouver les transparents sur http://web.walfield.org/papers/hurd-conference-ccc-20011228/(...) )), un certain nombre de gens travaillent sur L4, principalement les gens de l'université de Dresden - projet L4Ka. C'est à cette occasion là que Neal, comme Marcus, furent convaincus de la nécessité du port sur L4 - et suite à ça que le premier pas de L4Hurd va être suivi, avec la décision de Neal de passer son été avec les gens de L4Ka pour coder le portage. Ne rêvez pas, ça ne veut pas dire qu'il avait fini au bout :-) Il est très difficile de définir autant de nouvelles interfaces en si peu de temps, surtout quand on a pas envie de vivre reclus, et Neal n'est pas tout à fait le genre à vivre reclus ;-) Dans tous les cas, un certain nombre de choses avaient été définies, dont notamment l'ensemble des serveurs nécessaires, la gestion de choses comme les privileged system calls, la façon dont serait gérée le VMM[0].
Ian Duggan, et le projet L4Hurd enregistré sur Savannah, font partie de la suite du projet de Okuji et Farid, fondé sur Pistachio, et pour lequel peu ou rien n'a été fait - Pistachio est réellement le seul à nous intéresser, en réalité. Il est donc normal qu'il soit inactif. Le code fait par Neal H. Walfield et auquel on a contribué n'est disponible que dans un CVS privé - il ne mérite pas réellement l'attention, c'est plus les mails et les idées qui en ont résulté qui la mérite. Et, surtout, il repose entièrement sur l'API d'un Pistachio pas encore sorti, donc ..
-Il y a des réussite de hurd/GnuMach sur PPC, d'après Google... Quelqu'un a un lien qui explique comment faire que je me tente ça aussi ?
Et si jamais la licence n'est pas sympathique du tout, qu'est-ce qui se passe ? Réimplémentation libre de la version X2 de l'interface ? Abandon du projet L4Hurd ? On l'utilise en attendant une réimplémentation libre ou un changement de licence ? (à la manière de KDE et Qt à leurs débuts) Bref, qu'est-ce qui se passe ?
Une très bonne question, que je vous remercie d'avoir posée :-) Bon, d'abord, ce qui ne se passera pas : en aucun, aucun cas, il n'y aura abandon du projet L4Hurd. Et, on n'utilisera pas une version non-libre, il n'en est évidemment absolument pas question - bien que le problème soit différent que KDE et Qt, parce que l'exception de la GPL concernant les bibliothèques et outils essentiels au système serait facilement exploitable « légalement ». Bon, dans tous les cas, il est clair, net, et précis, que la licence de Pistachio, dont des pre-releases devraient être publiées d'ici quelques semaines à peine, des dires des développeurs qui s'y affairent, devrait être « sympathique ». C'est à dire, probablement quelque chose autour du BSD. Dans cette perspective, et vu le bon boulot des gens de L4Ka, une réimplémentation à nous utilisant les interfaces X2 (de Version4, plus généralement) n'est pas à l'ordre du jour.
[0]: http://web.walfield.org/papers/better-best-effort-20021026/(...)
[1]: http://mail.gnu.org/archive/cgi-bin/namazu.cgi?query=pjbruin&su(...)
Dans la série boulet intergalactique, après chris, je voudrai .. mmenal !
Bref, j'ai oublié les notes que je voulais laisser. Les voici :
[0]: http://www.gnu.org/software/hurd/hacking-guide/hhg.html
[1]: http://www.8ung.at/shell/ en allemand, mais tout à fait compréhensible :-)
[^] # Re: Nouvelle version des ISOs de Debian GNU et quelques infos sur le GNU Hurd
Posté par Manuel Menal . En réponse à la dépêche Nouvelle version des ISOs de Debian GNU et quelques infos sur le GNU Hurd. Évalué à 10.
Comme ça a déjà été discuté ici, il y a quelques temps Neal H. Walfield, un des développeurs principaux du Hurd (même s'il se consacre en ce moment à ses études plus qu'à l'informatique), a passé l'été à l'université de Karlsruhe, en compagnie de l'équipe L4Ka qui développe l'implémentation L4 la plus neuve et intéressante du moment (à mon avis), L4Ka::Pistachio. Il a pu, d'après ses discussions et ses tentatives de code, estimer le travail à faire et fournir pas mal d'éléments de réflexions, ainsi que code. Il a notamment réalisé un travail capital en documentant et concevant entièrement le nouveau système de VMM pour le Hurd sur L4 (qui est, soit dit en passant, une petite merveille. :)
Ce travail réalisé par Neal, de rapprochement entre les deux équipes (consacré par une réunion L4Ka/principaux développeurs du Hurd au CCC en décembre d'après), a permis de convaincre les principaux développeurs - Marcus, Neal, Marco, Roland, ... - de la nécessité et de l'intérêt du port du Hurd sur L4. À partir de là, tout s'enchaîne : aujourd'hui, la plupart des développeurs du Hurd se concentrent sur le port L4, qui dispose d'un CVS, qui n'est pas vide comme suggeré ci-dessus (hurd-l4 sur le CVS habituel du Hurd, à la place de hurd.) Il est bien évident qu'autant de travail prendra du temps, et des personnes. Il faut que chacun des développeurs se familiarise avec les nouveaux concepts à traîter, avec les nouveaux problèmes rencontrés, et propose des solutions efficaces et flexibles. Loin d'être évident, donc, et pas aussi rapide que de coder, une nouvelle console, un nouveau ftpfs, etc. :)
Quant à la portabilité : à vrai dire, le Hurd en l'état devrait déjà être très portable. Un port sur PowerPC a été réalisé par Peter Bruin, utilisant le port de CMU Mach sur PPC. OSF/CMU Mach - sensiblement identiques à GNU Mach - étant portés sur nombre d'architectures (Sparc, Alpha, M68K, PowerPC, x86, j'en passe, et des meilleures). Le principal problème : il n'existe pas de bootloader adapté (i.e., respectant le standard multiboot) sur ces architectures. (balo, hein :) C'est pour cette raison que certains développeurs se concentrent aujourd'hui sur la nouvelle version de Grub (codename: PUPA, disponible en Sid pour les Debianeux), bien avancée, et hautement portable, avant de se reconcentrer sur le Hurd sur L4 en lui-même. (c'est le cas de Marco Gerards, pour ceux qui suivent les listes et se demandaient où il est passé :)
Bien entendu, le port sur L4 permettra d'avoir une plus grande portabilité, dans la mesure où L4Ka::Pistachio (l'implémentation utilisée) est porté sur nombre d'architectures (IA-32, IA-64, PowerPC, Alpha, MIPS, et d'autres sont en cours), et surtout activement utilisé et testé par d'autres projets. Avoir une base stable, ça aide. :-)
[^] # Re: ISO vs. Gidgoo
Posté par Manuel Menal . En réponse à la dépêche Nouvelle version des ISOs de Debian GNU et quelques infos sur le GNU Hurd. Évalué à 10.
C'est en cela qu'il faut saluer le travail réalisé par Philip Charles, qui contribue activement à GNU/Hurd à sa manière et avec son temps et ses compétences, en collectant les paquets, la documentation, en tentant - avec l'aide de Jeff Bailey - de faire fonctionner les outils Debian (deboostrap, ...) avec GNU/Hurd. En effet, beaucoup de paquets centraux - on pense notamment à XFree86 - dans Debian GNU/Hurd nécessite aujourd'hui des petites manips, des petits hacks pour compiler ; ils ne peuvent donc pas faire partie de l'archive officielle Debian (qui requiert que les paquets s'autocompilent, et tend à éviter les uploads de paquets binaires). Ces paquets sont disponibles sur d'autres sources - principalement ftp://ftp.gnuab.org(...) mais aussi d'autres. Il faut donc les collecter, les tester, vérifier qu'ils s'intégrent bien. De plus, l'autobuilder fonctionnant plutôt .. aléatoirement, et quand il y a Jeff à côté (en attendant mieux), la plupart sont compilés à la main, et uploadés sur des sites comme gnuab.
De plus, Debian GNU/Hurd utilise aujourd'hui un système basé sur Linux pour son installation ; c'est plutôt compliqué et « tricky », ça nécessite pas mal de maintenances - il n'y a qu'à voir le numéro de ces ISOs : K5, il y a eu K-A+1== 11 révisions portant sur la structure même des CDs (changement d'organisation, mais surtout couramment changement sur la procédure même d'installation).
Voili voilà, donc, ça ne marchera pas. Et au passage, merci à Philip Charles pour ce travail de titan qui facilite grandement l'installation de Debian GNU/Hurd. (ah, et puis, on écrit Jigdo si je ne m'abuse :)
[^] # Re: Licence non libre?
Posté par Manuel Menal . En réponse à la dépêche RealNetwork passe son SMIL en opensource. Évalué à 1.
(d) You must make Source Code of all Your Externally Deployed Modifications publicly available under the terms of this License, including the license grants set forth in Section 3 below, for as long as you Deploy the Covered Code or twelve (12) months from the date of initial Deployment, whichever is longer. You should preferably distribute the Source Code of Your Deployed Modifications electronically (e.g. download from a web site); and
D'après les définitions de la première section, l'utilisation du logiciel dans un contexte professionnel non-R&D est une forme de "Deployment"; il est donc interdit de faire des modifications dans son coin du logiciel, de l'utiliser dans sa boîte, sans distribuer ces modifications. On a là une violation évidente, me semble-t-il, du fameux « privacy right » énoncé sur http://www.gnu.org/philosophy/free-sw.fr.html(...) ainsi :
Vous devez aussi avoir la liberté de faire des modifications et de les utiliser à titre personnel dans votre travail ou vos loisirs, sans en mentionner l'existence. Si vous publiez vos modifications, vous n'êtes pas obligé de prévenir quelqu'un de particulier ou de le faire d'une manière particulière.
Cette licence me semble donc poser le même problème que l'APSL sous laquelle est distribué Darwin, le coeur de MacOS X. Revenons cependant (dans le même post, je m'en excuse) sur ce que Daganf disait plus haut:
(c) You agree not use any information derived from Your use and review of the Covered Code, including but not limited to any algorithms or inventions that may be contained in the Covered Code, for the purpose of asserting any of Your patent rights, or assisting a third party to assert any of its patent rights, against Licensor or any Contributor.
Je ne vois effectivement pas, comme Boa treize, Arachne et Philippe Plantier ce qui peut vous paraître incompatible avec les définitions du libre de la FSF ou de Debian (les fameuses DFSG) dans ce point. Il ne s'applique de toutes façons pas en Europe, et j'espère que cette situation durera. Et dans tous les cas, il oblige juste la personne voulant attaquer en justice le "Licensor" à fonder ses arguments sur d'autres choses que du code obtenu via cette licence. Rien de particulièrement choquant ici : de toutes façons, la question des brevets dans les licences est un casse-tête sans fin auquel ni la FSF, ni Debian, ni l'OSI n'ont clairement répondu, et il vaudrait mieux ignorer tout article concernant les brevets si l'on souhaite déterminer s'il s'agit d'une licence de logiciel libre ou non.
Quant au point signalé par Branden, je ne suis sincèrement pas convaincu. Surtout que je ne suis pas sûr que cet article change quoi que ce soit quant aux problèmes d'exports : elle me semble juste un moyen pour Real de se protéger nettement des interprétations douteuses ou limite des lois sur l'export telles qu'elles existent aux États-Unis.
Disclaimer: IANAL (I Am Not A Lawyer). Je suis ce genre d'affaires depuis pas mal d'années, mais plein de choses m'échappent et j'en apprends chaque fois un peu plus.
[^] # Re: Version 0.1 de L4Ka:Pistachio disponible
Posté par Manuel Menal . En réponse à la dépêche Version 0.1 de L4Ka:Pistachio disponible. Évalué à 2.
Voici une réponse que j'avais faite : <http://linuxfr.org/2002/01/02/6461.html(...)actualité dans deux/trois jours, le temps que je sois libre.
[^] # Re: Sortie de WineX 3.0
Posté par Manuel Menal . En réponse à la dépêche Sortie de WineX 3.0. Évalué à 10.
Le seul probleme, je crois, pour winex, est sur la licence mais je laisse les specialistes en debatre : http://www.transgaming.com/license.php(...)
PERSO JE CONSEILLE WINEX ;)
Tu peux considérer que le côté libre, Open Source, ou quoi que ce soit de la licence t'importe peu - je le réprouve, mais je le conçois et l'accepte. En revanche, sans avoir pris connaissance de la licence tu ne peux toujours pas savoir si elle est acceptable à tes yeux ou non : et je doute que toute licence le soit à tes yeux - une licence qui autoriserait les auteurs de WineX à vérifier les logiciels que tu utilises avec, pour vérifier si tu as les licences, te semblerait probablement inacceptable. De plus, tu ne peux même pas savoir si un tel produit est simplement _légal_, s'il ne viole pas des licences. Et ça n'est pas du tout évident, étant donné que Wine est maintenant sous licence LGPL, licence qui ne permet pas l'inclusion du code dans un projet à la licence incompatible.
Bref. À la licence. Le lien que tu donnes semble nécessiter d'être enregistré, http://www.transgaming.com/license.php?source=1(...) semble mieux marcher. Où l'on apprend qu'il y'a des portions :
InstallShield Engine components Copyright(c) 2001 InstallShield Software Corporation.
MSVCRT Runtime library Copyright(c) 1999 Microsoft Corp.
.. ce qui n'est plus mentionné dans les fichiers de licence, etc., dans le CVS - logique, je doute que ces deux entreprises fournissent les sources, ou en tous cas les sources sous une licence permettant la redistribution. Voir <http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/winex/win(...)
Où l'on apprend ensuite que les parties Copyright Transgaming sont couvertes pas l'AFPL (Aladdin Free Public License). Il faut savoir que cette licence est non-libre, comme évoqué sur <http://www.gnu.org/licenses/license-list.html(...)
Ils semblent adopter concernant le code source originel de Wine une attitude double : d'abord, les composants qu'ils reprennent pour inclure directement dans le source de WineX semblent être issus des versions de Wine publiées sous licence X11 (licence qui permet ceci). Cependant, ils utilisent les versions de Wine publiées sous licence LGPL pour les "DLLs", qui seront alors sous forme de bibliothèque, et avec lesquelles ils pourront donc lier librement. Il reste à vérifier par quelqu'un utilisant, connaissant, WineX que (1) ils n'utilisent ces portions de code que dans les DLLs (2) ils ne font que de l'édition de lien dynamique (dynamic linking?) et non statique avec ces DLLs.
Voili, voila, my 2 cents. Je n'ai donc pas trouvé d'illégalité à vue de nez - mais il est clair que le logiciel est tout sauf libre.
[^] # Re: preter des LL
Posté par Manuel Menal . En réponse à la dépêche logiciels libres en bibliothèque. Évalué à 7.
La GPL implique d'être en mesure de fournir les sources du soft. Ceci ne risque t'il pas de poser des problèmes pratiques ?
Bien entendu. D'un point de vue légal, c'est une obligation. D'un point de vue pratique, ça n'est pas bien dûr à réaliser - peu de gens, en pratique, demandent (malheureusement?) le code source des logiciels, il suffit donc pour la bibliothèque de graver quelques CDs de sources, ou même simplement d'ajouter dans les CDs les sources s'il reste suffisamment de place sur le support. Je ne pense pas que ce soit un obstacle, concrètement.
La GPL autorise les modifications sur le soft. Est il acceptable, dans le cadre d'un prêt au public, que l'oeuvre prétée soit rendue altérée ?
Il y'a, lors du prêt de logiciel un contrat implicite entre le prêtant, la bibliothèque et l'emprunteur. Il suffit de préciser dans ces conditions qu'on considère que le support et l'information sur ce support doivent être retournés exactement dans l'état où ils ont été empruntés. Ceci n'est en aucun cas incompatible avec la GPL, qui ne précise évidemment rien quant au support : l'auteur pourra toujours redistribuer une version modifiée. J'espère cependant que les bibliothécaires en charge seront assez intelligents et ouverts pour considérer l'intégration du logiciel modifié s'il en vaut la peine. Il va sans dire cependant que pratiquement, il est impensable de prêter des logiciels sur un support RW dans une bibliothèque.. la seule restriction qu'imposera la GPL, c'est qu'il n'existe aucune protection contre la copie sur ce support.
Il n'y a, à mon avis, dans la GPL, rien qui soit incompatible avec le prêt en bibliothèque. Il est cependant vrai qu'il existe dans le cas des logiciels un contrat spécifique qui n'existe pas dans le cas des livres - qui sont directement couverts par la législation sur le droit d'auteur (les mentions "Tous droits réservé", etc. ne doivent être que des rappels), législation qui concerne tout le monde, que vous l'ayez explicitement accepté ou pas (nul n'est censé ignorer la loi). Cette différence obligera l'étude au cas par cas des licences - on pense notamment à une licence qui obligerait toute personne possédant une version modifiée d'un logiciel à la signaler à l'auteur originel si celà n'a pas été déjà fait (avec un moyen de quelconque de vérifier que ça n'a pas déjà été fait). Les bibliothèques peuvent difficilement se permettre de vérifier que tous les logiciels n'ont pas été modifiés (quelqu'un qui subtilise le CD et le remplace par un autre, etc.). Donc, dans la légalité pure (on doute bien sûr qu'un créateur de logiciel attaque une bibliothèque pour ça, mais nous ne sommes plus à une absurdité près dans le domaine de la PI), une bibliothèque ne devrait pas accepter de tels logiciels - qui ne seraient pas bien sûr, des logiciels libres, mais seraient en revanche Open Source (voir le privacy right dans mon commentaire plus haut), puisqu'elle n'est pas en mesure d'appliquer la licence.
Reste à déterminer s'il pourrait exister une licence libre incompatible avec le prêt en bibliothèque. Si oui, il faudrait certainement qu'un organisme se charge de cette vérification. Difficile à réaliser.. mais espérons !
[^] # Re: BCDI ??
Posté par Manuel Menal . En réponse à la dépêche logiciels libres en bibliothèque. Évalué à 10.
Il faut de plus savoir que le CRDP de Poitou-Charentes fournit en accompagnement de BCDI des « mémofiches » (<http://www.crdp-poitiers.cndp.fr/igdoc/memof.htm(...)il existe déjà un certain nombre de services payants autour de BCDI rendrait son passage sous une licence libre encore plus facile. Difficile cependant de faire entendre sa voix.
[^] # Re: logiciels libres en bibliothèque
Posté par Manuel Menal . En réponse à la dépêche logiciels libres en bibliothèque. Évalué à 10.
L'Open Source et les logiciels libres sont issus de deux mouvements ayant des objectifs communs, mais des visions radicalement différentes ; ils sont complémentaires en ce sens qu'ils insistent sur deux facettes de ce qu'on a perdu avec la propriétarisation des logiciels, avec le développement de ce qu'on appelera « l'industrie du logiciel ».
Le mouvement Open Source défend une certaine vision du logiciel qui est fondée sur des raisons « pragmatiques » : ils soutiennent, et tentent de prouver, que le fait de pouvoir lire, redistribuer et modifier le code source d'un logiciel permet la création de logiciels plus performants, plus évolués, plus sûrs et ceci plus rapidement. Ils insistent donc sur le côté pratique, méthodologique, un peu comme le feraient les fameuses méthodes de développement à la eXtreme programming (beuark). Et de ceci résulte une définition, qui est l'Open Source Definition. Cette définition a été écrite par Bruce Perens en '97, issue des « Debian Free Software Guidelines » qu'il a lui-même écrits. C'est dire si elle entretient des liens étroits avec le logiciel libre. Bruce Perens lui-même, a d'ailleurs plus tard déclaré qu'il préférait le terme logiciel libre - voir <http://www.fsfeurope.org/documents/whyfs.en.html(...)
Le mouvement du logiciel libre défend lui une toute autre vision du logiciel, une vision dont la base même est incrite dans le terme : la liberté. Il se veut défenseur de la liberté de chacun, d'une liberté d'accès à la connaissance, défenseur de valeurs de partage et d'enrichissement - l'action qui résumerait la mieux, à mon avis, cette vision est la demande de classement des logiciels libres comme patrimoine de l'Humanité <http://www.fsfeurope.org/projects/mankind/mankind.fr.html(...)Vous devez aussi avoir la liberté de faire des modifications [...] manière particulière), qui fait que l'APSL (Apple Public Source License, la licence sous laquelle est distribué Darwin, le coeur de MacOS X) est une licence Open Source, mais pas une licence libre.
Les différences entre l'Open Source et le Logiciel Libre, d'un point de vue strictement « légal » sont minimes ; très peu de licences sont Open Source et non libre, et aucune, à ma connaissance, n'est l'inverse. Et souvent, ça n'est pas tellement par différence de définition qu'une licence est acceptée par l'OSI et pas par la FSF, mais par une différence d'interprétation d'un point de licence. La différence de vision entraîne cependant ce qui crée la majeur partie des critiques et flamefests autour de la GPL: le copyleft. Dans l'optique du logiciel libre (mettons, dans l'optique de <http://mmenal.nerim.net/quest(...)http://www.fsf.org/copyleft/copyleft.fr.html(...)m a dreamer .. »).
[^] # Re: Quel moteur de recherche ?
Posté par Manuel Menal . En réponse à la dépêche Quel moteur de recherche ?. Évalué à 1.
[^] # Re: First jeudi d'avril et éventuel changement de lieu
Posté par Manuel Menal . En réponse à la dépêche First jeudi d'avril et éventuel changement de lieu. Évalué à 3.
Pas bien important tout ça. Enfin, pour le sous-bock, pour un first de maintenant, c'est bofissime. Et pour le Flam's, c'est pas mal pour des bouffes exceptionnelles (la bouffe LinuxFR du 29 septembre 2001), mais je vote [CONTRE] pour le first.
[^] # Re: Et les drivers ?
Posté par Manuel Menal . En réponse à la dépêche Démarrage du projet Gentoo GNU/Hurd le 13 Mars. Évalué à 1.
[^] # Re: Et les drivers ?
Posté par Manuel Menal . En réponse à la dépêche Démarrage du projet Gentoo GNU/Hurd le 13 Mars. Évalué à 7.
Sauf dans l'optique d'un système de fenêtrage conçu proprement pour utiliser les spécificités d'un système multi-serveurs à micro-noyau de seconde génération comme GNU/Hurd sur L4.. :-) Ce qui offre des possibilités infinies, notamment permettrait une gestion clean et efficiente des drivers - il utiliserait pas son propre système de pilotes, mais bien le framework fourni par le système.
Pour le reste, on utilise actuellement OSKit, donc les drivers de Linux 2.2 ou FreeBSD jenesaispluscombien.
On n'utilise en fait que les pilotes de Linux 2.2.12, mais il serait hypothétiquement possible d'utiliser les pilotes de FreeBSD v2.1.7.1 (hé, ça explique peut-être qu'on les utilise pas, pour ceux qui suivent le développement de FreeBSD.. bien qu'il soit infiniment plus agréable d'utiliser, lire, développer des pilotes pour FreeBSD que pour Linux, à mon humble "avis").
A terme, on aura des drivers en user-space sur L4, et il faudra probablement réécrire pas mal de choses.
Voire, tout. Il faut bien comprendre que la portabilité inter-systèmes, dans l'esprit du GNU Manifesto (et plus spécifiquement dans mon esprit (: ) est une bonne chose, mais ne doit se faire en aucun cas au détriment du reste - c'est à dire, si faire le logiciel comme on pense que ça doit être fait implique utiliser des spécificités de GNU, il faut le faire (et si ça implique utiliser des spécificités d'autres systèmes, il faut les implémenter sous GNU :-). Or, utiliser des pilotes de périphériques conçus, par exemple, pour Linux, entraînera forcément une perte de performances, qui ne sera pas compensée, étant donné qu'ils ne tireront pas partie des avantages offerts par L4 et le Hurd. On pense notamment au fait que les pilotes de périphériques écrits pour Linux sont conçus pour avoir une mémoire « wired », inamovible (imaginez le bordel avec un kernel dont la mémoire est pageable (: ), alors que les pilotes en espace utilisateur peuvent - et devraient, à mon avis - être conçus pour tirer parti du fait que la mémoire puisse être « paged out » en cas d'utilisation intensive de la mémoire par d'autres applications. Voire, même, pour certains périphériques très particuliers, avoir un schéma de gestion de la mémoire plus complexe qui permettrait une certaine perte pendant les périodes de charge mémoire très forte, sans que pour autant le système sature d'autant plus.
Bien entendu, celà n'est qu'une question d'implémentation, et Linux nous apportera beaucoup dans la mesure où les pilotes pourront servir de spécifications, spécifications en plus déjà mises en applications, donc où l'on pourra voir les workarounds de Linux aux différents bugs des différents modèles de la carte trucmuche, etc. Que du bon en perspective ;-)
[^] # Re: DIscussion avec Luc Ferry ?
Posté par Manuel Menal . En réponse au journal DIscussion avec Luc Ferry ?. Évalué à 1.
C'est en fait similaire à l'utilisation d'un : <a href="http://mmenal.nerim.net/quest(...)">Ce texte</a> plutôt que "Allez voir <a href="http://mmenal.nerim.net/quest(...)">http://mmenal.nerim.net/quest(...) </a>. Rien de bien passionnant .. :-)
[^] # Re: OCR sous Linux : comparatif
Posté par Manuel Menal . En réponse à la dépêche OCR sous Linux : comparatif. Évalué à 10.
Bon, ceci dit, ce sont bien les conneries du système des XPs qui sont en jeu ici. Dommage simplement que, malgré des propositions concrètes, il n'y ait pas eu de discussions et de réflexion à ce propos. (et le "envoie un patch" est un peu facile)
[^] # Re: OCR sous Linux : comparatif
Posté par Manuel Menal . En réponse à la dépêche OCR sous Linux : comparatif. Évalué à 10.
[^] # Re: OCR sous Linux : comparatif
Posté par Manuel Menal . En réponse à la dépêche OCR sous Linux : comparatif. Évalué à 10.
J'avoue avoir terriblement hésité, mais je me suis dit que ce serait plus drôle .. :-p
D'où vient le RN, si ce n'est pas indiscret ? Amygdalia ?
(Pour ceux qui ne sont pas « dans le bain », Amygdala <http://amygdala.sourceforge.net/(...)
Non. J'y ai bien pensé, j'ai bien suivi Amygdala, et j'ai lu le code activement. Je fus très intéressé, je le serai sans doute dans le futur : le premier problème est, j'aurais sans aucun doute (et j'ai eu, ça n'a pas manqué) à changer le code de mon RN, et pour ça, il faut que je sois parfaitement à l'aise avec le source. Le code d'Amygdala n'est pas illisible comme l'est beaucoup de code dans ce domaine, mais il est en C++, qui n'est pas tout à fait un langage que j'apprécie.
Je me voyais mal me piquer des crises de nerf sur du C++ :-) D'autant plus que bon, de toutes façons, il aurait fallu que je fasse des bindings, le reste de mon programme étant en C. (allez, j'avoue, y'aura du Guile pour les scripts d'extension .. :-) Bref, trop de boulot. J'ai donc fait ma propre implémentation (à partir d'anciens exercices à moi) assez simple, d'un réseau de neurones. Il est assez performant, bien que très simple. Assez adaptable, puisqu'il lit tout dans un fichier (dont je devrais changer le format, je pense (peut-être du XML, pour faire `in' ? :-) ), mais c'est vrai qu'il pourrait être plus performant. Je le retravaillerais avec l'aide d'Amygdala, et si un jour quelqu'un fait de bons bindings pour Amygdala en C, alors .. je céderai, et jetterai mon petit kibi de lignes de codes, et mon réseau entraîné à bloc pour être aussi performant que voulu le jour de la soutenance, à la poubelle. :-)
À vrai dire, le seul bout de code repris et pas complètement réécrit est pour Hough; à part l'import PGM ASCII, pour lequel je me suis inspiré de The Gimp. Hmm, il serait bien d'avoir une bibliothèque qui puisse m'ouvrir n'importe quelle image et me la filer dans un format qui me conviendrait .. Si quelqu'un a déjà testé, ou a des préférences, etc., you're welcome !
Misère, et pas le moindre petit morceau de source à grignoter... :-]°
Même Kilobug a été prié de rm -Rf'er le code que j'avais laissé sur son laptop pour l'occas' de la soutenance .. :-) Pour l'instant, ça serait pas grand chose, de toutes façons, et surtout inutilisable. Allez, patientez et laissez moi coder.
J'en profite pour répondre à Pierre :
Linus a dit : release often ! Je crois qu'il a raison et tu seras peut être étonné d'avoir de l'aide !
Oui, mais en l'espèce, faudra attendre que (1) ça ait un bon potentiel (2) ça soit légalement distribuable (je suis pas développeur mplayer.). Ce que Linus a oublié de préciser, c'est que le moment où l'on met les sources en ligne pour la première fois joue un rôle absolument essentiel dans la survie ou non du projet : tout, dans la communauté du libre, passe par la réputation, et si le projet fait bonne impression, ça va vite. Sinon, ça pèse contre lui bien longtemps. Donc, voilà, quoi.
[^] # Re: OCR sous Linux : comparatif
Posté par Manuel Menal . En réponse à la dépêche OCR sous Linux : comparatif. Évalué à 10.
GOCR a des performances tout à fait correctes sur un texte imprimé assez clairement et numérisé sans trop de parasites. Il a peu ou pas de post-traitement, il utilise des outils purement "mécaniques" (d'autres diront "algorithmiques") relevant à peine de ce qu'on appelle l'IA, et a des capacités d'apprentissage à peu près inexistantes. Ça reste cependant, à ce jour, l'outil d'OCR le plus efficace sous GNU/Linux, les fondements, plus anciens, d'un GNU OCR étant été oubliés de tous, et aujourd'hui plutôt .. à revoir de fond en comble.
Clara est aussi assez étrange. Il s'agit effectivement d'un projet pour apprendre, et le moins qu'on puisse dire est qu'il ne suit pas des règles courantes. Même à l'utilisation, ça se révèle plutôt .. déroutant :-) Cependant, c'est assez intéressant puisqu'on voit bien les phases de "blobification", etc. etc.
J'ai pour ma part été amené à réaliser un logiciel d'OCR plus « classique » pour GNU/Linux, utilisant simplement quelques procédés simples de pré-traitement - gradient et transformée de Hough, convolve - un réseau de neurones (avec possibilité d'apprentissage supervisé donc, mais aussi non-supervisé au dessus d'un certain seuil de confiance), et une vérification de post-traitement basique de l'ordre du dictionary search, pour l'instant. J'y travaille toujours dans mon temps libre - ce projet a été réalisé pour les Travaux Personnels Encadrés de Terminale scientifique, et aujourd'hui il n'est pas vraiment utilisable par quelqu'un d'autre que moi, parce que je fais mes fichiers de description du RN et de l'activation (y'a possibilité de persistence du RN, donc d'apprentissage par une application externe, mais aussi de persistence des niveaux d'activation) à la main, et de toutes façons il ne sera pas distribué tant que je n'aurai pas clairement établi l'origine de bouts de code repris pour Hough. De toutes façons, je travaille sur des mécanismes de post-traitement plus « intelligents », sur une interface graphique agréable et instructive, et je passe pas mal de temps à faire des tests pour voir ce qui pourrait améliorer en règle générale.
De façon générale, il est aujourd'hui plus performant, avec mon réseau de neurones, que gocr et que clara, et s'adapte très bien au changement de polices. Mais je ne parle pas de reconnaissance d'écriture manuscrite, c'est un _tout_ autre problème.
Enfin, just my 2 cents, et je ferai une news quand il sera prêt pour son first time. :-)
[^] # Re: Hurd bientot au niveau de l'Everest !!!
Posté par Manuel Menal . En réponse à la dépêche Le Hurd bientôt au niveau de l'Everest !. Évalué à 1.
[^] # Re: Hurd bientot au niveau de l'Everest !!!
Posté par Manuel Menal . En réponse à la dépêche Le Hurd bientôt au niveau de l'Everest !. Évalué à 3.
Ça n'était point mon propos. Mon propos était de dire : il faut trouver un terme qui identifie un système bien particulier, qui est le tien, qui est le mien, mais qui n'a que très très peu à voir avec d'autres systèmes exploitant Linux. Linux n'est pas satisfaisant, pour deux raisons principales :
Cela ne m'empeche pas de considérer que le système d'exploitation historique qui s'est concu autour du noyau Linux a pour nom le plus évident Linux, et pas GNU/Linux.
Mais, d'où vient l'évidence ? L'évidence est plutôt dans ta façon de faire que dans une réalité objective. Pour autant que je m'efforce d'observer une réalité objective, je vois une réalité historique qui est: "GNU a développé un certain nombres d'outils formant la base d'un système d'exploitation. Linus a, bien plus tard, développé un noyau, Linux, sur lequel ces outils furent portés. Le nom le plus logique serait une fusion des deux : LiGNUx ? Pas façile à dire. GNU/Linux? Bien, ça me paraît correct."
Après, RMS et ses partisans
Ah, je suis un partisan de RMS ? :-) Intéressant :-) Je peux partager un certain nombre d'opinions avec RMS, on peut avoir des vues convergentes sur un nombre important de sujet, je peux avoir un respect pour lui en tant qu'homme comme en tant que chercheur (hé, le dependency-directed backtrack, quand même), mais je ne me considère pas comme un partisan de RMS - je ne suis partisan de personne. Attention aux termes, dans une discussion sur des termes :-)
.. peuvent donner tout un tas d'arguments, mais je me poserais toujours la question : et pourquoi pas BSD ? et pourquoi pas tous les autres logiciels libres ? Au final, et pourquoi pas "Logiciels Libres & Co / Linux" ?
Sincèrement, je me demande parfois si en fait, la majorité des gens n'ont pas des réponses préparées dans leur tête qu'ils vont donner même si elles n'ont aucun sens vu les éléments donnés dans le message auxquels ils répondent. C'est assez impressionnant. D'aucuns attribueront ça à la lecture globale, lecture absolument inappropriée au débat, et pourtant habituelle, encore plus sur le Web. Dans tous les cas, la réponse à ta question est plus haut. Et dans le mail que je citais. Question de déterminant : ça, c'est la partie que je développais dans le mail cité. Question ensuite de spécificité : "GNU/Linux" est assez large et pourtant assez spécifique pour regrouper tout ce qu'une personne de bonne foi, et avec des connaissances correctes, regrouperait dans la même "classe" naturellement, mais pas plus. "Logiciels Libres & Co / Linux" signfierait : "tout système dont Linux constitue la base et qui utilise des logiciels libres & co" ; comme plus haut, trop générique. BSD/GNU/XFree86/Samba/Quesaisje/Linux, lui, serait trop spécifiquer pour désigner un système, mais plus une catégorie d'installations, un ensemble d'installations (voir la différence système/installation dans le premier mail).
Oh, au fait, l'URL donnée quand on clique sur ton nom ne marche pas : tu as dû oublier de marquer le 'http://'(...) ou quelque chose du genre, et les templates de LinuxFR ne doivent pas savoir gérer ça.
[^] # Re: Hurd bientot au niveau de l'Everest !!!
Posté par Manuel Menal . En réponse à la dépêche Le Hurd bientôt au niveau de l'Everest !. Évalué à 5.
Note qui'il y'a une contradiction évidente dans ta phrase : tout d'abord, tu admets l'unicité d'un système d'exploitation utilisant Linux : or, peut-on réellement et sérieusement dire qu'un système utilsant Linux, busybox, une libc minimalle (diet-libc, ou une des autres), est le même qu'un système utilisant Linux, les outils GNU, la GNU C Library, etc. ? Le problème ici, c'est que l'on admet que le système le plus courant est le seul : c'est bien évidemment faux. Bien que Linux ne soit pas le plus adaptable des noyaux, il existe des systèmes utilisant Linux dans l'embarqué, et ces systèmes n'ont décidément *rien* à voir avec le tien - celui que j'appelle GNU/Linux. Tu serais mis devant, tu ne verrais pas la ressemblance ..
Le problème que soulève cette non-unicité des systèmes d'exploitations utilisant Linux est celui classique du nommage : il faut trouver un compromis entre une appellation suffisamment large pour accepter toute la variété des systèmes qu'on rapprocherait naturellement comme étant « les mêmes » (on dira, la variabilité intra-classe), et suffisamment spécifique pour permette de différencier deux systèmes précisément, si l'expérience de notre jugement nous dirait qu'ils sont des systèmes différents - et deux systèmes utilisant Linux peuvent l'être (séparabilité des classes, donc.). Linux ne permet pas une séparabilité des classes.
GNU/KDE/Gnome/Samba/Apache/Linux et autres aberrations maintes fois proposées - encore récemment par Tim O'Reilly - par des gens n'ayant pas compris les vrais raisons de la critique de Linux comme nom du système dans son ensemble - ne permettent *absolument* pas d'avoir une variabilité intra-classe suffisante : elle permet en revanche d'avoir un compromis suffisamment précis pour désigner sa propre installation du système d'exploitation, et encore. Et comme je le disais dans une news précédente[0], je préférerais alors utiliser "Ma Debian GNU/Linux", qui me semble là, tout à fait correct.
[0]: http://linuxfr.org/comments/118290.html(...)
[^] # Re: Hurd bientot au niveau de l'Everest !!!
Posté par Manuel Menal . En réponse à la dépêche Le Hurd bientôt au niveau de l'Everest !. Évalué à 5.
Les trucs de théoricien à la noix ne sont pas faits pour rien. Ils ne sont pas faits pour faire beau. Il y'a des gens qui réfléchissent - si, si, ça peut te sembler difficile à concevoir, mais même toi, tu en es capable, au fond, et qui le fond pour le bien de tous. L'informatique est une science, et certains essayent de la construire. Je crois avoir employé beaucoup de temps à montrer, dans mes différents commentaires, dans ceux que j'ai cités, et dans bien d'autres endroits, à montrer en quoi ces choses, difficiles à appréhender il est vrai - et donc facilement critiquées, à la façon post-moderniste, mais pourtant si magiques, apportent énormément à tous les niveaux, à tout le monde, à toutes les utilisations - et c'est ça, l'adaptabilité de GNU/Hurd. Une question, une critique fondée en raison serait intéressante - mais pour celà, il va falloir lire, argumenter, reprendre. Pas se contenter de vagues allusions entendues, réferrant à un faux - je l'espère - consensus comme quoi « tout ce qui est théorie est inutile. »
Concernant les benchmarks, je m'étonnais déjà que personne ne l'ait mentionné. Ça a été suffisamment développé ailleurs[0], je ne pense pas que ça mérite de l'être encore sans aucune question précise. Si critique ou question il y a, cependant, je serais ravi de te répondre. Mais pour celà, il faudra garder en tête le maître mot : argumentation.
[0]: http://www.linuxfr.org/2002/10/23/10070.html(...)
[^] # Re: GNU/Hurd vs GNU/Linux ?
Posté par Manuel Menal . En réponse à la dépêche Le Hurd bientôt au niveau de l'Everest !. Évalué à 3.
Je compléterai - je ne pense pas l'avoir assez dit dans ces précédents commentaires, depuis lesquels ma façon de voir les choses et, surtout, de les expliquer a pas mal changé - en insistant sur le fait qu'on parle ici de deux variantes du système GNU[1], donc la comparaison au niveau de l'utilisateur final est quelque peu biaisée : la base du système d'exploitation n'a qu'une influence indirecte - ce qui ne signifie pas qu'elle n'est pas capitale - sur ce que voit, peut faire, et fait un utilisateur « de base ». Les repercussions sont quand même très importantes : la stabilité - un utilisateur de base ne voit peut-être pas que c'est le driver à deux balles de son périphérique quelconque à deux balles qui crashe, mais le crash, il le sent :-) ; la rapidité - la flexibilité entraîne une amélioration de la rapidité et de la « légèreté » importante; on pense notamment à la possibilité d'échanges de contrats concernant les ressources systèmes, comme dans le cas du VMM du Hurd pour L4[2] ; la sécurité - le système complètement modulaire, adaptable à tout type de sécurité (les « authentication tokens » sont génériques, ils peuvent s'appliquer aux capabilities, aux UIDs, mais aussi à une gestion des droits beaucoup plus fine) permet de limiter les dégâts occasionnés par un trou de sécurité.
Tous ces points, je les ai développés ailleurs et en d'autres temps ; je suis ouvert à toutes questions, ici ou ailleurs (le temps se resserre ici, sur DLFP coulent les news et nos questions). Au hasard, sur la ML HurdFr[3] :-)
[0]: http://linuxfr.org/2002/03/13/7530.html(...)
[1]: http://linuxfr.org/comments/118290.html(...) pour ma justification de l'appellation GNU/Linux
[2]: http://web.walfield.org/papers/better-best-effort-20021026/(...) et, pour pas faire genre « Je donne toujours la même URL », http://citeseer.nj.nec.com/ferguson96economic.html(...) :-)
[3]: http://hurdfr.org(...) dans les dernières nouvelles.
[^] # Re: GNU/Hurd vs GNU/Linux ?
Posté par Manuel Menal . En réponse à la dépêche Le Hurd bientôt au niveau de l'Everest !. Évalué à 10.
Oui, définitivement, oui. Tu dois remarquer toi-même, dans ta phrase, une contradiction flagrante : tu parles de module noyau. Tu es bien conscient que ces modules n'ont aucune autonomie, et qu'il s'agit juste de bouts de code qui seront ajoutés ou enlevés dynamiquement - c'est le principe des LKM. Ces bouts de code, une fois intégrés, font partie du noyau au même titre que ceux qui n'auront pas été chargés dynamiquement. Alors, le noyau n'est plus un gestionnaire de modules externes, puisqu'il comporte les parties qui étaient dans les modules. La modularité qu'implique l'utilisation de LKMs - très intéressante, cependant - n'est qu'une astuce pratique pour facilité la vie des utilisateurs : elle ne constitue en aucun cas une modularité de design, en aucun cas une modularité « logique » : si tu dois faire un schéma des différentes fonctions de l'OS, et par qui elles sont assurées, tu devras toujours faire un schéma avec un énorme (puisqu'il contiendra plein de cases avec ce qu'il fait, donc pas au sens de l'espace disque) noyal au milieu : un noyal monolithique.
Il faut bien aussi voir que s'il est difficile de discriminer parfaitement un micro-noyau d'un noyau monolithique, c'est parce qu'il s'agit également d'une question d'esprit, d'évolution, de volonté dans la conception du noyau, et pas seulement qu'une question des fonctionnalités que l'on peut avoir en espace utilisateur et superviseur (et en aucun cas, une question de taille). Mach, par exemple, bien que fournissant la majeure partie de son VMM en kernel space (toute la partie concernant la décision de quelles pages est swapped ou swapped in se trouve dans le noyau), fournit un certain mouvement vers l'espace utilisateur en fournissant le principe de memory objects et de backing store, délégant la responsabilité du choix du traitement de ces pages swapped out à un pager (page fault handler), qui sera chargé de les restituer quand y'en aura besoin (en cas de page fault). C'est, en fait, sur ce principe que sont implémentés les systèmes de fichier en espace utilisateur - et on imagine l'avantage qu'une telle approche fournit par rapport à des systèmes distribués, avec une mémoire distribuée, par exemple. Ces innovations, cette optique, plus le fait qu'une grande partie soit déjà délocalisée, en fait vraiment un micro-noyau. Ce qu'on ne peut pas dire de Linux. Linux, lui, a pour optique, de l'avis même de Linus Torvalds, une optique qui n'est pas celle du design, mais celle d'un pragmatisme technique. Ainsi, le cas de la VMM est intéressant : si l'on prend par exemple la VM rmap, on ne peut dire qu'elle n'est pas designée : elle est réfléchie, pensée, structurée, articulé autour d'un principe de reverse-mapping qui se justifie totalement, et le fait est que techniquement, c'est, à mon avis, une excellente VM.
En revanche, a-t-elle un vrai design de structure ? De la même façon que Linux, je ne le pense pas : il s'agit simplement d'une entité monolithique, ou tout est ensemble, les fonctions pas ou peu séparées logiquement, juste un programme, comme ça. Le cas de Mach évoqué ci-dessus montre un réel effort de design, puisqu'il y'a une séparation logique entre le "Who?" et le "Where?", permettant déjà une modularité et une adaptabilité qui change la vie. Voilà, ce que veut dire la modularité, et le design du Hurd. C'est encore plus vrai dans le cas de la VMM qui a été concue pour le Hurd sur L4[0].
Peut on encore parler de noyau monolithique à partir du moment où le plantage d'un module n'entraine pas l'arret complet du système ?
Euuuuh, ce ne serait plus des modules, mais des entités séparées. Ce qui n'est pas le cas actuellement. Je le dis et le répète : ce qui change dans un module, c'est la façon d'arriver dans le kernel, et le fait qu'on puisse le virer puis le remettre dynamiquement. C'est uniquement une facilité technique. Ils ont donc exactement les mêmes droits que ceux qui sont déjà dans le noyau. Ils peuvent provoquer l'arrêt complet du système, le plantage complet du noyau. Pensons par exemple aux drivers (libres) du winmodem du portable de Kilobug qui plantent quand on joue un ogg en se connectant :-)
La multiplication des systèmes d'exploitation "libres" (xBSD, Linux, Hurd), et je ne parle pas des multiples distributions linux ou version xBSD, ne risque t-il pas d'amener un peu plus de confusion chez les utilsateurs des dits systèmes, alors qu'une certaine cohésion commence (enfin) à se faire jour autour de GNU/Linux ?
C'est réellement une fausse question. Le problème est, il faut que les utilisateurs aient une vue d'ensemble assez globale du paysage disponible. Celà ne veut pas dire, des préjugés à deux balles qu'ils répandent sur les newsgroups du genre « Nunux c'est pour les débutants, ensuite c'est BSD pour les vrais proZ, etc. ». Ça veut dire avoir quelques éléments de base théorique, qui vont permettre de dire « Bon, voilà, les deux sont des trucs qui sont de la même famille, compatibles, y'a les mêmes logiciels dessus, c'est donc ce qui est très bas niveau qui change, genre tout ce qui va concerner le matos, etc. ». Ça va pas très loin, ça nécessite pas grand chose, mais ce serait heureux qu'un utilisateur basique sache un minimum d'informatique. Comment ça, utopiste ? (:
Si l'on ne parle pas d'opposition, alors j'ai un peu de mal à comprendre la complémentarité entre les deux systèmes. Existe t-il un système "libre" plus performant que l'autre (vitesse, éxécution des programmes, gestion de la MC, gestion des périphériques), de telle manière que le système le plus rapide pourrait servir pour "des expérimentations" et l'autre pour une production en entreprise ?
Si l'on ne parle pas d'opposition, c'est plus pour éviter le sous-entendu de rejet mutuel et de non communication entre les deux mondes. Linux, de par son excellence technique, a beaucoup à nous apprendre. Le Hurd pourrait apprendre pas mal de choses aux développeurs Linux. Pour l'instant, il n'y a pas « compétition » : les développeurs de GNU/Hurd utilisent GNU/Linux pour travailler, et l'un sert à l'autre. Il sert aussi à l'autre dans la mesure où il permet la promotion du libre, et le développement de logiciels libres, qui marcheront ensuite sous GNU/Hurd. Cependant, il ne faut pas se leurrer : GNU/Linux et GNU/Hurd se veulent des systèmes adaptables à à peu près toutes les possibilités - GNU/Hurd surtout, bien entendu ;-) Ils s'adressent donc au même public : tous ! Ensuite, le minoritaire pourra être utilisé pour des tâches où les avantages de l'autre ne comptent pas vraiment - changer le coeur d'un OS change beaucoup de choses, mais il ne peut pas tout.
Cette dernière question est la suite logique de la troisième, à savoir : Ces deux systèmes (diamétralement) opposées dans leur conception de base, peuvent ils etre compatibles au niveau des binaires, comme cela existe avec les Unix commerciaux et le GNU/linux avec le module IBCS ?
Oui, ils peuvent l'être, moyennant un effort. GNU/Hurd fournit une couche de compatibilité POSIX dans la GNU C Library, dans une certaine mesure il fournit aussi une compatibilité plus spécifiquement Linux et avec le port Linux de la GNU C Library, bien qu'à l'origine, il ait plus tendance à se rapprocher de BSD au niveau de ses interfaces - origines de Mach obligent, on retrouve les slices, la gestion des interruptions (niveaux de priorités, soft interrupts en « couches », ...). Il suffirait de presque rien, peut-être quelques symboles de plus, pour que te je dise : il y'a compatibilité binaire. (comment ça, c'est mauvais ?! :-). Cependant, je ne pense pas que ce soit une priorité, pour moi comme pour tous les développeurs de GNU/Hurd. Il me semble que la compatibilité sources devrait être assez, et qu'une compatibilité binaire ne peut engendre qu'une série de problèmes qui n'ont que peu d'intérêts. Ah, à moins que vous vouliez parler de logiciels propriétaires .. auquel cas vous oubliez qu'on parle ici du système GNU, l'officiel, le seul système d'ailleurs (« There is no system but GNU »), et que la possibilité du propriétaire ne rentrera aucunement dans nos priorités.
[0]: http://web.walfield.org/papers/better-best-effort-20021026/(...)
[1]:
[^] # Re: Hurd sur L4 et Hurd/GNUMach sur PPC ?
Posté par Manuel Menal . En réponse à la dépêche Le Hurd bientôt au niveau de l'Everest !. Évalué à 10.
-Il y a sur savanah un projet l4hurd consacré au port de Hurd sur micronoyau L4. C'est tellement actif que ça a l'air abandonné depuis 6 mois? Quelqu'un a des infos sur ce projet ?
Les problèmes d'organisation à L4Hurd .. :-) Bien difficile à expliquer. En fait, à l'origine, L4Hurd - c'est le nom qu'on donne habituellement au port du Hurd sur L4, n'y voyez aucun caractère officiel ou logique, il a juste le mérite de ne comporter aucune ambiguïté - est en fait un projet discuté depuis d'assez nombreuses années. La mailing list l4-hurd a été créée en octobre 2000, si mes souvenirs sont bons, et à l'époque, c'était Yoshinori K. Okuji, qui avait participé à pas mal de choses concernant le Hurd et GNU Mach, et qui est l'auteur de Grub, qui voulait le démarrer. Farid Hajji, à l'époque, voulait également participer au port. Les deux sont des gens que je respecte, ayant un niveau de connaissances techniques générales, et sur le Hurd et Mach en particulier, qui dépasse la plupart des gens - qui dépasse le mien, sans hésiter, même si on finit par atteindre des niveaux similaires. Mais, ils n'ont pas la même vision, je pense, que Thomas, Marcus ou Neal, du développement, et étaient plus dans une approche pragmatique de perfection technique quant aux rouages internes. Ainsi, une VMM à peu près « monolithique » (bien qu'en user space) qui reprendrait les bases de UVM (la VM de NetBSD (les médisants (et les épitéens) disent que c'est la seule chose de bien dans NetBSD .. :-> (et les intelligents que lisp ownaize)) avait été prévue. Ce port se fondait sur la version des API précédente, qui a abouti à Hazelnut, dernière implémentation de L4 sortie du projet L4Ka. Mais, rien de concret n'a *vraiment* été fait, Okuji et Farid ayant très peu de temps.
Là-dessus est arrivé Neal H. Walfield, développeur du Hurd depuis environ 1999, qui a eu la chance de rencontrer, lors du 18C3 (18ème Chaos Communication Congress (où Neal avait donnée une conf sur le Hurd dont on peut trouver les transparents sur http://web.walfield.org/papers/hurd-conference-ccc-20011228/(...) )), un certain nombre de gens travaillent sur L4, principalement les gens de l'université de Dresden - projet L4Ka. C'est à cette occasion là que Neal, comme Marcus, furent convaincus de la nécessité du port sur L4 - et suite à ça que le premier pas de L4Hurd va être suivi, avec la décision de Neal de passer son été avec les gens de L4Ka pour coder le portage. Ne rêvez pas, ça ne veut pas dire qu'il avait fini au bout :-) Il est très difficile de définir autant de nouvelles interfaces en si peu de temps, surtout quand on a pas envie de vivre reclus, et Neal n'est pas tout à fait le genre à vivre reclus ;-) Dans tous les cas, un certain nombre de choses avaient été définies, dont notamment l'ensemble des serveurs nécessaires, la gestion de choses comme les privileged system calls, la façon dont serait gérée le VMM[0].
Ian Duggan, et le projet L4Hurd enregistré sur Savannah, font partie de la suite du projet de Okuji et Farid, fondé sur Pistachio, et pour lequel peu ou rien n'a été fait - Pistachio est réellement le seul à nous intéresser, en réalité. Il est donc normal qu'il soit inactif. Le code fait par Neal H. Walfield et auquel on a contribué n'est disponible que dans un CVS privé - il ne mérite pas réellement l'attention, c'est plus les mails et les idées qui en ont résulté qui la mérite. Et, surtout, il repose entièrement sur l'API d'un Pistachio pas encore sorti, donc ..
-Il y a des réussite de hurd/GnuMach sur PPC, d'après Google... Quelqu'un a un lien qui explique comment faire que je me tente ça aussi ?
Tous les détails ici : http://lists.debian.org/debian-hurd/2002/debian-hurd-200204/msg0003(...) ; pour les patches manquants, les différents détails, simplement chercher les mails de Peter sur bug-hurd[1], et voir les plus à jour. Au passage : Pistachio est porté sur PowerPC.
Et si jamais la licence n'est pas sympathique du tout, qu'est-ce qui se passe ? Réimplémentation libre de la version X2 de l'interface ? Abandon du projet L4Hurd ? On l'utilise en attendant une réimplémentation libre ou un changement de licence ? (à la manière de KDE et Qt à leurs débuts) Bref, qu'est-ce qui se passe ?
Une très bonne question, que je vous remercie d'avoir posée :-) Bon, d'abord, ce qui ne se passera pas : en aucun, aucun cas, il n'y aura abandon du projet L4Hurd. Et, on n'utilisera pas une version non-libre, il n'en est évidemment absolument pas question - bien que le problème soit différent que KDE et Qt, parce que l'exception de la GPL concernant les bibliothèques et outils essentiels au système serait facilement exploitable « légalement ». Bon, dans tous les cas, il est clair, net, et précis, que la licence de Pistachio, dont des pre-releases devraient être publiées d'ici quelques semaines à peine, des dires des développeurs qui s'y affairent, devrait être « sympathique ». C'est à dire, probablement quelque chose autour du BSD. Dans cette perspective, et vu le bon boulot des gens de L4Ka, une réimplémentation à nous utilisant les interfaces X2 (de Version4, plus généralement) n'est pas à l'ordre du jour.
[0]: http://web.walfield.org/papers/better-best-effort-20021026/(...)
[1]: http://mail.gnu.org/archive/cgi-bin/namazu.cgi?query=pjbruin&su(...)
[^] # Re: Hurd bientot au niveau de l'Everest !!!
Posté par Manuel Menal . En réponse à la dépêche Le Hurd bientôt au niveau de l'Everest !. Évalué à 8.