La sortie de la version stable 4.4 LTS du noyau Linux a été annoncée le 10 janvier 2016 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 se trouve dans la seconde partie de la dépêche (qui est sous licence CC BY-SA, Attribution — Partage dans les Mêmes Conditions)
Sommaire
- En bref
- Annonces des RC par Linus Torvalds
-
Les nouveautés
- Gestion de la mémoire
- Architecture
- Développement et traçage
- Pilotes graphiques libres
-
Réseau
- Optimisation de la poignée de main TCP
- Encore plus rapide avec SO_REUSEPORT
- Et si on ajoutait la gestion fine de CPU ?
- Nouvelles méthodes de détection de pertes de paquets
- Passage à la micro-seconde pour le temps de transmission durant la poignée de main TCP
- Du changement dans les routes à chemins multiples en IPv4
- En bref
- Sécurité
- Périphériques en mode bloc (block devices)
- Systèmes de fichiers
- Virtualisation
- Cgroups
- Le bilan en chiffres
- Appel à volontaires
En bref
Au terme de deux années d’efforts, le code gérant TCP a été réorganisé, procurant une implémentation de bien meilleure qualité, avec des gains de performances pouvant dépasser 100 fois dans certains scénarios de serveurs TCP.
Un nouveau mécanisme d’entrée/sortie fait son apparition. S’il est encore expérimental et désactivé par défaut, il pourrait à terme compléter le mode de lecture des périphériques en mode bloc, en permettant une lecture séquentielle à plus haut débit.
Le mécanisme BSD Packet Filter du noyau a connu plusieurs évolutions importantes. Le principal changement est l’ouverture partielle de l’API aux programmes non privilégiés ; un code en espace utilisateur peut désormais utiliser l’appel système
bpf()pour placer un filtre sur un socket. Ce nouveau noyau permet aussi de créer des filtres persistants, c’est-à-dire, qui peuvent être conservés malgré l’arrêt du processus, puis repris par un nouveau processus. Enfin, ce système eBPF a été intégré à perf, l’outil de mesure des performances interne à Linux.Les utilisateurs de partitions ext4 chiffrées sont encouragés à passer à Linux 4.4 ou à utiliser des noyaux dans lesquels les corrections ont été rétro-portées : un bug menant à une corruption de données a été corrigé, ainsi qu’une fuite de mémoire.
Comme d’habitude, la grande majorité des commits est consacrée aux pilotes de matériel, tant pour améliorer la gestion de l’existant (portables Toshiba, etc.) que pour accepter de nouveaux matériels (nouvelle puce Realtek WiFi USB, Intel Skylake W8 touchpad, etc).
Annonces des RC par Linus Torvalds
RC-1
La version RC-1 est sortie le dimanche 15 novembre 2015 :
C’est dimanche, deux semaines sont passées et par conséquent, la 4.4-RC1 est parue et la fenêtre de fusion fermée.
Comme d’habitude, l’historique complet des changements est trop important pour être publié, vous trouverez donc en annexe le journal des fusions montrant l’origine des intégrations avec un petit commentaire sur chaque fusion.
Si on regarde l’ensemble des modifications en elles-mêmes, tout semble plutôt normal d’un point de vue général, même si les pilotes représentent peut-être une plus grosse part que d’habitude (75 % des correctifs) et les mises à jour d’architectures environ 10 %. Les 15 % restants se répartissent entre la documentation, les systèmes de fichiers, le cœur du réseau (par opposition aux pilotes réseau), l’outillage et les infrastructures cœur.
Les changements sur les pilotes sont partout, bien que les pilotes de préproduction, de réseau et de GPU ressortent (et ces trois parties comptent pour plus de la moitié des changements sur les pilotes – aux alentours de 40 % de l’ensemble des changements).
Du côté des architectures, l’ARM (en prenant en compte le 32 et le 64 bits) compte pour à peu près la moitié des changements, alors que x86, PowerPC, MIPS, chris et S390 comptent pour l’autre moitié.
Allez-y, testez.
Linus
RC-2
La version RC-2 est sortie le dimanche 22 novembre 2015 :
Tout semble plutôt normal du côté de la 4.4 sans grosses surprises dans la RC-2. Il y a eu quelques ajouts tardifs de fonctionnalités : la prise en charge des hugepages sur PA-RISC et quelques corrections concernant l’allocateur mémoire noyau slub ont seulement été fusionnées à la fin de cette semaine, mais à vrai dire, elles auraient dû faire partie de la fenêtre de fusion.
Mais le système d’allocation mémoire de masse n’est pas encore vraiment utilisé dans l’arborescence et donc, les mises à jour de ce côté portent sur une utilisation future plutôt que sur quelque chose qui pourrait régresser. Quant à PA-RISC, je n’arrive pas à trouver une raison de m’en inquiéter : je mets volontiers au défi tout utilisateur de PA-RISC de me prouver le contraire et de montrer comment la nouvelle fonctionnalité provoque une régression.
Amenez-vous pour voir.
Le gros des changements depuis la rc-1 (de loin) se situe dans les pilotes (environ 70 % de correctifs — les pilotes réseau et GPU en représentant la plus grande part), avec des mises à jour d’architecture (12 %, avec PA-RISC et S390 étant les deux plus grosses mises à jour) et la base réseau (8 %) étant l’essentiel du reste. Les 10 % restants sont dispersés ; fs (systèmes de fichiers), mm (gestion de la mémoire) et les outils de performance en représentant la plus grande part.
Le journal abrégé est joint. Vous pouvez y voir un aperçu des changements. Je ne peux pas vraiment dire qu’il en ressorte quelque chose de particulier.
Allez-y, testez.
Linus
RC-3
La version RC-3 est sortie le dimanche 29 novembre 2015 :
Je suis sorti presque toute la journée, donc, elle arrive quelques heures plus tard que d’habitude, mais elle est là, la RC hebdomadaire usuelle. « Progrès constant vers la 4.4 ».
Les changements semblent plutôt normaux : un peu moins de 60 % de mise à jour de pilotes (parmi lesquels près de la moitié sont des mises à jour de GPU, cette fois principalement biaisé par des correctifs de mises à jour des firmwares nouveau), environ 25 % de mises à jour d’architectures (principalement arm[64], mais aussi quelques changements dans x86, s390, powerpc, nios, mips, m68k, arc…) et environ 10 % de mises à jour de systèmes de fichiers. Le reste étant « divers » (principalement des fichiers d’en-tête).
Le journal abrégé ci-joint donne un aperçu des détails. Je ne pense pas qu’il y ait grand-chose d’enthousiasmant, bien que cela dépende évidemment du fait que vous ayez été affecté par un problème particulier, ou pas. Il est constitué principalement de petites corrections diverses.
Linus
RC-4
La version RC-4 est sortie le dimanche 6 décembre 2015 :
Une nouvelle semaine, une nouvelle rc. Nous avons eu un peu plus de commits que la semaine dernière (principalement dus à la fusion des correctifs réseau), mais dans l’ensemble, ça a été plutôt calme.
Tout semble plutôt normal : environ 70 % de pilotes – les pilotes réseau, gpu, audio, et scsi dominent. De surcroît, nous avons 15 % de cœur de réseau et le reste est partagé entre mises à jour d’architectures et choses diverses un peu partout (dont quelques correctifs vfs et cœur du noyau).
Le journal abrégé en annexe donne une vue d’ensemble des détails, il est suffisamment petit pour qu’on puisse facilement le lire en diagonale.
Linus
RC-5
La version RC-5 est sortie le dimanche 13 décembre 2015 :
Une nouvelle semaine, une nouvelle rc.
La semaine a été plutôt tranquille et la RC-5 a l’air plutôt normale. Il y a eu un assez méchant bug primordial, introduit dans la RC-4, qui est désormais corrigé dans la RC-5, mais bien que cela soit un peu gênant, je ne crois pas que beaucoup de personnes aient rencontré le problème.
Mis à part ce petit problème, les choses sont tout à fait normales et il n’y a vraiment pas beaucoup de changements, et ils sont tous assez petits pour démarrer.
Donc, tout semble bon, et je pense que nous sommes sur la bonne voie pour le calendrier de sortie habituel, ce qui devrait nous amener à une version 4.4 très tôt en 2016. Je suis enclin à retarder cette version d’une semaine non pas à cause des problèmes de parution, mais tout simplement parce que je sais que les prochaines semaines vont être calmes et la plupart des gens veulent se concentrer sur autre chose que de se préparer pour la prochaine fenêtre de fusion.
On verra. Je devrais en finir et sortir la 4.4 à temps et ensuite décaler la fenêtre de fusion.
Quoi qu’il en soit, si vous avez tous finalisé vos achats de Noël, je recommande chaudement de s’intéresser de près à la RC-5 entre les cadeaux et la décoration. Et si vous ne célébrez pas les fêtes, vous n’avez aucune excuse pour ne pas tester tout ça.
Linus
RC-6
La version RC-6 est sortie le dimanche 20 décembre 2015 :
Tout continue normalement. Si la RC-5 de la semaine dernière était effectivement très petite, la RC-6, cette semaine, est un peu plus grosse. La principale différence est que la RC-6 intègre un changement réseau.
Mais, la RC-6 est toujours aussi petite, et les correctifs sont normaux : au-delà de 60 % pour les pilotes, 16 % pour le cœur de la gestion réseau, 13 % pour des mises à jour d’architectures et 10 % pour des choses diverses (de la documentation, des en-têtes de fichiers, de petites mises à jour du système de fichiers, etc.). Vous pouvez consulter les changements joints pour avoir une idée de ce qu’il s’est passé.
Je pense (et j’espère) qu’avec les vacances, la semaine prochaine continuera à être calme.
Et peut-être, je peux espérer que les gens utilisent la coupure pour jouer avec leur matériel et tester la plus récente version du noyau.
Linus
RC-7
La version RC-7 est sortie le dimanche 27 décembre 2015 :
Noël est fini, et voilà le Nouvel An, mais il n’y a pas de repos pour les développeurs noyau, et la RC-7 est par là. [En regardant le patch RC-7]
OK, clairement il y a un peu de repos pour les développeurs noyau, car la rc7 est plutôt minuscule. Je pense qu’un tiers du patch provient des mises à jour de SPARC, et ils ne sont pas énormes non plus.
Le reste provient des autres architectures (x86, PA-RISC, MIPS, ARM, arc), des pilotes (gpu, sound, mtd…) et quelques mises à jour pour compiler. Mais tout est plutôt petit.
J’espère la même chose la semaine prochaine, quand je serai certainement prêt à publier la 4.4 finale, mais je vais probablement faire une RC-8 juste pour ne pas ouvrir la fenêtre de fusion alors que les gens sont toujours en vacances.
Linus
RC-8
La version RC-8 est sortie le dimanche 3 janvier 2016 :
En général, lorsque je fais une huitième RC, c’est qu’il reste un problème non résolu qui nécessite plus de temps pour être réglé. Cette fois, c’est seulement que je veux être certain que tout le monde est rentré de vacances et qu’il ne reste rien en cours, et que tous auront le temps de préparer leurs demandes d’intégration pour la prochaine fenêtre. Vous n’aurez aucune excuse si vous n’avez pas terminé vos travaux lorsque la fenêtre d’intégration s’ouvrira.
Les changements se trouvent dans les endroits habituels, et sont plutôt petits. On y trouve pour moitié des pilotes (principalement des pilotes de réseau, mais aussi du rdma et quelques autres changements mineurs) et pour le reste des mises à jour d’architectures (surtout SPARC, ARM), du code réseau et quelques corrections dans la cryptographie.
Mais c’est vraiment très petit. C’est bien comme ça que ça doit être, avec les vacances et la fin du cycle.
Attendez-vous à la sortie de la version 4.4 finale le week-end prochain, sauf si quelque chose de très inattendu survient.
Linus
Version finale
La version finale est sortie le dimanche 10 janvier 2016 :
Rien de fâcheux n’est arrivé cette semaine, donc Linux-4.4 est disponible dans tous les endroits habituels.
Les changements depuis la RC-8 ne sont pas énormes. Il y a environ un tiers de mises à jour d’architectures, un tiers de pilotes et un tiers « divers » (principalement du cœur de noyau et du réseau), mais c’est tout petit.
Ce qui serait notable comprend la remise en état de l’ABI sysenter pour x86-32, que quelqu’un (tousse*android-x86*tousse) a mal utilisé en ne recourant pas au vdso et utilisant cette instruction à la place.
L’historique complet est annexé pour les personnes intéressées ou simplement curieuses.
Et avec ça, la fenêtre de fusion pour la 4.5 est évidemment ouverte, même si je ne vais pas vraiment commencer l’intégration demain.
Linus
Les nouveautés
Gestion de la mémoire
L’appel système mlock() permet de verrouiller en mémoire une zone d’adressage d’un programme qui contient des données cruciales (cryptographie, etc). Mais en pratique, ce verrou est parfois excessif, car on bloque une large zone de mémoire dont on ne se sert que très partiellement. Le noyau 4.4 introduit mlock2() qui permet des verrous reportés (deferred memory locking). Cette gestion plus fine de la mémoire permettra donc de diminuer certaines consommations de mémoire. Pour plus d’informations, voir la nouvelle page de man mlock et (LWN) Deferred memory locking.
Une autre modification structurelle a permis de nettoyer le code d’allocation de la mémoire. La structure zonelist_cache, introduite en 2006, était une source récurrente de problèmes, notamment sur les architectures NUMA. Plutôt que de continuer à accumuler des aménagements sur ce code, une réécriture a permis de supprimer cet élément, avec performance généralement inchangée, voire meilleure. Ce n’est pas souvent qu’on retire 240 lignes de code du noyau.
Pour plus de détails, lire l´article de LWN : Some kernel memory-allocation improvements.
Architecture
ARM SoC
Raspberry Pi : ajout d´un pilote pour communiquer avec le firmware, voir plus loin pour plus de détails.
i.MX6PU : ajout de la prise en charge du mode veille (suspend/resume) de ce SoC de Freescale.
C.H.I.P : intégration de la prise en charge du chipset Allwinner R8 présent dans cette carte. Il manque encore la gestion du Wifi (dépendante de deux régulateurs pour être alimenté) et du codec audio qui n’est pas encore activé dans le DeviceTree.
ARM SCPI : ajout d´un pilote pour le SCPI (Système de contrôle du Processeur), un système utilisé pour communiquer avec le système embarqué de gestion de consommation.
Rockchip RK3288 : ajout des domaines de puissance (Power Domain) compatible avec le module
genpdqui permet de contrôler chaque domaine et de couper le courant de manière dynamique si le module n’est plus utilisé ou en veille.Divers : prise en charge du changement de CPU à chaud pour la série des BG2Q de Marvell berlin, et du SMP pour les 4 cœurs Cortex-A7 du SoC Mediatek MT6580. Prise en charge initiale de la famille de SoC Northstar Plus de Broadcom à base de Cortex-A9.
Plusieurs mises à jour ARM64, comme une meilleure détection des fonctionnalités des cœurs ARM64 (en particulier sur des systèmes hétérogènes.), une implémentation native de fonctions atomiques et une optimisation des fonctions natives de copie depuis/vers l’espace utilisateur, ainsi qu’une mutualisation du code de gestion des compteurs de performance matériels (PMU) entre arm et arm64.
L’architecture arm64 peut maintenant fonctionner avec des pages de taille 16 Kio. Cependant, Linus a émis de sérieux doutes quant à son utilité dans le monde réel. Petite explication : l’argument en faveur d’une taille de page de 16 Kio est de pouvoir gérer plus de mémoire. Sauf qu’avec cette taille de page, vous perdez beaucoup de mémoire et augmentez la fragmentation. Cela a déjà été évoqué il y a quelques années par les personnes s’occupant de l’architecture PPC. Excepté dans des cas très spécifiques (un seul processus qui a besoin de beaucoup de mémoire et très peu de processus en parallèle), cet apport n’a que peu d’intérêt.
MIPS
- Support du programme universitaire MIPSfpga qui permet aux universités du monde entier d’intégrer gratuitement un cœur MIPS dans leurs projets ;
- Grosse évolution et nettoyage du code de démarrage MIPS qui tend à supporter le Device Tree aussi bien que son homologue ARM ;
- Ajout du support d’un nouveau cœur de test 5Ke.
Développement et traçage
L’outil de traçage du noyau perf s’est enrichi d’une dizaine de fonctionnalités, allant d’une option pour afficher en nanosecondes les marqueurs de temps à la configuration des événements à tracer. Une grande part de ces modifications est spécifique ou optimisée pour l’Intel Processor Tracing.
Le travail le plus conséquent fut l’intégration de perf à eBPF. Une commande comme perf record --event bpf-code.c /bin/ls permet désormais de compiler le code source BPF et de charger ce filtre dans le noyau pour récupérer la trace noyau des événements sélectionnés.
Pilotes graphiques libres
Direct Rendering Manager
Le code commun des pilotes DRM a gagné la capacité de sonder les différents CRTC et encodeurs disponibles pour les systèmes utilisant un device tree. Ce code permet de factoriser le code de plusieurs pilotes.
L’interface fbdev au-dessus des pilotes DRM utilise maintenant la gestion du mode graphique atomique lorsque celle-ci est disponible afin de réduire le nombre de mises à jour du mode, et réduire ainsi les clignotements.
Pour plus d’informations, vous pouvez consulter la demande d’intégration DRM.
AMD (pilotes amdgpu et radeon)
Les pilotes amdgpu et radeon continuent d’évoluer, avec beaucoup de petites améliorations et un gros travail de fond avec l’ajout d’options de débogage, la gestion de nouveaux opcodes, l’activation du nouvel ordonnanceur GPU, et divers portages depuis radeon vers amdgpu.
Broadcom (pilote vc4, RPi)
Fruit de l’important travail débuté il y a un an et demi par Eric Anholt (ex Intel, recruté à cet effet par Broadcom), le pilote graphique libre pour les puces Broadcom VideoCore 4, utilisées par le Raspberry Pi, est maintenant intégré partiellement au noyau. Seules les parties KMS et 2D sont incluses ; la gestion 3D exigera de pouvoir se passer du firmware propriétaire pour la gestion d’énergie puisque l’IOMMU refuse actuellement l’accès au registre depuis les processeurs ARM ; les registres sont également non documentés. Le code inclut la gestion de HDMI, sans HDCP. Il est encore impossible d’initialiser le système sans logiciel propriétaire.
La gestion de la 3D fera son apparition dans Linux 4.5 (commit).
Intel (pilote i915)
Le processus de conversion du pilote i915 vers une gestion atomique du mode graphique continue avec l’ajout d’une base solide permettant de s’approprier le mode graphique utilisé par le firmware EFI (fastboot). Malheureusement, un bug a été trouvé tard dans le code ce qui a forcé à désactiver le code par défaut. À propos de la gestion atomique encore, le code permettant la validation et gestion dynamique de la fréquence d’horloge des CRTC introduit dans Linux 4.3 vient d’être porté dans le monde atomique.
Toujours côté affichage, la gestion du rafraîchissement automatique des panneaux (Panel Self-Refresh) et la gestion de la compression du framebuffer ont fortement avancé. Le PSR devrait être activé dans Linux 4.6 et devrait permettre de diminuer la consommation électrique.
L’espace d’adressage passe maintenant à 48 bits pour les processeurs Broadwell+ (génération 8), ce qui devrait permettre de gérer une plus grande quantité de mémoire, mais surtout va permettre d’avoir un espace d’adressage partagé entre le CPU et le GPU.
L’envoi de commande via le microcontrôleur GuC est maintenant géré, mais pas encore activé par défaut. Le GuC devrait à terme être un ordonnanceur et être responsable de la gestion d’énergie.
Pour plus d’informations, vous pouvez consulter le traditionnel article de blog de Daniel Vetter, le mainteneur i915.
NVIDIA (pilote nouveau)
Le pilote nouveau a reçu de nombreuses améliorations liées à la gestion d’énergie, notamment le reclocking. Roy Spliet a en effet ajouté la gestion du reclocking de la mémoire GDDR3 pour les GPU G94-G200 (commit). Karol Herbst a quant à lui amélioré la fonction de calibration des PLL générant l’horloge de la mémoire GDDR5 pour les familles Kepler+ ce qui permet un reclocking bien plus fiable (commit) ! Ben Skeggs a également perfectionné la détection des GPU ayant leur moteur 3D désactivé au démarrage (PGOB = Power Gating On Boot) et activé sa gestion pour le chipset GK107. Pour finir avec la gestion d’énergie, Martin Peres a ajouté la gestion des contrôleurs de tension commandés en modulation de largeur d’impulsion (PWM) qui sont très courants pour les GPU Maxwell et certaines cartes Kepler.
Alexandre Courbot de NVIDIA a profité des nouvelles fonctionnalités apportées par la réécriture du cœur de Nouveau (Linux 4.3) pour améliorer les performances des accès à la mémoire d’instance. Le nouveau code est 40 % plus rapide. Il a également converti le code de gestion de la mémoire vidéo pour utiliser la nouvelle API de Linux pour le DMA.
Autres
Le pilote virtio-gpu, présenté dans la dépêche Linux 4.2, a enfin reçu la gestion de la 3D dans le noyau. Le code nécessaire en espace utilisateur a été écrit, fusionné dans Mesa en octobre et sorti en version 11.1 (décembre 2015). Les changements nécessaires pour QEMU sont eux disponibles à partir de la version 2.5, sortie en décembre 2015. Pour plus d’informations, vous pouvez consulter une vidéo de démonstration ainsi que la page du projet Virgil3D.
Le pilote msm pour les GPU Qualcomm ajoute une gestion expérimentale du Snapdragon 820.
Réseau
Optimisation de la poignée de main TCP
La poignée de main TCP est critique pour plusieurs raisons : elle introduit de la latence avant le moindre transfert de données et elle est source d’une vulnérabilité permettant des attaques par déni de service.
La réorganisation de cette poignée de main et l’optimisation des performances est un travail de longue haleine qui a atteint un point très intéressant dans cette version grâce à la suppression d’un verrou dans la procédure gérant les paquets SYN.
Si on prend du recul, cette poignée de main est désormais 10 à 100 fois plus rapide qu’il y a deux ans. L’ordinateur de test du développeur est capable de gérer 3,5 millions paquets SYN par secondes, tout en ayant encore du temps CPU disponible.
Encore plus rapide avec SO_REUSEPORT
Toujours à propos de cette poignée de main, l’option SO_REUSEPORT permet à plusieurs sockets d’écouter sur le même port, permettant notamment d’améliorer les performances avec un serveur multithreadé. Cette option a elle aussi été optimisée, permettant d’arriver à six millions de paquets SYN par seconde, sur la même machine de test que citée dans le paragraphe précédent.
Et si on ajoutait la gestion fine de CPU ?
Et ce n’est pas terminé. L’option SO_INCOMING_CPU existait en lecture depuis 2014 et permettait de connaître le processeur gérant le flux de données TCP de la socket. À présent, cette option est également accessible en écriture (via setsockopt()) et permet à une application de spécifier le processeur qui devrait gérer la socket. Cela étend l’idée de l’option SO_REUSEPORT, en permettant à chaque fil d’exécution d’une application de se positionner sur un processeur particulier.
Nouvelles méthodes de détection de pertes de paquets
Toujours sur TCP (et encore par un développeur de chez Google, la même entreprise que pour les optimisations de performance), une nouvelle méthode de détection de paquets perdus arrive dans le noyau Linux. Savoir si un paquet a été perdu est un problème non trivial, mais essentiel de TCP, notamment parce que cette détection est à la base de la gestion de congestion.
RACK (pour « Recent ACK ») est un nouvel algorithme qui considère comme perdu un paquet s’il n’a pas encore été acquitté alors qu’un acquittement a été reçu pour un paquet émis plus tard. Cet algorithme était en production sur des serveurs Google depuis plus d’un an au moment de la proposition de patchs. Pour plus d’informations, vous pouvez lire la demande d’inclusion ainsi que le brouillon à l’IETF.
Passage à la micro-seconde pour le temps de transmission durant la poignée de main TCP
Ce n’est pas un hasard si l’auteur de ce commit est le même que celui qui a implémenté RACK : le noyau analyse maintenant à la microseconde le temps de transfert des paquets lors de la poignée de main TCP (les paquets suivants utilisaient déjà la microseconde). Cette amélioration de la précision est nécessaire sur les réseaux locaux si on souhaite utiliser cette information dans les algorithmes de congestion.
Du changement dans les routes à chemins multiples en IPv4
Pour comprendre ce changement, il faut remonter au noyau 3.6 et la suppression du cache des routes en IPv4. Comme effet de bord de cette suppression, le routage des paquets en cas de chemins multiples pour une même route était devenu quasi aléatoire pour chaque paquet. C’est normalement peu important (en IP, chaque paquet devrait être indépendant), mais dérange certaines applications qui attendent les paquets dans l’ordre (et augmente dans tous les cas le coût de traitement pour les applications qui savent réordonner des paquets arrivés dans le désordre).
Afin que les paquets appartenant à un même flux de donnée utilisent la même route (et arrivent donc probablement dans le bon ordre), Peter Nørlund a ajouté le calcul d’un condensat (hash) prenant en entrée les adresses IP source et destination. Tous les paquets ayant le même hash prendront le même chemin.
Dans les détails non triviaux, les paquets d’erreurs en ICMP sont également gérés (il faut regarder des adresses à l’intérieur d’un paquet, cela complexifie beaucoup le traitement). Cette fonctionnalité est indispensable pour que la découverte de la MTU continue de fonctionner correctement. En revanche, les identifiants de niveau supérieur (comme les ports en TCP et UDP), qui permettraient de mieux discriminer les flux, ne sont pas lus. Cette faiblesse d’identification des flux est une limitation d’IPv4 : en IPv6, on pourrait utiliser la lecture des labels de flux exactement pour ce cas d’usage.
En bref
L’ICMP avec IPVS
En parlant de chemins multiples et de gestion des erreurs ICMP pour découvrir la MTU, IPVS est un répartiteur de charge pour le noyau Linux. Facebook l’utilise, mais a fait face à un problème : les paquets ICMP signalant des erreurs ne sont pas transmis à l’instance source de l’erreur, provoquant notamment des problèmes de découverte de MTU. La série de correctifs ajoute une nouvelle option sysctl, qui permet de corriger ce problème. Le comportement par défaut ne change pas.
Les VRF fonctionnent désormais en IPv6
Nous en parlions dans la dépêche du noyau 4.3, les Virtual Routing and Forwarding (VRF) ont fait leur entrée dans le noyau Linux, mais ne fonctionnaient pas pour IPv6. C’est désormais corrigé, elles sont pleinement fonctionnelles avec les deux versions du protocole IP.
Identifiant de la table FIB en IPv4
Cette information était déjà disponible en IPv6, elle arrive en IPv4 : l’identifiant de la FIB est désormais inclus dans les informations de la table de routage.
Les tunnels Geneve en IPv6
Les tunnels Geneve sont un des très nombreux tunnels que le noyau Linux prend en charge. Ils fonctionnent désormais également en IPv6 (seul l’IPv4 était disponible auparavant).
Plusieurs chemins en MPLS
Annoncé dans la dépêche du noyau 4.1, le code pour MPLS dans le noyau Linux progresse. Il fonctionne maintenant avec plusieurs chemins pour une même route.
Des informations sur les ponts (bridges) via l’interface Netlink
Netlink est l’interface privilégiée pour exporter les informations réseau en espace utilisateur. Malheureusement, des morceaux historiques peuvent ne pas passer par là et ne pas exporter les informations dans /proc ou via le sysfs. C’était le cas pour les ponts (bridges), mais Nikolay Aleksandrov a fait un grand travail pour que le maximum d’informations soit maintenant accessible : annonce de la première partie, et de la seconde.
Des applications persistantes pour BPF
On ne présente plus le Berkeley Packet Filter (BPF) du noyau. Celui-ci avait une limitation pour certains utilisateurs : lorsqu’un programme s’arrête, les règles qu’il a pu mettre en place disparaissent.
Daniel Borkmann, principal développeur de cette partie du noyau, a donc proposé de permettre la persistance de ces règles, ce qui se concrétise par des fichiers spéciaux que les programmes peuvent ouvrir dans /sys/fs/bpf/.
Sécurité
Le chiffrement matériel avec le protocole Trusted Platform Module accepte désormais la norme TPM 2.0. C’est la seule fonctionnalité notable parmi des développements principalement de maintenance.
Périphériques en mode bloc (block devices)
Lecture sans interruption et polling
Rien à voir avec les coups de fils pour connaître notre gel douche préféré, c’est en fait l’apparition dans la couche E/S par bloc du noyau d’une technique issue de la couche réseau. Jusqu’à présent, la lecture d’un disque se faisait par interruptions successives déclenchées par le pilote, ce qui permet au processeur de s’occuper d’autres tâches entre deux interruptions.
Avec les SSD, les débits sont suffisamment élevés pour remettre en cause le mécanisme coûteux des interruptions matérielles et logicielles et envisager un flux plus continu. Ce noyau introduit un mécanisme de lecture où la couche-bloc demande elle-même les données (polling) au pilote. En cas de lecture séquentielle, le gain est parfois très net, jusqu’à un facteur deux, même s’il dépend fortement du périphérique.
L’implémentation est encore très partielle et expérimentale, mais son intégration au noyau devrait accélérer les développements. Pour en savoir plus : LWN.
Montage loop
Indépendamment du système de fichiers, on peut placer un point de montage loop sur un fichier, par exemple avec une image de DVD. Ce mécanisme utilise désormais des accès directs, sans passer par des mémoires tampon au niveau du périphérique de bloc loop. Les performances en sont grandement améliorées, notamment en termes de consommation de mémoire.
Systèmes de fichiers
F2FS
https://github.com/torvalds/linux/commit/0fcb9d21b4e18ede3727b8905e74acd0d1daef56
Intégration des changements de f2fs de Jaegeuk Kim :
La plupart des changements sont des améliorations de stabilité et de performance de la fonctionnalité de mise en cache des extensions en mémoire.
Avec en plus quelques nouvelles fonctionnalités et configurations supplémentaires ainsi que quelques corrections.
Btrfs
https://github.com/torvalds/linux/commit/27eb427bdc0960ad64b72da03e3596c801e7a9e9
Intégration des changements de btrfs de Chris Mason :
Beaucoup d’améliorations du côté de la gestion du sub-quota et beaucoup de nettoyage de la part de Dave Sterba et Anand Jain entre autres.
Josef a soumis un tas de corrections concernant l’allocateur utilisé en production chez Facebook. Il a trouvé que l’option mount -o ssd_spread améliore grandement les performances sur du RAID 5/6 matériel, mais au prix de quelques engorgements CPU. Ces patchs font alors une grande différence.
Ext4
https://github.com/torvalds/linux/commit/b0f85fa11aefc4f3e03306b4cd47f113bd57dcba
Voici le résumé par Ted Ts’o en charge de ext4 :
- Ajout de la prise en charge de la fonctionnalité CSUM_SEED qui permettra dans le futur aux applications en espace utilisateur de changer l’UUID du volume sans réécriture de toutes les métadonnées de ce volume.
- Un certain nombre de corrections diverses, qui concernent surtout le chiffrement de partitions ext4. Quiconque utiliserait ce chiffrement devrait rétro-porter tous les changements opérés en 4.4 pour corriger des fuites mémoires et des corruptions de données.
- Il y a aussi du nettoyage des tests de ext4 et de la prise en charge de sysfs.
Virtualisation
Il est désormais possible à une machine virtuelle dans QEMU d’utiliser l’accélération matérielle OpenGL 3D de son hôte. Ce projet assemble plusieurs éléments : virtio-gpu dans le noyau 4.4, virtio dans QEMU 2.5, et Mesa (git master).
KVM
https://github.com/torvalds/linux/commit/933425fb0010bd02bd459b41e63082756818ffce
s390
Des corrections et améliorations de la gestion des interruptions et du temps.
PPC
Principalement des corrections diverses.
ARM
Pas de grosses nouveautés, mais beaucoup de petites corrections et améliorations nécessaires :
- des corrections pour le compteur d’architecture (arch-timer)
- ajout de nouvelles sémantiques d’activation par niveau pour le compteur d’architecture (arch-timer)
- une série de patchs pour arrêter de manière synchronisée un système invité (nécessaire pour la redirection d’interruptions)
- amélioration des points de trace
- une astuce pour la gestion des exceptions de panique de niveau EL2
- encore du nettoyage de la virtualisation du GIC (Gestionnaire d’Interruptions de ARM) pour la suppression d’états redondants
x86
Quelques changements:
- gestion du "VT-d posted interrupts" (i.e. les périphériques PCI peuvent injecter des interruptions directement dans un CPU virtuel). Cela introduit donc un nouveau composant (dans virt/lib/) qui relie VFIO et KVM. Les mêmes composants seront aussi utilisés pour la redirection d’interruptions sur ARM.
- de nouvelles fonctionnalités Hyper-V, même si la principale "Hyper-V synthetic interrupt controller" devra attendre linux 4.5. Ceci permettra a KVM aussi d’exposer des périphériques Hyper-V.
- la virtualisation imbriquée prend maintenant en charge les VPID (comme les PCID mais pour les CPUs virtuels) qui accélèrent un peu les choses
- pour le futur matériel prenant en charge le NVDIMM, il y a maintenant la prise en charge de clflushopt, clwb et pcommit
- prise en charge du "split irqchip", i.e. LAPIC dans le kernel + IOAPIC/PIC/PIT dans l’espace utilisateur, qui réduit la surface d’attaque de l’hyperviseur
- intégration nécessaire des corrections pour le SMM (system management mode)
- pour le côté client, "stable scheduler clock support" a été réécrit pour que son fonctionnement soit indépendant du superviseur
Cgroups
https://github.com/torvalds/linux/commit/69234acee54407962a20bedf90ef9c96326994b5
Intégration des changements de cgroups de Tejun Heo. Le cœur de cgroups a vu de nombreux changements pour cette version :
- Le verrouillage
percpu_rwsempour le groupe de processus légers (threadgroup) est rétabli. Cette fonctionnalité était temporairement supprimée pour des raisons de latences causées par les appelsdown_write. Le re-travail de Oleg surpercpu_rwsemdont l’intégration est prévue pour la prochaine fenêtre d’intégration corrigera le problème. - Sur la nouvelle version de la hiérarchie, quand les gestionnaires sont activés et désactivés, toutes les opérations sont atomiques et peuvent échouer et revenir proprement. Cela permet des erreurs lors des appels ->can_attach() ce qui est nécessaire pour les
cpu RT slices. - Les tâches restent associées à leur cgroup original après leur sortie jusqu’à leur libération complète. Cela permet un suivi des ressources des tâches fantômes et facilite la découverte de l’origine de ces processus fantômes dans la nouvelle hiérarchie. Le gestionnaire de numéro de processus était cassé avant ces changements, car les processus fantômes échappaient à ces limites ; malheureusement changer ce comportement a requis bien trop de changements profonds et cela reste une mauvaise idée de porter ces corrections en arrière, donc le gestionnaire de numéro de processus sur 4.3, la première version l’incluant, restera cassé au moins jusqu’à ce que l’on soit certain des changements du cœur de cgroups.
- Optimisation d’une partie des tests communs en utilisant des
static_key.
Le bilan en chiffres
Selon le site LWN, cette version 4.4 a impliqué 1 548 développeurs alors que pour la version 4.3, il y en avait eu 1 600. Parmi ces 1 548 personnes, 246 ont fait leur première contribution au noyau.
Pour l’année 2015, la palme du développeur le plus actif a été remportée par H Hartley Sweeten si on s’appuie sur le nombre de commits (282 changesets), ou par Alex Deucher si l’on s’appuie sur le nombre de lignes modifiées (3 220 lignes).
Si l’on se réfère aux entreprises impliquées dans le noyau, Intel l’emporte haut la main, notamment devant Red Hat, Samsung et AMD, aussi bien en nombre de commits qu’en nombre de lignes modifiées (avec respectivement 12,9 % et 13,3 %).
Appel à volontaires
Cette dépêche a nécessité plus de 960 éditions (à l’heure de l’écriture de ces statistiques), et mobilisé 28 personnes du 16 novembre 2015 au 18 février 2016 dans l’espace de rédaction.
Cette dépêche est rédigée par plusieurs contributeurs, dont voici la répartition :
| Mainteneur | Contributeur(s) | |
|---|---|---|
| En bref | Aucun | rogo |
| La phase de test | Aucun | Aucun |
| Arch | Aucun | Tiwaz |
| IPC | Aucun | ariasuni |
| Développement | Aucun | rogo |
| Pilotes graphiques libres | Martin Peres | Aucun |
| Réseau | Aucun | Florent Fourcot, Tiwaz |
| Block devices | Aucun | rogo |
| Systèmes de fichiers | Aucun | ariasuni |
| Sécurité | Aucun | rogo |
| Virtualisation | Xavier Claude | Aucun |
| Édition générale | Aucun | jcr83, Moul, eggman |
Un peu de vocabulaire :
- le mainteneur d’une section de la dépêche est responsable de l’organisation et du contenu de sa partie, il s’engage également à l’être dans le temps jusqu’à ce qu’il accepte de se faire remplacer ;
- un contributeur est une personne qui a participé à la rédaction d’une partie d’une section de la dépêche, sans aucune forme d’engagement pour le futur.
Malgré cette équipe importante, beaucoup de modifications n’ont pas pu être expliquées par manque de temps et de volontaires.
Nous sommes particulièrement à la recherche de mainteneurs pour les sections Systèmes de fichiers, Réseau, Développement et IPC les précédents n’ayant pas donné de signes de vie pendant la rédaction des dernières dépêches.
Si vous aimez ces dépêches et suivez tout ou partie de l’évolution technique du noyau, veuillez contribuer dans votre domaine d’expertise. C’est un travail important et très gratifiant qui permet aussi de s’améliorer. Il n’est pas nécessaire d’écrire du texte pour aider, simplement lister les commits intéressants dans une section aide déjà les rédacteurs à ne pas passer à côté des nouveautés. Essayons d’augmenter la couverture sur les modifications du noyau !
C’est un travail à faire au fil du temps, par ajouts successifs (une simple adresse URL ou un paragraphe enrichissent déjà le contenu et les sources), n’hésitez pas !
Aller plus loin
- Dépêches des noyaux précédents (509 clics)
- Site officiel du noyau Linux (344 clics)
- Die Neuerungen von Linux 4.4 (143 clics)
# bravo !
Posté par BAud (site web personnel) . Évalué à 10.
Merci pour la finalisation de cette dépêche en rédaction, les statistiques parlent d'elles-mêmes pour y participer, y donner de la cohérence et une mise en forme homogène avant publication : cette finalisation est cruciale et pas si facile, ce pourquoi il est important d'avoir du contenu rédigé au fur et à mesure.
C'est souvent rappelé, mais cette dépêche est un incontournable sur un site tel que Linux Fr.org : n'hésitez pas à y participer, vous ne manquerez pas d'apprendre des choses au passage, même si vous ne connaissez pas le sujet initialement. Les traductions des annonces de Linus sont franchement abordables pour qui s'y connaît un minimum en anglais et sait s'adapter au style du locuteur, un peu spécifique il est vrai.
Bon, je ne remercie pas celui qui a subrepticement réintroduit le terme « support » après que j'ai regardé et fait une relecture :-) (mais, bon, j'aime bien râler, ça nuance on va dire :D)
Qui se lancerait pour l'animation de la rédaction et créer la dépêche pour la version suivante ?
[^] # Re: bravo !
Posté par freem . Évalué à 0.
Désolé, mais, moi, j'ai peur.
Pas de mon manque de compétences de traduction anglais-français et vice-versa, mais de ma compréhension du sujet.
Je ne sais pas si je suis le seul, mais je me permets de le dire, les dépêches sur le noyau linux sont totalement dénuées d'intérêt pour la majorité des utilisateurs. Oui, je sais, c'est méchant et direct et trop cru. Mais, je suis un programmeur, qui préfère le C++ (oui, je sais, Linus nous considère comme moins bons que les dev C, mais… je m'en fout, et ça reste à prouver, au fond, je prend ça comme une réponse à du troll) en général, qui aime taper dans le matos. Mais je ne maîtrise pas la complexité des noyaux, même pas de loin. Ce n'est pas que je ne veux pas, mais rien qu'installer une gentoo est loin d'être trivial, alors, comprendre ces dépêches?
C'est totalement hors de ma portée. Je ne veux pas que ça disparaisse, au contraire, j'aime qu'on me rappelle qu'il m'en reste tant à apprendre, mais, je sais pas, peut-être qu'un ou deux liens, ou autres journaux plus user-friendly serait bienvenus?
Pour préciser ma pensée, wesnoth publie, à chaque MàJ, 2 changelog, un pour les dev, et un pour les joueurs. Si je pouvais comprendre ce qui se dit dans les journaux relatifs aux changelogs linux, je pense que j'essaierai de faire une synthèse pour les utilisateurs. Malheureusement, je ferais sûrement plus perdre de temps qu'autre chose.
[^] # Re: bravo !
Posté par eingousef . Évalué à 10.
Ils ont rajouté une section "En Bref", c'est drôlement bien je trouve :o
*splash!*
[^] # Re: bravo !
Posté par rogo . Évalué à 10.
Merci. J'ai créé et rédigé cette section "En bref".
Comme freem, j'utilise Linux quotidiennement, mais je ne suis pas développeur C et la quasi-totalité des évolutions du noyau me dépasse ; je me fiche royalement des messages de RC, et je ne comprends qu'une petite partie des notes techniques. C'est pour cela que j'ai voulu ajouter ce petit résumé. À titre personnel, ma lecture de la dépêche n'irait pas plus loin. Ce résumé est construit grâce au travail des autres, notamment l'annonce sur kernelnewbies filtrée et complétée selon mes goûts.
Mon ressenti de rédacteur (une douzaine de paragraphes) est très mitigé. D'un côté, c'est un travail intellectuel très plaisant. Par exemple, pour écrire la section "Gestion de la mémoire", j'ai lu les articles LWN, puis les échanges sur la liste de diffusion du noyau, et, une fois atteint un degré de compréhension suffisant, j'ai écrit ces deux paragraphes, en espérant que quelqu'un de plus compétent relirait. Pour "Sécurité", c'était plus superficiel, simplement à partir de l'annonce sur lkml.
Les aspects négatifs sont tout de même très pesants. On n'a aucune visibilité : quel degré de détail viser ? quels sujets traiter ? qui a fait quoi ? qu'est-ce qui a été relu ? qu'est-ce qui n'est un premier jet temporaire que l'auteur va compléter ? La tribune, une simple pile mono-ligne, est le seul outil de discussion et de planification. Un exemple frustrant : de longs messages de commits ont été copiés dans la dépêche ; ils y sont restés plusieurs semaines, certains contributeurs les ont traduits littéralement, et au final les traductions ont été jetées quand ces sections ont été rédigées. Quel gâchis ! En l'état, je comprends que les contributeurs soient rares.
Je n'ai rien de concret à proposer spontanément, mais j'imagine qu'on pourrait améliorer le système de rédaction de ces dépêches complexes, notamment sur les aspects techniques.
[^] # Re: bravo !
Posté par BAud (site web personnel) . Évalué à 3.
oui, c'est normal : s'impliquer c'est rester jusqu'au bout. La rédaction c'est un travail et une synchronisation au jour le jour pour comprendre l'optique retenue par les contributeurs :-)
Alors là, je suis très déçu, rediger-des-depeches-noyau est là pour être alimentée avec l'expérience, les attentes de chacun et ce qui doit être mis en avant pour aider un repreneur de ce type de dépêche. Si tu n'y trouves pas tes réponses : édite le wiki, ajoute tes questions, cela alimentera son contenu. D'ailleurs, cela était indiqué initialement à publication, puis cela a disparu de l'initiative d'un modérateur : dommage :/
Merci de ton retour factuel et avec quelques propositions. Je ne suis pas forcément le mieux placé pour te répondre : un autre contributeur à l'espace de rédaction serait sans doute plus pertinent que moi pour expliquer le fonctionnement (anarchique, collaboratif, en bénévolat, par envie, par implication, pour le fun…)
Bah j'ai une des dépêches initiées la plus vieille, sans capacité d'y répondre s'il n'y a que moi qui cherche des solutions : https://linuxfr.org/redaction/news/comment-participer-a-la-redaction
Il y a quelques pistes fournies sur https://linuxfr.org/wiki/rediger-des-depeches-noyau : tu peux l'éditer et ajouter tes questions + propositions, restera à trouver quelqu'un pour finaliser la dépêche pour le noyau 4.5 qui n'a pas encore été créée en rédaction :/
[^] # Re: bravo !
Posté par rogo . Évalué à 6.
Vu le smiley final, j'imagine que c'est du second degré. Parce que je me suis déjà un peu impliqué sur d'autres dépêches noyau, mais beaucoup sur celle-ci. De mémoire, mes modifs doivent être réparties sur au moins 5 jours différents et étalées sur plusieurs semaines. C'est justement parce que je m'étais investi que le manque de perspective m'agaçait. De l'optique dans le brouillard ;-)
J'avais lu cette page sans en retirer grand chose ; ce sont des généralités, certes utiles, mais insuffisantes. La partie "Notes" est presque illisible — même en pensant à lire de bas en haut !
Un exemple pratique : quelqu'un avait rédigé dans cette dépêche plus de 20 paragraphes sur un sujet précis, dans une section sans mainteneur. J'ai mis une note pour signaler que ça me semblait déséquilibré. Une personne a acquiescé. Et ensuite ? J'ai attendu une semaine pour voir s'il y avait d'autres réactions, si possibles plus directives, avant de rédiger un paragraphe de remplacement, mais sans oser rien effacer. Une semaine plus tard, quelqu'un a fait le ménage.
Autre exemple : la liste des mainteneurs de sections, en fin de dépêche, est complètement bancale (section "IPC" fantôme, plusieurs sections non déclarées, etc). Je l'avais signalé dans la tribune, et demandé s'il y avait un usage établi, sans obtenir de réponse.
Jusqu'à la fin, je me suis attendu à ce que les sections Virtualisation et Cgroups soient rédigées. Mais, contrairement à Réseau et FS, elles en sont restées à l'état de traductions de message de commit, bien indigestes. Si j'avais su, j'aurais peut-être cherché à rendre ces passages plus présentables.
Comme le suggère eingousef ci-dessous, une prochaine fois je mettrai mes commentaires et mes questions directement dans le corps du document. Ça sera plus pratique et peut-être plus efficace que la tribune.
Je me sens un peu con de grignoter sur mes heures de sommeil pour ergoter là-dessus. On verra à l'usage, peut-être pour le 4.5.
[^] # Re: bravo !
Posté par BAud (site web personnel) . Évalué à 3.
oui, bien vu :-)
c'est la difficulté de notre fonctionnement en rédaction : l'informel, les habitudes, le fait que ça n'avance pas aussi vite qu'on le souhaiterait, les participations inattendues, la difficulté à maîtriser tous les sujets traités (et la confiance inhérente dans les ajouts).
Ceci dit, je trouve que malgré le départ de patrick_g< qui faisait un boulot incroyable, l'énergie de mupuf< en repreneur qui a su rassembler autant de monde avec le passage en rédaction collaborative mais a su laisser sa place (tout en restant présent sur son domaine), ça s'est passé relativement correctement : à un moment quelqu'un a retroussé ses manches et a tranché/choisi/complété puis fait publier cette dépêche. Si tout le monde comprenait comment cela arrive, il comprendrait que ce n'est pas organisable :-) et pourtant. Certains parlent de crowdsourcing, je préfère de loin le terme de participation volontaire
très bien vu : cela apporte du contenu directement au bon endroit (plutôt que d'avoir à parcourir la tribune), ajouté sur le wiki rediger-des-depeches-noyau
bah, personne ne souhaite se mettre en avant (moi le premier, ayant enlevé mon nom à ce tableau quand quelqu'un l'ajoutait… je ne fais que de l'ortho et de la mise en forme et un peu de correction des trads). Tu n'as pas obtenu de réponse parce que justement, il n'y a pas d'usage établi :-) ce n'est ni sain, ni malsain, c'est indécidable, ça dépend, ça dépasse :D
L'idéal, ce serait tout de même de mettre à jour le modèle de dépêches Noyau s'il y a des sujets à traiter spécifiquement et quelqu'un souhaitant s'en charger, mais quand je vois que M5oul< a initié la dépêche en repartant de la dépêche précédente plutôt que du modèle, les bras m'en tombent, ce n'est pas une attaque ad hominem : c'est un constat que capitaliser sur le wiki n'est pas connu voire complètement sous-estimé et, quand je ne suis pas optimiste, serait inutile /o\, je préfère croire que ce n'est pas « connu »).
ne te mets pas martel en tête, ni toi ni moi n'avons les réponses pour tenter de comprendre le fonctionnement et ce qui pourrait mieux fonctionner. Ta participation a été décisive, autant continuer, pourquoi pas ? Cela peut ressembler à des bouteilles à la mer, mais elles peuvent être repêchées :-) et franchement, ce n'est pas si dramatique, si tu as le temps et l'envie, tout est fait pour participer (mais plus il y a de fous moins ya de riz /o\).
[^] # Re: bravo !
Posté par eingousef . Évalué à 10.
Pour les dépêches que j'écris moi-même (donc quelques dépêches sur la culture libre et le jeu libre), c'est assez simple : j'écris ce que j'ai envie de lire. J'écris des notes en creusant le sujet autant que mes connaissances le permettent et ensuite j'élague en ne gardant que les trucs que j'aurais aimé lire. Je n'essaye pas tellement de m'adapter à tous les lecteurs de linuxfr (c'est impossible), mais je me définis un public et j'essaye de viser ce public là. Quand j'écrivais les dépêches 0 A.D. c'était "les gens qui jouent à 0 A.D. suffisamment pour connaître le jeu et vouloir savoir ce qu'il y a dans la nouvelle version, mais pas suffisamment pour regarder régulièrement les forums et la timeline de développement". Et si j'ajoute une info qui n'intéresse que moi, j'essaye de m'adapter à ce public en donnant des définitions/explications rapides, pour pas leur laisser l'impression de les noyer dans le détail.
Par contre pour les dépêches où je contribue, j'aime bien qu'on me donne des instructions claires, que le dictateur bienveillant de la dépêche sache où il va et ce à quoi il voudrait que sa dépêche ressemble, sinon c'est chiant. Si j'arrive en disant "Ok, là il manque quelque chose à propos de tel truc, qu'est-ce que tu voudrais que je dise, comment, avec quel niveau de détail et en combien de phrases ?", et qu'il me répond "Euh chais pas", ça me gonfle :o Alors parfois je prends le problème à bras-le-corps en me disant "Bon ok, voilà ce que j'aurais fait si ça avait été ma dépêche, paf, ça fait 2 paragraphes de 10 lignes, avec une nimage 600x80 au milieu, c'est ptet trop détaillé, ou pas assez, ou trop aéré, ça déborde sur d'autre sujets dont on parle après ou pas, l'image a l'air de casser la dépêche en deux, ou au contraire elle est trop discrète, etc, mais au moins j'ai fait un truc, et si vous êtes pas content, ben c'est comme ça épicétou :o" Et soit ça s'intègre bien et le dictateur est content, soit ça s'intègre mal et si c'est pas un branquignole ça le motive pour écrire un truc plus adapté. (Et si c'est un branquignole il accepte quand même le truc et au final on a une dépêche qui ressemble à rien /o\ )
Là où je suis plus embêté c'est quand je commence une dépêche parce que je sais qu'il faut l'écrire, mais dont je n'ai aucune idée de comment la réaliser. Je sais quelles infos il faut mettre dedans, quelle importance il faut leur donner, quel doit être l'aspect visuel de la dépêche au final, etc., mais je ne sais pas comment faire le boulot parce que c'est pas dans mes compétences.
L'interview d'Itms notamment ça a été assez dur, parce que j'avais jamais fait d'interview avant, je savais pas s'il fallait que j'envoie mes questions par mail toutes en même temps, s'il fallait que je revienne dessus après, s'il fallait que je les pose une par une pour me laisser la possibilité d'improviser, etc. Au final je les ai posées une par une en essayant de faire des transitions parfois, mais à certains moment je me suis un peu emmêlé les pinceaux. Il faut dire aussi qu'avec une dépêche de ce type on a pas trop le contrôle : il y a des trucs dont on sait qu'ils sont importants, mais c'est pas toujours facile de faire comprendre à l'intervenant que c'est de ça qu'il faut parler, bref ce type de dépêche est bien plus épuisant qu'une dépêche solo j'ai l'impression.
Là il y a aussi cette dépêche sur le projet Gooseberry (finalisé depuis plusieurs mois déjà !) que je dois faire (j'ai parlé du début, il faut que je parle de la fin, logique), mais j'ai vraiment du mal parce que ça touche à des trucs que je ne maîtrise pas du tout (création 3D). J'ai une idée de l'organisation de la dépêche, des points à aborder en gros, des questions que pourraient se poser les lecteurs qui ont lu les dépêches précédentes, mais quand j'essaye d'établir la liste des changements qui ont été faits au logiciel Blender durant ce projet, j'ai du mal parce que je comme je ne comprends pas, je n'ai aucune idée du degré d'importance de chacun des trucs que je vois. Il me faudrait des contributeurs qui connaissent bien le logiciel Blender et qui pourraient m'expliquer les fritures, mais autant je sais qu'il y a beaucoup de gens prêt à aider sur l'espace de rédac, autant je ne sais pas du tout si il y a des contributeurs capables de m'aider pour des trucs super précis. Pour les dépêches 0 A.D. j'avais surtout des joueurs qui venaient contribuer, quand j'avais besoin des gens pour m'expliquer des histoires de moteur graphique, de pathfinding, d'IA, etc : nada :/ Finalement pour l'interview à propos du pathfinding j'ai essayé d'apprendre un petit peu tout tout seul en lisant les articles Wikipedia en français et en anglais sur les différents algos. Je pourrais faire ça pour Blender, mais j'aime autant prévenir que vous l'aurez pas avant six mois la dépêche :o
Un autre truc super important, c'est que sur l'espace de rédaction il n'y a pas de possibilité de faire des revert sur des modifications qui viennent d'être faites, et ça quand vous avez un contributeur particulièrement chiant ça donne pas envie de contribuer (c'est pour ça que désormais je posterai mes dépêches en soumission directe, et j'éviterai autant que possible l'espace de rédac linuxfr, sauf quand je suis obligé évidemment, pour la dépêche sur Blender par exemple je pense que j'aurai pas trop le choix :/ ).
*splash!*
[^] # Re: bravo !
Posté par BAud (site web personnel) . Évalué à 4.
Concernant les entretiens, tu as LeBouquetin< qui a fait un très bon boulot dans la durée, ça mériterait d'être relancé, je ne sais plus si la bonne manière de faire avait été tracée sur le wiki, ce serait bien de le faire (questions systématiques + questions adaptées au type de projet, permettant d'avoir un plan cohérent de dépêche en dépêche).
Accessoirement LeBouquetin a aussi LA méthode de recrutement dans le forum où tous les éléments sont présents (ça c'est dans le wiki, je vous laisse retrouver :p).
euh bin, si : tu réécrits ce qui était présent auparavant (disponible via les versions disponibles justement), mais oui, je vois ce que tu veux dire…
pfff si tu parles de moi, tu aurais pu me le dire :/ Pour M5oul il fait du bon boulot si justement tu lui appliques ce que tu attends « j'aime bien qu'on me donne des instructions claires, que le dictateur bienveillant de la dépêche sache où il va et ce à quoi il voudrait que sa dépêche ressemble »
Bon, les commentaires de cette dépêche noyau ne sont pas là pour en discuter : n'hésite pas à rajouter des commentaires sur les pages wiki idoines (ou directement les compléter) même si malencontreusement beaucoup des commentaires des pages wiki ont été flingués (sur le critère de l'obsolescence) alors que cela donnait du contexte de temps en temps.
Franchement, pour un participant régulier à la rédaction comme toi, je reste étonné de te voir aussi peu intervenir sur le wiki ou les ML :/ mais bon, cela doit être dû au fait que ce n'est pas très bien décrit comme logique d'échange /o\
Merci beaucoup pour ton retour, qui fait comprendre quelques-unes de tes attentes, ce que tu pourrais apporter, ce qui est gênant, à nous (toi inclus) de s'améliorer et faciliter les contributions et l'implication de tous !
[^] # Re: bravo !
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Note que je kifferai grave écrire un truc sur GooseBerry, mais c’est trop pour moi aussi. Ça peut être une dépêche à quatre mains si tu veux. ;-)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: bravo !
Posté par eingousef . Évalué à 2.
D'accord mais j'ai surtout besoin de quelqu'un qui sache me traduire "procedural grass shading" et "dynamic hair stiffness and damping" en vrai français compréhensible par des humains normaux, et de me dire lequel qu'est le plus important à en parler que de l'autre :o
*splash!*
[^] # Re: bravo !
Posté par Jehan (site web personnel, Mastodon) . Évalué à 3.
Pour les mots techniques qui n'ont pas reçu de trad "officielle", ma suggestion est de garder l'anglais en italique avec une tentative de trad entre parenthèse (ou l'inverse).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: bravo !
Posté par Julien Wajsberg . Évalué à 7.
Pas d'accord avec toi.
J'ai beau coder du JavaScript toute la journée, ça m'intéresse beaucoup de connaître les évolutions du noyau. (OK, j'avoue, j'ai déjà compilé un noyau… et je continue de temps en temps :) ).
Merci aux contributeurs de la dépêche !
[^] # Re: bravo !
Posté par guppy . Évalué à 10.
Je ne sais pas si je suis le seul, mais je me permets de le dire, les dépêches sur le noyau linux sont totalement dénuées d'intérêt pour la majorité des utilisateurs.
Et ? Ici c'est linuxfr, peuplé de techniciens que le sujet intéresse. Si une partie du lectorat trouve le sujet trop compliqué, ils n'ont qu'à pas le lire. Ils peuvent aussi proposer une dépêche plus simple, moins technique, je serai étonné que la modération la refuse.
De plus, le sujet lui-même est très technique (nouvelle version du noyau d'un OS), en parler d'une manière non technique, ça se fait comment ? "Le noyau linux sort en version n, elle est plus cool que la version n-1. A plus les gars." ?
Oui, je sais, c'est méchant et direct et trop cru.
C'est surtout à côté de la plaque.
Pour préciser ma pensée, wesnoth publie, à chaque MàJ, 2 changelog, un pour les dev, et un pour les joueurs.
Donc arrête de cracher dans la soupe, prend ton bâton de pèlerin et fais donc la version pour les utilisateurs.
PS : je suis aussi dev c++, je joue aussi à Wesnoth, et je vois pas le rapport avec la choucroute.
PPS : installer une gentoo c'est trivial. Si tu penses le contraire, c'est que t'as jamais dû essayer.
PPPS : pendant que j'y suis, merci aux rédacteurs de cette dépêche, je trouve quant à moi que c'est du très bon boulot et c'est pour ce genre de contenu que je viens sur linuxfr.
[^] # Re: bravo !
Posté par superna (site web personnel) . Évalué à 5.
Salut,
J'ai rajouté et traduit plein de morceaux, mais j'ai du mal a organiser et synthétiser.
D'ailleurs, merci à ceux qui ont fait la synthèse, surtout de la partie réseau, ce que j'avais ajouté était brut de décoffrage !
Je suis disponible pour traduire autant que vous voulez, je suis habitué aux termes techniques du kernel et j'en parle en français avec mes collègues…
La 4.5 en est à la rc4, mais on peut déjà commencer l'article…
[^] # Re: bravo !
Posté par gUI (Mastodon) . Évalué à 10.
Je suis un informaticien "technique" (couches basses, firmwares, drivers) et pourtant je comprends que 10% de la dépêche.
Mais les 10% que je comprends :
- je suis bien content de l'apprendre
- c'est pas les même 10% que qqu'un d'autre
- je survole ausi le reste, histoire d'essayer de passer à 12% :)
Bref, prends ce que tu peux, je suis certain qu'il y a des passages qui t'intéressent.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: bravo !
Posté par Dr BG . Évalué à 8.
Je suis un peu dans ton cas. C'est clair que je ne comprends pas tout, mais je ne cherche pas non plus à comprendre. Je survole pour voir si un point m'intéresse (nouveau pilote, et non l'inverse ; amélioration…) et je le lis. Je passe les autres (archis exotiques, pilote nouveau, etc.).
[^] # Re: bravo !
Posté par steph1978 . Évalué à 3.
En tant que développeur, tu ne peux pas ignorer que ton code tourne sur du matériel et fait appel à des routines du noyau. A moins que tu développes toi même un noyau et dans ce cas tu sera content de lire ce qui se passe sur un noyau de référence.
Quant à comprendre, quand on te dit "Il est désormais possible à une machine virtuelle dans QEMU d’utiliser l’accélération matérielle OpenGL 3D de son hôte.", cela ne me parait pas inabordable pour un informaticien.
Bref, si ces dépêches ne t’intéresse pas ou que tu ne les comprends pas, tu n'es pas le développeur que j'aimerai avoir dans mon équipe.
# QEMU et accelération 3D
Posté par tuxicoman (site web personnel) . Évalué à 5.
Il y a une limitation sur l'API OpenGL utilisable ou ça dépend uniquement du driver de l'hôte?
[^] # Re: QEMU et accelération 3D
Posté par Martin Peres (site web personnel) . Évalué à 3.
Oui, il y en a une, OpenGL 3.3. Ca devrait être étendu dans le futur :)
# Chiffrement et Ext4
Posté par tuxicoman (site web personnel) . Évalué à 7.
Je ne comprends pas cette phrase mais les mots "corruption de données" font peur…
Quelqu'un pourrait ré-expliquer ?
[^] # Re: Chiffrement et Ext4
Posté par arnaudus . Évalué à 9.
Bah c'est pas dur : les données, elles t'appartiennent (ce sont des données personnelles). Mais si quelqu'un (genre Google) leur propose du pognon, elles peuvent décider de te trahir. La corruption de données, c'est une vraie plaie.
[^] # Re: Chiffrement et Ext4
Posté par rogo . Évalué à 2. Dernière modification le 19 février 2016 à 14:54.
Ce passage est une simple traduction de l'annonce sur la liste de diffusion du noyau (lkml) :
Bien entendu, le mot corruption est à prendre au sens premier de rupture, altération. Autrement dit, sur une partition ext4 chiffrée tournant sur un linux pre-4.4, il y a un risque que des fichiers soient endommagés.
J'ai regardé dans la distribution Debian si ces corrections avaient été rétro-porté dans les noyaux stable/testing, mais je n'ai rien vu dans le changelog.
Edit : dans la dépêche, le lien vers le "merge" ext4 est faux, il pointe vers le "merge" réseau.
[^] # Re: Chiffrement et Ext4
Posté par Antoine . Évalué à 1. Dernière modification le 19 février 2016 à 20:15.
De quel mécanisme de chiffrement s'agit-il ? De celui qui passe par luks ou cryptSetup, ou d'autre chose ?
[^] # Re: Chiffrement et Ext4
Posté par rogo . Évalué à 5.
C'est le chiffrement natif en ext4. Pas de cryptsetup/dm-crypt ou autre module dans le noyau. Ext4 sait faire ça depuis moins d'un an, cf (LWN) Ext4 encryption.
Pour plus d'info, voici le commit de Theodore Ts'o qui explique et corrige le bug. Ce même correctif est aussi dans le noyau 4.3.3.
[^] # Re: Chiffrement et Ext4
Posté par Antoine . Évalué à 3.
Merci, l'article LWN (et les commentaires associés) est très intéressant.
Pour ceux qui comme moi se posaient la question, la principale différence est que le chiffrement ext4 se fait fichier par fichier, répertoire par répertoire, ce qui permet beaucoup plus de souplesse. Aussi, effectuer le chiffrement au niveau du système de fichiers permettra d'attacher des métadonnées pour, par exemple, authentifier les données (c'est-à-dire vérifier qu'elles n'ont pas été modifiées par un attaquant).
# ipvs
Posté par Denis Dordoigne . Évalué à 6.
Pour ceux que le sujet ipvs intéresse, on avait publié ceci il y a quelques temps sur linuxfr.
Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr
# lien cassé
Posté par puyopuyo . Évalué à 1.
le liens nommé "voir plus loin" dans la section architecture au point Raspberry pi est cassé. le lien est http://linuxfr.org/redaction/news/sortie-du-noyau-linux-4-4#broadcom-pilote-vc4-rpi alors qu'il devrait etre http://linuxfr.org/news/sortie-du-noyau-linux-4-4#broadcom-pilote-vc4-rpi
[^] # Re: lien cassé
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# Merci !
Posté par DerekSagan . Évalué à 7.
Comme à chaque sortie de noyau, une dépêche bien agréable à lire ! Merci !
# QEMU
Posté par xcomcmdr . Évalué à 10.
Fuck yeah ! Adieu VMWare et VirtualBox !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: QEMU
Posté par Martin Peres (site web personnel) . Évalué à 5.
C'est pas encore vraiment hyper stable, mais ca arrive!
[^] # Re: QEMU
Posté par xcomcmdr . Évalué à 3.
Est-ce que ça marche avec une VM Windows ?
J'aurais des vieux jeux qui exigent XP qui auraient alors plus besoin d'utiliser VMWare ni un vieux ordi dédié.
(bon après pour ceux qui exigent Windows 9X, il y a Wine. En général, ça marche bien. Pour ceux qui exigent Windows 3.11, y'a Windows 3 dans DOSBox. :) Et bientôt aussi pour ceux qui exigent Windows 9X ou DOS et une 3DFX, il y a/aura le fork DOSBox-X).
Oui, je suis un peu foufou là dessus (tests de vieux jeux et rédactions de fiches pour abandonware-france.org)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: QEMU
Posté par Martin Peres (site web personnel) . Évalué à 5.
Euh, non, ca va pas le faire. Faudrait écrire un pilote 3D pour windows…
[^] # Re: QEMU
Posté par xcomcmdr . Évalué à 2.
Je m'en doutais. Merci pour la réponse. :)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: QEMU
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Et pour un vieux Windows en plus… Ça va être dur de trouver la motivation. :o
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: QEMU
Posté par Thomas Debesse (site web personnel) . Évalué à 4.
À propos de jeux sur des microsofteries, j’ai découvert récemment le projet xqemu qui essaie de bâtir un émulateur xbox basé sur qemu. Il y a encore beaucoup de travail à faire sur l’émulation du gpu nvidia pour obtenir de perf décentes, mais ça commence à faire tourner des jeux (trop lentement pour être jouable, certes). Pour les intéressés, j’ai pondu un petit script pour simplifier l’exécution du bouzin.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: QEMU
Posté par Martin Peres (site web personnel) . Évalué à 6.
Bourrins! Non mais sérieux, c'est des malades…
Bon, avec un peu de chance, ils vont beneficier des outils développés par nouveau pour savoir ce que fait exactement chaque instruction du GPU. Je me demande si Vulkan va pouvoir les aider car ils pourront traduire ca en SPIR-V. Reste à savoir comment les applications utilisaient le GPU à l'époque et si la création de pipeline states sera pas un facteur limitant les performances!
[^] # Re: QEMU
Posté par xcomcmdr . Évalué à 6.
La première Xbox, c'est un Pentium 3 à 733 MHz, une GeForce 3 modifiée, et 64 Mo de mémoire vive (DDR) partagée, mais c'est pourtant très difficile à émuler.
On sait émuler des Playstation 2, des Gamecube, et des Wii, mais aucune Xbox.
Peut être que la demande est moindre, aussi.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: QEMU
Posté par Prosper . Évalué à 4.
la difficulté principale vient surtout du gpu nvidia qui est plutôt different d une geforce3
http://www.neogaf.com/forum/showpost.php?p=48088464&postcount=26
# Génial mais dommage pas la même choses pour les autres noyaux
Posté par Shunesburg69 . Évalué à 1.
C'est agréable d'avoir des dépêches aussi détaillées.
J'aimerai bien qu'un jour il y ait la même chose pour le noyau de BSD ou celui de ReactOS.
[^] # Re: Génial mais dommage pas la même choses pour les autres noyaux
Posté par BAud (site web personnel) . Évalué à 8.
pour ReactOS il y a https://linuxfr.org/redaction/news/reactos-0-4-0
pour les *BSD, il y a au moins miod< qui passe de temps en temps, mais que ceux intéressés se lancent !
[^] # Re: Génial mais dommage pas la même choses pour les autres noyaux
Posté par Shunesburg69 . Évalué à 3. Dernière modification le 19 février 2016 à 11:52.
Pour FreeBSD j'ai vu désolé, mais pour ReactOS souvent on parle de l'OS mais pas trop des détails au niveau du noyau ou alors quelques trucs sommaires comme les nouveaux systèmes de fichiers.
[^] # Re: Génial mais dommage pas la même choses pour les autres noyaux
Posté par Thomas Debesse (site web personnel) . Évalué à 4.
Je recevrai de l’aide avec grand plaisir sur la partie noyau. Dans le ChangeLog tout est mélangé avec l’userland et c’est un peu difficile de rentrer dans le sujet d’un noyau (qui plus est NT)… En plus, vu que c’est la 0.4.0, on peut se permettre de détailler certaines directions prises depuis la 0.3.0.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Génial mais dommage pas la même choses pour les autres noyaux
Posté par windu.2b . Évalué à 8.
Pour Hurd, y a aussi du monde. C'est juste qu'ils attendent une nouvelle sortie…
[^] # Re: Génial mais dommage pas la même choses pour les autres noyaux
Posté par freem . Évalué à 2.
Question au passage, les *BSD, ils partagent le même kernels ou pas? Parce que tel que c'est présenté, on a l'impression qu'il s'agit d'OS (et non juste de distrib comme pour linux) différents… même s'il faut reconnaître qu'au moins eux n'ont pas 20 distrib qui ont les mêmes objectifs à epsilon près.
[^] # Re: Génial mais dommage pas la même choses pour les autres noyaux
Posté par BAud (site web personnel) . Évalué à 4.
plus ou moins, on va dire, même s'il y a clairement des divergences, non seulement dans les sources (qui reconvergent parfois) & surtout pour certains dans la config' retenue selon la distro
bin il y a les ports pour une grosse partie du userland. Mais pareil, PC-BSD, FreeBSD, DragonFlyBSD n'incluent clairement pas que le base-system
kof kof :-) cf. Berkeley_Software_Distribution, j'en compte 12 on va dire
Mais oui, l'approche de chacun est aussi distante qu'une Gentoo d'une Debian ou d'une Fedora ou d'une Slackware.
[^] # Re: Génial mais dommage pas la même choses pour les autres noyaux
Posté par Shunesburg69 . Évalué à 1.
Oups apparemment pour FreeBSD ça se fait déjà en date du 18/08/15
[^] # Re: Génial mais dommage pas la même choses pour les autres noyaux
Posté par Loïc Blot (site web personnel) . Évalué à 3.
Généralement je démarre toujours les articles FreeBSD et OpenBSD. Pour OpenBSD ce sera début mai, et début novembre, comme toujours. Pour FreeBSD, la 10.3 est en bêta il va être temps d'aller faire un tour sur les changelogs :)
Veepee & UNIX-Experience
# Erreur?
Posté par Ph Husson (site web personnel) . Évalué à 6.
"prise en charge du chipset Allwinner R8 de Mediatek"
Allwinner et Mediatek sont concurrents, ça m'étonnerait.
Le lien vers le commit de ce changement est mort, donc j'en sais pas plus.
Potentiellement, c'est l'ajout du support de puce wifi Mediatek pour C.H.I.P. qui est basée sur un Allwinner R8
[^] # Re: Erreur?
Posté par Ph Husson (site web personnel) . Évalué à 4.
"du SMP pour les 4 cœurs Cortex-A7 du SoC Mediatek MT658." devrait être MT6580
[^] # Re: Erreur?
Posté par Ph Husson (site web personnel) . Évalué à 3.
"Le pilote msm pour les GPU Qualcomm ajoute une gestion expérimentale du Snapdragon 8200."
Y a pas le lien du commit, mais c'est probablement Snapdragon 820 plutôt que 8200
[^] # Re: Erreur?
Posté par Martin Peres (site web personnel) . Évalué à 3.
Euh, oui! Désolé!
[^] # Re: Erreur?
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrections faites, merci.
# blocages lecture/écriture sur SSD/HDD
Posté par xcomcmdr . Évalué à 3.
Si je comprends bien, je vais arrêter d'avoir parfois le système qui se bloque temporairement parfois lors d'un accès à de grandes quantités de données séquentiellement sur mon HDD ou SSD ?
Car c'est quelque chose que j'ai toujours eu sous Linux, mais pas sous Windows.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: blocages lecture/écriture sur SSD/HDD
Posté par ʭ ☯ . Évalué à 4. Dernière modification le 19 février 2016 à 21:30.
J'ai jamais reproduit ton problème avec
dd if=/dev/sda bs=1M of=/dev/null
, tu es sûr que tu n'y ajoutes pas un swap saturé?
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: blocages lecture/écriture sur SSD/HDD
Posté par Florian.J . Évalué à 1. Dernière modification le 19 février 2016 à 23:27.
…Ou un partage NFS ?
J'ai des problèmes récurrents du même type (gel complet des accès disque pendant quelque secondes), qui disparaissent dès que je démonte le partage.
[^] # Re: blocages lecture/écriture sur SSD/HDD
Posté par BAud (site web personnel) . Évalué à 5.
sur un EeePC 901 avec que du SD, des I/O trop importantes gèlent la réactivité.
Bon, c'est un proc' mou, peu de RAM (seulement 1 Go), mais rester bloqué 5 sec quand il y a trop d'écriture, c'est un peu pénible…
Je n'ai pas de swap, ça ne sert à rien : si un logiciel demande tant de mémoire, il ne tournera pas très bien sur un CPU poussif…
J'ai beaucoup de cas d'usage qui fonctionnent très bien pour autant, même avec Gnome3 :
De temps en temps, les I/O sur disque gèlent effectivement la réactivité de mon EeePC 901 :/ C'est pénible, mais on s'habitue jusqu'à maintenant (même si mieux comprendre ce qui le déclenche pourrait aider).
[^] # Re: blocages lecture/écriture sur SSD/HDD
Posté par antistress (site web personnel) . Évalué à 2. Dernière modification le 20 février 2016 à 13:33.
J'ai moi-même un Dell mini9 (hackintosh) sous Debian stable avec GNOME 3 et Iceweasel, parfait pour surf et regarder des divx (http://libre-ouvert.toile-libre.org/index.php?tag/mini9)
J'ai aussi des gels, et c'est dommage, mais je ne saurais désigner le coupable. Tu es sûr que les I/O sur disque sont responsables ? Le CPU Atom-des-débuts me semblait un bon coupable également…
[^] # Re: blocages lecture/écriture sur SSD/HDD
Posté par BAud (site web personnel) . Évalué à 4.
bin, j'ai un GKrellM systématiquement sur mon bureau (une habitude du siècle dernier on va dire).
À chaque fois que j'ai un freeze : grosses I/O sur le disque, peu de CPU consommée, même le GKrellM ne se met plus à jour dans ces cas :/
donc bon, même si le CPU est poussif (c'est peu de le dire), ce n'est pas lui en cause àmha.
Un moyen facile pour le reproduire : graver un iso sur une clé USB, bah tu attends les 30 sec que ce soit fini et n'attend pas de pouvoir utiliser le netbook en même temps…
[^] # Re: blocages lecture/écriture sur SSD/HDD
Posté par antistress (site web personnel) . Évalué à 2.
merci je testerai un outil similaire pour voir
[^] # Re: blocages lecture/écriture sur SSD/HDD
Posté par Symen . Évalué à 3.
As-tu essayé de baisser la taille des tampons d'écriture dans le noyau ? (vm.dirty_bytes et vm.dirty_background_bytes, ou vm.dirty_ratio et vm.dirty_background_ratio)
Chez moi ils étaient énormes (plus de 1Go), ce qui menait à des situations où par exemple je lançais la copie d'un gros fichier sur une clé USB poussive, 99% de la copie se déroulait instantanément (remplissage du tampon), puis elle restait bloquée à 99% pendant 10 minutes sans pouvoir annuler la copie ni écrire quoi que ce soit d'autre.
[^] # Re: blocages lecture/écriture sur SSD/HDD
Posté par cluxter . Évalué à 7.
C'est quoi un hackintosh pour toi ?
[^] # Re: blocages lecture/écriture sur SSD/HDD
Posté par antistress (site web personnel) . Évalué à 4.
en tout cas c'est bien agréable de voir que les développements logiciels permettent d'optimiser nos vieilles bécanes, que ce soit avec le noyau Linux, les pilotes open-source comme Intel, l'arrivée de Wayland (https://bugzilla.gnome.org/show_bug.cgi?id=742254) ou le projet Candle de Mozilla (https://wiki.mozilla.org/Performance/Project_Candle) :)
[^] # Re: blocages lecture/écriture sur SSD/HDD
Posté par BAud (site web personnel) . Évalué à 10.
je crois qu'il va falloir préciser ce terme : dans les forums ici-même, certaines personnes avec un portable de 3 ans (2012 voire 2013 donc) considèrent que c'est un ancien voire un vieux PC : genre core i7, 16 Go de RAM hein… et certains se retrouvent à leur recommander un xubuntu… alors que bon, c'est une bête de course ce genre d'ordi ! Même actuellement, mon meilleur portable n'a que 8 Go de RAM et un CPU intel 5Y10 CPU @ 0.80GHz (avec GPU intégré).
[^] # Re: blocages lecture/écriture sur SSD/HDD
Posté par ʭ ☯ . Évalué à 2.
Pas de swap? C'est probablement là le problème. J'ai pour ma part mis un zram qui change tout même s'il n'est pas utilisé, ayant constaté que même avec un swapiness à zéro des processus swap faisaient ramer la machine…
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: blocages lecture/écriture sur SSD/HDD
Posté par freem . Évalué à 2.
Donc mon impression que webkit (et/ou son fork) bouffent nettement plus que firefox n'est pas illusoire? Le pire c'est que maintenant, quasi tout les browsers (IE et FF à part pour les "gros") n'ont pas une base webkit…
D'un autre côté, ça tiens peut-être des IHM? Quelqu'un sait comment mesurer la part des ressources bouffées par un utilisateur en particulier de webkit(ou son fork, me souviens plus du nom)?
[^] # Re: blocages lecture/écriture sur SSD/HDD
Posté par BAud (site web personnel) . Évalué à 2. Dernière modification le 23 février 2016 à 00:01.
Pour la comparaison de mémoire :
about:memorychrome://memory-redirect/mais les lenteurs peuvent venir de la gestion du cache, le déclenchement d'un GC, des onglets restant actifs (ou non) lorsqu'ils ne sont pas affichés => tout ceci a fait l'objet d'améliorations dans les dernières versions des deux navigateurs.
[^] # Re: blocages lecture/écriture sur SSD/HDD
Posté par freem . Évalué à 4.
La consommation mémoire ne veut rien dire dans le cas des browsers. Ils ont la fâcheuse tendance à gérer eux-même des caches sur le disque, après tout (plutôt que de laisser le kernel le faire, mais parfois je pense que les des de trucs webs se … laissons tomber).
Très honnêtement, je pense que les problèmes que j'expérimente sont plus dus a vivaldi qu'autre chose, et que c'est en train de franchir un tel cap de gêne qu'otter-browser pourrait devenir mon navigateur par défaut, malgré ses gros problèmes d'utilisabilité. Quitte a essayer de contribuer à l'une de ces usines à gaz, si j'arrive a compiler… à voir.
[^] # Re: blocages lecture/écriture sur SSD/HDD
Posté par antistress (site web personnel) . Évalué à 2. Dernière modification le 24 avril 2016 à 17:08.
Un upgrade du SSD reste envisageable, perso je me tate.
Par exemple :
LDLC SSD F2 mSATA 32 GB Vitesse d'écriture : 45 mo/s | Vitesse d'écriture aléatoire : 1000 IOPS http://www.ldlc.com/fiche/PB00200471.html ~20€
Kingston SSDNow mS200 mSATA 60 Go Écriture séquentielle SATA Rev. 3.0 jusqu'à : 520 Mo/s | Écriture/lecture aléatoire 4K : jusqu’à 86.000 IOPS http://www.ldlc.com/fiche/PB00148278.html ~40€
Avis ?
De mémoire les tests du SSD d'origine du Mini 9 donnaient ~10 mo/s en écriture…
[^] # Re: blocages lecture/écriture sur SSD/HDD
Posté par xcomcmdr . Évalué à 2.
J'ai 12 Go de RAM, Firefox, un Quad Core, et trois onglets dans Firefox.
L'écriture/lecture important peut venir d'un déplacement sur un HDD externe, une création d'un gros fichier, etc…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: blocages lecture/écriture sur SSD/HDD
Posté par eingousef . Évalué à 3.
T'aurais pas un portable sur batterie avec un paquet du style "laptop-mode-tools" d'installé ? Parce que chez moi avec ce paquet et en mode batterie, les disques durs "externes" arrêtent de tourner quand ils sont pas utilisés, et dès qu'un programme tape dedans, crac, ça freeze pendant une ou deux secondes le temps qu'ils se réveillent. Apparemment ça concerne les disques USB mais aussi le disque secondaire qui remplace le lecteur optique sur mon laptop (c'est peut-être tous les disques qui n'ont pas de partition système en fait).
*splash!*
[^] # Re: blocages lecture/écriture sur SSD/HDD
Posté par Symen . Évalué à 1.
Dans le même genre, sur mon netbook les têtes de lectures du disque se parquaient déjà après quelques dizaines de secondes sans accès disque, causant des lags réguliers de 2-3 secondes (alors que le disque lui-même continuait de tourner).
Du coup je pense aussi qu'il serait intéressant de désactiver les paramètres d'économie d'énergie, voir même de vérifier à la main avec hdparm -B que le niveau d'économie d'énergie du disque (APM level) est au minimum (254 ou 255 (off) selon les disques)
# Je vous aime
Posté par antistress (site web personnel) . Évalué à 7. Dernière modification le 20 février 2016 à 13:25.
Merci aux rédacteurs des dépêches noyau, je vous aime :)
Et aussi, c'est agréable dans cette version de lire la collaboration de Nvidia avec les contributeurs habituels de nouveau
# VRF vs Namespace
Posté par erdnaxeli (site web personnel) . Évalué à 2. Dernière modification le 20 février 2016 à 22:56.
J'ai toujours cru que les network namespaces et les VRF étaient équivalents (et les VRF de Cisco sont d'ailleurs mappées sur des namespaces Linux dans NX-OS). Quelle est la différence ?
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: VRF vs Namespace
Posté par Ph Husson (site web personnel) . Évalué à 5.
Il suffit de regarder le mail de demande d'inclusion ;)
https://lwn.net/Articles/632522/
« Of the list of problems
noted the big one is that namespaces do not scale efficiently to the number
of VRFs supported by networking gear (> 1000 VRFs). Networking vendors that
want to use Linux as the OS have to carry custom solutions to this problem --
be it userspace networking stacks, extensive kernel patches (to add VRF
support or bend the implementation of namespaces), and/or patches to many
open source components. The recent addition of switchdev support in the
kernel suggests that people expect the use of Linux as a switch networking
OS to increase. Hopefully the time is right to re-open the discussion on a
salable VRF implementation for the Linux kernel. »
Du coup la raison principale de l'auteur pour faire ça est visiblement la mise à l'échelle.
Une autre raison citée dans la dépêche de Linux 4.3 ( http://linuxfr.org/news/sortie-du-noyau-linux-4-3#prise-en-charge-initiale-des-vrf ) est de permettre le switch de table de routage de manière atomique, et de tester sa table de routage avant de l'appliquer.
[^] # Re: VRF vs Namespace
Posté par erdnaxeli (site web personnel) . Évalué à 7. Dernière modification le 21 février 2016 à 12:50.
Je suis allé voir le mail en question, qui est très intéressant. Voici donc un peu plus de détails pour ceux que ça intéresse.
Premièrement :
Mais les namespaces ne sont pas réellement adaptés. Quand on parle de VRF, on pense à une séparation L3 (Virtual Routing and Forwarding). Les namespaces eux séparent toute la stack réseau : L2 (interfaces) et L3 (RIB, FIB, Neighbors table). D'où les problèmes de mise à l'échelle (le coût d'un namespace est d'environ 200Ko de mémoire). En plus de cela s'ajoute des problèmes pratiques, puisqu'un processus qui veut pouvoir utiliser plusieurs namespaces doit avoir les droits root (ce qui n'est pas nécessaire pour ouvrir juste des sockets (même pour un port inférieur à 1024, on a pas besoin des droits root complets, juste de CAP_NET_BIND_SERVICE)).
Les VRF solutionnent ce problème en étant vraiment ce que leur nom indique, à savoir une séparation L3, et en ayant un coût quasi nul. On peut maintenant avoir plusieurs VRF dans un même namespace, et un processus peut changer la VRF d'un socket avec setsockopt sans être root.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
# Rémunération des développeurs noyaux
Posté par Eiffel . Évalué à 2.
J'ai eu une discussion avec quelqu'un qui travaillait chez Red Hat qui m'avait dit que les développeurs noyaux étaient plutôt bien payés et qu'ils avaient des conditions de travail sympa.
Sur le coup je n'ai pas pensé à lui demander ce qu'il entendait par "bien payé". Or j'aimerai bien devenir développeur noyau, par conséquent vous comprendrez que je m'intéresse un minimum à la rémunération ?
[^] # Re: Rémunération des développeurs noyaux
Posté par pasBill pasGates . Évalué à 2.
Ta question n'a pas de sens.
Le salaire varie selon le pays, selon l'expérience, selon la boite, selon le niveau de la personne… Par exemple si demain je changes de pays, mon salaire pourrait se voir couper en 3, aussi simple que ça.
[^] # Re: Rémunération des développeurs noyaux
Posté par Eiffel . Évalué à 1.
J'avais oublié de préciser que je parlais d'un développeur français et j'en profite pour préciser junior.
[^] # Re: Rémunération des développeurs noyaux
Posté par Antoine . Évalué à 5.
La question est un peu bizarre. Développeur noyau, ça veut avant tout dire que tu choisis une spécialisation très pointue qui t'intéresse fortement, où il faudra bosser beaucoup pour devenir et rester compétent, AMHA. Si c'est la rémunération qui t'attire, il y a probablement des voies plus faciles pour gagner sa vie.
Ceci dit, je ne doute pas que ce soit bien payé, mais c'est aussi un boulot que font assez peu de gens.
[^] # Re: Rémunération des développeurs noyaux
Posté par Eiffel . Évalué à 3.
J'étais sûr qu'en posant une telle question j'allais passer pour un gros rat qui aime l'argent.
Donc non, je ne veux pas devenir développeur noyau car ça paye bien mais parce que le développement bas niveau m'intéresse ET parce que c'est libre (parce que j'aimerai bien vivre du libre).
Je voulais juste me renseigner sur le salaire d'un métier que je n'écarte pas de mes possibilités futures.
[^] # Re: Rémunération des développeurs noyaux
Posté par BAud (site web personnel) . Évalué à 7. Dernière modification le 26 février 2016 à 22:30.
je ne pense pas que c'est le sens de la réponse d'Antoine<
Effectivement, en France certaines personnes renâclent à indiquer leur salaire (surtout pour ne pas susciter de jalousie àmha). Pour autant, là où cela peut passer pour une fierté de la culture anglo-saxonne de l'afficher, dans le monde de l'informatique je pense que les grilles sont bien connues :
bin, c'est la difficulté de te répondre : que tu sembles osciller entre libre et non libre, ne donne pas l'expérience que tu as à participer déjà (ne serait-ce que pour un patch d'une ligne au noyau, moi j'en ai une voire deux, pas beaucoup plus :/).
Bon, je vais encore me faire descendre pour avoir donné des chiffres :/ Tu trouveras mon salaire actuel au hasard dans un de mes commentaires descendu en flèche :-)
J'imagine qu'une étude a été faite sur le salaire moyen des informaticiens, selon le pays, le domaine, le produit (SAP paie plus il paraît, même si c'est très surfait), si tu trouves ce genre d'étude, n'hésite pas à partager :p
[^] # Re: Rémunération des développeurs noyaux
Posté par Eiffel . Évalué à 1.
Tout d'abord, je tiens à te remercier pour ta réponse :)
Après c'est clair que je ne serai pas développeur noyau demain, je n'ai fait aucune contribution et je ne consulte même pas la mailing list. Disons que, pour le moment, je fais mes premiers pas (à 4 pattes) dans le noyau.
Si on ne part pas en hors sujet, quelqu'un pourrait-il m'en dire plus sur les groupes ?
En effet je n'ai jamais entendu parler de ces groupes.
[^] # Re: Rémunération des développeurs noyaux
Posté par BAud (site web personnel) . Évalué à 3.
bah, c'est une notion des RH : à tes 18 ans, tu as choisi une école (une prépa de préférence, l'université c'est que tu voulais glander, un BTS c'est que tu n'étais pas bon, il y a l'alternance qui se démarque), à tes 20 ans tu as passé un concours et cela te suivra toute ta vie…
Pour caricaturer :
groupe A : Polytechnique, Centrale, Telecom Paris…
groupe B : IEE, Paris Tech
groupe C : Epita, epitech… (vu que tu achètes ton diplôme, faut assumer qu'il ne soit pas reconnu par la commission dans le cas de l'epitech)
bon, mon avis est sans doute biaisé sans le i, mais c'est ce que j'ai pu constater (et qui semblait partagé). Ne te fais pas léser avec un grand B.
En revanche, je suis très déçu : si tu veux devenir développeur noyau, bin envoie ton code, spa si dur, le salaire est accessoire… ou cela viendra de soi, si tu es bon. Ça me semble normal.
[^] # Re: Rémunération des développeurs noyaux
Posté par Renault (site web personnel) . Évalué à 8.
Je suis contributeur noyau débutant en embarqué (je ne contribue pas encore sur la branche Linus donc), et j'ai pu obtenir 35k€ en province pour ce travail. ;-)
[^] # Re: Rémunération des développeurs noyaux
Posté par BAud (site web personnel) . Évalué à 2.
il y a http://free-electrons.com/ qui fait du bon boulot dans l'embarqué
nous aimerions bien qu'ils nous rejoignent pour la version ARM de Mageia :-) (blino et pterjan sont sur le coup avec rtp, manque un communicant on va dire :D)
[^] # Re: Rémunération des développeurs noyaux
Posté par lasher . Évalué à 4.
Mais non tu ne passes pas pour un gros rat. :-) Et la question est légitime. Ceci étant dit, faire du dev noyau c'est évoluer dans un monde assez restraint, mais généralement demandé. Donc à moins d'être vraiment « junior » (i.e., aucune expérience dans le domaine) le salaire devrait être décent comparé aux salaires « locaux » (pBpG a raison de faire remarquer que les salaires d'un pays à l'autre varient pas mal).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.