Le wifi sous Linux sucks et depuis longtemps :
http://liquidat.wordpress.com/2007/02/12/linux-wireless-summ(...)

La société Devicescape a mis sous GPL sa pile et elle présente de bonnes fondations pour le futur de Linux. Merci à Devicescape.

John W. Linville mainteneur du composant Linux a depuis longtemps annoncé l'intention d'avoir cette pile en upstream :
http://www.spinics.net/lists/netdev/msg03625.html

Elle est maintenant dans la branche mm (passage obligatoire avant la branche Linux et maintenue par Andrew Morton).
http://liquidat.wordpress.com/2007/03/02/new-linux-wlan-subs(...)

Il est prévu qu'elle soit en upstream pour Linux 2.6.23 ou 2.6.24.

Les branches développement d'Ubuntu et Fedora ont cette nouvelle pile. C'est excellent, ça va faciliter les tests par le "pépin moyen" et les remontées de bug (il peut être intimidant de faire un rapport de bug sur lkml ou http://bugzilla.kernel.org/ ). Ça va impliquer les développeurs et testeurs noyaux de Fedora et Ubuntu sur quelque chose avec un bon potentiel au-lieu de maintenir une solution sans avenir. De plus Fedora et Ubuntu utilisent NetworkManager pour établir la connexion ce qui ne peut que favorise une synergie.

Cette nouvelle pile sera probablement dans FC7 (en tout cas elle est actuellement dans rawhide).
Quelqu'un dans l'audience peut en dire plus pour Ubuntu ?

Actuellement il y a peu de driver. Mais bonne nouvelle, le driver Intel ipw3945 qui utilise actuellement un deamon binaire, va abandonner ce dernier et fournir une solution 100 % libre pour la nouvelle pile (sauf peut-être le firmware). Avec l'ancienne solution Fedora ne pouvait fournir le driver Intel.


Vu sur OsNews : http://www.osnews.com/comment.php?news_id=17417


En passant, Con Kolivas a posté un patch de l'ordonnanceur Linux très intéressant :
http://marc.theaimsgroup.com/?l=linux-kernel&m=117299174(...)
En tout cas il est prometteur et a des retours très positifs. Mais a aujourd'hui, comme on peut s'y attendre, quelques bugs.

Il sera dans la branche mm assez rapidement.
Quoique... :
http://marc.theaimsgroup.com/?l=linux-kernel&m=117313519(...)

Mainline is crap at present, and -mm is crap^2.

:-)

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

L'article : http://www.phoronix.com/vr.php?view=9066

L'article montre l'installation, les doigts dans le nez, de FC5, FC4, Ubuntu 6.10, Mandrake 9.2, Windows XP, Windows Server 2003, Windows Vista sur F7 test 2 (test : c'est une béta, il y a des bugs, ça peut bouffer les jambes des bébés ou un chat, et c'est normal, vous êtes prévenus) en utilisant KVM/QEMU. KVM est dispo sur Linux en upstream depuis 2.6.20.

Windows Vista et Ubuntu 6.10 n'ont pu être installé. Pour Ubuntu c'est probablement un bug de F7 test 2 ou Ubuntu. On a l'assurance que ça va être corrigé ou qu'au moins ce n'est pas intentionnel. Pour Vista, on tombe sur un "blue screen of death". On peut se demander si MS ne le fait pas exprès. Pure supposition de ma part, d'accord, mais je n'ai pas oublié que MS a refusé que Xen continue de bosser sur une version modifiée de Windows qui permet d'utiliser la paravirtualisation (typiquement pour faire tourner Windows sur Linux). De plus MS l'interdit (dans le cas de la paravirtualisation).

NB : je n'ai pas utilisé KVM, mon cpu ne le permet pas et je suis limite niveau RAM (seulement 512 Mo, mais satisfaisant pour un OS). Je n'aime pas changer de matos quand qu'il marche bien, mais je commence à crever d'envi de m'acheter un CPU avec VT :-)

En parcourant l'article on voit que libvirt offre une facilité déconcertante.

Libvirt a été à l'origine développé par Red Hat (introduit dans FC5). Il est disponible et ouvert à toute contribution :
http://www.libvirt.org/ Licence : GPL

Dès l'origine libvirt a été développé pour supporter plusieurs solutions de virtualisation. Ce domaine étant récent, il bouge beaucoup.

XEN

