Sortie du noyau Linux 4.10

78
30
avr.
2017
Linux

La sortie de la version stable 4.10 du noyau Linux a été annoncée le 19 février 2017 par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site kernel.org.

Sommaire

Annonces des versions candidates par Linus Torvalds

RC-1

La version RC1 est sortie le samedi 25 décembre 2016 :

C’est Noël et deux semaines se sont écoulées depuis l’ouverture de la fenêtre de fusion. Celle‐ci est donc maintenant fermée.

J’ai accepté quelques demandes d’intégration aujourd’hui, mais j’en ai également rejeté quelques‐unes qui sont arrivées en retard et qui paraissaient douteuses. L’auteur se reconnaîtra.

Dans l’ensemble, ce n’était pas du tout une grosse évolution — rien à voir avec la 4.9. Cependant, elle n’était pas négligeable non plus. Je pense que la 4.7 était plus petite. La 4.8 aurait pu l’être aussi. C’est le jour de Noël et en ce moment, j’ai la flemme de calculer les statistiques comme je le fais habituellement.

Tout semble assez normal, même si nous avons eu une quantité inhabituelle de nettoyages ultimes dans toute l’arborescence sur les derniers jours de la fenêtre de fusion. Mais les statistiques générales semblent assez habituelles : un peu plus de la moitié concerne des pilotes. Il y a peut‐être un peu moins de mises à jour d’architecture que d’habitude et un bon nombre de mises à jour de documentation, en raison de la conversion vers sphinx. Et puis, il y a les diverses corrections habituelles un peu partout, bien que les mises à jour des outils de performances se démarquent.

Le journal abrégé est beaucoup trop grand, comme c’est toujours le cas lors de la fenêtre de fusion, donc comme d’habitude dans ces cas‐là, vous aurez juste le journal de fusion.

Linus

RC-2

La version RC-2 est sortie le dimanche 1er janvier 2017 :

Eh, ça a été une semaine vraiment lente entre le jour de Noël et le jour du nouvel an et je ne m’en plains pas du tout.

Cela signifie que la RC-2 est ridiculement et bizarrement petite. J’ai failli décider de la zapper entièrement, mais une petite RC sans importance de temps en temps ne fait de mal à personne. Donc, voilà.

Le seul travail remarquable ici est la correction DAX. Il aurait vraiment dû se trouver dans la fenêtre de fusion, mais dépendait de plusieurs choses dans cette fenêtre de fusion et a été retardé jusqu’à la RC2 pour cette raison. Même ça n’était pas très important et le reste est constitué de petites corrections insignifiantes.

Je m’attends à ce que les choses recommencent la semaine prochaine quand les gens se remettront des vacances.

Linus

RC-3

La version RC-3 est sortie le dimanche 8 janvier 2017 :

Donc, après une très petite RC-2 en raison de la petite pause de Noël, nous semblons être de retour à la normale. Après une période de calme comme ça, j’ai tendance à m’attendre à un gros morceau juste à cause du travail en suspens ; mais je suppose que pendant la courte pause, il y avait vraiment des vacances pour tout le monde, et donc au lieu de cela on observe juste un modèle habituel de RC. Elle est toujours un peu plus petite qu’une RC-3 typique, mais pour la première vraie RC après la fenêtre de fusion (c’est‐à‐dire que je la compare à une RC-2 régulière), c’est assez normal.

Les stats semblent normales pour le noyau : un peu moins de ⅔ de pilotes, avec presque la moitié restante de mises à jour d’architectures, le reste étant « divers » (principalement des systèmes de fichiers et du réseau).

Donc, rien de particulier ne sort du lot. Vous pouvez vous faire une idée des détails grâce au journal abrégé ci‐joint ; mais plus important encore, vous pouvez aller la tester.

Merci,

Linus

RC-4

La version RC-4 est sortie le dimanche 15 janvier 2017 :

Tout semble plutôt normal, et c’est donc une sortie dominicale comme d’habitude. Nous en sommes à la RC-4 et il est clair qu’on a commencé à trouver des régressions. C’est parfait.

C’est un ensemble de corrections légèrement plus hétérogène que la semaine dernière : la plus grande partie concerne les pilotes (pilotes graphiques, réseau, son et USB se démarquent), mais il y a aussi les changements habituels d’architectures (principalement x86 cette fois‐ci) et un nombre important de corrections des systèmes de fichiers (XFS, Btrfs, certains pour le cœur de VFS), les outils (surtout perf), la gestion de la mémoire, le réseau, etc.

