Sous certains conditions...
Voilà URL de la merde :
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ra(...)

Licensed Protocols to interoperate or communicate with an Authorized Windows Client. "Server Software" means software that is (i) designed and marketed as server software with the primary purpose of providing computing or data services concurrently to software programs running on multiple other computers, and (ii) running on a machine configured so that its primary purpose is to provide such services concurrently to multiple other computers. "Authorized Windows Client(s)" means the Native Microsoft Windows 95, Windows 98, Windows Millennium edition, Windows NT Workstation, Windows 2000 Professional, Windows XP Home, and Windows XP Professional desktop operating systems for personal computers and successors to the foregoing. "Native" means software as distributed by Microsoft under the applicable end user license agreement for such product and intended for use as part of such product, without the addition of any software code other than subsequent updates or service packs. "Compatible Software" means software that is capable of interoperating or communicating with the implementation of the relevant Licensed Protocol(s) in the Native Microsoft Windows NT Server (version 3.1 and above), Windows 2000 Server, Windows 2000 Advanced Server, Windows 2000 Datacenter Server and Windows Server 2003 server operating systems and successors to the foregoing.

Il y a une liste de protocole libre en annexe :
- ATM
- Automatic Web Proxy Detection
- Bluetooth
- DNS
- DHCP
- HTTP
- etc

De la merde quoi.

> Lire le journal (49 commentaires, moyenne: 1,5).

Celà faisait des années que Red Hat était premier. Debian est passé devant.
http://counter.li.org/reports/machines.php(...)

> Lire le journal (5 commentaires, moyenne: 0,8).

Une non officielle FC3rc2 est sortie :
http://testing.fedora.redhat.com/tree/(...)
ou
http://fedora.linux.duke.edu/FC3-rc/3/(...)

Sortie de la finale prévue pour le 8 novembre.

> Lire le journal (8 commentaires, moyenne: 2,5).

FC3 release candidat est sorti.
Normalement, sa difusion devait être "confidentielle".
Mais il y a une news sur lwn et distrowatch.
http://lwn.net/Articles/107942/(...)

Juste un journal pour dire un "petit" truc. Le paquet fedora-release de FC3rc1 "sucks".
Il n'a pas les dépôts de la distribution.
Mettez à jours fedora-release :
rpm -U http://fr2.rpmfind.net/linux/fedora/core/development/i386/Fedora/RP(...)

Puis vous pourrez utiliser yum et up2date.
Attention, ça pointe sur rawhide. À la sortie de FC3 finale, il faudra mettre à jours les dépôts utilisés (c-à-d mettre à jours fedora-release avec la version de FC3 finale).

> Lire le journal (1 commentaire, moyenne: 3).

J'ai hésité avant de faire ce journal.
Mais je pense que l'avis d'une personne, convaincu par les distributions binaires, sur une distribution source peut intéresser d'autres personnes.
Une personne convaincue par les distributions sources, sera convaincue par Gentoo et ce n'est "pas très intéressant" :-)
En général, je me fais exploser quand je teste un truc.
Je ne dois pas mettre assez de "la distribution de l'avenir", "un potentiel infini", ... et d'autres "formules" magiques.

Si vous vous attendez à des "formules" de ce type, allez vite ailleurs. Merci.

Pourquoi j'ai tester une Gentoo ?
Simple, j'ai voulu faire le point dans les distributions pour voir si ma distribution habituelle était la bonne (pour moi).
J'ai déjà testé Mandrake, Debian, Ubuntu (à l'arrache) et SuSE. Ma distribution habituelle est Fedora.
Donc, logiquement Gentoo est une suite dans cette série.
Sauf que Gentoo est une distribution source et c'est un modèle qui ne m'emballe pas. Il faut compiler, ça prend des plombes, ça bouffe de la place, si ça plante au milieu car t'as mis à jours une autre paquet t'as les boulles graves, si tu tombes sur une mise à jour d'un gros paquet en fait tu l'auras que 12 heures après (faut compiler), etc...

M'enfin, je me force car j'ai lu du bien de la distribution et aussi dans l'espoir de mourir moins con...

Ce test c'est déroulé il y a une semaine. Je dis tout de mémoire. Il y a peut-être des conneries.

Tout commence en allant sur le site Gentoo, je trouve la doc, elle est en français, elle n'est pas longue et correctement organisée. Surtout la doc évite de parler de ce qui n'est pas nécessaire. T'as le manuel d'installation (précis, concis) et pas un manuel d'installation noyé dans un manuel d'administration et d'introduction à Unix avec l'historique du mouvement open source dans le détail.
Bref, ça commence très bien. Une telle distribution dont le *coeur* de cible est les utilisateurs qui veulent un OS aux petits oignons doit s'appuyer sur une bonne doc et une bonne doc n'est pas un roman. C'est le cas. Le manuel d'installation est plus un HOWTO qu'un réel manuel. Pour une installation, c'est nickel. Le manuel d'utilisation ... est un manuel d'utilisation de Gentoo (c-à-d emerge/portage); et pas du logiciel libre en général. Tant mieux, c'est bien foutu.
Seul petit regrêt, le manuel passe rapidement sur l'installation depuis une installation existante alors que ça me semble la meilleur méthode, surtout car la plus confortable. Ton OS quotidien/favoris est disponible et en tâche de fond tu compiles.

En lisant la doc, ce qui m'a le plus particulièrement intéressé, c'est la capacité d'avoir une distribution "pil poid" correspond à mes besoins. Les optimisations de la mort qui tue avec CFLAGS, je m'en fous.
Pour un maximum de souplesse, il faut faire une installation depuis stage1. Je bootstrap. C'est long mais pas tant que ça.

Puis vient la configuration avant de compiler les programmes de mon choix.
Gentoo, donne une souplesse dans la configuration de la distribution assez impressionnante :
- USE : défini les fonctionnalités que vous voulez ou pas. Attention, ne définit pas les paquets que vous voulez ! Sert par exemple à dire d'ajouter le support pour postgresql aux programmes qui l'offrent. Par exemple, s'il y a "postgres" dans USE alors si vous demandez le paquet php, il sera compilé avec support pour postgresql.

