Gaël Le Mignot a écrit 812 commentaires

Et puis t'as pas d'équivalent de l'hostmux (qui permet d'accéder à tous les FTPs avec des CDs sans faire un mount ou settrans par site) sous GNU/Linux...

(mmenal@drizzt, 42) ~ $ settrans -cgap ftp /hurd/hostmux /hurd/ftpfs /
(mmenal@drizzt, 43) ~ $ cd ftp
(mmenal@drizzt, 44) ~/ftp $ ls
(mmenal@drizzt, 45) ~/ftp $ cd ftp.fr.debian.org
(mmenal@drizzt, 46) ~/ftp/ftp.fr.debian.org $ ls
debian debian-cd debian-non-US
(mmenal@drizzt, 47) ~/ftp/ftp.fr.debian.org $ cd debian/
(mmenal@drizzt, 48) ~/ftp/ftp.fr.debian.org/debian $ ls
README README.mirrors.html README.non-US dists indices ls-lR.gz pool tools README.CD-manufacture README.mirrors.txt README.pgp doc ls-lR ls-lR.pa tch.gz project

Sauf que sous GNU/Linux, ton ftpfs tu peux le monter qu'en root, il est instable (sous GNU/Hurd aussi, mais quand ftpfs plante il plante tout seul), il est pas multi-threadé, et il est beaucoup plus difficile de développer des modules noyaux types ftpfs que des translators.

hum, je ne sais pas ce qu'il se passe sur news.hurdfr.org, je n'ai pas accès à la machine, mais la liste des projets (légèrement obsolète) est sur http://hurdfr.org(...) et non news.hurdfr.org.

Euh, entre l'entrée en guerre uniquement quand les forces de Staline commençaient à battre celles d'Hitler (donc: on s'en fout si l'Europe reste sous Hilter, mais par contre Staline on en veut pas), et l'utilisation de _deux_ bombes atomiques contre des populations civiles, sans compter le bombardement de Drezt et autres, l'attitude des USAs pendant la seconde guerre mondiale n'est _vraiment_ pas à leur honneur, bien au contraire.

les autochtones américains ont été massacrés

Et moi je rappelle qu'ils le sont encore à l'heure actuelle.

L'espérance de vie d'un "Indien" aux Etats-Unis est de 47 ans actuellement.

Le taux de fausses couches sur la réserve de Pine Rige (Dakota du Sud) a été multiplié par 4 depuis que le gouvernement a autorisé (en violation des traités signés) l'exploitation de l'uranimum contenu dans les sous-sols de la réserve.

Léonard Peltier, l'un leader de l'AIM, est toujours en prison depuis plus de 27 ans, officiellement pour le meurtre de deux agents du FBI, alors que le procureur et le juge l'ayant fait condamner ont depuis déclaré qu'ils ne savaient pas qui était le coupable, et que le dossier du FBI sur l'affaire (rendu partiellement public après le procés) contient des preuves que le procès a été truqué.

L'extermination du peuple Indien a commencé il y a 500 ans, mais n'est toujours pas terminée, et continue d'être menée à bien par le gouvernement des Etats-Unis d'Amérique, mais de manière discrète.

-1 HS

Euh, la question était sur _gcj_ (GNU Compiler for Java) et non _gcc_ (GNU Compiler Collection). A ma connaissance aucune distrib n'est basée sur un compilateur Java.

Moi je n'ai testé gcj que rapidement il y a plus d'un an (les debian-prelease d'avant gcc 3.0), ça permettait de faire des choses, en particulier l'interaction C <=> Java marchait pas trop mal, mais ça ne supportait qu'une partie du Java et pas toujours très bien. Je ne sais pas ce que ça donne maintenant.

L'ABI _C++_ change, donc pas de problèmes pour la libc et tous les autres programmes écrits en C.

Pour le C++ (qui suxor de toute façon ;) ) je ne connais pas l'ampleur des changements entre g++ 3.1.1 et les autres 3.x donc je ne sais pas si plus rien ne marchera (comme entre le 2.x et le 3.x) ou si juste dans certains cas bien précis il y aura qqes problèmes.

