Sortie du noyau Linux 4.5

74
20
avr.
2016
Noyau

La sortie de la version stable 4.5 du noyau Linux a été annoncée le 13 mars 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

RC1

La version RC1 est sortie le dimanche 24 janvier 2016 :

La fenêtre de fusion est close et la RC1 est là. Allez‐y, testez !

C’est une version relativement normale — ni anormalement grande, ni anormalement petite. Les statistiques sont également relativement normales, avec les pilotes un peu au-dessus de 70 % de l’ensemble (le gros des pilotes étant les pilotes graphiques, le réseau, le son, staging, fbdev, mais il y en a un peu partout). Le journal abrégé est trop gros et indigeste pour être joint au message ; mais, je joins mon « journal de fusion » qui crédite les mainteneurs avec lesquels j’ai effectué les fusions — mais pas nécessairement les personnes qui ont fait chacun des correctifs.

Outre les pilotes, nous avons les mises à jour d’architectures (plus de la moitié d’entre elles étant pour ARM — 32 et 64 bits cette fois‐ci, le reste se composant des PowerPC, x86, MIPS, S390). Concernant les architectures, il est probablement utile de mentionner qu’apparemment, les gens d’ARM (!) ont finalisé leurs travaux sur la plate‐forme et que vous pouvez vraiment construire un noyau ARM générique pour toutes les plates‐formes ARMv6/7 (et décrire le matériel avec devicetree). Ça a pris de nombreuses années pour y arriver. Beau boulot.

Il y a, évidemment, les habituelles mises à jour de documentation, de systèmes de fichiers, de réseau et celles du noyau de base. Un certain nombre de jolis nettoyages de MM sont venus d’Andrew cette fois‐ci, par exemple, et Al Viro a fait en sorte que les recherches de chemin (pathname lookup) restent en mode RCU, même lors des traversées de chemins symboliques (symlink traversal).

Il y en a un peu pour tout le monde.

Linus

RC2

La version RC2 est sortie le dimanche 31 janvier 2016 :

Pas plus tard que vendredi, je comptais parler de combien il est agréable de voir cette nouvelle tendance de petites RC2, parce qu’il n’y avait vraiment pas eu beaucoup de demandes d’intégration.

Mais il s’avère que les demandes d’intégrations étaient juste fortement décalées vers la fin de la semaine et que la 4.5-rc2 n’est pas particulièrement petite après tout. Elle a quasiment doublé dans le week-end.

Ce n’est pas si gros que ça de toute façon et le décalage vers la fin de la semaine est probablement logique pour une RC2 — ça prend un certain temps pour commencer à trouver les problèmes que la fenêtre d'intégration a apportés. Ainsi, ce comportement bizarre ne m’inquiète pas : ça me parait assez naturel.

Pour le type de corrections que nous avons ici, le journal abrégé donne plus de détails, mais il y en a un peu partout. Les mises à jour de pilotes et d’architectures représentent seulement la moitié environ des modifications, avec des correctifs de performance et de nouveaux auto-test de virtio représentant la plupart de ce qui reste. Il y a également des correctifs de btrfs.

Rien de tout cela n’est vraiment important de toute façon.

Allez‐y, testez.

Linus

RC3

La version RC3 est sortie le dimanche 7 février 2016 :

C’est dimanche après-midi et tout est normal. Donc ça signifie qu’il y a une nouvelle RC pile dans les temps.

Elle est légèrement plus grosse que j’aurais aimé, mais pas excessivement (ni même inhabituellement). La majorité des correctifs sont assez petits, bien que les modifications soient totalement dominées par la (grosse) suppression des pilotes RDMA en staging qui n’allaient nulle part. Ces correctifs de suppression représentent 90 % du changement.

Les 10 % restants sont constitués principalement des pilotes (réseau, pilotes graphiques, son, USB), et de divers autres choses (réseau de base, quelques correctifs VM d’Andrew, ceux des systèmes monopuces ARM, la crypto, etc.).

Donc, ce n’est peut‐être pas une petite RC, mais il n’y a rien non plus de particulièrement inquiétant.

Le journal abrégé est joint, pour les personnes qui veulent un aperçu plus détaillé.

Linus

RC4

La version RC4 est sortie le dimanche 14 février 2016 :

C’est la Saint-Valentin, donc je prépare un cadeau pour tous, sous la forme d’une RC habituelle.