C’est le moment où je commence à espérer que la taille des RC va commencer à diminuer. On verra comment la petite taille de la RC-2 va se répercuter sur la suite — techniquement, nous en sommes à la RC-4, mais avec une semaine presque perdue, cela ressemble plutôt à une RC-3. Mais, je croise les doigts pour que nous ayons moins de changements la semaine prochaine.

De toute façon, allez‐y, testez‐la. Ce n’était pas une énorme fenêtre de fusion ; je pense qu’elle est en assez bon état pour qu’on se jette à l’eau.

Linus

RC-5

La version RC-5 est sortie le dimanche 22 janvier 2017 :

Les choses semblent se calmer un peu et tout semble en règle.

Il n’y a eu que 250 modifications (sans compter les fusions) au cours de la dernière semaine et les statistiques concernent moins de 300 fichiers (les pilotes et les mises à jour d’architectures étant en majorité, mais il y a également des mises à jour d’outils, de gestion des réseaux et de systèmes de fichiers).

Donc, continuez à tester et je pense que nous aurons un calendrier de sortie habituel.

Linus

RC-6

La version RC-6 est sortie le dimanche 29 janvier 2017 :

Cette semaine semble avoir été vraiment calme. La RC-6 semblait partie pour être une jolie petite version. Pile comme je le veux.

… puis, vendredi est arrivé et la petite et tranquille release candidate a quelque peu explosé au point de ne pas être si petite après tout.

Tant pis. Ce n’est pas comme si c’était un nouveau procédé — les gens finissent par m’envoyer leur travail de la semaine le vendredi et cela se passe depuis quelques années maintenant, je l’ai déjà signalé. C’était juste encore plus remarquable que d’habitude.

Et ce lot tardif de demandes d’inclusions arrivé vendredi (avec quelques‐unes ce week‐end) a fait de la RC-6 la plus grosse RC de ce cycle de publications jusqu’à présent (c’est évidemment sans compter la RC-1).

Ce n’est cependant pas si gros que ça, puisque la 4.10 a été jusque‐là globalement assez calme, mais c’est un peu pénible. J’espérais passer au calendrier habituel « la RC-7 est la dernière RC » pour une fois (malgré les 4.8 et 4.9 tendant vers une RC-8) et je veux vraiment que les choses se calment pour que cela se produise.

Nous verrons.

Quoi qu’il en soit, il n’y a rien qui m’inquiète particulièrement dans RC-6 en dehors du manque de ralentissement, et que c’est peut‐être juste le timing (c’est‐à‐dire que tout le monde n’envoie pas ses mises à jour à chaque RC, alors parfois ça s’accumule). Donc, je ne renonce pas à rêver que « la RC-7 soit la dernière RC ».

Les changements touchent principalement les pilotes (le processeur graphique et le réseau se démarquent, mais RDMA, média et MD sont assez remarquables également), le reste se composant principalement des mises à jour réseau génériques et XFS, avec le lot habituel de divers correctifs épars.

Allez le tester,

Linus

RC-7

La version RC-7 est sortie le dimanche 5 février 2017 :

Eh, regardez ça — tout a été très calme et à moins qu’un problème n’arrive, nous sommes de retour au calendrier habituel selon lequel c’est la dernière RC.

Bien sûr, en regardant réellement mon calendrier, j’ai remarqué que si ça se déroule comme cela, la prochaine fenêtre de fusion sera gênante pour moi à cause de mon voyage et, donc, il s’avère que je n’aurais pas dû espérer que les choses se calment. Mais, j’ai déjà fait des fenêtres de fusions durant un voyage auparavant, donc cela ne va pas être nécessairement un gros problème.

Et, de toute façon, n’importe quoi peut arriver pendant la semaine prochaine.

Quoi qu’il en soit, la RC-7 est assez petite, la moitié des corrections au niveau des pilotes (réseau, pilotes graphiques et HID comptant pour la majorité), 20 % de mises à jour d’architectures (X86, SPARC, PowerPC, un peu de cryptographie ARM64) et le reste est du « divers » : systèmes de fichiers, réseau général, mémoire virtuelle, script Genksyms, etc.