- KEYWORDS : Agit comme un "filtre". Permet de choisir entre la branche stable ou de développement par exemple. Interdit aussi l'installation d'un paquet. Par exemple vous avez choisi la "branche" stable et demandez un programme classé dans "testing" alors l'installation du paquet sera refusée.

Il y a aussi les profiles. Par défaut, c'est gentoo-2004.2. Mais avec noyau 2.4. Étant déjà trop habitué à Linux 2.6, j'ai fouillé pour contourner ce point "faible" et découvert que portage supportait les profiles en cascade. Très astucieux ça (ça a l'air récent).
Donc dans le profile gentoo-2004.2 j'ai choisi gcc34 (en fait, pour KEYWORDS = "x86" (stable) c'est gcc 3.3).
Dans ce sous profile il y a Linux 2.6. Parfait, j'ai le bon profile :-)

Après, je fixe la variable USE. C'est assez long à faire et demande réflexion (une erreur peut coûter une longue recompilation). Au final, j'ai une variable USE longue comme un jour sans pain (nptl, python, pam, etc). Cyniquement, je me dis qu'avec tout ça la "fameuse" gentoo va se gauffrer comme une merde. Je n'ai pas cherché un truc tordu pour planté Gentoo ! J'ai honnètement choisi ce qui me convient.
La variable USE (dans /etc/make.conf) étant pour tous les paquets, il est aussi possible de définir la variable USE à utiliser par paquet. Je n'ai pas eu besoin de cette possibilité.
Donc, je choisi les fonctionnalités que je veux (variable USE), dans la "branche" stable (KEYWORDS="x86") dans un profile avec linux 2.6.
Il manque maintenant à choisir les paquets. Celà sera fait avec "emerge nom_paquet".
Le moins qu'on puisse dire, c'est que c'est particulièrement souple _et_ puissant (c-à-d parfaitement gèrable).

Par précaution (car le bootstrap c'est fait avec les entêtes linux 2.4 et sans NPTL), je mets à jours (+linux26-headers +gentoo-dev-source (linux-2.6)), compiles un noyau, et recompiles tous les paquets (emerge --emptytree world).
Tous se passe bien mais je me rend compte qu'il y a quelques dépendances circulaires (entre autre entre nptl/db4/libc, c'est indépendant de Gentoo).
Bon, j'emploi les gros moyens. Je passe à stage2 (emerge system) et recompile encore le tout (emerge --emptytree world).
C'est long....
Mais ça ne me dérange pas. Je fais ça en chroot (+ screen) depuis ma distribution "normale" que je peux utiliser pleinement comme d'habitude.
C'est long ... mais c'est bon. Tout est d'équerre. Un petit "ooops", j'ai du ajouter "posix" pour perl.
Notons que je fais ça depuis FC3T3 et que chroot n'a pas posé de problème contrairement à Debian et Ubuntu.
Avant d'attaquer le "gros" reste (la compilation des programmes de mon choix), je fais quelques "emerge --verbose --pretend paquet" pour voir ce qui m'attend. À vu de pif, tout est correcte. Les dépendances sont pertinentes et je n'ai pas à ajouter de trucs (par contre, parfois, certaines dépendances semblent inutiles). Dans les paquets, il y a des paquets "virtuels" comme le paquet gnome. Par exemple "emerge gnome" signifie pour ma configuration : installe Gnome (les paquets "réels" et stables qui vont biens), demmerde toi avec les dépendances en tenant compte de la variable USE que j'ai défini.
Je lance "emerge postgresql subversion php x11 gnome evolution openoffice-xiniam pan ..." et je vais me coucher avec l'assurance de voir un joli plantage le lendemain matin compte tenu de mon USE.

Une petit explication sur "emerge 'paquet'". C'est un peu plus subtile qu'un "apt/yum install 'paquet'" avec la compilation en plus.
Les emerges explicitent (qui ne sont pas liés à une dépendance) sont stockés dans "world". World indique uniquement les paquets que vous avez explicitement demandés et donc dont que vous avez explicitement besoin. Ainsi, si après une mise à jours, un paquet n'a plus de dépendance avec world, vous (en réalité emerge/portage) pouvez facilement le savoir et le supprimer. Celà se fait avec "emerge depclean". Un "emerge --pretend depclean" ("--pretend" liste ce qui va être fait) est conseillé néanmoins :-).

Ou en étions nous ? Ah oui, je suis allez me coucher après avoir lancé un énorme "emerge ...." et me suis préparé psychologiquement à voir un plantage le lendemain matin. Le lendemain matin au réveil, je vais en direction de mon PC le sourire en coin.
Énorme déception. Ça compile toujours "joyeusement".

Je regarde le log de la compilation et je vois quelques "warning, lancer etc-update".
J'arrêtes la compilation (^C) et m'exécute. etc-update est assez trivial/basic mais astucieux et bien vu. Il permet de fusionner les fichiers de configurations actuels avec les nouveaux fichiers proposés. C'est un outil merge classique comme avec les gestionnaires de version. Je ne vois rien de "grave" et tout (deux fichiers :-)) est fusionné "les doigts dans le nez".
Je relance la même longue commande emerge (moins ce qui a déjà été fait) en me disant que c'est un bon test pour voir comment emerge va reprendre son travail. Ça roule sans problème.

Gentoo a aussi des "fonctionnalités" intéressantes que je n'ai pas testé. Il y a le flag "hardened" pour USE qui renforce la sécurité. SeLinux est aussi supporté et tout est configuré à la volé (comprendre avec une lonnngguuueee compilation). En fait, on trouve pratiquement tout.

Gentoo étant orienté source, on pourrait croire que c'est relativement "rustre" et que les paquets sont brutes de décoffrage. En fait non. Il y a beaucoup de "add-on", de patchs spécifiques.
De même, les fichiers de configurations par défaut sont globalement bien foutus et ce n'est pas le stricte minimum qui est fourni.

