La sortie de la version stable 4.8 du noyau Linux a été annoncée le 2 octobre 2016 par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site kernel.org.
Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche (qui est sous licence CC BY-SA).
Sommaire
- Annonces des RC par Linus Torvalds
- Les nouveautés
- Appel à volontaires
Annonces des RC par Linus Torvalds
RC-1
La version RC-1 est sortie le dimanche 7 août 2016 :
Deux semaines se sont écoulées et la fenêtre de fusion de la version 4.8 est donc maintenant fermée.
À cause de mon voyage de la semaine dernière, j’ai encore quelques demandes d’intégration en attente que je voudrais regarder de plus près auparavant, mais j’ai traité la majeure partie des demandes et je voulais être certain de ne pas en recevoir de nouvelles.
Ça semble devenir l’une des plus grosses versions de ces derniers temps, mais attendons de voir comment ça se termine. La fenêtre d’intégration a été plutôt normale, bien que le correctif en lui‐même ait l’air plutôt inhabituel : plus de 20 % concerne des mises à jour de documentation, dues à la conversion de la documentation DRM et media depuis Docbook vers le format Sphinx. Il y a d’autres mises à jour de documentation, mais c’est le plus gros morceau.
Si l’on met de côté le changement de format de documentation, tout semble plutôt normal, avec environ 60 % des modifications non relatives à la documentation sur des pilotes (pilotes graphiques, réseau, média, son, etc.) et environ 15 % sur des mises à jour d’architectures (ARM, POWER et x86 dominant, mais il y a aussi du MIPS et du S/390).
Le reste est réparti : cœur de réseau, outillage (essentiellement perf), incluant les fichiers, le cœur du noyau, VFS et les systèmes de fichiers bas niveau (XFS exclus). Quelques zones épargnées :
10 787 fichiers modifiés, 612 208 insertions(+), 272 098 suppressions(-)
En avant, testez. Les modifications et les journaux sont trop gros pour être postés, donc comme d’habitude pour une RC-1, j’ajoute seulement mon « journal d’intégration » pour une vue d’ensemble.
Linus
RC-2
La version RC-2 est sortie le dimanche 14 août 2016 :
Voici une semaine que la fenêtre d’intégration est fermée, et la version RC-2 est sortie. Testez‐la.
Les statistiques de modifications de la RC-2 semblent inhabituelles, du fait qu’un sixième concerne les pilotes (normalement les pilotes représentent environ la moitié de l’ensemble des mises à jour). Au lieu de quoi, ce sont les mises à jour d’architectures qui dominent, ainsi que
fs/etmm/. Mais ce n’est probablement que parce que les plus gros changements de pilotes n’ont pas commencé à arriver — la RC-2 a tendance à être une période calme après la folie de la fenêtre d’intégration.Et la raison pour laquelle
mm/se distingue est principalement à cause d’une demande supplémentaire pendant la fenêtre d’intégration que j’ai repoussée après la RC-1, afin de pouvoir regarder ça plus attentivement.Donc, je m’attends à ce qu’on revienne à la normale la semaine prochaine.
Rien de bien étrange ne semble être en cours ; donc, s’il vous plaît, allez la tester et rapportez tous les problèmes que vous rencontrerez. Évidemment, on est encore au début de la série de RC, mais je pense qu’il n’y avait rien de vraiment inquiétant durant cette fenêtre d’intégration, alors ne soyez pas timides.
Linus
RC-3
La version RC-3 est sortie le dimanche 21 août 2016 :
Après la semaine dernière caractérisée par des statistiques de modifications inhabituelles (seulement un sixième pour les pilotes), nous ne sommes toujours pas revenus à la normale avec la RC-3 et nous sommes dans la situation habituelle avec grosso modo 60 % des correctifs portant sur les mises à jour de pilotes. Cela s’étend encore, mais la plupart semblent tendre vers le réseau, les pilotes graphiques et le nouveau pilote EDAC. Mais tout ça est encore bien petit.
En dehors du département des pilotes, on a du réseau, quelques mises à jour de systèmes de fichiers (principalement XFS, bien que dans les statistiques de changement AFS soit également visible, mais surtout pour des changements liés au réseau) et une touche de mises à jour un peu éparpillées : documentation, planificateur, quelques modifications mineures d’architectures, etc.
Et quelques corrections sur les outils de perf.
Tout ça semble plutôt sain, je ne vois rien de très effrayant ici. Allez tester ça.
Linus
RC-4
La version RC-4 est sortie le dimanche 28 août 2016 :
Nouvelle semaine, nouvelle RC.
Tout semble normal et cela a été aussi un peu plus calme que la RC-3, donc espérons que nous sommes bien dans la phase « ça se calme ». Bien qu’avec les habituelles fluctuations relatives aux contraintes de temps (différents mainteneurs étalent leurs requêtes d’intégration différemment), il est difficile de déjà annoncer une tendance.
En tout cas, tout ça semble plutôt petit. Je pense que le plus gros truc ici est une correction sur la gestion d’énergie pour Skylake ajoutée comme une partie de la mise à jour du pilote graphique, juste avant que je n’envisage de couper la version RC-4. Tant pis. L’autre changement plutôt imposant est un lot de corrections Btrfs.
Mais dans l’ensemble tout ça ne semble pas effrayant et le reste est vraiment plein de mignonnes petites corrections éparses : divers pilotes de sous‐systèmes (son, RDMA, bloc), KVM et autres mises à jour d’architectures.
Voir l’habituel journal résumé ci‐dessous pour les détails — il est petit et facile à parcourir pour sentir le goût des trucs qui se sont passés.
En avant, testez.
Linus
RC-5
La version RC-5 est sortie le dimanche 4 septembre 2016 :
Donc, la RC-5 est sensiblement plus grosse que ne l’était la RC-4, et mon sentiment de la semaine dernière que nous commencions à nous calmer semble avoir été prématuré.
Cela dit, la plupart des
diffstatssemblent plutôt plats (ce qui implique plein de petits changements triviaux plutôt que des gros invasifs). Il y a du boulot dans le pilote réseau Mellanox mlx5 et il y a du bruit côté NFS et OverlayFS, mais dans l’ensemble c’est juste un tas de petites corrections. C’est sans doute un peu plus de petites corrections que ce que je préfère voir à ce stade, mais je suspecte que la RC-4 semblait si bien et si petite parce que de nombreuses corrections avaient été reportées à la RC-5.Non pas que tout ça semble inquiétant en tant que tel, mais si les choses ne commencent pas à se calmer maintenant, ça va finir par être une de ces versions qui ont besoin d’une RC-8. On verra.
Cela dit, quand on regarde individuellement les statistiques de chaque commit, tout ça semble petit et simple, c’est juste qu’il y en a plus que je ne l’aurais souhaité.
Le journal résumé est joint pour ceux qui veulent se faire une idée des trucs qui se sont produits.
Linus
RC-6
La version RC-6 est sortie le dimanche 11 septembre 2016 :
Les choses se sont calmées et tout semble très normal. Environ deux tiers de mises à jour de pilotes, la moitié du reste concernant des mises à jour d’architectures, et la seconde moitié des trucs divers (corrections de bogues liés à
fs/crypto, etc.).Évidemment, quelques minutes après la sortie, David m’a envoyé la demande d’intégration pour le réseau, c’est peut‐être la raison pour laquelle la RC-6 semble plutôt petite. Tant pis. Je n’ai pas encore décidé si nous allions ou non faire une RC-8, mais je ne crois pas que je doive le faire maintenant. Rien ne semble particulièrement mauvais, et ça dépendra de ce que donnera la RC-7.
Le journal résumé est joint — il est assez petit pour qu’on puisse le parcourir et avoir une idée de ce qui se passe.
Linus.
RC-7
La version RC-7 est sortie le dimanche 18 septembre 2016 :
Nouvelle semaine, nouvelle RC.
Normalement la RC-7 est la dernière de la série avant la version finale, mais maintenant je suis pratiquement sûr que ça va être une de ces versions qui viennent avec une RC-8. Les choses ne se sont pas calmées autant que je l’aurais aimé, il y a encore quelques discussions en cours. Et il est improbable que je trouve que tout va bien et que nous sommes prêts pour une 4.8 finale dimanche prochain.
Ceci dit, il n’y a rien de « gros » en cours, il y a juste plus de bruit que ce que je voudrais. Une partie de la RC-7 est, bien sûr, composée de corrections réseau qui ont manqué la RC-6 de quelques minutes, mais il y a aussi d’autres mises à jour de pilotes divers (RDMA, NVMe et quelques corrections PCMCIA — eh oui, ce n’est pas encore mort). Et un bon nombre de petites corrections d’architectures (les corrections uaccess d’Al sont sorties, mais il y a aussi quelques corrections de perf, de KVM et d’autres choses variées en cours également).
Le journal résumé n’est pas aussi court que je l’aimerais, mais il est joint et il n’est pas vraiment gros non plus — vous pouvez facilement le parcourir pour avoir une rapide idée des détails.
Une autre chose qui me fait dire « tant qu’on y est, faisons une RC-8 » est qu’il ne semble pas que linux-next soit si gros que ça, donc je n’ai pas l’impression d’une quelconque pression pour ouvrir la fenêtre d’intégration. Il y a bien quelques fonctionnalités qui semblent être planifiées pour une intégration dans la 4.9 et que j’attends, mais une semaine de plus ne nuira pas.
Bien sûr, peut‐être que les choses iront si merveilleusement bien la semaine à venir que je vais décider que la 4.8 est prête. Il n’y a vraiment rien de particulier qui m’inquiète, mais voir ces corrections de corrections la semaine dernière me fait juste dire « Eh, des trucs sont encore en cours. »
Mais s’il vous plaît, allez‐y, testez.
Linus
RC-8
La version RC-8 est sortie le dimanche 25 septembre 2016 :
Donc, comme déjà évoqué la semaine dernière (et envisagé comme une possibilité), voici la RC-8. Les choses ont en fait commencé à se calmer cette semaine, mais je n’ai pas trouvé inutile de faire une dernière RC, donc nous y voici. Je pense que la version 4.8 sera finalisée pour le week‐end prochain, sauf si quelque chose de vraiment inattendu se produit.
Il y a quelques entrées éparses dans la liste de régression de Thorsten, mais rien qui me guide vers « on doit suspendre la 4.8 ». Et les choses ont été vraiment calmes, avec juste quelques corrections ici ou là. Regardez le journal résumé ci‐après, mais c’est vraiment plein de petites choses : essentiellement des pilotes, avec un peu d’architectures et de crypto, et des petites corrections de MM et de systèmes de fichiers. Et une tripotée de réseau.
Linus
Version finale
La version finale est sortie le dimanche 2 octobre 2016 :
Cette dernière semaine était plutôt calme, ce qui me fait penser que j’aurais peut‐être dû finalement ignorer la RC-8.
Peu importe, aucun mal n’a été fait.Ceci veut dire que la fenêtre de fusion pour le 4.9 est ouverte et j’apprécie les personnes qui m’ont déjà envoyé des demande d’intégration en avance pour des raisons de voyages ou autre.
Je commencerais à les fusionner dès demain et on aura sûrement les développeurs les plus aguerris qui testeront la version 4.8 avant que la prochaine phase de développement ne commence. ;)Enfin, il y a quelques corrections d’importance mineure listées ci‐dessous : c’est un mélange de corrections d’architectures (ARM, MIPS, SPARC, x86), pilotes (réseau, nvdimm, graphique) et de code générique (aussi du réseau, un peu de systèmes de fichiers, cgroup et de gestion de machines virtuelles).
Finalement, c’est assez petit et il n’y en a pas beaucoup.
Allez le tester maintenant,Linus
Version 4.8.1
La version corrective 4.8.1, sortie le 7 octobre 2016 :
Je suis désolé d’avoir fusionné cette dernière série de correctifs d’Andrew juste avant de faire la version 4.8, parce qu’ils provoquent des problèmes et qu’ils sont maintenant dans le 4.8 (et que cette merde boguée est marquée pour la version stable aussi).
En particulier, j’ai eu droit a :
kernel BUG at ./include/linux/swap.h:276
Et le résultat final était un noyau mort.
L’erreur que le changement 22f2ac51b6d64 (« mm: workingset: fix crash in shadow node shrinker caused by replace_page_cache_page() ») avait pour but de corriger était apparemment présente depuis la version 3.15, mais la correction est clairement pire que l’erreur qui aurait dû être corrigée, car l’erreur originale n’a jamais tué ma machine !
J’aurais dû réagir à cet ajout de lignes contenant un BUG_ON(). Je suppose que j’aurais dû enlever ce stupide concept de BUG_ON() une fois pour toute, car il n’y a PAS DE P*TAIN D’EXCUSE pour consciemment tuer le noyau.
Pourquoi diable n’était‐ce pas un avertissement ?
Oui, je suis grognon. Ceci est arrivé très tard dans le cycle de publications et je m’attendais à bien mieux de la part d’Andrew. Ajouter n’importe où des BUG_ON() dans du code qui n’a pas vraiment été assez testé n’est pas acceptable. Et ce n’était clairement pas acceptable de me l’envoyer après la RC-8 sans que ce ne soit abondamment testé, ce qui n’a manifestement pas été le cas en l’occurrence. J’ajoute stable en copie ici pour les prévenir.
Linus
Les nouveautés
Prise en charge des plates‐formes
ARM/ARM64
ACPI
- ARM64 : prise en charge de NUMA via ACPI ;
- ARM64 : maintenant que l’ACPI supporte le mode « idle » LPI (Low Power Idle), activation du mode ACPI_PROCESSOR_IDLE ;
- ARM64 : prise en charge des bus PCI via ACPI.
Xen
- ARM : décrit comment utiliser l’ACPI de Xen sur des plates‐formes virtuelles ARM64.
Divers ARM64
- prise en charge de kexec ;
- implémentation d’une fonction de contrôle d’intégrité (checksum) IP optimisée pour ARM64 ;
- prise en charge de la compilation avec kcov.
Broadcom
- prise en charge du système monopuce BCM23550 avec SMP ;
- prise en charge initiale pour le Raspberry Pi 3 à base de bcm2835 ;
- prise en charge de la carte BCM953012ER à base de BCM5301x ;
- prise en charge du SoC bcm958625hr de la série NSP.
Qualcomm
Prise en charge de la carte Dragonboard avec le système monopuce Qualcomm APQ8060.
Atmel
- prise en charge de la carte Olimex SAM9-L9260 ;
- prise en charge de la carte at91sam9260ek via l’arborescence matérielle (Device Tree).
Freescale/NXP/(Qualcomm ?)
- prise en charge de la carte Auvidea H100 à base de systèmes monopuces i.MX 6 ;
- prise en charge de la carte Utilite Pro à base de systèmes monopuces i.MX 6s ;
- prise en charge de la carte Toradex Colibri à base de systèmes monopuces i.MX 7S/iMX 7D ;
- prise en charge de Creative X-Fi3 ;
- prise en charge de SanDisk Sansa Fuze+.
Allwinner
- prise en charge de la carte Bananapi M1 Plus (systèmes monopuces sun7i) ;
- prise en charge de Sinovoip BPI-M2+ (systèmes monopuces sun8i-h3) ;
- prise en charge de la tablette Polaroid MID2407PXE03 (systèmes monopuces sun8i) ;
- prise en charge de la carte inet86dz (systèmes monopuces sun8i).
Renesas
- ARM : prise en charge initiale du système monopuce R8A7792 ;
- ARM : prise en charge de la carte « blanche » avec le système monopuce R8A7792 ;
- ARM64 : prise en charge du système monopuce Renesas R8A7796 ;
- ARM64 : prise en charge de la carte Salvator-X avec le système monopuce R8A7796.
Divers
- ARM : prise en charge de la carte de développement Cirrus Logic EDB7211 (système monopuce CLPS711X) ;
- ARM : début de prise en charge de la carte Odroid XU (système monopuce Samsung Exynos) ;
- ARM64 : prise en charge du système monopuce LG Electronics lg1313 ;
- ARM64 : prise en charge du système monopuce Mediatek MT6755 ;
- ARM : prise en charge initiale du système monopuce HiSilicon Hi3519.
MIPS
Prise en charge de l’ajout à chaud de processeurs de type MIPS R6.
Pilotes graphiques libres
AMDGPU
Un ajout notable en ce qui concerne le pilote AMDGPU est la possibilité de surcadencer son processeur graphique grâce à la prise en charge d’OverDrive. Une fonctionnalité qui ravira joueurs et mineurs de tout poil.
La méthode n’est pour le moment pas très conviviale, car elle consiste à modifier la valeur de certains fichiers en ligne de commande.
Dans le détail, on a typiquement le fichier /sys/class/drm/card0/device/pp_sclk_od pour la gestion de la fréquence du processeur graphique et le fichier /sys/class/drm/card0/device/pp_mclk_od pour la mémoire. Les valeurs possibles vont de 0 à 20 par palier de 1 et représentent le pourcentage d’augmentation de la fréquence.
Nouveau
Début de prise en charge des processeurs graphiques GP100 et GP104.
Réseau
Wireless (802.11)
Les Beacon frames sont des trames de gestion du Wi‐Fi, leur gestion a été améliorée.
Il y a maintenant la prise en charge de MU-MIMO air sniffer. Les opérations privilégiées de Netlink sont maintenant gérées depuis les espaces de noms (comme les conteneurs LXC, Docker, VServer).
Une meilleure gestion interne des files d’attente logicielles via FQ/codel est introduite.
IPv6
Gestion du 6LoWPAN pour l’IPv6 en réseau personnel. Meilleure gestion de l’ICMP pour les tunnels GRE en IPv6.
Multi Protocol Label Switching (MPLS)
Permet une gestion interne des routes plus efficace, elle propose l’IP sur IP, IP via tunnel GRE.
Bluetooth
Amélioration des diagnostics pour l’authentification.
NFC
Gestion de l’attente des temps de réponse.
infiniBand
Ajout de l’émulation RDMA sur Ethernet. Gestion du pilotage de flux pour IPv6.
BATMAN
Le protocole de réseau maillé BATMAN a reçu son lot d’améliorations (multidiffusion, débogage…).
Systèmes de fichiers
ext4
Les codes de chiffrement ne sont plus spécifiques, ils ont été unifiés et mis en commun avec F2FS, cela permettra une meilleure maintenance.
Blocs
Diverses corrections au niveau de la gestion des blocs, cela va de l’ordonnanceur, à la gestion du bogue de l’année 2038.
Pas mal de changements côté NVMe (qui permet une bien meilleure exploitation des SSD qu’AHCI) et particulièrement NVMeF, correction dans Bcache (qui permet de fusionner un disque dur et un SSD en un disque hybride).
F2FS
Le système de fichiers a moins de pression sur les verrous, ce qui permet une meilleure montée en charge, des optimisations sur les écritures et diverses corrections.
NFS
Un problème de performance dans le NFS a été trouvé et corrigé, une mise en cache plus agressive et davantage de code optimisé, permettent d’optimiser le client NFS.
OrangeFS
La mise en cache côté noyau permet d’optimiser OrangeFS, en améliorant les latences, augmentant le débit et soulageant le réseau.
XFS
Le Reverse-Mapping a été inclus, cela permet de suivre le propriétaire d’un bloc. C’est le premier pas pour l’avancement sur un certain nombre de futures fonctionnalités (reflink, copy-on-write data, dedupe, online metadata et data scrubbing) et une bien meilleure gestion de la récupération des données pour un système de fichiers endommagé ou corrompu.
Btrfs
En plus des habituelles corrections de bogues, pour ce noyau nous avons droit à une réécriture complète de la vérification de l’espace libre, qui était en gestation depuis des mois. Cela diminue fortement les latences et maximise le débit.
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 | |
| Arch | Aucun | |
| Développeurs | Aucun | |
| Pilotes graphiques libres | Aucun | |
| Réseau | Aucun | |
| Systèmes de fichiers | Aucun | Herman Brule |
| Sécurité | Aucun | |
| Virtualisation | Xavier Claude | |
| Édition générale | Aucun | Martin Peres, yPhil |
Un peu de vocabulaire :
- le mainteneur d’une section de la dépêche est responsable de l’organisation et du contenu de sa partie, il s’engage également à l’être dans le temps jusqu’à ce qu’il accepte de se faire remplacer ;
- un contributeur est une personne qui a participé à la rédaction d’une partie d’une section de la dépêche, sans aucune forme d’engagement pour le futur.
Malgré cette équipe importante, beaucoup de modifications n’ont pas pu être expliquées par manque de temps et de volontaires.
Nous sommes particulièrement à la recherche de mainteneurs pour les sections Systèmes de fichiers 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. Essayons d’augmenter la couverture sur les modifications du noyau !
# Disque mou ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10. Dernière modification le 16 décembre 2016 à 10:24.
Des périphériques à l'état solide, des SSD quoi, qui ne sont justement pas des disques !
(Au passage, je n'ai jamais compris d'où sortait ce nom étrange de « périphérique à l'état solide », comme si les vénérables disques durs étaient à l'état liquide ou gazeux : personnellement, je préfère parler de périphérique de stockage flash.)
[^] # Re: Disque mou ?
Posté par windu.2b . Évalué à 2.
Existe-t-il des semi-conducteurs dans un état autre que solide ?
[^] # Re: Disque mou ?
Posté par Renault (site web personnel) . Évalué à 3.
Non.
Je pense que le but de la manœuvre est d'opposer la sauvegarde de l'information par une charge électrique dans un composant solide par rapport à une sauvegarde magnétique qui est dans un champs immatériel.
[^] # Re: Disque mou ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Mmh, dans les deux cas, on manipule et on mesure des champs immatériels, à savoir le champ électrique et le champ magnétique, créés par des phénomènes tout à fait matériels, à savoir l'accumulation d'électrons et l'orientation d'atomes…
[^] # Re: Disque mou ?
Posté par barmic . Évalué à 1.
C'est pas vraiment ce qui caractérise ce qui est ou non solide.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Disque mou ?
Posté par jcr83 . Évalué à 7.
Je pense que le terme "solid-state" a été créé en opposition à "vacuum tube", en français "tube à vide", lors de l'invention des premiers transistors.
[^] # Re: Disque mou ?
Posté par Christophe Duparquet (site web personnel) . Évalué à 1.
La page Wikipedia anglaise pour solid-state permet de mieux comprendre ce que ce terme sous-entend.
« J'ai pas Word, j'ai pas Windows, et j'ai pas la télé ! »
[^] # Re: Disque mou ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# GPGPU?
Posté par Larry Cow . Évalué à 4.
Est-ce que ça signifie qu'on peut faire de l'OpenCL avec un pilote Libre? Quelqu'un aurait des retours/pointeurs là-dessus?
[^] # Re: GPGPU?
Posté par xoddark . Évalué à 4.
Oui c'est possible, mais je ne saurais pas te dire ce qui fonctionne, et ce qui ne fonctionne pas.
Clover (l'implémentation OpenCL de Mesa basé sur Gallium) déclare savoir faire de l'OpenCL 1.2
A voir si ce n'est pas trop buggé.
Pour les versions plus récente d'OpenCL, il va falloir regarder plutôt de coté de RadeonOpenCompute et ROCm.
Mais la c'est un peu plus complexe a mettre en place je pense.
[^] # Re: GPGPU?
Posté par WhiteCat . Évalué à 3.
Non c'est encore totalement à la ramasse si tu veux faire des trucs sérieux, genre minage.
Déjà même avec le pilote proprio c'est limite…
Mouais, ce qui me ravirai surtout c'est de pouvoir downvolter le GPU ! Pour le minage c'est essentiel. L'overclocking on s'en fou.
Mais bon… AMD est encore une fois à côté de la plaque. Je me demande s'ils sont au courant que pour le minage leurs cartes sont majoritairement utilisées.
[^] # Re: GPGPU?
Posté par khivapia . Évalué à 2.
Je me demande s'ils sont au courant que pour le minage leurs cartes sont majoritairement utilisées.
Plutôt que des cartes NVidia ? Elles sont plus performantes que les autres solutions pour miner ?
# Franche camaraderie
Posté par arnaudus . Évalué à 1.
Dites donc, l'ambiance est toujours autant au beau fixe…
[^] # Re: Franche camaraderie
Posté par gUI (Mastodon) . Évalué à 6.
Pour avoir tâté le monde de l'upstream, il y a quand même une ambiance à l'humiliation qui est déroutante. Vu qu'on est entre personnes assez compétentes, c'est la coutume, ça passe, mais c'est pas conseillé pour un public non averti.
On retombe peu ou prou sur le problème de la gestion de projet par un Ayatollah. Ça a montré son efficacité, mais c'est pas facile tous les jours pour les autres.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Franche camaraderie
Posté par Renault (site web personnel) . Évalué à 10.
Il faut quand même ne pas oublier que Andrew a de lourdes responsabilités et qu'il les a car Linus a une confiance énorme en lui. Une erreur pareille qui passe entre les mailles du filet est très rare dans le noyau, si tard dans le cycle du développement du moins. Je ne trouve pas la phrase si insultante, elle sous-entend clairement qu'Andrew fait d'habitude du très bon travail mais que sur le coup il a merdé et qu'il est déçu. C'est tout. Je ne trouve pas cela si humiliant (il ne l'a pas insulté par rapport à ses habitudes).
Tout le monde connaît les règles du jeu avec Linus, ce n'est pas nouveau et Andrew en particulier les connaît très très bien.
Notons que Linus l'a toujours dit, l'avantage du LL, c'est que si Linus devient fou, incompétent ou que plus personnes ne lui fait confiance, on peut prendre les sources et aller faire son projet ailleurs avec les autres pour écarter Linus.
Si personne ne le fait vraiment, c'est que malgré tout le système semble fonctionner suffisamment bien. Même Google, qui a pourtant de gros moyens humains et financiers limite au maximum l'écart avec la branche officielle pour Android.
[^] # Re: Franche camaraderie
Posté par arnaudus . Évalué à 0.
Mouais, je trouve quand même ça déplacé de faire ça devant tout le monde. Il peut très bien lui dire ce qu'il pense en mail privé, et officiellement dire qu'il s'est expliqué avec Andrew et qu'ils s'étaient assurés que ce genre de choses n'arriveraient plus.
Honnêtement, je ne trouve pas ça digne d'un chef, de dénoncer nommément les responsables de conneries. C'est des méthodes de management à la Cyril Hanouna, c'est ça? Si une telle chose a pu arriver, c'est à cause d'un problème d'organisation, puisque le système est censé être fait pour que ça n'arrive pas. Peut-être qu'Andrew a fait comme Linus, qu'il a laissé passé un truc dans l'urgence sans le voir.
[^] # Re: Franche camaraderie
Posté par Renault (site web personnel) . Évalué à 8.
Je ne dis pas que c'est la méthode que j'aurais utilisé. Mais je ne la trouve pas si violente que cela. Il a dit qu'il était déçu, ce n'est pas ce que j'appelle une humiliation personnellement.
Il faut comprendre que Linus ne vérifie presque pas le travail validé par ses lieutenants directs dont fait parti Andrew. Car Linus n'est pas omniscient, il n'est pas expert en tout dans le noyau et intervient rarement aux endroits qu'il connaît peu. C'est le boulot d'Andrew de vérifier / tester le commit final qui ira dans le noyau pour sa partie.
Ce serait une erreur dans le VFS ou x86, Linus serait sans doute à blâmer car ce sont des endroits qu'il gère et adore. Pas ici.
Après comme je dis, je peux comprendre qu'on aime pas cette ambiance, et l'avantage du Libre c'est qu'on peut justement se débarrasser d'un mauvais gestionnaire de projets. Après il faut convaincre les autres contributeurs que Linus n'est pas adapté.
[^] # Re: Franche camaraderie
Posté par barmic . Évalué à 9.
Linus n'est pas un chef. Andrew fait bien ce qu'il veut Linus n'est pas son chef. Ils collaborent tous 2 sur le même projets. Linus a plus de responsabilité qu'Andrew, mais ça n'en fait pas un lien hiérarchique. Son chef c'est Google. Ce n'est pas une subtilité (du tout).
J'ai eu des retours de collègues qui ont travaillé aux USA et qui expliquent que la contrepartie à l'énergie positive que les américains donnent dans leur projet, c'est que quand il y a un souci, ils sont plutôt acerbes. C'est pas cool. C'est dommage, décevant, énervant, rageant,… mais c'est culturel. Je ne me permettrais pas d'affirmer que c'est moins bien que nous en France où on a tendance à tuer les projets dans l'œuf sans leur laisser leurs chances.
Ça n'excuse pas, ils sont peut être pas aussi violents (et ils ne le sont pas tous bien évidement !), mais ça ne paraît peut-être pas aussi violent pour les des employés américains que pour nous.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Franche camaraderie
Posté par BAud (site web personnel) . Évalué à 7.
je ne saurais pas dire, mais j'ai l'impression que c'est culturel : le travail est collaboratif, en public via des ML, que dirait-on si les remontrances ne passaient qu'en privé et seulement les félicitations en public ?
Une fois que l'on a choisi, en conscience, de travailler en public, sur Internet/via ML, il est « normal » que même les débordements arrivent. Sur le coup, de mon expérience, Linus me paraît soft et - en lisant entre les lignes - cela montre une connivence entre les deux (je doute que Linus ait perdu une seule once de son temps à asmather Andrew en privé, une petite phrase bien sentie suffit largement àmha).
Bon, après, vu de l'extérieur, sans prise en compte du contexte, cela peut paraître violent, pourquoi pas, alors que les deux sont déjà passés à autre chose àmha, c'est réglé, il y a plein d'autres trucs à gérer à côté pour s'arrêter sur un épisode et une vanne/bâche bien sentie.
[^] # Re: Franche camaraderie
Posté par Marotte ⛧ . Évalué à 10. Dernière modification le 18 décembre 2016 à 19:49.
Non. Ce serait le contraire de la transparence. Linus avait des reproches à faire à Andrew, il était décu de son travail, il lui a dit publiquement, comme ça tout le monde est au courant, c’est ça une gouvernance transparente.
De plus : « je m’attendais à bien mieux de la part d’Andrew. » me semble être au contraire une marque de respect.
« Être diplomate » ou « arrondir les angles » etc… ça va bien un moment… à y accorder trop d’importance on tombe dans une communication plate et insipide, donc pauvre.
Sans compter que devoir dire deux fois la même chose, une fois en privée avec Andrew et une fois publiquement, c’est une perte de temps.
[^] # Re: Franche camaraderie
Posté par Larry Cow . Évalué à 5.
Déjà. Et en prime, ça ne s'adresse pas à un contributeur junior en mal d'encouragements, et/ou qui risque de tout laisser tomber face à ce genre de "rebuffade" (gentillette au demeurant).
[^] # Re: Franche camaraderie
Posté par gUI (Mastodon) . Évalué à 9.
Je suis d'accord avec toi, comme je dis, c'est comme ça et ça marche pas trop mal, surtout entre adultes consentants :)
Exemple pour illustrer que c'est quand même plus général que Linus et son besoin de déléguer : regarde Gerrit. Outil génial pour la gestion/relecture de patches. Quand tu es relecteur, tu peux mettre +1 pour dire OK, et -1 pour faire des remarques sur le patch (et donc l'améliorer).
- Quand tu mets +1, il y a à côté "Looks good to me, but someone else must approve" (ça me parait bon, mais quelqu'un d'autre doit approuver). C'est logique, il faut qu'un mainteneur mette "+2"
- Quand tu mets -1, il y a à côté "I would prefer that you didn't submit this" (j'aurais préféré que tu ne soumettes pas ça).
Je suis désolé, quand un mec fait un bon patch, que tu lui fais une remarque (y compris un truc énorme comme un buffeur overflow potentiel), t'as pas forcément envie de lui balancer à la gueule "j'aurais préféré que tu soumettes pas ce patch". C'est assez violent je trouve (et gratuit aussi).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Franche camaraderie
Posté par Geo Vah . Évalué à 5.
Tous passe pas trop mal, surtout quand les adultes sont consentants…
Perso, je prends mon temps avec les stagiaires, les juniors de leur expliquer le pourquoi du comment.
Le mec qui n'est pas junior, j'attends de lui les basiques de son job et je ne perdrais pas mon temps a lui expliquer ce qu'il doit savoir.
Un senior -i.e. personne compétente- doit savoir se débrouiller sans moi et si j'ai confiance en lui, j'attends de lui qu'il fasse du boulot propre et je ne perdrais pas mon temps a refaire son boulot - oui je dis "t'as fait de la merde la…" mais jamais en public… Son boulot reflète le miens.
Je n’hésites pas a dire si le boulot est mauvais. En meme temps, ne pas oublier de dire que le boulot est bien fait, envoyer un email positif avec le manager en copie est toujours bien vu…
L’idée derriere est qu'un individu a et fera des erreurs. L’idée d'un travail de groupe est de rattraper les erreurs de chacun…
[^] # Re: Franche camaraderie
Posté par groumly . Évalué à -4.
La forme est inacceptable pour un projet de cet envergure.
La manière (forum publique) est inacceptable aussi.
C'est de la décence de base de a) pas pourrir les gens violemment et b) laver son linge sale en public.
Tu peux tres bien faire passer le message sans insulter et/ou humilier ton interlocuteur. Le message passera mieux et t'installes pas une ambiance de merde sur ta ML (ca m'amuse pas de lire ce genre d'humiliation).
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Franche camaraderie
Posté par Marotte ⛧ . Évalué à 3.
Non seulement tu peux mais je dirais qu’en plus tu dois, tout le monde est d’accord là dessus à priori.
Maintenant explique moi où tu vois insulte et humiliation dans le message de Linus…
Si dans la vie on ne peut plus dire à quelqu’un, devant d’autres personnes : « Tu m’énerves, ce que tu viens de faire c’est nul, le refais pas ! » je sais pas où on va…
[^] # Re: Franche camaraderie
Posté par xcomcmdr . Évalué à 2.
Tu as toutes les chances de braquer la personne / l'humilier avec ton discours nul.
Il suffit de dire "ce travail n'est pas celui que j'attendais" et d'expliquer pourquoi.
Nul besoin de s'énerver, ni de dire que c'est "nul". Non seulement ça n'avance en rien, mais ça humilie la personne…
L'empathie n'a jamais empêché personne de travailler en groupe, au contraire.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Franche camaraderie
Posté par groumly . Évalué à 6.
Buggy crap, no fucking excuse, should damn well never be let near the vm, remove the crap, why the fuck does this still happen, people still do this shit.
On peut expliquer qu'un patch est de mauvaise qualité sans le comparer à de la merde, et on peut demander à des gens d'arrêter d'utiliser des macros sans utiliser la tournure "why the fuck".
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Franche camaraderie
Posté par Marotte ⛧ . Évalué à -3. Dernière modification le 19 décembre 2016 à 04:53.
"shit" signifie "merde", mais pas seulement.
Ce n’est pas connoté aussi négativement que « merde » en français. Parfois ça veut simplement dire « truc » et il y a même l’expression "the shit" comme par exemple : "That movie's the shit, man! You have to see it!" ou "He thinks he's the shit." où au contraire la connotation et méliorative…
http://www.wordreference.com/enfr/shit
[^] # Re: Franche camaraderie
Posté par groumly . Évalué à 4.
Et donc, t'es en train de dire que Linus veut dire "les gens font toujours ces trucs géniaux"?
Évidemment, non, dans un contexte pareil, ca se traduit par "et les gens font toujours ce genre de conneries".
Et il te reste à expliquer les autres noms d'oiseaux (les craps, les fucking et le damn well not be allowed anywhere near the vm layer).
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Franche camaraderie
Posté par groumly . Évalué à 4.
Ah, et pis, quand à dire "ce que t'as fait c'est nul", je vois pas l'intérêt de dire que c'est "nul".
Tu rejettes le patch, tu dit pourquoi (que c'est pas cool de briquer une machine), et pis voilà. le résultat est le même et le patch est corrige, tout le monde est content.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Franche camaraderie
Posté par barmic . Évalué à 10.
Vous découvrez aujourd'hui que Linus n'est pas et ne sera jamais community manager ? Non il n'est pas parfait et je trouve assez ridicule de voir des gens par ici jouer les gens choqués :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Franche camaraderie
Posté par groumly . Évalué à -1.
Non, je le découvre pas et non je suis pas choqué.
Ca change rien au fait que l'attitude de Linus est toujours inacceptable, venant d'un leader d'un projet majeur, ce qui est le sujet de discussion.
La bienséance et les règles de vie en communauté. Ne pas insulter les gens en public, tes parents ne t'ont pas appris ca? C'est du même tonneau que "dit merci à la madame" pourtant.
Wat?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Franche camaraderie
Posté par Marotte ⛧ . Évalué à 4.
Arrête de nous faire ta vierge effarouchée, c’est vraiment l’hôpital qui se moque de la charité.
[^] # Re: Franche camaraderie
Posté par Zenitram (site web personnel) . Évalué à 2.
Tu te bloques sur un truc que tu ne comprends pas, ce qui fait que tu réponds complètement HS :
- groumly : c'est pas bien d'insulter
- barmic (et autres) : tu le prends comme insulte, pas nous et pas la personne visée.
- groumly : c'est pas bien d'insulter
euh…
Le sujet est que Linus est un leader d'un projet majeur peut-être aussi parce qu'il évite de se prendre la tête avec les gens qui font chier dès qu'il y a un mot pas apprécié (genre ils le prennent comme insulte).
Ca peut être un bon filtre pour virer les emmerdeurs (et la je vois le truc venir "ça fait fuir les femmes", qui serait un bon gros sexisme imaginant que toutes les femmes sont plus faibles sur ce sujet que tous les hommes, cf la discussion précédente sur le même type de problème de compréhension du sujet).
A noter aussi que ce n'est pas la personne visée qui râle "c'est une insulte", mais un tiers qui n'a rien à voir avec la discussion.
Faudrait peut-être se poser tranquillement, relire calmement, afin de comprendre l'autre pour pouvoir répondre à son argument et non pas un argument imaginaire.
Note au cas où : je ne prend pas spécialement position sur si Linus devrait changer de comportement ou pas, ce n'est pas le sujet de mon commentaire, qui est centré sur le blocage dans la discussion du fait que ça répond à côté.
PS : ha, juste pour "venant d'un leader d'un projet majeur".
A en croire les faits, Linus devrait non pas être déçu d'une personne, mais plutôt le traiter de connard et j'en passe, ça a l'air de fonctionner bien mieux que d'être gentil. Alors qu'on ne vienne pas parler de "être gentil avec tout le monde permet de faire plus de choses ensemble", et le comportement de Linus devrait être le dernier de tes soucis en ce moment si les insultes te posent un soucis.
[^] # Re: Franche camaraderie
Posté par barmic . Évalué à 5.
On a des messages qui valent pas loin de ce que fait Linus ici aussi. Avant de tenter de pacifier la LKML pourquoi ne pas s'intéresser à ce qui est devant toi ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Franche camaraderie
Posté par Marotte ⛧ . Évalué à 9.
Non mais fait chier putain merde à la fin ! Ya aucun problème de respect ici alors mets la en veilleuse bordel !
[^] # Re: Franche camaraderie
Posté par Antoine . Évalué à -3.
Sur le fond, je suis d'accord, la forme des échanges sur Linuxfr est aussi peu agréable que sur la LKML, mais en même temps, Linuxfr c'est un peu accessoire, c'est pas comme si effrayer de temps en temps des lecteurs et contributeurs potentiels de ce site menaçait de diminuer la qualité de l'écosystème logiciel utilisé par des millions de personnes.
Je ne dis pas que c'est une raison pour laisser faire, mais simplement qu'il y a beaucoup moins lieu de s'en inquiéter sérieusement.
[^] # Re: Franche camaraderie
Posté par barmic . Évalué à 9.
À ce niveau là, je pense que les 25 dernières années montrent qu'il ne faut pas trop s'inquiéter. Linus est à l'origine de linux et de git. Tu as l'impression que ce sont des projets en danger ?
C'est dommage, mais ta peur ne se présente pas dans les faits (il y a bien sûr des contre exemples, mais dans l'ensemble ses projets vivent bien).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Franche camaraderie
Posté par Antoine . Évalué à 0.
Qui parle de peur ou de mise en danger ? J'ai dit « menaçait de diminuer la qualité de l'écosystème logiciel utilisé par des millions de personnes ». Un projet n'a pas besoin d'être de très bonne qualité pour survivre (OpenSSL existe toujours).
[^] # Re: Franche camaraderie
Posté par barmic . Évalué à 4.
Pour git comme pour linux, ils ont de gros challengers qui sont tout à fait pertinents (pour git tu as mercurial par exemple, pour linux les BSD, windows, MacOS) et malgré cela, ce sont des projets qui ne sont pas en mode survis loin de là au contraire ils continuent à gagner en popularité.
C'est chiant, mais on peut difficilement dire que linux se porterait mieux si Linus se comporterait mieux, parce que linux va vraiment très très bien. Il va falloir trouver d'autres arguments pour dire à Linus qu'il doit se détendre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Franche camaraderie
Posté par Antoine . Évalué à 0.
Il faut être sérieux deux secondes. Windows et MacOS ne sauraient remplacer Linux, pour une raison simple : Linux est gratuit (et libre), ce qui est évidemment un très gros argument de vente. Quant aux BSD (ou Darwin), le retard à combler (support matériel, fonctionnalités, performances…) est énorme. Bref, oui, Linux est pépère sur son créneau aujourd'hui, et il le resterait un certain temps même si son développement venait à ralentir.
Quant à git, il me semble que ça fait longtemps que Linus a passé la main.
Le gros problème en effet c'est que c'est impossible à déterminer rigoureusement : il faudrait pouvoir tester avec et sans Linus, de façon réversible, et toutes choses égales par ailleurs. On ne peut donc que spéculer de façon plus ou moins informée, par exemple par des situations passées (genre glibc ou XFree86) dont la ressemblance est loin d'être évidente.
[^] # Re: Franche camaraderie
Posté par barmic . Évalué à 5.
La concurrence est plus dure que tu ne semble le croire. Tuer Windows server ce n'est pas n'importe quoi. Ne serais-ce parce que même sans parler technique MS est capable de tenir à bout de bras un projet suffisamment longtemps pour épuiser la concurrence. AIX sur serveur c'est d'une très grande qualité et linux est plutôt à la traîne à ce niveau là (techniquement parlant), mais il reste dans la course. QNX aussi est un concurrent de poids. Google va sortir fushia. La compétition est loin d'être inexistante.
Oui mais il a créé une communauté. Le genre de truc que tu fais pas si tu es vraiment aussi mauvais que ce que certains semblent affirmer au dessus.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Franche camaraderie
Posté par Maclag . Évalué à 2.
L'enjeu est différent, mais le principe est le même: ce sont des projets qui dépendent de contributeurs sinon ils meurent!
Linuxfr semble actif, preuve que l'ambiance n'a pas fait fuir tout le monde. C'est même mieux encore, vu que personne n'est payé pour contribuer au site!
[^] # Re: Franche camaraderie
Posté par Eiffel . Évalué à 1.
La réaction de Linus est assez moyenne, je suis aussi d'accord avec le fait qu'une "remontrance" en privée aurait été meilleur. Après au vu du "personnage", la réaction est plutôt soft.
Est-ce que vous connaissez des projets assez gros qui sont gérés d'une manière plus démocratique ?
[^] # Re: Franche camaraderie
Posté par patrick_g (site web personnel) . Évalué à 9.
Debian.
[^] # Re: Franche camaraderie
Posté par Eiffel . Évalué à 2.
Et du coup niveau organisation ça ressemble à quoi ? Plus à un comité (comme les comités de standardisation ?) ?
[^] # Re: Franche camaraderie
Posté par Jean-Baptiste Faure . Évalué à 3.
LibreOffice, même si le projet se réclame plutôt de la méritocratie et du "c'est celui qui fait qui décide".
Les questions de développement (code, L10N, QA, Documentation, Design/UX) sont discutées et tranchées par l'Engineering Steering Committee qui se réunit (réunion téléphonique) tous les jeudis et dont les comptes-rendus sont publics. Les membres de l'ESC sont choisis pas cooptation.
Le CR de l'ESC du 15/12 : http://nabble.documentfoundation.org/minutes-of-ESC-call-td4202197.html Il est en général rédigé par M. Meeks mais pas toujours.
[^] # Re: Franche camaraderie
Posté par Frank-N-Furter . Évalué à 3.
Debian Constitution
Constitution for the Debian Project / Decision-making bodies and individuals
Depending on the time of day, the French go either way.
[^] # Re: Franche camaraderie
Posté par Antoine . Évalué à 4.
Les quelques fois où j'ai lu une discussion sur les listes Debian, ça avait l'air assez salé… Bref le caractère démocratique du projet n'offre aucune protection contre les prises de bec, les messages agressifs ou les attaques personnelles. C'est surtout une question culturelle, une « ambiance » ayant tendance à s'auto-reproduire par sélection et/ou auto-adaptation des participations.
[^] # Re: Franche camaraderie
Posté par Larry Cow . Évalué à 10.
Et si quelqu'un avait encore des doutes malgré ça, La Chaîne Parlementaire devrait permettre de s'en défaire.
[^] # Re: Franche camaraderie
Posté par Albert_ . Évalué à 5.
C'est amusant comme on entend parler des messages de Linus quand il s'enerve mais je n'ai jamais vu de troll sur les milliers de messages normaux (mais d'un chiant ou d'un niveau technique un peu trop eleve)…
[^] # Re: Franche camaraderie
Posté par Yth (Mastodon) . Évalué à 6.
C'est à dire que le jour où Linus dira ça de moi, je vais pavaner comme un Paon, et avoir la banane pendant des semaines !
Mais bon, mauvaise ambiance vue de l'extérieur tout ça, point de vue, goûts, couleurs, opinions à l'emporte-pièce, etc… La vie quoi…
Yth.
# Merci !
Posté par antistress (site web personnel) . Évalué à 3.
Merci beaucoup pour la dépêche !
Dommage qu'il y ait moins de mainteneurs/contributeurs qu'avant, faute de compétence ou de temps à ce moment j'imagine.
Je croise les doigts pour qu'il y ait plus de monde sur les prochaines dépêches noyau :)
[^] # Re: Merci !
Posté par gusterhack . Évalué à 1.
La dépêche suivante sera beaucoup plus grosse. :)
[^] # Re: Merci !
Posté par antistress (site web personnel) . Évalué à 1.
Chouette !
http://p9.storage.canalblog.com/97/14/121246/7851229.jpg
# Retirez mon nom merci
Posté par Romain Perier . Évalué à 1.
Euh… ça fait déjà plusieurs dépêche que je ne contribue plus et que j'ai retiré mon nom… ça serait possible d'éviter de la rajouter ? merci ^
Sinon jolie travail !
[^] # Re: Retirez mon nom merci
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci. J'ai aussi corrigé la dépêche 4.9 en préparation et modifié le patron qui sert à initier les dépêches noyau, cela devrait donc régler le souci pour les prochaines versions.
[^] # Re: Retirez mon nom merci
Posté par Romain Perier . Évalué à 1.
Super merci!
# chiffrement FS
Posté par steph1978 . Évalué à 4.
J'en déduis que ext4 peut chiffrer les données, tout comme F2FS. C'est ce que confirme la page wikipedia de ext4.
Quels sont les avantages / inconvénient à chiffrer au niveau FS par rapport à chiffrer au niveau block (dmcrypt) ?
J'ai souvent vu du chiffrement block (c'est ce que m'a proposé ma distrib), rarement au niveau FS. D'ailleurs les man de mount ou mke2fs ne semblent pas dire comment faire.
[^] # Re: chiffrement FS
Posté par Kerro . Évalué à 6.
Le chiffrement au niveau du système de fichier permet généralement :
- de chiffrer certains répertoires/fichiers et pas d'autres
- d'avoir plusieurs clefs. Par exemple une clef par utilisateur. Très utile pour se protéger comme un certain nombre d'erreur de configuration des ACL et de certaines failles de sécurité
- d'éviter une couche de « device mapper » (pas certain que ça joue sur les performances, mais ça simplifie l'administration)
- d'avoir une vérification de l'intégrité des données (rien n'interdit de le faire au niveau du périphérique, mais je n'en connais pas qui le fasse)
- de chiffrer même si ça n'a pas été prévu au départ (puisqu'on n'a pas prévu le device mapper)
Je trouve que les 2 premiers points sont importants.
À l'inverse, chiffrer au niveau du périphérique permet de chiffrer même avec un système de fichier qui n'est pas prévu pour.
[^] # Re: chiffrement FS
Posté par barmic . Évalué à 3.
Dans mes souvenirs LUKS le permet aussi, non ?
Qu'est-ce que tu entends par là ? Quand tu déchiffre la partition, ton FS fait cette vérification et c'est voulu de ne pas pouvoir la faire sans avoir déchiffré ta partition.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: chiffrement FS
Posté par BAud (site web personnel) . Évalué à 2. Dernière modification le 22 décembre 2016 à 13:30.
dans mes souvenirs aussi 'fin la doc' :/ dans la pratique, j'aurais tendance à dire que c'était mis en œuvre pour tous les utilisateurs, mais pas pour chaque utilisateur.
là est la différence.
Tu choppes la bonne entrée (MITM) et zou, c'est du déchiffré pour tout le monde (quasi). Mais vu que 70% des attaques viennent de l'interne, tu peux comprendre l'analyse du niveau de sécurité atteint… et c'est là que tu comprends que la sécurité se préoccupe de gérer les attaques de l'externe venant de l'interne (mais si tu as compris, tu es devenu paranoïaque).
Une bonne attitude : tu as un accès physique, tu es admin de ce à quoi tu as accès. Et ça change la donne.
[^] # Re: chiffrement FS
Posté par Kerro . Évalué à 6.
LUKS permet à plusieurs personne de chiffre/déchiffrer la totalité de la partition.
Alors que le chiffrement au niveau du FS permet à chaque utilisateur de chiffrer ses fichiers à lui sans que d'autres puissent y accéder.
Je ne comprends pas ce que tu veux dire.
Les FS chiffrés qui font de la vérification de données (ce n'est pas le cas de ext4 je crois) permettent de s'assurer que les données déchiffrées sont les bonnes. Avec un chiffrement au niveau du périphérique ça n'est pas implémenté, donc si une erreur tombe au milieu d'un fichier, tu ne t'en rends pas compte.
Cela dit je ne suis pas certain que ce soit un super argument car à ma connaissance les FS qui chiffrent avec vérification des données font déjà cette vérification sans chiffrer (ça semble logique d'un point du point de vue du développeur).
# Système monopuce ?
Posté par Joël . Évalué à 2.
Encore une fois, très bonne dépêche, c'est toujours instructif d'en apprendre plus sur le noyau Linux. Par contre, je suis un peu étonné du choix de traduction de "System-on-Chip" en "système monopuce" qui me parait ne pas garder la même signification.
Un "système monopuce" sous-entend que le système ne contient qu'une seule puce, ce qui est probablement faux.
Par contre, la traduction que je préfère, "système sur puce", signifie qu'une puce (et rien n'empêche théoriquement d'en avoir plusieurs sur la même carte électronique) regroupe la plupart, voire la majorité, des composants principaux qui auparavant constituait un système entier, ce qui correspond à la réalité. Du plus, c'est vraiment la traduction littérale de System-on-Chip, donc quoi demander de plus :)
[^] # Re: Système monopuce ?
Posté par Joris Dedieu (site web personnel) . Évalué à 1.
En d'autres temps on parlait d'un microcontrôleur …
[^] # Re: Système monopuce ?
Posté par Maclag . Évalué à 3.
C'est vrai mais microcontrôleur ça évoque surtout des composants peu performants (au moins pour moi).
Là on parle de bonnes grosses bêtes!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.