Ce charmant personnage sévit sur DLFP depuis maintenant bien des années. Régulièrement, il joue à la limite de la légalité, et dès qu'il la dépasse allègrement (un thread où il s'envole), son compte est fermé. En l'occurrence, il n'a rien dit que de légal, tout aussi gerbant qu'il soit. Oh, son petit nom : adolphos. On retrouve son style inimitable qui lui vaut des notes si brillante sur (de mémoire principalement, il y en a plein d'autres) :
C'est dire s'il pollue...
Adolphos, l'extrême droite incarnée, l'Occident remis au goût du jour, avec l'anticommunisme et le libéralisme le plus dur comme point commun à tous ses pos^Wexcréments. Bref, rien ne sert de lui répondre.
Bon, ça fait trois fois, et même si j'aime pas faire ce genre de commentaires, j'aimerais bien qu'on m'explique *pourquoi* 3 personnes différentes ont voté contre ce commentaire ? C'était un commentaire à but informatif, totalement dans le sujet il me semble (article sur les brevets, qui plus est dans un journal "politique"). Alors, avant de mettre cet article [inutile], pouvez-vous y répondre en expliquant pourquoi ?
(Il serait plus que regrettable que le vote soit utilisé pour exprimer son désaccord avec l'orientation politique du journal cité. Mais je ne saurais préjuger des intentions des votants...)
À noter dans la même veine que l'Humanité, journal proche du Parti Communiste Français, a multiplié les articles contre les brevets logiciels jusqu'au vote. Les archives du journal, remontant à février 1990 (un projet de numérisation est en cours), étant disponibles en ligne gratuitement, vous pouvez trouver les articles simplement :
J'ai moi-même été étonné de la grande qualité de ces articles, notamment du dernier, très renseigné. En tous cas, il est toujours réjouissant de voir ce sujet traité avec considération, et non comme une bataille folklorique d'une communauté de rigolos.
C'est que tu n'as été qu'aux tanneries... Moi qui suis resté sage, je l'ai beaucoup vu. :-P
À propos du réseau, je confirme : c'était du grand n'importe quoi. Je comprends la nécessité d'authentifier les clients : il s'agit après tout d'une connexion Renater, et le GIP Renater a indiqué très clairement qu'il ne pouvait prendre la responsabilité d'accepter des réseaux non authentifiés (question de respect de la LCEN, la fameuse, vous savez). Mais je fais moi-même tourner un portail captif Talweg[1], et ça marche. Si vraiment on y arrivait pas, il y avait des ressources dans la salle pour trouver de l'aide...
Ceci dit, je trouve la tendance des évènements (du Libre et autre) à ne fournir que du réseau sans fil est extrêmement désagréable et injustifiée : on se rend bien compte que ça n'est pas une solution fiable, et si c'est agréable d'en avoir un disponible, ça ne peut pas remplacer un réseau filaire. D'autant plus que c'est pas bien difficile à tirer...
Je trouve aussi dommage qu'on n'ait pas eu la possibilité de rester le soir. Certes, il y a les tanneries, mais c'est pas pareil. À Bordeaux, on avait la possibilité de rester tard, jusqu'à la fermeture automatique, vers minuit je crois. Ca aurait donné la possibilité de se voir entre participants, de faire des trucs en commun.
Enfin, on veut des dev rooms l'année prochaine !
Sinon, c'était bien. Surtout la connex l'aprèm de la plénière 0:-)
J'en suis désolé. Le copié/collé m'a tué. J'ai pourtant re-cliqué, mais j'ai dû confondre la fenêtre ouverte par le lien et l'onglet où j'avais déjà ouvert le bon PDF...
Je te rappelle que ceux qui soumettent, relisent et modèrent les nouvelles sont bénévoles, n'ont pas beaucoup de temps, et que loin de vouloir induire les lecteurs en erreur, ils font eux-même des erreurs. Merci, Oumph< de l'avoir promptement corrigé.
Comme dit dans la nouvelle et sur le premier lien, les amendements retenus par la commission JURI ne retiennent que quelques amendements principalement cosmétiques (effectivement, des phrases bancales, des points trop gros pour passer, etc.). Mais les principaux points dangereux de la position du Conseil restent dans la version qui sera proposée au vote aux parlementaires :
* L'article 3 sur les conditions de brevetabilité est totalement inacceptable (il suffit d'avoir une application industrielle et d'apporter une innovation si minime soit elle)
* L'article 4 sur les exclusions est tellement vague et douteux qu'il en devient dangereux
* Le nouvel article 6 sur l'interopérabilité complique considérablement l'application de l'exception d'interopérabilité.
Bref, il ne faut pas que se fier au document officiel, évidemment parce que les explications sont là pour adoucir les moeurs et sont bien entendu orientées (pas que je crois possible de faire vraiment neutre - jamais justement, autant recouper avec la position orientée dans l'autre sens de la FFII), et surtout parce que ce qui est inacceptable dans ce texte, ce n'est pas ses apports mais ses manques, ce qu'il n'apporte pas.
C'est donc une défaite, car si les députés décidaient d'adopter la position de la JURI au nom des avancées minimes qu'elle comporte (et simplement parce qu'il est confortable d'accepter la position d'une instance "supérieure", encore plus quand ça ne va pas contre les pressions qu'on a subies), ce serait sans aucun doute et à court terme l'adoption d'une large brevetabilité des logiciels dans l'Union.
Je crains qu'il faille reprendre un tout petit peu l'histoire politique de la France et du Monde.
Pour la IVè République, les Français ont élu une Assemblée Constituante le 21 octobre 1945 (ils ont même élu une Assemblée et décider le même jour qu'elle serait constituante). Le 5 mai 1946, un premier texte est soumis à référendum, et le peuple le refuse à 53%. Une seconde Assemblée constituante est donc élue le 2 juin 1946. Elle propose un texte qui sera soumis au referendum et adopte a la majorite de 53% le 13 octobre 1946.
Pour la Vè République, le cas était assez différent, puisqu'on était dans un contexte de crise politique grave (guerre d'Algérie, 13 mai 1958), et que dans ce contexte on a remis au général De Gaulle les pleins pouvoir le 2 juin et le droit de réviser la Constitution le 3 juin. On agit dans un cas d'urgence (sans quoi on n'octroie pas les pleins pouvoirs), après le suicide de la IVè. La Constitution est rédigée par Michel Debré, aidé des juristes et des chefs de partis, ainsi que d'un conseil composé de parlementaires. Il est tout de même soumis au vote par referendum le 28 septembre 1958.
Aux États-Unis, la plupart des États (à ma connaissance l'ensemble, mais je ne veux pas m'avancer trop) prévoient que toute révision constitutionnelle, qu'elle soit parlementaire, gouvernementale ou populaire doit faire l'objet d'un referendum. Même si ça vient de représentants.
Plus généralement, la tradition du droit constitutionnel occidental veut qu'une Constitution _doit_ être adoptée par le peuple pour être légitime. À cette règle dérogent l'Allemagne dont la loi fondamentale est pour le moins spéciale (et peu traditionnelle), et les constitutions de démocratie jeune comme la Grèce et le Portugal (oui, je sais, Grèce, inventeur de la démocratie - reste que la Grèce sort de dizaines d'années de dictature et que son histoire constitutionnelle est très récente). L'autre tradition est qu'elle est rédigée par une Assemblée constituante. C'est cependant une pratique qui bouge, et il est de plus en plus courant de considérer que le gouvernement fraîchement élu est habilité à rédiger une nouvelle Constitution (puisqu'en général il est élu sur ce projet là). Le modèle de la Convention est plus rare, mais a un précédent non négligeable : la Convention de Philadelphie, dont Giscard n'a cessé de se réclamer, s'attirant les foudres des constitutionnalistes de tout bord qui estiment que cette Convention n'avait absolument rien à voir avec celle de Philadelphie, et qu'elle ne pouvait se réclamer de la même légitimité.
Bref, ça n'est pas un argument à la con. Et à ta question "Depuis quand ?", je dirais, depuis environ deux siècles, depuis la Constitution française et la Constitution de plusieurs États américains (Pennsylvanie, 1776, par exemple). Une Constitution est un texte trop important (on appelle pas ça "loi fondamentale" pour rien) pour la confier à une Assemblée qui peut décider en plein milieu "oh ben finalement on va faire tout autre chose, mais comme on est représentatif, on l'adopte". Tant qu'il n'y a pas de mandat impératif (pas dit que j'étais pour, 'tention), le contrôle doit se faire au moins en aval et en amont, donc par le referendum dans le cas d'une Constitution.
Il n'y en a qu'une autre d'après la liste communiquée aux assesseurs avant le vote : carte d'identité ou de circulation délivrée par les autorités militaires. Tous les documents doivent être obligatoirement munis d'une photographie, et généralement signés par le détenteur.
Un détail plus qu'important : la carte nationale d'identité tout comme le passeport peuvent être présentés périmés, puisqu'ils restent valables à vie sur le territoire national. Tous les autres documents doivent être en cours de validité.
Si vous avez le temps, n'hésitez pas non plus à vous proposer pour le dépouillement. C'est une expérience intéressante, et c'est souvent utile (selon les bureaux de vote, il peut y avoir abondance ou pénurie, bien évidemment...).
Voila, il ne vous reste plus qu'à voter ! (sauf pour nos amis anarchistes qui ne manqueront pas de me faire remarquer qu'ils n'iront pas ;-)
Ca ne serait plus un logiciel libre. C'est contraire à la liberté 0 dans la définition de la FSF ("liberté d'exécuter le programme _pour tous les usages_"), à la définition qu'en donne Debian dans les Debian Free Software Guidelines (points 5 et 6, notamment Aucune discrimination de champ d'application), et à l'Open Source Definition (issue des DFSG, donc points 5 et 6 aussi).
Qui plus est, d'un point de vue légal ça poserait des complications sans pareil. Quelqu'un connait une définition légale de "dictature" ? Je crains qu'il soit très difficile d'en donner une définition suffisamment précise pour figurer dans un contrat sans qu'elle soit totalement contournable ou totalement restrictive. Éventuellement, tu pourrais donner un certain nombre de conditions (que les textes prévoient la liberté d'opinion et d'expression, par exemple) mais elles seraient finalement probablement peu utiles (un grand nombre de dictatures prévoient la liberté d'opinion et d'expression - elles ne sont "juste" pas respectées).
Sans compter qu'à titre personnel, je trouverai ça assez idiot et contre-productif. Mais ça ne concerne pas la question posée.
Globalement, ça ne dépend pas beaucoup des applications. Ce sont les services systèmes qui sont plus lents dans un système multi-serveurs à base de micro-noyau. Je prends un exemple : lorsqu'on réalise une lecture de fichier, classiquement les données passeront par ces intermédiaires :
* le programme réalise un appel read() ; la GLibc contacte le translator chargé
du fichier et lui envoie une requête ;
* le système de fichier fait un appel à l'abstraction qui s'occupe de gérer son "backing store" (il y a généralement ce type d'abstraction, pour que le FS se lance de façon transparente sur une image, une partition, une image compressée/chiffrée, ...) ;
* cette abstraction va traduire la requête en une autre, selon le type de source ; disons qu'il s'agit d'une partition sur un disque IDE ;
* GNU Mach est donc appelé pour faire la lecture (les pilotes sont dans GNU Mach).
Dans l'autre sens, les données seront trimbalées dans toute la chaîne. On rajoute avec L4 une étape : le pilote IDE en espace utilisateur, qui fera lui-même vraisemblablement un appel système (à moins d'I/O port déjà mappé ou de DMA). Les IPCs dans GNU Mach sont asynchrones. Cela signifie que lorsqu'un thread fait un envoi de message à un autre thread, le noyau lui rend la main dès qu'il a enregistré la requête dans la queue des messages correspondant à ce thread (en fait, un thread n'est pas associé à une queue, mais passons). Bien sûr, il fait une copie logique, et même plus précisémen du copy-on-write, comme dit dans la news : mais comme les messages sont asynchrones, l'application continue à faire autre chose pendant le même temps, et si elle écrit là où les données étaient stockées, il faudra copier physiquement la mémoire dans la queue (dans le noyau! on sait comme les copies user space -> kernel sont extrêmement lourdes) en attendant que le destinataire vienne le chercher. Le temps que le message de retour soit passé dans toute la chaîne, il est bien probable qu'une application au moins ait modifié l'emplacement mémoire où elle avait stocké les données lues (disons, le pilote IDE). Du coup, au moins une copie physique lourde, si ce n'est deux. N'autoriser que des IPCs synchrones (et gérer le passage de mémoire intelligemment avec des containers comme le fait physmem) résout en grande partie le problème : c'est ce que fait L4.
L'autre problème est lié au simple fait que l'appel implique plusieurs services : outre le passage de message, le fait de passer d'une tâche à l'autre (changement de contexte) a lui aussi un coût associé. Une partie des coûts sont liés au TLB (Translation Lookaside Buffer). Ce TLB est un buffer où l'on met en cache les correspondances adresses virtuelles <-> adresses physiques. En effet, le fait de retrouver l'adresse physique à partir de l'adresse virtuelle est une opération assez pénible qui nécessite des parcours dans les pagetables de toutes façons assez longs (évidemment, les VM essayent de le rendre le moins long possible). Or, les adresses virtuelles sont dépendantes de l'espace d'adressage, donc a priori de la tâche en cours d'exécution. Comme on n'a pas moyen de préciser dans le TLB "cette association correspond à tel espace d'adressage" (tagger le TLB) sauf sur quelques architectures, il faut le vider à chaque changement de contexte. Et donc multiplier les parcours. Plus on multiplie les changements de tâche, plus on multiplie les parcours, plus on perd du temps. L4 se propose justement de résoudre ça (au moins en partie sur x86) sur au moins trois architectures (x86, PowerPC, Sparc), en utilisant des possibilités de chaque architecture. Du coup, on évite 4 fois sur 5 au moins les "vidages" de TLB.
Si vous voulez plus de détails sur les mécanismes, réferez vous aux publications de L4Ka ou aux anciens commentaires de Kilobug ou de moi. :-)
La branche actuelle ? Non, la branche actuelle utilise GNU Mach. GNU Mach est le seul noyau supporté par le Hurd actuellement, et le module 'hurd' dans le CVS ne contient que le support pour GNU Mach.
Il y a en plus une branche expérimentale qui consiste à porter le Hurd sur un nouveau micro-noyau, qui est dans un module à part ('hurd-l4') et qui en est au début de son développement. Si demain MacOS X décide de remplacer xnu (leur Mach++) par autre chose, il faudra sans aucun doute réécrire une grande partie de leur système de pilotes de périphériques, IOKit. Donc quand ils auront fini d'écrire leur noyau, ils penseront au support IDE. Et pourtant, je pense que ça te fera moins sourire.
Donc, c'est de l'humour gratuit uniquement lié au Hurd et à ce qu'il t'évoque, pas à son état... sois en conscient, au moins :-P
Note que je joue pas le rôle du censeur, je supporte même l'humour. Mais je tiens à remettre au clair ce que ce genre d'ironie laisse souvent penser aux lecteurs. Je me ramasse trop souvent l'ironie de gens qui ont entendu et répètent ce genre de blagues, en la prenant pour argent comptant. (Ah oui, et au fait, j'avais compris que c'était de l'humour, sinon j'aurai pas mis de smiley dès la première phrase. J'aurai peut-être dû être plus explicite, moi aussi).
(Sinon, tu me files le fauve quand ? Tu as une cage pour le transporter ? :-P)
Bon, je l'ai peut-être mal pris. Faire ses commentaires au taf n'est ptêt pas le milieu idéal pour être relaxé.
Note que gconfd marche, il faut juste le lancer à la main. Nautilus segfaulte parfois, mais sur le screenshot, tu as un gconfd qui tourne (sinon t'aurais pas grand chose) et un nautilus.
Quant au planning prévisionnel, je t'ai déjà répondu : il est extrêmement difficile de faire des prévisions à long terme, sur des effectifs réduits et changeants. Et comme ces prévisions sont toujours fausses, je m'en garderai bien. Effectivement, pour l'instant, le port du Hurd sur L4 n'intéresse que les gens qui s'intéressent à savoir comment est gérée la mémoire physique - et note que ça concerne directement l'utilisateur final - notamment l'administrateur système qui, à défaut que l'application ait développé le sien, pourra choisir son gestionnaire de mémoire le plus adapté pour son application.
Et je n'ai jamais dit "t'as qu'à lire les mailing lists" : j'ai dit que les détails des problèmes restants n'étaient intéressants que pour ceux qui souhaitaient s'en charger, et ceux là vont sans aucun doute consulter les mailing lists et s'y abonner (en tous cas, ils le devraient).
N'hesite pas a passer sur le canal IRC (irc.freenode.net #hurdfr) ou a envoyer un mail sur la mailing list d'HurdFR pour dire ce qui t'interesse, ce que tu te sens capable de faire (temps, competences). Publier des taches de differents niveaux sur une mailing list est un des projets d'HurdFR, mais il faut le temps que ca se mette en place...
C'est pas si bizarre que ca. En fait, c'est lie a deux choses :
a) Les translators passifs. GNU/Hurd, pour pouvoir fonctionner, a besoin d'un certain nombre de translators passifs installes. Par exemple, pflocal pour faire fonctionner tout ce qui est sockets Unix, pipes, etc, le translator exec, password (ca peut servir de pouvoir valider un couple (login,password) pour se logger ;-), etc. Or, on ne peut actuellement que positionner des translators passifs depuis GNU/Hurd (en utilisant la commande settrans).
b) L'installation se fait toujours actuellement depuis un GNU/Linux. Dans le cas de crosshurd, c'est normal, c'est fait pour. :-) Mais l'installer des CDs tourne lui aussi sous GNU/Linux, pour des raisons de stabilite, simplicite et parce qu'il manque encore quelques trucs pour porter l'installateur Debian sous GNU/Hurd. Donc on ne peut pas positionner les translators passifs pendant l'instant. Donc, on boote pour la premiere fois dans un systeme minimal (single, a peine un shell root ^^) et on lance un script (native-install) qui s'occupe de positionner les translators passifs. C'est la premiere passe de native-install. Ensuite, on reboote dans un systeme a peu pres bien en place, et on lance la configuration des paquets (vu que c'est installe depuis GNU/Linux, on a juste fait l'extraction et pas la configuration).
Les solutions existent : utiliser des attributs etendus POSIX pour les translators passifs (donc on pourra les changer et positionner depuis GNU/Linux) ; avoir un installer sous GNU/Hurd pour eviter la seconde passe. Pour le premier, ogi (celui qui a patche ext2fs pour supporter les FS de plus de 2G) travaille dessus dans le cadre de son boulot sur ext3fs. Dans le second cas, le LiveCD GNU/Hurd est deja un premier pas vers ca, ca viendra.
Attention, Mozilla ne fonctionne pas pour l'instant (il faut lancer gconfd a la main, et ensuite on ne peut pas taper d'URL ;-). Ce sont juste des paquets contenant un Mozilla non strippe (avec symboles de debug) pour le corriger.
Le Emacs est un Emacs22 CVS - les patchs Debian pour le dernier Emacs 21.4 le font segfaulter sous GNU/Hurd, pour une raison encore inconnue.
GNU/Hurd utilise evidemment la GNU C Library. Mais elle n'exporte pas exactement la meme interface binaire selon les ports. Ce n'est d'ailleurs pas une priorite : ca apporte parfois des complications (des interfaces optionnelles qui n'ont pas de sens chez nous devraient etre implementes juste pour la compatibilite, et on devra les maintenir en faisant attention a chaque changement, ...) pour pas grand chose. Une parfaite compatibilite POSIX est un but bien plus intelligent - les applications incorrectes doivent etre corrigees (les rendant plus portables y compris sur d'autres architectures), et autrement la compatibilite source est parfaite.
On garde effectivement un fichier TASKS et TODO dans les sources, mais le Hurd utilise egalement Savannah. Et la page en question n'est juste pas tres a jour (elle ne mentionne pas Savannah).
Ca en fait deja quelques uns. Si je ne m'abuse, e1000 est le nouveau driver qui remplace intel-gige, donc certaines cartes devraient etre supportees par ce dernier - meme si ce n'est pas le cas de toutes.
Je t'assure qu'il y a moyen de demander sans etre desagreable - d'autres le font. Je n'ai pas souhaite developper beaucoup plus dans la news parce que c'est une nouvelle, et il n'est pas forcement tres interessant de savoir dans le detail que ca marche sauf quand on utilise la fonctionnalite truc de machin etc. Ces informations la, tu les trouveras globalement sur les mailing lists, que tu consultes de toutes facons si tu souhaites aider au developpement - et c'est le seul cas ou le detail pourra t'interesser. Si tu veux vraiment le detail : gconfd ne se lance pas automatiquement (il segfaulte au lancement) : mais en le lancant a la main, ca marche ; nautilus a tendance a crasher parce que la GLib utilise pthread_attr_setstacksize incorrectement ; bref, des petits problemes qui ne manqueront pas d'etre corriges assez rapidement. L'idee est que Gnome fonctionne, mais si vous installez une K9, vous ne l'aurez pas en standard a cause de ces petites complications.
XFree86 marche, sinon tu n'aurais pas Gnome. Pour le support materiel, tu trouveras la plupart des informations dans le lien donne dans la FAQ (question 3.3). Les drivers "courants", ca peut vouloir dire tout et n'importe quoi, comme tu dis. Il n'y a pas d'acceleration 3D, parce qu'elle depend du DRI, et que GNU Mach ne le supporte pas. Pas de support de l'USB, du PCMCIA, de l'ACPI : je l'expliquais juste avant, ca n'est clairement pas une priorite puisqu'il s'agit de travail a faire sur GNU Mach, et que le but est de passer a L4. Gnome marche parce que Michael a pris le temps de faire des patchs pour Gnome, et pas encore pour KDE. Chacun porte en premier ce qu'il utilise lui-meme, evidemment. Mais Michael termine son mail par : "I hope KDE are packages are done when I'm back ;)" : j'attends vos patchs. :-P
Quant au reste, c'est du troll sans interet. GNU/Hurd est un systeme pour l'instant experimental. Il n'est pas stable, il n'est pas aussi rapide que GNU/Linux, il n'a pas le meme support materiel, simplement parce qu'il n'en est pas encore au stade ou ce sont les priorites du moment. Si tu peux sortir de ton attitude hautaine et venir pour faire de la comm' ou pour combler les lacunes qui t'importent, tu seras le bienvenu.
Évidemment, ça n'est jamais totalement à jour et il vaut mieux en discuter sur les mailing lists ou IRC quand on se met une tâche, parce que les développeurs ont souvent une idée de ce qui est urgent dans le moment, et parce qu'ils ont généralement déjà pensé à comment faire la plupart des tâches. HurdFR est aussi là pour répondre à ce genre de questions, sur la mailing list, sur IRC.
Je suis d'accord, il y a définitivement une difficulté à communiquer sur le Hurd. Les développeurs le font assez régulièrement sur les mailing lists (cf. les longs mails explicatifs de Neal ou de Marcus sur ce qui est fait et ce qui reste à faire, ou l'interview de Marcus) et Michael fait régulièrement le relai avec Kerneltrap.
On ne peut pas demander aux développeurs de rédiger eux-mêmes les news /., Kerneltrap ou autres. Ca prend du temps, et c'est mieux s'il est passé à coder (ou documenter son code). Éplucher les mailing lists, relayer les informations, c'est justement ce qui se fait de mieux en mieux, je trouve : par exemple, je remercie Victor et toi-même d'avoir soumis des news sur le sujet, que j'ai pu compléter avec les dernières nouvelles du Hurd. On a eu pas mal de news régulières sur le Hurd, assez complètes et explicatives, de Thomas, de Matthieu, de vous deux. Comme quoi, les choses progressent !...
Toutefois, je pense aussi qu'il manquerait une petite équipe, de deux disons, qui se chargeraient de faire des espèces de HWN (Hurd Weekly News (peut-être pas weekly ceci dit), sur le modèle des Debian Weekly News). Ca veut dire suivre plus ou moins attentivement les mailing lists, passer sur le canal IRC et demander aux développeurs ce qu'ils pensent qu'on peut mettre, etc. C'est pas un boulot très difficile, mais c'est assez prenant. Avant, il y avait le Hurd Traffic (comme Kernel Traffic), qui épluchait les mailings lists et en faisait des compte-rendus réguliers. Mais par manque de temps, ça n'existe plus. Effectivement, ça manque. Après ta thèse, tu dis ? ;-)
Les plannings, ça marche déjà difficilement dans les boîtes, où les gens sont payés pour un projet. Ca marche encore plus difficilement dans les gros projets tels que Gnome ou Linux, où un certain nombre de développeurs sont payés à plein temps, et où, en tout état de cause, il y a suffisamment de développeurs pour en avoir tout le temps un certain nombre. Pour un projet comme le Hurd, c'est inenvisageable. Trop peu de développeurs actifs, et trop aléatoire : les développeurs ont aussi une vie, qui peut les amener à ne pas pouvoir s'impliquer pendant des périodes de plusieurs mois.
Impossible également de prévoir si un ou deux développeurs ne vont pas nous rejoindre dans les mois à venir, qui feront avancer le projet considérablement plus vite (hé oui, 2 pour Linux c'est négligeable, pour le Hurd ça ne l'est pas du tout).
GNU/Hurd existe, est fonctionnel dans une certaine mesure. On peut l'installer, le tester, l'utiliser (même si personne ne voudrait l'utiliser dans son état actuel plutôt que GNU/Linux). Il faut, je pense, considérer GNU/Hurd sur Mach comme une plateforme temporaire qui permet de faire fonctionner le Hurd, et ainsi de l'essayer, de le débugger, de développer ses couches supérieures, et de créer Debian GNU/Hurd. Aussi, rajouter le support des winmodem, de l'ACPI, du son ou de l'USB, on peut pas dire que ce soit très utile (à moins, bien sûr, qu'on le fasse sans effort parce qu'on a trouvé un code simple à isoler et à gluecoder dans GNU Mach). On nous répète suffisamment qu'on perdrait notre temps avec le port sur L4 (ou à l'inverse, qu'on perdrait du temps avec Debian GNU/Hurd puisqu'il y a le port sur L4), on va pas nous demander en plus de perdre vraiment notre temps en développant GNU Mach plus qu'on en a besoin, uh ? :)
Et les développeurs ont l'intention de faire marcher ce "truc" un jour, merci pour eux. C'est justement parce qu'ils ont l'intention de le faire marcher, et bien, qu'ils ont entrepris le port sur L4, parce qu'ils pensent que c'est le meilleur moyen d'avoir un GNU/Hurd fonctionnel et optimal. Et si tu as bien lu la news, ça avance bien de ce côté là. Si tu veux imaginer ce qu'il reste à faire, prends un OS traditionnel, et divise le en deux parties : les couches basses du noyau (mémoire, scheduler, drivers, IPC, gestion des tâches, ...) et tout ce qui va au-dessus. Le port sur L4 représente le travail sur les couches basses du noyau : et vu que ça en est aux drivers, il y a déjà un certain état d'avancement. Le travail effectué sur Debian GNU/Hurd (en utilisant Mach) correspond au travail sur les couches supérieures : lui aussi avance bien, vu que GNU/Hurd sait faire tourner (partiellement) Gnome, remplit 9 CDs, etc. Lorsque le port sur L4 sera fonctionnel, il faudra évidemment faire un "sync", qui demandera un peu de boulot : mais c'est pas un si gros morceau. Concrètement, donc, c'est déjà bien avancé, et ça avance pas mal sur les deux fronts, compte tenu du nombre de développeurs.
Est-ce que tu penses qu'on fait fonctionner Gnome sans pilote IDE (ni SCSI, chipottez pas !) ? :-) GNU/Hurd, lorsqu'il utilise GNU Mach, supporte très bien IDE et SCSI, et toute une variété d'HBA (bon, aucun U160 ou U320, mais je suis en train de backporter un driver).
Et oui, un pilote IDE, ça tombe. En fait, ça m'est arrivé y a encore quelques semaines, et c'est arrivé à une assoce de mon entourage aussi. Lorsqu'une machine dispose de pas mal de disques, et que le disque qui s'occupe d'une partition de données pas vitale au système (celle qui contient le pr0^W^Wles vieux logs) crashe, tu aimerais fortement qu'il n'y ait pas d'interruption totale de service. Or il est extrêmement rare que ton noyau résiste à ça : soit tu te prends des Oops et une machine qui lagge tellement qu'elle est inutilisable (cas le plus rare dans mon expérience), soit la machine panic()e vite. C'est quelque chose de très désagréable sous GNU/Linux (vécu sous NetBSD aussi).
Et pour les autres types de pilotes, c'est encore plus courant. Disons, au hasard : les pilotes complètement instables non officiels ou fournis par votre constructeur mais pas intégrés à Linux. Je me souviens par exemple d'un portable où le noyau panic() ait dès qu'on utilisait en même temps le modem et le son. J'aurais apprécié perdre soit la connexion, soit le son, mais pas devoir attendre le reboot à -chaque- fois. Je pense pas que ce soit un avantage si négligeable, donc, en particulier en production.
Je suis désolé de faire mon critique, mais c'est bien dommage que cet évènement tombe le week-end du Libr'east, qui se passe justement sur un autre campus (MLV), à une demi-heure de là (compté en 63 + RER A :-P). J'imagine que de nombreuses personnes comme moi préféreront se rendre à un évènement de 3 jours, avec des conférences, etc. (bon, pour moi j'ai pas le choix, j'ai une conférence à faire jusqu'à 12h30).
À titre personnel je trouve ça d'autant plus dommage que je suis moi-même informaticien à Paris 7, donc que ça m'aurait dit de passer donner un coup de main ou simplement discuter. Peut-être une prochaine fois ?
[^] # Re: Je vote Gandhi.
Posté par Manuel Menal . En réponse au journal Un développeur en puissance?. Évalué à 8.
* http://linuxfr.org/~adolphos/(...)
* http://linuxfr.org/~Darkv/(...)
* http://linuxfr.org/~Moscva/(...)
* http://linuxfr.org/~solidarite/(...)
* http://linuxfr.org/~Stalinovsky/(...)
* http://linuxfr.org/~Aryaman/(...)
C'est dire s'il pollue...
Adolphos, l'extrême droite incarnée, l'Occident remis au goût du jour, avec l'anticommunisme et le libéralisme le plus dur comme point commun à tous ses pos^Wexcréments. Bref, rien ne sert de lui répondre.
[^] # Re: L'Humanité
Posté par Manuel Menal . En réponse au journal Brevets Logiciels au PS. Évalué à 1.
(Il serait plus que regrettable que le vote soit utilisé pour exprimer son désaccord avec l'orientation politique du journal cité. Mais je ne saurais préjuger des intentions des votants...)
# L'Humanité
Posté par Manuel Menal . En réponse au journal Brevets Logiciels au PS. Évalué à 2.
* Dans l'édition du 7, le vote est annoncé directement dans "l'Essentiel" : http://www.humanite.fr/journal/2005-07-07/2005-07-07-810077(...)
* ... et fait l'objet d'un article plus détaillé : http://www.humanite.fr/journal/2005-07-07/2005-07-07-810080(...)
* Enfin, dans l'édition du 8, un extrait du communiqué officiel du PCF sur la question (par la voix d'un député européen) se retrouve dès la seconde page : http://www.humanite.fr/journal/2005-07-08/2005-07-08-810189(...)
* ... et une pleine page (avec photo) est consacrée au sujet, un peu plus loin : http://www.humanite.fr/journal/2005-07-08/2005-07-08-810169(...)
J'ai moi-même été étonné de la grande qualité de ces articles, notamment du dernier, très renseigné. En tous cas, il est toujours réjouissant de voir ce sujet traité avec considération, et non comme une bataille folklorique d'une communauté de rigolos.
[^] # Re: Merci
Posté par Manuel Menal . En réponse à la dépêche Fêtez la fin des RMLL en ligne !. Évalué à 3.
À propos du réseau, je confirme : c'était du grand n'importe quoi. Je comprends la nécessité d'authentifier les clients : il s'agit après tout d'une connexion Renater, et le GIP Renater a indiqué très clairement qu'il ne pouvait prendre la responsabilité d'accepter des réseaux non authentifiés (question de respect de la LCEN, la fameuse, vous savez). Mais je fais moi-même tourner un portail captif Talweg[1], et ça marche. Si vraiment on y arrivait pas, il y avait des ressources dans la salle pour trouver de l'aide...
Ceci dit, je trouve la tendance des évènements (du Libre et autre) à ne fournir que du réseau sans fil est extrêmement désagréable et injustifiée : on se rend bien compte que ça n'est pas une solution fiable, et si c'est agréable d'en avoir un disponible, ça ne peut pas remplacer un réseau filaire. D'autant plus que c'est pas bien difficile à tirer...
Je trouve aussi dommage qu'on n'ait pas eu la possibilité de rester le soir. Certes, il y a les tanneries, mais c'est pas pareil. À Bordeaux, on avait la possibilité de rester tard, jusqu'à la fermeture automatique, vers minuit je crois. Ca aurait donné la possibilité de se voir entre participants, de faire des trucs en commun.
Enfin, on veut des dev rooms l'année prochaine !
Sinon, c'était bien. Surtout la connex l'aprèm de la plénière 0:-)
1: http://sourcesup.cru.fr/projects/talweg/(...)
[^] # Re: Erreur sur le deuxième lien
Posté par Manuel Menal . En réponse à la dépêche Un round de perdu pour les opposants aux brevets logiciels. Évalué à 3.
Je te rappelle que ceux qui soumettent, relisent et modèrent les nouvelles sont bénévoles, n'ont pas beaucoup de temps, et que loin de vouloir induire les lecteurs en erreur, ils font eux-même des erreurs. Merci, Oumph< de l'avoir promptement corrigé.
[^] # Re: les logiciels deja exclus de la brevetabilité
Posté par Manuel Menal . En réponse à la dépêche Un round de perdu pour les opposants aux brevets logiciels. Évalué à 4.
* L'article 3 sur les conditions de brevetabilité est totalement inacceptable (il suffit d'avoir une application industrielle et d'apporter une innovation si minime soit elle)
* L'article 4 sur les exclusions est tellement vague et douteux qu'il en devient dangereux
* Le nouvel article 6 sur l'interopérabilité complique considérablement l'application de l'exception d'interopérabilité.
Bref, il ne faut pas que se fier au document officiel, évidemment parce que les explications sont là pour adoucir les moeurs et sont bien entendu orientées (pas que je crois possible de faire vraiment neutre - jamais justement, autant recouper avec la position orientée dans l'autre sens de la FFII), et surtout parce que ce qui est inacceptable dans ce texte, ce n'est pas ses apports mais ses manques, ce qu'il n'apporte pas.
C'est donc une défaite, car si les députés décidaient d'adopter la position de la JURI au nom des avancées minimes qu'elle comporte (et simplement parce qu'il est confortable d'accepter la position d'une instance "supérieure", encore plus quand ça ne va pas contre les pressions qu'on a subies), ce serait sans aucun doute et à court terme l'adoption d'une large brevetabilité des logiciels dans l'Union.
[^] # Re: Pas moi
Posté par Manuel Menal . En réponse au journal J'ai honte d'être français !. Évalué à 8.
Pour la IVè République, les Français ont élu une Assemblée Constituante le 21 octobre 1945 (ils ont même élu une Assemblée et décider le même jour qu'elle serait constituante). Le 5 mai 1946, un premier texte est soumis à référendum, et le peuple le refuse à 53%. Une seconde Assemblée constituante est donc élue le 2 juin 1946. Elle propose un texte qui sera soumis au referendum et adopte a la majorite de 53% le 13 octobre 1946.
Pour la Vè République, le cas était assez différent, puisqu'on était dans un contexte de crise politique grave (guerre d'Algérie, 13 mai 1958), et que dans ce contexte on a remis au général De Gaulle les pleins pouvoir le 2 juin et le droit de réviser la Constitution le 3 juin. On agit dans un cas d'urgence (sans quoi on n'octroie pas les pleins pouvoirs), après le suicide de la IVè. La Constitution est rédigée par Michel Debré, aidé des juristes et des chefs de partis, ainsi que d'un conseil composé de parlementaires. Il est tout de même soumis au vote par referendum le 28 septembre 1958.
Aux États-Unis, la plupart des États (à ma connaissance l'ensemble, mais je ne veux pas m'avancer trop) prévoient que toute révision constitutionnelle, qu'elle soit parlementaire, gouvernementale ou populaire doit faire l'objet d'un referendum. Même si ça vient de représentants.
Plus généralement, la tradition du droit constitutionnel occidental veut qu'une Constitution _doit_ être adoptée par le peuple pour être légitime. À cette règle dérogent l'Allemagne dont la loi fondamentale est pour le moins spéciale (et peu traditionnelle), et les constitutions de démocratie jeune comme la Grèce et le Portugal (oui, je sais, Grèce, inventeur de la démocratie - reste que la Grèce sort de dizaines d'années de dictature et que son histoire constitutionnelle est très récente). L'autre tradition est qu'elle est rédigée par une Assemblée constituante. C'est cependant une pratique qui bouge, et il est de plus en plus courant de considérer que le gouvernement fraîchement élu est habilité à rédiger une nouvelle Constitution (puisqu'en général il est élu sur ce projet là). Le modèle de la Convention est plus rare, mais a un précédent non négligeable : la Convention de Philadelphie, dont Giscard n'a cessé de se réclamer, s'attirant les foudres des constitutionnalistes de tout bord qui estiment que cette Convention n'avait absolument rien à voir avec celle de Philadelphie, et qu'elle ne pouvait se réclamer de la même légitimité.
Bref, ça n'est pas un argument à la con. Et à ta question "Depuis quand ?", je dirais, depuis environ deux siècles, depuis la Constitution française et la Constitution de plusieurs États américains (Pennsylvanie, 1776, par exemple). Une Constitution est un texte trop important (on appelle pas ça "loi fondamentale" pour rien) pour la confier à une Assemblée qui peut décider en plein milieu "oh ben finalement on va faire tout autre chose, mais comme on est représentatif, on l'adopte". Tant qu'il n'y a pas de mandat impératif (pas dit que j'étais pour, 'tention), le contrôle doit se faire au moins en aval et en amont, donc par le referendum dans le cas d'une Constitution.
[^] # Re: précision
Posté par Manuel Menal . En réponse au journal Approuvez-vous le projet de loi qui autorise la ratification du traité établissant une Constitution pour l'Europe ?. Évalué à 2.
Un détail plus qu'important : la carte nationale d'identité tout comme le passeport peuvent être présentés périmés, puisqu'ils restent valables à vie sur le territoire national. Tous les autres documents doivent être en cours de validité.
Si vous avez le temps, n'hésitez pas non plus à vous proposer pour le dépouillement. C'est une expérience intéressante, et c'est souvent utile (selon les bureaux de vote, il peut y avoir abondance ou pénurie, bien évidemment...).
Voila, il ne vous reste plus qu'à voter ! (sauf pour nos amis anarchistes qui ne manqueront pas de me faire remarquer qu'ils n'iront pas ;-)
[^] # Re: Mouais.....
Posté par Manuel Menal . En réponse à la dépêche Linux à Cuba : İ Viva la penguinista !. Évalué à 2.
Qui plus est, d'un point de vue légal ça poserait des complications sans pareil. Quelqu'un connait une définition légale de "dictature" ? Je crains qu'il soit très difficile d'en donner une définition suffisamment précise pour figurer dans un contrat sans qu'elle soit totalement contournable ou totalement restrictive. Éventuellement, tu pourrais donner un certain nombre de conditions (que les textes prévoient la liberté d'opinion et d'expression, par exemple) mais elles seraient finalement probablement peu utiles (un grand nombre de dictatures prévoient la liberté d'opinion et d'expression - elles ne sont "juste" pas respectées).
Sans compter qu'à titre personnel, je trouverai ça assez idiot et contre-productif. Mais ça ne concerne pas la question posée.
[^] # Re: Avancement futur? + perfs ?
Posté par Manuel Menal . En réponse à la dépêche Nouvelle avancée du port du Hurd sur L4. Évalué à 8.
* le programme réalise un appel read() ; la GLibc contacte le translator chargé
du fichier et lui envoie une requête ;
* le système de fichier fait un appel à l'abstraction qui s'occupe de gérer son "backing store" (il y a généralement ce type d'abstraction, pour que le FS se lance de façon transparente sur une image, une partition, une image compressée/chiffrée, ...) ;
* cette abstraction va traduire la requête en une autre, selon le type de source ; disons qu'il s'agit d'une partition sur un disque IDE ;
* GNU Mach est donc appelé pour faire la lecture (les pilotes sont dans GNU Mach).
Dans l'autre sens, les données seront trimbalées dans toute la chaîne. On rajoute avec L4 une étape : le pilote IDE en espace utilisateur, qui fera lui-même vraisemblablement un appel système (à moins d'I/O port déjà mappé ou de DMA). Les IPCs dans GNU Mach sont asynchrones. Cela signifie que lorsqu'un thread fait un envoi de message à un autre thread, le noyau lui rend la main dès qu'il a enregistré la requête dans la queue des messages correspondant à ce thread (en fait, un thread n'est pas associé à une queue, mais passons). Bien sûr, il fait une copie logique, et même plus précisémen du copy-on-write, comme dit dans la news : mais comme les messages sont asynchrones, l'application continue à faire autre chose pendant le même temps, et si elle écrit là où les données étaient stockées, il faudra copier physiquement la mémoire dans la queue (dans le noyau! on sait comme les copies user space -> kernel sont extrêmement lourdes) en attendant que le destinataire vienne le chercher. Le temps que le message de retour soit passé dans toute la chaîne, il est bien probable qu'une application au moins ait modifié l'emplacement mémoire où elle avait stocké les données lues (disons, le pilote IDE). Du coup, au moins une copie physique lourde, si ce n'est deux. N'autoriser que des IPCs synchrones (et gérer le passage de mémoire intelligemment avec des containers comme le fait physmem) résout en grande partie le problème : c'est ce que fait L4.
L'autre problème est lié au simple fait que l'appel implique plusieurs services : outre le passage de message, le fait de passer d'une tâche à l'autre (changement de contexte) a lui aussi un coût associé. Une partie des coûts sont liés au TLB (Translation Lookaside Buffer). Ce TLB est un buffer où l'on met en cache les correspondances adresses virtuelles <-> adresses physiques. En effet, le fait de retrouver l'adresse physique à partir de l'adresse virtuelle est une opération assez pénible qui nécessite des parcours dans les pagetables de toutes façons assez longs (évidemment, les VM essayent de le rendre le moins long possible). Or, les adresses virtuelles sont dépendantes de l'espace d'adressage, donc a priori de la tâche en cours d'exécution. Comme on n'a pas moyen de préciser dans le TLB "cette association correspond à tel espace d'adressage" (tagger le TLB) sauf sur quelques architectures, il faut le vider à chaque changement de contexte. Et donc multiplier les parcours. Plus on multiplie les changements de tâche, plus on multiplie les parcours, plus on perd du temps. L4 se propose justement de résoudre ça (au moins en partie sur x86) sur au moins trois architectures (x86, PowerPC, Sparc), en utilisant des possibilités de chaque architecture. Du coup, on évite 4 fois sur 5 au moins les "vidages" de TLB.
Si vous voulez plus de détails sur les mécanismes, réferez vous aux publications de L4Ka ou aux anciens commentaires de Kilobug ou de moi. :-)
[^] # Re: La montre qui fait tout mais ne donne pas l'heure
Posté par Manuel Menal . En réponse à la dépêche Nouvelle avancée du port du Hurd sur L4. Évalué à 7.
Il y a en plus une branche expérimentale qui consiste à porter le Hurd sur un nouveau micro-noyau, qui est dans un module à part ('hurd-l4') et qui en est au début de son développement. Si demain MacOS X décide de remplacer xnu (leur Mach++) par autre chose, il faudra sans aucun doute réécrire une grande partie de leur système de pilotes de périphériques, IOKit. Donc quand ils auront fini d'écrire leur noyau, ils penseront au support IDE. Et pourtant, je pense que ça te fera moins sourire.
Donc, c'est de l'humour gratuit uniquement lié au Hurd et à ce qu'il t'évoque, pas à son état... sois en conscient, au moins :-P
Note que je joue pas le rôle du censeur, je supporte même l'humour. Mais je tiens à remettre au clair ce que ce genre d'ironie laisse souvent penser aux lecteurs. Je me ramasse trop souvent l'ironie de gens qui ont entendu et répètent ce genre de blagues, en la prenant pour argent comptant. (Ah oui, et au fait, j'avais compris que c'était de l'humour, sinon j'aurai pas mis de smiley dès la première phrase. J'aurai peut-être dû être plus explicite, moi aussi).
(Sinon, tu me files le fauve quand ? Tu as une cage pour le transporter ? :-P)
[^] # Re: Avancement futur?
Posté par Manuel Menal . En réponse à la dépêche Nouvelle avancée du port du Hurd sur L4. Évalué à 5.
Note que gconfd marche, il faut juste le lancer à la main. Nautilus segfaulte parfois, mais sur le screenshot, tu as un gconfd qui tourne (sinon t'aurais pas grand chose) et un nautilus.
Quant au planning prévisionnel, je t'ai déjà répondu : il est extrêmement difficile de faire des prévisions à long terme, sur des effectifs réduits et changeants. Et comme ces prévisions sont toujours fausses, je m'en garderai bien. Effectivement, pour l'instant, le port du Hurd sur L4 n'intéresse que les gens qui s'intéressent à savoir comment est gérée la mémoire physique - et note que ça concerne directement l'utilisateur final - notamment l'administrateur système qui, à défaut que l'application ait développé le sien, pourra choisir son gestionnaire de mémoire le plus adapté pour son application.
Et je n'ai jamais dit "t'as qu'à lire les mailing lists" : j'ai dit que les détails des problèmes restants n'étaient intéressants que pour ceux qui souhaitaient s'en charger, et ceux là vont sans aucun doute consulter les mailing lists et s'y abonner (en tous cas, ils le devraient).
[^] # Re: screenshot
Posté par Manuel Menal . En réponse à la dépêche Nouvelle avancée du port du Hurd sur L4. Évalué à 1.
[^] # Re: Debian Gnu tout court?
Posté par Manuel Menal . En réponse à la dépêche Nouvelle avancée du port du Hurd sur L4. Évalué à 3.
a) Les translators passifs. GNU/Hurd, pour pouvoir fonctionner, a besoin d'un certain nombre de translators passifs installes. Par exemple, pflocal pour faire fonctionner tout ce qui est sockets Unix, pipes, etc, le translator exec, password (ca peut servir de pouvoir valider un couple (login,password) pour se logger ;-), etc. Or, on ne peut actuellement que positionner des translators passifs depuis GNU/Hurd (en utilisant la commande settrans).
b) L'installation se fait toujours actuellement depuis un GNU/Linux. Dans le cas de crosshurd, c'est normal, c'est fait pour. :-) Mais l'installer des CDs tourne lui aussi sous GNU/Linux, pour des raisons de stabilite, simplicite et parce qu'il manque encore quelques trucs pour porter l'installateur Debian sous GNU/Hurd. Donc on ne peut pas positionner les translators passifs pendant l'instant. Donc, on boote pour la premiere fois dans un systeme minimal (single, a peine un shell root ^^) et on lance un script (native-install) qui s'occupe de positionner les translators passifs. C'est la premiere passe de native-install. Ensuite, on reboote dans un systeme a peu pres bien en place, et on lance la configuration des paquets (vu que c'est installe depuis GNU/Linux, on a juste fait l'extraction et pas la configuration).
Les solutions existent : utiliser des attributs etendus POSIX pour les translators passifs (donc on pourra les changer et positionner depuis GNU/Linux) ; avoir un installer sous GNU/Hurd pour eviter la seconde passe. Pour le premier, ogi (celui qui a patche ext2fs pour supporter les FS de plus de 2G) travaille dessus dans le cadre de son boulot sur ext3fs. Dans le second cas, le LiveCD GNU/Hurd est deja un premier pas vers ca, ca viendra.
[^] # Re: screenshot
Posté par Manuel Menal . En réponse à la dépêche Nouvelle avancée du port du Hurd sur L4. Évalué à 2.
Le Emacs est un Emacs22 CVS - les patchs Debian pour le dernier Emacs 21.4 le font segfaulter sous GNU/Hurd, pour une raison encore inconnue.
On fait tourner aussi E17 sous GNU/Hurd : http://dindinx.net/e/(...) ;-)
[^] # Re: Debian Gnu tout court?
Posté par Manuel Menal . En réponse à la dépêche Nouvelle avancée du port du Hurd sur L4. Évalué à 2.
[^] # Re: Avancement futur? Savannah?
Posté par Manuel Menal . En réponse à la dépêche Nouvelle avancée du port du Hurd sur L4. Évalué à 2.
[^] # Re: Avancement futur?
Posté par Manuel Menal . En réponse à la dépêche Nouvelle avancée du port du Hurd sur L4. Évalué à 5.
de4x5 de425 de434 de435 de450 de500 eexpresspro100 epic100 hp100 ne2kpci pcnet32 rtl8139 rtl8129 viarhine sis900 elcp tulip yellowfin starfire sundance winbond-840 hamachi intel-gige natsemi myson803 ns820 ac3200 ul32 at1700 ul epic wd80x3 3c503 el2 hplan hplanplus seeq8005 e2100 ne2000 ne1000 at1500 ne2100 fmv18x eth16i eth32 el3 3c509 3c579 vortex 3c59x 3c90x 3c515 znet znote eexpress eexpresspro depca de100 de101 de200 de201 de202 de210 de422 ewrk3 de203 de204 de205 apricot el1 3c501 wavelan el16 3c507 elplus 3c505 de600 de620 skg16 ni52 ni65 lance tlan
Ca en fait deja quelques uns. Si je ne m'abuse, e1000 est le nouveau driver qui remplace intel-gige, donc certaines cartes devraient etre supportees par ce dernier - meme si ce n'est pas le cas de toutes.
[^] # Re: Avancement futur?
Posté par Manuel Menal . En réponse à la dépêche Nouvelle avancée du port du Hurd sur L4. Évalué à 10.
XFree86 marche, sinon tu n'aurais pas Gnome. Pour le support materiel, tu trouveras la plupart des informations dans le lien donne dans la FAQ (question 3.3). Les drivers "courants", ca peut vouloir dire tout et n'importe quoi, comme tu dis. Il n'y a pas d'acceleration 3D, parce qu'elle depend du DRI, et que GNU Mach ne le supporte pas. Pas de support de l'USB, du PCMCIA, de l'ACPI : je l'expliquais juste avant, ca n'est clairement pas une priorite puisqu'il s'agit de travail a faire sur GNU Mach, et que le but est de passer a L4. Gnome marche parce que Michael a pris le temps de faire des patchs pour Gnome, et pas encore pour KDE. Chacun porte en premier ce qu'il utilise lui-meme, evidemment. Mais Michael termine son mail par : "I hope KDE are packages are done when I'm back ;)" : j'attends vos patchs. :-P
Quant au reste, c'est du troll sans interet. GNU/Hurd est un systeme pour l'instant experimental. Il n'est pas stable, il n'est pas aussi rapide que GNU/Linux, il n'a pas le meme support materiel, simplement parce qu'il n'en est pas encore au stade ou ce sont les priorites du moment. Si tu peux sortir de ton attitude hautaine et venir pour faire de la comm' ou pour combler les lacunes qui t'importent, tu seras le bienvenu.
[^] # Re: Avancement futur?
Posté par Manuel Menal . En réponse à la dépêche Nouvelle avancée du port du Hurd sur L4. Évalué à 2.
http://savannah.gnu.org/task/?group=hurd(...)
Il y a aussi les rapports de bugs : http://savannah.gnu.org/bugs/?group=hurd(...)
Enfin, pour Debian GNU/Hurd il y a les tâches suivantes : http://alioth.debian.org/pm/?group_id=30628(...)
Évidemment, ça n'est jamais totalement à jour et il vaut mieux en discuter sur les mailing lists ou IRC quand on se met une tâche, parce que les développeurs ont souvent une idée de ce qui est urgent dans le moment, et parce qu'ils ont généralement déjà pensé à comment faire la plupart des tâches. HurdFR est aussi là pour répondre à ce genre de questions, sur la mailing list, sur IRC.
[^] # Re: Avancement futur?
Posté par Manuel Menal . En réponse à la dépêche Nouvelle avancée du port du Hurd sur L4. Évalué à 7.
On ne peut pas demander aux développeurs de rédiger eux-mêmes les news /., Kerneltrap ou autres. Ca prend du temps, et c'est mieux s'il est passé à coder (ou documenter son code). Éplucher les mailing lists, relayer les informations, c'est justement ce qui se fait de mieux en mieux, je trouve : par exemple, je remercie Victor et toi-même d'avoir soumis des news sur le sujet, que j'ai pu compléter avec les dernières nouvelles du Hurd. On a eu pas mal de news régulières sur le Hurd, assez complètes et explicatives, de Thomas, de Matthieu, de vous deux. Comme quoi, les choses progressent !...
Toutefois, je pense aussi qu'il manquerait une petite équipe, de deux disons, qui se chargeraient de faire des espèces de HWN (Hurd Weekly News (peut-être pas weekly ceci dit), sur le modèle des Debian Weekly News). Ca veut dire suivre plus ou moins attentivement les mailing lists, passer sur le canal IRC et demander aux développeurs ce qu'ils pensent qu'on peut mettre, etc. C'est pas un boulot très difficile, mais c'est assez prenant. Avant, il y avait le Hurd Traffic (comme Kernel Traffic), qui épluchait les mailings lists et en faisait des compte-rendus réguliers. Mais par manque de temps, ça n'existe plus. Effectivement, ça manque. Après ta thèse, tu dis ? ;-)
[^] # Re: Avancement futur?
Posté par Manuel Menal . En réponse à la dépêche Nouvelle avancée du port du Hurd sur L4. Évalué à 10.
Impossible également de prévoir si un ou deux développeurs ne vont pas nous rejoindre dans les mois à venir, qui feront avancer le projet considérablement plus vite (hé oui, 2 pour Linux c'est négligeable, pour le Hurd ça ne l'est pas du tout).
GNU/Hurd existe, est fonctionnel dans une certaine mesure. On peut l'installer, le tester, l'utiliser (même si personne ne voudrait l'utiliser dans son état actuel plutôt que GNU/Linux). Il faut, je pense, considérer GNU/Hurd sur Mach comme une plateforme temporaire qui permet de faire fonctionner le Hurd, et ainsi de l'essayer, de le débugger, de développer ses couches supérieures, et de créer Debian GNU/Hurd. Aussi, rajouter le support des winmodem, de l'ACPI, du son ou de l'USB, on peut pas dire que ce soit très utile (à moins, bien sûr, qu'on le fasse sans effort parce qu'on a trouvé un code simple à isoler et à gluecoder dans GNU Mach). On nous répète suffisamment qu'on perdrait notre temps avec le port sur L4 (ou à l'inverse, qu'on perdrait du temps avec Debian GNU/Hurd puisqu'il y a le port sur L4), on va pas nous demander en plus de perdre vraiment notre temps en développant GNU Mach plus qu'on en a besoin, uh ? :)
Et les développeurs ont l'intention de faire marcher ce "truc" un jour, merci pour eux. C'est justement parce qu'ils ont l'intention de le faire marcher, et bien, qu'ils ont entrepris le port sur L4, parce qu'ils pensent que c'est le meilleur moyen d'avoir un GNU/Hurd fonctionnel et optimal. Et si tu as bien lu la news, ça avance bien de ce côté là. Si tu veux imaginer ce qu'il reste à faire, prends un OS traditionnel, et divise le en deux parties : les couches basses du noyau (mémoire, scheduler, drivers, IPC, gestion des tâches, ...) et tout ce qui va au-dessus. Le port sur L4 représente le travail sur les couches basses du noyau : et vu que ça en est aux drivers, il y a déjà un certain état d'avancement. Le travail effectué sur Debian GNU/Hurd (en utilisant Mach) correspond au travail sur les couches supérieures : lui aussi avance bien, vu que GNU/Hurd sait faire tourner (partiellement) Gnome, remplit 9 CDs, etc. Lorsque le port sur L4 sera fonctionnel, il faudra évidemment faire un "sync", qui demandera un peu de boulot : mais c'est pas un si gros morceau. Concrètement, donc, c'est déjà bien avancé, et ça avance pas mal sur les deux fronts, compte tenu du nombre de développeurs.
[^] # Re: La montre qui fait tout mais ne donne pas l'heure
Posté par Manuel Menal . En réponse à la dépêche Nouvelle avancée du port du Hurd sur L4. Évalué à 10.
Et oui, un pilote IDE, ça tombe. En fait, ça m'est arrivé y a encore quelques semaines, et c'est arrivé à une assoce de mon entourage aussi. Lorsqu'une machine dispose de pas mal de disques, et que le disque qui s'occupe d'une partition de données pas vitale au système (celle qui contient le pr0^W^Wles vieux logs) crashe, tu aimerais fortement qu'il n'y ait pas d'interruption totale de service. Or il est extrêmement rare que ton noyau résiste à ça : soit tu te prends des Oops et une machine qui lagge tellement qu'elle est inutilisable (cas le plus rare dans mon expérience), soit la machine panic()e vite. C'est quelque chose de très désagréable sous GNU/Linux (vécu sous NetBSD aussi).
Et pour les autres types de pilotes, c'est encore plus courant. Disons, au hasard : les pilotes complètement instables non officiels ou fournis par votre constructeur mais pas intégrés à Linux. Je me souviens par exemple d'un portable où le noyau panic() ait dès qu'on utilisait en même temps le modem et le son. J'aurais apprécié perdre soit la connexion, soit le son, mais pas devoir attendre le reboot à -chaque- fois. Je pense pas que ce soit un avantage si négligeable, donc, en particulier en production.
# Libr'est
Posté par Manuel Menal . En réponse à la dépêche Install Party samedi 23 avril 2005 à l'Université Paris VII - Denis Diderot. Évalué à 3.
À titre personnel je trouve ça d'autant plus dommage que je suis moi-même informaticien à Paris 7, donc que ça m'aurait dit de passer donner un coup de main ou simplement discuter. Peut-être une prochaine fois ?
[^] # Re: Sans oublie pearpc
Posté par Manuel Menal . En réponse à la dépêche Poissons d'avril de 2005. Évalué à 2.