- La version RC-1 est apparue juste quinze jours après la sortie du noyau stable précédent. Linus a reconnu que le noyau 2.6.21 avait connu une gestation difficile et il espère que cette RC-1 annonce un progrès sur ce plan (traduction libre): «Je pense (et j'espère) que cela ne va pas être aussi douloureux que les gros changements du code des timers du noyau 2.6.21. Bien qu'il y ait ici aussi des changements importants (...) cela semble assez solide.»
- La version RC-2 a continué sur cette voie d'une version solide et bien debuggée et Linus a rappelé la règle qui interdit d'ajouter des nouvelles fonctions à ce stade du développement (traduction libre): «N'essayez même pas d'envoyer autre chose que des corrections de bugs ! Je pense que la situation actuelle semble raisonnablement bonne pour le noyau 2.6.22.»
- La sortie de la version RC-3 le 25 mai a donné l'occasion à Linus d'écrire un de ses petits bijoux humoristiques dont il a le secret. Il a lancé un appel pour que les gens téléchargent et testent cette RC-3 au lieu d'aller à la plage (traduction libre): «Nous sommes vendredi soir et les USA se préparent à un long week-end de trois jours, souvent considéré ici comme le début officiel de l'été. Donc que peut faire un nerd blanc comme un bidet ? Vous ne pouvez pas aller à la plage parce que les gens normaux vont rigoler en vous voyant et vont vous jeter du sable à la figure. Mais vous _pouvez_ faire quelque chose : vous pouvez télécharger le dernier noyau RC-3 et sourire d'un air suffisant en sachant que vous faites tourner la toute dernière merveille sur votre machine. Et tout d'un coup, cela n'a plus d'importance que ce soit l'été parce que vous pouvez rester dans votre sous-sol aux stores fermés à vous faire bronzer à la chaude lumière de votre écran LCD plutôt qu'à la dure lumière du jour. Donc ne vous inquiétez plus de ces dangereux rayons ultra-violets et prenez votre vitamine D sous la forme prévue par Dieu (et l'industrie pharmaceutique) : des petites pilules facilement avalables. Les plages sont très surfaites de toute manière, le sable s'introduit dans le ventilateur des ordinateurs portables et en un clin d'oeil plus rien ne fonctionne.
Puissiez vous avoir un bel été.»
- La version RC-4 s'est contentée de corriger divers bugs et régressions et, dix jours plus tard, Linus s'est félicité d'avoir trouvé le temps de sortir la RC-5 en dépit de la monstrueuse flame-war GPLv2/GPLv3 ayant eu lieu sur la liste de diffusion.
- Le 24 juin est apparue la -RC6 et le premier juillet la -RC7 qui semble satisfaire Linus (traduction libre): «Nous devrions être dans une très bonne situation. Le flot des patchs a vraiment ralenti et la liste de régression s'est beaucoup réduite.»
- Enfin la version finale a été annoncée le dimanche 8 juillet et Linus s'est interrogé dans son courriel pour savoir si il était vraiment nécessaire de publier une liste complète des changements (un gros fichier de plus d'une centaine de milliers de lignes) alors que presque tout le monde utilise directement le gestionnaire de code source Git pour consulter cette liste. C'est donc sans doute la dernière fois que ce fichier récapitulatif des changements (changelog) sera publié séparément.
- Le noyau 2.6.22 inclut une toute nouvelle couche wifi plus propre et plus performante. Elle a été initialement écrite par la société Devicescape (sous le nom d'Advanced Datapath Driver) avant d'être libérée en mai 2006 et adaptée par les hackers Linux au cours de ces derniers mois. Parmi les progrès, on note une implémentation complètement intégrée du WEP, du WPA, du couplage (bridging) des canaux, de la qualité de service (avec priorisation de la voix sur IP), du support 802.11g, du code de debugging...etc
Auparavant l'ancienne couche wifi était assez "sale" et de nombreux pilotes de cartes avaient réécrit certaines fonctions dans leur coin au lieu d'utiliser la couche générique du noyau. La nouvelle couche Devicescape étant bien plus complète et propre, cela va permettre d'adapter tous ces pilotes pour éviter au maximum la duplication du code et simplifier l'écriture des nouveaux pilotes.
- On trouve également une couche Firewire complètement réécrite afin d'avoir un code plus petit, plus simple et plus maintenable, tout en conservant la compatibilité au maximum avec l'existant. L'API a été adaptée et le code passe de plus de 30000 ligne pour l'ancienne couche à moins de 8000 lignes dans cette nouvelle couche Firewire. Les quatre interfaces existantes pour les programmes en espace utilisateur (userspace ABI) ont fusionné afin de laisser place à une seule interface améliorée (la compatibilité est tout de même maintenue grâce aux bibliothèques libraw1394 et libdc1394).
- Le mécanisme eventfd de notification des évènements est inclus dans cette version 2.6.22. Cet ajout est la conclusion d'une longue controverse et un exemple quasi-parfait du mode de développement hautement compétitif qui caractérise le noyau Linux. En ce sens cet épisode mérite que l'on s'y arrête quelque peu.
En décembre 2006, la situation semblait claire puisque le mécanisme générique proposé par Evgeniy Polyakov, Kevent, semblait la solution qui allait s'imposer. Il en était à sa vingt-sixième version car les développeurs voulaient prendre tout leur temps avant d'introduire une nouvelle API qu'il faudra maintenir indéfiniment. En dépit de cette prudence, on pouvait penser que l'inclusion dans la branche principale n'était qu'une question de maturation, d'autant que kevent avait reçu le soutien résolu d'Ulrich Drepper, le mainteneur de GlibC. Pourtant, Davide Libenzi ne l'entendait pas de cette oreille et il a proposé une autre solution, eventfd, basée uniquement sur des descripteurs de fichiers (file descriptors) et qui évite d'introduire une nouvelle API. Cette stratégie nécessite la création des appels systèmes signalfd et timerfd et, si elle sacrifie la "généricité" de kevent, elle est plus simple et plus UNIX dans l'âme (car basée sur la philosophie du "tout est fichier"). Avec eventfd, on peut donc continuer à utiliser read(), select() et poll() comme on le faisait auparavant.
Après des échanges enflammés sur la liste de diffusion du noyau et une argumentation très tranchée d'Ulrich Drepper en faveur de kevent, l'opinion majoritaire penchait néanmoins pour eventfd quand un nouveau concurrent, pollfs, est apparu au dernier moment. Son auteur, Davi Arnaut voulait mettre tout le monde d'accord mais son code a été durement critiqué et il n'a pas changé fondamentalement la donne. Après un dernier baroud d'honneur d'Ulrich Drepper le mécanisme de notification eventfd a finalement été introduit dans le noyau 2.6.22. La communauté Linux a donc fait le choix d'un outil simple à l'inverse, par exemple, de FreeBSD qui a privilégié, avec kqueue, le caractère très générique du fonctionnement au prix d'une plus grande complexité.
- Continuant son combat pour un support aussi universel que possible, le noyau Linux accueille une nouvelle architecture de processeur. Blackfin est un microprocesseur à architecture RISC développé par Intel et Analog Devices, Inc (ADI) pour le marché de l'embarqué. C'est un processeur hybride (mi-CPU, mi-DSP) qui fait le pari du support complet sous Linux afin d'élargir son marché. Un site web a été mis sur pieds afin de centraliser toutes les ressources relatives à Linux et au logiciel libre.
- Une partie importante du noyau Linux est son allocateur de mémoire (qui s'occupe de garder en cache de nombreux objets de différentes taille afin de permettre d'allouer la mémoire de façon efficace et rapide). Cet allocateur se nomme SLAB (il existe également une autre version, nommée SLOB, pour l'embarqué) et son code est complexe au point de décourager les contributions. La version 2.6.22 introduit un tout nouvel allocateur de mémoire (portant le nom poétique de SLUB) dont le code est beaucoup plus simple tout en étant plus performant (de 5 à 10%).
Ce projet a été lancé par la société SGI afin d'améliorer le rendement de ses superordinateurs comportant plus de mille processeurs. En effet elle s'est aperçue que SLAB engloutissait sans raison plusieurs gigaoctets de mémoire dans cette configuration extrême et a donc décidé de remédier une bonne fois pour toute à ces défauts en créant un nouvel allocateur plus efficace.
Par défaut, SLUB n'est pas activé (c'est une option lors de la compilation) mais sa présence dans la branche principale du noyau va permettre d'avoir de nombreux retours d'expérience et il a vocation à remplacer complètement SLAB à brève échéance.
- UBI (Unsorted Block Images) est un tout nouvel outil présent dans cette version de Linux et qui permet de gérer les périphériques à base de mémoire NAND flash. C'est en quelque sorte un équivalent de LVM mais spécialisé dans la mémoire flash (LVM maps logical sector numbers to physical HDD sector numbers, UBI maps logical eraseblocks to physical eraseblocks).
Il permet la répartition des écritures sur toute la mémoire et il tient compte des blocs mémoire défectueux. Il gère également la création de volumes UBI qui peuvent être dynamiquement créés, re-dimensionnés ou supprimés. Un fichier PDF complet sur la conception d'UBI est disponible ici.
- L'ordonnanceur CFQ (Complete Fair Queuing) qui s'occupe de gérer les entrées/sorties a été largement amélioré dans la nouvelle version du noyau Linux. Il peut maintenant détecter des processus qui coopérent entre eux ce qui lui permet de choisir la meilleure queue en attente. De plus Jens Axboe, son mainteneur principal, a choisi de s'inspirer de CFS, le tout nouvel ordonnanceur des processus actuellement développé par Ingo Molnar. L'idée principale est d'abandonner les listes triées par niveau de priorité (linked list per priority level for sorting and service uses) afin d'opter pour des arbres de recherches (rbtree of cfq_queue's, sorted by when to service them). Le concept est donc plus naturel et le fonctionnement de l'ordonnanceur est plus rapide.
Enfin le code de CFQ code a été simplifié en le purgeant d'une bonne partie des fonctions n'étant plus utiles.
- L'interface utimensat a été ajoutée afin de permettre une précision du niveau de la nanoseconde dans les timestamps des systèmes de fichiers. Jusqu'ici l'interface utimes ne proposait qu'une précision limitée à la microseconde.
- Le support des sous-types de systèmes de fichiers a été introduit dans le nouveau noyau Linux. Il permet de distinguer facilement les divers système de fichiers en espace utilisateur (basés sur FUSE). Ainsi, alors qu'auparavant le noyau ne faisait pas la différence et qu'il était difficile de spécifier le système de fichier utilisé dans son fstab, on peut maintenant mettre une mention bien plus explicite (par exemple "fuse.sshfs").
- Dans la perspective d'une refonte future du code pour obtenir plus de stabilité et de rapidité, les fonctions d'hibernation (suspend to disk) et de veille (suspend to RAM) ont été séparés. Cela va permettre d'analyser plus finement les spécificités de chacune des fonctions et de les optimiser séparément.
- Dans le domaine des réseaux TCP de nouveaux algorithmes de gestion des problèmes de congestion ont étés introduits. On note l'implémentation de YeAH-TCP et celle de TCP-Illinois.
Ces deux algorithmes sont spécialisés dans les réseaux à très grande vitesse (In some scenarios, TCP can only utilize less than 10% of network capacity. So a more efficient modification to TCP, which is called high sped TCP variant by researchers in this area, is needed in high speed networks).
- Comme d'habitude un grand nombre de pilotes ont été ajoutés ou améliorés dans ce nouveau noyau Linux (par exemple le pilote IVTV qui permet le support des cartes TunerTV + compression MPEG de marque Connexant) et une multitude d'autres modifications ont trouvé leur chemin. Comme il en a pris l'habitude le site Linux Weekly News propose un article faisant le bilan complet sur les contributeurs de cette version. On peut y lire que la différence entre le noyau 2.6.22 et son prédécesseur immédiat est de 6000 patchs (écrits par 885 développeurs différents) ce qui représente 494000 lignes de code ajoutées et 241000 supprimées.
Si on se tourne vers le futur pour deviner ce que contiendront les versions à venir du noyau on peut regarder du coté d'utrace. C'est un remplaçant du système ptrace qui garde la même interface pour les programmes en espace utilisateur mais qui propose des fonctions bien plus riches). Ces divers outils de tracing fournissent au processus parent un moyen de contrôler l'exécution d'un autre processus afin de faciliter le débogage (cet article détaillé fait le point sur les outils de tracing pour Linux).
Le travail sur le système de fichier de nouvelle génération Ext4 se poursuit et la liste des nouvelles fonctionnalités est alléchante (voir aussi ce fichier pdf issu du symposium Linux d'Ottawa).
Le patch permettant d'implémenter la fonction de lecture spéculative à la demande (On-demand readahead) continue sa maturation. Cette fonction de lecture spéculative, qui existe depuis longtemps, autorise le chargement à l'avance du contenu d'un fichier que le noyau est en train de lire afin de pouvoir fournir les données plus rapidement aux applications. La nouveauté de ce patch réside bien entendu dans le "à la demande" qui permet d'avoir un code plus simple et plus flexible (ici aussi un papier du symposium Linux est disponible).
Le système de fichier spécialisé dans la mémoire Flash (LogFS) est également développé très activement dans la perspective de l'explosion imminente des disques durs de type SSD. LogFS est basé sur l'idée que les systèmes de fichiers classiques sont conçus principalement pour des disques magnétiques alors que les disques flash ne nécessitent pas tout le code extrêmement complexe qui tente d'éviter la fragmentation des fichiers. L'approche suivie est donc basée sur une écriture séquentielle des données (log-structured approach) qui, et c'est ce qui constitue la grande différence avec JFFS2, ne nécessite pas de scan complet du volume au montage. Comme un système classique toute la structure est donc gardée en mémoire directement dans le disque ce qui accélère considérablement le mount (sur un système OLPC on passe de 3,3 secondes sous JFFS2 à 60 millisecondes avec LogFS).
Enfin le nouvel ordonnanceur CFS d'Ingo Molnar (évoqué lors de la dépêche sur le noyau 2.6.21) en est à sa dix-neuvième version et le temps de l'inclusion dans la branche principale approche à grands pas !
Aller plus loin
- Les nouveautés de Linux 2.6.22 (65 clics)
- Le bilan des ajouts 1 (44 clics)
- Le bilan des ajouts 2 (48 clics)
- Les articles du symposium Linux 2007 (48 clics)
# Bravo !
Posté par liberforce (site web personnel) . Évalué à 10.
[^] # Re: Bravo !
Posté par Guillaume CASTAGNINO (site web personnel) . Évalué à 10.
Complet, avec tous les pointeurs sur les divers éléments cités...
Une dépêche de très grande qualité
Merci !
[^] # Re: Bravo !
Posté par reno . Évalué à 10.
J'ai eu l'impression de lire LWN!
[^] # Re: Bravo !
Posté par Ludovic F (site web personnel) . Évalué à 6.
Merci à l'auteur !
[^] # Re: Bravo !
Posté par H_francis . Évalué à -1.
#include <stdio.h>
void affiche_bravo(void);
int main(void)
{
affiche_bravo();
return 0;
}
void affiche_bravo(void)
{
puts("Bravo! Tres belle news! Felicitation!");
affiche_bravo();
}
Mpf.
[^] # Re: Bravo !
Posté par IsNotGood . Évalué à 1.
[^] # Re: Bravo !
Posté par H_francis . Évalué à 0.
[^] # Re: Bravo !
Posté par NickNolte . Évalué à 5.
Complet, clair et accessible, bravo.
Bon, Patrick_g, tu dois comprendre que c'est foutu pour toi... tu as la responsabilite, a present de presenter chaque nouvelle mouture du noyau nunux avec cette meme qualite. :)
Merci
[^] # Re: Bravo !
Posté par patrick_g (site web personnel) . Évalué à 10.
Bah j'ai regardé l'historique du site et je vois que j'ai écopé d'une condamnation longue sans remise de peine ;-)
C'est vrai qu'au fil du temps ces news kernel ont tendance à s'allonger démesurément :
2.6.13 => http://linuxfr.org/2005/08/29/19485.html (article de 1644 caractères).
2.6.18 => http://linuxfr.org/2006/09/20/21352.html (article de 2493 caractères).
2.6.19 => http://linuxfr.org/2006/11/30/21677.html (article de 6580 caractères).
2.6.20 => http://linuxfr.org/2007/02/05/21986.html (article de 6764 caractères).
2.6.21 => http://linuxfr.org/2007/04/26/22398.html (article de 9446 caractères).
2.6.22 => http://linuxfr.org/2007/07/09/22676.html (article de 14910 caractères).
Je pense qu'entre 10000 et 15000 caractères (en tout) c'est la bonne longueur pour évoquer la saga des -RC et détailler un peu les nouveautés. Je vais essayer de m'y tenir à l'avenir.
# Merci !
Posté par Neilink . Évalué à 10.
[^] # Re: Merci !
Posté par patrick_g (site web personnel) . Évalué à 10.
[^] # Re: Merci !
Posté par BAud (site web personnel) . Évalué à 7.
bwalé départ pour les RMLL, j'espère voir Alan Cox.
# Merci
Posté par polytan . Évalué à 9.
# erreur lien
Posté par Kibos . Évalué à 1.
# Fast forward
Posté par patrick_g (site web personnel) . Évalué à 10.
A propos d'analyse du développement de Linux il y a un article extrêmement intéressant parmi ceux du dernier symposium => https://ols2006.108.redhat.com/2007/Reprints/kroah-hartman-R(...)
Le kernel hacker Greg Kroah-Hartman s'est servi du logiciel développé par Linux Weekly News (gitdm) pour analyser statistiquement les évolutions du noyau sur une période de près de deux ans et demi (du kernel 2.6.11 au kernel 2.6.21).
Je vous invite à lire cet article car il est bourré d'informations passionnantes.
Juste à titre d'exemple :
Entre la release du noyau 2.6.11 et celle du 2.6.21 il s'est écoulé 852 jours. Sur cette période le diff en nombre de patchs est de 59164. Une simple division donne donc le chiffre ahurissant de 2.89 patchs par heure pendant deux ans et demi (24 heures sur 24 et sept jours sur sept) !
En nombre de ligne de code c'est plus de 85 lignes de code noyau par heure pendant deux ans et demi...simplement hallucinant.
Mode optimiste on/
Et après on se demande pourquoi Microsoft ne peux pas suivre le rythme !
Mode optimiste off/
[^] # Re: Fast forward
Posté par windu.2b . Évalué à 2.
Avec ceux de la news ("On peut y lire que la différence entre le noyau 2.6.22 et son prédécesseur immédiat est de 6000 patchs (écrits par 885 développeurs différents) ce qui représente 494000 lignes de code ajoutées et 241000 supprimées."), ça donne une idée de l'ampleur du travail effectué par tous ces travailleurs de l'ombre!
Un grand bravo à tous ceux-là, parce que franchement je suis sur le c*l quand je vois le boulot abattu.
Et un grand merci pour la news bien sûr: elle est claire, précise, bien documentée...
[^] # Re: Fast forward
Posté par mickabouille . Évalué à 4.
On l'appelle Jonathan Corbet ;) ou "grumpy editor" parfois
Il y a plusieurs personnes à LWN
[^] # Re: Fast forward
Posté par Matthieu Lemerre . Évalué à 6.
Oui enfin il faut se dire que si les "bonnes" lignes avaient ete ecrites directement au lieu d'etre reecrites incrementalement on serait arrive au meme resultat avec bien moins de patchs...
La qualite d'un logiciel ne se mesure pas a son nombre de ligne de code (j'aurais tendance a penser le contraire: un bon logiciel en fait beaucoup en peu de lignes).
Note: non, je ne suis pas pro-microsoft (qui a d'ailleurs le meme genre de strategie je pense)
[^] # Re: Fast forward
Posté par oops (site web personnel) . Évalué à 1.
Ben oui quoi, pourquoi ils ne font pas un noyau parfait dès le départ !!!
Ils sont vraiment mauvais ces développeurs Linux.
http://widefox.pbwiki.com/Source pour voir un comparatif : près de 2 fois moins de lignes de code pour Linux ( qui supporte pourtant bien plus d'architectures )
[^] # Re: Fast forward
Posté par Mathieu Schroeter (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: Fast forward
Posté par oops (site web personnel) . Évalué à 1.
Par rapport à la taille des binaires ?
Par rapport à ce qui ont pu voir ceux qui ont accès aux sources ?
Par rapport à ceux que disent dit Ballmer ?
Je ne sais pas mais une recherche sur google donne entre 2,5 et 5 fois plus.
Ce qui me parait normal vu qu'ils ont une gestion de la compatibilité ascendante.
[^] # Re: Fast forward
Posté par pasBill pasGates . Évalué à 5.
a) le Kernel de Vista sans drivers fait beaucoup, beaucoup, _beaucoup_ moins que 10 millions de lignes. L'OS entier en fait genre 50-60, croire que le kernel fait 20% de cela c'est un gros gag. Je viens de calculer le chiffre en faisant un compte des lignes de tous les fichiers dans le repertoire et c'est a des annees lumieres de 10 millions.
b) On ne sait pas comment ils calculent ces chiffres (au hasard, la stack reseau n'est pas architecturalement parlant dans le kernel mais un driver dans Windows, il compte ca ? )
c) Le gars qui a pondu cette page ne sait clairement pas de quoi il parle et s'amuse a scotcher des chiffres pris n'importe comment, genre sa mesure de nombre de bugs, il utilise un chiffre de 63'000 du temps de Win2k qui etait une rumeur et qui ne correspond absolument au nombre de defauts, mais au nombre de chose a changer (feature request, probleme dans la doc, ...).
Tu peux oublier ces chiffres, ils ne valent rien du tout et sont totalement faux.
[^] # Re: Fast forward
Posté par Gilles G. . Évalué à 1.
Merci pour l'info en tout cas.
Si j'ai bien compris, le noyau Vista est de l'ordre de taille du noyau Linux donc...(en lignes de code) ?
[^] # Re: Fast forward
Posté par Mathieu Schroeter (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: Fast forward
Posté par ndv . Évalué à 2.
Wikipedia semble le confirmer :
http://fr.wikipedia.org/wiki/Noyau_windows_NT
Précisions sur les noyaux hibrides :
http://fr.wikipedia.org/wiki/Noyau_%28informatique%29#Noyaux(...)
[^] # Re: Fast forward
Posté par Xavier Teyssier (site web personnel) . Évalué à 2.
[^] # Re: Fast forward
Posté par pasBill pasGates . Évalué à 4.
[^] # Re: Fast forward
Posté par pasBill pasGates . Évalué à 1.
Quand a la taille exacte, pas sur que j'ai le droit de donner le chiffre, mais de toute facon a mon avis le chiffre de cette page sur le noyau Linux est probablement faux aussi, sans parler du fait que MS et le noyau ont des demandes differentes niveau commentaires dans le code, donc c'est pas vraiment comparable de toute facon.
[^] # Re: Fast forward
Posté par windu.2b . Évalué à 5.
Si même toi, tu en viens à reconnaitre que MS ne commente pas son code, et que c'est pour ça qu'ils mettent autant de temps pour publier un patch, alors c'est que tout fout l'camp ma bonne dame! :-p
[^] # Re: Fast forward
Posté par herodiade . Évalué à 3.
En bonus, il décompose le décompte en sous-totaux par langages (ANSI C, C++, asm, ...). voir http://www.dwheeler.com/sloccount/ (ok, pour l'utiliser sous Windows, il faut Cygwin, mais il existe des outils équivalents et natifs, voir par ex. sur http://www.qsm.com/CodeCounters.html ou http://www.programurl.com/code-counter-pro.htm ).
[^] # Re: Fast forward
Posté par vladislav askiparek . Évalué à 1.
La qualité par exemple...
[^] # Re: Fast forward
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Fast forward
Posté par Matthieu Lemerre . Évalué à 1.
Je dis pas, mais de la a faire 19 versions d'un scheduler en 3 mois...
Mais c'est bien le pb de POSIX (et des interfaces POSIX-like en general): comme c'est sense faire fonctionner pleins de taches differentes, qui ont plein de workloads completements differents, avec la meme interface, on se retrouve a faire un scheduler qui doit inferer le comportement de tout un tas d'application avant d'agir en consequence.
Alors je comprends bien: avec tous les workloads "classiques" qui doivent exister, il doit en falloir du temps pour tous les faire marcher... Jusqu'a ce qu'on trouve un nouvel exemple qui marche pas. Et hop, une version de plus!
En tout cas je lui souhaite bien du courage.
# La même rengaine...
Posté par Janfi . Évalué à 4.
Concernant l'intégration de la couche wifi devicescape, est-ce que cela signifie que pour les réseaux en WPA par exemple il ne sera plus nécessaire d'utiliser wpa_supplicant, fichiers de conf à la main et consorts ? On pourra enfin se connecter en entrant "simplement" la passphrase ?
Merci...
[^] # Re: La même rengaine...
Posté par ribwund . Évalué à 4.
Et pour se connecter "simplement", il suffit d'utiliser NetworkManager :)
[^] # Re: La même rengaine...
Posté par Larry Cow . Évalué à 7.
Si les drivers dupliquent moins de code, on peut s'attendre à une plus grande homogénéité entre eux, et donc un meilleur support par les outils graphiques. Finie, la déception de constater que sa distribution comporte un merveilleux outil de configuration du wifi, mais que sa carte réseau n'est pas supportée et doit être configurée à la main.
[^] # Re: La même rengaine...
Posté par Taku . Évalué à 6.
Combien de "ca marche pas sous linux mon wifi" sur les forums de diverses distributions ?
[^] # Re: La même rengaine...
Posté par Sébastien TeRMiToR . Évalué à 2.
Bien a vous
[^] # Re: La même rengaine...
Posté par djibb (site web personnel) . Évalué à 2.
c'est le WPA2 que j'attends. il est peut etre inclus dedans ?
# Fin de la branche CK
Posté par paul . Évalué à 10.
Comme tu l'as relevé, la concurrence est rude pour l'inclusion dans la sacro-sainte branche vanilla. Et cette concurrence, dont chacun appréciera à sa façon la loyauté, aura provoqué indirectement le départ de Con Kolivas, auteur de la branche CK. Depuis des années, les patchs les plus innovant en matière d'ordonnancement, d'allocation, et de performance en général trouvent leurs chemin en premier lieu dans la branche de Con Kolivas. Ce dernier, après avoir mis au point un ordonnanceur particulièrement intéressant, a souhaité une inclusion dans la branche Vanilla. La sagesse prévalant, la discussion sur les atouts indéniables des concepts du Staircase Deadline a été longue [1]. Ingo Molnar, le développeur préposé depuis longtemps à l'ordonnancement dans la branche de linus, a développé son propre ordonnanceur, le CFS, principalement basé sur SD, et a reçu les faveurs de linus. Ensuite, CK s'est entendu dire que ce serait une duplication d'effort de maintenir 2 ordonnanceurs équivalents, donc que SD n'avait pas vraiment sa place dans le vanilla vu que CFS va y rentrer [2].
Con Kolivas, ayant trouvé que c'était quand même un peu gros, et pensant que la concurrence logicielle ne justifie pas le manque de considération pour les individus, a décidé de tirer sa révérence définitivement. Son patchset pour ce noyau 2.6.22 sera donc le dernier [3]. Merci pour tous ses apports logiciels et pour toutes ses idées, mais surtout, merci à lui pour son engagement et son temps passé sur linux.
[1] http://linuxfr.org/comments/825903.html#825903
[2] http://news.gmane.org/gmane.linux.kernel.ck
[3] http://members.optusnet.com.au/ckolivas/kernel/
[^] # Re: Fin de la branche CK
Posté par oliv . Évalué à 10.
1- Il est jugé techniquement supérieur
2- Ingo Molnar est capable de travailler en équipe et d'accepter les contributions d'autres personnes à "son bébé". Il suffit de regarder les changelogs de CFS pour voir que de nombreuses améliorations ne sont pas de lui. Dans un projet aussi communautaire que linux, c'est fondamental (cf. la situation de la couche IDE des noyaux 2.0, 2.2).
3- Ingo Molnar lance un projet et le maintient ou bien lui trouve un autre mainteneur (le dernier noyau realtime a été annoncé par Thomas Gleixner qui à l'origine était un petit contributeur, et maintenant est le principal contributeur de ce patch). Quelques temps après avoir créé SD, Kolivas a du s'arrêter de développer pour des raisons de santé. C'est ce qui a poussé Ingo Molnar à lancer CFS. Il n' y avait personne qui pouvait/voulait continuer le travail de Con Kolivas. C'est important d'avoir l'assurance que tel ou tel projet sera maintenu.
4- La lecture de la liste de diffusion du noyau montre que Con a commis quelques erreurs: des accusations paranoïaques et de tricherie contre CFS (e.g. l'histoire du renice de X). De son coté, Ingo Molnar a toujours rendu à César ce qui lui appartient. Il a clairement déclaré que certains concepts venaient de Kolivas, et n'a jamais dans ses changelogs, prétendu que son poulain était le meilleur.
5- Quand des défauts, bugs ou problèmes plus conceptuels ont été abordés pour les deux projets, Ingo Molnar a comme d'habitude corrigé les bugs (dans les heures qui suivaient). Cela fait de nombreuses version de CFS où il n' y a pas de bugs (il y a une constante: des gens rapportent des bugs, et réalisent ensuite qu'il se sont trompés où que le bug est en fait présent sous le noyau de base ou du à autre chose (e.g. le cas d' un bug de XTerm la semaine dernière)). Les problèmes soulevées par Bill Davidsen contre SD n'ont jamais reçu de réponse, ce qui a poussé Linus a faire un rappel à l'ordre.
Bref, Con a fait du bon boulot techniquement, et le patch "swap-prefetch" a toutes les chances d'être intégré au noyau, mais il n' a pas su gérer l'aspect humain de la contribution: accepter les critiques, accepter des devoir adapter son code au noyau, et non pas l'inverse.
Mais c'est mon opinion sur cette triste histoire, je le reconnais.
[^] # Re: Fin de la branche CK
Posté par patrick_g (site web personnel) . Évalué à 4.
[^] # Re: Fin de la branche CK
Posté par Edouard Gomez (site web personnel) . Évalué à 9.
> 1- Il est jugé techniquement supérieur
Son design fait intervenir des structures plus complexes a manipuler que le Staircase Deadline (SD). Si bien qu'il ajoute des lignes de code a sched.c là ou SD en enleve et le rend plus simple a maintenir.
> 2- Ingo Molnar est capable de travailler en équipe et d'accepter les contributions d'autres personnes à "son bébé". Il suffit de regarder les changelogs de CFS pour voir que de nombreuses améliorations ne sont pas de lui. Dans un projet aussi communautaire que linux, c'est fondamental (cf. la situation de la couche IDE des noyaux 2.0, 2.2).
Ingo est un vieux routard du noyau, il a une aura dans la communauté LKML qui attire beaucoup plus qu'un pauvre gars, même pas informaticien qui tente de convaincre son monde depuis bientot 5 ans au travers de patchs toujours refusés upstream faute de consensus/perseverence.
> 3- Ingo Molnar lance un projet et le maintient ou bien lui trouve un autre mainteneur (le dernier noyau realtime a été annoncé par Thomas Gleixner qui à l'origine était un petit contributeur, et maintenant est le principal contributeur de ce patch). Quelques temps après avoir créé SD, Kolivas a du s'arrêter de développer pour des raisons de santé. C'est ce qui a poussé Ingo Molnar à lancer CFS. Il n' y avait personne qui pouvait/voulait continuer le travail de Con Kolivas. C'est important d'avoir l'assurance que tel ou tel projet sera maintenu.
Faux, CFS n'est pas du au retrait de Con Kolivas suite a sa maladie.
1- Con est tombé malade suite au stress et travail imposé par la LKML sur son scheduler. En gros il propose un patch et au lieu d'y contribuer tout le monde l'a fusillé en lui disant que l'idée est bonne, mais l'implémentation n'est pas ce qu'ils attendaient.
2 - Ingo a validé le concept mais a lui aussi refusé l'implementation de Con. Il disparait et reapparait avec son CFS.
> 4- La lecture de la liste de diffusion du noyau montre que Con a commis quelques erreurs: des accusations paranoïaques et de tricherie contre CFS (e.g. l'histoire du renice de X).
Le renice de X est une vérité vraie. Je 'tinvite a relire la LKML il y a quelques années ou Ingo et Linus defendaient le fait que renicer X c'etait pas la bonne approche dans la course a l'interactivité.
Il est donc compréhensible que Con trouve que le renice automatique de X dans les premieres version de CFS soit de la pure triche pour pallier au manque d'interactivité de CFS dans sa jeunesse.
> De son coté, Ingo Molnar a toujours rendu à César ce qui lui appartient. Il a clairement déclaré que certains concepts venaient de Kolivas, et n'a jamais dans ses changelogs, prétendu que son poulain était le meilleur.
Oui et non, il est comprehensible que Con qui bosse depuis plusieurs années sur l'amelioration du scheduler ait les boules.
Il s'est fait refuser le staircase scheduler, bien qu'il eut:
- été plus simple que le scheduler mainline
- intégré la notion d'interactivité de facon naturelle et deterministe.
Il s'est fait refuser RSDL (Rotating Staircase Deadline Scheduler) et SD:
- car l'approche etait un peu hors norme
- car personne ne l'a vraiment concretement aidé à l'ameliorer en respectant le design de base (y a eu des patchs envoyes pour integrer des heuristiques de bonus d'interactivité par celui qui tune ce meme parametre dans le noyau mainline depuis quelque temps). Mais le fameux 'envoies ton patch au lieu de critiquer gratuitement' a pas eu lieu. Les critiques etaient là, les patchs non.
On peu donc comprendre que l'arrivée de CFS soit mal percue. Ingo n'a pas patché SD, il s'est mis a coder dans son coin en repompant l'idee de base, fait un truc a sa sauce, et attiré les developpeurs interesses car il est plus affluant dans la communauté LKML.
> 5- Quand des défauts, bugs ou problèmes plus conceptuels ont été abordés pour les deux projets, Ingo Molnar a comme d'habitude corrigé les bugs (dans les heures qui suivaient). Cela fait de nombreuses version de CFS où il n' y a pas de bugs (il y a une constante: des gens rapportent des bugs, et réalisent ensuite qu'il se sont trompés où que le bug est en fait présent sous le noyau de base ou du à autre chose (e.g. le cas d' un bug de XTerm la semaine dernière)). Les problèmes soulevées par Bill Davidsen contre SD n'ont jamais reçu de réponse, ce qui a poussé Linus a faire un rappel à l'ordre.
48 versions de SD, c'est peut etre pas assez ?
En fait, tu disais que le post original de la thread etait biaisé en faveur de Con, et bien j'ose dire que le tien est clairement biaisé en faveur d'Ingo.
L'erreur c'est que tu as uniquement suivi la LKML pour te faire une idee, et SD a été développé sur la mailing list de Con Kolivas. Cela explique certainement ta partialité.
Mais ayant vu les choses sur les deux MLs, je dirais que Ingo a fait un petit coup de pute a Con:
- il ne l'aide pas
- il deprecie le design
- il vient avec un concurrent
- il attire a lui tous ceux qui seraient en mesure d'aider Con
- il renie certaines choses qu'il a rejeté des années durant pour son scheduler O(1) mainline (modularité, pas de bonus d'interactivité ...).
Donc oui, Con a eu les boules, c'est normal.
Ingo a mergé son CFS, tant mieux pour Linux qui profitera d'un scheduler techniquement supérieur au mainline 2.5.x->2.6.21.
PS: malgré mon plaidoyer pour Con, je trouve qu'Ingo fait du super boulot. C'est juste la facon de faire qui a été "border line" et que j'ai trouvé un peu irrespectueuse humainement.
[^] # Re: Fin de la branche CK
Posté par patrick_g (site web personnel) . Évalué à 3.
"I'd like to give credit to Con Kolivas for the general approach here: he has proven via RSDL/SD that 'fair scheduling' is possible and that it results in better desktop scheduling. Kudos Con!"
Donc Ingo reconnait parfaitement avoir utilisé l'idée originale de Con et il attribue correctement le crédit de cette idée (et ajoute ses remerciements).
Ensuite il a l'air de dire (ce qui est normal) que sa solution est techniquement supérieure :
"CFS's design is quite radical: it does not use runqueues, it uses a time-ordered rbtree to build a 'timeline' of future task execution, and thus has no 'array switch' artifacts (by which both the vanilla scheduler and RSDL/SD are affected)."
[^] # Re: Fin de la branche CK
Posté par imalip . Évalué à 6.
Chouette. Le mec a bossé sur un systeme pendant des années, s'est fait allumer, et des qu'il est indisponible, les memes qui l'ont allumé reprennent les idées qu'il a développées. Mais il a droit a une ligne de remerciement dans "le nouveau scheduler CFS d'Ingo Molnar", alors il peut fermer sa gueule.
A ce tarif la, je veux bien comprendre qu'il l'ait un peu mauvaise et laisse tomber le projet, je suis déja passé par la...
[^] # Re: Fin de la branche CK
Posté par David . Évalué à 10.
Interviews de 2002 :
Kolivas : http://kerneltrap.org/node/465
Molvar : http://kerneltrap.org/node/517
Un resume tres complet des echanges entre Kolivas et Molvar sur LKML :
http://kerneltrap.org/node/8059/L
Pour ma part, je vois 2 lamentables erreurs de gestion humaine :
- Molvar affirme avoir creer CFS en 62 heures, plus 6 heures de test. Il s'est fonde sur les idees de Kolivas qui travaille sur le sujet depuis plusieurs annees. Mais Molvar n'a pas trouve necessaire d'en discuter 1 minute avec Kolivas avant de poster son patch CFS sur LKML.
- Les mainteneurs (Torvalds, Molvar, Piggin et d'autres) ont souvent regarde de haut les patchs CK. Puis Torvalds en a remis une couche en soutenant Molvar sur LKML, comme quoi rivalite et tension participe a la qualite du kernel...
Ma conviction (tout a fait personnelle), c'est que Molvar ne devait pas trop apprecie que depuis 2002-3 un gus australien developpant sur son temps libre viennent marcher sur ses plate-bandes, en disant que le scheduler o(1) n'etait pas si bon que ca.
(autre conviction : Torvalds est un super ingenieur, mais un pietre manager).
Sequence souvenir (26 juillet 2003) :
http://www.ussg.iu.edu/hypermail/linux/kernel/0307.3/0554.ht(...)
[^] # Re: Fin de la branche CK
Posté par Gabriel Linder . Évalué à 2.
[^] # Re: Fin de la branche CK
Posté par David . Évalué à 3.
[^] # Re: Fin de la branche CK
Posté par paul . Évalué à 10.
C'est tout à fait l'impression que cette histoire me laisse également. D'un coté un développeur payé par red-hat dont le boulot à plein temps est de faire de l'ordonnancement dans le kernel. De l'autre un médecin avec sa petite famille qui prend de son temps libre pour trafiquer le noyau. Ce dernier n'est pas vraiment de la bande à linus, il se permet de dire que certaines portions du kernel pourraient être améliorées, et puis il le prouve en le faisant.
En résumé, voici une reconstitution fortement exagérée de ce qui a pu se passer :
Kolivas : bon, o(1) c'est sympa mais parfois j'ai du lag dans les applications, je pense qu'on pourrait peut-être remplacer la contrainte de ...
Molnar : bullshit on peut pas faire mieux
----- un peu plus tard ----
Kolivas : c'est bon j'ai un nouvel ordonnanceur qui s'appelle RSDL, testez-le pour voir
---- linus et molnar en privé ----
Molnar : eh linus, y'a le toubib' qui r'commence à faire mon taff', comment tu veux que je justifie ma paye moi après ?
linus : bon sang mais c'est que ça marche sacrément bien son machin en plus, ça me dirait bien de l'utiliser mais j'ai pas envie de passer pour une bille en admettant sa supériorité
molnar : et moi donc !
linus : tu sais quoi, de toute façon ce mec m'énerve, c'est moi le roi ici, i am the king, et y'a que moi qui ai le droit de dire quand un truc c'est de la merde ! Tiens t'as qu'à lire un peu son code, moi je m'arrange pendant ce temps, je vais bien lui trouver un truc, au pire je le traiterai de nazi.
--- de retour sur la LKML ---
linus : Kolivas, c'est bien ton truc, mais faudrait faire ça ça et ça en plus, pour la semaine prochaine
(...)
kolivas : voila linus, c'est fait
linus : ah, euh, ok, bon alors tu feras ceci, cela, et aussi ça ça ça et ça et puis aussi ça et tu referas ça, le tout pour demain !
(...)
kolivas : voila
linus : bon sang j'en ai marre, maintenant tu recommences tout à zéro et je veux qu'en lisant les premières lettres de chaque ligne de ton code ça fasse un pamphlet à ma gloire, tu dors pas et tu me fais ça pour demain matin et j'envisagerai de remplacer o(1) par SD
kolivas : arg, glaps -> hosto
--- sur la LKML ---
molnar : eh les mecs j'ai un nouvel ordonnanceur, j'ai fait ça vite fait, je pense que d'ici une soixantaine de hacks et quelques renice ça fonctionnera bien
linus : mais c'est suuuupaaaaiiiiiiiiiirre, quelle heureuse surprise, allez on l'adopte !
kolivas : euh, mais le miens il fait mieux et depuis quelques mois, il est moins gros et moins dur à ...
linus : ouais, mais toi t'es un qu'un sale faiblard, regarde t'es allé à l'hosto, t'es même pas capable de maintenir du code et puis t'façon y'a déjà CFS, t'as pas l'impression de venir faire double-emploi là ? Et puis le logiciel, c'est comme mon sexe, c'est meilleur quand c'est gros et dur.
--The End--
[^] # Re: Fin de la branche CK
Posté par Gabriel Linder . Évalué à 2.
[1] : http://article.gmane.org/gmane.os.openbsd.misc/126235
et l'article dont ils parlent : http://blogs.zdnet.com/Ou/?p=559
[^] # Re: Fin de la branche CK
Posté par EdB . Évalué à 3.
C'est les autres qui déforment et disent "regarde Linus dit que Theo raconte que des conneries".
C'est aussi aux lecteurs et à toi d'être critiques.
[^] # Re: Fin de la branche CK
Posté par Gabriel Linder . Évalué à 2.
[^] # Re: Fin de la branche CK
Posté par H_francis . Évalué à -1.
Équitable dans le sens, équitable quoi, juste et honnête, Fair Scheduler, bien, qui respecte tout le monde quoi, comme linux et le travail communautaire, etc, bref, tous ces beaux concepts philosophiques qui sont quand même importants, comme le sheduler du noyau qui est important aussi, non?
Bon dommage alors
# Regressions et mac80211
Posté par herodiade . Évalué à 10.
Quelques précisions et compléments d'informations, en vrac :
* Puisqu'on parle de la liste des régressions. Adrian Bunk maintenait une telle liste durant les derniers mois, qu'il postait chaque semaine sur LKML. Fâché de l'insuccès de son travail (il considère que le 2.6.21 n'aurait pas du sortir en l'état), Bunk a décidé d'abandonner cette tache ingrate, au grand dam des autres développeurs (y compris de Linus) (cf. http://kerneltrap.org/node/8110 ). À cette occasion Google a rappelé qu'ils cherchent à embaucher un « bug master » pour le noyau Linux. Finalement Michal Piotrowski a pris les choses en main et maintient une liste des régression dans un wiki (à l'adresse citée plus haut).
* La nouvelle couche Wi-Fi (<- ça s'écrit comme ceci en fait) s'appelle mac80211 (ou encore d80211). Outres les fonctionnalités citées dans la dépêche, elle mutualise une implémentation MAC logicielle commune pour les divers pilotes, souvent nécessaire avec les chipsets modernes et sots, dits « softmac ». Son intégration dans le noyau standard a parait-il permis de la stabiliser, et simplifiera grandement l'intégration des pilotes récents (nombreux sont ceux qui l'utilisait déjà auparavant, bien qu'elle n'était pas incluse dans le noyau), comme iwlwifi (Intel 4965AGN), les pilotes ralink rt2x00, le nouveau pilote pour le chipset Marvel Libertas, le Broadcom bcm43xx, et bien d'autres. L'ancienne couche Wi-Fi (qui s'appelle ieee80211) est conservée dans le noyau (de nombreux « vieux » pilotes l'utilisent). La perspective d'une telle cohabitation - et du travail de maintenance qui s'en trouve doublé - fut la cause de nombreux débats sur les listes de diffusion. Remarquez aussi que l'API de configuration WEXT du ieee80211 est rendue obsolète par le nouveau mécanisme nommé cfg80211, basé sur netlink (API nl80211). Une couche de compatibilité est toutefois maintenue (avec l'aide, si je me souviens bien, d'une bibliothèque en espace utilisateur).
* La nouvelle couche FireWire (<- ça s'écrit ainsi) est certes plus dense (moins de lignes de codes) mais n'est pas tout à fait complète encore. Par exemple l'eth1394 (émulation ethernet sur FireWire) n'est pas encore porté, si vous utilisez cette fonctionnalité, attendez encore un peu.
[^] # Re: Regressions et mac80211
Posté par patrick_g (site web personnel) . Évalué à 3.
1) Merci pour le lien vers la liste des régressions. Effectivement c'est une bonne idée d'inclure ce lien lors d'une news kernel et je vais essayer de m'en souvenir pour celle du 2.6.23 (entre parenthèse la liste des régressions du 2.6.22 me semble minuscule par rapport à l'ampleur des changements).
2) Pour ce qui est de la présence de l'ancienne couche Wi-Fi : Elle n'a évidemment pas vocation à faire de vieux os dans le noyau et elle sera éliminée sans pitié dès que les derniers pilotes seront portés sur la nouvelle pile.
[^] # Re: Regressions et mac80211
Posté par herodiade . Évalué à 9.
Remarque qu'il ne s'agit que des régressions connues : le noyau est toujours mieux testé juste après la sortie d'une nouvelle version (malheureusement !). Et il ne s'agit (presque) que de régressions, les bugs touchant des nouvelles fonctionnalités ou architectures ne sont pas des régressions. Pendant la phase de développement cette liste a été très longue, par moments. Elle a effectivement été sérieusement réduite (preuve, peut-être, de son efficacité : les problèmes n'ont pas été négligés).
Je suis moins optimiste en ce qui concerne l'ancienne couche Wi-Fi : je n'ai pas l'impression que qui que ce soit travaille à l'adaptation des pilotes prism2.5 ou encore ipw2200, par exemple. Peut-être parce que mac80211 n'est (ou du moins n'était, récemment) pas encore tout à fait adapté aux chipsets fullmac (me semble-t-il avoir lu, je ne suis pas 100% sur que ce soit toujours vrai), et qu'il suffira d'attendre quelques mois de maturation. Peut-être aussi parce qu'il est difficile de restructurer complètement un logiciel éprouvé par le temps sans causer de grosses régressions.
Mais il ne faut pas oublier qu'un certain nombre d'entre eux furent développées en interne par des sociétés commercialisant le chipset mais ne donnant pas les specs, ou sous NDA seulement, et qu'Intel, par exemple, n'a aucune envie de consacrer des ressources pour re-développer un produits qu'ils ne vendent plus, alors qu'il est tellement plus simple d'encourager les utilisateurs à changer de matériel. Quand on disait que « donner les specs, sans NDA, c'est beaucoup mieux que donner un driver GPL » ...
[^] # Re: Regressions et mac80211
Posté par patrick_g (site web personnel) . Évalué à 8.
C'est clair et Theo à 100 fois raison de se battre là-dessus.
[^] # Re: Regressions et mac80211
Posté par reno . Évalué à 1.
<mode optimiste>
Peut-être est-ce parce que les développeurs du noyau ont du sortir leur 'brown paper bag' (expression venant du sac utilisé pour 'cacher' les bières aux US il me semble, le pays étant "légèrement" puritain) pour la 2.6.21 et ont soigner la 2.6.22?
</mode optimiste>
[^] # Re: Regressions et mac80211
Posté par gvallee . Évalué à 9.
Dans les "brown bags" sont bien les sacs en papier de couleur brune, utilises pour mettre les bouteilles d'alcool certes mais egalement utilises par exemple par les petites epicieries.
Ensuite la vraie situation concernant l'alcool aux US est la suivante :
- Dans la plupart des counties (comtes en bon francais) et des etats, il est interdit de boire de l'alcool sur le voie publique ; comme dans la majorite des communes francaises. La principale difference est qu'aux US, la loi est reellement appliquee. :-)
- Dans la plupart des etats/counties, il est interdit d'avoir une bouteille d'alcool ouverte et apparente sur le voie publique. Tu fais ce que tu veux dans un lieu prive (toujours un peu comme la France).
- Il existe des counties sec (dry counties), i.e., des counties ou la vente et l'achat d'alcool est interdit. Pour anecdote le distillerie Jack Daniels est dans un county sec.
- Dans certains etats les supermarches ne peuvent pas vendre d'alcool, exception pour la biere. Pour trouver du vin ou des liqueurs il faut aller dans des "liquor shops".
- Il est interdit d'avoir une bouteille d'alcool ouverte dans les parcs naturels regionaux et federaux.
- Il est souvent interdit d'acheter de l'alcool le dimanche matin avant midi (au moins de ce que je sais dans le sud, dans la "bible belt").
Bref, comme souvent, generaliser comme tu le fais sur les US n'a pas de sens quand tu connais un peu le pays. Il y a des differences enormes entre les etats et meme entre counties. Mais je suis egalement concient que beaucoup de gens ici ont simplement une animosite naturelle contre les US (je ne dis pas que c'est ton cas, je te connais pas personnellement).
Au passage en Californie par exemple, je pense que l'on peut dire que les gens sont globalement moins puritains qu'en France.
Mes 2 cents inutiles et hors sujet (vous pouvez donc moissonner).
[^] # Re: Regressions et mac80211
Posté par reno . Évalué à 7.
Réglementation qui vient de la religion (wikipedia: puritain: conception de la foi chrétienne) et il me semble que même en Californie les gens sont toujours plus religieux qu'en France (même s'ils le sont moins bien que dans le reste des USA), sinon je suis plutôt d'accord avec toi sur le reste.
[^] # Re: Regressions et mac80211
Posté par gvallee . Évalué à 4.
De plus ca n'est pas parce que une minorite bruyante mais puissante (les puritains) fait passer des lois que tu dois te permettre de juger un pays en entier. D'autant qu'a ma connaissance, la loi sur l'alcool et les brown bags n'est pas directement lieu a un mouvement religieux, c'est a ma connaissance une loi "pour le respect de l'ordre" qui a une signification differernte ici (la notion de liberte est differente ici par rapport a la notion de liberte communement acceptee en France). Tu affirmes que c'est le cas, je suis interesse par tous pointeurs sur le sujet. L'interdiction de vendre de l'alcool le dimanche matin est par contre pour des raisons purement religieuses.
Ensuite a ma connaissane, non les gens en Californie ne sont pas plus religieux (mais peut-etre que l'on ne donne pas la meme definition au terme) qu'en France. De maniere generale de toute facon, la plupart des gens aux US se foutent de ta religion et de tes habitudes. Car contre oui comme je l'ai dis plus haut une groupe puritain existe aux US, est puissant et fait du bruit... de la a "condamner" les US dans son entier, il ne faut pas pousser.
<mode provocation>
Et puis de toute facon, en voyageant tu te rends compte que les francais sont faineants bruleurs de voitures hein... je suppose que de la meme maniere les americains sont puritains.
</mode provocation>
Pour finir tu penses ce que tu veux, tu dis ce que tu veux. Personnellement j'ai la chance de connaitre un peu les US, je precise quelques points que tu mets en valeur et qui sont "deplaces". J'avais tendance a penser la meme chose que toi avant de decouvrir les US et en passant du temps sur place je me suis rendu compte que la majorite des prejuges que j'avais n'avaient aucune realite de masse (bref que c'etaient des generalisations deplacees).
Maintenant j'arrete ici cette "conversation" qui n'a strictement rien a faire sur ce site et qui de toute facon ne va rien changer du tout.
[^] # Re: Regressions et mac80211
Posté par Thomas Douillard . Évalué à 3.
[^] # Re: Regressions et mac80211
Posté par gvallee . Évalué à 3.
[^] # Re: Regressions et mac80211
Posté par reno . Évalué à 3.
Je n'allais pas faire une tartine pour une plaisanterie a 2 cents.
>>tu as ensuite conclu que les US sont puritains.<<
C'est une bonne première approximation, il me semble pour expliquer cette réglementation, il ne faut pas chercher plus loin.
>>non les gens en Californie ne sont pas plus religieux qu'en France.<<
D'après une assistante d'anglais Américaine que j'ai eu, >80% des Américains vont au moins une fois par mois à l'église (en fait c'était encore plus élevé que ça), chiffre très très supérieur a la fréquentation des églises Française (qui ont tendance a être peu fréquentée).
C'était une moyenne pour tout les USA, j'ignore quel est le chiffre pour la Californie, mais s'il correspondait a la moyenne Française, il faudrait que dans les autres états, ils aillent a 150% l'église.
Après peut-être qu'elle a dit une bêtise, mais comme elle était Américaine, je lui ai fait confiance pour ce point.
[^] # Re: Regressions et mac80211
Posté par gvallee . Évalué à -1.
Mais bon c'est une discussion sterile...
# Support de Blackfin
Posté par Boa Treize (site web personnel) . Évalué à 3.
[^] # Re: Support de Blackfin
Posté par BAud (site web personnel) . Évalué à 2.
[^] # Re: Support de Blackfin
Posté par Boa Treize (site web personnel) . Évalué à 4.
[^] # Re: Support de Blackfin
Posté par daemontux . Évalué à 1.
# Merci
Posté par Carl Chenet (site web personnel) . Évalué à 2.
# Qu'est-ce que « eventfd » ?
Posté par Laurent A. . Évalué à 2.
Si ces deux interfaces n'ont aucun rapport entre elles, est-ce que quelqu'un sait si des améliorations sont prévus pour Inotify ? Je pense notamment à ne plus avoir une limite sur le nombre de fichiers « monitorables », ou encore sur la possibilité de lancer Inotify sur tous les sous-dossiers d'une arborescence sans avoir à la parcourir manuellement.
[^] # Re: Qu'est-ce que « eventfd » ?
Posté par patrick_g (site web personnel) . Évalué à 4.
# CFS dans 2.6.23 !
Posté par Sebastien . Évalué à 7.
Enfin le nouvel ordonnanceur CFS d'Ingo Molnar (évoqué lors de la dépêche sur le noyau 2.6.21) en est à sa dix-neuvième version et le temps de l'inclusion dans la branche principale approche à grands pas !
Ca y est, il est dans la branche principale:
http://lwn.net/Articles/241085/rss
[^] # Re: CFS dans 2.6.23 !
Posté par Gabriel Linder . Évalué à 2.
$ cat /proc/version
Linux version 2.6.22.1-cfs-v19-dargor (root@oblivion) (gcc version 4.1.2) #1 SMP PREEMPT Wed Jul 11 09:52:58 CEST 2007
[^] # Re: CFS dans 2.6.23 !
Posté par gpe . Évalué à 0.
Déjà que je trouve un Linux normal (2.6.18) bien plus réactif et fluide qu'un Windows XP alors avec CFS...
[^] # Re: CFS dans 2.6.23 !
Posté par David . Évalué à 4.
[^] # Re: CFS dans 2.6.23 !
Posté par Gabriel Linder . Évalué à 1.
[^] # Re: CFS dans 2.6.23 !
Posté par reno . Évalué à 3.
[^] # Re: CFS dans 2.6.23 !
Posté par David . Évalué à 3.
En est-il de meme pour l'ordonnanceur CFS, ou est-ce sans incidence ?
[^] # Re: CFS dans 2.6.23 !
Posté par reno . Évalué à 4.
Bon, ce n'est pas 100% vrai: par exemple une future modification (sur la gestion des timers il me semble) consiste a regrouper le lancement des taches: plutot qu'avoir:
tache A: t: 0, 1, 2, 3
tache B: t 0.5 1.5 2.5
il vaut mieux avoir tache A et B: 0 1 2 3 d'un point de vue consommation électrique, car le CPU reste libre plus longtemps entre les deux, donc peut être mis dans un mode de consommation électrique plus faible plus longtemps.
[^] # Re: CFS dans 2.6.23 !
Posté par herodiade . Évalué à 6.
L'idée est que dans de très nombreux cas, on a besoin de programmer une tâche dans le futur, ou à intervalle régulier, mais on n'a pas nécessairement besoin que la date d'exécution de cette tache soit vraiment précise à la fraction de seconde près. On souhaite seulement que « cet (évènement|tache à exécuter) ai lieu approximativement (dans|toutes les) X seconde(s) ».
Ainsi, si nous avions 10 pilotes de périphériques différents qui programmaient l'exécution d'une tâche toutes les secondes environ, mais n'avaient pas initialisé leurs timers en même temps (ou bien avec un intervalle légèrement différent), ils réveillaient le noyau 10 fois par seconde. Si ces 10 pilotes sont modifiés pour programmer leur réveil à une date arrondie avec round_jiffies, ils s'exécuteront en même temps, causant un seul réveil par seconde (un seul réveil à la seconde entière, qui, au passage, aurai de toutes façon eu lieu, même en l'absence de ces 10 pilotes, car il y a déjà d'autres choses converties au round_jiffies).
Il reste beaucoup de travail pour tirer pleinement parti de cette nouvelle API partout où le noyau pourrait le faire, mais certains y travaillent visiblement, et chaque petite conversion réduit le nombre de réveils par seconde dont le noyau à besoin.
Note : s'il y a des développeurs GTK/Gnome dans le coin : c'est exactement comme g_timeout_add_seconds_full() ou g_timeout_add_seconds() (au lieu de g_timeout_add()). Cette fonction permet d'économiser de l'énergie en réduisant les réveils de la CPU, car elle regroupe tout les évènements programmés à la prochaine seconde entière. Svp, si vous n'avez pas besoin d'une granularité/précision très fine, par ex. si vous avez besoin de programmer une action « approximativement toutes les X secondes », préférez utiliser celle-ci au lieu de g_timeout_add().
[^] # Re: CFS dans 2.6.23 !
Posté par herodiade . Évalué à 7.
Il serait vraiment intéressant que quelqu'un rédige un article sur la programmation économe en énergie pour linuxfr (ou mieux Linux Magazine) : utilisation des évènements plutôt que polls réguliers, utilisation de hal, de inotify ou de gamin, des timers regroupés, regroupement des accès aux block devices, réduction des animations graphiques (elles réveillent xorg), stracer régulièrement son application juste pour vérifier qu'elle ne fait vraiment rien lorsqu'elle est au repos, utiliser le système de notification d'Alsa (plutôt que poller le mixer), audit et disagnostic avec block_dump, strace, ltrace, powertop, lm-profiler et blktrace, ...
Les ventes de portables par an ont maintenant dépassé les ventes de stations de bureau[2][3] : la consommation est donc devenue une problématique majeure pour le succès de « Linux sur le desktop ». Et Linux est une option considérée depuis peu avec beaucoup d'attention par les intégrateurs, maintenant - c'est récent - qu'ils disposent de chipsets x86 mobiles tout-en-un à très bas prix : le coût d'une licence Windows sur le portable final est dans ce cas proportionnellement très significatif. C'est probablement un critère déterminant dans le choix de Linux pour l'Asus EEPC, l'Intel Classmate ou encore l'OLPC, et de l'investissement d'Intel (qui commercialise de tels chipsets bons marché) qui paye des développeurs comme Arjan van de Ven pour travailler à plein temps sur la consommation électrique de Linux.
Linux dispose d'une belle perspective pour s'imposer à travers ce nouveau marché des portables (en particulier des ultraportables à bas prix), mais il faut pour cela qu'on apprenne à programmer de façon économe. Jusqu'à présent, on ne considérait pas vraiment cet aspect spécifique, au coté, par exemple, des améliorations des performances ou de la consommation de mémoire vive. Mais les développeurs noyau essaient d'attirer notre attention sur ce sujet[4].
[1] http://lwn.net/Articles/240253/ (voir aussi http://lwn.net/Articles/228143/ et http://www.ussg.iu.edu/hypermail/linux/kernel/0610.1/0959.ht(...) ).
[2] http://www.usatoday.com/tech/news/2005-01-23-laptop_x.htm
[3] http://www.msnbc.msn.com/id/8090448
[4] Je pense à PowerTOP d'Arjan van de Ven, mais aussi au fameux Why Userspace Sucks—Or 101 Really Dumb Things Your App Shouldn’t Do, Dave Jones (Red Hat), Proceedings of the Linux Symposium, 2006, Ottawa [https://ols2006.108.redhat.com/reprints/jones-reprint.pdf]
# Scheduler
Posté par karteum59 . Évalué à 2.
Réciproquement, si je devais mettre en oeuvre un scheduler pour de la QoS réseau, est-il sensé d'imaginer copier-coller CFS de Ingo Molnar ? (ou un autre scheduler processus du noyau, mais je prends CFS pour exemple puisqu'il paraît qu'il est top :).
[^] # Re: Scheduler
Posté par reno . Évalué à 4.
Pour les IO disques, il y a une gestion de localité tres importantes, mais pas pour le reseau..
Certes vu de loin ça fait la même chose, mais en pratique..
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.