Enfin, la compilation est terminée. Dieu que c'est long. Je parcours l'énorme log et je constate qu'il reste quelques problèmes de dépendance circulaire. Mais Gentoo n'y est peut rien. J'ai autre chose à faire pour les deux jours à venir et pendant ce temps je peux refaire un "emerge --emptytree world". Je le fais.

Deux jours plus tard, tout est place. Je fais le tour du propriétaire :
- Linux 2.6.8.1 + patchs
- libc 2.3.3 assez récente
- evolution 1.4 (c'est la branche stable)
- firefox 0.10
- gnome 2.6
- xorg 6.8.0
etc...


Pour une version stable, c'est à jour.

Avant de rebooter sous Gentoo, il faut passer un bon moment avec la doc et les fichiers de configurations dans /etc. Rien de très dure mais assez long.
Je paufine /etc, me crée un compte, et je vérifie une dernière fois.

Tout est OK, je reboote.

Je suis sous Gentoo. Que dire ? Ça marche. À partir de là, c'est une distribution "comme les autres". Son "charme" n'est pas là. Du coup j'ai plus envis de jouer avec elle ;-|
Pour le "fun", je fais :
- emerge --sync
- emerge --deep update

Fichtre. Il y a une mise à jours d'openoffice....
^C

Je vais finir sur un reproche. Il manque un "journal" des compilations avec les warnings/conseils donnés par emerge. Fouiller dans les logs (qu'on aura pris soit de créer...) est lourd.


Conclusion:

Je ne parle que de l'emploi "stage1" (ou stage2, il n'y a pas énormément d'écart) ou on peut réellement tirer avantage de la formidable souplesse de Gentoo par rapport aux autres distributions.
Je ne change pas de distribution et reste un adèpte des distributions binaires (avec les sources de disponibles qu'en même :-)).
Néanmoins, force est de constater que Gentoo est particuliairement bien foutu. L'installation est "laborieuse" mais un usage quotidien semble tout à fait envisable avec la branche "stable" même adaptée aux petits oignons comme je l'ai fait. Il n'y a qu'à faire "emerge --sync ; emerge --update" de temps en temps et suveiller le log de les compilations.
Il ne faut pas si tromper, même si je ne passe pas sous Gentoo, cette distribution, pardon, cette meta-distribution m'a _réellement_ impressionnée. Elle m'a impressionné par ces idées/inovations et par la qualité globale compte tenu des contraites énormes : faire une (meta)distribution source _hyper_ configurable, _réellement_ gérable et stable.

Chapeau bas.

Et en plus ça marche sur plusieurs plate-forme. Que dire de plus ? Les faits parlent d'eux même.

Il est vrai que j'ai du mal à voir l'intérêt _réel_ de tout ça. Peut-être pour l'embarqué ou quelques cas particuliers. Quoiqu'il en soit, c'est une formidable bête à compiler et une plate-forme de test du logiciel libre (compiler dans 50 000 configurations différentes) formidables. C'est peut-être grace ça qu'elle est déjà disponible sur plusieurs plate-forme et très à jours.

Bref, gouttez la et si le coeur vous en dit bouffez en tout les jours :-) (surtout si vous avez un gros apétit (genre bi-cpu ou quadri-cpu)).
Bien que l'installation ne soit pas très dure (mais très loins d'être "out of box"), elle demande un minimum de background et surtout de culture du logiciel libre. Sinon on n'est pas capable de définir correctement ce qu'on veut (variable USE) et Gentoo (depuis stage1) est sans intérêt.

Par rapport à la série de distribution que j'ai testé, Gentoo a amené de la fraicheur. Elle a du "chien" par rapport aux autres. C'est aussi la dernière distribution que je teste et je suis content de terminer sur Gentoo et non sur une ennuyeuse ... ou ...

> Lire le journal (15 commentaires, moyenne: 2,6).

Causons un peu desktop, poste client. Attention, pas dans le sens :
- "la transparence xorg roxor"

Le stateless n'est pas nouveau et d'ailleurs ça a été fait. En même temps ça n'a jamais été réellement fait... C'est toujours compliqué à mettre en oeuvre, à déployer, ce n'est pas générique, il y a des contraintes, etc...

Red Hat veut faire du stateless (traduction svp) un élément centrale.

C'est particulièrement intéressant en entreprise.

Red Hat a défriché le terrain.
Introduction par Havoc Pennington (assez technique) :
http://people.redhat.com/~hp/stateless/StatelessLinux.pdf(...) ("Introduction to stateless Linux - Proposal for the Fedora Project")

David Malcolm a fait un Howto :
http://people.redhat.com/dmalcolm/stateless/stateless-linux-HOWTO-e(...)

Les développements déjà réalisés (sous GPL, évidemment) :
http://people.redhat.com/dmalcolm/stateless/(...)

L'annonce et le thread sur fedora-devel-list :
https://listman.redhat.com/archives/fedora-devel-list/2004-September(...)

Quelques réflèxions sans beaucoup de recul :
- Techniquement, Linux a fait des progrès énormes dans le desktop. Udev, Hal, SeLinux,etc permettent d'envisager des postes clients "exploitables" sans jamais utiliser le compte root ni rogner sur la sécurité.
- Il ne faut pas sous-estimer Red Hat et c'est un évènement important même si actuellement il n'y a presque rien de concrêt. À mon sens, il ne faut pas prendre à la légère cette "annonce" (qui n'en est pas vraiment une...).
- Le rôle et l'importance de Fedora dans Red Hat est encore affirmé. C'est pour ceux qui en doute...
- Petit à petit, et avec une "véritable" vision/projet, Red Hat s'investit dans le desktop (pour entreprise).
- Ce projet va aussi améliorer le Linux "non-stateless" (lire le papier d'Havoc).
- Ça va prendre du temps...


Puisque j'y suis, Colin Charles présente les nouveautés les plus importantes de FC3 (test 2 prévue pour le 20 septembre) et donc aussi de RHEL 4 :
http://www.bytebot.net/talks/FC3-t2rawhide-whatsnew.pdf(...)

> Lire le journal (6 commentaires, moyenne: 5,2).

Je ne ferais pas un topo sur le "pourquoi Debian c'est Bien (TM) pour le LL".
J'ai testé une Debian Sarge. Et ça tombe bien elle est en phase RC.

J'avais deux contraintes (que j'ai appliqué pour les autres distributions que j'ai testé récemment pour comparer) :
- je n'ai pas de graveur.
- Je dois pourvoir tout installer depuis les disques dures. Je ne veux pas abandonner très tôt un test car si je n'arrive pas à mettre en place la connection ADSL :-). Puis ça accélère le test (comprendre : "ça le rend moins pénible").

Sur le site web, je trouve rapidement des torrents pour Sarge.
Fichtre 13 isos ! Que du binaire.
Soit :
- 8 Go !
- plus de 14 000 paquets ! Je ne compte pas contrib (qui a peu de paquet).

Une Fedora (qui n'est pourtant pas considérée comme légère), c'est 2 Go et 1 600 paquets.
Sur mon système, j'ai 455 paquets (je fais le tri après l'installation).
Certe, qui peut le plus, peut le moins.
Mais il est peut-être temps de faire un Debien Extra à l'instar du Penguin Liberation Front ou Freshrpms.
Chercher un paquet de "base" parmis 14 000 paquets, c'est parfois _très_ chiant.
Downloader 13 isos (!) pour ne pas être dépendant du réseau, c'est lourd et pas très "netiquette".
Heureusement, il y a bittorrent.

L'installation Debian à 2 modules/phases :
1- Un OS minimum qui doit tenir en RAM pour faire une installation minimum sur DD.
2- Boot sur l'installation minimum (qui est "énorme" par rapport à 1-) pour finir l'installation.

C'est un détail technique.

Sur les CD, il n'y a pas le nécessaire pour faire une installation depuis le disque dure. Pas cool, ça m'a bouffé du temps pour voir ça.
Je récupère hd-media sur le site Debian.
Nouvelle essai, marche pas. Debian n'active pas le raid automatiquement (même pour les partitions marquées "raid autodetect") alors que Red Hat et Mandrake font ça depuis le moyen âge de l'informatique. Néanmoins, la partition raid est détectée et /etc/raidtab de l'installation est correctement renseigné et activé.
Je déplace les iso sur une partition "normale" et refais l'installation.
J'ai maintenant l'installation minimum sur le disque dure. Il me suffit maintenant de monter les images iso via loopback et faire pointer /etc/apt/sources.list sur les images iso montés.
Problème, /dev/loop* va jusqu'à 7 alors que j'ai 13 ISOs. Un coup de MAKEDEV pour ajouter les /dev/loop* qui manquent (j'ai aussi ajouté dans modprobe.conf "options loop max-loop=32" (j'ai contrôlé dmesg)). Nouvelle tentative, nouvel échec.
Je passe sur mon OS habituel, je montes toutes les isos et je copie. Bref, j'en suis à 16 Go d'occupation disque pour faire une installation !
Je continue l'installation. Ça se passe correctement. L'installation se fait en "medium" et j'ai quelques questions qui me laissent "sans voie" (notament des questions sur le clavier et X11). Je laisse les valeurs par défaut. Dans tasksel, je demande tout (ce qui n'est pas synonyme de "tous les paquets").

L'installation est finie !

Mais que de chemin parcouru.
Le "pire", ce ne sont pas les problèmes ici et là. Il ne faut pas oublier que c'est une beta/rc.
Le pire est la quantité de doc qu'il faut bouffer pour se lancer dans une installation avec une "relative" confiance.
Ça fait mal à dire, car on sent bien que le guide d'installation est fait avec les meilleurs intentions, mais c'est trop gros ! Et c'est trop gros car le guide d'installation fait aussi guide d'administration, compilation noyau, etc. Qu'on soit bien claire, je ne dis pas que le contenu est sans intérêt ou de mauvaise qualité, mais il n'est pas au bon endroit.

Je redémarre pour commencer "réellement" le test. L'installation devant être rare avec Debian, il ne faut pas y faire trop attention. Ceci dit, l'ergonomie a l'air d'être une notion étrangère à toute la procédure d'installation (ça n'aide pas pour la doc...). Oui, on peut faire pire. Mais on peut faire beaucoup mieux (et toujours en mode texte).