Mais oui, bien sûr, les états-unis défendent le peuple irakien contre le maichant Saddam... Sauf que l'Irak est bombardé en continu depuis 11 ans, que Saddam est toujours en place et encore plus puissant qu'avant dans son pays, que les partis d'opposition sont encore plus sévèrement opprimés, avec le soutien du peuple parce qu'accusés de connivance avec les USAs, et que pendant les pires heures du blocus un enfant mourrait toutes les trois secondes de malnutrition ou de manque de médicaments...

La victime de la politique des USAs en Irak c'est le peuple Irakien, et le peuple Kurde qui vit dans une partie de l'Irak, certainement pas Saddam Hussein.

-1 HS

Hum, la roadmap est prévisionelle et n'a pas été mise à jour, les dates ne sont donc qu'approximatives...

Et puis y'a un truc qui me semble louche, c'est que d'après la roadmap la 1.1 beta ne soit pas vraiment une branche mais plus un freeze du tronc comme lors de la 1.0, alors un passage à gtk 2 pendant un freeze ça me semble un peu gros... là j'avoue que je suis un peu perdu.

Même si Photogenics est propriétaire, ce logiciel reste la bienvenue sous Linux

Là faudrait qu'on m'explique. Le projet GNU, dont le système GNU/Linux est une variante, a pour _but_ de permettre aux gens de ne pas utiliser de logiciel propriétaire. Je ne vois pas en quoi on peut se réjouir que du logiciel propriétaire soit porté sous une variante du système GNU.

Cela n'a que très peu d'intéret d'utiliser un système libre si c'est pour faire fonctionner du logiciel propriétaire dessus.

Le logiciel libre n'est pas là pour des raisons pratiques (oui, techniquement GNU/Linux est supérieur à la plupart des autres systèmes, mais c'est pas la question), mais pour des raisons éthiques et philosophiques.

Je ne dis pas que c'est une mauvaise nouvelle de voir du logiciel propriétaire sous GNU/Linux, mais voir des gens s'en réjouir, cela revient à dire que le logiciel propriétaire c'est pas si mal, acceptable, ... et là je dis non !

C'est pas exactement ça, sous GNU/Linux, tu as aussi un mappage de l'exécutable en mémoire, mais le système de fichier est conçu pour ne pas effacer les fichiers encore utilisés.

Donc si tu fais un mmap() (ou un open()) sur /tmp/foo puis un unlink() sur /tmp/foo, tu détruis bien l'association faite entre le nom /tmp/foo et l'inode, mais l'inode lui ne sera supprimé que lorsqu'il ne sera plus utilisé.

Mais ça veut dire quoi 99.9999 % d'uptime ? Si tu prends la machine, avec le matos le mieux supporté et super testé, que tu la mets dans un placard, que tu débranches le câble réseau et que tu désactives crontab, bien sûr que ta machine elle va tenir 100% d'uptime (hors coupures de courant ou panne).

C'est pas là la question, c'est ce qu'il se passe quand tu utilises la machine et que tu la stresses un peu. Et bien là, non, je suis désolé, win 2k ou XP tiennent beaucoup moins que GNU/Linux. Moi j'ai vu plus de plantages sous XP ou 2K que sous GNU/Linux et j'en ai vraiment pas vu beaucoup des XP ou des 2000, par contre des GNU/Linux un sacré paquet.

Les BSOD sous XP j'en ai vu deux, et je n'ai vu XP tourner que pendant quelques unes des présentations des projets de fin d'années dans ma promo (un BSOD avec un vidéo intégrée dans un document Power Point et l'autre lors d'un problème de lecture sur la disquette ou se trouvait le ppt), je trouve ça quand même assez gros pour un OS soi-disant "stable".

Et pour 2000 j'ai déjà vu au boulot une machine sous 2k planter ou rebooter (et plusieurs fois) juste en éditant un gros document word. Je veux bien qu'OpenOffice ne soit pas très stable, mais je l'ai jamais vu emmener le système avec lui.

Donc, oui, 2k et XP sont bcp plus stables que les 9x (pas dur) mais c'est encore loin d'être aussi stable qu'un GNU/Linux ou qu'un FreeBSD (au niveau du système, je ne dis pas que les applis ne crachent pas parfois sous GNU/Linux)

Une prerelease sans doute, comme sur la Sid:

(kilobug@drizzt, 8) ~ $ gcc -v
version gcc 3.1.1 20020703 (Debian prerelease)

gcc 3.1.1 ne devrait pas tarder.