Désamour entre Red Hat et Xen ? Peut-être. Fedora 7 n'aura peut-être pas Xen. Le dernier noyau de développement n'a pas Xen. En tout cas, F7 sera la dernière Fedora avec Xen.
Plus qu'à demi-mot, les développeurs noyaux de Red Hat (et pas seulement eux) ont dit que c'était une peine terrible de maintenir Xen dans Linux. Mais ne crachons pas dans la soupe surtout que beaucoup de machines n'ont pas la technologie VT.

Compatibilité

La compatibilité est une contrainte en développement logiciel. Comment faire évoluer quelque chose quand en même temps les exigences de compatibilité demandent de ne rien changer ? On sait ce qu'en pense Linus Torvalds et bon nombre de développeurs noyau.

Windows a une longue pratique d'offrir la compatibilité ascendante (source et binaire) même si pour Vista ça sucks un peu. Ça a fait en partit son succès. C'est une exigence légitime des entreprises pour qui un sou est un sou.
GNU/Linux (l'OS, pas seulement le noyau) n'est pas en reste, mais se contraint moins sur ce point et est plus exigent envers les développeurs d'applications qui doivent de temps à autre porter leur application vers la dernière version.

Globalement le libre (sa communauté de développeurs) n'est pas très pointilleux sur la compatibilité. Je comprend ça parfaitement.

Mais les entreprises le sont. Ainsi il y a des distributions pour entreprise. La tâche d'offrir la compatibilité est si "ingrate" que ce sont des développeurs payés qui le font. Ces distributions offrent une stabilité de l'API (binaire et source) sur plusieurs années (7 ans pour Red Hat, 9 ans (?) pour Novell). Mais ça ne conserne qu'une version de la distribution. Un programme qui tourne sur RHEL version n peut ne pas marcher sur RHEL version n+1 (ni Red Hat ni Novell le garantit).

Sans transition, Red Hat a sorti en beta RHEL 4.5 ("service pack" 5 de RHEL 4 en terminologie Windows). Ces mises à jours ne sont pas des corrections de bug ou de sécurité, qui sont faites en permanence, mais ajoutent des fonctionnalités. La mise à jour 5 ajoute entre autre la possibilité de faire tourner RHEL 4 en invité (guest) sur la prochaine RHEL 5 via la paravirtualisation de Xen.
RHEL 4 utilise un 2.6.9 et uniquement un 2.6.9 (afin de conserver la compatibilité source ou binaire). J'imagine que la tâche n'a pas dû être aisée pour backporter Xen 3 sur un 2.6.9 (RHEL 5 utilise Xen 3).

Mais je m'égare :-)
La virtualisation va répondre à l'"impossibilité" de concilier le développement en upstream par la communauté (peu soucieuse de compatibilité) et l'exigence légitime des entreprises d'avoir une API stable. Du moins il faut que les changements d'API soit peu coûteux aux entreprises. Mais en même temps les entreprises veulent les dernières évolutions (plus de possibilité, plus d'opportunité, etc).

Avec RHEL 4.5 et 5, on voit déjà ce qui se dessine. je n'ai pas besoin de vous faire un dessin :-)
Avec la technologie VT, ça se fait tout seul (ou presque). Mais vu l'effort déployé Red Hat pour fournir RHEL 4.5 (afin que ce soit utilisable sur les CPU sans VT ; peut-être la majorité des bécanes qui utilisent RHEL 4) on sent qu'il y a une grosse demande ici.

J'enfonce des portes ouvertes, depuis longtemps on sait que la virtualisation va "bouleverser" l'informatique.
Je me réjouis que la virtualisation se marie bien avec le libre. Alors que le libre est de plus en plus développé par des entreprises (soucieuses de leurs clients, de compatibilité, etc), avec la virtualisation le style de développement du libre n'y perdra peut-être pas son "âme".

Retard de RHEL 5

Un paragraphe avant que les questions arrivent.
Il est facile d'avoir des infos sur Fedora (calendier, plan, etc), il est moins aisé d'en obtenir avec RHEL.
En général Red Hat ne donne pas de date de sorti ou reste très évasif. Peut-être sous la pression de SLES 10 qui fournit Xen (version 2 ?), Red Hat a annoncé la sortie de RHEL 5 pour fin 2006. Bizarrement c'est en décembre 2006 que Red Hat a annoncé que la sortie était repoussée pour le 28 février 2007 (finalement RHEL 5 doit sortir en mars).
J'ai du mal à croire que le retard de dernière minute soit lié uniquement à des bugs à corriger, sinon Red Hat aura fait l'annonce plus tôt. On l'a déjà vu pour Fedora, lorsqu'un retard est pris, il est annoncé très tôt. FC6 a été retardé de deux semaines (pour ne pas dire une semaine, car la sortie doit se faire un jour précis de la semaine pour respecter les exigences des administrateurs de mirroirs) à la fin de son développement à cause de bugs (1 voire 2 semaines, ce n'est pas 2 mois). Technologiquement une RHEL 5 est principalement une FC6 et ne part pas à l'aventure.

J'imagine que Red Hat a changé son plan pour RHEL 5 au dernier moment (ou que Red Hat avait fait une erreur dans son plan initiale). La paravirtualisation pour RHEL 4 n'avait peut-être pas été prévue (d'où cette annonce de beta tardive) et je pense que Red Hat ne voulais pas sortir RHEL 5 sans RHEL 4.5 dans son nouveau plan.
Il se dit aussi, "dans les milieux qui s'autorisent à penser", que Red Hat veut proposer une nouvelle solution de sauvegarde pour RHEL 5.

Quand Fedora ne sort pas une fonctionnalité importante, ce n'est pas grave. C'est repoussé de 6 ou 8 mois. Pour RHEL c'est grave, c'est repoussé d'au moins 18 mois, ce sont des clients de perdu durant 18 mois au moins.

Red Hat n'a pas une grande urgence à sortir RHEL 5. Red Hat vend du support. Tous ceux qui sont inscrit sur rhn auront accès à RHEL 5 (pas d'entrée de pognon pour Red Hat). RHEL 5 c'est principalement pour obtenir des nouveaux clients séduits par les nouvelles fonctionnalités.

M'enfin, je pense que Red Hat a sous estimé la tâche de livrer Xen.

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

C'est un article lwn sorti il y a une semaine (pour se financer lwn réserve certains articles aux abonnés payant durant une ou deux semaines) et maintenant disponible à tout le monde.

On peut toujours dire que ce n'est pas une image parfaite, mais c'est intéressant.
L'étude a été faite entre un 2.6.19 et un 2.6.20, et un 2.6.16 et un 2.6.20 (une année de développement).

Le "champion" est "Unknown" (29,5% sur un an). "Unknown" n'est pas toujours inconnu. Le rédacteur a regroupé dans cette catégories les "petites" contributions (afin de ne pas voir un tableau de 500 lignes). Ce qui montre que Linux n'est pas la propriété d'une boite.
En deux on a, comme on pouvait s'y attendre, Red Hat : 14,4 %
En trois : IBM : 8.0 %
En quatre : QLogic !?! : 3,7 %
En cinq : Novell : 3,6 %
En six : Intel : 3,1 %

Dans les distributions qui contribuent, il n'y en a que deux qui sont "visibles" !

L'article : http://lwn.net/Articles/222773/

C'est un gros boulot qu'a fournit l'éditeur de lwn pour nous fournir cet article très instructif.

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

ext3cow : http://www.ext3cow.com/

Exemple (pris de la doc) :
Fig. 1. Creating snapshots and accessing data in the past in ext3cow.
[user@machine] echo "This is the original foo.txt" > foo.txt
[user@machine] snapshot
Snapshot on . 1057845484
[user@machine] echo "This is the new foo.txt." > foo.txt
[user@machine] cat foo@1057845484
This is the original foo.txt.
[user@machine] cat foo
This is the new foo.txt.
Fig. 2. Creating distinguished (named) snapshots in ext3cow.
[user@machine] snapshot /usr/bin
Snapshot on /usr/bin 1057866367
[user@machine] ln -s /usr/bin@1057866367 /usr/bin.preinstall
[user@machine] /usr/bin.preinstall/gcc

Sympa non ?
Le tout sans dégradation significative de performance. Ext3COW pour Ext3 Copy On Write. Donc ça ne bouffe pas trop de place disque.

Je n'ai pas souvenir que ext3cow ait été discuté sur linuxfr. Je voulais lui faire un peu de publicité.
Je ne l'ai pas utilisé.

Description détaillée :
http://hssl.cs.jhu.edu/papers/peterson-tos05.pdf

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

Il parait que la tradition veut que le vendredi soit le jour du kiki^W n'importe quoi et plus particulièrement du troll.

A tout seigneur tout honneur : Debian.
Etch était prévu pour décembre 2006, on est fin février 2007.

A vos pronostic...

Pour vous aider, un petit article : http://www.linux-watch.com/news/NS2327436222.html

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

L'excellentissime PostgreSQL est disponible en version 8.2.0.
L'annonce détaillée en français :
http://www.postgresql.org/about/press/presskit82.html.fr

Voilà, voilà, voilà...

Pour rappel, PostgreSQL est dispo chez free.fr.

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