La sortie de la version stable 3.8 du noyau Linux vient d’être annoncée par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site kernel.org.
Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche (qui est sous licence libre CC BY-SA).
À noter, une nouvelle survenue pendant le développement de cette version, dont l’incidence sur les développements futurs reste inconnue : Alan Cox, qui a été employé successivement par Red Hat et Intel, a décidé de quitter Intel et le développement du noyau (dont il est un des piliers) pour raisons familiales.
Merci aux participants à la rédaction de cette dépêche : Batchyx (notamment toute la partie Réseau), detail_pratique, yogitetradim, Spack, Ner’zhul, Étienne Bersac (notamment les parties « Optimisation pour architecture NUMA » et « Virtualisation »), Pierre Mazière, baud123, Xavier Claude, Akiel, Christophe Turbout, Strash et RbN.
Sommaire
-
La phase de test
- RC-1 : beaucoup de commits et un peu de vin chaud
- RC-2 : une RC de taille raisonnable pour la nouvelle année
- RC-3 : fin des vacances, une RC de taille raisonnable mais pas anodine pour autant
- RC-4 : une RC calme qui sort le jour des enfants
- RC-5 : avant la conférence Linux Australie
- RC-6 : depuis l’Australie
- RC-7 : sur le retour
- Les nouveautés
- Les améliorations
- Statistiques
La phase de test
RC-1 : beaucoup de commits et un peu de vin chaud
La version RC-1 a été annoncée par Linus le 21 décembre 2012 :
« La plus longue nuit de l’année est derrière nous¹, et quoi de mieux à faire que se prendre un bon vin chaud, s’installer confortablement, se relaxer et jouer avec la dernière RC du noyau ?
C’était une grande fenêtre de fusion : nous avons plus de commits que n’importe quel autre noyau de la série 3.x (cependant la version 3.2-rc1 était presque aussi importante). En d’autres mots, c’était une fenêtre de fusion mouvementée.
Diffstat semble normal : à peu près 63 % des patches sont dans les pilotes — staging, réseau, SCSI, GPU, audio, DRBD, etc. —, 18 % de mises à jour dans l’architecture (avec divers changements dans la plate‐forme ARM, qui constituent la plus grosse partie — soupir), et le reste vient de « divers », tels le cœur du réseau, les systèmes de fichiers (un nouveau système de fichiers, F2FS, optimisé pour les mémoires Flash) et des fichiers include.
Allez‐y, testez. »
Linus
⁽¹⁾ Et par « nous », je veux principalement dire les gens dans le même fuseau horaire et le même hémisphère que moi. Parce que je suis trop égocentrique pour me soucier des autres. »
RC-2 : une RC de taille raisonnable pour la nouvelle année
La version RC-2 est sortie le 2 janvier 2013 :
« C’est une nouvelle année, les gens retournent travailler, et essayent désespérément d’oublier toute la nourriture qu’ils ont ingurgitée en excès durant ces deux dernières semaines. Et eh, pour célébrer cela, voici la RC2 !
Le correctif est relativement petit, et largement dominé par les mises à jour pour processeurs graphiques et la suppression triviale de __devinit/exit dans la couche I²C. Mais il y a quelques travaux sur les systèmes de fichiers (ext4, eCryptfs, Ceph), et quelques correctifs de machines virtuelles ; ainsi que quelques tardifs nettoyages sur ARM OMAP.
Le résumé des modifications est en annexe, et mon « merge log » ressemble à ça :
Wolfram Sang : i2c __dev* suppression d’attributs
David Miller : Correctifs réseau
Eric Biederman : Correctifs d’espaces de noms
Guenter Roeck : Correctifs sur hwmon
Olof Johansson : Correctifs sur ARM SoC, tardifs nettoyages sur OMAP pour ARM
Dave Airlie : Mise à jour de DRM
Ted Ts’o : Correctifs de bogues sur ext4
Sage Weil : Correctifs sur Ceph
Tyler Hicks : Correctifs sur eCryptfs
Bjorn Helgaas : Mises à jour PCI
Wim Van Sebroeck : Correctifs sur watchdog
Bryan Wu : Correctifs sur LED
Allez‐y, testez. »
Linus
RC-3 : fin des vacances, une RC de taille raisonnable mais pas anodine pour autant
La version RC-3 est sortie le 9 janvier suivant :
« Les vacances sont terminées et les choses commencent à revenir à la normale. À l’exception de Greg, je suppose, qui doit probablement essayer de s’extraire de sa montagne de courriels.
Une nouvelle semaine, une nouvelle version candidate. De taille plutôt normale. La plupart des changements concernent des pilotes et sont répartis un peu partout pour effacer les dernières traces de __dev[init|exit], un tas d’entre eux étant d’une seule ligne .
Mais, à part ça, il y a de vraies mises à jour (les pilotes graphiques se distinguent — principalement Radeon et Exynos), du travail au niveau des architectures (ARM, PowerPC, MIPS et MicroBlaze), des systèmes de fichiers (F2FS, GFS, CIFS et NFS) et du réseau (Netfilter et Sun RPC).
Et j’espère vraiment que les choses vont se calmer. J’ai conscience qu’il y a eu des patches de vacances rejetés, mais essayons avant tout d’avoir une RC4 vraiment plus petite.
OK ? »
Linus
RC-4 : une RC calme qui sort le jour des enfants
La version RC-4 a été annoncée par Linus le 17 janvier :
« Salut, déjà une nouvelle semaine ! En fait, ça m’a tellement surpris que j’ai eu besoin d’un jour supplémentaire. Le concept “sortie en milieu de semaine” me semble bizarre.
Ceci m’a conduit à me demander quel était le jour le plus commun pour une sortie, et statistiquement, la plupart des sorties ont lieu un dimanche. L’“astuce Git de la semaine” ressemble à ça :
git log --no-walk --pretty="%ad" $(git tag -l)
qui peut ensuite être redirigé vers :
cut -d' ' -f1 | sort | uniq -c | sort -n
afin de voir l’ensemble des statistiques des étiquettes Git.
Cette digression mise à part, je peux joyeusement annoncer que la RC4 est plus petite que la RC3 malgré le jour supplémentaire, même s’il s’en faut de peu. Il n’y a pas vraiment grand‐chose qui sorte du lot : à part un nouveau pilote sans fil (le pilote Atheros Wilocity) et des changements OMAP DRM, le diffstat est plutôt plat et diffus. Ce qui signifie de nombreux petits changements un peu partout.
Le journal des modifications est joint, mais c’est en gros 85 % de pilotes, dont plus de la moitié se rapporte au nouveau pilote sans fil et aux changements OMAP DRM précités. Il y a également d’autres changements noyés dans la masse : de petites mises à jour ARM et S390 (plus des touches de SuperH et de x86), quelques petites corrections de systèmes de fichiers, des choses de ce genre.
Testez. Mon intuition est que les choses vont vraiment se calmer. Et je détesterais être contredit. »
Linus
RC-5 : avant la conférence Linux Australie
La version RC-5 est sortie le 25 janvier :
« Salut, Linux 3.8-rc5 est sorti. Donc, allez‐y !
Je voyagerai pour LCA — Linux Conference Australia — la semaine prochaine, j’espère donc que les choses se calmeront. Elles ne se sont pas trop calmées pour cette RC5, vu qu’on a encore plus de 300 commits pour cette version. Non pas que ces derniers soient tous inquiétants, mais il y a plus de mouvements sur Btrfs, F2FS, ptrace et dans le chargement des modules que ce que j’aurais préféré voir à ce stade.
Bien sûr, il y a aussi les classiques mises à jour de pilotes : i915 et Radeon, USB, série, etc. Mais ces pilotes représentent moins de la moitié des patches ce coup‐ci.
Allez‐y, testez. »
Linus
RC-6 : depuis l’Australie
La version RC-6 a été annoncée le 1ᵉʳ février :
« Voici la très attendue publication spéciale LCA, mais sans changement de mascotte cette fois. Elle n’est pas énorme, mais je veux vraiment que la RC7 soit plus petite, et je maudirai haut et fort quiconque m’enverra une requête d’ajout pour des choses que je ne considèrerai pas valables.
Il y a quelques mises à jour x86 et réseau, plus des changements au niveau du son et des pilotes graphiques Exynos qui montrent le bout de leur nez. Et de nombreuses autres choses dans des sous‐systèmes çà et là (pinctrl, regulator, IOMMU, NFS, DM/MD…).
Vous connaissez la chanson. »
RC-7 : sur le retour
La version RC-7 a été annoncée le 9 février :
« Une autre version d’Australie, juste avant de rentrer à la maison. Une fois de plus, cela n’a pas été aussi calme que ce que j’aurais souhaité (et avec l’épouvantable accès à Internet la semaine dernière, chaque récupération était assez pénible — Git utilise plutôt bien la bande passante, mais nécessite néanmoins un réseau qui tienne et ne perde pas de paquets à droite et à gauche). Bref, la voici. Surtout des mises à jour de pilotes (USB, réseau, Radeon, régulateur, son) avec quelques soupçons d’autres trucs (Btrfs, réseau, etc). Ça reste plutôt petit dans l’ensemble. »
Linus
Les nouveautés
i386 : car c’est un bon camaraaaadeu
La prise en charge des processeurs i386 a été retirée du noyau à l’initiative d’Ingo Molnar (comme ça, vous avez le nom du coupable à châtier ; mais attention, il n’est pas seul, c’est une décision collégiale des mainteneurs x86). Le point d’entrée en termes d’ancienneté, s’agissant de l’architecture x86, devient donc de fait le i486.
Mine de rien, c’est tout un symbole : il s’agit de l’architecture sur laquelle Linus Torvalds a créé Linux en 1991. Toutefois, ce dernier n’a pas montré de sentimentalisme excessif (ce qui n’est de toute façon pas son genre) et lui a souhaité bon vent.
À noter qu’Intel a cessé de commercialiser ces puces en 2007.
Cette nouveauté nous donne l’occasion de nous replonger dans le passé du noyau et de sa prise en charge progressive d’un nombre toujours plus grand d’architectures processeur :
- la version 1.0, considérée comme stable, sort en mars 1994 pour processeurs i386 uniquement ;
- avec la 1.2 qui sort un an plus tard, en mars 1995, Linux devient portable en prenant en charge de nouvelles architectures : Alpha, SPARC et MIPS ;
- l’année suivante, la 2.0, sortie en juillet 1996, peut gérer plusieurs processeurs (SMP) ;
- la prise en charge des architectures ARM est introduite dans la version 2.1.80 un an et demi plus tard, en janvier 1998 ;
- la 2.2 sort un an plus tard, en janvier 1999, avec la prise en charge des m68k et PowerPC, puis, en fin d’année (avec la 2.2.13), des IBM mainframes, ouvrant Linux au monde professionnel ;
- la 2.4 sort deux ans plus tard, en janvier 2001, avec la prise en charge des X86-64 (la 2.6.24 qui sortira en janvier 2008 unifiera les architectures i386 et x86-64) ;
- la 3.1, sortie en octobre 2011, gère l’architecture OpenRISC ;
- sans qu’il s’agisse d’une nouvelle architecture processeur, l’intégration dans la 3.3, sortie en mars 2012, d’un certain nombre de pilotes Android est à signaler ;
- la 3.4, sortie en mai 2012, ajoute l’architecture x32 ;
- la 3.7, sortie en décembre 2012, ajoute l’architecture AArch64 (ARM64).
Optimisation pour architecture NUMA
Les architectures NUMA, où chaque processeur a un contrôleur mémoire dédié, nécessitent une révision de l’ordonnanceur. En effet, l’ordonnanceur doit tenir compte de la topologie du processeur pour placer un processus sur le cœur le plus proche de sa mémoire. L’ordonnanceur actuel est trop naïf pour ces architectures, ce qui provoque des pertes de performance.
Linux 3.8 apporte une première étape dans la prise en charge correcte de ces architectures. Ce ne fut pas facile, car ce sujet touche à deux domaines traditionnellement distincts : la mémoire et le processeur. Les équipes respectives se sont donc chamaillées pendant quelques semaines avant d’aboutir à un premier jalon.
Seules les fondations pour une prise en charge automatique du NUMA ont été posées. Les prochaines versions du noyau devraient donc voir l’arrivée d’ordonnanceurs automatiques pour architecture NUMA. Chaque équipe devrait proposer sa solution, plutôt orientée gestion de la mémoire ou du processeur. Le plus optimal l’emportera.
Prise en charge préliminaire du futur processeur IBM POWER8
Alors que le processeur IBM POWER8 est annoncé pour succéder cette année (dans les serveurs haut de gamme IBM) au POWER7 — qui était à l’honneur notamment dans les dépêches des versions 2.6.27 et 2.6.36 du noyau —, celui‐ci intègre dès à présent une prise en charge préliminaire de ce processeur.
Le POWER8 sera gravé en 22 nm et proposera notamment un simultaneous multithreading (SMT) de quatrième génération.
Pour rappel, la feuille de route d’IBM est conçue sur la base d’une refonte majeure de la conception du processeur tous les trois ans (ex : POWER7), avec à la mi‐étape un raffinement des méthodes de gravure et quelques changements modestes d’architecture (ex : POWER7+), à la façon de la stratégie tic‐tac d’Intel.
Pilote graphique pour Nvidia Tegra 2/3
Bien que la version 2.6.36 du noyau ajoutât la prise en charge du cœur processeur ARM du Tegra (et que, récemment, la version 3.4 ajoutât celle du Tegra 3), il manquait dans tous les cas la prise en charge de la partie graphique de ces système monopuce (SoC). Dorénavant, Linux embarque un pilote graphique basique (pour l’instant limité à la 2D) pour les SoC Tegra 2 et Tegra 3. Une fois n’est pas coutume, ce pilote est développé avec la collaboration du concepteur Nvidia (qui ne va pas pour autant jusqu’à le développer lui‐même : fuck).
Nouveau système de fichiers pour mémoires Flash : F2FS
Le nouveau système de fichiers F2FS (sigle pour Flash-Friendly File-System) qui fait son apparition dans cette version du noyau a été spécialement conçu par Samsung pour les appareils utilisant de la mémoire Flash, comme les clés USB, cartes mémoires et tous les appareils embarquant ce type de mémoire (tablette, smartphone…).
Ce n’est pas le premier système de fichiers à avoir cet objectif (citons YAFFS, JFFS2, LogFS ou encore UBIFS) : l’avenir nous dira si le succès est au rendez‐vous. Ce nouveau système de fichiers cible certaines mémoires Flash embarquées, et non les disques SSD. Les mémoires ciblées contiennent un contrôleur FTL, conçu pour implémenter dans le matériel l’optimisation de mémoire Flash que des système de fichiers comme FAT n’ont pas.
À noter que Microsoft promeut dorénavant à cet effet exFAT (pour Extended File Allocation Table), un système de fichiers propriétaire et breveté développé en 2006 (au lieu de l’antique FAT32 limité aux fichiers de moins de 4 Gio). Ainsi, la norme des cartes mémoire SDXC (qui doivent succéder aux cartes SDHC) prévoit que celles‐ci soient formatées par défaut en exFAT. Sous Linux, il existe depuis peu un pilote libre en espace utilisateur (fuse-exfat), sous licence GPL v3, gérant ce système de fichiers.
Les améliorations
Chiffrement plus rapide
Il existe différents algorithmes de chiffrement inclus dans le noyau Linux, tels que Camellia, CAST5, Serpent, Twofish et CAST6.
Afin de rendre leur usage le plus transparent possible pour l’utilisateur et de permettre leur généralisation, il est essentiel que ces algorithmes soient performants et tirent profit au mieux des possibilités matérielles.
Les précédentes versions du noyau ont connu un certain nombre d’optimisations dont nous nous sommes fait le relai :
- code assembleur optimisé x86_64 de Twofish et Blowfish (Linux 3.2) ;
- code assembleur optimisé SSE2 et x86-64 de Serpent (Linux 3.3) ;
- code assembleur optimisé x86-64 de Camellia (Linux 3.4) ;
- code assembleur optimisé AVX de Serpent et Twofish (Linux 3.6).
Cette nouvelle version du noyau apporte de nouvelles optimisations :
- optimisation de Camellia pour les jeux d’instructions AES-NI, AVX et x86_64 ;
- optimisation de CAST5, Serpent, Twofish et CAST6 pour le jeu d’instructions AVX.
Pilotes graphiques pour vos PC
Intel
Les nouveautés couvrent ici principalement la stabilisation des pilotes pour deux architectures qui forment quasiment les deux bouts de la chaîne de puces graphiques du fondeur : l’antique Gen2 et le pas-encore-sorti Haswell, mais aussi la correction d’un bogue qui créait des artefacts visuels avec les dernières générations (Gen6+) :
- Prise en charge a priori stable de la partie graphique de Haswell (le successeur à venir de Ivy Bridge) ;
- Avec cette version du noyau et les pilotes ad hoc (v 2.20.12 ou supérieure), les utilisateurs de puces graphiques Intel Sandy Bridge (Gen6) et Ivy Bridge (Gen7) devraient finalement être débarrassés d’un défaut qui aura donné bien du fil à retordre aux développeurs : le tearing (des parties de l’image se scindent en bandes horizontales qui apparaissent décalées les unes par rapport aux autres pendant un court laps de temps, voir le rapport de bogue correspondant) ;
- Stabilisation des pilotes des puces i830/i845 (Gen2) commercialisées au début des années 2000 : ceux‐ci n’avaient pas vraiment apprécié le passage à l’architecture Graphics Execution Manager en 2008. Cette version du noyau, couplée avec les pilotes ad hoc (v 2.20.16 ou supérieure), règle tout cela ! Certains diront qu’Intel aura pris son temps, d’autres salueront le fait qu’Intel, non content de fournir uniquement des pilotes Linux libres pour ses puces graphiques, continue d’optimiser ses pilotes pour ses très anciennes puces.
Nouveau (pilote libre pour puces Nvidia)
La grande Nouveau‐té est que cette version du noyau permet désormais la prise en charge (2D, et 3D dans la limite de Gallium3D) de toutes les puces Nvidia, même les plus récentes (Fermi, Kepler…). Le temps que ce noyau fasse son chemin dans les différentes distributions et l’expérience utilisateur sera tout à fait confortable par défaut. Un grand bravo à l’équipe de Nouveau qui, rappelons‐le, développe entièrement par rétro‐ingénierie.
Les efforts pour permettre la gestion automatique du ventilateur, initiée lors de la version précédente du noyau, se poursuivent mais n’ont hélas pu aboutir pour cette version : croisons les doigts pour la prochaine ! De même pour le changement de fréquence — reclocking.
Le Z-buffer permet de ne calculer que la partie rendue à l’écran pour économiser notamment la bande passante. Il semble que seules les puces de génération nv20 en tiraient partie jusqu’à présent. Dorénavant les générations nv30 (GeForce 5/FX) et nv40 (GeForce 6 et 7) en profitent aussi.
Radeon (pilote libre pour puces ATI/AMD)
AMD continue de publier tout doucement les spécifications de ses puces, de sorte que la nouvelle version du noyau prend en charge les transferts de mémoire asynchrones (afin de pouvoir charger les informations en mémoire même lorsque les unités de calcul des shaders sont occupées à faire le rendu). Ceci pour les puces R600 et supérieures (voir ici et là). Il reste toutefois à mesurer les bénéfices pratiques de cette fonctionnalité (avec la version adéquate du pilote 3D).
Systèmes de fichiers Btrfs et ext4
Cette version du noyau ajoute un système de fichiers spécialisé, ainsi que nous l’avons vu. Mais qu’en est‐il des systèmes généralistes ?
Pour faire court, des modifications apportées à Btrfs (toujours considéré comme expérimental) le rendent plus rapide dans certaines conditions (voir les notes de Chris Mason à ce sujet), tandis que celles apportées à ext4 le rendent plus efficace avec des fichiers de petite taille en les stockant avec les nœuds d’index — inodes — (lire les notes de Ted Ts’o) à ce sujet.
Réseau
Pour cette version, les nouveautés (lire ici et là) sont plus limitées que dans la précédente.
Netlink
Netlink est une interface de communication entre le noyau et des processus en espace utilisateur présente depuis le noyau 2.2. Elle sert principalement à examiner, configurer et surveiller les données réseau comme les adresses IP, les tables de routage et autres paramètres. Cette interface, plus récente et moderne que la myriade d’ioctl (qu’utilisent encore les vénérables ifconfig et route), possède de nouvelles fonctionnalités dans cette version 3.8.
Il est désormais possible d’examiner, surveiller et modifier la base de données multicast des ponts réseau — bridges. C’est la table qu’utilise le noyau lorsqu’il reçoit une trame multicast sur un pont réseau pour savoir vers quels ports la trame doit être renvoyée. Toujours sur les ponts réseau, il est maintenant possible de modifier tous les paramètres via Netlink, de quoi rendre obsolète le programme brctl.
Autre nouveauté pour le multicast, mais niveau IP cette fois : l’implémentation du routage multicast IPv4 et IPv6 a été dépoussiérée, et il est maintenant possible d’examiner l’état du routage multicast via Netlink.
Une nouvelle interface permettant de modifier les paramètres réseau, auparavant présents sous forme de sysctl, a été intégrée dans ce noyau. Pour l’instant, seuls les paramètres forwarding (permettant d’activer le routage entre interfaces) et rp_filter (permettant d’activer le filtrage de l’adresse source) peuvent être modifiés et surveillés via Netlink.
La gestion de ces nouvelles fonctionnalités a bien sûr été ajoutée dans le programme iproute2, l’utilisateur principal de Netlink, qui fournit les commandes ip address, ip route et autres pour configurer le réseau de manière moderne. Ce programme utilise exclusivement les interfaces Netlink lorsqu’elles sont disponibles et sinon utilise des appels à ioctl().
Notamment, avant ce noyau 3.8, certains types de tunnels ne pouvaient pas être créés via Netlink. C’est maintenant corrigé, et cela permettra d’éliminer quelques appels à ioctl() lorsque l’on utilise ip tunnel.
Espace de nom réseau en tant qu’utilisateur
La fonctionnalité permettant de créer une pile réseau virtuelle pour isoler les interfaces et configurations réseau les unes des autres a gagné une fonctionnalité supplémentaire : il n’est plus nécessaire d’être root pour créer un espace de noms réseau — network namespace.
Un utilisateur simple pourra donc créer un espace de noms réseau, créer des interfaces virtuelles, configurer des adresses IP, ses tables de routages, son pare‐feu Netfilter (via iptables) et bien d’autres fonctionnalités, dans un environnement séparé. Comme avant, les cartes réseau originales ne pourront pas être modifiées ou utilisées dans le nouvel espace de noms, sauf si l’administrateur décide de les déplacer.
Concrètement, un processus qui crée un nouvel espace de noms réseau sera coupé du réseau physique, et pourra créer des interfaces virtuelles comme s’il était administrateur d’une machine virtuelle sans lien avec l’hôte. Mais, pour tout le reste, il restera un processus dans la machine hôte.
Pour créer un espace de noms réseau en tant qu’utilisateur, un processus devra créer un espace de noms d’utilisateurs où il se placera en tant que « super‐utilisateur virtuel ».
Les mount namespaces, les pid namespaces et les user namespaces ont aussi été modifiés pour être gérés en tant que simple utilisateur.
Wi‐Fi 802.11
Dans ce noyau apparaît un pilote pour les puces Wilocity 6210. Il s’agit du premier pilote Linux d’un matériel utilisant le standard 802.11ad. Ce standard, basé sur Wi‐Fi mais baptisé WiGig, permet en utilisant une bande de fréquences à 60 GHz, d’obtenir des débits allant jusqu’à 7 Gbit/s, mais sur des distances réduites par rapport à un réseau Wi‐Fi classique.
Ce noyau marque également le début de la gestion du standard 802.11ac. Ce standard, plus dans la continuité du Wi‐Fi 802.11n, permet des débits de 500 Mbit/s à 1 Gbit/s, notamment en permettant d’utiliser des canaux plus larges. Aucun pilote de périphérique gérant ce standard n’est pour l’instant intégré dans ce noyau, et cette fonctionnalité reste pour le moment expérimentale.
Protection contre les attaques TCP aveugles.
Le noyau 3.8 implémente maintenant le standard RFC 5961 qui vise à mitiger certaines attaques aveugles contre TCP, qui peuvent permettre à un attaquant de terminer une connexion voire d’injecter des données dans le flux. La faiblesse vient des numéros de séquence de TCP. Un attaquant cherchant à couper une connexion TCP sans avoir accès au contenu de la connexion a besoin de deviner un numéro de séquence valide. Or, un numéro de séquence valide n’a pas besoin de correspondre exactement à la valeur attendue, mais peut être légèrement supérieur, jusqu’à une valeur Receive Window, négociée lors de l’établissement de la connexion. Mais, la taille de cette fenêtre n’a cessé de croître avec le temps pour augmenter les performances, ce qui fait qu’un attaquant peut deviner un numéro de séquence plus facilement.
Pour éviter ces attaques, la RFC 5961, maintenant implémentée dans ce noyau 3.8, recommande de ne pas accepter les demandes de coupure de connexion qui ne tombent pas exactement sur la valeur attendue, mais à la place, de renvoyer un paquet ACK contenant le numéro de séquence attendu. Si la demande était légitime, alors le pair renverra une demande avec un numéro de séquence exact, garantissant sa légitimité. Comme cela ne change pas le protocole TCP, cette solution peut être implémentée dans ce noyau sans casser la compatibilité avec les autres systèmes.
Autres nouveautés
D’autres petites nouveautés sont apparues dans ce noyau ; Linux gère maintenant les cartes réseau capables de calculer les sommes de contrôles de paquets encapsulés dans des tunnels. Il est maintenant possible de filtrer en fonction du réseau local virtuel (VLAN) dans un filtre Berkeley, le traduction d’adresses réseau (NAT) gère mieux les changements de routages et le noyau gère maintenant les extensions DOVE pour VXLAN, qui permettent d’utiliser VXLAN sans multicast IP.
Virtualisation
La prise en charge des architectures ARM par KVM a été repoussée. Peut‐être pour la 3.9 ?
Deux fonctionnalités importantes pour le conteneur sont disponibles dans cette version : la limitation de la mémoire noyau pour un cgroup et les espaces de noms utilisateur.
Limitation de la mémoire noyau
Les contraintes d’utilisation mémoire d’un cgroup concernent maintenant également la mémoire noyau. Cela permet de confiner les attaques de type « fork‐bomb » ou des congestions réseau à un conteneur.
Espace de noms utilisateur
Le but est de ne pas considérer l’utilisateur root d’un conteneur comme le root de l’hôte. Cela se fait par une table de correspondance associée au processus. On peut lire cette table dans /proc/PID/uid_map. Les groupes sont évidemment gérés de la même manière.
Statistiques
En ce qui concerne les statistiques du cycle de développement du noyau 3.8, le total des patches s’établit à 12 394, alors qu’il était de 11 990 pour le noyau précédent. C’est à nouveau un chiffre très élevé, même si l’on compare aux précédentes versions en remontant assez loin.
L’accroissement net du nombre de lignes de code est d’environ 225 000.
Selon les statistiques du site remword, 1 305 personnes différentes ont participé à l’écriture des patches de ce nouveau noyau (1 316 développeurs pour le précédent). Le contributeur le plus prolifique est encore une fois H. Hartley Sweeten avec 426 patches (soit 3,44 %). Mais si l’on tient compte du nombre de lignes de code, il s’agit alors de Greg Kroah‐Hartman (47 613 lignes, soit 5,21 %, en 80 patches) et H. Hartley Sweeten n’est plus « que » deuxième (37 580 lignes, soit 4,11 %).
À suivre avec la version 3.9…
Aller plus loin
- What’s new in Linux 3.8 — The H Open (561 clics)
- KernelNewbies 3.8 page (312 clics)
# OpenCL, Intel, hem...
Posté par ParaDoxe . Évalué à 2.
Toujours pas de support d'OpenCL pour le pilotes Intel. :(
[^] # Re: OpenCL, Intel, hem...
Posté par BAud (site web personnel) . Évalué à -8.
peux-tu élaborer ?
Fais-tu référence à http://linuxfr.org/users/zezinho/journaux/un-nouveau-joli-testeur-de-carte-graphique-proprietaire-pour-linux-unigine-valley qui montre qu'Intel fait peut-être d'abord de l'open-source pour les pilotes graphiques sous Linux, mais parfois d'abord du propriétaire sous d'autres OS ? (pas forcément dans cet ordre).
[^] # Re: OpenCL, Intel, hem...
Posté par ParaDoxe . Évalué à 3.
Je faisait juste référence à l'absence de support de l'OpenCL dans le pilote libre pour les cartes graphiques Intel. Il n'y a aucune sous-entendu là dedans.
[^] # Re: OpenCL, Intel, hem...
Posté par BAud (site web personnel) . Évalué à -7.
un peu tout de même : OpenCL permet d'utiliser le GPU en supplément du CPU. Intel le permet sous d'autres systèmes que Linux ?
[^] # Re: OpenCL, Intel, hem...
Posté par ParaDoxe . Évalué à 1.
C'est hors propos. La news parle du Kernel Linux et j'en fais de même.
[^] # Re: OpenCL, Intel, hem...
Posté par BAud (site web personnel) . Évalué à -3.
Ma question naïve, t'aurait permis d'indiquer ce que tu souhaitais en faire sous Linux, quelles applis en bénéficient ou auraient pu en bénéficier (en libre, tu auras traduit). Visiblement, tu es insatisfait, reviens à la prochaine version :-) En indiquant ce que tu en attends, cela peut permettre d'indiquer ce que cela apporte (j'en ai quelques idées, outre BOINC mais je préférerais que tu parles de tes utilisations).
[^] # Re: OpenCL, Intel, hem...
Posté par ParaDoxe . Évalué à 5.
C'est surtout pour être utilisé avec des applications comme Darktable ou les futures versions de GIMP.
[^] # Re: OpenCL, Intel, hem...
Posté par BAud (site web personnel) . Évalué à -7.
Cela sert à quoi, concrètement ? Passer par le CPU fournit la fonction, en quoi utiliser le GPU améliore les choses. Bon, j'arrête de te prendre par la main, si tu ne sais pas dire ce que ça apporte, c'est que tu t'en passes sous Linux (alors que cela pourrait apporter pas mal de choses, si tu ne veux pas en parler, c'est ton problème, moi je n'en ai pas le besoin :D).
Et pourtant, je connais bien les traitements graphiques (c'est particulièrement intéressant et plus complexe que ceux que certains croient, cf. gmic) : comment les utiliserais-tu, qu'est-ce que cela te permettrait de faire que tu ne peux faire aujourd'hui ?
[^] # Re: OpenCL, Intel, hem...
Posté par ParaDoxe . Évalué à 5.
Il n'est pas nécessaire de donner autant de détails.
Si tu connais aussi bien domaine du traitement graphique que tu le dis, tu connais les avantages que cela apporte.
[^] # Re: OpenCL, Intel, hem...
Posté par JGO . Évalué à 7. Dernière modification le 20 février 2013 à 11:54.
Perso j'essaie d'apprendre openCL pour paralléliser des calculs. Je m'en sors en utilisant les pthreads sur mes 4 cœurs mais mais je voudrais bien utiliser le GPU pour accélérer ça encore plus. En plus openCL permet d'accélérer les transformées de Fourier, ce que les autres systèmes pour paralléliser les boucles (p.ex. pthreads, openMP) ne font pas. J'ai essayé fftw/gsl/lapack/mkl mais ça devient embêtant d'utiliser autant d'API différentes. Il y a aussi la solution CUDA mais le code devient non portable (uniquement NVidia, et en plus il faut investir dans une carte graphique de cette marque). OpenCL utilise automatiquement tous les cœurs de CPU et GPU disponibles, quels que soient la marque, dès lors qu'un driver/SDK est installé et les implémente. L'objectif ultime est que openCL me permette d'utiliser les 4 cœurs CPU + ma carte ATI + le GPU Intel intégré à la carte mère.
[^] # Re: OpenCL, Intel, hem...
Posté par Guillaum (site web personnel) . Évalué à 5.
Je ne comprend pas du tout ce que tu racontes sur le fait que que OpenCL permet d'optimiser les transformée de fourier contrairement à pthreads ou openMP.
OpenCL n'a rien de magique. Tout ce que tu peux faire avec OpenCL peut être fait avec n'importe quel api à base de thread sur CPU (TBB, openMP, pthread). Et tout ce que tu peux faire sur GPU se fait avec une autre API comme OpenGL ou DirectX. C'est juste une façon de programmer différente.
Ce qui fait la force d'openCL c'est que c'est le seul outil qui tourne autant sur CPU que sur GPU de façon unifiée. Maintenant cela ne veut pas dire que c'est transparent (en pratique il faut souvent écrire un code différent pour CPU et pour GPU), et il faut soit même faire la répartition du travail entre le CPU et le GPU (ainsi que les synchronisations/ transferts, …).
Bref, openCL est une très belle techno (malheureusement qui a du mal à s'imposer face à cuda), mais ce n'est pas un truc magique qui accélère l'internet et fait le café.
[^] # Re: OpenCL, Intel, hem...
Posté par Shuba . Évalué à 4.
Souvent les GPUs exposent des instructions hardware permettant d'optimiser les rendus graphiques, il est peut-être possible d'en tirer parti pour faire une transformée de Fourier accélérée. Après je connais pas assez quelles instructions hardware sont disponibles pour pouvoir dire si c'est effectivement le cas, mais en tout cas on peut faire des choses différemment sur le GPU.
C'est sûr, mais pour y avoir goûté ça pique vraiment, donc ça se comprend qu'on ait envie d'avoir un driver OpenCL plutôt que de devoir jouer avec des framebuffer objects, des textures, du glsl…
[^] # Re: OpenCL, Intel, hem...
Posté par Guillaum (site web personnel) . Évalué à 10.
Je me suis mal exprimé. Tout à fait d'accord que certains problèmes (typiquement une transformé de fourier) sont plus adaptés à un GPU qu'un CPU, mais cela ne veut pas dire que ce n'est pas optimisable sur CPU et que le jeux n'en vaut pas la chandelle. En ce moment on assiste à une grande passion pour le GPU, mais si les développeurs passaient autant de temps à optimiser pour CPU qu'il le font pour GPU, beaucoup de code CPU tourneraient bien plus vite.
Programmer pour GPU c'est globalement faire du C avec d’énormes contraintes. Du C où tu sais comment les données sont disposées en mémoire, du C où tu sais comment la machine charge les données. Du C où tu essayes de ne pas faire de if parce que c'est mal. Du C où tu n'aimes pas les accès aléatoire au données. Du C où tu fais toi même les copies entre la ram et le cache parce que la machine ne le fait pas pour toi. Du C sans fonctions récursives. Du C sans types "pratiques" (les doubles… LOL…).
Les instructions hardware disponibles dans un GPU sont souvent liées au pipeline graphique (globalement: remplir des triangles), qui n'est pas exposé dans OpenCL.
En pratique ce que va t'exposer OpenCL c'est certaines fonctions optimisées ou calculs vectoriels, mais tout cela est aussi disponible sur un bon CPU (sse/avx). Le truc c'est qu'avec un peu de chance, sur CPU ton compilateur va savoir exploiter cela tout seul, sur GPU il faut le faire à la main.
Ce qui fait la différence entre un GPU et un CPU c'est que l'architecture est différente, ainsi en fonction du type de problème à traiter, il est clair qu'un GPU sera plus adapté et pourra roxer à mort du pinguin en performance (en fait tout les problèmes qui peuvent se décomposer en une grosse quantité de sous problèmes identiques et indépendants nececitant beaucoup de calcul et générant peu de transactions mémoire).
Donc un GPU n'est pas une bête simple à domestiquer et un code "naïf" sur GPU ne va pas donner grand chose comparé au même code naïf sur CPU.
Essayes OpenCL… C'est la même chose, tu remplaces les framebuffer objects par des buffer objects, les textures par des images et le glsl par de l'OpenCl ;) C'est juste plus générique et permet de cibler avec le même code deux plateformes hétérogènes (CPU et GPU), mais ce n'est finalement pas si simble.
tl/dr: Le GPU c'est cool. J'aimerais bien avoir OpenCL disponible de partout sans me poser de question, mais s'il vous plait, arrêter de brandir le mot GPU de partout en disant que cela va sauver le monde et que c'est la solution à tout les problèmes, après il y a des décideurs qui écoutent…
[^] # Re: OpenCL, Intel, hem...
Posté par steph1978 . Évalué à 3.
C'est pas lui qui sait pas, c'est toi. Tu n'as qu'à chercher par toi même.
On va pas ré-expliquer une technologie connue à chaque fois qu'on la mentionne dans un message.
[^] # Re: OpenCL, Intel, hem...
Posté par antistress (site web personnel) . Évalué à 7.
rien de rien d'annoncé à ce sujet hélas, par contre OGL 3.3 en bonne voie et OGLES 3.0 acquis
# Merci !
Posté par Errata . Évalué à 10.
J'ai pas l'occasion de suivre les news sur le kernel, de fait j’apprécie beaucoup les résumés qui sont publié ici.
Merci et continuez le bon boulot =)
# Coquille
Posté par Naha (site web personnel) . Évalué à 3.
nécessitent
[^] # Re: Coquille
Posté par Brice Goglin . Évalué à 3.
L'autre coquille, c'est que les architectures NUMA n'ont pas forcément un controleur par processeur. Les Opteron et Intel (depuis Nehalem) ont un controleur mémoire intégré. Mais avant, quand le controleur n'était pas intégré, il pouvait y avoir plusieurs processeurs autour de chacun des controleurs. IBM, SGI et Bull notamment, ont longtemps fait des grosses machines NUMA comme ça, avec par exemple 2 ou 4 Itanium ou Xeon pre-Nehalem autour de chaque controleur.
# tearing et gen6
Posté par jacobus77 . Évalué à 1.
Just une précision, pour le tearing et les intel graphics gen6 le problème n'est pas encore vraiment résolu: c'est juste les infrastructures qui sont en place pour une vsync sans trop de perte de performance (et peut-être pas pour les premières révisions des gen6 sandy bridge si je me souviens bien).
[^] # Re: tearing et gen6
Posté par antistress (site web personnel) . Évalué à 2. Dernière modification le 20 février 2013 à 00:38.
J'ai beau avoir un Gen7 je n'ai pas fait gaffe à un éventuel tearing depuis mon achat (mais je ne joue pas)
Cependant ce commentaire [1] laissait entendre que c'était réglé ?
vsync, justement, c'est pas ce qui règle le problème ?
[1] https://bugs.freedesktop.org/show_bug.cgi?id=37686#c113
# Nouveau…
Posté par ariasuni . Évalué à 2.
Diantre! Je comptais utiliser Nouveau à partir de Linux 3.8, mais je pense que je vais attendre la 3.9. :/
Sacrebleu! Pas encore pour moi… (j'ai une NV50) :(
Mais au moins:
J'espère que cela donnera la visibilité et le succès que le projet mérite. Et n'oubliez pas de les aider en utilisant REnouveau.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Nouveau…
Posté par Martin Peres (site web personnel) . Évalué à 10. Dernière modification le 20 février 2013 à 02:26.
Désolé, c'est un peu de ma faute mais c'est aussi dû au fait que j'ai pas réussi à convaincre le mainteneur de la stabilité de mon code. Du coup, il a maturé durant quelques mois sur notre branche perso et a eu quelques corrections de bugs, notamment pour les nv40 :)
Pitié, faut oublier REnouveau. On a en plus besoin depuis des années :)
[^] # Re: Nouveau…
Posté par djano . Évalué à 10.
Met un gros DEPRECATED sur la page freedesktop.org ci-dessus :)
[^] # Re: Nouveau…
Posté par ariasuni . Évalué à 7.
Tu veux dire que c'est grâce à toi qu'on a nouveau, non? :)
Mettre l'avertissement en haut de page et plus visible alors, je l'avais pas vu! Faut dire que j'ai pas exploré la page non plus…
Écrit en Bépo selon l’orthographe de 1990
# LXC
Posté par Tonton Benoit . Évalué à 10.
Même pas le temps de lire la new qu'il est déjà là, à attendre d'être compilé :)
Donc on pourra lancer un conteneur LXC facilement sans être root ?
Et avec l'arrivé des user namespaces y'a plus grand-chose comme "défaut" à LXC non ?
# Statistiques étranges
Posté par Kerro . Évalué à 2.
Soit environ 600 lignes de code par jour pendant les 68 jours qui séparent cette version de la précédente.
Même si c'est le nombre de lignes des diffs, admettons.
[^] # Re: Statistiques étranges
Posté par zul (site web personnel) . Évalué à 6.
Ce n'est pas forcément le nombre de ligne de code qu'ils ont écrit en 68 jours, c'est le nombre de ligne de code qui sont rentrés dans le noyau de linus :). Certains patchs peuvent être à priori plus vieux, tout dépend combien de temps / étapes ils ont mis avant d'arriver dans le noyau mainstream.
# Désolé les mouches
Posté par ianux (site web personnel, Mastodon) . Évalué à 10.
Je vais faire mon chieur, mais F2FS n'est pas un acronyme, mais un sigle. Je ne sais pas pourquoi, plus personne n'utilise le mot sigle, il n'y a plus que des acronymes. Pourtant, ce sont deux choses différentes.
Un acronyme, comme son nom l'indique, est un sigle qui se prononce comme un mot, plutôt que d'énoncer les lettres unes à unes.
Exemple : GNOME est un acronyme, KDE est un sigle.
C'est tout pour aujourd'hui.
[^] # Re: Désolé les mouches
Posté par kursus_hc . Évalué à 10.
Pas sûr, moi j'avais lu fdeuphsse.
[^] # Re: Désolé les mouches
Posté par Maclag . Évalué à 6.
Moi j'éternue en espérant que les gens comprennent: «'k deeeee!!!»
[^] # Re: Désolé les mouches
Posté par calandoa . Évalué à 10.
Un gnome vaut mieux kde tu l'auras.
# Désolé les mouches
Posté par ianux (site web personnel, Mastodon) . Évalué à -2.
Je vais faire mon chieur, mais F2FS n'est pas un acronyme, mais un sigle. Je ne sais pas pourquoi, plus personne n'utilise le mot sigle, il n'y a plus que des acronymes. Pourtant, ce sont deux choses différentes.
Un acronyme, comme son nom l'indique, est un sigle qui se prononce comme un mot, plutôt que d'énoncer les lettres unes à unes.
Exemple : GNOME est un acronyme, KDE est un sigle.
C'est tout pour aujourd'hui.
[^] # Si les modos pouvaient effacer ce doublon…
Posté par ianux (site web personnel, Mastodon) . Évalué à 2.
J'ai une connexion de merde.
Merci
[^] # Re: Désolé les mouches
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Corrigé, merci.
# .
Posté par ianux (site web personnel, Mastodon) . Évalué à -4. Dernière modification le 20 février 2013 à 02:48.
.
[^] # celui-ci aussi
Posté par ianux (site web personnel, Mastodon) . Évalué à 4.
Pâle tentative de modif (on ne peut pas effacer le post dans le temps imparti pour le modifier ?).
[^] # Re: celui-ci aussi
Posté par Marotte ⛧ . Évalué à 10.
Nope. Ça permet de savoir que untel a écrit une connerie et s'est ravisé. :)
# RFC5691 vs RFC5961
Posté par Maxime (site web personnel) . Évalué à 5.
Dans le texte, il y a une typo sur le numéro de la RFC, il s'agit de la RFC5961 et non RFC5691.
Je me demandais au passage si cette technique n'engendrait pas de nouveaux problèmes. Je n'ai pas le temps de lire cette RFC tout de suite, et donc quand je lis "mais à la place de renvoyer un paquet ACK contenant le numéro de séquence attendu", je me demande si un attaquant ne peut pas créer un flood d'envoi de paquets ACK du serveur au client initial. Enfin, je ne suis pas sûr de comprendre vraiment l'idée en fait :). Quid des performances ?
[^] # Re: RFC5691 vs RFC5961
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
[^] # Re: RFC5691 vs RFC5961
Posté par Batchyx . Évalué à 3. Dernière modification le 20 février 2013 à 17:18.
Ça m'apprendra à m'y prendre quelques jours avant la sortie ;)
Pour les ACK bidons, il faut savoir quel but tu veut atteindre.
Si tu veux couper la connexion et que l'un des deux pair légitimes cherche à couper la connexion, je vois pas pourquoi tu aurai envie de balancer des ack bidons, rien faire est parfaitement suffisant. Les acks bidons risquent plus d'empêcher la fermeture de la connexion qu'autre chose ;)
l'ACK que tu envoie quand tu détecte le RST litigieux est un ACK TCP parfaitement classique, qui va juste servir à indiquer quel est ton numéro de séquence attendu pour que l'autre pair se synchronise. Si l'autre pair n'a pas l'intention de couper la connexion, il ne va pas renvoyer de RST quand il recevra un ACK (qu'il soit bidon ou pas). Mais s'il a effectivement l'intention de couper la connexion, alors le standard TCP classique dit qu'il doit renvoyer le RST, parce que le précédent à potentiellement été perdu.
# Pourquoi Nouveau est plus mis en avant que Radeon?
Posté par Creak . Évalué à 10. Dernière modification le 20 février 2013 à 10:20.
Hello!
De ce que j'ai compris, AMD/ATI est beaucoup plus open source-friendly que sont concurrent nVidia. La preuve en est que les spécifications des cartes du premier sont librement accessibles et elles ne le sont pas du tout pour le deuxième. C'est d'ailleurs pour cela que j'ai récemment acheté une Radeon, pour saluer l'implication d'AMD et parce que je pense que c'est la solution la plus pérenne.
Et pourtant, dans les faits, l'actualité de Nouveau se retrouve toujours plus mise en avant que celle de Radeon. C'est probablement la partie émergée de l'iceberg, il faut avouer qu'il semble y avoir moins de dev pour radeon que pour nouveau, mais je ne comprends pas pourquoi… Surtout quand Linus fait un gros fuck à nVidia, je comprends pas qu'on continue de vouloir mettre en avant leurs cartes plutôt que celles d'AMD.
Y a-t-il une raison que je ne verrai pas?
PS: Excellente dépêche, comme toujours… kodos à tous les rédacteurs!
Merci,
Creak
[^] # Re: Pourquoi Nouveau est plus mis en avant que Radeon?
Posté par MTux . Évalué à 2.
Question de performances du pilote…
[^] # Re: Pourquoi Nouveau est plus mis en avant que Radeon?
Posté par Adrien . Évalué à 4.
euh sources ? Entre nouveau et radeon, les performances sont à mon avis du côté du dernier des cartes équivalentes…
Peut-être aussi qu'on parle moins de radeon parce que ça marche ? Je me souviens qu'il y a quelques années les pilotes wifi faisaient parler d'eux… aujourd'hui ça marche et c'es silence radio.
Le jour où radeon sera bon sur la 3D ou openCL, on risque d'en entendre parler…
[^] # Re: Pourquoi Nouveau est plus mis en avant que Radeon?
Posté par MTux . Évalué à 3.
Je pensais plutôt au pilote propriétaire Nvidia.
Il marche bien et offre d'excellentes performances.
Historiquement, fglrx (pilote propriétaire ATI) était une vraie plaie et tout sauf fiable. Non seulement c'était la galère pour l'installer mais en plus tu avais souvent des crash. Aujourd'hui les choses vont mieux mais il garde sa mauvaise réputation.
Quand au pilote radeon il est très bon mais en deçà du pilote propriétaire au niveau des performances.
[^] # Re: Pourquoi Nouveau est plus mis en avant que Radeon?
Posté par bobble bubble . Évalué à 3.
le silence "radio" pour les pilotes wifi, ca explique bien pourquoi on ne voit rien de nouveau sur les pilotes "graphiques"
pour avoir testé trois fabricants de cartes graphiques, j'ai trouvé que nvidia avec son pilote proprio s'en sort le plus honorablement : les applis opengl sont fluides même dessus le joli compiz, seul problème effectivement : le rendu des couleurs est trop poussé, si je peux me permettre cette mauvaise traduction ça va jusqu'à teindre mon blanc noyau
j'imagine que c'est aussi une raison du succès de nouveau, cette volonté de rendre libre ces belles perfs que le pilote proprio d'amd ne m'a pas montrées. Par contre je comprends mal pourquoi ces fondeurs de gpu s'associent aussi timidement au libre, sauf intel qui n'a rien à perdre vu la qualité de ses chipsets. Si qq'1 peut m'aiguiller, je suis preneur
[^] # Re: Pourquoi Nouveau est plus mis en avant que Radeon?
Posté par Batchyx . Évalué à 3.
La différence entre les pilotes wifi et les pilotes graphiques, c'est que personne ne comprend rien à wifi.
[^] # Re: Pourquoi Nouveau est plus mis en avant que Radeon?
Posté par bobble bubble . Évalué à 2.
à la base, c'était un jeu de mollet : le silence radio pour des pilotes wifi, je trouve ça drôle.
Heureusement que les commits ne sont pas intégrés en fonction de la compréhension des utilisateurs finaux ;)
[^] # Re: Pourquoi Nouveau est plus mis en avant que Radeon?
Posté par reynum (site web personnel) . Évalué à 2.
Je serais aussi très intéressé par une réponse d'un utilisateur avisé à la question ci-dessus.
kentoc'h mervel eget bezan saotred
[^] # Re: Pourquoi Nouveau est plus mis en avant que Radeon?
Posté par reno . Évalué à 2.
Les spécifications partielles des cartes sont librement accessibles, pour autant que je sache AMD/ATI n'a jamais fourni les spécifications de la partie décodeur vidéo intégré dans ses cartes.
Et non, refaire la même chose en utilisant la partie graphique, ça n'est pas pareil au niveau utilisation de la batterie pour les ordinateurs portables.
[^] # Re: Pourquoi Nouveau est plus mis en avant que Radeon?
Posté par Creak . Évalué à 10.
Ca reste toujours infiniment plus que ce que fait nVidia pour le monde libre.
A un moment il faut aussi soutenir les entreprises qui vont dans ce sens, plutôt que d'investir toutes nos ressources dans le retro-engineering de cartes graphiquesn, tout ça pour un constructeur qui à l'air de se foutre de Linux comme de sa première chaussette.
[^] # Re: Pourquoi Nouveau est plus mis en avant que Radeon?
Posté par reno . Évalué à 10.
Je ne dis pas le contraire.
Plutôt faux puisqu'ils ont porté leurs pilotes sur Linux, que NVidia en ai rien à faire du libre, ça oui par contre.
[^] # Re: Pourquoi Nouveau est plus mis en avant que Radeon?
Posté par misaflo (site web personnel) . Évalué à 6.
Tout à fait.
De plus AMD ne fait pas que publier certaines spécifications de ses cartes, mais participe aussi (un peu) au développement des pilotes libres (radeon) et de mesa (http://developer.amd.com/tools/open-source/).
J'ai un radeon HD 6450 (entrée de gamme), les pilotes libres marchent bien, malgré les faibles performances en 3D comparées aux proprios (mais ça s'améliore doucement au fil du temps).
[^] # Re: Pourquoi Nouveau est plus mis en avant que Radeon?
Posté par Maclag . Évalué à 10.
C'est pourquoi, quand on n'a pas besoin de performances qui tuent la mort, on prend du Intel tout intégré. Ça juste marche, c'est juste rapide, et c'est développé directement en licence Libre par le constructeur.
Vu les perfs des pilotes AMD/ATI et l'effort démesuré du constructeur pour améliorer les perfs, faudrait voir si une carte entrée de gamme Radeon avec pilote libre fait vraiment beaucoup mieux que les bons procos Intel. Sinon c'est aussi une solution pour le chauffage l'hiver…
[^] # Re: Pourquoi Nouveau est plus mis en avant que Radeon?
Posté par reno . Évalué à 10.
Parce que les devs de Nouveau communiquent plus que ceux pour AMD?
# ordonnancement NUMA
Posté par Brice Goglin . Évalué à 5.
Le problème est justement qu'il ne faut que ce soit uniquement l'ordonnanceur qui gère ça. Si les données sont bien réparties en mémoire, il arrivera peut-etre à répartir les processus près de leurs données tout en équilibrant bien la charge parmi les processeurs. Mais dans la plupart des cas, mettre les processus près de leurs données va imposer un déséquilibre de charge de calcul.
Et on se pose alors la question de migrer certaines données vers un autre noeud NUMA. En gros il faut répartir les données et les calcul en même temps, pas l'un puis l'autre.
Au final, il faut que l'ordonnanceur et la gestion mémoire se mettent d'accord sur une de ces stratégies :
1) est-ce qu'on migre les processus près des données (pas très cher, mais peut déséquilibrer la charge de calcul)
2) est-ce qu'on migre les données près des processus (cher, équilibre mieux la charge de calcul)
3) ne rien faire, équilibrer la charge et avoir éventuellement des processus qui utilise des données loin d'eux, et donc plus lentement.
Comparer ces trois approches est très difficile car ça impose de connaître les schémas d'accès mémoire des processus pour évaluer les différents surcoûts ci-dessus.
[^] # Re: ordonnancement NUMA
Posté par xcomcmdr . Évalué à 2.
Corrigé !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: ordonnancement NUMA
Posté par Brice Goglin . Évalué à 1.
Merci
# Système de fichiers pour Flash
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Holà, non, je ne crois pas. Il y a deux types de périphériques à mémoire Flash :
Ce nouveau système de fichier vise visiblement les premiers.
Voilà : tout comme YAFFS, JFFS2, LogFS et UBIFS, cela viste les mémoires Flash à accès plus ou moins direct, contrairement aux SSD, clefs USB ou cartes SD.
Oulà, oulà, c'est fait pour quel type de périphérique finalement ?
FAT, exFAT, ça c'est clairement destiné aux périphériques à accès bloc avec FTL intégrée : les SSD, clefs USB et cartes SD par exemple.
[^] # Re: Système de fichiers pour Flash
Posté par ymorin . Évalué à 7. Dernière modification le 20 février 2013 à 13:42.
Justement, non. J´ai assisté à la présentation faite par un ingé de Samsung lors de la dernière ELC-E, et f2fs est clairement fait pour les périphériques avec FTL (eg. les SDcards).
D'ailleurs, on sentait bien derrière ses explications, qu'ils (les dev. f2fs) avaient beaucoup discuté avec leurs collègues hardeux qui concevaient ces SDcards.
http://elceurope2012.sched.org/event/43d200d4be7a9971f268e521af3dffaf
http://elinux.org/images/8/81/A_New_File_System_Designed_for_Flash_Storage_in_Mobile.pdf
http://free-electrons.com/pub/video/2012/elce/elce-2012-hwang-f2fs-filesystem-flash-storage.webm
Hop,
Moi.
[^] # Re: Système de fichiers pour Flash
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
On a donc un système de fichiers optimisé pour des contrôleurs d'adaptation de Flash optimisés pour les systèmes de fichiers standard. Bien bien… En tout cas ça vaudrait la peine de l'indiquer clairement je pense.
[^] # Re: Système de fichiers pour Flash
Posté par ymorin . Évalué à 8.
Ouais. Ça fait un peu bizarre à lire, mais c´est exactement ça.
Alors que, si on avait directement accès à la flash, ou un moyen de charger un
firmwarealternatif, on pourrait implémenter notre propre algorithme dewear-leveling, voire même utiliser différents algorithme en fonction de l'utilisation.En plus, ces
firmwaresfont souvent un travail de sagouin, sont peu optimisés, parfois même peu fiables (parfois au point de rendre inutilisable une flash toute neuve, même après unpower-off! ).Mais non. Faut que ça marche sous Windows, le reste on s´en fout.
Hop,
Moi.
[^] # Re: Système de fichiers pour Flash
Posté par Aissen . Évalué à 6.
Ce n’est pas aussi simple car l’objectif de Samsung est de mettre ça dans des appareils mobiles qui utilisent souvent une eMMC. Certaines des ces eMMC sont faites par Samsung, et dans tous les cas, l’ensemble des propriétés des FTL de ces cartes sont connues par Samsung… C’est donc un avantage, car les deux (le FS et le FTL de la carte) s’emboîtent alors très bien. Il y a très peu d’amplification d’écriture par exemple.
Là où le bas blesse c’est lorsqu’on veut utiliser F2FS sur une carte SD dont on ne connaît pas les propriétés (les tailles de blocs), et ben ça n’est plus du tout efficace. Et rien n’est prévu dans le filesystem pour "découvrir" les paramètres de la SD sous-jacente, il faut le tuner selon les propriété de la carte, ce qui n’est pas un problème pour Samsung, mais un peu plus pour un bidouilleur dans son coin.
J’ai reprit une partie de ce qui est expliqué ici: http://lwn.net/Articles/518988/
[^] # Re: Système de fichiers pour Flash
Posté par Maclag . Évalué à 5.
Donc si je comprends bien, Samsung a intégré au noyau un système de fichier qui ne marche bien que sur des appareils Samsung?
Ils auraient peut-être dû l'appeler SamsungFS!
D'un autre côté, c'est Libre: on peut bien ajouter cette phase découverte sur le périphérique, ou on peut espérer que les constructeurs vont en profiter pour standardiser tout ce bordel pour que les benchmarks faits à l'arrache ne les enfoncent pas trop…
[^] # Re: Système de fichiers pour Flash
Posté par antistress (site web personnel) . Évalué à 2.
F2FS File-System Runs Great On SDHC Storage
http://www.phoronix.com/scan.php?page=article&item=linux_f2fs_sdhc&num=1
# Félicitations
Posté par maboiteaspam . Évalué à 1.
That's it, that's all.
Félicitations pour cette nouvelle news collaborative !
Allez hop -1 pour futilité, Avec le sourire : )
# erreur d'historique?
Posté par ZeroHeure (site web personnel) . Évalué à 3.
N'y-a-t-il pas une erreur dans l'historique du noyau? il me semblait (ça remonte loin!) qu'Alan Cox avait effectué le premier portage de Linux, vers m68k, (pas tout à fait officiel peut-être), et que c'était ce travail qui avait rendu le noyau portable.
J'ai cherché un petit peu, sans retrouver, mais si c'est bien ça, faudrait rendre justice à m'sieur Alan.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: erreur d'historique?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Vers l'alpha, je pense, premier port de Linux.
"La première sécurité est la liberté"
[^] # Re: erreur d'historique?
Posté par ymorin . Évalué à 2.
A quand un processeur Oméga, pour enfin dire que Linux, c´est l´Alpha et l´Oméga ?
Hop,
Moi ---> [].
# C'est de la bombe
Posté par shingo (site web personnel) . Évalué à -4.
J'ai installé et configuré le kernel 3.8, il marche très bien et même mieux que le précédent. Je trouve que c'est plus rapide, mais là où j'ai senti une grosse différence c'est avec les yeux Steam qui sont généralement plus fluide !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
# i386
Posté par Thom (site web personnel) . Évalué à 3.
Mon premier ordinateur…
Adios, amigos.
La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
# Vraiment plus performant et plus stable
Posté par shingo (site web personnel) . Évalué à 1.
Du moins chez moi. Le kernel 3.7.9 n'était pas très stable avec l'ahci activé dans le bios. J'avais sans cesse des kernel panic et des erreurs sata3 mais depuis que je suis passé au kernel 3.8, c'est parfait. Aucun kernel panic de la journée ! J'ai trouvé les jeux sur Steam, plus fluide, un gain de quelques FPS et un chargement plus rapide.
Vraiment c'est du bon travail !
[^] # Re: Vraiment plus performant et plus stable
Posté par tyoup . Évalué à 2.
Ouais, en gros c'est de la bombe ! :-)
[^] # Re: Vraiment plus performant et plus stable
Posté par X345 . Évalué à 9.
Moi depuis que j'ai installé le kernel 3.8, j'ai trouvé une copine, j'ai une grosse caisse et il y a moins d'ondes électromagnétiques dans ma maison.
# monde professionnel
Posté par PLuG . Évalué à 2.
la 2.2 sort un an plus tard, en janvier 1999, avec la prise en charge des m68k et PowerPC, puis, en fin d'année (avec la 2.2.13), des IBM mainframe, ouvrant Linux au monde professionnel ;
C'est un lancé de troll ou bien sans mainframe pas de professionnels ?
Cette phrase m'a un peu surprise, mais je dois être le seul puisque personne ne l'a relevé :-)
[^] # Re: monde professionnel
Posté par antistress (site web personnel) . Évalué à 2.
C'est sans volonté de troller, je sais plus où j'ai piqué ça c'est pas mon domaine de compétence..!
[^] # Re: monde professionnel
Posté par Maclag . Évalué à 5.
Je ne dirais pas que j'ai les réponses, mais je peux faire des suppositions:
Avec un Linux un peu jeune, les portages auraient pu passer pour des bidouillages de geeks passionnés. Les processeurs m68k et même PowerPC étaient déjà accessibles au grand public.
En passant aux mainframes IBM, Linux a gagné ses lettres de noblesse (support IBM? intérêt de clients clés?). C'était peut-être un élément déclencheur de l'essor de Linux dans le monde professionnel comme solutions viable?
# Le noyau casse la WIFI sur certains ordinateurs portables
Posté par GRONDIN Bertrand (site web personnel) . Évalué à -1. Dernière modification le 05 mars 2013 à 18:10.
Les versions 3.8.1 et 3.8.2 casse la WIFI.
J'ai une distribution Debian wheezy/sid, et dispose d'un ordinateur portable ASUS K73S.
Ce problème a été aussi évoqué sur cette page.
# lguest introuvable
Posté par hamador . Évalué à 0. Dernière modification le 10 avril 2013 à 11:41.
Bonjour,
Avez vous réussi à recompiler le noyau 3.8 ?
En effet, que je tente de recompiler le noyau 3.8 ou 3.*, j'ai une erreur de compilation car il lui est impossible de trouver la Documentation lguest.
Savez vous où je peux l'a trouver ?
Après une recherche, il y aucune référence à lguest dans le dossier Documentation du tar.
Du coup, il m'est impossible de le recompiler. J'ai aussi tenté de récupérer la documentation lguest du 3.0 puis l'a placer dans le dossier Documentations du 3.8 mais ça ne fonctionne pas mieux.
Merci bien pour votre aide
[^] # Re: lguest introuvable
Posté par hamador . Évalué à 0.
Tracelog
make[1]: quittant le répertoire « /usr/src/linux-3.8.6 »
/usr/bin/make EXTRAVERSION=-20130509 ARCH=i386 \
-C Documentation/lguest
make: *** Documentation/lguest: Aucun fichier ou dossier de ce type. Arrêt.
make: *** [debian/stamp/build/kernel] Erreur 2
[^] # Re: lguest introuvable
Posté par heinquoi . Évalué à 0.
MDR. Merci Hamador.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.