Donc oui, pour l'instant c'est une version CVS, mais une version CVS entre le 3.1.0 et le 3.1.1 (bugfixes only) ça n'a pas grand chose à voir avec une version CVS entre le 2.95 et le 3.0 (changement radicaux dans l'architecture même)

Le pb est du au langage C++ qui est _horrible_ à compiler, et les devs de g++ doivent donc fréquemment briser la compatibilité binaire pour contourner des limites, ce qui explique que g++ 2.96 (version CVS jamais releasée) soit incompatible aussi bien avec le 2.95 qu'avec le 3.0.

Les distribs ayant choisies d'intégrer g++ 2.96 sont donc confrontées à 3 versions incompatibles du compilateur: g++ 2.95, g++ 2.96 et g++ 3.x ce qui explique des versions incompatibles en peu de temps.

La seule chose que l'on peut reprocher à Mandrake dans cette histoire est d'avoir choisi d'utiliser g++ 2.96, mais c'est de l'histoire ancienne, c'est fait, et passer à g++ 3.1 maintenant est AMHA la meilleur chose à faire, donc oui, là, ils n'ont plus le choix et sont obligés de sortir une nouvelle version incompatible (pour ce qui est des programmes en C++), et cela justifie un changement de numéro de version je pense.

Quand tu compiles une application, tu utilises des bibliothèques partagées qui sont linkés avec ton programme au lancement. Si ton application est en C++ et compilée avec g++ 3.0 alors qu'une lib (par exemple la libstdc++) est compilée avec le 2.95 ça ne marchera pas (idem si c'est la lib qui est compilée avec le 3.0 et le programme avec le 2.95).

Par contre je le répète, pour les programmes en C il n'y a pas d'incompatibilités, donc pour gnome 2 pas de soucis.

Nan, je voulais juste dire qu'une des vocations de debian est d'être la distrib officielle de GNU.

Désolé, mais là tu dis _n'importe quoi_.
Debian (enfin, Software in the Public Interest) et la FSF n'ont rien à voir, la Debian GNU/Linux n'est aucunement une distribution officielle du système GNU (puisque ce n'est même pas le système GNU), et même Debian GNU/Hurd est loin d'être le système GNU.

D'ailleurs les DFSG et la définition de libre pour la FSF ne sont pas les mêmes.

La distribution "officielle" GNU verra le jour je ne sais pas quand, mais ce ne sera pas Debian. Ce sera une distribution de GNU/Hurd utilisant au maximum les fonctionnaliés de GNU/Hurd, y compris pour ce qui est de la gestion des paquets, des fichiers de configurations & compagnie, et non pas comme la Debian GNU/Hurd une version de Debian utilisant le Hurd et un micro-noyau à la place de Linux, mais essayant de rester le plus proche possible de la Debian GNU/Linux pour tout ce qui est conf/installation/packaging

Ah ouais, je savais pas, merci :)
Décidément, la mandrake se debianise de plus en plus, et elle est de mieux en mieux :)

Enfin, c'est mon avis pour la suivre un peu, chaque version est bien meilleure que la précédente, on se rapproche de Debian :)

Bonne chance les gars de Mandrake, continuez comme ça ;)

-1 on s'en fout

Ben en fait pas vraiment puisqu'on code en C++, qu'on fait de la compilation distribuée pour réduire les temps de compilation, donc il _faut_ qu'on ait tous la même version du compilateur (donc g++ 2.96).

J'ai réussi à faire passer le serveur de prod sous Debian (enfin, c'est moi qui ait fait l'install et je leur ai pas laissé le choix) mais pour nos machines, non, ou faudrait que je fasse passer tout le monde sous Debian et c'est pas gagné :/

-1 ma vie on s'en fout

Ou alors que j'installe un g++ 2.96 sur une debian mais ça risque d'être galère :/

Mais, le jdk de sun, bien que non libre, est open source et il peut peut etre quand même être inclus dans la distrib.

open source selon quel définition ? Pas selon l'OSI en tout cas. Et AMHA, il n'a rien à faire dans une distribution libre. Je pense d'ailleurs que Mandrake devrait adopter une charte comme le Debian Social Contract avec les DFSG (Debian Free Software Guidelines) définissant clairement ce qui peut être inclus dans la version 'libre' de la distribution.

