Une flame war d'un fort beau gabarit\nComme il l'avait annoncé lors du cycle précédent, Linus a décidé de fermer la période de merge plus tôt que d'habitude. Le plan était de donner une leçon en claquant la porte au nez des récalcitrants qui persistaient à envoyer leurs patchs au tout dernier moment. C'est donc seulement 11 jours après la sortie du noyau 2.6.33 que la version RC-1 a été annoncée :\n« Voilà c'est dispo maintenant. J'ai encore quelques branches pour lesquelles j'ai des demandes de pull et que je veux scruter d'un peu plus près (ceph, branche gdb, etc) et il est possible que j'ai laissé passer quelques autres demandes. Si vous pensez que vous avez été oublié alors faites-moi signe, mais à part ça la période de merge est terminée.\nComme promis si vous pensiez attendre le dernier jour de la fenêtre des 15 jours pour envoyer votre demande eh bien maintenant vous devrez attendre le 2.6.35.\nPlus ou moins 850 développeurs ont contribué jusqu'à présent, plus de 6 500 fichiers modifiés, plus de 400 000 lignes ajoutées et environ 175 000 supprimées. En d'autres termes trop de trucs pour en faire un résumé.\nUn truc qui m'a impacté, comme ce sera sans doute le cas pour d'autres personnes, c'est qu'en cas d'utilisation de Nouveau vous devrez aussi installer les nouvelles versions de libdrm/nouveau_drv.\nÀ part ça si quelque chose ne marche pas c'est le moment de brailler ! ».\nCertains développeurs se sont fait avoir par la fermeture précoce de la période de merge et, naïfs comme ils sont, ils ont protesté auprès de Linus en soulignant que la date de fin était devenue imprévisible. Bien entendu la seule réponse de Linus a été un tonitruant "THAT WAS THE WHOLE F*CKING POINT!" (que je traduirai poliment en "Cher ami, c'était bien le but de la manœuvre").\nAssez curieusement Linus a rendu disponible la version candidate RC-2 sans l'accompagner d'un mail descriptif comme il en a l'habitude en temps normal. En fouillant la liste de diffusion du noyau on trouve quand même une explication dans un autre de ses mails :\n« Désolé pour le long délai. J'ai passé 5 jours à assister à deux présentations Intel lors des 2 dernières semaines et cela a monopolisé une bonne part de mon temps ».\nCette absence temporaire ne l'a pas empêché de déployer toute sa verve quand il a eu à analyser les patchs qui lui avaient été soumis en son absence:\n« Je _déteste_ absolument quand je vois du code de compatibilité pour une fonction qui vient juste d'être ajoutée. Ma réaction immédiate c'est What The Fuck ? Quelle sorte d'abruti ne prendrait même pas la peine d'écrire dès le début un code compatible 64 bits ? Il faut juste que l'interface fonctionne proprement au lieu d'ajouter cette couche de compatibilité merdique ».\nC'est dans le mail de la version RC-3, le 30 mars dernier, que Linus s'est expliqué sur ses décisions concernant les deux versions candidates précédentes et sur le fait qu'il avait finalement été magnanime en acceptant les patchs tardifs:\n« OK, donc la RC-2 a été bordélique, aucun doute là-dessus. Je suis trop tendre pour bloquer le travail de gens donc ma tentative de donner une bonne leçon lors de la RC-1 n'a pas vraiment fonctionné comme je l'espérais. Mais la _prochaine_ fois ! Attention à vous cette fois !\nBon de toute façon, à partir d'une RC-2 bordélique nous avons maintenant une RC-3 qui devrait être en bien meilleur état. De nombreuses régressions sont corrigées et le shortlog est suffisamment court pour être posté sur la liste de diffusion ».\nLinus évoque ensuite un important bogue potentiel pour les utilisateurs de SELinux sous Ext3 qui auraient utilisé les versions candidates précédentes. Il explique comment corriger la corruption des labels de sécurité et conclut enfin qu'il est peu probable que ce bug touche beaucoup de monde:\n« Bien entendu je suspecte que la plupart des gens qui font tourner des noyaux expérimentaux sont aussi ceux qui ont désactivé SELinux il y a longtemps tellement c'est emmerdant. Ou bien que ces personnes ont probablement fait le saut vers Ext4 (qui n'a pas le bug) depuis des lustres...mais bon qu'est-ce que j'en sais après tout ? ».\nAprès la RC-3 il a fallu attendre deux longues semaines pour que Linus annonce le 12 avril la sortie de la quatrième version candidate. Ce retard s'explique par un bug mystérieux détecté dans la RC-3:\n« Cela fait deux semaines au lieu d'une comme d'habitude parce que nous avons chassé une régression vraiment ennuyeuse dans le code de la mémoire virtuelle et que je ne voulais pas sortir la RC-4 avec ce bug.\nDes _super_ remerciements pour Borislav Petkov qui a signalé le problème et qui non seulement a été capable de le reproduire de façon régulière mais aussi de tester immédiatement de nouveaux patchs pour isoler le bug. Ce truc nous a pris dix jours d'aller-retours d'emails et Borislav a été disponible en permanence, jour et nuit, pour nous aider à trouver la cause du problème ».\nPour ceux qui seraient curieux au sujet du bug vicieux évoqué par Linus, le site LWN a publié un article explicatif (dose d'aspirine fortement recommandée). Comme le dit l'article de façon imagée cette chasse au bug a été intense et compliquée: "the most intensive head-scratching which has been seen on the list".\nCe que Linus ne dit pas dans son message de RC-4 c'est que c'est lui, parmi tous les autres développeurs chassant le bug, qui a finalement trouvé l'origine du problème. Après des espoirs déçus à la suite de la correction d'autres bugs sans que le problème d'origine ne disparaisse, il a semblé sur le point de se résigner au retour arrière sur tout le patch.\nDur, dur quand même de jeter l'éponge après une telle chasse: « Je détesterai avoir à faire un revert sur tout le patch du fait des heures que j'ai passé à lire ce code (au point que je pense même le comprendre) ».\nN'étant pas touché par le oops il n'a pas pu tester lui-même ni déboguer directement. Il a dû se contenter de lire le code gérant la mémoire virtuelle et regarder le contenu des registres du dump posté par Borislav pour imaginer d'où pouvait bien venir ce problème qui mystifiait tous les développeurs. Ayant des super-pouvoirs il a fini par se douter de l'origine du oops et il a proposé une théorie explicative à laquelle personne d'autre n'avait pensé et qui s'est révélée parfaitement correcte.\nAvec l'annonce de la RC-5 du 19 avril dernier on est revenu à une situation plus normale:\n« Nouvelle semaine, nouvelle RC. Cette fois il n'y a pas eu de grosse régression bien vilaine sur laquelle se pencher et c'est juste une RC tout à fait classique. Des petites corrections un peu partout. La plus notable pour les gens qui ont eu le problème est une correction pour les soucis de boot (Problème de division par zéro dans ACPI: Bugzilla du noyau 15749)...mais il y a des patchs pour plein d'autres trucs ».\nC'est dans la version RC-6 du 29 avril que Linus a, entre autres choses, dévoilé le nouveau nom de code du noyau. Fidèle a son habitude d'utiliser des noms d'animaux absurdes (voir la liste) il a choisi cette fois Sheep on Meth (ce qui en français donne quelque chose comme "Moutons drogués à la méthamphétamine"). Il est évident que ce n'est pas avec ça qu'il va détrôner le "Homicidal Dwarf Hamster" du noyau 2.6.20.\nEnfin, neuf semaines après la première version candidate de ce cycle, c'est le 9 mai que Linus a annoncé RC-7:\n« Je pense que c'est la dernière RC. Tout a été particulièrement calme sur le front des patchs, même si il y a eu des discussions assez animées sur la liste ».\nLa partie client du système de fichiers distribué Ceph fait son entrée dans le noyau Linux.\nCeph est issu de la thèse de doctorat de Sage Weil qui a ensuite continué à développer son bébé pour arriver à un niveau de maturité lui permettant de demander son intégration dans la branche principale.\nCe qui distingue Ceph c'est que les données et les métadonnées sont séparées dans des serveurs distincts. On a ainsi des serveurs MDS (pour MetaData Server) et des serveurs OSD (pour Object Storage Devices) qui font de la répartition intelligente et qui s'adaptent à la charge. La sémantique d'accès aux données est sans surprise puisqu'elle répond à la norme POSIX et, en cas de gros problème, la récupération de ces données se fait à partir de plusieurs disques simultanément et à destination de plusieurs autres disques (mode N-way replication).\nOn pourrait penser que Ceph est proche du système de fichiers à haute performance Lustre, très utilisé sur les superordinateurs et développé par Oracle. C'est vrai car Lustre sépare lui aussi les données et les métadonnées dans des serveurs différents. Néanmoins, il existe plusieurs différences (outre le fait que Lustre n'est pas encore intégré officiellement dans le noyau).\n- Les noeuds de stockage locaux de Ceph utilisent le très moderne système btrfs ce qui permet de profiter de ses fonctions de sommes de contrôle ou de réplication.\n- L'administration de Ceph est plus simple que celle de Lustre. Pour obtenir de la haute disponibilité il suffit d'indiquer qu'on veut x réplications de données et le système s'occupe tout seul de copier les données en cas de crash d'un nœud. La syntaxe à utiliser est très claire puisqu'un niveau de réplication impliquant un quadruplage des données s'ordonne ainsi : ceph osd pool set data size 4.\n- Les noeuds de métadonnées et de données de Ceph fonctionnent avec des démons en espace utilisateur alors que pour Lustre tout est entièrement en espace noyau. De plus, Ceph utilise des serveurs de métadonnées répartis sur plusieurs machines quand Lustre ne peut utiliser qu'un seul serveur de métadonnées.\nAu bilan Lustre reste imbattable sur son créneau des hautes performances pour lequel il est parfaitement adapté mais Ceph offre une alternative de système de fichier distribué plus simple à administrer et intégrant "de base" plus de fonctions. Le fait qu'il se base en local sur des noeuds utilisant btrfs est une très bonne idée car cela permet de réutiliser du code sans réinventer la roue. Sage Weil a d'ailleurs participé à l'amélioration de btrfs avec plusieurs patchs. Pour aller plus loin dans la découverte de Ceph on peut consulter cette présentation au format odp et lire cet article de linux-mag qui fait le point et rappelle que le système est encore considéré comme expérimental (comme btrfs d'ailleurs).\nPar rapport à NILFS, qui est un autre système de fichiers basé sur l'approche "log structured", la fonction de ramasse-miette est entièrement dans le noyau au lieu d'être en espace utilisateur avec NILFS. Ainsi, une suppression de fichier sous LogFS mettra immédiatement à disposition cet espace libre alors que pour NILFS il faudra attendre que le démon de garbage collection en espace utilisateur se déclenche.\nLe patch de mise en veille asynchrone des périphériques a été intégré dans le noyau 2.6.34.\nDans la version 2.6.32 de Linux, le développeur Rafael Wysocki avait incorporé une gestion dynamique de l'énergie (runtime power management) pour les périphériques rattachés à l'ordinateur. Avec cette infrastructure, il devenait possible de mettre en veille et de rallumer à la volée les divers périphériques inutilisés d'une machine afin de gagner en consommation d'énergie.\nContinuant dans cette voie Rafael a écrit un nouveau patch visant à rendre ces transitions asynchrones afin de gagner en rapidité.\nAvant ce patch, les changements d'état des périphériques étaient synchrones, ce qui signifie qu'ils devaient se dérouler de manière purement séquentielle, les uns après les autres. C'est évidemment une méthode lente et ce d'autant plus que le nombre de périphériques est élevé. Avec le patch mise en veille asynchrone des périphériques inutilisés, on peut procéder aux extinctions ou aux rallumages de plusieurs périphériques en parallèle. Comme les mises en veille et les rallumages se font plus rapidement il est évident qu'au final on gagne en consommation.\nLe problème évident avec cette méthode, c'est qu'il existe des dépendances entre certains périphériques. Par exemple, une dépendance existe entre un contrôleur PCI et les périphériques actuellement branchés sur les ports PCI. Il n'est pas possible d'éteindre à la volée le contrôleur sans avoir d'abord éteint tout ce qui lui est attaché. Inversement, il n'est pas possible de rallumer des périphériques PCI sans prendre la précaution de rallumer en premier le contrôleur.\nLe patch de Rafael, très complexe, prend donc bien soin d'examiner la topologie complète des périphériques afin de prendre des décisions pertinentes quant à leur gestion asynchrone.\nLe problème c'est que Linus Torvalds, inflexible gardien de la propreté du code, a détesté le patch initial de Rafael :\n« Je pense que le patch est complètement et totalement pourri. À la fois d'un point de vue implémentation _et_ d'un point de vue conceptuel. Nous n'avons pas besoin de ces initialisations de flags par périphérique, pas plus que nous n'avons besoin que les pilotes "activent" le code asynchrone.\nPourquoi le code de mise en veille/réallumage a besoin de toute cette m*rde ?\nCe serait bien plus naturel d'introduire un hook qui s'occuperait de la phase de pré-mise en veille et parcourrait l'arbre des périphériques pour faire le boulot asynchrone.\nEn d'autres termes, je ne vais certainement pas inclure cette folie ».\nSelon Linus, le code Rafael était bien trop compliqué et, durant toute la longue discussion qui a suivi sur la liste de diffusion, il a poussé pour avoir la solution la plus simple possible:\n« OK les gars, arrêtez de balancer des idées folles sur la liste. Ce n'est pas comme si notre infrastructure de mise en veille était devenue si stable et ennuyeuse et que nous voulions la rendre à nouveau peu fiable.\nPourquoi est-ce que vous fabriquez tous ces trucs qui sont bien plus complexes qu'ils ne devraient ? ».\nAprès avoir tenté une première approche basée sur un sémaphore posé sur chaque nœud de l'arbre des périphériques, Linus a finalement accepté en bougonnant une version qui se base sur la notion de "complétion".\nLa technique est détaillée dans le message de commit mais schématiquement cela consiste à associer une structure de complétion à chacun des noeuds de l'arbre (dev->power.comp). Par défaut cette structure est positionnée sur "not_complete". De plus, les périphériques qui implémentent la fonction de mise en veille asynchrone doivent faire appel à la fonction device_enable_async_suspend() pour activer un flag. Lors d'une mise en veille, l'infrastructure de gestion de l'énergie de Rafael va lancer des threads et attendre que tous les périphériques ayant le flag asynchrone se mettent en veille avant d'éteindre le bus maître.\nJon Corbet, qui a analysé toute cette affaire dans un article du site LWN, conclut lucidement par ces mots:\n« Cet épisode peut être vu comme une marque de dédain pour le temps de développement qui a été consacré à un patch. Il n'est pas rare que du code qui a demandé beaucoup de travail finisse par être mis au rebut ou complètement réécrit. Ce modèle de développement peut sembler tout à fait dispendieux et il ne fait aucun doute qu'il peut être très frustrant pour les développeurs impliqués. Mais c'est aussi un élément fondamental des procédures de contrôle de qualité qui existent dans le modèle de développement du noyau. L'infrastructure de mise en veille a été nettement améliorée par ce remaniement de dernière minute ».\nLe mécanisme de sécurité GTSM (Generalized TTL Security Mechanism) entre dans le noyau.\nDécrite dans la RFC 5082, cette protection est destinée à contrer des attaques de type déni de service permises par le protocole de routage BGP (Border Gateway Protocol).\nCe protocole BGP permet aux équipements réseau de définir la route que doivent parcourir les paquets. Mais comment s'assurer que le routeur supposé ami avec qui on est en train de dialoguer et d'échanger des routes n'est pas en réalité une machine lointaine sous le contrôle d'un vil pirate ? Pour le savoir, les sessions BGP utilisent une signature cryptographique basée sur MD5. Et là, paf, c'est le drame car avec cette solution le méchant n'a plus qu'à envoyer pleins de paquets forgés pour mettre à genoux le pauvre petit routeur. Calculer le hash MD5 de la signature prend du temps et, si le routeur est bombardé de paquets forgés, son processeur ne suffira pas à la tâche.\nC'est pour contrer ce déni de service potentiel que le mécanisme GTSM a été introduit.\nGTSM utilise un champ sur 8 bits qui est présent dans les paquets IPv4, le champ TTL (Time-to-live) qui compte le nombre de routeurs que traverse le paquet avant d'arriver à destination.\nCe champ a été introduit à l'origine pour éviter que des paquets ne tournent en boucle à l'infini dans le réseau. Au moment de l'envoi, on positionne le champ à une certaine valeur (souvent 64) et chaque routeur décrémente le champ de un lors de son passage. Au bout de 64 sauts de machine en machine le champ est à zéro et le paquet peut être jeté aux oubliettes.\nAvec le mécanisme de sécurité GTSM, un routeur va devoir positionner le champ TTL à 255, le maximum permis par la taille de 8 bits, avant de l'envoyer au routeur avec qui il communique. Sachant que deux routeurs BGP sont presque toujours adjacents sur le réseau (ils sont seulement à un "saut" l'un de l'autre) la machine qui reçoit le paquet aura ainsi un moyen facile de vérifier que le paquet n'est pas forgé. S’il a un TTL de 255, alors c'est qu'il n'a rien traversé entre-temps et on peut lui faire confiance. Si le TTL est inférieur à 255 alors le paquet est forgé et on peut le jeter sans même avoir à calculer un couteux hash MD5.\nL'activation du mécanisme se fait via l'option IP_MINTTL qui permet de définir le TTL minimum (évidemment, on doit choisir 255 pour que ça marche).\nLe message de commit signale que pour l'instant l'option équivalente pour IPv6 (IPV6_MINHOPLIMIT) n'est pas encore implémentée et, autre limitation provisoire, que seuls les paquets TCP sont concernés.\nÀ noter que le mécanisme GTSM, simple et astucieux, était déjà présent chez les noyaux BSD (par exemple depuis la version 7.0 de FreeBSD) et que Linux ne fait donc ici que rattraper son retard sur ses cousins libres.\nLe patch "lockdep RCU", permettant la vérification automatique des appels au code RCU dans le noyau, a été accepté dans le noyau 2.6.34.\nLa technique du Read-Copy Update est un mécanisme de synchronisation spécialisé qui permet à de multiples threads de lire et modifier simultanément une donnée sans que le processus écrivant n'ait besoin de poser un verrou bloquant sur la donnée. Le RCU autorise donc à lire une ressource partagée comme si on était seul à y accéder. L'idée de base c'est que quand une opération d'écriture, et non plus de lecture, est demandée par un thread alors la ressource est copiée ailleurs avant d'être modifiée. L'original continue d'exister jusqu'à ce que les threads de lecture aient fini leur travail.\nPaul McKenney est le grand gourou Linux de la technique RCU qu'il améliore et peaufine dans presque chaque nouveau noyau. Après le RCU hiérarchique de Linux 2.6.29 et le Tiny RCU du 2.6.33, voici maintenant arriver le patch de lockdep-RCU.\nPour tenter de comprendre ce qu'apporte ce patch il faut savoir que la technique RCU, assez simple à décrire brièvement, est en réalité relativement complexe dans ses détails techniques. Si les processus lisant la donnée s'exécutent dans des sections délimitées par des appels à rcu_read_lock() et rcu_read_unlock() il faut aussi que le code offre de plus fortes garanties de cohérence de la donnée. En effet certaines architectures de processeur (Alpha par exemple) réordonnent les accès mémoire et c'est pareil pour les compilateurs qui peuvent, lors d'optimisations agressives, réordonner le code assez librement. Il faut donc que le mécanisme de RCU tienne compte cette absence de garantie et propose une solution technique.\nCette solution c'est le mécanisme de publication-souscription (Publish-Subscribe). Le processus utilisant la fonction de RCU va faire un appel à rcu_assign_pointer() et à rcu_dereference() pour forcer le processeur ou le compilateur à respecter l'ordre désiré.\nLe bon usage de toute cette "triperie" technique n'est pas simple à vérifier et il serait certainement utile d'avoir un outil permettant d'automatiser autant que possible la vérification.\nLa technique du RCU a été introduite dans le vénérable noyau de développement 2.5.43 en 2002 et dans le noyau 2.6.10 de décembre 2004 il n'y avait que 38 occurrences de rcu_dereference() dans le code. La vérification de tous ces appels pouvait donc encore se faire artisanalement "avec les yeux".\nDans le noyau 2.6.32 il y a plus de 230 appels à rcu_dereference() et on atteint les limites puisque les développeurs constatent que l'utilisation du RCU n'est pas toujours parfaite dans le code des périphériques (voir ce mail récapitulatif de Thomas Gleixner).\nPaul McKenney, aidé de Peter Zijlstra et de Thomas Gleixner, a donc choisi de modifier l'outil lockdep d'Ingo Molnar pour lui permettre de détecter les utilisations fautives de RCU. Lockdep est déjà utilisé largement par les hackers du noyau pour valider les utilisations des verrous dans Linux afin de détecter les interblocages. Quand lockdep est actif dans un noyau alors une instrumentation du code est effectuée et chaque synchronisation est interceptée à la volée pour vérification.\nÀ partir du noyau 2.6.34, toute utilisation de lockdep transformera la fonction rcu_dereference() en rcu_dereference_check() et toute utilisation de cette fonction sera soumise à la vérification vigilante des conditions définies par les développeurs.\nLe patch lockdep-RCU introduit dans le nouveau noyau va permettre de fiabiliser encore plus les primitives de Read-copy Update. Selon Paul McKenney: « nous n'en sommes qu'au début des primitives RCU vérifiées par lockdep. Elles ont été appliquées au code de la pile réseau, au système de fichiers virtuel et à l'ordonnanceur. Dans le futur le lockdep-RCU devrait être très utile pour détecter encore mieux les bugs d'usage du RCU ».\nLe patch vga_switcheroo intègre le noyau pour permettre de basculer entre des GPU différents.\nDepuis plusieurs mois apparaissent des ordinateurs portables qui possèdent deux cartes graphiques différentes. L'une est une puce dite "discrète", c'est-à-dire une carte AMD ou NVidia classique, dotée d'une mémoire dédiée, et qui est utilisée pour jouer ou pour faire de la 3D. Habituellement cette carte chauffe et consomme pas mal de courant. L'autre carte est une puce "intégrée" bien plus basique (incluse dans le processeur pour les dernières générations) et qui sert essentiellement à toutes les tâches ne nécessitant pas de gestion performante de la 3D.\nLes systèmes d'exploitation propriétaires gèrent déjà ces machines hybrides à double GPU (gestion à chaud pour Windows 7 et via un redémarrage de session pour MacOS X) mais Linux ne pouvait pas les exploiter jusqu'à présent.\nPour permettre de prendre en charge ces nouvelles sortes de machines le développeur Dave Airlie (responsable de la partie "Direct Rendering Manager" du noyau) a travaillé sur une fonction de bascule entre les cartes graphiques baptisée "vga_switcheroo".\nDave a décrit l'avancée de son patch dans plusieurs articles successifs sur son blog (1 - 2 - 3 - 4 - 5) et l'utilisation de la fonction semble assez simple.\nTout se passe dans le répertoire /sys/kernel/debug/vgaswitcheroo dans lequel se trouve un fichier switch. On va pouvoir écrire quatre commandes différentes dans ce fichier (outre ON et OFF pour éteindre complètement une puce):\necho DIS > switch => bascule immédiate vers le GPU discret (la puce puissante)\necho IGD > switch => bascule immédiate vers le GPU intégré (la puce basique)\necho DDIS > switch => bascule retardée vers le GPU discret (la puce puissante)\necho DIGD > switch => bascule retardée vers le GPU intégré (la puce basique)\nLa bascule immédiate ne marchera que si X n'est pas lancé. On utilisera donc bien plus souvent les fonctions de lancement avec retard (DDIS et DIGD) qui enregistrent la demande de changement de GPU pour la rendre effective lors du redémarrage de X.\nEn effet une limitation importante de vga_switcheroo c'est qu'il oblige à redémarrer le serveur X si on veut que la bascule soit effective. Cela est dû au fait que X n'a pas été prévu à l'origine pour autoriser ce genre d'acrobatie.\nPour mieux comprendre pourquoi le serveur X ne sera sans doute jamais adapté pour permettre la gestion "à chaud" de ces nouveaux portables bi-GPU allez lire ce post LinuxFr très intéressant de Stéphane Marchesin dans la dépêche "Du côté de chez Xorg".\nMême si le changement complètement transparent de carte semble pour l'instant hors de portée, il reste tout de même assez rapide de basculer d'un GPU à l'autre. Dave Airlie a ainsi enregistré une petite vidéo afin de montrer au monde entier le switch de carte graphique sur sa machine. La vidéo est visible sur le site Dailymotion.\nPour les réfractaires à la ligne de commande il est parfaitement envisageable de rendre plus "jolie" la bascule en créant un lanceur sur sa barre de tâche qui pointerait vers un petit script shell du type utilisé par Dave dans sa vidéo. Ainsi un utilisateur voulant lancer un jeu cliquerait d'abord sur un simple bouton et le changement de GPU + redémarrage de X de ferait automatiquement en quelques secondes.\nÀ noter que Linus, décidément fort prodigue en gueulantes lors de ce cycle, a objecté sur l'option de configuration à "Yes" par défaut dans le patch initial qui lui a été proposé:\n« Pourquoi est-ce que vga_switcheroo est activé par défaut ? On ne fait pas des trucs comme ça. Les nouveaux pilotes et les nouvelles fonctions ne sont _pas_ activées par défaut.\nLe "default y" est une habitude de me*de. Un développeur pense toujours que _son_ code est tellement spécial et important qu'il devrait être activé par défaut, MAIS C'EST FAUX.\nDonc prière de s'en souvenir : a moins que votre nouvelle fonction ne guérisse le cancer, elle ne devrait certainement pas être activée par défaut ».\nCe sera donc aux distributions de choisir de configurer ou pas vga_switcheroo dans leurs versions du noyau.\nRefus des patch SquashFS\nPour donner une plus juste appréciation du travail des développeurs du noyau, il ne faut pas seulement parler des nouveautés qui entrent dans un noyau, il faut également parler du code qui est bloqué et refusé par ces mêmes développeurs.\nEn effet, il est crucial que les standards d'acceptation de code soient élevées si on veut que Linux maintienne son niveau de qualité.\nDans le rôle du dragon cracheur de feu on retrouve souvent, et c'est bien normal, Linus lui-même. L'innocente brebis qui a été dévorée cette fois-ci est Phillip Lougher qui avait proposé diverses améliorations de Squashfs, un système de fichiers compressé et en lecture seule qui est entré dans le noyau 2.6.29. Dans la dépêche LinuxFr sur cette version il était indiqué que SquashFs utilisait la compression gzip mais qu'il existait un projet pour utiliser l'algorithme lzma à la place. Avec lzma il est possible de compresser encore plus un système de fichiers et donc de faire tenir plus de logiciels sur un LiveCD par exemple.\nPhillip Lougher, l'auteur de Squashfs, a donc écrit une série de patchs pour ajouter ce support de lzma et a proposé à Linus de rapatrier sa branche Git. À l'évidence il ne s'attendait pas à s'entendre rétorquer un cinglant:\n« Bordel mais c'est quoi ces fichiers complètement illogiques et monstrueux ? Il n'est pas question que je merge ça. ».\nLinus n'a pas aimé que le code de décompression spécifique soit incorporé dans un header (dans include/linux/decompress/unlzma_mm.h) et il a protesté avec son ton habituel:\n« Cette façon débile de cacher une implémentation pourrie de malloc dans un fichier de header me fait juste vomir.\nJe refuse de voir l'inclusion de trois nouvelles copies de ce truc dégoûtant (bunzip, inflate et lzma).\nC'est déjà assez dégueulasse comme ça dans compress/mm.h (ce truc devrait d'ailleurs être mis en orbite à coup de bombes nucléaires, c'est le seul moyen d'en être débarrassé) mais quand je vois qu'on essaye de répandre cette horreur un peu partout dans le noyau je passe en mode attaque zombie et je cours tout nu dans tous les sens avec ma tronçonneuse ».\nUne telle perspective ayant de quoi effrayer le hacker le plus endurci, Phillip Lougher a dû remballer la majeure partie de son code. Il a sauvé ce qui pouvait être sauvé (surtout du nettoyage de code) et il a annoncé qu'il allait s'atteler à la modification des fichiers désignés par Linus. Comme cette modification touche plusieurs architectures il faudra attendre un peu pour pouvoir profiter de l'algorithme de compression lzma dans Squashfs.\nBtrfs, le futur système de fichiers star de nos distributions puisqu'il a vocation à remplacer ext4, a été largement amélioré dans cette nouvelle version du noyau.\nUne fonction très appréciable de btrfs, c'est la possibilité de faire des instantanés du système (snapshots). Jusqu'à présent il y avait des limitations en terme de sous-volume bootable ce qui réduisait l'intérêt du système. Avec le 2.6.34 cette limitation saute et il deviendra bien plus facile pour les distributions de faire des instantanés pour sécuriser une mise à jour en permettant de redémarrer sur un sous-volume sain.\nLa fonction de défragmentation intégrée à btrfs permet maintenant de défragmenter des parties d'un fichier dans un certain intervalle au lieu de devoir tout défragmenter. Au niveau de la compression, là aussi on accède à plus de granularité puisqu'on peut compresser certains fichiers (avec force_compress:1) sans devoir imposer cette option à tout le volume.\nEnfin un appel système permettant de chercher des fichiers modifiés dans le volume (c'est l'ioctl find-new) a été ajouté dans les fonctions de btrfs. Il permettra aux programmes en espace utilisateur de l'utiliser pour retrouver rapidement tout fichier ayant été modifié récemment. Chris Mason a fait un test sur un dépôt Git contenant toutes les sources du noyau en modifiant un unique fichier. Un petit "find -newer" lui sort le fichier en 9 secondes alors le nouveau ioctl de btrfs se contente de 0.04 secondes.\nUn autre système de fichier, XFS, a lui aussi été amélioré substantiellement dans le noyau 2.6.34. Les améliorations sont toutes purement internes et les utilisateurs devraient uniquement en sentir les effets en constatant une amélioration du débit des entrées/sorties. Par exemple l'algorithme chargé de placer les inodes a été complètement réécrit, ce qui augmente les performances de lecture des métadonnées. Le code permettant d'agrandir un volume XFS a été lui aussi réécrit pour être plus générique et supprimer des limitations internes. Selon Christoph Hellwig, mainteneur du système de fichiers XFS, cela facilitera l'inclusion de la future fonction de contraction des volumes.\nLe système de fichiers ExoFS, qui était entré dans le noyau 2.6.30, et qui utilise le nouveau mode de stockage réseau OSD (Object Storage Device) peut maintenant fonctionner en mode RAID 0. Cette amélioration décrite dans le message de commit permet aussi de définir des "striping-groups", c'est à dire que seuls certains disques du système utiliseront l'option de striping RAID 0. Si l'on en croit le message de Boaz Harrosh la prochaine étape prévue pour ExoFS sera le support des modes RAID 5 et RAID 6.\nL'interface utilisée pour la virtualisation, virtio, a été améliorée par l'ajout du module vhost_net. Ce module, écrit par Michael Tsirkin, implémente un périphérique en mode caractère afin de réduire le nombre d'appels systèmes (syscalls) entre l'hôte et le système invité. On gagne ainsi en performances réseau sans devoir changer quoi que ce soit sur le système invité puisque vhost_net élimine 4 syscalls pour chaque paquet échangés. D'après la page consacré à vhost_net sur le site de KVM, les performances réseau du guest, testées avec TCP_STREAM, passent de 72 Mo/s à 78 Mo/s (81 Mo/s en natif). Pour le test TCP_RR on passe de 395 µs/transaction à seulement 86 µs/transaction (48 µs/transaction en natif).\nSi vous vous intéressez aux cartes graphiques Intel, alors vous serez contents d'apprendre que le pilote KMS du noyau 2.6.34 intègre d'ores et déjà le support du nouveau coeur graphique de Sandy Bridge. Ce processeur qui sortira en fin d'année incorporera le coeur graphique sur le même die que le CPU classique. En effet, pour réduire la consommation et utiliser le "budget transistor" que permet la loi de Moore, la mode est à la "fusion" des CPU et des GPU. Intel, souvent critiqué pour la faible puissance de ses coeurs graphiques, promet que Sandy Bridge permettra d'au minimum doubler les performances actuelles.\nPour les cartes existantes le travail a surtout porté sur la gestion efficace de l'énergie (-0.8W en mode économie) et sur la fonction d'overclocking des puces Ironlake présentes dans les Core i5 et Core i7.\nHabitué à la maintenance des outils de monitoring du noyau - il travaille aussi sur SystemTap - le développeur Masami Hiramatsu a décidé d'optimiser le code des kprobes. Il s'agit de sondes qui sont injectées dans le noyau afin de générer des informations et des statistiques sur son fonctionnement interne. La documentation explique que les kprobes utilisent, sur les machines x86 et x86-64, l'instruction breakpoint pour intercepter les informations voulues. Dans son message de commit Masami Hiramatsu explique qu'il a utilisé un jump au lieu du breakpoint. Cela consomme un petit peu de mémoire en plus mais le gain en performances est très sensible puisque le coût d'un kprobe passe, sur un Xeon 2.33 GHz en mode 64 bits, de 0,91 microsecondes à seulement 0,06 microsecondes.\nIntroduit dans le 2.6.31 l'outil perf est chargé du tracing dans le noyau Linux. Dans cette version perf peut maintenant générer également des statistiques sur l'utilisation des verrous. C'est Hitoshi Mitake qui a soumis le patch permettant l'utilisation de cette toute nouvelle commande "perf lock".\nDans le 2.6.34 on trouve également un support des scripts écrits en Python pour perf. Alors qu'avant seul Perl était disponible, Tom Zanussi a écrit le patch ajoutant le scripting Python. Plusieurs scripts sont déjà prêts à être utilisés et vous les trouverez dans tools/perf/scripts/python. Une documentation complète est également disponible.\nToujours en chantier le pilote KMS Radeon intégré dans le noyau 2.6.34 supporte maintenant les cartes de type Evergreen R800 (toutes les cartes connues sous le nom commercial HD 5000). Ce support est très préliminaire puisqu'il ne permet pas encore l'accélération 2D/3D mais au moins les cartes sont reconnues. Le développeur Alex Deucher a détaillé sur son blog les 13 patchs qui ont été nécessaires à cette intégration des cartes Evergreen dans le noyau. La publication par AMD des spécifications des cartes R800 va certainement permettre au pilote libre d'avancer et les patchs implémentant l'accélération sont déjà disponibles pour la prochaine version. En ce qui concerne les cartes plus anciennes, la gestion de l'énergie est améliorée, le support audio HDMI arrive pour les R700 et un vérificateur de commandes (Command Checker) est maintenant activé pour les cartes R600/700 afin de renforcer la fiabilité et la sécurité.\nLe code gérant la mémoire virtuelle a été amélioré pour faciliter la montée en charge. Ce patch, celui-là même qui contenait le fameux bug résolu par Linus, change la complexité algorithmique du parcours des pages mémoires anonymes (celles qui sont créées à la demande d'un processus unique). Avant on était en 0(n) (complexité linéaire) et avec le patch de Rik van Riel, on passe en complexité constante 0(1). Le message de commit indique que sur le benchmark AIM7, qui sert à mesurer le débit de jobs lancés par des utilisateurs, on passe de 9 700 users à 29 700 users sur la même machine ayant 16 Go de mémoire.\nLe code de l'ordonnanceur des entrées/sorties CFQ a été retouché afin d'améliorer encore un peu ses performances. En premier lieu l'algorithme plaçant les requêtes dans les listes d'attente a été modifié afin de prendre en compte les disques SSD. Jusqu'à présent CFQ groupait les requêtes sans tenir compte du fait que le périphérique était de type rotatif (disque dur) ou pas (SSD). Maintenant l'algorithme sait qu'il ne doit pas tenir compte de la localisation de la requête pour les disques SSD et le placement dans la liste d'attente devient donc plus équitable qu'avant.\nEnsuite le code de gestion des périphériques rotatifs permet, grâce à ce patch, de mieux distinguer les cas de requêtes séquentielles par rapport aux requêtes nécessitant de déplacer aléatoirement la tête de lecture (seek). L'heuristique est plus performante et elle garde maintenant un historique des 32 dernières requêtes pour améliorer encore plus la précision.\nEnfin une optimisation simplissime pour réduire l'empreinte mémoire a été effectuée sur la structure cfq_queue dans le cas des noyaux 64 bits. La taille passe ainsi à 256 octets ce qui permet de la faire tenir plus facilement dans le cache de l'allocateur kmem_cache.\nLe module lkdtm, qui propose une fonctionnalité rarement utile pour l'utilisateur de base puisqu'il sert à faire planter le noyau, a été amélioré dans cette nouvelle version de Linux. Utile aux développeurs pour tester la fiabilité des dumps générés après un crash, ce module s'utilise en passant des arguments lors du chargement (au moment du insmod). Maintenant on peut également l'utiliser avec debugfs qui est un système de fichier spécial utilisé pour le déboguage. La documentation indique qu'on peut faire joujou en demandant des plantages différents du type PANIC ou bien CORRUPT_STACK ou encore WRITE_AFTER_FREE. Des heures de fous rires en perspective !\nUne flame war d'un fort beau gabarit (↑)\nLe pilote libre Nouveau, écrit pour remplacer le binaire propriétaire des cartes graphiques NVidia, a été intégré dans la précédente version du noyau Linux. Depuis cette intégration l'interface externe de Nouveau a changé et tout le code qui existait en espace utilisateur est devenu incompatible avec l'ancienne API. Pour utiliser Nouveau dans le noyau 2.6.34 il faut donc obligatoirement avoir une version compatible de la libdrm (Direct Rendering Manager library).\nEn soi ce changement n'est pas suffisamment important pour nécessiter un paragraphe explicatif mais ce qui est intéressant c'est qu'il a provoqué des échanges animés (lire flame war) entre Linus et les responsables du patch.\nCette conversation, et l'argumentation utilisée par les uns et les autres, offre une perspective sur diverses questions intéressantes: Quel est le but de la branche -staging ? L'inclusion par les distributions de pilotes absents de Linux est-elle une bonne chose ? Faut-il versionner les API ?\nC'est pour ça qu'il m'a semblé utile de traduire les mails les plus significatifs de cette polémique sur la LKML. Je me suis parfois permis de fusionner plusieurs extraits de mails en un seul paragraphe pour condenser les échanges.\nCe qu'il faut bien garder en mémoire, c'est que le pilote Nouveau est encore dans la branche -staging de Linux. Cette branche, très spécifique, est destinée à accueillir les pilotes encore en développement et qui avant cela stagnaient un peu partout sur le net. Cela permet une centralisation de ces pilotes au sein de la branche principale du noyau (mainline) et cela incite à un développement plus coordonné au lieu d'avoir du code dispersé de tous les côtés.\nLa branche -staging possède des règles précises mais, à lire le texte de Greg Kroah-hartman, il n'est pas écrit noir sur blanc qu'un changement d'interface externe avec l'espace utilisateur est autorisé. Toutefois l'interprétation qui est généralement retenue est qu'il est permis de changer une telle API externe puisque les pilotes dans -staging sont justement là pour être lourdement modifiés et rejoindre les standards de qualité du noyau.\nC'est pour cette raison que les développeurs de Nouveau et de la couche graphique du noyau ont été fort surpris de la réaction de Linus suite à l'annonce du changement d'API:\n« Ce changement rend impossible le _test_ d'un nouveau noyau. Upgrader en même temps X et le noyau de façon forcée n'est pas envisageable, pleins de gens utilisent juste une distribution quelconque (Fedora 12 dans mon cas) et vous venez juste de tout casser. Nous ne pouvons pas casser ainsi la configuration des gens. Ce pilote est, que vous le vouliez ou non, utilisé par Fedora 12 (et probablement par d'autres distributions). Il est peut-être défini comme "staging" mais cela ne change pas le fait qu'il est utilisé en production par des grosses distributions ».\nLinus a été particulièrement énervé par cette modification car elle l'empêche, lui comme tous les autres contributeurs potentiels, de faire des tests avec l'outil bisect de Git. Cette fonction est fort utile puisqu'elle permet de retrouver relativement facilement le patch fautif ayant introduit un bug:\n« Est-ce qu'il y a une version de la libdrm qui peut gérer les _deux_ API pour permettre aux gens d'utiliser bisect ? C'est à dire, même si on a une version récente de libdrm est-ce qu'elle marchera aussi avec le vieux noyau ? La rétro-compatibilité c'est super important ».\nÀ la suite de cette tirade Jesse Barnes lui a répondu:\n« Bien sûr que la rétrocompatibilité c'est important. Mais ce pilote est clairement du type "À utiliser à vos risques et périls". Cela signifie que tant qu'il se trouve en staging il est obligatoire de garder une synchronisation noyau/userspace si on veut changer le noyau.\nMaintenant si le fait d'être en staging ne permet plus de changer l'API quand on a besoin de le faire alors il n'y aura pas d'autre choix que de retirer le pilote du noyau et de ne le soumettre à nouveau pour inclusion qu'une fois que l'interface sera stable ».\nLinus n'a pas vraiment apprécié cette obligation de changer simultanément le noyau et la libdrm puisqu'elle réduit drastiquement le nombre de testeurs des nouveaux noyaux :\n« Le fait est que vous n'avez même pas _essayé_ de garder la compatibilité.\nSérieusement qu'est-ce que vous voulez que je fasse dans cette situation ? Je ne vais pas sortir un noyau que je ne peux pas tester. Donc si je ne peux pas avoir une libdrm qui fonctionne dans mon environnement je vais _devoir_ faire un revert sur le patch que vous m'avez demandé d'inclure.\nVraiment. Regardez ça de mon point de vue. Regardez ça du point de vue de n'importe quel développeur du noyau. Ce serait complètement irresponsable pour moi de sortir le 2.6.34 sans avoir eu la possibilité de le tester moi-même sur ma propre machine ».\nCette fois c'est Ben Skeggs qui a tenté de raisonner Linus:\n« C'est *toi* qui as poussé pour que Nouveau intègre la branche staging avant que ses développeurs ne soient prêts. Nous n'avons aucune intention de garder des API foireuses quand elles ne répondent pas aux besoins. L'idée même de staging c'est de permettre ce genre de chose alors pourquoi cette surprise ? Je suis d'accord que c'est galère de faire un bisect mais c'est loin d'être une fonction utilisée par des masses de gens ».\nMatthew Garrett a enfoncé le clou:\n« Quand tu a demandé que Nouveau soit inclus les gens t'ont dit explicitement que l'interface était instable et que les applis en espace utilisateur devraient s'adapter. Tu as demandé que ce soit incorporé quand même et maintenant tu n'es pas content parce que l'interface a changé et que l'espace utilisateur doit s'adapter ? ».\nRéponse immédiate de Linus:\n« Est-ce que c'est si dur que ça de comprendre les règles basiques de développement du noyau ?\nNouveau était déjà dans Fedora 12. Les gens peuvent se cacher derrière tous les "c'est juste en staging" et les "tu nous l'as demandé" qu'ils veulent mais cela ne change rien au simple fait fondamental: Les distributions devraient s'assurer que les pilotes sont présents en upstream. Les gens dépendent de ces pilotes.\nÀ ce propos j'espère me débarrasser de ma carte nVidia merdique très bientôt...mais cela ne change pas mon objection. Je n'ai pas demandé que Nouveau soit mergé en staging pour le plaisir. Je l'ai demandé parce qu'une distribution majeure l'utilisait déjà ».\nIngo Molnar a fait quelque peu dévier la conversation en soulignant le fait qu'un changement d'API avec l'espace utilisateur était presque toujours une grave erreur. Selon lui c'est le résultat d'une tendance à créer des interfaces inutiles entre des composants:\n« Ma conclusion est claire comme le cristal. Changer une API d'un coup est une erreur, c'est dommageable, cela limite la base des développeurs, cela limite la base des testeurs, c'est une perte de temps et d'efforts. C'est une mauvaise décision technique. C'est du masochisme. Il y a peu de règles inconditionnelles dans le monde du libre mais cela en est une.\nTout ça est souvent le résultat d'une _autre_ mauvaise décision technique : la sur-modularisation.\nXorg, mesa/libdrm et les pilotes DRM du noyau ne représentent pas vraiment trois ou quatre projets séparés mais un seul méta-projet abstrait ».\nStéphane Marchesin, le créateur du projet Nouveau, lui a répondu que c'était facile à dire mais qu'aucune solution technique réelle n'était vraiment envisageable à court terme :\n« Tu sais quoi ? Tous les développeurs des pilotes graphiques sont d'accord sur ce diagnostic, mais il n'y a pas de solution évidente. Voici les interfaces qui sont impliquées dans le problème:\n- L'interface drm\n- L'interface d'accélération de X.Org\n- L'interface Mesa\nToute solution implique de fusionner ensemble deux ou plus de ces composants afin d'enlever une interface ».\nStéphane a ensuite examiné les trois paires possibles de composants qu'on pouvait essayer de fusionner (drm-xorg; drm-mesa, xorg-mesa). Après avoir souligné tous les problèmes techniques que cela posait il a conclu que ce n'était pas pour demain :\n« Dans un futur lointain je peux seulement espérer que toute l'accélération (2D et 3D) se fera seulement via OpenGL. Cela voudra dire qu'on peut supprimer entièrement DDX. Nous parlons de ça depuis environ 6 ans mais c'est encore loin d'être le cas ».\nAprès ces considérations prospectives la conversation est revenue sur le sujet chaud. Sans autre solution, Linus a dû rapatrier les sources de libdrm sur sa machine et bidouiller pour pouvoir tester le noyau incluant le patch de changement d'API de Nouveau. Évidemment cette contrainte, et surtout la perte d'autres testeurs potentiels qu'elle implique, l'a fait grogner:\n« Franchement je persiste à penser que je ne devrais pas avoir à faire ce genre de contorsions. Le versionnage devrait être prévu. Et je persiste aussi à penser que "staging" n'est pas une excuse pour dire "c'est un truc tout pourri et on s'en fout ».\nLes échanges auraient pu s'arrêter là mais Daniel Stone a cru bon d'essayer de tirer un bilan et son mail a remis le feu aux poudres:\n« Peut-être que la leçon que nous devons tirer de tout ça est: "Si les développeurs ne veulent pas merger quelque chose parce que ce n'est pas encore prêt et qu'ils prévoient de gros problèmes dans le futur alors il faut les écouter au lieu de se foutre de leur avis" ».\nJeff Garzik lui a retorqué:\n« Le cheval s'est échappé de l'écurie quand Fedora a sorti une version stable avec Nouveau dedans, pas quand Linus l'a mergé dans sa branche ».\nDavid Miller a lui aussi contesté le jugement de Daniel Stone:\n« Si nous n'avions pas incorporé le pilote alors les utilisateurs de Fedora n'auraient pas du tout été capables de tester les nouveaux noyaux amont.\n< Si on réfléchit à la situation il n'y a qu'une et une seule action qui aurait permis que tout se passe bien: Incorporer le pilote en upstream et ne pas changer l'API externe. En fait j'irai même jusqu'à dire qu'à partir du moment ou Nouveau est arrivé dans Fedora et a été activé par défaut alors on aurait du geler l'interface externe ».\nEn définitive l'origine de cette flame war est à chercher dans le fait que plusieurs développeurs ont considéré qu'après l'incorporation dans Fedora puis dans Linux le changement d'API avait été introduit de manière désinvolte et sans tenir compte de l'écosystème global de Linux. C'est Fedora qui a été pointé du doigt pour avoir oublié cette règle cardinale du modèle de développement du libre: Les changements doivent se faire en amont sinon tout le monde en pâtit.\nTed Ts'o a tenté de tirer la morale de cette histoire dans deux mails sévères (fusionnés ici):\n« Quelqu'un chez Red Hat/Fedora a pris la décision de rendre disponible ce pilote dans une distribution très populaire afin d'avoir plus de retours de tests. Et cela a été fait sans mettre en place le versionnage nécessaire pour que les développeurs puissent tester les nouveaux noyaux. C'est, selon moi, un truc anti-social qui a été fait là.\nLa raison pour laquelle ce thread a fait autant de traffic c'est qu'il est fondamentalement au sujet des normes communautaires. Il y a plein de choses qui ne sont pas illégales mais qui sont en même temps anti-sociales.\nCe qui est arrivé c'est que quelqu'un a dit "Je veux expérimenter sur un paquet d'utilisateurs mais je ne veux pas fournir les efforts pour faire ça de manière correcte. Je veux prendre un raccourci. Je ne veux pas me préoccuper du fait qu'il sera impossible de tester les nouveaux noyaux sans utiliser des combinaisons de patches à la Frankenstein entre Fedora 13 et Fedora 12".\nLe vrai problème c'est que Fedora et la communauté de Nouveau agissent de façon incroyablement égoïste. Ils voient les choses uniquement de leur petit point de vue et se fichent des inconvénients qu'ils infligent au processus de développement du noyau et aux autres développeurs du noyau.\nC'est _légal_ cependant c'est anti-social.\nFedora n'est pas la seule bien entendu. Ubuntu a fait ça également, et pire même, avec des pilotes binaires. Mais ce n'est pas parce que Ubuntu a fait pire qu'il ne faudrait rien dire sur Fedora dans ce cas là ».\nPour conclure sur ce psychodrame, et malgré le ton abrasif de Ted Ts'o, je pense qu'il faut ramener les chose à une plus juste proportion. Le ton de la LKML est très franc, brutal parfois, car les hackers du noyau ne sont pas des droïdes de marketing pratiquant la langue de bois. Cela n'empêche pas les gens de travailler ensemble et Linus, en dépit de sa gueulante, a incorporé le patch de Nouveau, testé son noyau et continué a sortir les versions candidates de son cycle habituel.\nCette poussée de fièvre s'explique en partie par le fait que le projet Nouveau est scruté de très près. Pour beaucoup de gens Nouveau représente enfin la solution qui va permettre le support libre des cartes graphiques d'un acteur majeur du marché.\nJe crois que c'est Mike Galbraith qui a trouvé le mot de la fin approprié:\n« Si on veut voir les choses du bon côté tout ce vacarme a envoyé un message très positif à l'équipe de développement de Nouveau: Hé les mecs, votre travail est important !\nÀ leur place je serai fier comme un paon :) ».\nCôté statistiques ce noyau a vu l'intégration d'un peu moins de patchs par rapport aux précédents. L'article récapitulatif pour le 2.6.34 du site LWN est disponible et on pourra également se reporter au site dédié aux statistiques du noyau Linux.\nPour le noyau 2.6.34, le nombre de patchs était de 9 100 au 5 mai (10 863 pour le 2.6.33). On constate donc une certaine réduction du nombre de patchs lors de ce cycle (bien visible sur ce graphique). À priori cela ne s'explique pas par la fermeture anticipée de la période de merge car Linus a accepté par la suite les demandes de merges des contributeurs. Peut-être est-ce simplement qu'il y avait moins de nouveautés à intégrer cette fois-ci ?\nSi on fait un bref récapitulatif des huit derniers noyaux, cela donne :\n2.6.27 => 10 625 patches\n2.6.28 => 9 045 patches\n2.6.29 => 11 696 patches\n2.6.30 => 11 984 patches\n2.6.31 => 10 881 patches\n2.6.32 => 10 997 patches\n2.6.33 => 10 863 patches\n2.6.34 => 9 100 patches\nEn nombre de développeurs, le 2.6.34 aura vu les contributions de 1 129 personnes différentes (1 201 pour le noyau 2.6.33). Parmi ces développeurs 263 sont des primo-contributeurs (postant un patch pour la première fois depuis le 2.6.12-RC2 qui est le point de départ des statistiques du site remword). En moyenne ces 1 129 développeurs ont proposé 7 patchs (mais la "traine" est assez longue puisque 552 personnes n'ont posté qu'un seul patch).\nEn ce qui concerne les futures nouveautés des prochaines versions du noyau on peut se tourner vers la page spécifique de la Fondation Linux.\nEn 2008 un travail de longue haleine avait été entrepris par les développeurs de Linux pour supprimer du code du noyau le fameux verrou géant (BKL pour Big Kernel Lock). Ce verrou bride les performances des machines multiprocesseurs et tout le monde souhaite avec ferveur sa disparition.\nDeux ans plus tard le travail se poursuit et Arnd Bergmann a récemment annoncé une nouvelle offensive pour faire reculer l'hydre du BKL.\nSa branche Git s'intitule bkl-removal et Arnd a travaillé sur des parties du noyau assez diverses. D'autres développeurs, comme Frédéric Weisbecker, ont participé à la discussion et ont proposé des stratégies pour faciliter la transition (même Linus s'est invité pour indiquer, crûment, sa préférence).\nParmi les nouveautés à attendre dans les prochaines versions du noyau on trouve ainsi un nouveau mutex (bkldev_mutex) qui est posé dans la couche en mode bloc (block layer) sur tous les pilotes qui faisaient auparavant appel au BKL.\nDans TTY c'est également un mutex local (le "Big TTY Mutex") qui a été posé sur ce sous-système en remplacement du Big Kernel Lock global.\nLes appels aux fonctions ioctl() et llseek() qui reposaient dans certains cas sur le BKL ont été audités et les fonctions ont été nettoyées dans la perspective d'une éradication complète dans l'avenir.\nLe code présent dans init/main.c et qui utilisait sans raison particulière le verrou global a été retiré.\nOutre le travail de fond d'Arnd Bergmann il y a également Andi Kleen qui a travaillé sur la couche USB et Frédéric qui se penche sur la situation de procfs.\nUn article du site LWN évoque également la possibilité d'une option de configuration CONFIG_BKL qui permettrait, peut-être dès le noyau 2.6.35, d'enlever complètement le support du verrou géant du noyau. C'est une bonne méthode pour repérer facilement tout ce qui repose encore sur le BKL et qui ne marche plus quand on l'enlève.\nPour documenter tous ces nouveaux efforts d'éradication du BKL une page spéciale du wiki de kernelnewbies a été créée. Cette page vous permettra d'approfondir le rapide survol esquissé ici et, peut-être, vous incitera à vous lancer à votre tour dans le combat glorieux contre le BKL !\nLes nouveautés du noyau 2.6.34 (70 clics)\nLes articles de H-Online (7 clics)\nLes prévisions pour l'avenir de Linux (15 clics)\nPosté par 2PetitsVerres le 17/05/10 à 13:08 . Évalué à 9.\nTous ceux qui vont dire merci patrick_g< t'es trop génial (ou approchant) je les moinsse.\nPosté par monde_de_merde le 17/05/10 à 13:16 . Évalué à -8.\nmerci patrick_g< t'es trop génial (ou approchant) je les moinsse.\nPosté par Anonyme le 17/05/10 à 13:38 . Évalué à -10.\nmince patrick_g j'en ai marre de la longueur de ces news, c'est imbuvable.\n[^] # Réponse à prendre au 1er degré\nPosté par tom120934 le 17/05/10 à 15:07 . Évalué à 5.\nJ'ai souvent tendance à remercier patrick_g pour la qualité de ses news / journaux, mais là je dois reconnaître qu'il fait très fort.\nC'est le premier article de sortie d'un nouveau kernel que je lis (oui ok honte sur moi) et j'ai été _ravi_. Oui la répartie des kernel hackers est distrayante (Linus en tête) et c'est ainsi plus enthousiasmant/facile à lire. Mais au delà de ça, les explications techniques sont un mine d'infos pour un profane (mes années de C/C++ sont loin derrière moi) et me fait encore plus apprécier le travail caché derrière ma distrib.\nDonc, véritablement au 1er degré : MERCI POUR LE POISSON !\nLâchez vos moinssages :)\nPosté par rewind le 17/05/10 à 14:12 . Évalué à 10.\nPosté par Colin Pitrat (site Web personnel) le 17/05/10 à 15:40 . Évalué à 5.\nTout à fait d'accord, c'est tellement évident que patrick_g est un faux compte et qu'il y a une armée de journalistes techniques derrière ... C'est du stakhanovisme !\nPosté par JP Martin le 18/05/10 à 23:39 . Évalué à -2.\nEt c'est avec un réel plaisir que je lis son journal à chaque sortie de noyau.....\nMerci patrick_g pour ton formidable travail de pigiste\nNB : vivement le prochain\nPosté par windu.2b le 19/05/10 à 00:42 . Évalué à 7.\nJ'ai déjà lu des articles de fond de journalistes renommés être bien moins creusés que ça...\n# Le jeu du lundi\nPosté par patrick_g (site Web personnel) le 17/05/10 à 13:54 . Évalué à 10.\nToi aussi cherche le mot magique caché dans la dépêche : https://linuxfr.org/comments/1125652.html#1125652\n[^] # Re: Le jeu du lundi\nPosté par Jehane le 17/05/10 à 13:58 . Évalué à 5.\nPosté par patrick_g (site Web personnel) le 17/05/10 à 14:14 . Évalué à 8.\nEn ROT13 alors.\nPosté par khivapia le 17/05/10 à 15:07 . Évalué à 10.\ncerzvrerf yrggerf qrf cerzvref cnentencurf qr yn cnegvr "Ra oers"\nPosté par imr le 17/05/10 à 17:38 . Évalué à 9.\nHoly Cow, batman! Je n'aurais jamais trouvé.\nEt les 3 "L" à la fin, pour "le logiciel libre", c'est carrément subversif, ça dénonce grave. Il va avoir des problèmes avec les GNU/commissaires politiques.\nPosté par gnumdk (site Web personnel) le 17/05/10 à 13:55 . Évalué à 10.\nJe ne sais pas ce qui est le plus intéressant, la partie technique ou la partie sociale de la nouvelle :)\nEn tout cas, je ne sais plus quel "kernel hacker" (1) définissait Linus comme "le dictateur bienfaisant" mais cela semble proche de la réalité :)\n(1) C'est dans la vidéo "The code", la monsieur qui explique ce qu'est un noyau.\n[^] # Re: Dallas...\nPosté par Zenitram (site Web personnel) le 18/05/10 à 05:53 . Évalué à 9.\n"le dictateur bienfaisant" mais cela semble proche de la réalité :)\nIl y a une grosse différence très intéressante sur les dictatures dans le cas du libre : si suffisamment de monde n'est pas content du dictateur qui ferait des choses débiles, il peut élire un autre qui devra montrer qu'il est meilleur au final et amène plus de monde avec lui.\nEt ça, c'est quelque chose qui n'existe pas dans la vraie vie où on a des dictateurs... Dictateur, oui, mais qui peut dégager rapidement si il fait trop n'importe quoi, les avantages de la dictature (réactivité etc...) sans (trop) les inconvénients en quelque sorte, que du bonheur!\nPosté par Boa Treize (site Web personnel) le 18/05/10 à 09:52 . Évalué à 5.\n> Dictateur, oui, mais qui peut dégager rapidement si il fait trop n'importe quoi\nÇa dépend comment le projet est organisé. Avec une infrastructure moderne décentralisée à base de Git entre autres, c'est tout à fait vrai. Dans certains vieux projets où toute l'infrastructure (serveurs, mailing lists) est dans les mains de quelques uns, les choses sont beaucoup plus compliquées. On peut toujours forker, mais il faut repartir de presque zéro.\nPosté par reno le 18/05/10 à 12:03 . Évalué à 5.\nCe qui est amusant, c'est que Linus a fortement poussé (*) pour justement décentraliser l'infrastructure autour de Linux: un "dictateur" qui soutient les outils qui permettraient de le remplacer en fait..\n*: bon il faut dire qu'il y a eu une période ou Linus était considéré comme un goulet d'étranglement pour Linux (je n'ose même pas imaginer le nombre de patch qu'il devait recevoir chaque jour): ca fait une bonne motivation pour décentraliser le système..\nPosté par windu.2b le 18/05/10 à 13:31 . Évalué à 10.\nSi on se réfère au sens qu'avait le mot "'dictateur" sous la Rome antique, on est déjà un peu plus dans le vrai : un homme, désigné par le Sénat, qui reçoit les pleins pouvoirs de ce dernier, mais peut le perdre tout aussi vite et qui, de toute façon, ne l'a que pendant une durée limitée (pouvant être reconduite).\nLinus est un dictateur dans le sens où la communauté le reconnait comme le maître du noyau Linux et c'est à lui que sont confiés les décisions finales (commit des patches, ...). Mais si demain la communauté venait à en choisir un autre, Linus ne pourrait pas faire grand chose contre ça...\nPosté par FantastIX le 19/05/10 à 18:33 . Évalué à 2.\nDisons que dans la Rome antique, dégager le dictateur en cours s'avérait souvent fatal pour lui... Heureusement on a quelque peu progressé depuis ;) .\nPosté par Gof (site Web personnel) le 18/05/10 à 19:37 . Évalué à 2.\nSi suffisamment de monde n'est pas content du dictateur, il y peut y avoir une révolution.\nPosté par exolin le 17/05/10 à 14:08 . Évalué à 2.\nJ'attendais l'article avec impatience après avoir eu l'écho des «soucis » qui s'étaient produits avec nouveau. Après lecture le problème reste assez flou: il est demandé aux développeurs de réaliser tout changement dans l'interface externe avant l'inclusion dans le noyau?\nSinon est-il prévu un jour l'accélération 3D pour le pilote radeon (pour une vielle X800 notamment)?\nBon article plaisant à lire comme toujours :)\nPosté par glisse le 17/05/10 à 14:25 . Évalué à 4.\nl'accel 3D sur X800 est dispo dans mesa depuis 5-6ans de memoire ...\nPosté par Thomas Douillard le 17/05/10 à 15:11 . Évalué à 1.\nPour quelqu'un qui n'est pas à fond dedans, c'est quoi les sous entendu de ta réponse ?\nPosté par ʭ ☯ le 17/05/10 à 15:17 . Évalué à 8.\nQue tu n'as probablement pas essayé un logiciel 3D dans ta distribution favorite depuis 5 ans ;-)\nPosté par glisse le 17/05/10 à 16:27 . Évalué à 3.\nAu debut je voulais faire une blague sur la necessite de faire des apt-get update/upgrade un peu plus souvent puis je me suis dis que c'etait pas drole. Cela etant dis je suis sidere que des gens ne se rendent pas compte que des drivers 3d existe, 5 ans apres. En faite je me demande ou les gens vont chercher leur informations ...\nJ'avais aussi oublie de remercier Patrick pour sa depeche. Allez bonne journee a tous.\nPosté par ʭ ☯ le 17/05/10 à 15:16 . Évalué à 9.\nC'est le module DRI r300 qui les gère, ça fait exactement depuis le 19 Mai 2005 que la X800 est annoncée comme fonctionnant sans blocages - donc 5 ans et 2 jours!\nSource : http://r300.sourceforge.net/\nPosté par Ph Husson (site Web personnel) le 17/05/10 à 23:02 . Évalué à -1.\nL'IPoT fait des ravages. (ou alors un an = 365jours ?)\nPosté par exolin le 17/05/10 à 16:47 . Évalué à 2.\nPosté par VINDICATORs le 18/05/10 à 16:04 . Évalué à 1.\nFedora intègre les dernières évolution du pilote xorg-x11-drv-ati "radeon" avec mesa-dri-drivers depuis Fedora 12.\nL'accélération est matériel avec les évolutions de mesa qui intègre une bonne partie des développement de Galium3D.\nTout n'est pas parfais, mais cela avance dans le bon sens.\nJe parle bien sur du pilote en version 2.6.13, de mesa 7.7 et +.\nPar contre pour Ubuntu...\nPosté par Tsomi le 17/05/10 à 15:39 . Évalué à 6.\n>> et bien maintenant vous devrez attendre le 2.6.35.\n>> eh bien maintenant vous devrez attendre le 2.6.35.\n>> Tu a demandé que ce soit incorporé quand même et maintenant tu n'est pas content\n>> Tu as demandé que ce soit incorporé quand même et maintenant tu n'es pas content\n>> C'est *toi* qui a poussé pour que Nouveau intègre la branche staging\n>> C'est *toi* qui as poussé pour que Nouveau intègre la branche staging\nEt sinon, dépêche de qualité, comme d'hab.\nPosté par patrick_g (site Web personnel) le 17/05/10 à 15:52 . Évalué à 3.\nFautes corrigées, merci (sauf la première pour laquelle je ne suis pas convaincu, il y a une règle officielle là-dessus ?).\nPosté par Tsomi le 17/05/10 à 16:13 . Évalué à 1.\nAh, dans « l'officiel » je trouve bien ça :\n...mais je dois avouer que je ne trouve rien de l'Académie qui réprouve explicitement l'orthographe « et bien ». Ça m'étonne, venant d'eux !\nDonc ça sera un... au temps pour moi :)\nPosté par Tsomi le 17/05/10 à 16:18 . Évalué à 2.\nArf, Templeet n'a pas l'air trop copain avec les liens à rallonge de Google books, et tinyurl ne s'en sort pas mieux.\nOn va dire Dictionnaire de l'Académie française, Volume 1, page 186, alors.\nPosté par windu.2b le 17/05/10 à 16:26 . Évalué à 6.\nDans le genre "officiel", je peux te proposer ce passage d'une (célèbre) fable de La Fontaine :\nPosté par patrick_g (site Web personnel) le 17/05/10 à 16:49 . Évalué à 4.\nIl n'y a pas plus officiel que La Fontaine donc je rends les armes.\nPosté par Renault (site Web personnel) le 17/05/10 à 21:37 . Évalué à 1.\nPetite faute « Fedora n'est pas la seule bien entendu. Ubuntu a fait ça également, et pire même, avec des pilotes binaires. Mais ce n'est pas parce que Ubuntu à fait pire qu'il ne faudrait rien dire sur Fedora dans ce cas là ». »\nPosté par patrick_g (site Web personnel) le 17/05/10 à 23:06 . Évalué à 2.\nCorrigé. Ah vivement un beau correcteur grammatical sous Linux.\nPosté par ʭ ☯ le 18/05/10 à 10:30 . Évalué à 7.\nEn tout cas, il est pointilleux, celui de Linuxfr! Le jour où j'ai un texte à faire relire, je le mets dans un journal ;-)\nPosté par liberforce (site Web personnel) le 18/05/10 à 21:08 . Évalué à 2.\nbreackpoint => breakpoint\nPosté par patrick_g (site Web personnel) le 18/05/10 à 21:53 . Évalué à 2.\nPosté par Naha (site Web personnel) le 17/05/10 à 16:57 . Évalué à 2.\ns/pleins/plein/ (exemple : « Il y a plein de pichets pleins »)\ns/à besoin/a besoin/\ns/du le Big Kernel Lock/du Big Kernel Lock/\nPosté par patrick_g (site Web personnel) le 17/05/10 à 16:59 . Évalué à 2.\nPosté par Donk le 17/05/10 à 18:00 . Évalué à 2.\nSection "Système de fichiers Ceph", le lien vers le fichier odp n'est pas bon.\nAinsi que le lien vers la vidéo de Dailymotion dans la section "VGA-Switcheroo"\nPosté par patrick_g (site Web personnel) le 17/05/10 à 18:26 . Évalué à 2.\nC'est corrigé. Encore Templeet qui avait mangé des balises.\nPosté par Dreamkey le 17/05/10 à 18:03 . Évalué à 1.\nPartie "RC-4" : Borislav pour imaginer d'où pouvait\nPartie "Une flame war" : autant de traffic c'est qu'il est fondamentablement au sujet\nMais je n'ai pas encore pu tout lire, peut-être d'autres se cachent :p\nPosté par patrick_g (site Web personnel) le 17/05/10 à 18:29 . Évalué à 2.\nCorrigé. Merci d'avoir signalé les fautes.\nJe propose que tu utilises la tribune rédacteur [https://linuxfr.org/redacteurs/] pour signaler les autres afin d'éviter de poster trop de commentaires d'ortho sous la news.\nPosté par windu.2b le 17/05/10 à 18:37 . Évalué à 3.\nAutre faute, enfin si j'ai bien tout compris : le nom du noyau (Sheep on Meth) est annoncé dans la section "RC-6", alors que lorsqu'on regarde le diff, c'est lors de la sortie de la RC-5 qu'il semble avoir choisi ce nom.\nD'ailleurs, le diff en question date du 19/04 (date de la RC-5) et non du 29/04...\nPosté par Davy Defaud le 17/05/10 à 18:49 . Évalué à 1.\nUne autre dans le paragraphe sur la RC5 :\n« La plus notable pour les gens qui eu le problème »\nPosté par patrick_g (site Web personnel) le 17/05/10 à 18:54 . Évalué à 4.\nCorrigé. Merci de me l'avoir signalé.\nJe pense qu'il va falloir trouver un système plus intelligent pour signaler toutes les (innombrables) coquilles sans poster des commentaires dans la news.\nLa tribune rédacteur peut-être ?\nPosté par Sytoka Modon (site Web personnel) le 18/05/10 à 20:13 . Évalué à 4.\nMoi j'aime bien ces corrections en direct pour deux raisons :\n- je vois qu'il y a pas que moi qui fait des fotes ;-)\n- je lis et j'apprends en voyant les corrections proposées\nBref, tout cela est très pédagogique et très communautaire.\nPosté par patrick_g (site Web personnel) le 18/05/10 à 21:07 . Évalué à 3.\nCertes...mais à chaque fois mon moral en prend un coup. Avoir imprimé la news pour la relire et avoir laissé passé autant de trucs c'est déprimant.\nM'enfin bon le principal c'est que la news s'améliore à chaque correction ;-)\nPosté par patrick_g (site Web personnel) le 17/05/10 à 18:50 . Évalué à 3.\nOuaip, après vérification je confirme que tu as raison. Un véritable oeil de lynx ;-)\nJe laisse comme ça car ce n'est pas une pure faute d'ortho ou de grammaire et ça nécessiterait de reprendre l'organisation des RC.\nPosté par moi1392 le 18/05/10 à 15:09 . Évalué à 2.\npuisqu'on est dans les coquilles :\n"tu nous l'aS demandé"\nPosté par patrick_g (site Web personnel) le 18/05/10 à 17:24 . Évalué à 2.\nPosté par Zarmakuizz (site Web personnel) le 18/05/10 à 17:10 . Évalué à 2.\nPatch great_patrickg_kernel_2.6.34_ortho9 :\nEn effet une limitation importante de vga_switcheroo c'est qu'il oblige a redémarrer le serveur X si on veut que la bascule soit effective.\nPosté par Dreamkey le 18/05/10 à 21:29 . Évalué à 1.\nPartie "Mise en veille asynchrone"\t: décisions pertinentes quant à leur gestion\n"En bref"\t: tête de lecture (seek). L'heuristique\n"En bref" : ce module s'utilise soit en passant des arguments lors du chargement (au moment du insmod). Maintenant [... ]\t-> il manque un soit\nSinon il me semble qu'il manque un "pour" quelque part, mais je n'arrive pas à retrouver où.\nPosté par patrick_g (site Web personnel) le 18/05/10 à 21:54 . Évalué à 2.\nOn s'approche asymptotiquement de la perfection !\nMerci pour les remarques, c'est corrigé.\n# perf trace -s timechart.py\nPosté par Pierre le 17/05/10 à 15:42 . Évalué à 4.\na noter en passant le support de perf scripting python par pytimechart, une interface graphique rapide pour regarder les donnees extraites avec timechart.\nLe mieux est de regarder un peu ces screencast pour ce faire une idee:\na look at mplayer startup:\na look at ubuntu boot:\n[^] # Re: perf trace -s timechart.py\nPosté par fweisbec le 17/05/10 à 18:12 . Évalué à 2.\nOui et ce serait bien de l'avoir upstream ;-)\n# Erreur : HTML invalide\nPosté par Pinaraf le 17/05/10 à 18:08 . Évalué à 6.\nBelle dépêche, à un détail près qui pique les yeux dans Konqueror : y'a des erreurs dans le code HTML pour le premier titre, je cite :\n«<h2><a name="test">La phase de test</a> (<a href="#sommaire">↑</a>)</h2<h3><a name="rc1">RC-1</a></h3><br />»\nIl manque un > pour le </h2>…\n[^] # Re: Erreur : HTML invalide\nPosté par patrick_g (site Web personnel) le 17/05/10 à 18:32 . Évalué à 2.\n# Encore un probleme pour l'affichage..\nPosté par reno le 17/05/10 à 18:16 . Évalué à 2.\nDécidément le matériel évolue tellement rapidement pour l'affichage que le logiciel est (encore une fois) dépassé: même pas le temps d'exploiter (enfin) correctement l'accélération 3D, que le changement a chaud des GPU arrive et s'avère aussi incompatible avec l'architecture existant..\nJe me demande si les futurs CPUs qui intègreront la carte graphique (un concept que je trouve plutôt curieux d'ailleurs car le CPU a une bande passante mémoire bien inférieure a celle d'un GPU) vont encore nécessiter de tout casser????\n[^] # Re: Encore un probleme pour l'affichage..\nPosté par lolop (site Web personnel) le 17/05/10 à 20:37 . Évalué à 9.\nEst-ce que ça ne serait pas plutôt les futurs GPU qui intègreront un petit CPU :-)\nPosté par Frank-N-Furter le 17/05/10 à 18:20 . Évalué à 5.\nFaidora saymal, elle perd son sang froid.\n[^] # Re: Antisocial\nPosté par imr le 17/05/10 à 20:22 . Évalué à 4.\navec Theodore T'so (kernel hacker bien connu) dans le rôle du boomerang.\nCe que j'ai trouvé intéressant, c'est que ce que pas mal de monde disait sur les drivers libres expérimentaux ou pulse audio dans pleins de posts quand ils sont enfoncés de force Dans Les Computers des utilisateurs qu'ils transforment en bétas testeurs malgrè eux, à savoir que ça ne sert pas le libre mais red hat, trouve ici son exacte correspondance avec les hackers du noyau:\nThey only care about their narrow point of view, and don't care about the pain they are inflicting on the kernel development process and other kernel developers. This is _legal_. It is, however, anti-social."\nA noter qu'il parle de douleur et pas d'inconvénients comme dans la traduc de l'article, c'est beaucoup plus fort. Douleur + comportement anti social, on parle bien là de violence.\nPosté par Gniarf le 17/05/10 à 21:08 . Évalué à 1.\ncomme KDE 4, quoi :)\nPosté par imr le 17/05/10 à 22:07 . Évalué à 3.\nOui, aussi. :(\nPosté par grid le 18/05/10 à 15:00 . Évalué à 4.\noui, mais la faute n'incombe pas à KDE4 ou au driver Nouveau, c'est parce que les distributions font la course à la nouveauté (pure raison marketting et non technique)\nSlackware est plus conservateur dans les technologies, ce qui fait que c'est souvent plus stable.\nPosté par reno le 18/05/10 à 15:50 . Évalué à 0.\nBof, se plaindre qu'une distribution comme Fedora faite par RedHat pour tester des nouveautés fasse la course a la nouveauté, cela me fait bien rire..\nAprès oui il y a des distributions "grand publiques" telle Ubuntu qui font n'importe quoi en incluant du code pas vraiment mature (je pense a PulseAudio) dans leur nouvelles versions..\nPosté par barmic le 18/05/10 à 18:23 . Évalué à 2.\nJ'avais cru comprendre que ce n'était plus comme ça qu'il fallait la voir depuis que c'est devenue un projet communautaire. Il faut continuer de la voir comme une bêta de Red Hat ?\nPosté par barmic le 18/05/10 à 15:50 . Évalué à 6.\nJe ne connaît pas la vénérable, mais Debian est vachement bien foutu à ce niveau. Il est possible pour les développeurs de créer des paquets pour Sid et ainsi faciliter les tests sans pour autant pourrir la version stable.\nPosté par patrick_g (site Web personnel) le 17/05/10 à 22:35 . Évalué à 1.\n>>> A noter qu'il parle de douleur et pas d'inconvénients comme dans la traduc de l'article\nJe pense que j'aurai du traduire par "le mal qu'ils infligent".\nPosté par Mildred (site Web personnel) le 18/05/10 à 13:09 . Évalué à 7.\nEn même temps ce n'est pas comme si chez Fedora ils ne disaient pas que le but de la distribution c'est de mettre en avant de nouvelles technologies, pas encore forcément disponibles dans les branches principales des projets upstream.\nC'est un des buts de Fedora, et je me vois mal les critiquer pour ça.\nMaintenant, c'est vrai que tester de nouveaux kernels sous Fedora n'est peut être pas évident. Pour ça, ce que je verrais de mieux, c'est faire un rapport de bugs, expliquant qu'il est impossible de tester un nouveau kernel sans douleur. Pas de critiquer sans fin Fedora.\nLes bugs, ça arrive à tout le monde.\nPosté par VINDICATORs le 18/05/10 à 16:00 . Évalué à 2.\nJ'allais le dire ;), Fedora est un laboratoire en perpétuel développement. C'est bien défini depuis sa sortie!\nPour les nouveaux noyau il suffit d'aller les chercher au bon endroit, style ici :-> http://koji.fedoraproject.org/koji/index . Après un nouveau noyau officiel, directement télécharger depuis le site officiel, peut s'installer sans problème.\nAprès KDE4 est stable depuis un bon moment, en plus vous pouvez le configurer totalement pour retrouver ce qui était possible sous la version 3.xxx!\nMais bon... Il y a des têtus qui n'aiment pas qu'ont leur disent leur quatre vérités...\nPosté par imr le 19/05/10 à 02:19 . Évalué à 8.\nEn même temps ce n'est pas comme si chez Fedora ils ne disaient pas que le but de la distribution c'est de mettre en avant de nouvelles technologies\nPas de critiquer sans fin Fedora. Les bugs, ça arrive à tout le monde.\nTu fais une double attaque à l'épouvantail.\nPersonne n'a dit ce à quoi tu réponds.\nLes kernel hackers n'ont pas attaqué fedora parce que son implémentation de nouveau est bugguée, mais parce que la nature des problèmes qu'elle a montre un manque de respect pour son upstream.\nPersonne n'a attaqué fedora ici parce qu'elle est expérimentale mais parce que certains de ses utilisateurs ont pourri ubuntu pour exactement la même raison: manque de respect pour l'upstream.\nOr, depuis longtemps la situation est celle ci:\nd'un coté redhat contribue au desktop en promouvant des nouveautés en développement très expérimentales comme nouveau ou pulse audio, de l'autre une campagne de fond a lieu pour pourrir ceux qui ne les implémentent pas. Si tu implémentes pulse audio immédiatement, c-a-d si tu contribues upstream, tu es un bon citoyen.\nC'est une imposture intellectuelle de dire d'un coté, tu n'es pas obligé d'utiliser ces drivers/sous systèmes et de l'autre d'attaquer ceux qui ne le font pas sur les mêmes bases. C'est encore plus une imposture d'attaquer ensuite les distros d'être de mauvais citoyens parce que ces sous systèmes ne fonctionnent pas bien, c'est qu'ils ne contribuent pas assez, comme ubuntu est souvent attaquée ici.\nPosté par Grunt le 18/05/10 à 19:19 . Évalué à 0.\nC'est monstrueux, tu veux dire que des utilisateurs qui ont une carte graphique 3D pour bosser plus efficacement avec Compiz-Fusion se font imposer de force des pilotes buggés?\nIls devraient réclamer le remboursement de leur licence OEM!\n# Il parle de la transition KDE3 -> KDE4 la, non?\nPosté par zaurus (site Web personnel) le 17/05/10 à 20:38 . Évalué à -9.\n« Ma conclusion est claire comme le cristal. Changer une API d'un coup est une erreur, c'est dommageable, cela limite la base des développeurs, cela limite la base des testeurs, c'est une perte de temps et d'efforts. C'est une mauvaise décision technique. C'est du masochisme. Il y a peu de règles inconditionnelles dans le monde du libre mais cela en est une. »\nJe ne m'en suis toujours pas remis personnellement.\nAu boulot je garde un KDE3 qui est parametre de maniere a ce que je sois\nhyper efficace, chez moi je teste d'autres WM pour dire adieu a KDE... :(\n[^] # Re: Il parle de la transition KDE3 -> KDE4 la, non?\nPosté par Tonton Benoit le 18/05/10 à 15:16 . Évalué à 5.\nIl parle de la transition KDE3 -> KDE4 la, non?\nNon il parle de la migration Gnome 1.xx > 2 ^^\n# Ceph, ca a l'air interessant ce systeme de fichiers!\nPosté par zaurus (site Web personnel) le 17/05/10 à 20:40 . Évalué à 5.\nC'est vrai que les FS distribues qui demandent pas un admin\na plein temps a configurer, ca se fait un peu attendre pour\nPosté par bghflt (site Web personnel) le 17/05/10 à 20:52 . Évalué à -1.\nMaintenant c'est confirmé, Patrick_G est un robot à architecture multi-scalaire.\nUne analyse si détaillée ne peut provenir que de la NSA.\nPosté par Littleboy le 18/05/10 à 02:22 . Évalué à 2.\nIl est surtout abonne a LWN.net (d'ailleurs on peut le voir troller de temps en temps, genre sur Theora, mais ca marche beaucoup moins bien que sur LinuxFR...)\nPosté par Guillaume Knispel le 18/05/10 à 03:37 . Évalué à 5.\nContrairement à ici, la tradition de lwn n'est pas vraiment aux énormes trolls débridés dans les commentaires.\nJ'aime les deux approches :P\nPosté par Sytoka Modon (site Web personnel) le 18/05/10 à 09:44 . Évalué à 7.\nUn abonnement LWN ne suffit pas à écrire de bonnes dépêches sur DLFP ;-)\nPosté par WhiteCat le 18/05/10 à 16:02 . Évalué à 1.\nOui, il faut se taper tous les mails de la LKML, et ça je suis pas encore tout à fait prêt à le faire tout seul ^^\n# A propos de l'USB\nPosté par freejeff le 17/05/10 à 22:04 . Évalué à 5.\nÇa fait longtemps que je me pose la question, mais est ce qu'il existe une pile usb préemptive ?\nSans vouloir dire de bétises, il me semble que Ingo Molnar a introduit la possibilité d'avoir une version RT d'un noyau classique avec l'option CONFIG_PREEMPT_RT (Attention, je ne saurais être précis la dessus) appelée "hard-realtime scheduling". Cette option permet notament aux gens faisant de l'audio de réduire drastiquement la latence. Je citerai Linus :\nJ'ai utilisé de manière tout à fait satisfaisante le noyau packagé par debian linux-rt dans le cadre d'une version d'ubuntu-studio avec des cartes d'acquisitions PCI, mais je n'ai jamais eu de bons résultats (voir bien pire qu'avec la version classique du noyau) avec une carte usb.\nIl semble que cette pile (je ne sais pas si ce terme convient, j'aurais a priori dit "driver" sans conviction) ne soit pas capable de fonctionner sans aberrations i.e : valeur d'acquisitions erratiques, j'avais trouvé USB4RT, mais ça date de 2005 et le patch de Ingo n'a été introduit qu'à partir de fin 2007 !\nJe me permets donc (vu que c'est LA news ou je peux le faire) de demander aux gens qui sont un peu plus dans la technicité que moi s'ils connaissent des moyens de faire de l'USB en RT, et si oui est il possible de le faire sans un gros hack condamnant le pc à ne plus subir aucune mis à jour.\nEst-ce que quelqu'un a déjà vu ça passer ce sujet sur la LKML (oui, je sais, je pourrais chercher moi même), suis-je le seul à me poser cette question ?\nPour info la granularité temporelle que j'ai réussi à atteindre sur une carte PCI est de l'ordre de 100 kHz stable (limite de la carte d'acquisition) sans buffer et de 1 kHz avec des erreurs en USB.\n[^] # Re: A propos de l'USB\nPosté par Guillaume Knispel le 18/05/10 à 03:45 . Évalué à 6.\nLes noyaux généralistes ne sont pas vraiment conçus pour faire du temps réel dur déterministe. Rien que 1kHz avec quelques centaines de us de jitter peut-être dur à atteindre (et même sur du PCI), selon le hard présent dans la machine et les driver, et même le code de la CM qui fait des trucs derrière le dos de l'OS en mode de management.\nDonc même sans considérer le noyau, les PC généralistes (style station, laptop ou serveur quelconque) ne sont pas vraiment conçus pour faire du temps réel. On peut avoir de la chance, ... ou non !\nTant mieux si tu as réussis à atteindre 100kHz stable sur une carte PCI, mais ne t'attend pas à ce que ce résultat soit largement reproductible sur pleins de PC différents, voire peut-être même deux version de Linux différente si tu as pas trop de bol.\nPosté par freejeff le 18/05/10 à 09:12 . Évalué à 3.\nN'était ce pas la raison du patch du noyau ?\nIl me semble de plus que même si linux est un noyau "généraliste", sa base est massivement utilisée dans l'embarqué avec les processeur arm de type 7, 9 et cortex A8. Je sais qu'il y a quelques changements, mais ça n'en est pas moins un linux.\nPosté par Nicolas Boulay le 18/05/10 à 13:01 . Évalué à 5.\nLes patch RT sont fait pour diminuer le jitter pour les timer d'une précision autour de la milliseconde.\nEn gros pour des timer à 1 ms, tu peux avoir 1ms de jitter sur un linux normal qui tombe à qq dizaine de µs en RT.\nRien n'est magique. J'avais entendu parler il ya longtemps de drivers proprio nvidia qui pouvait utiliser le bus PCI pendant 300ms !\nPosté par freejeff le 18/05/10 à 17:47 . Évalué à 2.\nIl me semble que même sur un noyau non RT, il existe des High Resolution Timer qui permettent d'avoir une granularité d'une µs ?\nJe pense que cette granularité couplée à un jitter de 10 µs est largement suffisante pour beaucoup d'applis non ?\nPosté par Nicolas Boulay le 19/05/10 à 12:46 . Évalué à 2.\nLe timer a la granularité mais cela ne veut pas dire que Linux va le respecter.\nIl y a plein de raisons : driver avec fonction longue non interruptible, attente de BKL/sémaphore/mutex/spinlock/..., transfert PCI long, etc...\n# Encore un noyau ? / Linus geule à la place de parler calmement?\nPosté par DrBuenol le 17/05/10 à 22:06 . Évalué à -10.\nAves la centaine de systéme de fichier et pilotes et autres, c'est plus un noyau....(à mon sens)\nEt le fait que Linus geule sur tous et (on dirait) tent d'imposé son opinion....c'est pire que tout\n[^] # Re: Encore un noyau ? / Linus geule à la place de parler calmement?\nPosté par WhiteCat le 18/05/10 à 16:08 . Évalué à 7.\nTu es sûrement plus compétent pour définir ce que devrait être un "noyau" ?\nLinus gueule sur tout, mais visiblement tous les développeurs (et les sociétés qui les embauchent) semblent s'en accommoder. Et je pense qu'ils se foutent pas mal du genre d'avis que tu donnes, vu que tu n'as sûrement jamais contribué à Linux (vu ta 1ère remarque je pense pouvoir l'affirmer).\nPosté par liberforce (site Web personnel) le 18/05/10 à 21:14 . Évalué à 6.\nToi t'es nouveau par ici...\n# btrf compress_force\nPosté par john_labite le 19/05/10 à 15:54 . Évalué à 2.\nma petite correction, sur le bon -et excellent- article cette fois\n[^] # Re: btrf compress_force\nPosté par patrick_g (site Web personnel) le 19/05/10 à 17:33 . Évalué à 3.\n>>> Il ne me semble pas que ce soit -encore- possible de le faire fichier par fichier\nTu est sûr ? Ce n'est pas comme ça que je comprends ce commit (mais je me gourre peut-être) : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6(...)\nIl y a aussi le mail de pull de Chris Mason qui en parle : http://thread.gmane.org/gmane.linux.kernel/961862\n"I added the ability to compress a single file on demand and defrag only a range of bytes in the file".\nPosté par john_labite le 20/05/10 à 15:51 . Évalué à 1.\nsi je comprend bien, il faut 'juste' defragmenter un fichier pour activer la compression dessus (même si j'ignore comment passer comme argument le flag de compression);\nil va falloir tester :)\nPosté par Jllc le 24/05/10 à 22:26 . Évalué à 1.


M-Paiement | CCNews | Page 2\nArchives de Catégorie: M-Paiement\n19/10/2015 · 2:17\nUne fois l’application téléchargée sur leur smartphone Orange NFC compatible, les clients Orange – détenteur d’une SIM NFC compatible – n’ont plus qu’à se laisser guider. Quelques clics suffisent pour créer son compte et activer le service, et ce, quelle que soit sa banque. Pour bénéficier de l’option standard, les clients n’ont aucun document à fournir. Aujourd’hui, plus de trois millions de clients Orange possèdent déjà un mobile compatible.\n1/ Service Orange Cash : compte de monnaie électronique prépayé et rechargeable émis et géré en France Métropolitaine par Wirecard Card Solutions Ltd – 3rd Floor Grainger Chambers, 3-5 Hood Street, Newcastle upon Tyne, NE1 6JQ, UK – société autorisée par la Financial Conduct Authority (réf. 900051), sous licence Visa Europe. Service soumis à conditions réservé aux utilisateurs majeurs d’une ligne mobile Orange souscrite en France Métropolitaine (hors offre prépayée) et détenteurs d’une carte SIM et d’un terminal Orange paiement sans contact compatibles. Nécessite le téléchargement de l’application gratuite Orange Cash éditée par Orange (hors coût de connexion).\n2/ Ces offres sont soumises à conditions. Détails sur le site orangecash.fr :bons plans\nClassé dans M-Paiement, TELECOMS\n06/05/2015 · 9:27\nEn attendant une spin-off, PayPal dépasse eBay\nSource : Statista, Felix Richter, le 23 Avril, 2015\nLe service de paiement d’eBay continue à stimuler la croissance de l’entreprise. Au cours du premier\ntrimestre de 2015, les revenus de la division des paiements ont atteint les 2,11 milliards de dollars, en hausse de 14% par rapport à la même période en 2014.\nPendant la même période, le coeur de métier d’eBay, la grande distribution sur l’Internet, a enregistré une baisse de chiffre d’affaires pour la première fois depuis des années et ne représente plus la majorité des revenus d’eBay. Avec des ventes atteignant un montant de $ 2,07 milliards, le site éponyme de vente aux enchères eBay et d’autres marchés détenues par la société génèrent désormais moins de revenus que PayPal.\nAlors que les derniers résultats ne soient pas nécessairement catastrophiques pour l’avenir de eBay sans PayPal, les dirigeants d’eBay auront beaucoup de mal à dissiper les doutes des investisseurs quant aux perspectives de croissance de l’entreprise en tant que société autonome.\nClassé dans Économie numérique, M-Paiement, Monétique\n15/03/2015 · 7:02\nApple Pay : l’authentification faible\nDe nouveaux exploits de fraudeurs viennent de démontrer l’importance du « maillon faible » dans les systèmes de paiement. Chez Apple Pay, c’est la procédure d’authentification. Dans les nouveaux instruments de paiement les offreurs affirment que leur produit est sécurisé, sans préciser leur niveau de sécurité. Chez Apple Pay, la sécurité repose en partie sur la tokenisation et la biométrie. Le « maillon faible » d’Apple Pay est l’approvisionnement des cartes bancaires, une opération qui consiste à enregistrer ses cartes en les scannant à l’aide de l’application photo de l’appareil. C’est ce que révèle le site Drop Labs.\nLe système de fraude des délinquants est dramatiquement simple: des bandes criminelles organisées distribuent des iPhones pré-approvisionnés avec des cartes volées, à des complices, des « mules », qui vont les utiliser pour faire des achats frauduleux. Celles ci ont eu lieu autour de la ville de Miami en Floride et Dallas. Les cartes prépayées sont les premières concernées car elles peuvent être rapidement utilisées pour recevoir de l’argent ou une bien. Comble de l’ironie: le conseilleur est le payeur, les magasins Apple ont été les cibles les plus intéressantes pour les fraudeurs. Pour les fraudeurs, il est beaucoup plus intéressant d’utiliser des cartes volées enregistrées dans des portefeuilles électroniques comme Apple Pay que pour des achats à distance. En effet, dans les transactions de commerce électronique, le fraudeur doit attendre la livraison, ce qui laisse un délai d’au moins 24 heures au commerçant pour vérifier la validité du paiement. En revanche dans les transactions en face à face le produit est donné au client dès que le paiement est validé.\nManifestement, il y a un problème d’authentification de la carte dans les échanges entre Apple Pay et la banque de l’émetteur.\nClassé dans Industrie, International, M-Paiement\n18/02/2015 · 6:19\nSamsung Pay présenté le 1er mars à Barcelone\nSamsung a invité les medias, les analystes et les développeurs pour le 1er mars 1015. Objet de l’invitation : la présentation de son dernier né le smartphone Galaxy S6 et Galaxy S6 Edge. Les deux nouveautés seront présentées à l’occasion du prochain Mobile World Congress de Barcelone du 2 au 5 mars 2015. L’annonce de Samsung aura donc lieu la veille de l’ouverture du salon.\nDifférentes sources indiquent que ces modèles auront un boîtier métallique et une version modifiée de l’interface TouchWiz*. Par ailleurs, il est fait allusion à un écran incurvé.\nUn accord entre Samsung et Visa\nDes sources proches du dossier ont confié à notre confrère coréen que Samsung s’apprête à lancer un moyen de paiement mobile avec le Galaxy S6. L’industriel Coréen a conclu un accord avec Visa. Le paiement à la mode Samsung s’appellerait tout simplement Samsung Pay. Ce moyen de paiement serait basé sur la technologie de LoopPay**.\nContrairement à la technologie NFC qui exige sur le terminal de paiement soit équipé de cette technologie.\nLoopPay utilise la technologie MST (Magnetic Secure Transmission) qui va transformer le terminal de paiement à pistes magnétiques en terminal sans contact. Et ce, sans modification ou mise à niveau du terminal de paiement. Toutes les données sont cryptées. Cet accord signé avec Samsung va très sensiblement augmenter sa base d’utilisateurs.\nLes utilisateurs de ces nouveaux smartphones disposeront d’un nouveau capteur d’empreintes digitales pour effectuer les paiements. L’utilisateur ne glissera plus son doigt, mais le pressera sur le capteur.\n*TouchWiz est une interface utilisateur appelée surcouche pour appareils mobiles, développée par Samsung.\n18/02/2015 · 5:58\nPaiement mobile : même les allemands s’y mettent\nDans le pays du cash roi, près d’un tiers des habitants seraient prêts à utiliser les paiements sur téléphones mobiles. Selon un sondage réalisé par le cabinet TNS Infratest, 31 % des allemands serait prêts à payer par téléphone mobile. A condition qu’on puisse effectuer l’opération en gardant son téléphone dans son sac ou son porte-monnaie.\nQuelque 33% des 1 002 consommateurs interrogés ont déclaré qu’ils souhaitent payer à une station-service ; 33% autres aimeraient acheter leurs billets pour les transports publics et 30% considèrent les moyens de paiement mobiles comme une « véritable alternative » pour le shopping au supermarché ou à la pharmacie.\nLa sécurité du paiement mobile est une forte préoccupation pour 63 % des répondants.\nDans le même temps, 43 % des propriétaires de smartphones souhaitent que le paiement mobile soit simple d’utilisation. Ne pas sacrifier la sécurité à la facilité d’usage.\nPendant ce temps, 48% pensent qu’ils accepteront de payer avec un smartphone s’ils sont sûrs de leur sécurité et 28% y voient un argument convaincant pour les paiements mobiles s’il s’avère qu’il est plus rapide que les autres méthodes de paiement. Un peu plus de la moitié (52%) des répondants de moins de 30 ans pense aussi qu’il est important d’avoir la possibilité de payer dans tous les canaux de vente en utilisant un système de paiement mobile.\n« Les résultats dépassent nos attentes », déclare le PDG Nils Winkler de Yapital. « Ils sont en phase avec notre opinion sur les problèmes des consommateurs posés par les moyens de paiement disponibles actuellement. Ils renforcent notre hypothèse selon laquelle un système de paiement mobile ne peut être efficace que s’il fonctionne sur tous les canaux de vente et offre au consommateur des valeurs supplémentaires ».\n12/01/2015 · 9:05\nTalk to Pay propose le « coffre-fort pour passwords »\nDans Talk to Pay, je demande l’extension « Coffre-fort de passwords ».\nOn connaît le service Talk to Pay, une solution universelle de paiement par carte bancaire en un clic proposée par la banque du client. En l’occurrence, à ce jour, La Banque Postale, LCL, le Crédit Agricole et, bientôt, une autre banque. L’une des originalités du service est d’offrir une authentification du client par la reconnaissance vocale, un procédé biométrique mis au point par PW Consultant (Patrick Wajsbrot Consultant). Cette reconnaissance vocale génère un token unique à chaque opération. Et, dès lors que la solution T2P permet de s’authentifier par la voix au moment du paiement, pourquoi ne pas l’utiliser pour permettre aux clients de la banque utilisatrice d’offrir ce procédé biométrique pour leur permettre d’accéder à tous les sites internationaux exigeant l’usage d’un code confidentiel.\nL’idée de Patrick Wajsbrot a pour origine une discussion avec Jean-Marc Mosconi, délégué général de Mercatel. Ce dernier lui faisait remarquer que le taux d’abandon des commandes sur l’Internet avoisinait les 30 % parce que le site marchand demandait une identification par code. Bien souvent l’acheteur l’avait oublié et plutôt que de demander un nouveau code préférait abandonner la transaction. Attitude courant, notamment dans les achats d’impulsion. De l’idée il n’y a qu’un pas (et des financements). L’extension était créée et proposée au secteur bancaire.\nIl existe déjà un certain nombre de solutions permettant l’identification d’un individu. Ce sont pour la plupart des solutions privatives qui exigent la confiance de l’utilisateur dans la sécurité de la solution. Par ailleurs, le principe de ces solutions est de stocker les codes. L’utilisateur a accès à son « coffre-fort » et donc à consulter tous les codes à l’aide d’un « Master Password »… qui peut être piraté. c’est qui fait l’originalité de l’extension Talk to Pay est que la solution repose sur l’infrastructure de sécurité de la banque qui a, en règle générale, la confiance de ses clients et que le « Master Password » est la propre voix, plus divers éléments sécuritaires, de l’utilisateur. Enfin, souligne Patrick Wajsbrot, « nous ne proposons pas le remplissage automatique des données, parce que ce sont des données personnelles qui peuvent être piratées. Ce qui est important est de faciliter l’usage de l’internet pour des utilisateurs dans leurs actes récurrents, dans un cadre sécuritaire fort qui est offert par la banque du client ». Mais les compagnies d’assurance ou tout autre organisme de confiance peuvent aussi utiliser Talk to Pay et ses extensions.\nRappelons que dans Talk to Pay, il existe des services additionnels aux paiements qui permettent la gestion des transactions par le client de la banque. Par exemple, Patrick Wajsbrot cite l’historique et le détail des transactions réalisées. Ainsi, un client peut vérifier non seulement le montant de la transaction, mais aussi le détail de la commande, article par article. Un service que n’offre pas les portefeuilles électroniques souligne Patrick Wajsbrot.\nClassé dans Banque, Biométrie, M-Paiement


vente Maison T5 restaurée avec jardinet et garage.\nMaison t5 restauree avec jardinet et garage\nMaison T5 restaurée avec jardinet et garage. Brive-la-Gaillarde (19100)\nSylvie Faugeras, votre conseillère en immobilier au 06.64.91.53.84 vous propose à quelques minutes du centre ville de Brive, dans le quartier des Rosiers, cette maison en pierre des années 50 entièrement restaurée et à très fort potentiel. En effet, sa configuration vous permettra soit d'accueillir une famille avec des enfants car elle dispose de quatre chambres, deux bureaux (ou chambres d'enfants), deux salles de bain avec toilettes et une salle d'eau avec toilettes, soit de la diviser en deux ou trois appartements avec des entrées séparées. Un appartement avec cuisine, chambre et salle d'eau existe déjà au rez de jardin par exemple. La pièce de vie lumineuse car traversante vous séduira à coup sûr et vous n'entendrez aucun bruit grâce une double fenêtre en PVC double vitrage qui vous isolera parfaitement. Une belle cuisine aménagée et équipée, une véranda, une terrasse couverte, une terrasse découverte, une cave, un garage et un jardinet complètent ce bien. Voici une belle opportunité à saisir!\nSylvie Faugeras 06.64.91.53.84. www.openimobilier.immo sylviefaugeras@yahoo.fr\ncuisine + séjour 11.50 Rez-de-chaussée\nsalle d'eau+ wc 3.26 Rez-de-chaussée\ncave 7.53 Rez-de-chaussée\ngarage 11.74 Rez-de-chaussée\nterrasse couverte 11.00 Rez-de-chaussée\nterrasse 14.76 Rez-de-chaussée\ncuisine 7.52 1\nsalon/sejour 39.04 1\nsalle de bain + wc 3.05 1\nvéranda 10.00 1\nchambre 9.50 2\nchambre 11.57 2\nbureau 6.00 2\nbureau 6.50 2\nsalle de bain + wc 3.45 2