La sortie de la version stable 4.1 LTS du noyau Linux a été annoncée le 21 juin 2015 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.
Sommaire
- En bref
- Annonces des versions candidates par Linus Torvalds
- Les nouveautés
- Le bilan en chiffres
- Appel à volontaires
En bref
Annonces des versions candidates par Linus Torvalds
RC-1
La version RC-1 est sortie le dimanche 26 avril 2015 :
Cette fenêtre d’intégration a été normale et je publie, conformément au calendrier prévu. Mes quelques jours de voyage n’ont pas interféré, car j’avais toujours accès à Internet.
La fenêtre d’intégration est assez normale aussi, par rapport à ce qui a été fusionné.
En ne regardardant que la taille, on se dit que ça va tout juste rentrer — alors que la 4.0 était un peu plus petite que d’habitude — la 4.1 semble pile dans la fourchette normale des deux dernières années. Et les statistiques des correctifs aussi ont l’air normales : le gros des changements concerne les pilotes (à peine moins de 60 % des correctifs), avec des mises à jour d’architecture autour de 20 % et le reste est disséminé un peu partout.Aucune nouvelle fonctionnalité fracassante ne me vient à l’esprit, même si la prise en charge initiale de l’ACPI pour ARM 64 bits semble amusante. Selon vos intérêts, votre appréciation de « grande nouveauté » peut évidemment différer de la mienne. Il y a beaucoup de travail partout et certains points pourraient bien faire une grande différence selon vos usages.
Donc, allez‐y, testez. Même une RC-1, aussi brute qu’elle puisse parfois être, a tendance à être de bonne qualité. Ce n’est pas si effrayant. Promis.
Linus
RC-2
La version RC-2 est sortie le dimanche 3 mai 2015 :
Ces derniers temps, les RC-2 ont été plutôt petites — ressemblant plus à des RC tardives. Il fut un temps où je ne pouvais même pas poster le journal abrégé, parce qu’il était trop long. Ça n’a pas été le cas pour les quelques dernières versions.
Je pense que les gens ont tendance à prendre un moment de repos après la fenêtre d’intégration, parce que les RC-3 ont tendance à être un peu plus grosses à nouveau. Mais c’est peut‐être aussi parce que je suis devenu meilleur à dire « la fenêtre d’intégration est terminée, je n’accepte pas les traînards » ou que les gens respectent mieux la fenêtre d’intégration. Quelle qu’en soit la raison, le temps des énormes RC-2 semble être heureusement révolu.
Donc, le cycle de développement de 4.1 correspond à ce nouveau modèle. Même si elle n’est pas aussi petite que, disons, la 3.19-rc2 ne l’était (elle était vraiment exceptionnelle), la 4.10-rc2 [sic] est plutôt petite et tout a été assez calme. Le diffstat est plutôt plat et propre, à l’exception notable du nouveau générateur de nombres pseudo‐aléatoires basé sur SHA512 pour s390. Je suppose que j’aurais dû prendre aussi tout ça en main. Mais le reste a vraiment l’air de petits correctifs, pas de gros nouveaux morceaux de code.
Comme d’habitude, c’est un mélange de correctifs de pilotes, de mises à jour d’architectures (avec s390 se démarquant à cause d’un changement sur le générateur de nombres pseudo‐aléatoires) et d’un peu de systèmes de fichiers et de réseau. Le journal abrégé ci‐joint contient les détails, il n’y a rien de particulièrement inquiétant. Jusqu’à présent, la 4.1 a l’air plutôt normale.
Linus
RC-3
La version RC-3 est sortie le dimanche 10 mai 2015 :
Et une version de dimanche de fête des mères pour vous, que vous soyez maman ou non. Car, eh, c’est dimanche après‐midi une fois encore et c’est ainsi ça que sortent mes versions candidates.
Rien de particulièrement effrayant ou inquiétant n’est à signaler, bien qu’il y ait de petites réparations un peu partout. Certaines sont les régressions de cette fenêtre d’intégration et d’autres sont plus vieilles. Et certaines sont si vieilles que j’ai presque pensé que « si c’est cassé depuis 2011 et que tu le remarques seulement maintenant, ça aurait peut‐être pu attendre la prochaine fenêtre d’intégration .» Vous vous reconnaîtrez (et les autres aussi, s’ils lisent les messages de commit — votre honte s’y retrouve).
Le journal abrégé en annexe donne un aperçu honnête et il n’est pas trop gros. Comme vous pouvez le voir, c’est surtout des pilotes, avec une poignée de mises à jour d’architectures (surtout ARM). Et une poignée de trucs divers : outils de performances, documentation, systèmes de fichiers. La mise à jour d’InfiniBand est un part important des pilotes, on a eu des trucs retardés à cause de changements dans la maintenance.
Allez‐y, testez. À la RC3, les choses devraient être plutôt sans danger et ce serait le moment de vérifier que tout fonctionne correctement, si vous n’avez pas déjà testé un des noyaux de développement précédents.
Linus
RC-4
La version RC-4 est sortie le lundi 18 mai 2015 :
Celle‐ci a raté ma publication dominicale habituelle, parce que j’étais sorti presque toute la journée d’hier. De plus, il y avait une régression de la mise en veille qui semblait devoir recevoir un correctif imminent, donc ça ne me dérangeait pas de faire une publication tard dans la soirée, dans l’espoir d’une rustine supplémentaire.
Ça y est, correctifs de dernière minute et tout. Le correctif RC-4 est un peu plus gros que les précédents, mais ça semble dû principalement à des aléas temporels normaux — simplement la fluctuation liée à l'arrivée de l’arborescence des sous‐mainteneurs — et le fait que la RC-4 contienne les correctifs de Greg dans diverses arborescences de pilotes et les correctifs de Davem concernant le réseau, de sorte que la taille légèrement plus importante n’est pas représentative de soudains problèmes.
Bien que les pilotes et le réseau dominent les changements, il y a une poignée de changements épars : mises à jour des systèmes de fichiers (Btrfs et NFS), mises à jour d’architectures (principalement ARM, ARM64 et MIPS) et d’autres changements divers.
Allez‐y, testez et avertissez chacun de la moindre régression trouvée.
Linus
RC-5
La version RC-5 est sortie le dimanche 24 mai 2015 :
Je suis de retour à mon habituel calendrier dominical et la RC-5 est de retour à sa taille habituelle, après une légère augmentation de la RC-4.
Les choses semblent assez normales. Nous avons à peu près deux tiers de mises à jour de pilotes (pilotes graphiques, InfiniBand, audio, réseau, SCSI et température) et quasiment la moitié de ce qui reste est une mise à jour du réseau. Le reste est principalement des mises à jour d’architectures et quelques correctifs des systèmes de fichiers. Mais tout cela est plutôt restreint.
Donc, nous sommes dans les temps pour une 4.1 normale, si ce n’est que le calendrier de la prochaine fenêtre d’intégration semble se télescoper avec nos vacances familiales annuelles. Donc nous allons voir comment ça va marcher. Je pourrais finir par retarder la publication juste pour éviter cela (ou simplement retarder l’ouverture de la fenêtre d’intégration). Je n’ai pas encore décidé.
Mais, s’il vous plaît, continuez à tester.
Linus
RC-6
La version RC-6 est sortie le dimanche 31 mai 2015 :
Ça a été une semaine plutôt normale, bien que je ne puisse pas dire que les versions candidates aient précisément déjà commencé à diminuer. Non, les RC n’ont pas été suffisamment grandes pour commencer un cycle de publication, et les choses ont été plutôt calmes, mais je serais plus heureux si l’on n’avait pas de bruit dans le RAID 5 et la carte des périphériques [device‐mapper] à cette étape.
Cela dit, ce n’est pas comme si la RC-6 était une grosse version candidate, et les choses paraissent normales. Il s’agit pour la moitié environ de pilotes (principalement des cibles SCSI, du réseau et du graphique, plus les modifications du RAID et de la carte des périphériques mentionnées plus haut, avec d’autres corrections diverses).
Le reste est assez également réparti entre les mises à jour d’architectures (Alpha sort du lot), des mises à jour de systèmes de fichiers (XFS, CIFS et OverlayFS) et « divers » (réseau, l’outil de mise à jour de
turbostatet la documentation).La plupart des correctifs sont plutôt petits. Le journal abrégé est joint, il donne une bonne idée des choses que nous avons ici.
Linus
RC-7
La version RC-7 est sortie le dimanche 7 juin 2015 :
Encore un dimanche, encore une RC.
Normalement, la RC-7 tend à être la dernière version candidate, et il n’y a pas grand‐chose qui mérite notre attention ce coup‐ci. Cependant, nous avons encore quelques régressions et, comme je l’ai mentionné la semaine dernière, mes vacances familiales annuelles arrivent. Nous aurons donc une RC-8 et une semaine supplémentaire avant que la RC-8 ne soit réellement publiée.
Ça s’est agréablement calmé cependant et la RC-7 vaut certainement la peine d’être testée pour vérifier que tout fonctionne pour vous. Parce qu’on est sacrément proche de la version finale et qu’elle devrait être assez sûre à tester. Les changements apparus la semaine dernière sont plutôt restreints. Le journal abrégé en annexe devrait vous donner un aperçu de ce qui se passe. Beaucoup d’entre eux sont des correctifs d’une ligne, avec quelques correctifs légèrement plus gros sur certaines architectures (des contraintes de performance sur x86, quelques mises à jour sur SPARC), ainsi que des pilotes en attente d’intégration [branche staging].
Linus
RC-8
La version RC-8 est sortie le dimanche 14 juin 2015 :
Je suis en vacances, mais le temps ne s’arrête pas pour autant et c’est dimanche, donc le moment de sortir une RC que j’espère finale.
Il se trouve que je voulais faire traîner la publication d’une semaine, de sorte à ne pas avoir la fenêtre d’intégration pendant mes vacances — nous avons encore quelques correctifs dans md. Comme Neil Brown l’a dit : « ça n’a pas été un bon cycle pour md :-( ».
Les correctifs sont assez petits et j’espère que tout va bien maintenant. Mais une semaine supplémentaire pour tester ne va certainement pas faire de mal, donc une RC-8 est tout à fait appropriée.
Il y a aussi diverses choses qui avancent, dont les correctifs MIPS, ainsi que de petites mises à jour pour ARM, s390 et x86.
Mais le gros est — comme d’habitude — les pilotes et, non, ça ne vient pas du camp md — ces correctifs sont très petits. Il s’agit principalement d’Ethernet, du DMA esclave [slave DMA] et de spund, ainsi que des correctifs DRM et d’autres choses.
Il y a aussi quelques correctifs de réseau et diverses petites choses. Le journal abrégé est joint comme d’habitude, pour les personnes qui veulent un aperçu des détails.
Quoi qu’il en soit, c’est pas comme s’il y avait une tonne de correctifs. La plupart d’entre eux sont de petits correctifs, donc je ne pense pas que ce soit particulièrement inquiétant. C’est simplement que la RC-8 sort non seulement à cause de mon agenda, mais aussi à cause de petits détails qui surgissent sans cesse.
Faisons en sorte que la semaine prochaine soit vraiment calme. Le pouvons‐nous ? Parce que je vais très activement éviter de lire mes courriels.
Linus
Version finale
La version finale est sortie le dimanche 21 juin 2015 :
Bon, après une semaine très tranquille passée la publication de la RC-8, la version 4.1 finale est maintenant publiée.
Je ne suis pas sûr que ce fût calme parce qu’il n’y avait aucun problème — touchons du bois — ou parce que les gens ont décidé d’épargner mes vacances, mais, quelle qu’en soit la raison, j’apprécie. Ça n’est pas comme si le cycle de sortie de la 4.1 avait été particulièrement pénible, espérons que la semaine supplémentaire de décantation ait permis d’en faire une meilleure version. Ça n’est pas une mauvaise chose, puisque la 4.1 est une version à support à long terme [LTS].
Quoi qu’il en soit, depuis la RC-8, nous avons eu des changements vraiment petits, principalement quelques corrections finales de pilotes (le son HDA, le DRM, les périphériques de stockage SCSI et la cryptographie) et quelques petits correctifs divers. Le journal abrégé ci‐joint est probablement le plus petit jamais écrit. Je ne m’en plains pas.
Et cela signifie évidemment que la fenêtre de fusion de la 4.2 est maintenant ouverte.
Linus
Les nouveautés
Architecture
Gestion du matériel
Qualcomm MSM8916
Le Snapdragon 410 est la nouvelle famille de systèmes monopuce ARM 64 bits (ARM v8) de chez Qualcomm. Le MSM8916 intègre quatre cœurs ARM Cortex A53, gravés en 28 nm et cadencés à une fréquence de 1,4 GHz. Il adopte une architecture de type Harvard, en séparant les données et les instructions du cache de niveau 1. Il incorpore un processeur graphique Adreno 306 et un processeur de signal Hexagon QDSP6.
Il fait partie des nouveaux systèmes monopuces ARM64 à faire leur apparition dans Linux 4.1.
Xilinx ZynqMP
Xilinx est un constructeur américain principalement connu pour ses périphériques et puces à logique programmable. Également connu comme étant l’inventeur du FPGA, il se focalise aujourd’hui sur la conception de systèmes monopuces programmables, combinant des cœurs ARM à des FPGA. Cela vous donne la possibilité de rerouter électriquement l’intégralité d’une carte de développement ou de développer n’importe quel périphérique à l’intérieur du FPGA intégré à la puce (un périphérique Ethernet PHY qui gère du PTP, par exemple).
Parmi les deux puces les plus connues, nous pouvons citer le Zynq-7000 et le Zynq UltraScale MPSoC, aussi appelé ZynqMP. C’est à ce dernier que nous nous intéresserons.
Le ZynqMP est le premier système monopuce programmable 64 bits de chez Xilinx, il s’agit de la gamme de puces haute performance qui dispose d’un processeur à quatre cœurs ARM Cortex A53, des coprocesseurs Cortex-R5 dits temps réels, un processeur graphique ARM Mali 400MP, la gestion de la mémoire DDR4. Bref, vous l’aurez compris, c’est une véritable machine de guerre qui fait tout, sauf repasser votre linge. :/
Linux 4.1 intègre la gestion de ce nouveau système monopuce. Restent maintenant à venir les cartes de développement et les kits d’évaluation.
L’ajout de la prise en charge de l’Intel Skylake continue
L’outil Turbostat est fourni avec le noyau Linux pour analyser statistiquement les performances des processeurs Intel récents. Il a été amélioré pour les spécificités des processeurs Skylake.
Intel Bay Trail & Cherry Trail
Ces processeurs obtiennent un changement de réglage par défaut, qui donnera de meilleures performances quand il faut de la puissance de calcul, tout en limitant la consommation supplémentaire. Celle‐ci peut toujours être maîtrisée avec le profil « powersave ». Concrètement, le « setpoint » par défaut est passé de 97 à 60.
Meilleure gestion de l’énergie
Ce noyau gère mieux l’énergie pour les x86 et les ARM, avec une meilleure prise en compte de l’ACPI (ARM 64 bits inclus), une gestion du futur matériel Intel, la gestion des mises à jour pour les domaines de puissance : le noyau peut maintenant gérer plus finement les économies d’énergie, car il connaît la topologie de la dissipation de la puissance. Par exemple, si le processeur et le processeur graphique sont sur la même puce (die), il s’agit du même domaine de puissance.
L’architecture ARM64 prend désormais en charge l’Advanced Configuration and Power Interface, aussi appelée ACPI. La prise en charge de l’ACPI pour l’ARM a été controversée par le passé : de nombreux développeurs préféreraient utiliser de façon universelle le mécanisme d’arborescence de périphériques pour la détection des périphériques sur cette architecture. L’ajout de l’APCI s’est fait tranquillement cependant, et il semble très vraisemblable qu’il y ait des serveurs utilisant l’ACPI en vente dans un futur proche. Cela dit, il reste du travail : le commit de fusion précise que « nous n’allons prendre en charge aucun périphérique pour le moment, donc son champ d’application est assez limité ». Voir Documentation/arm64/arm-acpi.txt pour de plus amples informations à propos de l’ACPI sur ARM.
Voir l’article de LWN.net : ACPI for ARM?, [correctif de la demande d’inclusion], Documentation/arm64/arm-acpi.txt.
La prise en charge de Full DynTicks pour les invités KVM permet de ne plus réveiller le processeur à intervalles réguliers, et donc permet une meilleure économie d’énergie quand on a des machines virtuelles en fonctionnement.
AMD Bulldozer
Amélioration de l’entropie pour AMD Bulldozer, ce qui permettra d’avoir des nombres aléatoires de meilleure qualité pour les opérations de chiffrement.
Changement risqué pour x86
Beaucoup de changements ont été apportés aux appels système, interruptions, etc. pour x86. Un gros effort a été mené pour clarifier et remplacer du code spaghetti en assembleur, vieux d’une décennie, par du C, ainsi que ses dépendances en C. Le code est maintenant plus simple, plus clair, plus compact et donc maintenable.
En raison de la nature des changements sur ces parties critiques, des risques de problèmes peuvent apparaître.
Correction à chaud sur architecture S/390
Gestion préliminaire pour l’utilisation de correctifs à chaud du noyau pour l’architecture S/390. Suppression de la prise en charge du mode 31 bits autrefois nécessaire pour dépasser l’agaçante limite mémoire des 16 Mio.
Équilibrage de charge
La surveillance de la charge par l’ordonnanceur a été retravaillée pour que la charge par processus soit indépendante de la vitesse du processeur. Cela devrait permettre de meilleures décisions pour l’équilibrage de charge selon les changements de fréquence, et améliorer la prise en charge des systèmes à processeurs asymétriques comme le récent big.LITTLE où plusieurs types de cœurs se retrouvent dans le même processeur. La technologie big.LITTLE permet de mixer des cœurs à très faible consommation avec des cœurs puissants s’activant à la demande en cas de forte sollicitation. Cela permet d’économiser de l’énergie.
MIPS
L’architecture MIPS prend dorénavant en charge l’adressage XPA. Cela permet aux systèmes 32 bits d’accéder à toutes les adresses de la mémoire physique (40 bits).
Développeurs
Utilisation de GCC 6
Le noyau Linux utilise actuellement un fichier d’entête compiler-gccX.h pour gérer efficacement les spécificités propres à chaque version majeure de GCC.
La possibilité de tout fusionner dans un seul compiler-gcc.h est discutée, pour ne pas créer un fichier par version de GCC dû au changement dans la politique de publication de GCC (une version par an). En effet, précédemment, chaque version majeure était due à une évolution marquante, et pouvait fortement affecter le noyau.
La nouvelle politique pour GCC est plus pragmatique, avec des versions plus incrémentales et régulières, permettant de profiter des avancées du projet, sans forcément remettre en question de manière profonde le logiciel et la manière de l’utiliser (raison première d’un fichier par version).
Il reste encore des changements à faire pour rendre le code compatible avec le compilateur LLVM/Clang et la norme C11.
AIO
Les méthodes aio_read() et aio_write() ont été supprimées de la structure file_operations. Les (relativement) nouvelles méthodes read_iter() et write_iter() devraient être utilisées à la place.
Débogage des systèmes de fichiers
Il y a une nouvelle cible « log writes » pour la carte des périphériques (device mapper) qui enregistre toutes les opérations d’écriture sur un périphérique bloc. Il est destiné au débogage des systèmes de fichiers. Voir Documentation/device-mapper/log-writes.txt pour les détails.
User mode Linux
Linux en mode utilisateur — User mode Linux — a vu la prise en compte du multitâche et de la gestion mémoire highmem supprimés. Aucune de ces fonctionnalités ne marchait correctement — voire ne fonctionnait tout court — et les deux étaient des fardeaux à maintenir.
GPIO
Le nouveau système d’« accaparement » du système d’entrées‐sorties à usage général GPIO peut être utilisé pour câbler facilement — et de façon permanente — l’état d’une ligne GPIO spécifique sans nécessiter de pilote. Voir la documentation du correctif pour les détails.
Outil perf
Comme d’habitude, l’outil de mesure de performance a vu une longue liste d’ajouts et d’améliorations ; voir le correctif de la demande d’inclusion pour les détails. Certaines des caractéristiques les plus importantes incluent la possibilité d’attacher des programmes BPF aux sondes noyau, la prise en compte de la fonctionnalité trace des processeurs Intel à venir (« un traceur matériel sous stéroïdes »), la prise en compte de la fonction à venir de surveillance de la qualité de service du cache d’Intel, etc. (Documentation Intel : Processor Tracing).
Suppression du « domaine d’exécution » noyau
Le « domaine d’exécution » a été retiré du noyau. L’idée qui sous‐tendait cette fonctionnalité était de permettre l’importation de caractéristiques étrangères à Linux — des interfaces logicielles de noyaux d’autres systèmes UNIX —, mais elle n’a jamais été très utilisée, et n’a même jamais très bien fonctionné.
Voir l’article de LWN.net : Remove execution domain support.
Minimisation de la taille du noyau
L’utilisation d’utilisateurs, de groupes et de « capacités » (capabilities) est optionnel. Cette option de configuration à la compilation est destinée aux tout petits systèmes embarqués qui n’en faisaient déjà pas usage, et qui peuvent donc être allégés de 25 Kio environ.
Voir l’article de LWN.net :Linux as a single-user system, [correctif].
Pilotes graphiques libres
Direct Rendering Manager
La nouveauté principale pour la partie commune de tous les pilotes graphiques libres est l’ajout d’un allocateur de mémoire graphique « virtuelle » (c’est‐à‐dire, utilisant la mémoire centrale de l’ordinateur au lieu d’utiliser de la mémoire graphique dédiée). Cet allocateur réutilise l’interface GEM qui est l’interface d’allocation utilisée par presque tous les pilotes graphiques libres. Cette approche a pour unique intérêt d’aider les pilotes de rendu (rasterisation) logicielle tels que le pilote Mesa/Gallium LLVMpipe.
Grâce à la couche Virtual GEM, il devient possible à LLVMpipe de transférer avec DRI2 le résultat du rendu au serveur graphique X sans effectuer de copies. Cette couche devrait cependant être inutile dans le cas de Wayland et DRI3 qui préfèrent utiliser DMA-buf pour des raisons de sécurité et de simplicité. DMA-buf étant plus générique que GEM, il a toujours été possible de partager de la mémoire centrale avec plusieurs pilotes. Cependant, DRI3 n’est pas encore considéré comme stable actuellement, ce qui est probablement la raison pour laquelle Zach Reizner a décidé de ressusciter le projet d’Adam Jackson, empaqueteur de la pile graphique pour Red Hat, datant de 2012.
Le correctif original permettait également de gérer le partage de tampons graphiques via PRIME (DMA-buf), cependant, plusieurs ingénieurs ont trouvé que Google avait décidé de se servir de cette interface d’une autre façon qui n’est pas sûre vis‐à‐vis de la cohérence des caches, surtout sur les processeurs ARM. Le résultat de la discussion est que VGEM doit respecter son objectif initial, qui est celui proposé par Adam en 2012, LLVMpipe sur DRI2. La gestion de PRIME a donc été supprimée.
Pour que cette fonctionnalité devienne utile, il reste cependant encore à modifier le pilote LLVMpipe pour enfin éviter les copies inutiles des images produites par LLVMpipe à destination du serveur graphique X, qui sont particulièrement lourdes avec les résolutions actuelles de nos moniteurs.
Le reste des modifications de la partie commune des pilotes graphiques libres n’est pas aussi intéressant. Pour plus d’informations, vous pouvez consulter les demandes d’intégration DMA-buf, panels et DRM.
AMD/ATI
Pilote de rendu (pilote radeon)
Dans cette nouvelle version, le pilote radeon ajoute une gestion expérimentale du transport multiflux (MST) sur DisplayPort 1.2. Cela permet de faire transiter des flux (images, son et données) pour différents écrans via une seule sortie (et un seul câble) DisplayPort. Cette gestion a été ajoutée par Dave Airlie (Red Hat) pour les processeurs Cayman et (en théorie) les processeurs plus récents. Pour activer cette gestion, vous devrez utiliser l’option noyau radeon.radeon_mst=1.
Une autre fonctionnalité intéressante a été ajoutée pour ceux d’entre nous qui connectent leur carte AMD à une télévision. Les télévisions sont en effet différentes des moniteurs pour ordinateurs, car elles ne reçoivent en théorie que des couleurs RVB dans la plage 16-235 au lieu de 0-255. Cela veut dire que les couleurs 0-16 seront toutes considérées comme absence d’une couleur et 235-255 seront considérées comme sa présence complète. Cette gestion a été demandée durant l’été 2014 par plusieurs utilisateurs. Si vous voulez essayer, il vous faudra invoquer xrandr de cette façon xrandr --output <sortie> --set output_csc tvrgb.
Le pilote radeon exporte désormais beaucoup plus d’informations concernant l’état du processeur graphique. Ces informations sont destinées à être exposées par l’afficheur tête haute de Gallium ou les extensions OpenGL permettant d’exposer les compteurs de performance. Ces informations supplémentaires concernent les horloges mémoire et processeur graphique, ainsi que l’état des différents moteurs d’exécution du processeur graphique (2D, 3D, décodage vidéo et DMA).
Pour plus d’informations sur les nouveautés du pilote radeon, vous pouvez consulter la demande d’intégration radeon.
Pilote HSA (pilote amdkfd)
Le pilote amdkfd, qui permet de faire communiquer plus rapidement le processeur graphique et le processeur, permet désormais de gérer plusieurs pilotes graphiques en même temps. C’est nécessaire afin de gérer le futur pilote graphique qui sera prochainement intégré au noyau et qui sera l’unique pilote Linux capable de gérer les nouveaux APU d’AMD (Carrizo).
Pour plus d’informations sur les nouveautés du pilote amdkfd, vous pouvez consulter la demande d’intégration amdkfd.
Intel (pilote i915)
Peu de nouveautés visibles pour les utilisateurs du pilote i915. Les nouveautés principales concernent l’affichage. La première est la gestion dynamique de la fréquence de rafraîchissement (DRRS) pour les plates‐formes qui le prennent en charge. La seconde est la gestion matérielle de la lecture des tampons graphiques utilisant le Y-tiling, avec une rotation de 90° et 270°, en plus des 0° et 180° déjà disponibles sur les plates‐formes avant le Skylake.
Beaucoup de travail de réagencement du code est également en cours. Le travail principal continue sur la gestion atomique du mode graphique avec l’ajout de l’infrastructure qui va faciliter la migration de la gestion actuelle à la gestion atomique.
Du côté de PPGTT (mémoire virtuelle allouée par client graphique), beaucoup d’efforts sont faits afin de gérer des espaces d’adressage supérieurs à 32 bits (4 Gio). En effet, activer un espace d’adressage de 48 bits utiliserait beaucoup de mémoire rien que pour allouer la table de pagination. Du coup, Ben Widawsky travaille à faire l’allocation de cette table de façon dynamique. Espérons que Linux 4.2 apportera la gestion des grands espaces d’adressage qui permettront au processeur graphique d’accéder à toute la mémoire d’un processus 64 bits sans avoir à copier inutilement des zones mémoire ou faire des opérations de réagencement des MMU). Si vous êtes intéressés par PPGTT, vous pouvez consulter les articles de Ben Widawsky sur le sujet, qui expliquent en détail l’objectif derrière PPGTT (1, 2, 3 et 4).
Pour finir, les développeurs i915 essayent de fournir l’accélération graphique aux machines virtuelles Xen sans avoir à passer par une virtualisation complète. Les machines virtuelles auront un pilote (appelé XenGT) qui communiquera avec un autre pilote sur l’hôte via des hypercalls, afin de transmettre les différentes commandes. Le résultat devrait être très performant et proche de ce qu’essaye de faire Ben Skeggs pour le pilote Nouveau.
Si vous voulez en savoir plus, vous pouvez consulter l’habituel compte‐rendu détaillé des modifications de Daniel Vetter (mainteneur du pilote i915).
NVIDIA (pilote nouveau)
Du côté du pilote libre pour les processeurs graphiques NVIDIA, l’ingénieur Alexandre Courbot de NVIDIA a ajouté la gestion de l’IOMMU pour les processeurs graphiques GK20A, que l’on peut trouver dans les systèmes monopuces Tegra K1.
Ben Skeggs a également écrit les microcodes nécessaires à la gestion matérielle des contextes graphiques pour la première version des processeurs Maxwell, les puces GM107. Ces microcodes sont essentiels afin de prendre en charge l’accélération 2D et 3D et le décodage vidéo. Les puces suivantes ont également reçu des modifications afin de pouvoir charger ces microcodes, mais aucune version libre ne peut être écrite, car ces derniers nécessitent un microcode signé par NVIDIA. Ce dernier devraient redistribuer très prochainement les différents microcodes dans le projet linux-firmware.
Avec un peu de chance, NVIDIA redistribuera également les microcodes nécessaires à l’encodage et au décodage vidéo, ainsi que la documentation des interfaces, ce qui devrait réduire le temps de développement pour ajouter la gestion d’une nouvelle puce ! On se consolera comme on peut pour la perte de liberté, et un travail d’audit du code sera encore nécessaire pour garantir qu’il n’y a pas de portes dérobées.
Pilotes graphiques pour systèmes monopuces
Qualcomm (pilote msm)
Le pilote msm pour les processeurs graphiques Qualcomm gagne la gestion des liens DSI et double DSI, ainsi que la gestion du vol de mémoire, ce qui permet de faire une transition sans à‐coups depuis l’animation de chargement (splash screen). La gestion des nouveaux processeurs graphiques Snapdragon 410 fait également son apparition.
Pour plus d’informations, vous pouvez consulter la demande d’intégration msm.
NVIDIA (pilote tegra)
La nouveauté principale du pilote NVIDIA tegra à destination des systèmes monopuces Tegra (2, 3 et 4) est la possibilité d’utiliser les compteurs matériels de suivi du rafraîchissement vertical grâce aux points de synchronisation proposés par le pilote et le bloc host1x. Cela devra permettre d’implémenter une gestion plus efficace de la commutation de page (page flipping).
Pour plus d’informations, vous pouvez consulter la demande d’intégration tegra.
Renesas (pilote rcar-du)
Le pilote Renesas a reçu beaucoup de modifications de la part de Laurent Pinchart, afin de gérer la gestion atomique du mode graphique !
Pour plus d’informations, vous pouvez consulter les demandes d’intégration rcar-du.
Autres
Les pilotes Samsung (exynos) et Texas Instruments (omap) ont tous les deux profité d’une révision de l’architecture du code et de corrections des bogues en vue de gérer la gestion atomique du mode graphique, mais le code n’est pas encore prêt.
Pour plus d’informations, vous pouvez consulter les demandes d’integration exynos et omap.
Sécurité
Lorsque le noyau essaie d’accéder à des adresses qui ne sont pas directement accessibles, la l’unité de gestion de la mémoire (MMU) génère une erreur de pagination — page fault exception — et exécute le gestionnaire d’erreur de pagination. Lors de l’accès à des zones mémoire contrôlées par un processus en espace utilisateur, ce gestionnaire vérifie que le code effectuant cet accès fait bien partie d’un tableau listant les parties dans le noyau qui ont effectivement le droit d’accéder à ce type de zone mémoire. Ce tableau contient donc principalement toutes les invocations des fonctions de type copy_*_user().
Ce mécanisme permet au noyau d’accéder de façon sûre aux données en espace utilisateur à l’aide d’une interface restreinte (les fonctions copy_*_user()), sans avoir à vérifier explicitement l’accès à tous les pointeurs avant de les déréférencer.
Chaque module contient son propre tableau listant ces exceptions. À partir de cette version du noyau, le chargeur de module vérifiera activement que toutes les entrées de ce tableau pointent bien vers du code inclus dans le module. Toute entrée pointant à l’extérieur générera une erreur [correctif], Documentation/x86/exception-tables.txt : Kernel level exception handling in Linux.
Audit
Une situation de compétition potentielle dans le code d’audit pouvait tronquer le rapport d’audit après le champ comm, et donc provoquer la perte d’informations. Pour de plus amples informations, voir le correctif.
SELinux
La table de hachage contenant la politique SELinux dans le noyau a été convertie en « tableau flexible » (flex array). Il utilise un nouvel algorithme de hachage produisant une meilleure répartition. Le nombre d’entrées par défaut a également été augmenté. Ces modifications devraient réduire l’impact de la recherche d’une règle dans la politique SELinux dans le noyau, et donc réduire globalement l’impact de SELinux. Pour de plus amples informations, voir les correctifs 1, 2 et 3.
Certaines commandes netlink n’étaient pas mentionnées dans la table utilisée par SELinux, à cause d’un oubli lors de leur introduction dans le noyau. Ces correctifs corrigent le tir et l’un d’entre eux ajoute une vérification à la compilation pour que la situation ne se reproduise plus. Pour de plus amples informations, voir les correctifs 1, 2, 3, 4, 5, 6, 7, 8 et 9.
SMACK
Les sockets ouverts par des fils d’exécution dans le noyau sont correctement nommés. Pour de plus amples informations, voir le correctif.
L’appel système keyctl avec l’action KEYCTL_GET_SECURITY retourne maintenant le contexte de sécurité [correctif].
Le mainteneur du module de sécurité SMACK a ajouté, à contre cœur, un mode « mise en place » qui peut être utilisé pour déboguer la configuration et la politique SMACK. « C’est finalement disponible, c’est dangereux, mais il semble que beaucoup de développeurs ne sachent pas faire autrement, donc j’ai mis ça en place. J’ai essayé de rendre ce mode aussi sûr que possible, mais c’est de toute façon impossible vu que cela reste une tronçonneuse. » Pour de plus amples informations, voir le correctif.
Liste non exhaustive des vulnérabilités corrigées
- CVE-2015-4178 mitre [correctif] ;
- CVE-2015-4177 mitre [correctif] ;
- CVE-2015-4176 mitre [correctif] ;
- CVE-2015-4001 NVD, mitre, CVE-2015-4002 NVD, mitre, CVE-2015-4003 NVD, mitre, CVE-2015-4004 NVD, mitre : annonce sur la LKML par Jason A. Donenfeld, annonce sur oss-sec, documentation du pilote OZWPAN [correctifs : 1, 2, 3, 4] ;
- CVE-2015-3339 NVD, mitre [correctif] ;
- (?) [correctif] ;
- Pas de CVE : fuite d’information [correctif].
Nouveau matériel pris en charge
- Générateur de nombres aléatoires : Altus Metrum ChaosKey [correctif].
Réseau
eBPF
eBPF est un système universel de machine virtuelle intégré au noyau, désormais utilisé pour la classification et le routage des paquets. Cela permet d’avoir plus de débit et moins de latence, particulièrement sur les routeurs.
Plus d’informations dans les correctifs [1 et 2] et l’article de Phoronix.
Routage des paquets en utilisant le mécanisme « multiprotocol label switching » (MPLS)
Le mécanisme de routage MPLS (multiprotocol label switching) est maintenant géré par Linux. [correctifs : 1, 2 et 3]
Implémentation de la RFC 7217 (IPv6)
La RFC 7217 vient d’être implémentée dans Linux, ce qui devrait permettre de garder une adresse IPv6 anonyme (l’adresse MAC n’est pas divulguée dans l’adresse IP) tout en gardant la propriété importante de stabilité de l’adresse lors de la mobilité. Pour plus d’informations, veuillez consulter la RFC 7217.
Systèmes de fichiers
Pilote pour les périphériques dits à mémoire persistante
Le pilote basique de mémoire persistante a été incorporé, améliorant la prise en compte dans le noyau des périphériques à mémoire non volatile de grande taille.
Article LWN.net : Persistent memory support progress.
F2FS
F2FS dispose maintenant du cache en mémoire extent_cache. La fonctionnalité fs_shutdown permet de faire des tests de coupure d’alimentation pour fiabiliser le comportement en cas de coupure à chaud. Dorénavant, le chemin des liens symboliques est stocké inline, c’est‐à‐dire directement dans le nœud d’index (inode). F2FS permet déjà de stocker des petits fichiers directement dans ces derniers (voir Enable F2FS support inline data). Les liens symboliques étant un cas spécifique de petit fichier (fichier contenant un lien), ce traitement ne s’appliquait jusqu’alors pas à eux. On notera par ailleurs l’activation par défaut du stockage inline à partir de cette version.
Diverses améliorations côté gestion de l’énergie, point important vu l’utilisation de F2FS dans nos téléphones.
Pour plus d’informations, vous pouvez consulter l’article de Phoronix.
BLK-MQ
La gestion des multi‐queues a été améliorée, surtout avec le multiprocesseur.
ext4
ext4 est maintenant capable de chiffrer directement les fichiers et dossiers du système de fichiers. Cette nouvelle fonctionnalité permet de se passer de dm-crypt ou eCryptfs, suivant les cas.
XFS
Lors d’un renommage, la source n’est plus supprimée mais remplacée par des blancs (RENAME_WHITEOUT). Cela devrait permettre son utilisation avec le système d’union de systèmes de fichiers OverlayFS.
Nouveau aussi dans XFS, la prise en charge de l’option FALLOC_FL_INSERT_RANGE par fallocate(), permettant aux applications d’insérer des trous dans un fichier.
Les superblocs par processeur ont été remplacés par des compteurs génériques.
Nouveau verrou inode mmap sur les erreurs de page.
Une réécriture de la soumission des entrées‐sorties directes pour mieux prévenir les corruptions de données lors des écritures.
Amélioration de la journalisation des messages, et les traditionnelles corrections de bogues et nettoyages.
RAID 5 et 6 pour le RAID Logiciel
Les blocs de 4 Kio sont maintenant gérés. Le cache de bande est maintenant dynamique. Le RAID 6 peut maintenant faire des cycles lecture/modification/écriture avec de meilleures performances sur des grappes de six disques ou plus.
RAID 1
Le sous‐système MD (RAID) peut dorénavant gérer les matrices RAID 1 de façon distribuée sur une grappe de serveurs (cluster). Le code correspondant est actuellement marqué comme expérimental, mais il est de toute évidence proche d’un état de production.
Device mapper
Le gestionnaire de périphériques peut maintenant fonctionner comme un périphérique bloc à files multiples, augmentant les performances. Cette fonctionnalité est actuellement désactivée par défaut, mais peut être activée avec la variable de configuration CONFIG_DM_MQ_DEFAULT.
Btrfs
Les systèmes de fichiers de plus de 20 Tio n’étaient pas gérés correctement à cause d’un problème de gestion de l’espace libre, cela est maintenant corrigé. Des corrections pour la suppression de fichiers de plus de 3 Tio ont également été apportées.
Enfin, un bogue empêchant le passage d’un niveau de RAID à un autre a de même été corrigé.
tracefs
Steven Rostedt vient d’intégrer un nouveau système de fichiers : tracefs. Certains administrateurs système ont remonté qu’il y avait un souci à être obligé d’utiliser debugfs pour pouvoir activer les fonctionnalités de « traçage » du noyau. Pour des raisons de sécurité, certains interdisent simplement l’utilisation de debugfs.
tracefs apporte la possibilité d’utiliser les capacités de « traçage » sans l’utilisation de debugfs, et ceci sans casser la compatibilité avec les outils existants.
zram
Le périphérique bloc zram peut maintenant effectuer la compression de blocs de données. Voir l’article LWN sur le sujet.
Meilleure gestion des erreurs pour les disques
Le standard ATA de commandes de gestion des disques a une nouvelle spécification ACS-4. Elle permet grâce à la commande NCQ Autosense d’obtenir le même niveau d’information sur les erreurs qu’en SCSI. Le noyau 4.1 implémente cette commande, qui n’est pour l’instant reconnue que par une poignée de nouveaux disques durs.
Virtualisation
KVM
Comme d’habitude, la demande d’intégration se fait en deux fois, une pour les PowerPC et une pour les autres architectures.
- s390 (mainframe IBM) : prise en charge des instructions SIMD, le code de gestion des interruptions a été retravaillé afin de pouvoir récupérer la liste des interruptions et de pouvoir en définir avec des
ioctl(), ceci afin de permettre la migration d’invités d’un hôte à l’autre. Les clefs de stockage qui permettent de protéger l’accès aux données peuvent être maintenant définies et récupérées dans un invité via de nouveaux appelsioctl(). - MIPS : prise en charge des instructions FPU et SIMD.
- x86 : principalement des corrections de bogues, il y a eu un débat sur le fait que les développeurs KVM se sont permis d’aller mettre du code dans l’ordonnanceur, zone du noyau qui appartient à un autre mainteneur, qui plus est, ce dernier n’était pas du tout content du code. Finalement, le code a été écrit d’une autre façon pour qu’il n’y ait pas besoin de modifier autre chose que KVM.
- ARM : des corrections pour la migration à chaud, prise en charge des
irqfd(ce qui permet d’injecter des interruptions dans l’invité via un descripteur de fichier eventfd) et ioeventfd (qui permet de faire l’asynchrone pour certaines opérations d’entrée‐sortie pour lesquelles une opération synchrone dans un invité est très coûteuse, comme une demande d’opération DMA), ainsi que le « page aging ». - PowerPC : amélioration du débogage, légère amélioration des performances et nettoyage du code pour les processeurs de type Book3S.
Xen
- ajout d’un pilote contrôleur programmable d’interruptions (APIC) pour gérer plus de 255 processeurs virtuels dans les invités ;
- amélioration des performances pour les opérations de migration, sauvegarde et restauration de l’état ;
- prise en charge de la sauvegarde et la restauration pour le pilote scsiback/front ;
- mise en place de l’infrastructure pour avoir le XenBus sur plusieurs pages.
VirtIO
Le sous‐système virtio a un nouveau pilote virtio-input. Son travail est de collecter et faire suivre les événements des périphériques d’entrée vers un périphérique virtuel.
Le bilan en chiffres
En ce qui concerne les statistiques du cycle de développement du noyau 4.1, le site LWN.net a publié son traditionnel article récapitulatif.
En nombre de modifications, on se situe à 11 664, soit environ 1 500 modifications de plus que la version précédente du noyau, mais reste en dessous de la moyenne de ces derniers noyaux. Cette nouvelle version a ajouté 486 000 lignes de code alors qu’elle en a supprimé 286 000, ce qui a conduit à une augmentation nette de 200 000 lignes. Le nombre de contributeurs s’approche quant à lui au moins à 1 492 auteurs. Il est possible que lors de la sortie, plus de 1 500 auteurs aient contribué ce qui est un nouveau record !
Pour changer, le développeur ayant fait le plus de modifications travaille au nettoyage des pilotes Comedi. Cependant, ce n’est pas l’habituel Hartley Sweeten, mais Ian Abbott qui remporte la palme cette fois. Du côté des développeurs ayant le plus modifié de lignes, Jie Yang se retrouve sur la première marche par son travail de réorganisation du pilote audio Intel.
Au moins 215 entreprises ont participé à l’élaboration de ce noyau. En tête, on retrouve encore Intel, qui a effectué 11,2 % des changements que l’on peut trouver dans cette nouvelle version. En deuxième place, Red Hat a contribué pour 9,2 % des changements. Il est cependant important de noter que les développeurs sans affiliation ont effectué 9 % des modifications, soit juste un peu moins que Red Hat, alors que les personnes non identifiées ont écrit 8,1 % des modifications. On peut donc dire que, bien que le noyau soit majoritairement écrit par des employés d’entreprises, les contributeurs indépendants sont toujours les bienvenus et sont même une majorité !
Appel à volontaires
Cette dépêche est rédigée par plusieurs contributeurs dont voici la répartition :
| Mainteneur | Contributeur(s) | |
|---|---|---|
| La phase de test | Aucun | eggman |
| Arch | Romain Perier | |
| Développeurs | Aucun | |
| Pilotes graphiques libres | Martin Peres | |
| Réseau | Aucun | BRULE Herman (alpha_one_x86) |
| Systèmes de fichiers | Aucun | BRULE Herman (alpha_one_x86),Mali |
| Sécurité | Timothée Ravier | |
| Virtualisation | Xavier Claude | |
| Édition générale | Aucun | Martin Peres, eggman, Timothée Ravier |
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 Édition générale, Systèmes de fichiers et Réseau, 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. La page wiki Rédiger des dépêches noyau signale quelques possibilités pour aider à la rédaction et s’y impliquer (ce que tout inscrit peut faire, ne serait‐ce que traduire^Wsynthétiser les annonces de RC). Essayons d’augmenter la couverture sur les modifications du noyau !
Aller plus loin
- Les noyaux précédents (580 clics)
- Site officiel du noyau Linux (500 clics)
# Sur laptop avec GPU Intel
Posté par Julien Wajsberg . Évalué à 8.
Attention, le noyau 4.1 a ce souci: https://bugzilla.kernel.org/show_bug.cgi?id=100641
Le problème visible est qu'il ne se met plus en veille après une première veille. Un contournement a été ajouté à systemd v221.
[^] # Re: Sur laptop avec GPU Intel
Posté par NeoX . Évalué à 5.
troll inside :
bug noyau, ou bug systemd ?
:p
NB: je ne suis pas allé voir le bugtracker cité en source
[^] # Re: Sur laptop avec GPU Intel
Posté par benoar . Évalué à 5.
Tu blagues mais c'est effectivement un peu le cas : http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/62584/focus=62733
C'est un changement du noyau suite à un « mauvais comportement » de systemd, qui a cassé systemd d'une autre manière à laquelle ils ne s'attendaient pas…
[^] # Re: Sur laptop avec GPU Intel
Posté par DerekSagan . Évalué à 10.
ah, le noyau ne fait pas partie de systemd ?
# Résignation du poste d’éditeur de la dépêche
Posté par Martin Peres (site web personnel) . Évalué à 10.
Version courte: https://www.youtube.com/watch?v=NLG9ELhaktk
Version longue:
Il devient apparent que depuis la fin de mon doctorat, je ne consacre plus autant de temps à l'informatique. Du coup, je laisse traîner les taches qui me sont les moins satisfaisantes … tel que le travail d’édition de cette dépêche.
J’apprécie toujours autant de contribuer à la partie graphique, mais la relecture attentive, relancer les contributeurs, rendre le style homogène, remplir les manques et faire en sorte qu'on soit dans les temps ne fait plus vraiment partie de mes priorités. Comme je tiens à cette dépêche, je préfère passer le flambeau à une personne qui saura faire un meilleur travail que le mien durant ces deux dernières dépêches!
La dépêche cherche donc, de toute urgence, un nouvel éditeur en chef! Postez vos candidatures ci-dessous! Vous pouvez aussi candidater pour travailler sur les sections qui n'ont pas de mainteneurs car elles en ont vraiment besoin! D'habitude je prend le temps de les compléter un peu plus, mais c'est vraiment plus ma priorité maintenant :s
De mon coté, je continuerai à maintenir la section pilote graphiques libres! Et si je suis en retard dessus, je pries le futur éditeur de bien vouloir me botter le cul!
[^] # Re: Résignation du poste d’éditeur de la dépêche
Posté par esdeem . Évalué à 10.
Merci pour ton engagement jusque là.
Ton travail d'édition a été appréciable et ce fut, en ce qui me concerne, agréable de participer à l'édition des dépêches noyau.
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: Résignation du poste d’éditeur de la dépêche
Posté par Xaapyks . Évalué à 2.
Merci pour ta participation en tout cas (ainsi qu'aux autres contributeurs) !
Tant que tu es dans le coin, j'ai une petite question puisque la dépêche parle du multi-stream sur displayport, je m'interroge sur l'adaptative-sync ? Tu sais si c'est prévu sur DRM/radeon ? Et même éventuellement chez les autres (Ce serait un comble de rendre compatible un GPU nvidia :D mais du coup même question pour G-sync chez eux ?)
Je trouve peu d'infos à ce sujet.
[^] # Re: Résignation du poste d’éditeur de la dépêche
Posté par Martin Peres (site web personnel) . Évalué à 3.
Pour le coup, je n'ai aucune idée! je suppose que Radeon devrait pouvoir gérer ca plus ou moins rapidement. Cela dit, je doute qu'il soit possible de faire de l'adaptative-sync sur du hw pas prévu pour!
[^] # Re: Résignation du poste d’éditeur de la dépêche
Posté par Gnurou (site web personnel) . Évalué à 6.
Juste pas curiosité, combien d'heures estimes-tu passer sur chaque dépêche?
Je filerai bien un p'tit coup de main, mais je pense qu'on a le même problème de gestion du temps… :P
[^] # Re: Résignation du poste d’éditeur de la dépêche
Posté par Martin Peres (site web personnel) . Évalué à 4.
Hey, tu veux aider sur la partie graphique? Je dis pas non!
Disons que je fais en fonction du temps disponible. Il y a beaucoup de variance suivant les releases aussi. Quand je comprend tout se qu'il se passe, j'ai peu de boulot a faire en plus de regarder les pull requests sur dri-devel et la liste des commits. Du coup, je dirai que tout écrire serait l’équivalent de 5-10h.
Parfois, les pull requests sont peu clairs et je regarde les commits, les bug reports associés et les articles de blog. Par exemple, je n'avais aucune idée que les télés avaient un espace de couleur différent des écrans de PC! Ça m'a prit une grosse demi heure de lecture en partant de l'acronyme pour avoir une bonne compréhension des patchs! Pareil sur PPGTT, les commits sont pas fait pour etre compris par ceux qui n'ont pas lu la doc, alors il faut se renseigner avec des ressources publiques (les ingés intel bloguent pas mal!) et la, on peut facilement passer 1 ou 2h sur un paragraphe.
En général, je passe une soirée pour collecter les liens + écrire la partie DRM. Ensuite je passe une soirée par gros driver (intel, radeon et nouveau). Je réserve ensuite une demi soirée pour les pilotes ARMs.
Concernant le travail d’édition, c'est probablement une vingtaine d'heure si on veut bien faire! Il faut tout homogénéiser, organiser, relancer les contributeurs, etc… Récemment, ce travail s'est résumé a faire plusieurs relectures et bouger les paragraphes qui n'ont rien a faire dans Arch/, mais c'est pour ça que je résigne! Je ne fais plus un bon boulot!
Disons que je sais pourquoi je fais le travail sur la partie graphique (apprendre et me tenir a jour), concernant l’édition, c'est vraiment pas ma passion mais je le faisais, faute de trouver quelqu'un d'autre pour le faire!
[^] # Re: Résignation du poste d’éditeur de la dépêche
Posté par Mali (site web personnel) . Évalué à 4. Dernière modification le 17 juillet 2015 à 17:16.
Je crois qu'on dit "démissionne" en bon français ;-)
[^] # Re: Résignation du poste d’éditeur de la dépêche
Posté par Lucas . Évalué à 5.
En fait non, même si dans ce sens résigner est désuet et que le verbe est transitif.
[^] # Re: Résignation du poste d’éditeur de la dépêche
Posté par Mali (site web personnel) . Évalué à 1.
Effectivement, autant pour moi. Je croyais à une francisation de "resigned"
[^] # Re: Résignation du poste d’éditeur de la dépêche
Posté par BAud (site web personnel) . Évalué à 3.
Si je n'avais pas vu l'annonce en tribune de rédaction, j'aurais cru à une phôte d'ortho avec « je resigne ! » vu tout le boulot de motivation effectué avec efficacité jusque maintenant. La canicule est passée par là :/
Pour autant, le dernier § est présent depuis le début : cela ne doit pas être un frein à l'implication (j'ai toujours essayé de faire en sorte de m'en enlever si quelqu'un m'y rajoutait :D).
Alors, qui pour vouloir écrire sur son CV « J'ai remplacé patrick_g< et mupuf< pour motiver la bande de joyeux drilles souvent présents à écrire les dépêches noyau sur LinuxFr.org à ma place ! » ? :D
Hormis savoir écrire sur une ML, être présent sur la tribune de réduction, faire des relectures et avoir du temps sur la fin pour homogénéiser / trancher et compléter comme on peut ce qui manque (ça ce serait aux mainteneurs de le faire pour leur partie), pas besoin de compétences particulières sortant de la norme (éventuellement aimer écrire de manière compréhensible et en équipe). Je mets dans un autre commentaire le temps à être prêt à y passer.
[^] # Re: Résignation du poste d’éditeur de la dépêche
Posté par antistress (site web personnel) . Évalué à 4.
Hey ! Il y en a eu d'autres ! ;)
(mais ces vrais que ces deux là savent de quoi ils parlent…)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Résignation du poste d’éditeur de la dépêche
Posté par xcomcmdr . Évalué à -10.
Au temps pour moi ne veut rien dire. Autant pour moi a déjà un peu plus de sens.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4. Dernière modification le 30 juillet 2015 à 10:11.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Résignation du poste d’éditeur de la dépêche
Posté par xcomcmdr . Évalué à -10.
Peu importe, ça n'a aucun sens et l'explication de l'Académie est tirée par les cheveux et n'explique rien.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Résignation du poste d’éditeur de la dépêche
Posté par barmic . Évalué à 6.
Ce qui n'a aucun sens pour toi remplirait pas mal de livre ce n'est pas pour autant que c'est faux ou que ça n'existe pas.
Pour une grande partie des gens la manière dont a évolué le français n'a pas de sens (les règles pour ajouter, ou non, un "s" par exemple) ce n'est pas pour autant qu'ils peuvent se permettre de violer l'orthographe des mots.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Résignation du poste d’éditeur de la dépêche
Posté par xcomcmdr . Évalué à -2.
Quitte à ne pas violer quelque chose, autant ne pas violer la logique avec une expression qui ne veut rien dire.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Résignation du poste d’éditeur de la dépêche
Posté par xcomcmdr . Évalué à -3.
Merci pour l'insulte gratuite.
Pour une grande partie des gens, ce n'est pas parce que c'est l'Académie qui le dit qu'il faut mettre son esprit critique au placard.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Résignation du poste d’éditeur de la dépêche
Posté par NicolasG . Évalué à -1.
http://www.arte.tv/guide/fr/042859-000/le-scandale-impressionniste?autoplay=1
[^] # Re: Résignation du poste d’éditeur de la dépêche
Posté par gst . Évalué à 2.
Merci, j'ai appris quelque chose aujourd'hui \o/ :)
[^] # Re: Résignation du poste d’éditeur de la dépêche
Posté par Martin Peres (site web personnel) . Évalué à 6.
Oops pour la transitivité! Mais oui, je voulais pas démissionner, juste donner ma place à quelqu'un capable de faire un meilleur travail.
[^] # Re: Résignation du poste d’éditeur de la dépêche
Posté par BAud (site web personnel) . Évalué à 9. Dernière modification le 17 juillet 2015 à 23:25.
Concernant le travail d'édition et le temps à y passer, basé sur un ressenti de ce que j'ai pu constater, je proposerais plutôt le découpage suivant :
Soit :
En étant mainteneur, il est sans doute possible de réduire ces temps, la participation régulière allant de soi.
En temps que relecteur / correcteur épisodique, cela me prend désormais 10 min à évaluer les changements, mais de l'ordre de 1 h à faire chaque relecture complète + petites corrections de-ci, de-là comme l'ortho, le Markdown, les formulations, la cohérence des traductions… (cela me prenait de l'ordre de 2h pour les dépêches de patrick_g< mais l'organisation était différente et j'étais sans doute moins efficace, j'y reviendrai si je retrouve ce que j'avais pu indiquer à l'époque).
Nÿco< a eu la bonne idée de demander des stats de rédaction par dépêche qui pourraient corroborer (ou infirmer) cela ;-) (avec quelques extensions et une représentation plus graphique sans doute, un peu comme sur https://github.com/linuxfrorg/linuxfr.org/graphs/contributors vu que je n'ai pas réussi à retrouver une similaire sur ohloh^WOpenHub :/).
[^] # Re: Résignation du poste d’éditeur de la dépêche
Posté par Martin Peres (site web personnel) . Évalué à 3.
Ça semble être un bon plan pour du bon boulot d’édition!
[^] # Re: Résignation du poste d’éditeur de la dépêche
Posté par antistress (site web personnel) . Évalué à 6.
Bravo et merci Martin pour le boulot accompli tout au long de ces dépêches :)
# Drivers graphiques libres broadcom videocore4 (raspberry pi) ?
Posté par aworan78 . Évalué à 2.
Bonjour à tous,
Je me demande si le driver graphique pour le vc4 (qui est le gpu raspberry pi) a été ajouté au noyau 4.1.
Je ne vois pas mention de celui-ci dans l'article.
J'avais cru comprendre sur phoronix que c'étais prévu pour cette version : http://www.phoronix.com/scan.php?page=news_item&px=Raspberry-Pi-VC4-Linux-4.0
Quelqu'un est au courant de son intégration ou non ? :)
Merci !
[^] # Re: Drivers graphiques libres broadcom videocore4 (raspberry pi) ?
Posté par Martin Peres (site web personnel) . Évalué à 10.
Non, je ne suis au courant de rien de ce coté là!
En tout cas, il n'est pas mergé: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/gpu/drm
[^] # Re: Drivers graphiques libres broadcom videocore4 (raspberry pi) ?
Posté par aworan78 . Évalué à 3.
Dommage,
Merci pour ta réponse en tout cas :)
# Erreur de calcul
Posté par benoar . Évalué à 3.
Augmentation nette de 200 000 lignes plutôt, non ?
[^] # Re: Erreur de calcul
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
[^] # Re: Erreur de calcul
Posté par Martin Peres (site web personnel) . Évalué à 2.
Bien vu! Erreur de copier/coller, vérifié sur LWN.
# Francisation
Posté par Alexandre Belloni (site web personnel) . Évalué à 4.
Moi je trouve dommage que la dépêche soit francisée à outrance ce qui en vient jusqu'à nuire à la lisibilité. Je donnerai pour exemple l'utilisation du mot "correctif" pour désigner un patch alors que c'est un ajout de fonctionnalité qui ne corrige rien.
Ou encore, je défie quiconque de me dire ce qu'est réellement: "Le nouveau système d’« accaparement » du système d’entrées‐sorties à usage général GPIO peut être utilisé pour câbler facilement — et de façon permanente — l’état d’une ligne GPIO spécifique sans nécessiter de pilote."
Il y a aussi les expressions bien traduites une fois sur deux:
- "Le MSM8916 intègre un ARM Cortex A53 quad-cœurs"
- "un processeur quatre cœurs ARM Cortex-A53"
On est bien en présence de quatre cœurs ARM Cortex-A53 dans les deux cas.
[^] # Re: Francisation
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
https://fr.wikipedia.org/wiki/Patch_%28informatique%29
« Les termes recommandés en France par la DGLFLF sont « retouche » ou « correctif ». Au Canada, le terme recommandé par l'OQLF est « correctif », le mot « rustine » étant également accepté. » correctif est bien utilisable pour toute modification.
Pour ton second paragraphe, n'hésite pas à proposer une meilleure traduction.
Merci pour la correction sur le quadricœur.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Francisation
Posté par BAud (site web personnel) . Évalué à 5.
Merci pour la suggestion du terme « modification », je l'ai ajoutée à la page de traductions-classiques, c'était aussi un des termes proposés par Jiehong< pour commit. Il y a d'ailleurs beaucoup d'autres termes dont discuter sur cette page wiki :-) N'hésite pas à y participer _o/
Désolé pour le quad-cœur qui était resté, je crois que je l'avais vu mais omis de le rectifier sur le moment, pensant sans doute repasser dessus par la suite.
Àmha, pas forcément besoin de franciser à outrance, effectivement ; pour autant il y a beaucoup de termes ayant leur équivalent en français (et tout aussi précis que l'anglais, autant les utiliser, même si je reste toujours autant dubitatif devant cadriciel o_O au hasard, mais je n'ai pas mieux jusque maintenant).
[^] # Re: Francisation
Posté par Zenitram (site web personnel) . Évalué à 2.
Après, tout est dans le subjectif, car de mon point de vue à 200% subjectif, traduire patch et commit est déjà dans l'outrance…
(surtout quand ça fait des "Ça y est, correctifs de dernière minute et tout. Le patch rc-4 est un peu plus gros que les précédents" où on a des correctifs et des patchs pas loin, on s'y perd)
Sur ce, vivement la fin de semaine (parce que dire Week end serait sans doute mal vu même si il est dans un dictionnaire français) et n'oubliez pas de vous arrêter aux panneaux "arrêt" (le premier qui dit stop sera mal vu étant donné qu'il y a l'équivalent en français) (ha souvenir du Québec francisant plus que les français…)
[^] # Re: Francisation
Posté par BAud (site web personnel) . Évalué à 6.
chaque traducteur choisit d'utiliser les termes ;-) perso, je traduis rarement commit et patch (je les mets parfois en italique).
Pour information, je te remets la ligne d'origine, à comparer au résultat en français (à peine plus long) :
N'hésite pas à venir participer pour renverser la tendance à trop traduire ;-) Tu pourras y noter l'éradication systématique du terme « support » lorsqu'il s'agit de gérer ou prendre en charge du matériel :D (il perdure dans les phrases en anglais).
[^] # Re: Francisation
Posté par esdeem . Évalué à 3.
Le problème de « modification » pour patch, c'est que la notion même de correctif à appliquer, un peu comme une rustine sur une chambre à air, y est complètement absente.
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: Francisation
Posté par BAud (site web personnel) . Évalué à 2.
Je te renvoie à la définition informatique de patch : en réalité, c'est aussi appliquer la sortie d'un
diff -Naurvia la commandepatch. Cela fait qu'il peut y avoir des ajouts de fonctionnalité, pas seulement des contournements ou de petits correctifs…[^] # Re: Francisation
Posté par esdeem . Évalué à 3.
Le lien que tu donnes ne me donne pas tort, mais ta remarque est correcte.
Le français est pour le coup plus subtil que la langue de Shakespeare.
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: Francisation
Posté par xcomcmdr . Évalué à 2. Dernière modification le 17 juillet 2015 à 11:10.
Je vois pas en quoi. On peut utiliser le terme générique patch, mais aussi modification en anglais si on veut éviter que ce soit pris pour juste du correctif.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Francisation
Posté par Alexandre Belloni (site web personnel) . Évalué à 0.
Non parce que le correctif, c'est un fix. Donc la modification (patch) peut être un correctif (fix). Et voilà, les deux langues ont le même niveau de subtilité.
[^] # Re: Francisation
Posté par esdeem . Évalué à 2.
C’était dans le sens de la traduction [en → fr].
Un mot comme patch nécessite un peu d’attention si l’on veut traduire la subtile différence entre correctif et modification, le patch pouvant amener les deux.
fix est (quasiment) toujours traduit par correctif ; patch, non.
Pour le reste, on trouve dans l’autre sens [fr→ en] le même genre de problèmes.
Dans la langue d’arrivée, il est n’est pas rare de devoir choisir un mot dont le sens est plus précis que le sens général du mot dans la langue de départ, parce qu’il n’y a pas de mot dans la langue d’arrivée qui recoupe l’ensemble du sens du mot dans la langue de départ.
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: Francisation
Posté par Alexandre Belloni (site web personnel) . Évalué à 2.
Donc on est bien d'accord, il y a une association 1:1 entre fix et correctif et patch et modification.
Traduire patch par correctif, c'est ajouter de l'information par rapport au texte original.
[^] # Re: Francisation
Posté par Michaël (site web personnel) . Évalué à 3. Dernière modification le 23 juillet 2015 à 07:06.
Je pence que “pièce” ou “rapiècement” est pas mal, comme dans “pièce” de tissu. Seul le second suggère une correction.
[^] # Re: Francisation
Posté par BAud (site web personnel) . Évalué à 3.
/me remet une pièce dans le juke-box ;-)
s/pence/pense/ au passage :D
[^] # Re: Francisation
Posté par flan (site web personnel) . Évalué à 4.
J'aime bien le terme retouche, je le trouve bien adapté et je le note pour plus tard. Merci !
[^] # Re: Francisation
Posté par Alexandre Belloni (site web personnel) . Évalué à 3.
Je ne pense pas que ça soit une bonne pratique de se baser sur les recommandations du Canada. J'y ai fini mes études et j'avais le droit a tout mes anglicismes entourés en rouge avec écrit loi 101 à côté. Tout ça pour des mots simples comme buffer (de buffer circulaire, qui me semble être communément accepté en français) ou socket.
D'un autre côté, à l'oral, il font exactement l'inverse et parlent de fuse (fusibles), breaker (disjoncteur) ou wiper (essuie glace).
Aussi, je ne connais personne qui suit à la lettre la DGLFLF et je pense qu'il faut accepter que les secteur est mené par des anglophones.
Avec la DGLFLF, on peut faire des phrases qui ont du sens mais qui sont incompréhensibles:
"J'ai utilisé mon bloc-notes électronique pour écrire un correctif pour la barrière de sécurité du noyau. Le code ne passait pas le bon chiffre binaire dans le tampon configurant le connecteur logiciel."
Glossaire pour rigoler:
- socket: connecteur logiciel
- e-mail: courrier électronique
- URL/URI: adresse universelle
- boot: amorce
- applet: appliquette
- notepad: ardoise électronique
- notebook: bloc-notes électronique
- spammer: arroseur
- firewall: barrière de sécurité
- bug: bogue
- set top box: boîtier adaptateur
- chat: causette
- bit: chiffre binaire
- bytecode: code à octets
Je reviens aussi sur la première expression qui m'a fait tiquer, lors d'une des premières dépêches: "systèmes monopuce" (c'est encore plus drôle quand on voit l'utilisation directe de die dans la suite de la dépêche). Je ne connais pas un seul fabricant de SoC qui utilise "systèmes monopuce" pour décrire leur produit (même pas les fabricants Français).
Après, j'apprécie globalement ces dépêches, je reviens à mon point premier qui est qu'elles deviennent illisible sans dictionnaire tellement les expressions utilisées ne sont pas usitées. Je pense que quelqu'un que ne sais pas ce qu'est une GPIO par exemple ne saura pas non plus ce que sont des "entrées‐sorties à usage général". Je suis d'accord qu'il faille simplifier pour rendre les explications accessible au profane mais je ne pense pas que la traduction des termes techniques les rendent plus compréhensibles (en tout cas, c'est l'inverse pour moi).
[^] # Re: Francisation
Posté par Foutaises . Évalué à 9.
Sans vouloir m'engager plus avant dans le débat, j'avais bien compris le sens de cette phrase en Français, et j'imagine que dans le doute, une simple lecture du glossaire suffit à rendre tout lumineux par la suite.
D'ailleurs, je ne vois pas trop en quoi ton glossaire ferait rigoler, j'y trouve des traductions qui tombent sous le sens (e-mail : courrier électronique, boot : amorce, bit : chiffre binaire), et qui étaient déjà utilisées il y a plus de 20 ans de ça pour expliquer les termes dans l'autre sens, à des étudiants qui ne pipaient pas grand chose à l'anglais/l'informatique, et qui avaient donc besoin d'un lexique vers le Français.
À part peut-être bit, qui gagnerait à être traduit par « unité binaire », étant donné qu'un chiffre (0 à 9) peut nécessiter plusieurs bits pour être codé (ce qui ne retire rien au fait qu'un 0 ou un 1 est bel est un chiffre binaire).
Je ne savais pas ce qu'était une GPIO (du moins l'abréviation), alors que j'ai compris de quoi il s'agissait avec « entrées‐sorties à usage général » (et le contexte). De même, je ne suis pas certain de me rappeler ce que voulait dire GPIO dans quelques mois, alors que je comprendrai de suite en voyant la traduction française.
J'ai bien compris que le fond de ta critique ne concernait que la francisation à outrance de termes techniques, et je sais qu'il y a des cas de figure où effectivement, les traductions peuvent être malheureuses, mais ce n'est pas pour autant qu'il faille abandonner tout effort de préserver notre culture, ou du moins de ne pas se laisser bouffer par une autre.
Aujourd'hui, on a globalement 2 générations qui ont été abreuvées d'anglais et de culture américaine, qui trouvent que les films sont mieux en VO parce que les voix américaines font plus badass (parce que dur à cuir, ça pète moins, tu vois ?) – sans qu'il soit question de qualité de doublage (je ne parle pas des Dragon Ball Z, Ken le Survivant ou pire encore, aux doublages/traductions déplorables il est vrai). Le plus triste, c'est quand tu vois la gueule des sous-titres FR qu'ils font, avec des lignes de 80 caractères bourrées de fautes et au vocabulaire très pauvre, souvent sans même avoir compris le sens véritable (ou l'humour) de la tournure anglaise derrière, sans parler des abus de tutoiement, etc.
En fait non, ce n'est pas le plus triste… J'ai vu récemment passer des messages sur les forums de jeux vidéos pourtant très bien traduits, avec même un effort remarquable en ce sens, pour réclamer l'abandon du « doublage » et le recours à la seule VO… Comme si les personnages 3D avaient une « langue originale »… Mais bon, c'est juste que pour eux qui sont abreuvés de culture américaine, les voix américaines sonnent mieux à leurs oreilles, et les mots anglais en jette plus, et tout ce qui fait trop franco-franchouillard c'est naze, ça leur est presque étranger.
C'est quand je vois ça que je me dis qu'il faut au contraire intensifier la traduction intelligente de ce qui peut l'être, pour ne pas empirer la situation en faisant baigner toujours plus les gens dans la culture anglo-saxonne.l
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Francisation
Posté par briaeros007 . Évalué à 5.
Ben moi non.
déjà "chiffre binaire" j'avais absolument pas compris comme "bit";
la "barrière de sécurité du noyau", j'ai aucune idée à quoi ça fait référence.
Je fais quel recherche "grep" sur le code de linux pour avoir une idée avec "barrière de sécurité" ?
Le français c'est cool.
Mais je ne suis pas sur que s'amuser à se créer un petit ilot de mot compris que d'une minorité , et nécessite pour un type du métier de faire 5 recherches dans un dico pour lire une phrase de 2 lignes soit la meilleur façon de pousser à l'adoption de plus de français.
Concernant "entrées‐sorties à usage général", peux-tu m'expliquer ce que tu as compris avec ce terme ?
Je ne trouve pas que ca reflète ce que je connais des GPIO, mais comme je connaissais les GPIO déjà avant le terme français, je suis biaisé. D'où ma question ;)
[^] # Re: Francisation
Posté par Arthur Accroc . Évalué à 5.
« Bit » est l’abréviation de « binary digit » qui veut dire… « chiffre binaire » !
Après pour des abréviations comme GPIO (que je ne connaissais pas), ce n’est pas tant la langue que l’abréviation qui fait que c’est abscons.
Si on ne connaît pas toutes les abréviations, les expressions littérales — en français ou pas — sont plus abordables, même si elles n’ont pas la précision d’un article Wikipédia (qu’on utilise les unes ou les autres, un lien détaillant les réalités techniques qu’elles désignent serait le bienvenu).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Francisation
Posté par Moonz . Évalué à 4.
Non. Sérieusement, non. En tant que non biologiste, la seule chose que m’apporte « Acide désoxyribonucléique » relativement à « ADN », c’est que c’est un acide. Allez, sans t’aider de google, c’est quoi le « complexe majeur d’histocompatibilité » ? C’est une expression littérale, ça devrait donc être abordable non ?
GPIO, ça a l’avantage d’être reconnu instantanément par ceux qui connaissent (perso j’ai déjà joué avec les ports GPIO de mon raspberry, et j’ai pas reconnu l’expression « entrées‐sorties à usage général… »), d’être googlable facilement par ceux qui connaissent pas, et de ne pas être ambigu.
[^] # Re: Francisation
Posté par ElectronLibre63 . Évalué à 10.
C'est facile de trouver des contre-exemples, mais ça montre simplement que beaucoup de gens utilisent des sigles sans connaître leur signification.
Au boulot, j'ai sans arrêt des problèmes avec des personnes qui utilisent des sigles, chaque service utilise ses sigles, et bien sûr il y a des sigles communs aux différents services qui ont des significations différentes. Et parfois lorsque j'en ai marre de ne pas comprendre de quoi on me parle, et que je leur demande une explication, l'habitude d'utiliser un sigle fait qu'ils en oublient la signification et sont bien en peine de me répondre.
Un exemple parmi tant d'autres, j'ai eu à remplir l'annuaire d'un fax commun à plusieurs services, il s'est trouvé que sur plus de 200 numéros, il y avait plusieurs couples avec le même nom et des numéros différents. Ça aurait pu être plusieurs contacts au sein de mêmes sociétés, mais les numéros étaient très différents et après vérification, c'était des sociétés différentes mais avec des initiales identiques.
D'ailleurs il suffit de voir les pages wikipedia sur les sigles pour s’apercevoir des multiples significations que peuvent avoir un sigle.
Donc généralement, je trouve que l'usage de sigles et abréviations, doit se limiter au groupe auquel ils s'adressent, et plus on s'adresse à un public large, plus il est préférable d'utiliser une expression littérale et éventuellement mettre entre parenthèses le sigle ou l'abréviation (voire le contraire si le sigle est plus connu).
[^] # Re: Francisation
Posté par Thomas Debesse (site web personnel) . Évalué à 9.
Non, un bit c’est une unité binaire, car cette unité peut à la fois prendre la valeur numérique
1ou0.Le chiffre
1ne peut qu’exprimer la valeur numérique1, de même, le chiffre0ne peut qu’exprimer la valeur numérique0.L’unité est un nombre spécial, c’est le nombre qui sert à composer d’autres nombres dans une base donnée.
En hexadécimal, le chiffre
Aexprime une unité associée à la valeur numériqueAen base hexadécimale, valeur numérique qui s’écrit10en base décimale (qui est un nombre de même valeur mais qui n’est pas une unité).Pour éviter les erreurs, on peut faire cette analogie :
Mais à la différence des mots où seuls quelques rares mots comme « a » (verbe avoir) sont exprimés avec seule lettre, tous les chiffres seuls expriment un nombre.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Francisation
Posté par BAud (site web personnel) . Évalué à 4.
tu abuses àmha, un chiffre binaire c'est 0 ou 1 : pour quiconque a fait un peu de C ou d'assembleur. Un nombre binaire, si tu connais et que ça te parle, un chiffre binaire, cela devrait être pareil :-) bit comme binary digit demandent une explication et la compréhension préalable (que tu as sans doute oubliée la première fois où tu y as été confronté).
Un peu comme ne pas confondre le baud avec du bit/s ou du o/s, selon la définition de l'information transmise :D (pour le minitel c'était sur 10 bits et non 8 par exemple…).
[^] # Re: Francisation
Posté par Renault (site web personnel) . Évalué à 6.
Je ne suis pas sûr qu'un grep sur le code source avec le terme anglais t'aide beaucoup plus, tu ne rédiges pas un code comme un document technique. Les termes ne se suivent pas toujours !
Puis si ton but est que chaque mot technique correspond à une requête grep, donc ce cas à une époque il fallait rédiger les dépêche en allemand pour LibreOffice, pour la plupart tu peux oublier de traduire le texte en français tant qu'à faire…
Oui pour ne pas franciser tout et n'importe quoi, mais non à l'effet inverse à tout mettre en anglais quand le terme français correspondant est approprié.
[^] # Re: Francisation
Posté par Martin Peres (site web personnel) . Évalué à 10.
Je trouve au contraire que "systèmes monopuce" est une excellente traduction de SoC, c'est presque une relation 1-1.
Cela dit, je comprend ta remarque sur la francisation a outrance. J'ai aussi vécu au Canada. Perso, je n'utilise presque aucun mot que j'utilise dans la dépêche dans la vie de tous les jours car personne d'autre ne les connait, mais c'est ma faute et j'aimerai bien éviter qu'on se retrouve avec une langue ou la moitié des mots sont d'origine étrangère avec une prononciation vraiment différente (Hello Canada!). On est un des rare pays a avoir une seule langue comprise et utilisée en majorité par tout les habitants des pays francophones et si on commence a faire ca, on va encore plus diverger. Il est totalement possible d'avoir plusieurs mots dans différentes langues sans trop s'embrouiller!
Je vis actuellement en Finlande ou une bonne majorité des habitants est bilingue (Finlandais, Anglais) ou trilingue (Finlandais, Suédois et Anglais). Il y a quelques mots importés en Finnois, mais la majorité ne le sont pas (et c'est un bonheur d'apprendre des mots qui n'ont aucune racine grecque ou latine, hmm hmm). Même les ingénieurs a Intel Finlande utilisent très peu l'anglais quand ils parlent entres eux. Alors oui ça donne des mots bien rigolos (PC = tietokone = knowledge-machine) mais au final, y'a plein de mots composés qu'on a qui ne veulent rien dire, surtout chez les animaux :D Tant que le mot est unique, c'est tout ce qui importe.
TL;DR: Pour résumer, on est dans une situation ou il y a de nouveaux mots anglais qu'on ne prend pas le temps de traduire ce qui fait quand une traduction est proposée, c'est limite déjà trop tard. Je n'aime pas les langues ou la moitié des mots viennent d'autres langues (canada et certains pays du Maghreb font ça avec le fr, du moins a l'oral). Ce n'est pas un probleme d'avoir plusieurs mots pour designer la même chose tant que c'est dans une autre langue. Du coup, je pense que le meilleur endroit pour faire connaitre des nouvelles traductions est dans les articles techniques tels que cette dépêche et je suis content qu'on le fasse, même si parfois on oublis de marquer le mot original et si ça fait un poil chier de devoir apprendre de nouveaux mots.
[^] # Re: Francisation
Posté par BAud (site web personnel) . Évalué à 4. Dernière modification le 23 juillet 2015 à 01:03.
j'en ai profité pour rajouter subrepticement (en loussdé quoi) un § https://linuxfr.org/wiki/traductions-classiques#quelques-avis-sur-les-traductions
Vu que ce genre de discussion a émergé sur de précédentes dépêches, je laisse à titre d'exercice à ceux motivés d'en faire ressortir les suggestions pertinentes et les ajouter à la page wiki ;-)
[^] # Re: Francisation
Posté par needs . Évalué à 5.
[^] # Re: Francisation
Posté par Thomas Debesse (site web personnel) . Évalué à 1. Dernière modification le 26 juillet 2015 à 09:19.
Et pourquoi pas conduit ? parce que bitoduc, ça commence malheureusement par bit*, ça rime malheureusement avec trou***, et o est malheureusement homophone avec au, y a plus élégant. :D
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Francisation
Posté par louiz’ (site web personnel) . Évalué à 10.
Et quel est l’intérêt de cacher la moitié de ces mots ?
Si c’est pour protéger la sensibilité du lecteur, tu penses que le lecteur ne va pas les comprendre, du coup le message n’a aucun intérêt car il ne sera pas compris.
Si tu penses que le lecteur va les comprendre, alors autant écrire les mots en entier, le lecteur va les « dire » dans sa tête de toute façon en lisant le message, et ça sera « vulgaire » dans tous les cas.
Donc stop cette auto-censure idiote, et écrivons bite et trouduc en toutes lettres, merci.
[^] # Re: Francisation
Posté par eingousef . Évalué à 1.
je ne sais pas quelle était la nature de ta relation avec cette Line mais je trouve ta traduction un peu vulgaire :o
*splash!*
[^] # Ça tombe bien que tu te proposes de participer, on manque de forces vives.
Posté par esdeem . Évalué à 10. Dernière modification le 16 juillet 2015 à 18:41.
C'est bien beau de râler, mais la majorité du taf a été effectué par une poignée de personnes, dont tu n'étais pas.
Je t'invite dès lors à créer, en commençant ici, le brouillon de la dépêche pour la sortie de Linux 4.2.
La rc-1 date du 5 juillet et le mail de Linux est en attente de traduction.
La rc-2 date de ce week-end et le mail de Linus est également en attente de traduction.
Au passage bien venue dans l'équipe d'édition.
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: Ça tombe bien que tu te proposes de participer, on manque de forces vives.
Posté par robin . Évalué à 3.
Je suis intéressé par le fait de traduire les annonces de rc (je ne sais pas si ça correspond à la catégorie « La phase de test », et si c'est le cas il ne faudrait pas que je marche sur tes plate-bandes :) ). En revanche je n'aurais pas le temps de m'y mettre avant dimanche soir.
bépo powered
[^] # Re: Ça tombe bien que tu te proposes de participer, on manque de forces vives.
Posté par esdeem . Évalué à 3. Dernière modification le 17 juillet 2015 à 00:44.
Oulà ! Ce ne sont pas mes plate-bandes, loin de là (par ailleurs je suis contributeur et non mainteneur). Je préfère de loin relire à traduire. :)
Il n'y a par ailleurs aucun soucis à traduire partiellement en laissant de grosses balises¹ dans le texte histoire que ce soit facile à repérer et qu'un contributeur à l'esprit frais et au regard neuf fasse une seconde passe.
¹ du genre ##[A TRADUIRE : …]##
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: Ça tombe bien que tu te proposes de participer, on manque de forces vives.
Posté par robin . Évalué à 3.
Pas soucis. Mes propositions de traductions ressembleront donc à
##[Orthographe et grammaire à vérifier impérativement et en détail, avec des compresses pour les yeux par ce que ça fait mal quand même]##
traduction: Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec a diam lectus. Sed sit amet ipsum mauris. Maecenas congue ligula ac quam viverra nec consectetur ante hendrerit. Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean ut gravida lorem. Ut turpis felis, pulvinar a semper sed, adipiscing id dolor. Pellentesque auctor nisi id magna consequat sagittis. Curabitur dapibus enim sit amet elit pharetra tincidunt feugiat nisl imperdiet. Ut convallis libero in urna ultrices accumsan. Donec sed odio eros. Donec viverra mi quis quam pulvinar at malesuada arcu rhoncus. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. In rutrum accumsan ultricies. Mauris vitae nisi at sem facilisis semper ac in est.
##[Fin vérification]##
Mais sinon je suis partant pour faire les premiers jets des traductions :)
bépo powered
[^] # Re: Francisation
Posté par ekacnet (site web personnel) . Évalué à 1.
J'abonde dans ton sense (je "plussois"), il y a trop de traduction au mot à mot.
Certaines francisations sont horribles, la carte des périphériques est une mauvaise traduction de device mapper, le terme anglais serait device map.
Je ne pense pas que cartographieur soit une traduction plus appropriée, peut être que le gestionnaire des associations entre périphériques est plus juste.
Le fait est que l'anglais est malheureusement bien mieux adapté pour transmettre un concept en un nombre limité de mots.
[^] # Re: Francisation
Posté par esdeem . Évalué à 2.
La première
traductionadaptation était mappeur de périphériques, ce qui est acceptable, si mapper et mappage sont corrects. Antidote, par exemple, me les propose sans ciller, ajoutant que les deux termes sont liés à l’informatique.Le travail d’édition étant ce qu’il est, un
farceurcontributeur a changé cela en carte de périphériques et c’est resté.0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: Francisation
Posté par Stéphane Aulery (site web personnel) . Évalué à 10.
Je ne suis pas d’accord avec cette généralité. Le latin a un ample vocabulaire juridique et le grec philosophique. Ils sont bien meilleurs dans ces cas de figure.
Nous sommes accoutumés à un vocabulaire informatique anglais parce que le monde anglo-saxon mène la barque en ce domaine. Si les systèmes d’exploitations majeurs étaient développés en France, nous aurions des mots très adaptés aux concepts informatiques élaborés chez nous.
Un aiguilleur ou aiguillage de périphériques ? Il y a moyen de trouver des mots français mais il faut se donner la peine de chercher dans d’autres domaines moins soumis à la pression anglophone. Ça sonne mal au premier abord, mais c’est bien le sens recherché. Question d’habitude à mon avis. Il faut accepter que des mots courants prennent un nouveau sens.
Par exemple de nos jours le sens le plus commun d’écran (Surface [courbe, fond du tube cathodique,] permettant de voir des images [transmises par ondes électromagnétiques]) est inverse au sens original : Objet conçu pour arrêter un rayonnement.
SA
[^] # Re: Francisation
Posté par gnumdk (site web personnel) . Évalué à 5.
Oui mais dans le cas présent, quand je lis "device mapper", je sais de quoi on parle, quand c'est traduit, je ne peux pas faire le rapprochement…
Il faut arrêter les "nazis de la traduction" ;) Que je sache, il est plutôt commun d'utiliser des mots d'autres langues… Il suffit de voir le nombre de mot d'origine française dans la langue anglaise. Et je trouve cela encore plus justifié quand il s'agit de termes techniques.
Par contre, effectivement, quand quelqu'un commence à remplacer des mots courants par leur version anglaise, là c'est gonflant.
[^] # Re: Francisation
Posté par Stéphane Aulery (site web personnel) . Évalué à 4.
Parce que toute la documentation est en anglais et sans ça marche ou crève. L’informatique est cruciale mais la France pour le moment ne fait rien (en apparence ou réellement ?) pour garantir son indépendance dans ce domaine.
Il y a une raison historique majeur à cette influence :
Conquête de l’Angleterre par les Normands et ses conséquences : Influence du français sur l'anglais
SA
[^] # Re: Francisation
Posté par Zenitram (site web personnel) . Évalué à -1. Dernière modification le 17 juillet 2015 à 09:15.
Il y a moyen, oui. Maintenant, la question n'est pas de savoir si il y a moyen, mais si il y a une utilité à le faire.
Les sujets sont nouveaux, il n'y a pas d'historique à gérer, et le monde s'est agrandi (on sort des frontières françaises/francophones), pourquoi donc vouloir tout traduire même les choses qui n'ont pas besoin d'être traduites?
A noter que les anglo-saxons n'ont aucun problème à prendre un mot non anglais quand l'origine du sujet n'est pas anglo-saxone (déjà-vu, entrepreneur, press attaché…). Mais après on se demande pourquoi l'anglais est plus utilisé, préféré? c'est un ensemble de facteurs, pas que l'économie, mais aussi sans doute l'appréciation des mots étrangers pour enrichir sa langue (en plus d'être tolérant aux fautes des étrangers).
Comme tu dis, "se donner la peine". je croyais qu'il y avait un manque de contributeurs! Pourquoi alors faire du travail en plus? Il semble donc que vous avez trop de contributeurs et que du coup vous passez du temps sur se donner la peine de chercher des traductions à des mots qui en n'ont pas besoin.
Perso, je me met maintenant à lire les dépêches sur les noyaux en diagonale, car il est certes intéressant d'avoir des nouvelles dessus, mais les "traductions" (entre parenthèse car la c'est un choix idéologique plus que des traductions, dans le même style que ami.e.s, et avec patch/commit traduit on commence à bien s'y perdre) rendent la lecture difficile (quand on met le nom anglais entre parenthèses, il faut peut-être se demander si traduire bourrinement est pertinent) car il faut du coup qu'on traduise une traduction en décodant (vu que les traductions ne sont pas toujours pertinentes) pour s'y retrouver.
[^] # Re: Francisation
Posté par Dr BG . Évalué à 8.
Pour faire évoluer le français ? On ne peut pas se plaindre que le français n'évolue pas et manque de vocabulaire technique et refuser de créer de nouveaux mots ou faire évoluer le sens d'autres. Même les nouvelles choses développées en France ont maintenant un nom en anglais dès le départ… dans la tête des gens le français est forcément ringard dès le départ donc se ringardise encore plus etc.
Même les mots français commencent à disparaître au profit de l'anglais parce que c'est plus cool : driver, software, hardware, data, device…
[^] # Re: Francisation
Posté par wismerhill . Évalué à 5.
:-)
[^] # Re: Francisation
Posté par Dr BG . Évalué à 4.
C'était fait exprès :-)
« J'aime pas les mots anglo-saxons comme fun, ça fait un peu destroy quelque part ! » Régis Laspalès.
[^] # Re: Francisation
Posté par DerekSagan . Évalué à 2.
À rapprocher de: la traduction de « DMZ » en français, c'est « no man's land ».
Et le pire, c'est que c'est vrai.
[^] # Re: Francisation
Posté par DerekSagan . Évalué à 4.
Ou encore: la traduction de « from scratch » en français, c'est « ex nihilo ».
[^] # Re: Francisation
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
En même temps la traduction de « double entendre » c'est « double sens », celle de « agent provocateur » c'est « provocateur » et celle de « battalion » c'est « bataillon ».
[^] # Re: Francisation
Posté par Renault (site web personnel) . Évalué à 9.
Je dirais que l'avantage de traduire, quand les mots existent et sont répandus, aident à mieux comprendre ce qu'il décrit.
Pour moi un feedback c'est moins clair qu'un retour, un driver c'est moins clair qu'un pilote de périphérique, etc. Les mots français ont l'avantage de facilement être compréhensible par le profane car le mot a souvent été choisi, comme pour l'anglais, en analogie avec d'autres concepts qu'il connait (ce qui est le cas d'un pilote par exemple). Pourquoi faire compliqué inutilement ?
Je ne dis pas que tout doit être traduit à fond, mais quand c'est possible c'est bien aussi. D'autant qu'avec un contenu très technique, tu peux vite aboutir à des phrases ayant plein de mots anglais et le mélange français-anglais n'est pas forcément très élégant, surtout en prononciation. Quand c'est un mot de temps en temps ça passe sans soucis.
Le but est d'avoir un équilibre, je pense que limiter l'usage de mots anglais est bénéfique pour la compréhension et l'élégance du texte. Mais on ne doit pas interdire son usage, juste privilégier la traduction quand elle existe, est claire et connue.
[^] # Re: Francisation
Posté par akh2020 . Évalué à 10.
Je suis d'accord avec toi. J'ajouterais même qu'une langue qui laisse la création de mot aux autres langues, je crois que ça s'appelle une langue morte.
Je ne comprends pas non plus pourquoi le français sonne si mal parfois. Je pense que le côté ringard dont tu parles doit produire bien souvent le même effet pour une personne ayant l'anglais comme langue maternelle. Non ? Du coup, je me dis que c'est peut-être simplement nous qui avons assimilé les mots directement dans leur sens technique, sans faire le rapprochement avec les analogies dont parle Renault (bug, spam, etc).
[^] # Re: Francisation
Posté par ariasuni . Évalué à 3.
Même si je ne suis pas d’accord avec toutes les traductions de la dépêche, il y a à mon avis trop de termes anglais en français dans certains domaines quand on comprends aussi bien en français, ou quand la traduction en français a du sens. D’autre part on ne peut pas vraiment comparer avec l’anglais qui a intégré peu de mots français récemment, les autres sont beaucoup plus vieux et relativement bien intégrés à la langue.
Un exemple d’adaptation de l’anglais réussie selon moi c’est celle de parse. Parseur et parsage ont un sens (beaucoup plus court et compréhensible qu’analyse(ur) syntaxique), au contraire parser et parsing sont bof. Dans d’autres cas, des équivalents français sont plus clairs, tels que bibliothèque plutôt que library, noyau plutôt que kernel ou modification plutôt que patch (bien que mon avis ne soit pas franchement tranché pour ce dernier, j’ai longtemps vu ce terme comme un truc obscur). En tant que francophone, certains termes sont plus compréhensibles en français, c’est logique.
Dans le monde francophone on aime pas forcément trop ça, au Japon ça se fait beaucoup (et franchement j’aime pas ça). Tu parles de choix idéologique, mais utiliser le mot anglais est aussi un choix; c’est certes le plus facile, le plus évident. Ne «rien faire» ne veut pas ne pas prendre parti.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Francisation
Posté par Romain Perier . Évalué à 2.
Je suis assez d'accord, et j'ai tendance à le reprocher depuis le début (moi même modérateur de l'une de ces sections). Ca ne rajoute pas necessairement de la pertinence et ça a des fois aucun sens de traduire certains termes techniques…. quand on parle de commit ou de merge par exemple… on va parler de "changements" et de "fusion" ? et les rebase alors ? Le plus drôle c'est les "shortlog" je crois… :D
Oui c'est utile de faire un minimum d'effort de traductions, car on est en france, on parle français, mais il faut que ça reste dans la mesure du raisonnable et que ça ait du sens… des fois ça fait saigner les yeux. Concernant le quatre coeurs ARM Cortex-A53, c'est une erreur de ma part. Merci pour l'info.
Quelqu'un pourrait faire la modif svp ?
# Snap 410
Posté par MTux . Évalué à 3.
Bizarre… Cela fait longtemps que des smartphones avec du Snap410 fonctionnant sous Android sont commercialisés. Cela veut dire qu'ils tournaient sur un kernel fait maison, avec le support de l'architecture directement implémenté directement par le constructeur ?
[^] # Re: Snap 410
Posté par Ph Husson (site web personnel) . Évalué à 4.
Ils tournaient avec des kernel fait par Qualcomm (kernel dispo sur leur page opensource, https://www.codeaurora.org), potentiellement légèrement modifié par le constructeur
Et ça va durer, même maintenant que Linux 4.1 est sorti, vu que les kernel Android ont toujours 3 ans de retard.
[^] # Re: Snap 410
Posté par Renault (site web personnel) . Évalué à 4.
Notons que c'est souvent le cas d'un fabriquant de SoC ou de puce, ils vont produire un support pour Linux (ou d'un autre OS, suivant la cible) avec une version maison patchée qu'ils supportent. Potentiellement certaines applications sont également adaptées. Ils appellent ça un BSP.
Très souvent ils le distribuent avec la vente des puces, avec des NDA dans tous les sens parfois. Si tu as de la chance, le constructeur va pousser ses modifications au projet officiel. Mais c'est rarement complet (le support des SoC de Texas Instrument dans le Linux officiel a été fait par TI lui même, mais la moitié des trucs sont passés à la trappe).
Il faut dire que les concepteurs de SoC n'exploitent pas toujours l'API du noyau et font un truc à leur sauce dans leurs coins de manière assez sale. Cela fonctionne mais du coup ça reste souvent en dehors du noyau officiel.
[^] # Re: Snap 410
Posté par Ph Husson (site web personnel) . Évalué à 2.
Ouaip, mais globalement ça va en s'améliorant.
Tous les constructeurs de puces (même les chinois, Mediatek, Rockchip, Allwinner du moins) se mettent à pousser des morceaux dans Linux, et Qualcomm (le constructeur Android "historique") se met au vert, en avançant sur l'usage d'API standard (genre leur driver 3D utilise DRM maintenant, ils ont l'API standard de GPIO et clocks, ils utilisent les device-tree, …).
[^] # Re: Snap 410
Posté par Renault (site web personnel) . Évalué à 2.
Ça progresse, mais l'inertie du secteur va rendre cela encore long pour en tirer les bénéfices. :)
Il y avait justement un sondage pour le Linux embarqué, si les gens qui développaient des solutions comme ça utilisait le noyau officiel récent. La majorité disait que non, et l'une des raisons majoritaires est bien le support des pilotes pour des versions précises, souvent anciennes.
[^] # Re: Snap 410
Posté par mripard . Évalué à 3.
C'est faux dans le cas d'Allwinner. C'est une communauté de développeurs volontaires qui pousse ces patches, contrairement à Mediatek ou Rockchip qui s'occupent de ça eux même.
[^] # Re: Snap 410
Posté par benoar . Évalué à 4.
Merci pour cette précision. Est-ce que je pourrais te demander ce qui pousse Free Electrons, en plus de la communauté, à pousser les patchs pour Allwinner ? Je me suis toujours demandé si vous aviez peut-être un contrat avec eux, ou alors si c'était « pour la renommée », ou autre chose.
[^] # Re: Snap 410
Posté par mripard . Évalué à 2.
Ni l'un ni l'autre. Jusqu'à récemment, c'était juste du boulot perso sur le temps libre. Depuis pas longtemps, on a un client qui nous fait bosser dessus, mais ça date de quelques semaines, donc y a pas vraiment eu d'effets visibles encore.
[^] # Re: Snap 410
Posté par Albert_ . Évalué à 2.
Et toute cette sauce cela respecte les licenses?
[^] # Re: Snap 410
Posté par Renault (site web personnel) . Évalué à 3.
Globalement oui, mais comme les patchs sont moches, gros et pas toujours bien intégrés à l'existant, bonjour pour faire l'intégration à la version officielle. Sans volonté du constructeur, cela reste un exercice difficile.
# chiffrement avec ext4
Posté par Anonyme . Évalué à 5.
Comment qu’on fait ?
[^] # Re: chiffrement avec ext4
Posté par Anonyme . Évalué à -3.
en général il y a tous ce qu'il faut dans /usr/src/linux-4.1.XXXX/doc, bon ca t'aide pas des masses mais c'est un bon début. Trés utile en cas de manque d'internet, en tout cas.
après si tu veux VRAIMENT savoir comment on fait et que tu aime le sport -> ext4.c est très bien commenté et tu auras toutes les options que tu veux.
d'après mon doigt mouillé, il faudra probablement une nouvelle version de mount et un petit coup de echo 1 dans /proc
[^] # Re: chiffrement avec ext4
Posté par BAud (site web personnel) . Évalué à 1.
LWN a un article : https://lwn.net/Articles/639427/ publié en avril 2015 (et indiqué dans la dépêche), il y a la doc' de conception de Michael Halcrow en lien à la fin.
[^] # Re: chiffrement avec ext4
Posté par dastious . Évalué à 3.
Merci la bible Arch : https://wiki.archlinux.org/index.php/Ext4#Using_ext4_per_directory_encryption
# Bof Bof
Posté par walker17x . Évalué à -10.
Bon je suis un débutant et je ne prétend pas étre un expert , mais j'utilise linux depuis ubuntu 14.04 avec linux 3.13 et depuis je suis maintenant avec arch et le kernel 4.1 mais je n'ai pas remarqué le moindre changement au niveau de l'utilisateur , pas le moindre , c'est vraiment la meme chose.
[^] # Re: Bof Bof
Posté par kowalsky . Évalué à 10.
ce qui peut t’intéresser un peu plus, c'est les changements dans GNOME, KDE ou je ne sais ce qu'utilise Ubuntu.
En tant qu'utilisateur final, tu n’interagis avec le noyau qu'à travers des interfaces (graphique ou shell).
[^] # Re: Bof Bof
Posté par Martin Peres (site web personnel) . Évalué à 10.
La majorité du code du noyau est due aux pilotes. De ce coté la, tu peux attendre une meilleure gestion du matériel existant, meilleures performances, moins de bugs.
De temps en temps, il y a de nouvelles interfaces qui apparaissent et qui, quelques mois plus tard, sont utilisées par des programmes que tu utilises. Sans le savoir, tu vas probablement donner tout le mérite au développeur de cette application, alors que c'est un travail partagé! Par exemple, les namespaces permettent a systemd beaucoup de choses telles que rendre certains dossiers inaccessibles a certains services (sans avoir a changer les droits). Une autre est la gestion atomique du mode graphique qui va permettre aux compositeurs Wayland d'utiliser les plans graphiques matériels pour faire la conversion d'espace colorimétrique de façon transparente ce qui va permettre de réduire la consommation électrique!
Au final, le noyau n'est pas sensé être visible donc ce n'est pas étonnant que tu ne te rendes pas compte des changements!
[^] # Re: Bof Bof
Posté par gnumdk (site web personnel) . Évalué à 10.
Pourtant moi j'ai vu un changement, du temps du noyau 2.2, j'avais régulièrement des "kernel panic", aujourd'hui, c'est très très rare… Et quand ça arrive, je soupçonne directement la matériel :)
[^] # Re: Bof Bof
Posté par xcomcmdr . Évalué à 2.
Oui bon si on va par là, évidemment moi aussi du temps du noyau 0.9 j'avais du mal…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Bof Bof
Posté par Chris K. . Évalué à 3.
A part au démarrage après une mauvaise config, patch hasardeux ou un problème matériel je n'en ai jamais rencontré de vrai (en pleine utilisation) pour ma part. Même à l'époque du 2.2 la stabilité a toujours été un des gros points forts. Tu aurais peut être déjà dû soupçonner le matériel à l'époque :D.
il y a de vrais gros changements très visibles pour peut qu'on utilise la fonctionnalité au niveau des programmes en espace utilisateur. Par exemple le passage d'ipchains vers iptables a été assez violent pour moi ^^.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bof Bof
Posté par antistress (site web personnel) . Évalué à 10.
À ce sujet, une distribution GNU/Linux est-elle à présent capable de travailler en YUV sans faire de conversion préalable en RGB très exigeante en ressources matérielles comme c'était le cas jusqu'à récemment ?
Je pense au travail fait sur DRI2 et DRI3 pour prendre en charge le YUV directement (1), et permettre à libva (VA-API) et à un compositeur Wayland d'en tirer profit (2), tout comme à GStreamer (3) ?
L'idée serait que par exemple la lecture de vidéos sous Firefox ou que le montage vidéo sous Pitivi soit moins gourmand (et d'avoir une expérience fluide même sans accélération matérielle)
Sais tu où en est la pile graphique libre sur ce point ?
(1) http://www.x.org/wiki/Events/XDC2012/Proceedings/
(2) http://www.phoronix.com/scan.php?page=news_item&px=MTA4OTg
(3) http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2012/omap-dmabuf-gstcon2012.pdf
Merci d'avance :)
[^] # Re: Bof Bof
Posté par Martin Peres (site web personnel) . Évalué à 7.
Si tu n'as pas d'acceleration matérielle, alors ca n'a aucun intérêt que X ou un compositeur wayland gère le YUV car il va devoir faire la conversion lui même en utilisant le CPU! Le seul but de garder le format original dans le conpositeur, c'est de pouvoir utiliser les plans graphiques pour faire la transformation colorimétrique en matériel ou, au pire, avec des shaders.
X supporte depuis des années de faire passer des images en YUV, via XV. Pitivi peut utiliser ca! Pas besoin de DRI2/3. D'ailleurs, je ne me souviens pas que DRI3 supporte de multiples formats, mais c'est possible.
Concernant Wayland, y'a encore pas mal de problèmes a résoudre mais les plans graphiques universels aident beaucoup pour exposer de façon uniforme entre les pilotes ces plans. C'est pas encore parfait car les informations de format sont pas assez évolués pour vraiment exploiter au max le matériel (compression et options de pavage)! On y travaille mais faudrait déjà que Wayland s'impose pour que nos employeurs nous laisse y bosser plus :p On y arrive!
[^] # Re: Bof Bof
Posté par xcomcmdr . Évalué à 4.
J'ai pris KDE en partie parce qu'ils suivent de près Wayland. ^
J'ai hâte que KWin y passe !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Bof Bof
Posté par cedric . Évalué à 4.
Ca dépend ! Si tu utilises un compositeur, je suis près à parier qu'il recompose la surface yuv dans le buffer écran. Le seul cas à peu près gérer, c'est le cas plein écran et encore il y a pas mal de driver qui ont des problèmes…
Et comme dit Martin, pour wayland, il y a encore beaucoup de boulot pour tout le monde ! Du kernel aux applications, il y a plein de chose a juste faire marcher. On en est pas encore aux optimisations. Même si l'architecture de wayland devrait rendre les choses plus facile. Peut être dans le courant de l'année prochaine…
[^] # Re: Bof Bof
Posté par laviestbelle . Évalué à 2.
Martin c'est une super nouvelle que tu m'apprends là, juste aurai tu une idée de l'ordre de grandeur du gain d'autonomie que cette amélioration pourrais engendrer ? :)
[^] # Re: Bof Bof
Posté par Martin Peres (site web personnel) . Évalué à 5.
Dur a dire. Ca depend de trop de facteurs. Mais ca devrait etre visible!
Tu peux voir un exemple de difference de performance dans un cas extreme, le rasp pi: https://fooishbar.org/tell-me-about/wayland-on-raspberry-pi/
# gcc 6?
Posté par Marc (site web personnel) . Évalué à 2.
C'est pas plutôt gcc 5 dont il s'agit ici ? La version 6 (prochaine version majeur) est en cours de dev depuis très peu de temps.
[^] # Re: gcc 6?
Posté par Renault (site web personnel) . Évalué à 8.
Non justement.
GCC et Linux collaborent souvent en avance de phase pour que Linux puisse bénéficier de ces avancées le plus tôt possible. Et cela permet souvent à GCC d'avoir du retour de bogues.
On peut compiler Linux avec GCC 5.1 depuis un paquet de temps maintenant.
[^] # Re: gcc 6?
Posté par Marc (site web personnel) . Évalué à 5.
Ok, merci pour la précision :). En l'état, ça donne l'impression que le support de GCC 6 est bouclé alors qu'en réalité, c'est une tâche en cours ("Support des prochaines version de GCC" aurait été plus clair par exemple).
# On veut zfs !!!
Posté par zaurus (site web personnel) . Évalué à 2.
;-)
[^] # Re: On veut zfs !!!
Posté par claudex . Évalué à 6.
C'est sur oraclefr.org qu'il faut poster ça.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.