Tout a l’air normal, il y a un problème en attente et non expliqué pour l’instant, avec des modifications concernant les VM dans cette version (en particulier le nettoyage transparent des huge pages), mais cela semble concerner uniquement l’architecture S390, donc cela ne devrait pas bloquer tout le monde.

Et sinon tout semble normal. La taille est normale, comparée aux récentes RC4, et rien ne ressort en particulier. Un peu moins des 2/3 concerne les pilotes (DRM, son, SCSI, réseau… C’est assez réparti), et le reste est habituel : mises à jour d’architectures, (ARC, MIPS, ARM) et diverses choses (cryptographie, réseau et noyau…).

Comme d’habitude, le journal abrégé est attaché, on peut le parcourir pour avoir une idée de ce qui se passe.

Donc, à part vous occuper de votre chéri(e), vous pouvez y aller et tester.
Je voyagerai la semaine prochaine, mais j’aurai mon ordinateur portable, et si les choses restent tranquilles et normales comme jusqu’ici, il ne devrait pas y avoir de problèmes.

Linus

RC5

La version RC5 est sortie le samedi 20 février 2016 :

Tout continue à être normal et a été bien calme. D’accord, le nettoyage de la VM THP semble toujours poser problème sur S390, mais à part cela, je ne vois rien d’inquiétant.

Une autre semaine, une autre RC. La modification a l’air tout à fait normale, avec 55 % de pilotes (DRM et clk surtout, mais ils ne sont pas seuls) et presque 20 % de mises à jour d’architectures (ARM, m68k, PowerPC, S390, x86). Le reste est réparti entre systèmes de fichiers (ext4, EFI, CIFS), quelques mises à jour de noyau et en‐têtes de fichiers. Et des mises à jour de documentation. Tout a l’air normal.

Le journal abrégé est joint.

Linus

RC6

La version RC6 est sortie le dimanche 28 février 2016 :

J’aurais souhaité une RC-6 plus petite mais, en même temps, je suis plutôt soulagé que Kirill ait trouvé et corrigé le problème avec le nettoyage du code des THP qui nous avait frappé pendant ce cycle de publication. Donc, je ne peux pas vraiment me plaindre. S’ajoute à mon grand soulagement un autre rapport de bogue effrayant qui s’est avéré ne pas être du tout un bogue du noyau, mais un problème de microcode. Ce qui pourrait peut‐être être pire, mais au moins ce n’est pas quelque chose dont nous sommes responsables (et maintenant que c’est connu, c’est évitable).

Les statistiques des changements paraissent bizarres cette fois, parce qu’il y a un gros correctif concernant les fichiers d’en‐tête des pilotes réseau, qui donne l’impression que le dossier des include représente quasiment 40 % des changements. Mais ce correctif ne fait que renommer une tonne de champs réservés, aucun code n’est effectivement modifié.

Si l’on ignore cette bizarrerie statistique, tout semble plutôt normal : principalement des pilotes (le réseau et l’USB dominent, mais il y a également quelques modifications de pilotes graphiques, son, ACPI), avec les habituelles mises à jour d’architecture (ARC, ARM, x86) et un peu de réseau de base. Quelques travaux de performance et quelques corrections de systèmes de fichiers (NFS, DAX et un peu de VFS de base).

J’aimerais pouvoir dire que nous sommes sur la bonne voie pour respecter le calendrier habituel de publication, mais attendons de voir l’avancement la semaine prochaine. Si la RC-7 n’a pas commencé à diminuer, je pourrais décider finalement que cette version est l’une de celles où l’on fait aussi une RC-8. C’est trop tôt pour le dire. Il n’y a rien de particulièrement effrayant, mais j’aurais aimé une RC encore plus calme cette semaine.

Le journal abrégé est joint, comme d’habitude, pour les personnes qui veulent un aperçu des détails.

Linus

RC7

La version RC7 est sortie le dimanche 6 mars 2016 :

Les choses se sont calmées la semaine dernière et je pense que l’on aboutira à une version normale, où la RC-7 est la dernière RC.

Bien sûr, je me réserve le droit de changer d’avis, au cas où nous trouverions quelque chose de fâcheux, mais dans l’ensemble, ça me paraît bien. Nous avons eu des changements plus importants que je n’aimerais à ce stade, mais ils concernaient pour la plupart des pilotes individuels. La plupart des modifications sont triviales, d’une ou deux lignes, avec peut‐être juste la couche bloc qui se distingue par de plus gros changements (et plus gros relativement au reste, pas particulièrement gros dans l’absolu).