L’ensemble est relativement petit, et rien de particulier ne sort du lot (à part un rappel supplémentaire de mon aversion pour modversions — nous avons corrigé un autre bogue aléatoire déclenché par un outil spécifique à une architecture en particulier). Le journal de fusion abrégé est en annexe pour les personnes qui veulent une vue d’ensemble du détail des modifications.

Linus

RC-8

La version RC-8 est sortie le dimanche 12 février 2017 :

Eh, c’est une nouvelle semaine et j’aurais pu sortir la version 4.10.

Elle n’a pas été si chargée que ça, bien que nous ayons eu un certain nombre de petites corrections de régressions de dernière minute (certaines ne faisant qu’annuler des choses qui posaient problème et demandaient un peu plus de réflexion, d’autres les corrigeant). Mais rien qui sorte de l’ordinaire et je n’aurais eu aucune gêne à sortir la version finale aujourd’hui.

Mais, j’ai décidé qu’il n’y avait pas non plus d’énormes raisons impérieuses de le faire (autre que de revenir au calendrier habituel « la RC-7 est la dernière RC », ce qui aurait été appréciable) et avec les voyages à venir, j’ai décidé que je ne devais pas forcément ouvrir la fenêtre de fusion. J’ai déjà géré des fenêtres de fusion pendant des voyages, mais je préfère l’éviter. Si nous en étions à la deuxième semaine de la fenêtre de fusion, lorsque la plus grande partie a été fusionnée, ce serait une chose, mais ce n’est pas comme cela que ça se présente.

Évidemment, tous les développeurs qui sont déjà prêts pour la fenêtre de fusion (et oui, vous devriez, n’est‐ce pas ?) et qui savent que tu seras occupé la semaine suivante [N. D. T : oui, la rupture de syntaxe se trouve aussi dans l’original], vous êtes plus que bienvenus pour envoyer vos demandes d’intégration tôt. Je vais les garder dans un coin, rien à craindre.

Et, si ce n’est pas le cas, vous avez maintenant une semaine supplémentaire pour peaufiner votre travail. ;)

Le journal de fusion abrégé est annexé, mais tout semble plutôt normal : pratiquement la moitié du correctif est constitué de pilotes, un tiers du reste étant des mises à jour d’architectures (ARM, PowerPC et x86). Le restant concerne surtout le réseau et quelques mises à jour de systèmes de fichiers, avec un petit nombre d’autres choses (documentation, outil perf, en‐têtes des fichiers et divers). Environ un tiers des commits est marqué comme étant stable.

Linus

Version finale

La version 4.10 finale est sortie le dimanche 19 février 2017 :

La voilà donc, la version 4.10 définitive. C’est assez calme depuis la RC-8, mais nous avons bien fini par corriger plusieurs problèmes mineurs, donc cette semaine supplémentaire a été complètement bénéfique.

Globalement, la 4.10 n’a pas fini aussi petite qu’elle en avait l’air au départ. Après l’immense version qu’a été la 4.9, je m’attendais à ce que les choses soient plutôt calmes, mais cela s’est terminé en une version plutôt dans la moyenne, selon les normes des noyaux modernes. Nous avons donc environ 13 000 commits (sans compter les fusions qui représenteraient un peu plus de 1 200 commits supplémentaires, si on les prenait en compte). Le travail est terminé, évidemment. Le journal abrégé ci‐dessous ne concerne que les changements de la semaine dernière, depuis l RC-8.

Allez‐y, vérifiez que tout va bien. Et je commencerai évidemment à intégrer des soumissions pour la 4.11 dès lundi.

Linus

Améliorations apportées à cette version

AMD Ryzen

L’arrivée de cette nouvelle architecture de processeurs a montré un problème dans l’affectation des fils d’exécution (threads) aux cœurs des processeurs AMD Ryzen. En effet, avant cette version, les fils d’exécution des processeurs Zen disposaient chacun d’un numéro d’identification unique (cpuid_core_id), alors qu’avec la nouvelle topologie de cœur Zen, deux fils d’exécution d’un même cœur doivent avoir le même numéro d’identification.
On peut supposer que cela pouvait nuire aux performances dans certains scénarios, mais rien n’a été précisé à ce sujet dans le commit. À noter que cette correction a été rétro‐portée dans le noyau 4.9.10.

La prise en charge de ces processeurs a également été ajoutée au module de détection d’erreurs mémoire (EDAC). Ceci ne sera utile que sur les machines disposant de mémoire ECC, principalement les serveurs (dont la gamme AMD Ryzen n’est pas encore sur le marché).