Je me loggue sur une console texte et ... pas de "caplock" ni de "Verr Num". Je me dis que c'est multi-plateforme et que c'est pour avoir le même comportement sur toute les plate-formes. Je me loggue sous X11 ... "caplock" et "Verr Num" sont fonctionnels. Ce n'est pas très cohérent.

Je regarde /proc/modules juste après le boot et j'ai 58 modules de chargé ! Je n'ai pas usb et pourtant il y a des modules usb de chargés, etc. Je comprend maintenant pourquoi on explique très tôt qu'il faut recompiler un noyau...

Le noyau installé est un i386 alors que j'ai un athlon et qu'il y a un noyau k7 et i686 de disponible. De même pour la libc.

Utf n'est pas utilisé par défaut.
Il n'y a pas less ! Faut faire un "apt-get". Il n'y a pas les alias "rm=rm -i ..." pour le compte root. vim n'est pas installé (c'est que vi).
Alors que Debian charge 58 modules au boot, il ne charge pas psmouse. Donc XFree86 plante. Ça doit être spécifique à l'utilisation du noyau 2.6.
Les valeurs de HorizSync et VertRefresh dans XFree86 sont absentes (Donc je suis temporairement limité à 1024x768).

Franchement, je me demande si Debian ne fait pas exprès d'avoir un boot moche. Je ne demande pas une barre de progression graphique. Mais quelque chose de claire, lisible. Actuellement, c'est vraiment brouillon.

Il y a pleins de petits trucs "irritants".
Jusque là, deux points positifs :
- apt/dpkg/etc sont extrèmement rapides alors qu'il y a 14 000 paquets de disponibles !
- aptitude est beaucoup mieux que dselect.