Les changements sont très épars, mais environ 3/4 touchent les pilotes (la suppression d’un pilote USB redondant représente le plus gros morceau, mais il y a un peu de tout, y compris des correctifs de compatibilité de son, de pilotes graphiques, watchdog, libdata, RDMA, etc.). Le reste correspond à des correctifs d’architectures (SPARC, x86, MIPS, ARM) et de systèmes de fichiers (JFFS, CIFS, Ceph, Btrfs, mais aussi un joli petit correctif dans le code de dentry qui non seulement corrige un bogue, mais nettoie aussi pas mal de choses).

Donc, allez‐y, testez, parce que nous devrions avoir pratiquement terminé à ce point pour cette version et les choses semblent aller très bien.

Le journal abrégé est joint comme d’habitude, pour les personnes qui veulent des informations plus détaillées à propos des choses qui ont eu lieu cette semaine,

Linus

Version finale

La version finale est sortie le dimanche 13 mars 2016 :

C’est un peu tard pour un dimanche, plus tard que mon horaire habituel, parce que je n’arrivais pas à décider si je devais faire une RC-8 ou pas et j’ai tergiversé à ce sujet. En fin de compte, j’ai évidemment décidé de publier, mais il aurait pu en être autrement.

Nous avons eu une méchante régression qui a été réparée hier. Les dernières corrections de la couche réseau envoyées en début de semaine étaient plus grandes que je ne l’aurais souhaité. Mais la couche bloc devrait être parfaite maintenant. David a relu toute sa demande de modification de la couche réseau une nouvelle fois pour me rassurer à ce sujet. Donc, à la fin, je ne vois rien pour retarder ce cycle de sortie plus longtemps que d’habitude.

Dans l’ensemble, tout semble plutôt petit. Le diffstat paraît un peu plus gros pour un correctif de XFS, parce qu’il a trois correctifs de travail de nettoyage qui le précèdent. Il y a aussi un correctif de modèle de type d’accès (?) dans la couche son qui générait beaucoup de bruit, mais tout est très simple en fin de compte.

En plus de ce qui précède, il y a de petits correctifs un peu partout — le journal abrégé est joint pour les gens qui veulent parcourir les détails, comme d’habitude.

Allez‐y, testez. Et, évidemment, avec la publication de la 4.5, je vais ouvrir la fenêtre de fusion pour la 4.6.

Linus

Les nouveautés

Gestion de la mémoire

Architecture

Gestion d’énergie

La gestion d’énergie du noyau est améliorée (et le sera davantage pour la prochaine version 4.6), grâce à une meilleure gestion du processeur graphique, de l’ACPI et du PCI express. Si vous aimez les chiffres et les jolies courbes, Phoronix montre l’amélioration de la consommation, en milliwatts. En résumé, nous avons un gain moyen de 9 % pour la version 4.5 par rapport à la version 4.4 et, logiquement, la température globale baisse d’un même facteur. Des gains de 10 % à 12 % supplémentaires sont à attendre pour la version 4.6.

ARM SoC

Retravail massif des architectures ARM v6 et ARM v7

Ce travail est le résultat de cinq ans pour unifier les architectures ARM v6 et ARM v7 et permettre l’utilisation du même noyau. Cela fait suite au grand nettoyage et travail d’abstraction de la plate‐forme via la création de sous‐systèmes. Cela permet, entre autres, de faire démarrer différentes plates‐formes avec un seul et même noyau, alors que, jusqu’à présent, il était nécessaire d’avoir un noyau par plate‐forme.

Référence : commit.

En bref

  • prise en charge des processeurs ARM Cortex-A9Tango4, spécialisés pour les plates‐formes multimédia « sécurisées » de Sigma Designs ;
  • prise en charge du Broadcom BCM2836 (système monopuce du Raspberry Pi 2) et de la gestion de puissance (power management) via le microcode interne ;
  • activation de cpufreq sur le Freescale i.MX7D ;
  • Rockchip : prise en charge du SMP pour le rk3036, prise en charge générale pour le rk3228 ;
  • prise en charge du SMP pour les systèmes monopuces Broadcom Kona et NSP ;
  • nettoyage du côté OMAP en supprimant l’ancien code IOMMU ;
  • ajout de la prise en charge de l’Orange Pi Plus (puce Allwinner).

MIPS

  • Début de prise en charge du système monopuce à base de MIPS Microchip PIC32MZDA, actuellement seulement le Device Tree, les pilotes viendront pour Linux 4.6 ;
  • prise en charge des structures nvram pour BCM963xx ;
  • beaucoup de travail sur la prise en charge de la norme IEEE Std 754 (math-emu) ;
  • prise en charge du MediaTek MT7621.