Microsoft Surface 3

Amélioration de la prise en charge des boutons de la tablette, ainsi que de la gestion du couvercle (cf. article sur Phoronix).

Architectures

ARM

L’architecture ARM 64 bits (ARM64/AArch64) prend en charge le bus PCI (Peripheral Component Interconnect) avec l’ACPI (Advanced Configuration and Power Interface). Cette norme a pour but de réduire la consommation d’énergie d’un périphérique. Elle est codéveloppée par Hewlett‐Packard, Intel, Microsoft, Phoenix et Toshiba (cf. article sur Phoronix).

X86

L’architecture x86 reçoit de nombreuses corrections de bogues et optimisations : les très anciens processeurs sans identifiant CPUID ne démarraient plus. Il y a aussi des corrections dans la mise à jour des microcodes.

Pilote audio

Une meilleure gestion de l’énergie est proposée par le DAPM.
De nouveaux pilotes pour les puces Cirrus Logic CS42L42, Qualcomm MSM8916-WCD, et Realtek RT5665.
Et aussi des correctifs pour Intel Skylake.

Pilote graphique

Nouveau (carte graphique NVIDIA)

La mise à jour du pilote inclut la gestion du contrôle des DEL du logo NVIDIA illuminé sur le côté de certaines cartes graphiques de la marque, la prise en charge du DisplayPort MST (Multi Stream Transports) qui permet une utilisation de plusieurs écrans via un seul câble DisplayPort à condition que votre moniteur prenne en charge la version 1.2 du DisplayPort.

Très attendue, la prise en charge du changement de la fréquence qui permet enfin de jouer à pleine puissance avec les pilotes libres. En effet, beaucoup de cartes démarrent à basse vitesse, et le pilote propriétaire est chargé de faire varier la fréquence en fonction de la charge demandée, que ce soit pour la 3D ou la décompression vidéo. Ainsi, il était impossible d’utiliser VDPAU pour lire une vidéo en 1080p sur une 9300 M, alors que ça passait en 720p. Cela reste manuel et expérimental, il y a notamment des cas où la fréquence mémoire ne change pas en même temps que le processeur. Il faut écrire le niveau de performance demandé dans /sys/kernel/debug/dri/0/pstate.

Ces grosses modifications devaient au départ arriver dans Linux 4.9, mais ont été reportées pour améliorer le code.

Voir l’article du site Phoronix.

AmdGPU (carte graphique ATI/AMD)

Cette mise à jour introduit la prise en charge des affichages virtuels multiples et la mise à jour de la gestion de l’alimentation des cartes graphiques.
Et aussi l’accélération du processeur graphique pour les générations plus récentes lors de l’utilisation du circuit de décodage vidéo universel UVD.

La prise en charge des processeurs graphiques Radeon RX550 (nom de code Polaris 12) a été ajoutée.

Elle apporte aussi son lot de nettoyage de code et correction de bogues.

Voir l’article du site Phoronix dédié à ce sujet.

Prise en charge des plates‐formes

Amélioration de la prise en charge d’Amlogic S905 et suivants

La gestion des systèmes monopuces ARM 64 bits d’Amlogic fait l’objet d’un gros travail depuis Linux 4.7. Linux 4.10 amène de nombreux changements :

  • prise en charge de l’USB 2 pour la famille GXBB (S905) ;
  • prise en charge de la famille GXL (S905X et S905D), quasi identique au S905 ;
  • prise en charge de la famille GXM (S912), identique à la famille GXL avec 8 cœurs Cortex-A53 ;
  • gestion de l’interface Ethernet interne 100 Mbit/s des familles GXM et GXL ;
  • gestion de la sortie graphique Composite avec un pilote tout neuf DRM/KMS (Direct Rendering Manager / Kernel ModeSetting) qui utilise les derniers composants comme Atomic Modesetting, GEM-CMA, FBDev-CMA ou encore PRIME-CMA, ceci pour les trois familles GXBB, GXL et GXM ;
  • gestion de l’interface SDCard/SDIO/eMMC pour les trois familles GXBB, GXL et GXM ;
  • prise en charge du Wi‐Fi via SDIO pour les trois familles GXBB, GXL et GXM ;
  • prise en charge des cartes Nexbox A1 et A95X.

La prise en charge de l’affichage par HDMI est prévue pour une prochaine version.