Mais peut-être est-ce qu'il a déjà des Mandrake Free Software Guidelines ? ;)

A propos de xerces, xalan, tomcat, jboss, et pourquoi pas ? C'est énormément utilisé comme softs.

Parce que ça nécessite du logiciel non libre pour fonctionner, et ça n'a donc rien à faire dans une distribution qui se prétend libre. Et sortir une version du système GNU (ce qu'est une distribution GNU/Linux) en incluant du non-libre, ça ça pose un gros problème AMHA (je ne dis pas que non-free ou les power pack doivent être supprimés, mais que tout doit être fait pour qu'une version 100% libre existe et que les utilisateurs soient prévenus lorsqu'ils installent du non libre)

Il faut recompiler toutes les applications C++ à cause du changement d'ABI (Application Binary Interface): il est impossible de linker un .o compilé avec g++ 2.95 avec un .o compilé avec 2.96, et idem pour 2.96 vs 3.1.

Pour les programmes C, il n'y a pas de gros problème, mais pour bénificer des optimisations de gcc 3.1 il faut bien sûr recompiler (par contre on peut avoir la libc compilée avec gcc 3.1 et lancé un binaire compilé avec le 2.95 ou le 2.96 sans pb)

En tout cas, j'utilise une Sid sur plusieurs machines depuis un an et demi, avec plusieurs màj par semaine, sans gros problèmes (qqes petits de temps en temps mais rien de grave), j'ai essayé de mettre une cooker sur ma machine au taf (j'y suis depuis 6 mois et je fais pas des upgrade souvent), et j'ai réussi à casser urpmi ou autres packages cruciaux plus d'une fois, donc dire Sid = Cooker, ça me semble un peu présomptueux.

-1 car totalement subjectif

PS: ah oui, une question: y'a un moyen sous mdk d'avoir une mdk 8.2 avec quelques paquets cooker comme on peut avoir sous Debian via Apt::Default-Release et apt-get -t ?

Beaucoup d'OS essaient d'approximer le LRU (qui est assez difficile à implémenter exactement), ce que fait la VM d'andrea (linux 2.4.1x) je ne sais pas, vu qu'elle est très mal documentée.

Pour de la docuementation sur les VMs de manières générales, je te conseille "Modern Operation Systems, 2ème édition" de Andrew S. Tanenbaum.

> mieux par rapport a quoi ? l'actuel 2.4.18 ?

Le patch inclu dans le noyau 2.5.26 n'utilise pas encore les possibilités du -rmap, ce n'est qu'un patch minimal qui implémente le reverse mapping.

Le patch -rmap complet (qui lui ne s'applique que sur un noyau 2.4 et est inclus dans les noyaux -ac et -mjc) donne des résultats concrets, même s'ils sont discutés.

> le gain est il qualifiable et quantifiable ?

Il est très difficile de quantifié ce genre de gain, les benchs de VM sont très peu fiables, et les débats là-dessus assez houleux. Surtout que -rmap est encore en cours d'optimisation.

Ce qui est sûr c'est que -rmap permet au moins de faire passer l'agorithme de remplacement de pages en O(mémoire physique) et non en O(mémoire virtuelle) comme c'est le cas actuellement (mémoire virtuelle incluant le swap, plusieurs fois les pages partagées, ...) donc si la machine est chargée le gain est appréciable.

Un autre problème de la VM courante, liée à l'archi x86, est que le DMA nécessite des pages contigües situées au dessous de 16Mo de mémoire physique pour fonctionner, or obtenir ce genre de page sur une VM classique obligé à parcourir l'ensemble de l'espace d'addressage de tous les processus pour trouver les pages se trouvant dans la bonne zone, avec -rmap c'est instantanné, il suffit de regarder les pages intéressantes directement.

Pas tant que ça, le 2.4 date de janvier 2001, avec un feature freeze à Halloween, on aura pas de 2.6 avant 2003, ça fera un peu plus de deux ans entre le 2.4 et et le 2.6, ce qui est le rythme pour les précédentes versions aussi

linux-2.0.1.tar.bz2 4626 KB 03.07.1996 00:00:00

linux-2.2.0.tar.bz2 10345 KB 26.01.1999 00:00:00

linux-2.4.0.tar.bz2 19325 KB 04.01.2001 00:00:00