Développement et traçage

Prise en charge de l’option Sanitizer (-fsanitize=undefined) de GCC

Cette option, disponible à partir de GCC 4.9, est un outil de débogage qui insère du code d’instrumentation durant la compilation. Ce code permet de faire des vérifications à l’exécution, et de prévenir en amont les comportements dits « indéfinis ». Désormais, le noyau 4.5 prend en charge l’activation de cette option.

Introduction d’un nouvel appel système copy_file_range()

Ce nouvel appel système copy_file_range() permet de faire des copies « sans charge ». S’il n’apporte que peu d’avantage en local, ce nouvel appel permet, dans le cas de systèmes de fichiers réseau, d’effectuer la copie sans passer par le client dans le cas d’un transfert sur le même serveur. Par exemple, pour une copie en NFS, il peut éviter de faire transiter le flux du fichier sur le réseau.

Pilotes graphiques libres

AMD (pilotes amdgpu et radeon)

Prise en charge expérimentale de PowerPlay

La prise en charge expérimentale de PowerPlay apporte de meilleures performances au pilote amdgpu. Les cartes graphiques modernes démarrent en mode économie d’énergie et faible performance. Pour avoir les meilleures performances, la carte doit dynamiquement changer ses fréquences d’horloge.

Linux 4.5 ajoute la prise en charge de la technologie PowerPlay dans le pilote amdgpu pour les processeurs graphiques Tonga et Fiji, ainsi que pour les processeurs graphiques embarqués Carrizo et Stoney.

PowerPlay est le nom commercial d’un ensemble de technologies de gestion de l’énergie réalisées dans plusieurs processeurs graphiques AMD. Il est disponible via le pilote propriétaire Catalyst et a pour but de remplacer la gestion de l’énergie actuellement utilisée sous Linux dans le pilote amdgpu.

Pour les processeurs graphiques ayant la possibilité de changer les fréquences d’horloge, les performances seront bien meilleures.

PowerPlay n’est pas activé par défaut pour le matériel pris en charge, à cause de soucis de stabilité. Il est cependant activable en ajoutant l’option « amdgpu.powerplay=1 » au démarrage.

Voir : https://lists.freedesktop.org/archives/dri-devel/2015-November/094230.html.

Broadcom (pilote vc4 pour RPi)

Intel (pilote i915)

  • ajout d’une prise en charge basique de Kabylake ;
  • ajout de l’identificateur PCI pour le SKL GT4 ;
  • ajout de la prise en charge de DP MST (Display Port Multi-Stream Transport) côté processeur graphique, pour l’audio.

NVIDIA (pilote nouveau)

  • prise en charge du changement de vitesse du PCI Express ;
  • suppression de l’interface pstate, ajout de debugfs ;
  • améliorations diverses.

Autres

Ajout du pilote DRM etnaviv pour cœur 3D basé sur Vivante, utilisé dans de nombreuses cartes ARM.

Réseau

 Paramètres TCP keepalive configurables par espace de noms réseau

Les paramètres réseaux par défaut (tcp_keepalive_time, tcp_keepalive_intvl, tcp_keepalive_probes) gérant les paquets TCP keepalive sont maintenant configurables par espace de nommage réseau (network namespace) grâce à Nikolay Borisov ([1], [2] et [3]).

Les espaces de nommage réseau, dont les conteneurs sont friands, sont des copies de la pile réseau, avec leurs propres interfaces, routes, règles pare‐feu, mais aussi leurs propres paramètres réseaux accessibles par le pseudo‐système de fichiers /proc, par exemple.

Pour rappel, le principe des paquets keepalive est de détecter les déconnexions et de maintenir les connexions actives malgré les équipements réseau rencontrés (pare‐feu, NAT…). Ainsi, lorsqu’un socket est configuré avec l’option SO_KEEPALIVE, ce qui n’est pas le cas par défaut, un chronomètre est activé à chaque réception de paquet. Après une certaine durée — tcp_keepalive_time — sans avoir reçu de nouveau paquet de l’hôte distant, un paquet sonde keepalive est émis, afin de solliciter une réponse. Sans réponse, de nouveaux paquets sondes keepalive sont réémis à intervalle de temps régulier tcp_keepalive_intvl. Passé un certain nombre d’essais tcp_keepalive_probes, la connectivité est considérée comme perdue si aucun paquet n’a été reçu.

 Ajout des compteurs paquets/octets au module Netfilter nft_ct