Autres

  • prise en charge des cartes Luxul XAP-1510, Luxul XWR-3100, Netgear R8500, TP-LINK Archer C9 V1 et Tenda AC9 basées sur des  systèmes monopuces Broadcom ;
  • prise en charge du système monopuce Modem MDM9615 et la carte Sierra Wireless MangOH Green, le système monopuce MDM9515 est dans le module semi‐génerique WP8548 de Sierra Wireless ;
  • prise en charge des Nexus 5X et Nexus 6P à base de systèmes monopuces Qualcomm msm8992 et msm8994 ;
  • prise en charge initiale du Motorola Droid 4 à base de système monopuce TI OMAP4430 ;
  • prise en charge initiale de AM571x-IDK à base de système monopuce TI AM5718 ;
  • prise en charge de la famille DRA71x de Texas Instruments ;
  • prise en charge du Oxford Semiconductor OX820, successeur du OX810SE, et du NAS Pogoplug V3 ;
  • prise en charge initiale du routeur libre OpenHardware Turris Omnia à base de système monopuce Marvell ;
  • prise en charge des cartes à base d’i.MX6 : Toradex Colibri, Engicam i.CoreM6, UDOO Neo, liteBoard, liteSOM, Boundary Devices Nitrogen6_SOM2 ;
  • prise en charge des  systèmes monopuces r8a7743 et r8a7745 de Renesas et des cartes SK-RZG1E et SK-RZG1M ;
  • prise en charge des cartes MK808, Rockchip PX3 Evaluation, Rockchip RK1108 Evaluation à base de  systèmes monopuces Rockchip RK3066 et RK1108 ;
  • prise en charge de la carte PX5 à base de système monopuce Rockchip rk3188 ;
  • prise en charge de la carte Macnica Sodia à base de système monopuce FPGA ;
  • prise en charge de la carte NanoPi M1 SBC à base de système monopuce AllWinner Sun8i ;
  • prise en charge de la carte Pine64 à base de système monopuce AllWinner A64 ;
  • prise en charge des cartes LS1046A-QDS et LS1046A-RDB à base du système monopuce FreeScale LayerScape LS1046A ;
  • prise en charge des cartes TM2 et TM2E à base de système monopuce Samsung Exynos 5433 ;
  • prise en charge de la carte NVIDIA P2771 à base de système monopuce Tegra de NVIDIA ;
  • prise en charge de la carte MicroZed à base de système monopuce/FPGA Zynq-7000 ;
  • prise en charge du microcontrôleur STM32F746.

Statistiques

En nombre de correctifs soumis par entreprise

Le plus grand nombre de contributions pour cette version 4.10 est d’origine non précisée (Inconnue : 3 103, 23,82 %). Ensuite, on trouve les sociétés Intel avec 1 730 correctifs (13,28 %) et Red Hat, 882 correctifs (6,77 %), suivis par Samsung (3,98 %) et Novell (3,83 %). Les développeurs bénévoles sont en sixième place avec 473 correctifs (3,63 %).

En nombre de correctifs par nation