Allons faire un tour du côté de l'interface graphique. Le gdm utilisé semble être une vieille version. Je me loggue et par défaut c'est KDE. Version 3.2.3. Le son pour les évènements est activé. Quel horreur (l'activation par défaut), Mandrake(10.1) et Red Hat ont bien fait de virer ça.
Je passe sous Gnome. Gnome se plaind du réseau (j'ignore). C'est Gnome 2.6. Mozilla n'utilise pas le thème gtk en cours. C'est le Gnome "standard" par défaut il me semble. Les barres de taches sont petites. C'est un problème lorsqu'on ajoute certaines applets.

Je décide de configurer ma connection ADSL. Je compile le driver, je le charge, ça marche.
Je configure ppp, je lance et ça plante : "Unresolv symbol". Il manque libatm.so. Le légendaire .deb a des faiblesses... J'ajoute libatm et refais un test. Échec. Pour des raisons que j'ignore, le module pppoatm n'est pas chargé. Bizarre, il se charge tout seul sur les autres distributions. Pas grave.

Je reboote. Je lance adsl et... ça ne marche pas. En fait, Debian charge automatiquement unicorn_pci_eth (que je viens d'installer) alors qu'il faut charger unicorn_pci_atm. Je ne sais pas d'où vient cette manie de tout charger mais ça commence à être pénible...
Je configure un serveur DNS cache. Je teste et ... ça ne marche pas. Il n'y a pas de resolv.conf . Je l'ajoute. Ça ne marche toujours pas. Je fouille et je constate que l'interface lo n'est pas activée !
C'est quoi ce délire ?
nb : je sais que l'interface lo n'est pas obligatoire.

Bon, je tape des "ifconfig ..." et "route add ..." pour faire ça à l'arrache.
Je suis sur le web. Enfin...

Je reconfigure apt pour ne plus pointer sur les iso mais sur la dernière version de sarge. Je lance la mise à jours.
En attendant, je recherche où il faut tripoter dans la distribution pour avoir l'interface lo et "proprement". Après de très très fastidieuses recherches (ben oui, il y a 14 000 paquets) je trouve "ifupdown". Utiliser ça, c'est comme éditer à la main les fichiers dans /etc/sysconfig d'une distribution rpm-base. Ça marche mais on peut légitimement penser qu'il y a un programme pour ça.
Malgrès les apparances, ça allait. Je n'en avais pas encore marre alors que j'avais passé plus d'une journée à batailler.

Je vais sur le web à la pêche aux informations. Je tombe sur une doc Progeny. Je vais à la section networking pour voir ce qui est conseillé d'utiliser pour configurer le réseau. Et là, patatra :
Pour configurer le réseau, gnome-system-tools est conseillé !
En gros, la distribution ne propose rien. Dans ces conditions, inutile de chercher une cohérence (comme le MCC de Mandrake ou les (system|redhat)-config-* de Fedora/RedHat, etc).
Du coup, j'en ai HYPER marre. J'ai arrêté mon test, ce qui fait qu'il est pas aussi "complet" que je le veux alors que j'ai passé beaucoup plus de temps sur Debian que sur les autres...

Voilà une distribution qui n'installe pas less (surement pour des raisons de place disque) mais qui conseil d'installer gnome-system-tools (et gnome donc) pour configurer le réseau. La distribution pèse 8 Go, mais ifupdown n'est pas installé. C'est une distribution principalement pour le réseau mais l'interface lo n'est pas configurée. Etc...

Franchement, ça me fend le coeur. On sent dans la distribution pleins de bonnes intentions. Et ce ne sont pas "seulement" des intentions, c'est souvent utile. Malheureusement la somme de plein de bonnes intentions ne fait pas forcément un bon "tout". Cette volonter de satisfaire tout le monde en devient presque contre productive. L'absence de compromis ou d'accèpter de temps à autre une régression, semble finir par produire un système qui ne satisfait personne.
Que veut dire cette branche principale (main) de 8 Go ?
Si Debian met dans main "uniquement" les paquets utilisés par plus de 2 % des utilisateurs debian, la distribution sera au moins deux fois plus légère. Les autres paquets seront dans "extra" par exemple (évidemment, il ne sagit pas de les supprimer).
Pourquoi Debian fait encore de Linux 2.4 son noyau par défaut pour sarge/testing qui est une branche de développement? Lorsque Sarge sortira les nouvelles offres des "poids lourds" du serveur seront uniquement basées sur Linux 2.6.
Sortir une nouvelle distribution avec par défaut un noyau en fin de vie est "bizarre". Comme Sarge supporte aussi Linux 2.6, ça fait beaucoup de boulot pour pas grand chose. Pour une branche de développement, Debian pourrait être plus "volontaire". Fedora utilise uniquement Linux 2.6 depuis FC2test1 (début 2004) et la prochaine RHEL sera linux 2.6 uniquement aussi.
Cette "histoire de noyau" me parait étrange car un changement majeur de version d'une distribution est le moment idéal pour monter en version un élément aussi important que le noyau. Je suis presque sûr que mon problème de souris ne serait pas là si Debian s'était concentré sur Linux 2.6.

J'avais testé Woody à sa sortie. Ce qui est "fou" c'est que peu de chose ont changé. Ça reste une vieille distribution alors que j'ai testé le dernier cri Debian ! Certe, on peut aligner les numéros de version des différents logiciels et constater qu'ils sont globalement récents. Mais tout le reste semble relever du même esprit. Un petit exemple :
- Debian demande le mot de passe root pour rebooter même pour les terminaux locaux. Pourquoi interdire le reboot pour :0.0 alors que la prise de courant doit sûrement être à côté de l'utilisateur ?
La rentrée (octobre/novembre) sera chaude avec les nouvelles SuSE, Mandrake, Fedora. Lorsque Sarge sortira, elle sera aussi sous les feux des projecteurs. Surtout car c'est une évènement plus rare que les autres distributions.
Les testeurs vont vites (2 jours à 1 semaine). Dans ces conditions, il n'est pas facile pour une distribution de séduire.
Pour Debian 3.0 (il y a 2 ans), il y avait eu quelques articles au "vitriol" dont le fond n'a pas été remis en cause.
Pour Debian 3.1 se sera la même chose. Pas grave pour les utilisateurs actuels et même futur. Ce qui est embêtant, c'est que Debian devra se contenter (peut-être pour son bonheur) de peu ou pas d'aide de la part des acteurs commerciaux. Linux étant en expansion, sa niche (les geeks) va diminuer et il ne sera pas un "OS pour tous".

Bien sûr il y a des dizaines de millier d'utilisateurs de Debian qui sont parfaitements satisfaits. Sur une longue période, ils ont sûrement passé beaucoup moins de temps à installer et paramétrer des distributions GNU/Linux que moi.
Et ça grace à Debian :-)

> Lire le journal (91 commentaires, moyenne: 1,7).

En ces temps de "sécurit" aigu, il convient de bien contrôler ce qu'on nous propose (TCPA, DRM, etc). J'avoue être d'une grande méfiance dans ce domaine.

Il y a une petite nouveauté dans Linux qui commence à être exploité.
Il est possible de signer les modules du noyau et interdire de charger les modules qui n'ont pas une signature valide.

La signature est une signature gpg "classique" stockée dans le modules en utilisant les capacités ELF (ce n'est pas un fichier .sig à part).

Le contrôle de la signature est fait "classiquement" par le noyau avec la clée public.

Allons dans le détail :
* dans /usr/src/linux/crypto/signature/key.h il y a la (ou les) clée public gpg (pour contrôler la signature des modules).
* /usr/src/linux/scripts/modsign/modsign.sh signe les modules en utilisant une clée privée gpg.
* La clée public est dans le noyau. Donc pour changer/ajouter une clée public, il faut recompiler le noyau (cette exigence est assez évidente). Une indirection supplémentaire serait un plus (Par exemple : le noyau aurait une clée et un modules signé par la clée privée du noyau contiendrait d'autres clées publics).

C'est assez simple côté utilisateur final mais néanmoins assez chiant à mettre en oeuvre actuellement.

Avantages :
- Il est difficile pour un cracker de charger un modules "méchant" s'il n'est pas signé
- "traçabilité" des modules.

Utilisation "concrète" :

Fedora (et sûrement Red Hat dans un proche avenir) utilise ça.
Le noyau Fedora a une clée public Red Hat :
- "pub 512D/D7186B51 2004-08-16 Red Hat, Inc. (Kernel Module GPG key)"
Évidement, personne (sauf Red Hat) à la clée privée qui signe les modules.

Vous voyez déjà le "drame" :
- si le module n'est pas signé par "M. Red Hat" (ou IBM si sa clée public est aussi ajoutée dans le noyau), alors le module ne peut pas être chargé.

Voilà ce que ça donne :
modprobe: FATAL: Error inserting ext2 (/lib/modules/2.6.8-1.521/kernel/fs/ext2/ext2.ko): Operation not permitted
kernel: An attempt to load unsigned module was rejected

En fait il n'y a pas de problème et ce pour plusieurs raisons :
- Pour que le noyau exige des modules signés il faut explicitement le demander (paramètre enforcemodulesig).
- Le noyau n'est pas signé mais uniquement les modules.
- C'est le noyau qui vérifie la signature des modules et pas l'inverse. Donc on est jamais dépendant des modules et surtout d'un module binaire qui exigerai un noyau signé par Red Hat par exemple.
- Il y a les sources :-)

Cette fonctionnalité a été initialement développé par un développeur IBM.
Elle a été reprise par un dev Red Hat.
Les patchs nécessaires sont dans rawhide (paquet kernel) :
http://fr2.rpmfind.net/linux/fedora/core/development/SRPMS/(...)
Ce sont les patches *modsig*

PS : rpm n'est pas le plus ouvert des standards (par exemple tar ou cpio) mais il n'est pas necéssaire d'avoir rpm pour lire un rpm
/usr/lib/rpm/rpm2cpio.sh :
#!/bin/sh

pkg=$1
if [ "$pkg" = "" -o ! -e "$pkg" ]; then
echo "no package supplied" 1>&2
exit 1
fi

leadsize=96
o=`expr $leadsize + 8`
set `od -j $o -N 8 -t u1 $pkg`
il=`expr 256 \* \( 256 \* \( 256 \* $2 + $3 \) + $4 \) + $5`
dl=`expr 256 \* \( 256 \* \( 256 \* $6 + $7 \) + $8 \) + $9`
# echo "sig il: $il dl: $dl"

sigsize=`expr 8 + 16 \* $il + $dl`
o=`expr $o + $sigsize + \( 8 - \( $sigsize \% 8 \) \) \% 8 + 8`
set `od -j $o -N 8 -t u1 $pkg`
il=`expr 256 \* \( 256 \* \( 256 \* $2 + $3 \) + $4 \) + $5`
dl=`expr 256 \* \( 256 \* \( 256 \* $6 + $7 \) + $8 \) + $9`
# echo "hdr il: $il dl: $dl"

hdrsize=`expr 8 + 16 \* $il + $dl`
o=`expr $o + $hdrsize`

dd if=$pkg ibs=$o skip=1 2>/dev/null | gunzip

> Lire le journal (4 commentaires, moyenne: 1,8).

Oui.

Sous Linux il faut partager son expérience, ses compétences, etc . On me disait ça et je le pensais.

Non. Plus maintenant.

J'ai aimé passer sous Unix/Linux car tout y était 10 fois plus cohérent que sous Windows.
Le contact avec Linux était rugueux mais passionnant, formateur, etc.

Ben maintenant c'est la philosophie Windows qui a cours.
Le linuxien nouveau se fout de la rigueur, du libre, des licences (d'ailleur ils ne sont maintenant qu'un minorité à connaitre réellement la GPL). Il pense comme sous Windows. il est client d'informatique, un gosse capricieu.

J'ai déserté les mailings/sites d'aide tellement les nouveaux me cassaient les couilles.

Je vais me la jouer élite et bien sélectionner mes "relations" maintenant.

Parler de communauté Linux avait un sens avant.
Maintenant la communauté Linux est la même que la communauté Windows.

NB : Il n'y a pas que des cons sous Windows. Loin de là. Mais ce n'est pas la majorité. Maintenant c'est pareil pour Linux.

> Lire le journal (74 commentaires, moyenne: 3,2).

C'est avec "tristesse" que je me rend compte que cette l'idéologie est de plus en plus populaire ici :
- Éduquer le developpeur/utilisateur et en demander le moins possible à l'OS.

Ça vient souvent de Windowsiens. A l'origine tout le monde pensait que c'était pour justifier la faiblesse de leur système et maintenant les gens trouvent ça normal.

Donc s'il y a des problèmes avec le multi-utilisateur c'est la faute aux développeurs d'applis, si les virus prolifèrent c'est de la faute aux utilisateurs, etc...

De tel propos sur un site Windows me laissent totalement indifférent. À la limite, ça me fait rire. Mais ici ... (et ce n'est pas le première fois) : http://linuxfr.org/2004/09/01/17138.html(...)

Si l'OS est multi-utilisateur, c'est à l'OS d'être multi-utilisateur et pas à l'applis (c'est tellement con à dire...).
Si l'OS est multi-tache, c'est à l'OS d'être multi-tache (btw, que devait faire le développeur sous Win 3 pour faire un semblant de multi-tache? C'était "normal" ?).
etc

J'espère que ce courant de pensé dlfp ne va pas atteindre Unix/Linux et que ces OS resteront au plus près du "do the right thing" et ne va pas sombrer dans le :
- vite fait mal fait, et c'est aux développeurs/utilisateurs de compenser les faiblesses.

> Lire le journal (187 commentaires, moyenne: 2).

http://mail.gnome.org/archives/gnome-announce-list/2004-September/m(...)

Je ne sais pas si c'est nouveau mais je trouve que c'est une très bonne idée de splitter le projet en 3 parties :
- platform
- desktop
- bindings

> Lire le journal (6 commentaires, moyenne: 1).

Yum 2.1.0 est sorti.
Beaucoup de bonnes choses :
- plus rapide (beaucoup)
- dépôt utilise un nouveau format de donnée (plus léger, xml et indépendant de rpm/dpkg)
- etc

Le blob Seth Vidal :
http://blog.sethdot.org/index.cgi/146(...)

Aussi sur FedoraPeople :
http://fedora.linux.duke.edu/people/(...)

L'annonce sur mailing devel de Fedora :
http://www.redhat.com/archives/fedora-devel-list/2004-August/msg011(...)

Nouveau format de dépôt :
http://linux.duke.edu/projects/metadata/(...)

Le site Yum :
http://linux.duke.edu/projects/yum/(...)

Sera rapidement dans Rawhide et donc sera dans FC3.

Actuellement, c'est principalement pour les développeurs/testeurs.

> Lire le journal (24 commentaires, moyenne: 1,9).

J'ai toujours été perturbé par FAM. Avoir un démon pour une tâche de ce type...

Mais c'est fini !
Le projet Marmot qui a été chauffé à blanc par le démon de la Fam nous a accouché du Gamin.

C'est pas claire ? Voir ici :
http://www.gnome.org/~veillard/gamin/overview.html(...)

> Lire le journal (14 commentaires, moyenne: 2,5).

Perso, les '0' à la place de 'NULL' me gonffle. C'est très courant en C.

Vu sur lwn.net.

Voilà que Linux va faire la chasse à l'utilisation abusive de '0' pour les pointeurs :

http://lwn.net/Articles/93574/(...)

Un mail de Linus pour clarifier le tout :

http://lwn.net/Articles/93577/(...)

 > What's wrong with using 0 as the NULL pointer? In contexts where
 > a plain 0 is unsafe, NULL is usually unsafe as well.

It's not about "unsafe". It's about being WRONG.

The fact is, people who write "0" are either living in the stone age, or 
are not sure about the type.
[...]
In other words:

	char * p = 0;	/* IS WRONG! DAMMIT! */
	int i = NULL;	/* THIS IS WRONG TOO! */

and anybody who writes code like the above either needs to get out of the 
kernel, or needs to get transported to the 21st century. 

		Linus

J'adore son style.

> Lire le journal (49 commentaires, moyenne: 2,5).

J'ai vu ça sur mailing Fedora :
http://www.redhat.com/archives/fedora-devel-list/2004-July/msg01041(...)
---------------------------------------------

From: Build System

New package valgrind
Tool for finding memory management bugs in programs
---------------------------------------------

From: "Bill Rugolsky Jr."

Not to look a gift horse in the mouth, but what happened
to the alleged patent issues?

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=78403(...)

Is valgrind really here to stay? Wonderful if true, because
Purify/Quantify for Linux is broken on Fedora glibc (only works
on RHEL3), and is much more cumbersome to use anyway.
---------------------------------------------

From: Bill Nottingham

They have been resolved. I will try and get something more
official-sounding, as otherwise this just comes out as
'Trust me! Really!'.
---------------------------------------------


Très bonne nouvelle !

Site Valgrind :
http://valgrind.kde.org/(...)

> Lire le journal (1 commentaire, moyenne: 1).

MySQL v4 est aussi "connu" pour ne pas être diffusé par Red Hat et Fedora (d'autres ?) pour des raisons de licence de libmysqlclient.

From: Zak Greant <zak@mysql.com>
To: community@lists.mysql.com
Date: Thu, 15 Jul 2004 09:41:25 -0600
Subject: A new version of the MySQL FLOSS Exception

Greetings All,

I am very pleased to announce that the latest version of the FLOSS
exception has made it through rounds of review by the community, the
MySQL lawyers and MySQL team.

The FLOSS Exception is an exception to the terms and conditions of the
GPL licensing for the MySQL clients that allows for greater
compatibility between the GPL and other common Free Software/Open
Source licenses.

The complete text of the latest version is posted at
http://zak.greant.com:8888/licensing/getfile/licensing/FLOSS-except(...)

A history of changes may be found at
http://zak.greant.com:8888/licensing/rlog?f=licensing/FLOSS-excepti(...)

(Click the (diff) links on the preceding page to see changes between
version.)

Barring any unforeseen difficulties, this exception should be added to
the next minor releases of the various official MySQL client APIs.

Cheers!
--zak

Reste à espérer que cette licence soit dans les sources. Sinon c'est sans valeur.

> Lire le journal (15 commentaires, moyenne: 1,9).

Note de mise à jour :
http://subversion.tigris.org/svn_1.1_releasenotes.html(...)
Overview

Subversion 1.1 can best be summarized as: (1) a new non-database repository back-end
Plus d'info ici :
http://web.mit.edu/ghudson/info/fsfs(...)

Symlink versioning

This feature allows unix users to to place symlinks under version control. (Note: this is not about creating links inside a repository that point to other parts of the repository!)

Compatibility Concerns

Subversion's compatibility and version-numbering policy is documented in the project's HACKING file. Here's a quick summary:

* Database schema: if upgrading to Subversion 1.1, there is no need to dump and load your repository. There will be no changes requiring dump/load before Subversion 2.0.

* Client/server compatibility: a 1.X client and 1.Y server are always interoperable. However, the latest features or bugfixes may not be available unless both client and server are the latest version.

* API/ABI compatibility: the 1.1 release only adds new functions; thus a 1.0 program can both compile against and use 1.1 libraries at run-time, but a 1.1 program cannot use 1.0 libraries.

> Lire le journal (4 commentaires, moyenne: 2,5).

L'annonce :
http://www.redhat.com/archives/fedora-announce-list/2004-July/msg00(...)

À lire car toujours aussi rigolotte mais assez peu informative cette foi.
Je répète c'est une TEST c'est-à-dire une BETA. C'est pour les testeurs. Si ça plante c'est normal.
Autre rappel, la mise à jour via yum/apt/up2date n'est jamais prévue lorsqu'il s'agit d'une TEST. Si ça marche tant mieux mais ne faites des rapports de bug qu'avec une installation fraiche.

Disponible pour i386 et x86_64. En images CD (4) et DVD.
Lire l'annonce pour les miroirs et les torrents.
VOTRE ATTENTION : Il y a des torrents dédiés à l'Europe. Ça évite les transferts transatlantic. Utilisez les si vous êtes en Europe (ça marche diablement bien, je download à 110 Kio pour une ligne à 128) :
http://sunsite.mff.cuni.cz/fedora-torrent/(...)

Distribution pas aussi "révolutionnaire" que la FC2.
SeLinux sera activé par défaut (il s'en est fallu de peu pour FC2).
Evolution 1.5.9 (evolution 2.0 est prévu pour FC3 finale).
gcc 3.4 par défaut et gcc 3.5 en "preview".
Gnome 2.7 (Gnome 2.8 est prévu pour FC3 final).
Udev et hal. Udev ne sera peut-être pas utilisé par défaut pour la version finale. C'est en discussion.

FC3 sera la base de la future RHEL 4.
FC3 finale est prévue pour le 18/10 :
http://fedora.redhat.com/participate/schedule/(...)

RHEL 4 est prévue début 2005.

Différences FC et RHEL :
http://fedora.redhat.com/about/rhel.html(...)

http://www.fedora.us/(...) devrait proposer rapidement des paquets supplémentaires pour FC3T1 (mplayer, apt, etc).

> Lire le journal (10 commentaires, moyenne: 2,3).

Je peux faire un journal.

J'en profite.

* Le cuisine de SCO ne prend pas
et ça sent le brulé dans toute la cuisine :
http://lwn.net/Articles/93111/(...)

* Prochaine release d'X.Org en préparation.
http://freedesktop.org/pipermail/xorg/2004-July/001442.html(...)
Suivez le thread pour connaitre les prochaines nouveautés.

* FC3 test 1 bientôt disponible
http://fedora.redhat.com/participate/schedule/(...)
sortie de la version finale prévue pour le 18/10
Quoi de neuf :
http://www.redhat.com/archives/fedora-devel-list/2004-July/msg00056(...)
C'est encore en discution (avec ou sans udev, eclipse, theora, revenir à 3 CDs pour Core et déplacer des trucs dans Extra, etc).

* Slackware n°1 sur distrowatch
http://www.distrowatch.org/(...)
Enfin sur le dernier mois. Non, je ne vais pas conclure que c'est la distribution la plus utilisée.

* Red Hat invite les développeur d'OpenGFS
Après le passage sous GPL de GFS, Red Hat invite l'ensemble des développeurs travaillant sur des solutions cluster à une rencontre :
http://opengfs.sourceforge.net/(...)
RedHat invites us to a face-to-face technical meeting with GFS and cluster component engineers, to be held on July 29 and 30, 2004, in Minneapolis. Anyone interested is welcome to attend this rare opportunity (limited to first 50 people, first-come-first-serve). For more info, contact RedHat's Daniel Phillips.

> Lire le journal (8 commentaires, moyenne: 1,5).

Je n'ai pas vu cette information passer ici.
C'est une copie d'un commentaire que j'ai fait ici :
http://linuxfr.org/2004/06/25/16655.html(...)

Je lisais la "propagande" Red Hat sur GFS et je suis tombé sur ça :
http://www.redhat.com/whitepapers/rhel/RHEL_Scalable_OS_Storage_Inf(...)
The recently published world record TPC/C benchmark, achieved by a partnership of Oracle, Red Hat, and HP, included a storage system with over 2000 physical disks providing a total of 93TB of data, hosting a 90TB database. So the ultimate scalability of Linux is not in doubt. The photograph below shows the actual benchmark configuration. Details of the benchmark can be found at http://www.tpc.org/(...) .

Voir la photo du monstre en bas de la page.

Le record tpc :
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=al(...)

La bécane (le monstre):
http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=103120803(...)
Total System Cost : 6,541,770 US $
Server Information
CPU: Intel Itanium 2 Processor 6M 1.5GHz
# of CPUs: 64
Cluster: Y

Voir aussi :
http://www.tpc.org/results/individual_results/HP/HP%20Integrity%20r(...)
768 Go de mémoire vive !


Ça mériterait presque une news. Mais c'est un peu vieu (08/03) même si le record tient toujours.

> Lire le journal (7 commentaires, moyenne: 0,4).