Les expressions de suivi de connexion ct (conntrack) dans les règles nftables acceptent maintenant deux paramètres supplémentaires, packets et bytes, qui permettent par exemple de filtrer les connexions « suivies » respectivement par nombre de paquets ou par nombre d’octets échangés.
Si la direction (original ou reply) n’est pas précisée, ces compteurs représentent la somme des valeurs dans les deux sens. Amélioration proposée par Florian Westphal [1].

Sécurité

Périphériques en mode bloc (block devices)

Correction pour la couche MD (dont le mainteneur quitte son rôle de mainteneur) pour la prise en charge des horodatages de 64 bits pour le bogue de l’année 2038.

Amélioration de la stabilité de BCache pour former une sorte de disque hybride à partir d’un SSD et d’un disque rotatif.

Diverses améliorations sur l’implémentation des normes NVM Express (NVMe) et lightNVM, qui sont bien plus adaptées pour le transfert vers les disques non‐rotatifs comme les SSD.

Systèmes de fichiers

Btrfs

Une nouvelle gestion du système de cache de l’espace libre permet d’être plus performant. Cela se ressent surtout sur les larges volumes de plus de 30 Tio. Cette fonctionnalité peut être testée via l’option « space_cache=v2 ».

ext4

Diverses corrections, surtout autour du chiffrement, ont été récemment ajoutées. Ajout du projet de quota.

Virtualisation

Il y a peu de changements avec cette version. Espérons que ça nous réserve de plus grands changements pour la suite.

KVM

S390

Prise en charge du runtime instrumentation pour les invités. Cela permet de faciliter le traçage et le débogage d’applications. Cela est utilisé par des outils comme Valgrind.
Un invité peut maintenant avoir 248 processeurs virtuels.

ARM

Réécriture du world switch de l’architecture ARM64 en C. Prise en charge des identifiants de machine virtuelle sur 16 bits. Les compteurs de performances de la virtualisation devaient être introduits avec cette version, mais ils ont raté la fenêtre de fusion.

x86

Introduction de nouvelles fonctionnalités Hyper-V (synthetic interrupt controller, un des blocs du bus des périphériques paravirtualisés), nettoyage du code des MMU.

Cgroups

Stabilisation de l’unification de la hiérarchie des cgroups : Les cgroups, introduits depuis le noyau 2.6.24, ont été retravaillés pour obtenir une nouvelle implémentation disponible depuis le noyau 3.16. Cette nouvelle version n’était disponible jusqu’à présent que via une option de montage spécifique (-o DEVEL_sane_behavior), attestant de son caractère expérimental.

Ce code est considéré comme suffisamment stable pour être désormais exposé plus directement, via le type de système de fichiers cgroup2, montable directement sans option spécifique.

Le bilan en chiffres

Selon le site LWN.net, l’article de Jonathan Corbet indique que cette version 4.5 a impliqué 1 528 développeurs, alors que pour la version 4.4, il y en avait eu 1 575.
Nombre de lignes par entreprise

Pour cette version 4.5, la palme du développeur le plus actif a été remportée par Linus Walleij, si l’on s’appuie sur le nombre de commits (236 changesets), ou par Doug Ledford, si l’on s’appuie sur le nombre de lignes modifiées (53 086 lignes).
Nombre de lignes par entreprise

Si l’on se réfère aux entreprises impliquées dans le noyau, Intel l’emporte haut la main, notamment devant Red Hat, Linaro, Samsung et AMD, en nombre de commits, même si Red Hat est premier d’une courte tête en nombre de lignes modifiées.

Systématisation du choix du noyau destiné à être maintenu à long terme

L’annonce a été faite durant ce cycle : dorénavant le premier noyau à sortir chaque année sera automatiquement désigné comme étant la version LTS annuelle, comme développé dans ce journal.

Appel à volontaires

Cette dépêche a nécessité plus de 410 éditions (à l’heure de l’écriture de ces statistiques), et mobilisé 23 personnes du 24 février 2016 au 13 avril 2016 dans l’espace de rédaction.

Graphe
Cette dépêche est rédigée par plusieurs contributeurs, dont voici la répartition :