Trente‐sept pays ont participé par leurs contributions à cette version du noyau. En première place, la Chine avec 1 077 correctifs (8,27 %), puis l’Allemagne avec 1 013 correctifs (7,77 %) et les États‐Unis avec 735 correctifs (5,64 %).

  • # Coquille

    Posté par . Évalué à 4 (+3/-0).

    prise en charge initiale du routeur libre OpenHardware Tussis Omnia à base de système monopuce Marvell ;

    Ne s'agirait-il pas plutôt du routeur Turris Omnia ?

    Sinon, merci à tous les contributeurs pour leur travail !

  • # 4.11

    Posté par (page perso) . Évalué à 6 (+5/-0).

    Le même jour que la news du 4.10 : le 4.11 est officiellement dispo :)

    • [^] # Re: 4.11

      Posté par (page perso) . Évalué à 3 (+7/-6).

      Tant qu'un éditeur se nommera pas et fera pas sortir la dépêche le meme jour que la sortie du kernel qu'il traite, ca partira en cacaouettes… L'approche à la debian de sortir les choses "quand elles sont prêtes" n'a pas vraiment de sens car tout le monde se fou de la version précédente du noyau, le mieux est l'ennemi du bien!

      Merci quand meme aux contributeurs pour votre travail, ca doit pas être facile de se motiver!

      • [^] # Re: 4.11

        Posté par . Évalué à 10 (+19/-1).

        tout le monde se fou de la version précédente du noyau

        Ce n'est pas parce que tu t'en fous que c'est le cas de tout le monde. La plupart des gens utilisent le noyau fourni par leur distribution, et à ma connaissance les dépêches sortent bien avant l'intégration dans les distributions les plus populaires.

        Membre de l'april, et vous ? http://www.april.org/adherer

        • [^] # Re: 4.11

          Posté par (page perso) . Évalué à -10 (+1/-13).

          J'utilise un noyau 4.10 fourni par Fedora (Fedora 25) depuis plusieurs semaines. Merci pour avoir publié la dépêche 4.10 en même temps que la sortie de 4.11, ça m'a bien fait marrer :-D

          • [^] # Re: 4.11

            Posté par . Évalué à 10 (+13/-0).

            Avoir la dernière version d'un noyau c'est une chose. L'exploiter correctement, savoir l'intérêt qu'il y en a, les nouvelles possibilité… c'en est une autre.

            L'intérêt d'une tel dépêche ce n'est pas d'annoncer un nouveau noyau (Il en sort un tous les 15 jours…), mais c'est de savoir l'utilité qu'il peux y avoir a mettre à jour ses distributions Linux. C'est aussi de se tenir a jour des possibilités offertes (Par exemple la fonction statx() dans le 4.11), c'est aussi mieux comprendre le fonctionnement du noyau en donnant des occasion d'en approfondir des aspects.

            Donc en sois avoir la dernière news on s'en fiche, on veux avoir des informations sur les nouveauté… La différence c'est la profondeur de l'article au détriment de sa fraîcheur ou du buzz.

            • [^] # Re: 4.11

              Posté par . Évalué à 7 (+4/-0).

              Il en sort un tous les 15 jours…

              C'est plus proche de tous les 2 mois.

              Donc en sois avoir la dernière news on s'en fiche, on veux avoir des informations sur les nouveauté… La différence c'est la profondeur de l'article au détriment de sa fraîcheur ou du buzz.

              Pour le coup je ne la trouve pas très poussée malheureusement.

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

          • [^] # Re: 4.11

            Posté par (page perso) . Évalué à 10 (+14/-0).

            Moi, ce que je trouve navrant, c'est ce genre de commentaire qui prends les contributeurs de haut.

            Ces personnes ont sacrifié de leur temps libre pour rédiger avec soin cette news très technique sur un sujet relativement complexe.

            Certes, il est dommage que la parution de la news tombe alors qu'une nouvelle version du noyau est déjà publié, mais cela ne retire en rien la qualité du travail fourni.

            D'ailleurs une news pour le noyau 4.11 est encours de rédaction, je suis certains que les rédacteurs de celle-ci seraient très content de toute aide pour la finir avant la publication des sources du prochain noyau!

            http://linuxfr.org/redaction/news/sortie-du-noyau-linux-4-11

        • [^] # Re: 4.11

          Posté par . Évalué à -1 (+5/-2).

          Bête question: c'est normal qu'une Debian up-to-date tourne avec un noyau 3.16 et ubuntu avec un 4.4 là ou raspbian (debian) tourne en 4.9 ?

          Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

          • [^] # Re: 4.11

            Posté par . Évalué à 9 (+7/-0). Dernière modification le 02/05/17 à 22:46.

            Oui c'est normal. Debian ne met pas ses versions à jour au cours d'une version stable mais effectue seulement des correctifs de sécurité. Ubuntu n'est pas basé sur la version stable de Debian. Raspbian recompile et patch les paquets sources Debian et a son propre noyau pour l'adapter aux spécificités du matériel.

            Pour avoir un noyau 4.9 avec Jessie, il faut utiliser les backports.

            Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

            • [^] # Re: 4.11

              Posté par . Évalué à -4 (+2/-2). Dernière modification le 02/05/17 à 23:05.

              On est obligé de passer par le téléchargement sur la page que tu as linké?
              J'ai essayé sur une Debian Jessie en ajoutant "deb http://httpredir.debian.org/debian jessie-backports main contrib non-free" dans /etc/apt/sources.list comme indiqué sur le wiki de debian puis aptitude update puis apt-get dist-upgrade et rien.

              Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

              • [^] # Re: 4.11

                Posté par . Évalué à 5 (+3/-0).

                Oui, il faut bien ajouter le dépôt backports à ton sources.list puis cibler celui-ci lors d'une commande d'installation de paquet :

                apt-get update; apt-get -t jessie-backports install linux-image-amd64
                

                Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

                • [^] # Re: 4.11

                  Posté par . Évalué à -2 (+4/-2).

                  Nice ça fonctionne !
                  Merci @kantien :)

                  4.9.0-0.bpo.2-amd64 #1 SMP Debian 4.9.18-1~bpo8+1 (2017-04-10) x86_64 GNU/Linux
                  

                  Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

                  • [^] # Re: 4.11

                    Posté par . Évalué à 4 (+2/-0).

                    De rien. Vu que tu n'avais jamais utilisé les backports, tu peux lancer un :

                    apt-get -t jessie-backports upgrade
                    

                    pour voir tous les paquets que tu peux mettre à jour dans leur version backportée. Et si tu veux aller plus loin, mais c'est plus risqué et tendu, tu peux jouer avec le apt pinning.

                    Ou en plus secure, mais plus long en temps de calcul (cela lance un solveur SAT pour vérifier si le paquet est installable en gérant les conflits entre paquets) :

                    apt-get install apt-cudf aspcud
                    

                    puis pour installer un paquet :

                    apt-get --solver aspcud install ton-paquet
                    

                    Il y a quelques articles d'exemples sur le blog de Roberto DiCosmo. Cette méthode permet d'installer des paquets que le solveur interne de apt-get aurait refusé pour cause de conflits.

                    Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

        • [^] # Re: 4.11

          Posté par . Évalué à 2 (+2/-1).

          En l'occurrence, je pense qu'au vu du travail que Martin a fait sur bon nombre de dépêches précédentes sur les noyaux linux ainsi que celui qu'il a accompli et qu'il continue d'accomplir sur le noyau linux en lui-même, « Ce n'est pas parce que tu t'en fous que… » est totalement déplacé.

          • [^] # Re: 4.11

            Posté par . Évalué à 3 (+1/-0).

            Euh… c'est lui qui a dit que tout le monde s'en foutait !

            Membre de l'april, et vous ? http://www.april.org/adherer

      • [^] # Re: 4.11

        Posté par (page perso) . Évalué à 10 (+12/-0).

        Tout le monde ne s'en moque pas :) Avoir une dépêche de ce qu'il y a ou aura dans sa distribution est intéressante.
        Voir aussi les évolutions même avec un peu de retard vaut la lecture.

        Merci pour le boulot de suivi et de traduction fait

      • [^] # Re: 4.11

        Posté par . Évalué à 7 (+4/-0).

        L'approche à la debian de sortir les choses "quand elles sont prêtes" n'a pas vraiment de sens car tout le monde se fou de la version précédente du noyau[…]

        Je suis plus mesuré. Le support matériel n'est pas très intéressant en effet. C'est une évolution totalement linéaire et ça peut se résumer dans un tableau. Par contre les évolutions architecturales, l'ajout de nouvelles fonctionnalités (non liées directement au matériel). C'est super intéressant ! Je n'ai pas du tout touché à cette dépêche et les mails (« Dépêche renvoyée en rédaction ») qui passent dans la liste des rédacteurs est trop régulière et trop automatique pour que je me motive à lire et à comprendre ce qu'on attend de moi, mais il ne faut pas hésiter à envoyer un mail pour demander de l'aide, j'aime bien tenter de rédiger un paragraphe (même si mon implication n'est pas énorme).

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

        • [^] # Re: 4.11

          Posté par (page perso) . Évalué à 10 (+12/-0).

          Perso, je me fiche qu'un nouveau noyau soit sorti.

          Par contre, en ce qui concerne, ces dépêches sont une une mine d'or.

          J'arrive ainsi à suivre à peu près les évolutions, logiciels et je découvre du matériel ou même des façons d'appréhender des pbs.

          Donc merci, et quand c'est prêt c'est aussi très bien pour des personnes comme moi 😀

      • [^] # Re: 4.11

        Posté par (page perso) . Évalué à 3 (+3/-1).

        Salut mupuf!

        Se motiver est une chose et tu le sais puisque tu as drivé quelques dépêches noyau.

        Avoir les compétences nécessaires pour comprendre et rendre en français les évolutions du noyau et une autre paire de manches.

        La contre, toutes les bonnes volontés ne peuvent pas grand chose et en conséquence, ça prend du temps.

        Traduire les annonces de sortie pour que personne ensuite n'en fasse grand chose ou faire des corrections pour une dépêche qui risque de ne pas sortir faute de personnes compétentes et intéressées à ce genre de rédactions ne va pas les faire ni sortir à l'heure, ni les étoffer.

        On a tous nos emplois du temps, nos compétences et nos intérêts. Les miracles, ça n'existe pas. Alors ça arrive quand ça arrive, si ça arrive.

        Sed fugit interea, fugit inreparabile tempus, singula dum capti circumvectamur amore

        • [^] # Re: 4.11

          Posté par (page perso) . Évalué à 2 (+0/-0).

          C'est clair qu'il manque un LWN en langue française. Dommage que les éditions Diamond n'ait pas tenté une voie dans cette direction. Cela paru pendant des années les plus à même d'essayer. Mais il y en a peut être d'autres ?

          • [^] # Re: 4.11

            Posté par (page perso) . Évalué à 7 (+5/-0).

            Déjà que LWN.net a du mal à se financer très correctement alors qu'ils publient en langue anglaise, avec un public très international, alors en langue française j'ai des doutes sur la viabilité économique d'un tel sujet.

            D'autant qu'en général, les gens qui lisent et comprennent LWN.net comprennent la langue anglaise, même les francophones.

            • [^] # Re: 4.11

              Posté par (page perso) . Évalué à 4 (+2/-0).

              les gens qui lisent et comprennent LWN.net comprennent la langue anglaise

              C'est une lapalissade ;-)

              Cela dit, je lis personnellement mais ne comprends pas toujours (souvent) LWN…

              • [^] # Re: 4.11

                Posté par (page perso) . Évalué à 5 (+4/-1).

                En fait j'ai mal formulé ma phrase.
                Disons que de manière général le public cible d'une publication type LWN.net (qui est très technique et centré sur le noyau Linux) est un public qui normalement comprend la langue anglaise.

                Un francophone, capable de lire un contenu tel que le LWN.net en terme de niveau mais sans connaissance de l'anglais, ça doit exister, mais pas suffisamment pour permettre l'émergence d'un tel média.

                • [^] # Re: 4.11

                  Posté par (page perso) . Évalué à 3 (+1/-0). Dernière modification le 08/05/17 à 21:56.

                  Je n'ai pas dis qu'il faille faire un clone parfait francophone de LWN ;-) C'est plus l'esprit de LWN auquel je pensais comme libéré TOUS les articles au bout d'une durée limité ET fixe.

  • # Commentaire supprimé

    Posté par . Évalué à -1 (+0/-1). Dernière modification le 08/05/17 à 16:51.

    Ce commentaire a été supprimé par l'équipe de modération.

  • # Merci

    Posté par (page perso) . Évalué à 4 (+3/-0).

    Comme toujours, merci pour la dépêche. Je vois que certains râlent pour le retard, personnellement je trouve que ce n'est pas bien grave, surtout quand on voit la longueur de la dépêche à se taper en terme de rédaction. Pour les pressés, il existe LWN (oui il faut être anglophone). Je préfère attendre la version traduite ici parce qu'il arrive régulièrement que je ne saisisse pas parfaitement les termes techniques en anglais (et je passe complètement à côté de certaines choses) et les rédacteurs font un travail formidable de traduction.

    Le 4.11 n'est même pas encore dans testing sur Arch, y a pas tant de retard que ça !

    La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas sentis la différence.

    • [^] # Re: Merci

      Posté par (page perso) . Évalué à 5 (+4/-0).

      Une question que je me posais, c'est est-ce qu'on ne pourrait pas « économiser » en ne traduisant plus les messages de RC ? C'est environ la moitié de la dépêche, et j'ai l'impression qu'ils n'apportent pas grand-chose comparé au reste.

      Cela dit, peut-être que ça intéresse pas mal d'entre vous et/ou que le travail nécessaire sur cette partie est peu important par rapport au reste.

      La connaissance libre : https://zestedesavoir.com

      • [^] # Re: Merci

        Posté par . Évalué à 5 (+4/-0).

        Le gros avantage des messages de RC c'est qu'ils sont simple à trouver, et simple à traduire. À peu près n'importe qui peux le faire. En revanche tout les articles annexes sont plus dur à trouver, nécessitent plus de connaissance et sont donc plus dur à rédiger. Enlever les messages de RC ne changerai pas grand chose à la parution de ces dépêches.

        bépo powered

Envoyer un commentaire

Suivre le flux des commentaires

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