Répartition des modifications par utilisateur

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

  • # Bilan en chiffre

    Posté par  . Évalué à -1.

    Intel l’emporte haut la main, notamment devant Red Hat

    Heu c'est pas plutôt l'inverse ???

    • [^] # Re: Bilan en chiffre

      Posté par  (site web personnel) . Évalué à 4.

      Il faut lire la phrase en entier ;-)

      S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

    • [^] # Re: Bilan en chiffre

      Posté par  (site web personnel) . Évalué à 7. Dernière modification le 20 avril 2016 à 23:45.

      c'est surtout eggman< qui a été très présent pour rédiger cette dépêche… de là à demander ou plébisciter qu'il remplace mupuf<, mon don pour la prétérition ne me le fera pas proposer.

      Bref, si la dépêche sort avec un mois de retard (la suivante est déjà en cours et il y a du boulot), c'est aussi ma faute, pardon aux familles toussa : n'hésitez pas à participer, ce n'est pas si compliqué vu qu'à une époque patrick_g< le faisait tout seul ! cf. thèmes récurrents et template-des-news-noyau

      Merci de votre attention, en espérant votre implication à Participer à LinuxFr

      • [^] # Re: Bilan en chiffre

        Posté par  . Évalué à 3.

        c'est surtout eggman< qui a été très présent pour rédiger cette dépêche… de là à demander ou plébisciter qu'il remplace mupuf<, mon don pour la prétérition ne me le fera pas proposer.

        En fait ce que je fais depuis que je participe au dépêches noyau, c'est de la traduction et des relectures.
        Rien de folichon, mais c'est indispensable.
        Je ne me sens pas du tout suffisamment de compétences pour plein d'aspect techniques, même si je comprends ce que je lis.
        Au surplus, je fais ça quand j'ai du temps et parce que ça m'amuse.
        Donc prendre les rennes des dépêches noyaux, c'est pas pour tout de suite.

        0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0

  • # Chiffrement dans Ext4

    Posté par  (site web personnel) . Évalué à 6.

    Ext4

    Diverses corrections surtout autour du chiffrement ont été récemment ajoutées.

    Il y a des fonctionnalités de chiffrement dans Ext4‽

    • [^] # Re: Chiffrement dans Ext4

      Posté par  (site web personnel) . Évalué à 10. Dernière modification le 20 avril 2016 à 14:35.

      T'es nouveau ici ? :) Cf Linux 4.1 section ext4 (évoqué aussi dans les dépêches suivantes 4.2 , 4.3 et 4.4 ).

      • [^] # Re: Chiffrement dans Ext4

        Posté par  . Évalué à 3.

        Je pense qu'il veut dire que bien que ça existe il n'y a pas vraiment de doc ni de retours d'utilisation.
        On peut pas encore remplacer luks proprement.

      • [^] # Re: Chiffrement dans Ext4

        Posté par  (site web personnel) . Évalué à 3.

        Je n'avais pas fait attention. Je dois dire que c'est passé carrément inaperçu, mais si ce n'est pas encore documenté, ce n'est pas étonnant.

        • [^] # Re: Chiffrement dans Ext4

          Posté par  . Évalué à 1.

          Il y a une documentation sur la doc d'ArchLinux, mais vu la tronche des manipulations à faire, c'est pas encore très rassurant (même si au final ça marche sans doute très bien).
          Je n'ai pas non plus vu d'intégration dans les dernière versions de Gnome, je suis peut être passé à coté :/

    • [^] # Re: Chiffrement dans Ext4

      Posté par  (site web personnel) . Évalué à 7.

      Bha oui !
      Sur mon disque en ext4 j'ai un fichier dans lequel on peut lire 42 => False.
      C'est un chiffre et il ment car 42 => True. :-D

      kentoc'h mervel eget bezan saotred

      • [^] # Re: Chiffrement dans Ext4

        Posté par  . Évalué à 5.

        42 est un nombre, pas un chiffre.

        • [^] # Re: Chiffrement dans Ext4

          Posté par  . Évalué à 0.

          On peut aussi dire chiffre : https://fr.wikipedia.org/wiki/Chiffre

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: Chiffrement dans Ext4

            Posté par  (site web personnel) . Évalué à 4.

            Vu le sujet, ça pourrait aussi être un chiffre

            Mais va savoir…

            Proverbe Alien : Sauvez la terre ? Mangez des humains !

          • [^] # Re: Chiffrement dans Ext4

            Posté par  . Évalué à 10.

            Certes, on peut abusivement dire « chiffre » pour « nombre  » mais j'y vois deux inconvénients :

            • on passe pour un plouc incapable de différencier nombre et chiffre, goudron et route, ordinateur et Windows, web et internet ;
            • on profane le repos éternel d'Émile Littré.

            Après on ne s'étonne que les jeunes ne sachent plus lire les classiques ! Par exemple :
            Aussi bien n'y suis fors que une ciffre donnant umbre et encombre, [Chastelain, Chron. des ducs de Bourg. II, 26]

            ;-)

        • [^] # Re: Chiffrement dans Ext4

          Posté par  . Évalué à 10.

          En base 43 ou plus, 42 est un chiffre si on reprente les chiffres de cette base avec les nombres en base 10.

  • # merci

    Posté par  . Évalué à 2.

    Merci, j'attendais avec impatience cette dépêche.

  • # Correction

    Posté par  . Évalué à 3.

    Amélioration de la stabilité de BCache pour former un sorte de disque hybride à partir d'un SSD et d'un disque rotatif.
    Amélioration de la stabilité de BCache pour former un*e* sorte de disque hybride à partir d'un SSD et d'un disque rotatif.

    Rien de bien mAIChant…

    Merci pour cet article.

  • # La toute première fois

    Posté par  . Évalué à 7.

    Merci beaucoup pour cette dépêche, comme d'habitude très attendue.

    Fait amusant, c'est la première fois qu'une dépêche sur le noyau sort après l'apparition du-dit noyau dans les dépôts stables (ArchLinux), et je la lis en étant déjà sur ce noyau.

    • [^] # Re: La toute première fois

      Posté par  (site web personnel) . Évalué à -7.

      C'est en effet amusant :
      J'ai compilé le kernel 4.5 le 13 mars au soir et je l'utilise depuis ce jour-là, donc ArchLinux a vraiment beaucoup de retard.
      Je ne comprends pas l'intérêt d'utiliser une telle distribution si peu a jour (enfin à part pour les gens qui n'ont pas de compétences en informatique et sont incapables de compiler des kernelles).

      • [^] # Re: La toute première fois

        Posté par  . Évalué à 3. Dernière modification le 20 avril 2016 à 18:59.

        Je me suis également posé la même question.

        Ca a peut être un rapport l'ISO qui sort en début de chaque mois.
        Peut être qu'ils ne veulent pas prendre le risque de mettre à jour ce composant critique et d'avoir des problèmes.

        Et sans même parler de l'ISO, peut être qu'ils font une exception sur ce composant.
        Mais à ce moment là, ils devraient étendre ce principe à la libc, etc…

        Je ne trouve rien sur internet qui confirme/infirme mon propos. Ce sont juste des suppositions.

        • [^] # Re: La toute première fois

          Posté par  . Évalué à 10. Dernière modification le 20 avril 2016 à 21:16.

          Juste à titre informatif—et sans nourrir le troll ;-) :

          Historiquement, les devs d'ArchLinux attendent la première rustine de correction d'un kernel avant de l'intégrer dans base (par exemple le 4.5 .1 dans ce cas-ci). Le délai entre la sortie d'un noyau et son .1 étant semble-t-il de plus en plus long, les devs semblent avoir décidé de faire parfois des exceptions à ce principe (ce qui est soit dit en passant arrivé pour le 4.5, même si au final le 4.5.1 est rentré seulement quelques jours plus tard).

          • [^] # Re: La toute première fois

            Posté par  . Évalué à 10.

            Pour préciser : pour la première fois depuis extrêmement longtemps, le 4.3.1 est sorti plus d’un mois après le 4.3. Pendant ce temps, le 4.2 était arrivé à 4.2.8, mais sous Arch on en restait à 4.2.5 puisque le 4.3 était dans le dépôt testing.

            Ça a entraîné une discussion pour savoir comment gérer ce genre de chose, surtout qu’à l’époque le fait d’avoir attendu le 4.3.1 s’est avéré être une très bonne idée (https://bugs.archlinux.org/task/46968). Et l’écart entre le 4.4.1 et le 4.4 a également été plus long que d’ordinaire, pareil pour le 4.5.1 qui se faisait attendre : apparemment, en l’absence de problème majeur répertorié, les mainteneurs du paquet linux sous Arch ont décidé, pour la première fois depuis que je suis sous Arch, de pousser le .0 dans les dépôts stables.

            Car sinon en effet, la politique c’était d’attendre le .1 histoire que les gros bugs n’arrivent pas dans les dépôts stable. Quand un noyau passe du stade de -rc à release, le nombre d’utilisateurs augmente considérablement, donc les bugs apparaissent plus facilement. En gros, Arch attend que les utilisateurs de Gentoo essuient les plâtres. ;)

          • [^] # Re: La toute première fois

            Posté par  . Évalué à 3.

            Merci pour cette précision, je n'étais pas au courant de tout ça, ça explique donc tout !

            De ce fait, ArchLinux pourra peut être rattraper son retard sur les mises à jours pour réussir enfin à avoir une bibliothèque logicielle à peu près à jour ;)

            • [^] # Re: La toute première fois

              Posté par  (site web personnel) . Évalué à -2.

              Le seul logiciel qui m'ennuie pour sa vieille version (et qui m'oblige à utiliser un paquet git via AUR), c'est quodlibet.

              Sinon, voici le uname de mon archlinux testing :

              [fred@fredo-arch ~]$ uname -a
              Linux fredo-arch 4.5.1-1-ARCH #1 SMP PREEMPT Thu Apr 14 19:19:32 CEST 2016 x86_64 GNU/Linux
              Très vieux en effet :)

              Un libriste qui en a sa claque des puristes.

            • [^] # Re: La toute première fois

              Posté par  . Évalué à 2.

              pour réussir enfin à avoir une bibliothèque logicielle à peu près à jour ;)

              Je ne connais pas forcément bien ArchLinx, mais je pensais que c'était une rolling release et que les mises à jours des logiciels arrivaient très vite sur Arch. C'était de l'ironie ton message, ou je me trompe sur ArchLinux ?

              • [^] # Re: La toute première fois

                Posté par  . Évalué à 9.

                Le « point-virgule/parenthèse fermante » était là pour montrer l'ironie, AMHA.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: La toute première fois

        Posté par  (site web personnel) . Évalué à 3.

        Si tu veux le dernier noyau sur ArchLinux, quand il est rendu disponible et modulo le temps que les paquets tiers (du type extension pour VirtualBox) soient compilés, il y a l'option d'activer les dépôts testing et community-testing.

        Ensuite, comme précisé par ailleurs, c'est un choix des mainteneurs de poster sur les dépots stables la version .1 du noyau, histoire que les platres soient secs.

        Quant à compiler mon noyau, je ne l'ai plus fait depuis… 2004 environ. Cela fait-il de moi un incompétent en informatique ?

        Un libriste qui en a sa claque des puristes.

      • [^] # Re: La toute première fois

        Posté par  . Évalué à 10. Dernière modification le 21 avril 2016 à 10:19.

        Je ne comprends pas l'intérêt d'utiliser une telle distribution si peu a jour (enfin à part pour les gens qui n'ont pas de compétences en informatique et sont incapables de compiler des kernelles).

        C'est bien sûr un troll, mais pour le rappel. Arch a d'autres intérêt que son coté très à jour :

        • un système de paquet simple : les choses les plus sophistiquées sont à gérer par l'administrateur
        • des paquets aussi peu re-touché que possible par rapport à l'upstream
        • une administration « à l'ancienne » :)
        • une documentation assez fournie et propre : très technique par rapport à celle d'ubuntu-fr par exemple qui se rapproche plus d'une suite de howto

        Ma liste n'a pas vocation à être exhaustive :)

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # En bref

    Posté par  (site web personnel) . Évalué à 6. Dernière modification le 21 avril 2016 à 00:47.

    La mise en commun des architectures ARMv6 et v7, l'ajout au pilote amdgpu de la fonction PowerPlay pour certains processeurs graphiques AMD (certes désactivée par défaut) et l'intégration du pilote etnaviv pour les processeurs graphiques Vivante font partie des nouveautés notables selon moi à la lecture de cette dépêche.

    Par contre ce n'est pas clair pour moi si les améliorations dans la gestion d'énergie ne concernent que les processeurs Intel les plus récents ou si elles sont génériques ?
    Réponse à moi-même : a priori c'est pour les CPU Intel les plus récents https://www.phoronix.com/scan.php?page=news_item&px=Intel-DRM-Next-PSR-FBC

  • # Ext4 project quota

    Posté par  . Évalué à 10.

    Ext4 ne reçoit pas un "projet de quota" mais une fonctionnalité de quota par projet. Actuellement, ext4 gère des quotas par utilisateur ou par groupe. Le quota par projet consiste en la possibilité d'ajouter des identifiants de projet (labels) à des répertoires dont les sous-objets hériteront, pour ensuite gérer des quotas en volume ou en inode par label.

    cf: https://lwn.net/Articles/623835/

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.