Sortie du noyau Linux 3.7

91
11
déc.
2012
Noyau

La sortie de la version stable 3.7 du noyau Linux vient d’être annoncée 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 (dont un certain nombre concernent les architectures ARM) est dans la seconde partie de la dépêche (qui est sous licence CC BY-SA).

Merci aux participants à la rédaction de cette dépêche : Florent Zara, Christophe Turbout, Sylvestre Ledru, patrick_g, detail_pratique, SQP, baud123, _PhiX_, Maxime, EdB, Thomas DEBESSE, Yves Bourguignon, Batchyx, Strash, Martin Peres, yogitetradim, Akiel, matteli, mike.simonson, Kioob, david.g, Benoît, Remus, maboiteaspam et obms

Sommaire

La phase de test

RC-1 teintée de scepticisme

La version RC-1 a été annoncée par Linus le 14 octobre 2012 :

Les deux semaines sont finies, j'ai fait les fusions pendant mon voyage, donc pas de raison de les prolonger. Le 3.7-rc1 est sorti et il y a quelques gros trucs qui valent le coup d'être mentionnés :

  • nettoyage des fichiers d'include « UAPI ». L'idée est que ce qui est exporté en espace utilisateur devrait maintenant être trouvé dans include/uapi et arch/$(ARCH)/include/uapi. Espérons que ça finira vraiment par marcher. Parce que sinon c'était juste une merde inutile. De toute façon, je ne veux plus jamais revoir ce genre de nettoyage massif des fichiers d'include.
  • inclusion de l'architecture arm64 : on verra bien si ça fonctionne… et on verra combien d'années il faudra aux mainteneurs d'arm pour faire ce que chacune des autres architectures 64 bits a déjà fait : refusionner avec le code 32 bits. Comme d'habitude, ils ont affirmé qu'il y avait des tonnes de raisons expliquant que ce cas était différent, et comme d'habitude, tout cela finira se révéler n'être que des c***eries, et dans quelques années nous aurons de gros patches pour tenter de tout refusionner. Mais peut-être était-ce vraiment différent cette fois. Je me marre…
  • code arm multiplateforme. Enfin ! L'arborescence arm complète (appareils, code, bazar, etc.) signifie qu'au moins quelques noyaux arm peuvent maintenant être compilés pour prendre en charge plusieurs plateformes différentes avec un seul binaire. Je suis sûr qu'il manque encore plein de trucs, mais c'est de toute façon une étape importante.
  • virtualisation d'arm et gestion de Xen.
  • les espaces de noms utilisateurs reviennent, et ils fonctionnent.
  • signature des modules du noyau.
  • jolis nettoyages : workqueues (Tejun Heo) et les execve / kernel_thread génériques (Al Viro).

Il y a des tonnes d'autres mises-à-jour, mais ce qui précède est le plus marquant, parce c'est du lourd et du neuf. J'en rate d'ailleurs peut-être un peu. Évidemment, en sus des nouveautés du dessus, le gros des patches concerne les habituelles mises-à-jour des pilotes — que je n'ai pas évoquées. Donc, les nouveautés marquantes sont en fait plus petites que les habituelles mises-à-jour.
Bref, le résumé du journal est bien trop gros, comme toujours pour une rc-1, mais j'ai joint mon résumé des fusions qui donne au moins une idée générale de ce que j'ai pu faire.

RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

La version RC-2 a été annoncée par Linus le 20 octobre 2012 :

Depuis quelques mois, c'est devenu presque habituel de ma part de publier des versions d'un aéroport alors que je voyage quelque part. Cette -rc n'y échappe pas. Reste libre, petit point d'accès de l'aéroport de Portland !

Bref, ça fait grosso-modo une semaine, donc voici la -rc2. Les trucs les plus notables sont les corrections des problèmes provoqués par la dernière -rc : il y a beaucoup de patches de nettoyage en rapport à la réorganisation des fichiers d'en-tête UAPI, mais aussi quelques changements sur le fonctionnement de la signature des modules.

Précisément, la réorganisation d'UAPI (même en détectant les renommages) éclipse tout le reste : les stats de diff sont très inhabituelles. Au lieu du classique « 65% de pilotes et le reste en vrac », on a 50% de patches d'architecture (principalement les fichiers d'en-têtes d'UAPI), 30% de fichiers d'include (encore des fichiers d'en-têtes d'UAPI), et 20% pour tout le reste.

Malgré tout, le résumé reste à peu près lisible, parce que les changements d'UAPI ne sont pas effectivement majoritaires, donc rien ne sort du lot. Des changements sur les pilotes DRM et USB, et quelques corrections un peu partout.

Testez donc et amusez-vous bien.

RC3 par un fan d'Highlander

La version RC-3 a été annoncée par Linus le 28 octobre 2012 :

Une semaine est passée, il est temps de sortir la -rc3 !

Rien ne sort particulièrement du lot : beaucoup de petites corrections, avec par exemple les corrections de fuites de mémoire dans les pilotes usb. Beaucoup de changements, sans lien les uns avec les autres.

La majorité concerne les pilotes (tous ceux dans : drm, réseau sans fil, staging, usb, son), mais aussi quelques corrections dans les systèmes de fichiers (ntfs, btrfs, ext4), au niveau architectures (arm, x86 et m68k) et des mises-à-jour diverses. Le résumé du journal est joint ci-dessous.

En parlant du résumé : mon dieu, certains d´entre vous ont besoin de changer de prénom. Je suis habitué au fait qu´il y ait de multiples « David » et « Peter » etc, mais il y a trois « Linus » différents dans cette rc.
Les gars, écoutez bien : je veux rester unique comme l'est un flocon de neige, pas juste un autre gars dans la masse.
Je vais me chercher une broadsword.

Linus  « Il ne peut en rester qu'un » Torvalds.

RC4 : ext4 corrigé = fin du raffut

La version RC-4 a été annoncée par Linus le 4 novembre 2012 :

Cette semaine a été plutôt calme, donc les gars voici pour vous une jolie petite -rc.

Rafael m'a inquiété, pendant un moment, avec ce qui semblait être une régression difficile à déboguer, mais cela s'est avéré être un problème en espace utilisateur, donc tout semble plutôt stable. Les choses semblent totalement normales : la plupart des changements sont des corrections de pilotes, avec une poignée d'autres trucs (client nfs, mises à jour mineures d'architectures et quelques trucs réseau).

Les corrections de pilotes concernent à peu près tout : son, carte graphique, interface homme-machine et périphériques d'entrées, bus i2c, réseau.

Peut-être le plus important à signaler, à cause du bruit engendré dans certains cercles, la correction concernant ext4 bitmap journaling qui règle ce problème qui a fait tant de boucan. C'est une petite correction et malgré tout ce raffut, vous ne pouviez être confronté à ce bogue, à moins d'avoir fait des choses insensées, en utilisant des options de montage spéciales.

Autre chose ? Rien de particulier ne ressort. Le résumé ci-joint donne un aperçu raisonnable sur le détail de ce sur quoi les gens travaillent. Je voyagerai la semaine prochaine, mais je pense avoir un accès wifi correct et, si ça reste aussi calme, personne ne s'en rendra compte.

Allez-y et testez.

RC5 : Linus voyage dans le temps et l'espace

La version RC-5 a été annoncée par Linus le 11 novembre 2012 :

Une autre semaine vient de passer (modulo les différences de timezone), donc la rc5 est là.

Je suis heureux de constater que c'est plutôt une petite rc. La rc4 était déjà plutôt calme et cette rc5 a encore moins de commits. Plus important, à part un revert et une mise a jour du pilote pnctl, c'est non seulement un petit nombre de commits, mais ils sont pour la plupart d'une seule ligne. Les stats de diff semblent plutôt jolies et homogènes.

Les mises à jours sont :

  • architecture (sparc, arm/arm64 et s390)
  • pilotes (drm, mmc, net, pinctrl, hid, sound, hwmon, pci)
  • divers (net, akpm, xen, virtio, mudles et crypto)
  • systèmes de fichiers (gfs2, xfs et cifs)

Mais c'est réellement petit.

Le résumé du journal est joint ci-dessous.

S'il vous plait, testez - Bien que j'espère que c'est calme parce que les choses sont sur une bonne voie - je voudrais que ce soit vérifié.

RC6 : Jusqu'ici tout va bien

La version RC-6 a été annoncée par Linus le 16 novembre 2012 :

Légèrement moins d'une semaine, mais comme je pars en vacances demain, la voilà.

Les choses continuent d'être calmes. Nous avons quelques commits de plus que dans la -rc5, mais pas assez pour m'inquiéter, et la plupart des changements sont vraiment minuscules. En outre, les quelques commits qui ne sont pas d'une ligne (ou de quelques lignes) ont tendance à être des retours en arrière (par exemple le ré-ajout de /proc/<pid>/oom_adj) ou des choses assez obscures (la fonction MIPS irqflags).

Donc, nous avons quelques mise à jour d'architectures (principalement mips et unicore32, avec une poignée de arm[64] et s390) et changements sur les pilotes (son, net, usb). Avec quelques corrections réseau et mm.

Le shortlog ci-joint donne un aperçu du genre de choses qui se sont produites, ce n'est pas vraiment très excitant, mais c'est assez court pour être lu entièrement et donner une vague idée.

J'aurais un ordinateur portable avec moi pendant mon voyage, mais si tout se calme encore plus, je serais content. Je ferais bien une -rc7, mais en considérant combien tout cela a été calme, je soupçonne que c'est la dernière -rc. À moins que quelque chose de dramatique ne se produise.

RC7 : Garçon, une autre !

La version RC-7 a été annoncée par Linus le 25 novembre 2012 :

Une semaine plus tôt, j'avais même envisagé de zapper la -rc7 tellement tout était calme mais j'ai finalement décidé qu'il n'y a avait aucune raison à se dépêcher de sortir cette version.

Comme j'avais tristement raison. La -rc7 est maintenant disponible, et elle n'est pas vraiment plus petite que les précédentes versions, bien au contraire. Pour une raison que j'ignore, la prise en charge des unités de stockage block layer est apparue sur le radar et les modules md, scsi, mais aussi la couche générique sont concernés par ces changements. C'est donc certain : nous voulons une autre semaine de test ; heureusement, tout cela est vraiment solide.

Quelques changements corrigent les systèmes de fichiers (reiserfs, xfs et ext3), ainsi que d'autres mises à jours de pilotes (sound, networking and drm).

Shortlog ajouté. Déballez le paquet et testez le.

RC8 : Linus frappé par l'esprit de Noël ?

La version RC-8 a été annoncée par Linus le 3 décembre 2012 :

Je ne voulais pas en arriver là, mais j'étais mal à l'aise hier de sortir la 3.7 en raison de problèmes de dernière minute, et j'ai décidé de ne pas me précipiter.

Et aujourd'hui, je me sens encore moins à l'aise, à cause du retour d'un problème dans kswapd. J'ai donc finalement décidé de livrer une nouvelle -rc.

Ce n'est pas très pratique au niveau des dates, car cela signifie que la prochaine période de fusions interviendra à une date très proche de Noël. Cela devrait au moins motiver les gens à m'envoyer les changements au plus tôt et à ne pas attendre la dernière minute. Ça serait chouette.

Et puisque je décale tout d'une semaine, je serais très méchant si quelqu'un décide de m'envoyer des modifications à un moment aussi tardif du processus qui n'auraient pas pour but de résoudre des problèmes majeurs. Si vous m'envoyez des petits patches qui ne corrigent pas des problèmes majeurs (plantages, failles de sécurité…), je vais vous maudire et ignorer votre demande. Alors ne le faites pas.

La seule chose que je souhaite voir, ce sont des patches qui corrigent des problèmes critiques. Dans le cas contraire, ou si aucun retour utilisateur ne motive votre patch, posez le devant le sapin et attendez la version 3.8.

(Bon, tandis que j'écris ça je reçois une de ces demandes de modification qui me fait penser "nous n'avons pas vraiment besoin de ça". Je vais l'inclure parce que, techniquement, elle est arrivée avant que je n'envoie cet avertissement, mais…).

Les nouveautés

ARM SoC multi-platform

La grande diversité des plateformes à base d'architecture ARM est une force de cet écosystème, mais c'est aussi une source de complexité lorsqu'il s'agit d'implémenter leur prise en charge logicielle. Jusqu'à présent, chaque architecture ARM nécessitait de compiler une version du noyau spécifique, à l'inverse de ce qui se passe avec les autres architectures (à quelques exceptions près : versions 32/64 bits dans le monde x86 par exemple). Une première implémentation de la branche ARM soc multi-platform vient d'être introduite, destinée à être complétée ultérieurement. Elle permet la prise en charge de différentes plateformes ARM avec une seule et même version compilée du noyau, ce qui est un gros progrès.
Il faut en effet savoir qu'avec une architecture x86, le noyau peut se lancer et demander au matériel de s'identifier, alors que les matériels ARM n'ont pas cette capacité et qu'il faut donc préalablement configurer le noyau pour un matériel donné. Le travail réalisé consiste à sortir la description du matériel du noyau et à la reporter dans un fichier texte qui lui sera transmis lors du démarrage par le chargeur d'amorçage, permettant de réaliser des versions du noyau beaucoup plus polyvalentes. Les plateformes actuellement prises en charge sont les suivantes : Highbank, Vexpress, Mvebu, Socfpga and Picoxcell.

AArch64 (ARM64)

Jusqu'à présent les architectures ARM sont des architectures RISC 32 bits (dites AArch32). La société ARM et ses partenaires ayant des vues commerciales sur le marché des serveurs, très gourmands en mémoire, une version 64 bits (ARMv8) se concrétisera en 2014 avec la série des processeurs Cortex-A50 (que les Cortex-A53 et Cortex-A57 inaugureront). Préparant ce lancement, Catalin Marinas de la société ARM a proposé les modifications nécessaires pour permettre au noyau de gérer cette nouvelle architecture, dite AArch64.
Debian souhaite de son côté intégrer cette fonctionnalité à Jessie, le successeur de Wheezy (qui elle-même devrait succéder à Squeeze début 2013).

Xen pour processeurs ARM

Selon indexel.net, il s'agit là de la confirmation de « deux tendances lourdes de l'industrie informatique : l'intérêt croissant des fabricants de serveurs pour les processeurs basse consommation et l'arrivée imminente de la virtualisation sur les terminaux mobiles ». C'est à Citrix Systems que l'on doit, au terme de plus d'un an de développement, le portage de l’hyperviseur Xen pour processeurs ARM Cortex A15, à partir des fonctions liées à la virtualisation introduites avec l’architecture ARMv7… En attendant la prise en charge des architectures ARMv8 et ARM 64 bits.
Samsung mène de son côté le projet Xen ARM Project, un projet de paravirtualisation qui ne repose pas sur les extensions de virtualisation ARMv7 et prendra en charge les architectures ARMv5 et ARMv6.

SoC ARM Freescale i.MX (DragonBall MX)

Toujours du côté des architectures ARM, un nouveau pilote graphique KMS offre la prise en charge des SoC ARM Freescale i.MX51 et i.MX53 (à base de Cortex-A8 – le premier des deux étant un SoC bas de gamme destiné aux netbooks fonctionnant sous Google Chrome OS notamment), voire i.MX6 (à base de Cortex-A9).

Supervisor Mode Access Prevention (Intel Haswell)

La gestion du SMAP (Supervisor Mode Access Prevention) a été ajoutée pour les futurs microprocesseurs Intel (famille Haswell, prévue pour 2013) : il s'agit d'une fonctionnalité hardware qui déjoue, au prix d'un léger impact sur les performances, les accès non désirés aux données en espace utilisateur à partir du mode superviseur.
Cette fonction s'ajoute aux deux précédentes : XD (Execute-Disable) qui a été introduite avec les AMD Athlon 64/Opteron puis reprise dans les derniers Intel Pentium 4 Prescott, et SMEP (Supervisor Mode Execution Prevention) qui a été introduite avec les derniers processeurs Intel (famille Ivy Bridge).
Les développeurs de PaX (un patch externe applicable sur le noyau Linux et qui vise justement à protéger les zones mémoires contre diverses attaques, que nous avions récemment évoqué ici) ont donné leur avis sur cette fonctionnalité, avec, en conclusion : « Intel implémente l'équivalent de UDEREF 6 ans après PaX, PaX l'utilisera sur amd64 pour des performances améliorées »…

MODSIGN (sécurisation des modules complémentaires du noyau)

La possibilité de charger des modules complémentaires d'un noyau en train de fonctionner est une fonctionnalité très pratique. Elle autorise les distributions à inclure des noyaux de plus petite taille qui pourront quand même prendre en charge une grande quantité de matériel par ce biais. Cette technique pose toutefois une difficulté : comment garder le contrôle des modules chargés ? Il pourrait s'agir d'un blob que la distribution ne souhaite pas supporter, voire d'un logiciel malveillant… Il est désormais possible de compiler le noyau de telle sorte qu'il n'accepte que les modules signés.
David Howells, pour le compte de Red Hat, a proposé cette fonctionnalité que l'arrivée prochaine du secure boot (que Fedora 18 prendrait en charge) rend d'une actualité brûlante.
Deux nouvelles options de configuration du noyau sont introduites : CONFIG_MODULE_SIG et CONFIG_MODULE_SIG_FORCE. La première autorise la prise en charge des modules signés proprement dite : les modules seront signés lors de la compilation et le noyau vérifiera les signatures lors du chargement des modules. Les signatures peuvent utiliser les algorithmes de cryptographie SHA-1, SHA-224, SHA-256, SHA-384 et SHA-512. Avec la deuxième, le chargement d'un module ne sera autorisé que s'il utilise une clé spécifique du noyau.

Wii Balance Board (^_^)

Après le Kinect de la Xbox 360 et la Wiimote, c'est au tour de la Wii Balance Board (que l'on trouve dans le célèbre pack Wii Fit) de se voir offrir l'honneur d'une prise en charge par le noyau (au moyen d'une modification du pilote Wiimote). David Herrmann (blogue, github), à l'origine de la prise en charge de la Wiimote comme de la Wii Balance Board, explique : « la Nintendo Balance-Board est un contrôleur qui se comporte exactement comme la Wiimote, mais qui transmet ses données via une extension. Nous pouvons donc simplement ajouter la Balance-Board à la façon d'une extension pour obtenir une prise en charge complète ».

Oracle SPARC T4

Le processeur SPARC T4 (alias Niagara 4) lancé par Oracle en 2011 est désormais pris en charge. Le T4 est le dernier rejeton de la famille de processeurs SPARC développée par Sun Microsystems, qu'Oracle a repris en 2010. Il s'agit d'une puce RISC octocœurs, chaque cœur gérant huit threads. Pour mémoire, le T3 possédait deux fois plus de cœurs mais ceux-ci étaient moins rapides (1,65 GHz maximum pour le T3 contre 2,85 GHz ou 3 GHz pour le T4, suivant les serveurs). En outre, des optimisations conféreraient au T4 des performances mono-thread cinq fois supérieures à son prédécesseur. Le T5, qui devrait être annoncé prochainement, serait, lui, un processeur à 16 cœurs.

Un rappel qui intéressera sans doute nos lecteurs : l'architecture SPARC a été introduite par Sun Microsystems mi-1987, mais c'est une marque de SPARC International, regroupant notamment Oracle et Fujitsu, et qui préside aux évolutions de l'architecture. Les spécifications de celle-ci sont entièrement libres, ce qui autorise la création par quiconque de processeurs compatibles. La dernière version de l'architecture est ainsi la SPARC V9, apparue vers 1994 et qui marque le passage au 64 bits. Les processeurs SPARC T3 et T4 actuellement commercialisés par Fujitsu ou Oracle par exemple implémentent cette architecture.

Les améliorations

Pilotes graphiques pour vos PC

Avec cette version du noyau, Intel comme Nouveau posent les bases pour des développements futurs qui devraient être intéressants.

Intel

Du côté d'Intel pour commencer, outre la poursuite de l'implémentation de la gestion des prochains processeurs Haswell (successeurs d'Ivy Bridge) et Valley View (SoC à base de processeur Atom) – qui utilisent tous deux un cœur graphique de même génération que celui équipant les actuels processeurs Ivy Bridge (Gen7) – et diverses améliorations sur les architectures existantes, on signalera surtout l'importante réécriture du code gérant les modes d'affichage (mode-setting) afin d'améliorer la gestion des interfaces DisplayPort. Ce travail permettra à l'avenir d'autres améliorations comme le projet Fastboot qui – comme son nom ne l'indique pas – évite le désagrément visuel des changements de résolutions successifs au démarrage, en prenant le contrôle de l'affichage tout de suite après le BIOS ou le chargeur d'amorçage (une arlésienne du monde Linux). Suite à l'annonce de ces changements sur son blogue, Daniel Vetter (blogue) a dû se justifier auprès des *BSDistes en colère qui craignaient que les 18 mois passés à porter l'ancien code n'aient servi à rien. Au final, la situation ne serait pas aussi désolante a-t-il expliqué, la base du code n'étant pas touchée.

Également, après avoir été activé sur Ivy Bridge (Gen7, Linux 3.2) puis Sandy Bridge (Gen6, Linux 3.4), le mode RC6 (mode de gestion d'énergie qui passe en veille profonde la partie graphique du processeur en cas d’inactivité) est activé pour les processeurs Clarkdale et Arrandale (tous deux équipés d'un cœur graphique Gen5 Ironlake).

Nouveau (pilote libre pour puces Nvidia)

En parlant de réécriture, difficile de ne pas évoquer le travail de réécriture d'une large portion du code de Nouveau par Ben Skeggs (Live Journal, Google+) pour le compte de Red Hat (des milliers de lignes de code ont été changées à cette occasion). Ne vous attendez pas pour autant à des nouveautés extraordinaires en termes de fonctionnalités ou de performance, du moins à ce stade. Il s'agit avant tout d'un travail de restructuration du code à partir de l'expérience accumulée ces dernières années et qui facilitera les développements futurs, comme l’amélioration de la gestion de l'énergie en permettant d'identifier plus facilement les parties du GPU actives ou non à un moment donné, ou l'implémentation du SLI. Ce travail fait, Ben Skeggs s’attelle à présent à la gestion de la fréquence de la puce (une autre façon d'optimiser la gestion de l'énergie) et à celle des modes d'affichage, de sorte que nous devrions voir le résultat de ce travail prochainement.

De son côté, Martin Peres alias mupuf (blogue, page recherche, Google+), doctorant au Laboratoire Bordelais de Recherche en Informatique (LaBRI), œuvre également sur la gestion de l'énergie (pour therm et fanctrl) et a introduit un mécanisme de contrôle rudimentaire du ventilateur, à deux positions : AUCUN et MANUEL. Comme leurs noms l'indiquent, le premier signifie que le pilote n’intervient pas et le second permet à l'utilisateur de définir la vitesse de rotation et ainsi de soulager ses oreilles. Il s'agit d'une première étape vers la gestion automatique du ventilateur qui devrait être introduite dans Linux 3.8.
Pour en savoir plus, n'hésitez pas à lire le passionnant entretien qu'il a récemment donné dans nos colonnes (vous y découvrirez également comment le projet Nouveau est organisé).

Linux 3.1 avait vu Ben Skeggs triompher du microcode des puces Fermi : dorénavant Nouveau ne dépendrait plus du microcode non-libre de Nvidia pour ces puces. Cette fois c'est le microcode des puces Kepler que Ben Skeggs a réussi à libérer ! C'est important car cela permet d'avoir ces cartes immédiatement fonctionnelles dans nos distributions, sans avoir à intégrer des morceaux de code non-libres dont la redistribution peut être soumise à condition. Ce travail n'est cependant pas encore terminé, car l'utilisation d'applications OpenGL telles que gnome-shell est encore très instable.

Radeon (pilote libre pour puces ATI/AMD)

Les principales nouveautés sont :

  • La série des Radeon HD 6900, nom de code Cayman, utilise désormais une mise à jour asynchrone des pages de table de la Mémoire Virtuelle
  • Gestion d'une page de table à 2 niveaux pour économiser encore un peu plus de mémoire.
  • Gestion des PLL améliorées.

Lorsqu'au moins deux écrans partageant une PLL compatible sont connectés, le système n'utilisera désormais plus qu'une seule horloge pour gérer les multiples affichages. Ceci afin d'optimiser la gestion de la batterie.

  • Gestion native du rétroéclairage pour les systèmes ATOMBIOS.
  • Gestion ACPI améliorée pour mieux interagir avec le GPU.
  • La fonction de rétroéclairage est corrigée sur certains ordinateurs portables.
  • Documentation des interfaces ACPI d'AMD
  • Nettoyage de code et corrections de bugs.

Systèmes de fichiers

Btrfs

Les modifications clés pour cette version 3.7 de Linux concernent notamment la nouvelle technique hole punching (comme EXT4 et d'autres systèmes de fichiers auparavant, Btrfs peut désormais désallouer les blocs mémoires d'un fichier : cette technique de « perforation » est intéressante notamment pour les logiciels de virtualisation, en leur permettant de désallouer l'espace mémoire occupé par un fichier supprimé depuis un hôte – voir le commit de Chris Mason "add hole punching"), des corrections du code send/receive qui a été introduit avec la version précédente du noyau (cette fonction donne la possibilité aux programmes de l'espace utilisateur de réaliser une différence entre deux snapshots, de sauvegarder celle-ci dans un fichier et d'effectuer des opérations de restauration ; cette fonctionnalité est particulièrement intéressante pour la réalisation de backup incrémental, atomique), des performances améliorées pour fsync (spécialement pour les machines virtuelles installées sur une partition Btrfs – voir le commit de Chris Mason "turbo charge fsync" – mais cela ouvre aussi la voie à d'autres améliorations de performance comme celle concernant les écritures synchrones : voir le commit de Chris Mason "improve fsync by filtering extents that we want") et, enfin, une augmentation du nombre de liens durs pointant vers un même fichier (il est désormais possible d'avoir non plus 20, mais jusqu'à 65 536 liens durs pointant vers un même fichier).

Ext4

Laissons la parole à Theodore Ts'o, lui-même, pour évoquer les modifications apportées à son bébé (propos traduits par nos soins) :

La grosse nouveauté ajoutée cette fois-ci est la gestion du redimensionnement à la volée via la fonctionnalité meta_bg (metablock group feature). Cela nous permet de redimensionner les systèmes de fichiers de taille supérieure à 16 To. En outre, d'une manière générale, la vitesse du redimensionnement à la volée s'en trouve accrue.
Nous avons aussi corrigé un certain nombre de concurrences critiques, dont certaines pouvaient aboutir à un interblocage, dans les entrées/sorties asynchrones d'ext4 et la défragmentation à la volée, grâce au bon travail de Dmitry Monakhov.
Il y a aussi eu la correction d'un grand nombre de bogues mineurs et un nettoyage du code réalisé par d'autres contributeurs de ext4, dont un bon nombre soumettait des corrections pour la première fois.

En marge des modifications prévues, il y a celles qui n’étaient pas prévues… Un bogue du système de fichiers dans la version 3.6 du noyau a fait s'allumer beaucoup de pixels sur les écrans alors que celui-ci ne survient que dans certaines conditions particulières et rares, et avec des options expérimentales activées. Rassurez-vous ce bogue a été débusqué et corrigé dans cette version et vous pouvez à présent remettre le niveau d'alerte sur DEFCON 4 ou 5. Ce bogue aura au moins permis de faire un peu d'humour puisque Theodore Ts'o l'a dénommé « le bogue Lance Armstrong » compte tenu de sa caractéristique : bloquer les alertes, malgré un comportement anormal.

ALSA

Les nouveautés consistent en quelques nouvelles fonctionnalités pour les pilotes audio incluant des optimisations de la consommation électrique à la volée :

  • la plupart des pilotes audio utilisent la nouvelle API d'économie d'énergie ; le très courant pilote audio HD sait à présent optimiser la consommation électrique à la volée (l'option power_save de sysfs peut aussi être utilisée manuellement à cet effet), la gestion de la consommation électrique à la volée du pilote ALSA HDA est améliorée ;
  • le pilote audio HD a vu son code de chargement de firmware réécrit ;
  • nouveaux pilotes pour Wolfson Microelectronics Bells, Wolfson Microelectronics WM0010 et DA9055.

Réseau

Les nouveautés sont ici assez nombreuses :

Gestion du NAT en IPv6

À l'origine, la position de l'ancien mainteneur de netfilter, Harald Welte, était qu'il faudra lui passer sur le corps avant que la gestion du NAT en IPv6 soit intégrée. Les temps ont changé depuis, et Harald Welte n'est plus le mainteneur en chef de netfilter. Depuis, une certaine variante de NAT IPv6 a été normalisée par l'IETF dans la RFC6296, qui résolvait une partie des problèmes que posait le NAT en IPv4. La position de Harald Welte s'est assouplie, et c'est finalement Patrick McHardy, le mainteneur en chef actuel, qui fournira l'implémentation du NAT IPv6, après qu'il a été admis par l'équipe de développement qu'il y avait des cas d'utilisation légitimes, et qu'avoir une seule implémentation était préférable. Ces patches n'implémentent pas que la RFC6298, mais aussi le NAPT tel qu'il est utilisé en IPv4.

Inutile de préciser que, avant même que la série de patches soit intégrée dans la branche principale, celle-ci a déjà provoqué de vives réactions, notamment à l'IETF.

TCP Fast Open côté serveur

Alors que la gestion de TCP Fast Open côté client (celui qui initie la connexion) est déjà intégrée dans le noyau Linux 3.6, la gestion côté serveur a été intégrée dans ce noyau 3.7.

Pour rappel, le but de TCP Fast Open est de réduire le temps de connexion lors d'une ouverture de session TCP, en utilisant une poignée de main (en anglais : handshake) à deux paquets au lieu de trois. Pour cela, un cookie doit être échangé entre le client et le serveur lors d'une poignée de main précédente.

VXLAN

Bien que VXLAN soit encore à l'état de brouillon à l'IETF, le noyau 3.7 gère maintenant ce protocole. VXLAN est un moyen de déployer un réseau virtuel prenant en charge les VLAN, au-dessus d'un réseau IPv4 classique.

VXLAN permet d'utiliser jusqu'a 16 millions de VLAN différents, au lieu des 4094 VLAN traditionnels. Cela est intéressant pour les opérateurs de clouds, car ils isolent souvent leurs clients entre-eux, en les mettant sur des VLAN différents et sont gênés lorsque le nombre de clients à servir dépasse 4094, surtout lorsque certains clients demandent plusieurs VLAN.

Enfin, le fait que VXLAN soit au-dessus d'un réseau IP permet d'alléger la charge qui pèse sur les switchs, qui n'ont plus à gérer les adresses des machines virtuelles, le routage étant déporté au niveau des hôtes, à une couche au dessus d'IP.

Autres améliorations réseau

Quelques améliorations sur les espaces de noms réseau ont été intégrées dans le noyau 3.7 : l'implémentation du protocole SCTP et le commutateur virtuel openvswitch tiennent maintenant compte de ces espaces réseau. Rappelons que les espaces de noms réseau permettent de créer une pile réseau virtuelle afin d'isoler certaines interfaces ou configurations réseau, pour ne les rendre disponibles qu'à certains processus. Cela est notamment utilisé dans les conteneurs lxc.

L'implémentation des tunnels GRE a également subi quelques améliorations : il est maintenant possible d'utiliser IPv6 dans les tunnels GRE, et les interfaces GRE gèrent maintenant le Generic Receive Offload, qui permet de grouper des paquets similaires afin de factoriser le traitement de ces paquets.

Enfin, en bref, le filtre BPF gère maintenant les opérations modulo et XOR, le MTU par défaut de l'interface lo passe de 16 Kio à 64 Kio, la gestion de la mémoire utilisée pour stocker les données des paquets a été optimisée et le module team, l'évolution à long terme du bonding, gère maintenant les interfaces non-ethernet, comme par exemple les tunnels IP.

Perf

perf, le sous-système d'évaluation des performances et ses outils ont reçu d'importantes améliorations avec ce nouveau noyau Linux 3.7.

Ingo Molnar rapporte lors de sa demande d'inclusion que plus de 30 contributeurs ont pris part aux centaines de commits. La majeure partie de ces changements concerne les outils d'analyse.

Les améliorations les plus notables de cette version 3.7 concernent un nouvel outil d'analyse perf kvm, un outil d'enregistrement des performances de l'ensemble du système, corrections d'UProbes, possibilité de compiler perf pour les systèmes Android, la fonction ftrace est étendue pour devenir dynamique, les performances de perf sont améliorées, support de l'analyse des événements par groupe, et plus encore.

Beaucoup d'améliorations concernent l'infrastructure du sous-système perf de Linux, comme souligné par la demande d'inclusion.

UAPI : Éclatement des fichiers d'en-tête

UAPI est l'acronyme de Userspace API (API étant lui-même un acronyme).

Cette modification, que l'on doit à David Howells (travaillant pour Red Hat et à qui l'on doit également la sécurisation des modules complémentaires du noyau évoquée ci-dessus), vise à séparer plus finement les fichiers d'en-tête (en anglais : header) du noyau, entre ceux à destination de l'espace utilisateur et ceux à usage interne uniquement. Cette modification permet de résoudre le problème d'en-tête incluant un en-tête qui inclut le premier en-tête (problème dit du header spaghetti) et qui empêchait David Howells de pouvoir marquer certaines fonctions inline (mot clé en C permettant de remplacer l'appel d'une fonction par le corps de celle-ci, pour gagner en performance).

Cette tâche étant colossale (583 fichiers modifiés pour 32928 insertions et 30367 suppressions), sa réalisation a été automatisée à l'aide de scripts sur lesquels a porté en fait le plus gros du travail.

À condition de maîtriser l’anglais, vous pourrez obtenir de plus amples informations à ce sujet sur LWN.

C'est la deuxième grosse modification des en-têtes du noyau, après celle de la version 3.4, qui n'avait pas été trop mal accueillie. En revanche, celle-ci a mis du temps avant d'être incluse (elle était superbement ignorée lors des demandes de pull des noyaux précédant) et a valu à son auteur la mise au point suivante de la part de Linus :

David
Je veux qu'il soit parfaitement clair que si tu proposes un jour un nouveau nettoyage d'envergure des fichiers d'include, je répondrai « b*rdel non » et te bloquerai de mes courriels à jamais. D'accord ? Alors ne t'en donne pas la peine. Nous en avons terminé avec ce genre de jeux. Pour toujours. Ça n'en vaut pas la peine, ne suggère plus jamais d'autres « nettoyages ».

Statistiques

En ce qui concerne les statistiques du cycle de développement du noyau 3.7, le site LWN a publié son traditionnel article récapitulatif.
En termes de patches, le total s’établit à 11 982, alors qu’il était de 10 226 pour le noyau précédent. C’est un chiffre très élevé, puisque seul l'antique noyau 2.6.25 le dépasse avec 12 243 patches. Si l'on considère uniquement la période de merge (donc avant la sortie de la RC1), on a même un record absolu avec 10 409 patches intégrés par Linus.
En seulement 71 jours, ce sont environ 719 000 lignes de code qui ont été ajoutées et 395 000 supprimées, pour un accroissement total d’environ 324 000 lignes.

Selon les statistiques du site remword, 1 316 personnes différentes ont participé à l'écriture des patches de ce nouveau noyau (1 251 développeurs pour le précédent). Le contributeur le plus prolifique est encore une fois H. Hartley Sweeten avec 417 patches portant sur le nettoyage du sous‐système Comedi (périphériques d’acquisition de données).
Un autre contributeur notable de ce cycle est Al Viro qui, avec 179 patches, continue son travail de refactorisation et de nettoyage de la couche VFS.
En termes de lignes de code, c'est bien entendu David Howells qui l'emporte avec son projet d'éclatement des fichiers d'en-tête évoqué plus haut.

C'est maintenant la période de merge du noyau 3.8 qui s'ouvre et Linus a déjà annoncé qu'elle se fermerait un peu plus tôt que d'habitude, pour ne pas se télescoper avec les vacances de Noël. Si vous avez des branches Git à lui envoyer, dépêchez-vous ou craignez son courroux !

  • # Déjà en test... et Linux a gagné !

    Posté par (page perso) . Évalué à  10 . Dernière modification : le 13/12/12 à 09:16

    Je viens de voir qu'il y a quelques instants, la mise à jour semi-automatique de Mageia a installé le nouveau noyau et m'a demandé de relancer les machines. Ce que j'ai fait et j'ai commencé à le tester. La gestion de fréquence du CPU de mon vieux portable, un Pentium 4, ne fonctionne toujours pas alors qu'elle fonctionnait il y a quelques années, mais c'est peut être cpufreq qui est le coupable.

    Mon propos est d'exprimer mon admiration pour la vitesse de réaction et de propagation du logiciel libre. Un système propriétaire ne peut plus rivaliser avec les logiciels libres lorsque ceux-ci ont atteint une taille importante. C'est ce que HP, IBM et bien d'autres ont compris et c'est pour cela qu'ils contribuent tous à la Fondation Linux. Cette puissance extraordinaire du développement collaboratif est à l'origne d'une réflexion que j'ai pu entendre récemment : Si les gens sont moins passionnés qu'il y a une douzaine d'années, c'est parce que Linux a gagné. Plus besoin de de battre.
    Que Linux ait gagné, oui, je le crois mais est-ce que les logiciels libres ont gagné ? Je crois que leur combat durera encore pas mal de temps.

    • [^] # Re: Déjà en test... et Linux a gagné !

      Posté par (page perso) . Évalué à  10 .

      La gestion de fréquence du CPU de mon vieux portable, un Pentium 4, ne fonctionne toujours pas alors qu'elle fonctionnait il y a quelques années, mais c'est peut être cpufreq qui est le coupable.

      Ton portable ne gère pas probablement pas la fréquence CPU, mais celle du bus mémoire : le Pentium4-M n'ont pas de gestion de l'énergie intégrée. Bref, la gestion qui fonctionnait avant consiste juste à faire dormir le CPU 50% du temps, rendant la machine désagréable à utiliser.
      Cela est maintenant refusé par défaut par le pilote "cpufreq_ondemand" car la latence est trop grande. (Fais un dmesg| grep demand pour confirmer).

      ⚓ À g'Auch TOUTE! http://agauch.fr

      • [^] # Re: Déjà en test... et Linux a gagné !

        Posté par (page perso) . Évalué à  4 .

        Effectvement, tu as raison : too long transition latency… fall back to performance. Cela signifie que je n'aurai plus une grande autonomie sur batterie car en plus, cette dernière est en fin de vie.
        Mon problème est résolu, même si ce n'est pas ce que je souhaitais…
        Merci José

        • [^] # Re: Déjà en test... et Linux a gagné !

          Posté par . Évalué à  10 .

          Passer à 50% de fréquence cpu peut être plus couteaux que de rester à 100% et de couper de temps à temps. Si le cpu ralentit, c'est rarement le cas du bus mémoire et des mémoires caches, ce qui augmente l'énergie par cycle de cpu. Si on considère qu'une tache a besoin d'un nombre fixe de cycles, la tache prend plus d'énergie. La baisse de fréquence utilisé par intel était une protection thermique au début, pour éviter la destruction du cpu.

          "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

          • [^] # Re: Déjà en test... et Linux a gagné !

            Posté par . Évalué à  2 .

            J'adore tes commentaires, j'apprends à chaque mot ! :)

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

    • [^] # Re: Déjà en test... et Linux a gagné !

      Posté par (page perso) . Évalué à  6 .

      La masturbation est interdite en public. Monsieur Jarillon, veuillez ranger votre petit module aux yeux du public, c'est indécent !

      Au passage, je saisis pas trop le passage entre le premier paragraphe parlant d'une régression et le deuxième qui commence par "Mon propos est d'exprimer mon admiration pour la vitesse de réaction" … heuuu… plait-il ?! (extrapolé dans le monde des fruits et légumes: "Bon, j'ai installé l'upgrade du iBule, j'ai les boutons qui ne marchent plus; [mais] Mon propos est d'exprimer mon admiration pour la vitesse de réaction et de propagation du logiciel propriétaire"; Dans le monde militaropoétique cela se traduit par "Ne laissez pas le famas philosophique au petit, il est capable de se tirer une balle argumentaire dans le pied"

      ps: Pierre, je t'aime malgré tout ;-) smouaack

  • # Bravo!

    Posté par (page perso) . Évalué à  10 .

    Encore une excellente dépêche de patrick_g!

    Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

    • [^] # Re: Bravo!

      Posté par (page perso) . Évalué à  10 .

      Mouarf je l'attendais celle-là ;-)
      Bon, trêve de plaisanterie, c'est quand même bien de changer un peu d'auteur non ? Sur cette news je n'ai rédigé que le paragraphe sur les stats et tout le reste vient d'antistress et des autres contributeurs.
      Bravo à eux et merci pour leur boulot !

      • [^] # Re: Bravo!

        Posté par . Évalué à  6 .

        Le compte patrick_g a maintenant 10 ans !
        Joyeux anniversaire.

      • [^] # Re: Bravo!

        Posté par . Évalué à  10 .

        Patrick_g c'est un peu notre Linux Torvald à nous,

        au debut il etait seul, devait faire tout le boulot
        et puis les volontaires sont arrivés,
        les participations augmentent,
        et Patrick_g n'a plus alors qu'à signer en bas de la page ;)

        Bon anniversaire à toi Patrick.

        • [^] # Re: Bravo!

          Posté par (page perso) . Évalué à  7 . Dernière modification : le 12/12/12 à 14:19

          Tu te trompes, notre équivalent de Linux Torvald c'est Patrix_g (le gaulois).

        • [^] # Re: Bravo!

          Posté par . Évalué à  4 .

          Il va bientôt falloir écrire des dépêches sur l'élaboration des dépêches noyau !
          À quand est fixée la période de merge pour la dépêche sur 3.8 ?

          • [^] # Re: Bravo!

            Posté par (page perso) . Évalué à  3 .

            Il va bientôt falloir écrire des dépêches sur l'élaboration des dépêches noyau !

            Tu rigoles, mais j'ai commencé à compléter le processus de rédaction sur Template Des News Noyau de ce que j'en ai vu et ça me donnait justement cette idée : d'avoir un retour d'antistress< et des participants à la rédaction de ce genre de dépêche (dans une dépêche collaborative bien sûr dans l'espace de Rédaction :D).

            • [^] # Re: Bravo!

              Posté par (page perso) . Évalué à  4 .

              C'est une bonne idée, même si le plus simple est comme souvent d'observer avant de se lancer.
              Idéalement ce que j'aimerais pour des dépêches aussi longues et techniques c'est que chacun prenne une rubrique et la dirige, et au final on créditerait le responsable de chaque rubrique. Ça permet notamment à des contributeurs d'exposer un avis critique en leur nom.

            • [^] # Re: Bravo!

              Posté par . Évalué à  2 . Dernière modification : le 13/12/12 à 12:06

              J'aurais du commencer par lire ce lien avant de me lancer je me serais évité des questions.

              +1 bonne idée.

  • # c'est beau

    Posté par . Évalué à  10 .

    La dépèche de la sortie d'un noyau est toujours un tendre moment, de la lecture, des étoiles pleins les yeux… Et après je retourne à la RHEL … avec son noyau en 2.6.32.

    Merci à tous pour me vendre ma petite dose de rêve !

  • # RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

    Posté par . Évalué à  10 .

    Depuis quelques mois, c'est devenu presque habituel de ma part de publier des versions d'un aéroport alors que je voyage quelque part. Cette -rc n'y échappe pas. Reste libre, petit point d'accès de l'aéroport de Portland !

    Ok, donc c'est maintenant officiel : Linus ne publiera jamais une RC depuis une gare ou un aéroport français ! :-/
    Monde de merde…

    • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

      Posté par (page perso) . Évalué à  4 .

      Le wifi gratuit de l'aéroport de Toulouse marche très bien. En tout cas, je n'ai jamais eu de problème avec.

      • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

        Posté par . Évalué à  10 .

        Le wifi gratuit de l'aéroport de Toulouse marche très bien.

        Et personne ne l'a encore dénoncé à la justice ? J'espère que la Hadopi trainera l'aéroport de Toulouse devant les tribunaux pour "défaut de sécurisation de l'accès à Internet".

        Heureusement que la loi nous rappelle où sont les vraies valeurs. On commence par ouvrir un spot wifi libre, on passe ensuite à la critique du système de brevets, et on finit par vouloir donner les livres électroniques ou la musique qu'on a achetés, pardon, loués.

        • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

          Posté par (page perso) . Évalué à  6 .

          Et personne ne l'a encore dénoncé à la justice ? J'espère que la Hadopi trainera l'aéroport de Toulouse devant les tribunaux pour "défaut de sécurisation de l'accès à Internet".

          Je ne sais pas pour Toulouse, mais dans plusieurs autres aéroports que j'ai testé, le gratuit ne veut pas dire non authentifié : envoi dans code d’authentification par SMS (numéro de téléphone mobile demandé, c'est tout). Bref, rien à voir, on peut très bien faire du Wifi gratuit tout en respectant HADOPI ou autre législation des fournisseurs d'accès, merci de ne pas tout mélanger (surtout vu que le défaut de sécurisation concerne des particulier et non des fournisseurs de service comme les aéroports), ça décrédibilise plus qu'autre chose.

          • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

            Posté par . Évalué à  1 .

            mais du coup il n'est pas libre au sens Free Speech, il est juste gratuit au sens Free Beer

            • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

              Posté par (page perso) . Évalué à  4 .

              Je ne vois pas en quoi être responsable de tes conneries change quoi que ce soit à ta liberté.
              C'est libre au sens Free Speech, mais effectivement pas libre au sens Freenet / anarchisme / je ne sais quoi.
              Merci de ne pas mélanger "libre au sens Free Speech" avec la liberté d'insulter / contrefaire / pirater / que sais-je, le libre ce n'est pas l’irrespect des lois.

              Ou veux tu dire que respecter les lois n'est pas être libre de ton point de vue? Soyons clair sur tes motivations…

              • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

                Posté par . Évalué à  2 .

                je parles juste du coté "linguistique"

                pour une borne wifi, devoir entrer un code WPA ou devoir passer par un proxy authentifiant,
                dans les deux cas ce n'est pas etre "libre" d'utiliser la borne, au sens "free speech".

                apres que l'acces à la borne soit payant ou gratuit, c'est le coté "free beer"

                • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

                  Posté par (page perso) . Évalué à  3 .

                  pour une borne wifi, devoir entrer un code WPA ou devoir passer par un proxy authentifiant,
                  dans les deux cas ce n'est pas etre "libre" d'utiliser la borne, au sens "free speech".

                  Ah bon… Nous n'avons pas la même idée de "free speech" sans doute, une source pour préciser que ton idée est plus généralisée que la mienne, ou c'est subjectif entre nous avec personne de "mieux" que l'autre?

                  Pour moi en tous cas, demander un numéro de téléphone n'a absolument rien à voir avec un blocage de "free speech", mais alors rien du tout, je ne vois pas du tout le rapport, ou alors la GPL n'est pas libre car elle me file des contraintes "je ne suis pas libre de faire comme je veux" (pour moi, la GPL est libre malgré ses contraintes).

                  • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

                    Posté par . Évalué à  2 .

                    la GPL ne te demande aucun identifiant pour faire ensuite ce que tu veux du code que tu as recuperé

                    je n'ai pas besoin de donner mon identié (login/pass ou numero de telephone/imei) pour utiliser un code source.

                    mais je suis peut-etre en plein delire avec le wifi "libre" dans les aeroports qui serait en fait une mauvaise traduction de "free wifi in airport" qui aurait du etre "wifi gratuit dans les aeroports"

                    • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

                      Posté par . Évalué à  9 .

                      En même temps ca ne rime à rien de mélanger les choux et les carottes. Comment veux comparer la license d'un logicel avec les conditions d'accès à un service ?

                      La loi demande que l'utilisateur du service soit identifié. Vouloir appliquer bêtement la signification de "libre" utilisé pour les licenses n'a aucun sens.

                      je n'ai pas besoin de donner mon identié (login/pass ou numero de telephone/imei) pour utiliser un code source.

                      Non mais pour utiliser le service qui est d'"accéder au code source" tu peux mettre en place exactement la même procédure (ne distribuer qu'aux clients identifiés). Lesdit clients faisant après ce qu'ils veulent.

                    • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

                      Posté par (page perso) . Évalué à  3 . Dernière modification : le 12/12/12 à 17:06

                      je n'ai pas besoin de donner mon identié (login/pass ou numero de telephone/imei) pour utiliser un code source.

                      Mais est-ce que si on te demandais de le faire, tu considérerais la chose libre?
                      En tous cas c'est considéré quand même comme libre "as a speech" par OSI:
                      http://opensource.org/licenses/NASA-1.3
                      "each Recipient, upon receipt of the Subject Software, is requested to provide Government Agency, by e-mail to the Government Agency Point of Contact listed in clause 5.F., the following information"
                      (note : j'ai subit cette licence que je n'aime pas à caus epar exemple de cette clause non justifiée pour du code)

                      De la même manière, ça arrive qu'on te demande ton email pour tout téléchargement de code source libre (voire des fois on te demande de payer, libre != gratuit).

                      Ensuite, ben la loi c'est la loi, et le libre n'est pas au dessus de la loi, c'est tout.

                      Encore une fois, jusqu’à preuve du contraire, ça n'a absolument rien à voir avec le libre. Le libre "as a speech" n'interdit pas de demander un numéro de téléphone (ni de faire payer d'ailleurs), à ma connaissance. J'attends donc que tu me démontres que ton idée est communément admise, en attendant c'est une limitation que tu apportes sur le libre qui est entièrement personnelle. Encore une fois, c'est uniquement fait pour respecter la loi, je ne vois pas pour quelle raison tu imagines que ça empiète sur une quelconque liberté : avec ou sans numéro de téléphone à donner, tu as la même liberté "as a speech" d'utilisation d'une borne Wifi dans les aéroports que chez quelqu'un qui le laisse ouvert à tous. Dans ces aéroports, c'est libre "as a free speech" et "as a free beer".

                    • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

                      Posté par . Évalué à  1 .

                      Non non : il s'agissait bien de libre au sens de libre d'accès, au sens de libre d'accès qui permet par exemple de se connecter quelque part en ssh avec des logiciels standards, sans juste proposer un proxy web tout pourri.

                    • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

                      Posté par . Évalué à  2 .

                      Si tu veux pousser cette comparaison bizarre : si, un accès à Internet "libre", au sens du logiciel, est possible et légal.

                      L'idée, c'est que le fournisseur propose l'accès contre une contrepartie (identité, argent..), ensuite tu peux faire ce que tu veux de cet accès, y compris le partager avec d'autres gens sans rien leur demander. Exactement comme un logiciel libre vendu par son éditeur.

                      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

          • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

            Posté par . Évalué à  3 .

            numéro de téléphone mobile demandé, c'est tout

            Ça marche tout le temps ?

            Je veux dire, il y a des cas « problématique » : numéro étranger, numéro en 07 et non 06, etc. Déjà que pour les mails c'est la merde alors qu'il existe des RFC claire, pour la téléphonie, j'ai même pas envie d'imaginer le bordel.

            • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

              Posté par (page perso) . Évalué à  1 .

              Le dernier que j'ai testé est Genève avec un tel allemand et un tel français, pas de soucis. Les aéroports c'est la base de l'international quand même, et les SMS ont toujours marché ou que j'aille.

              • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

                Posté par . Évalué à  1 .

                Oui enfin selon ton forfait, tu ne reçois pas les trucs a l'étranger, ou tu raque (donc ce n'est plus gratuit)

                Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

                  Posté par (page perso) . Évalué à  1 . Dernière modification : le 12/12/12 à 18:07

                  Peut-être le truc à 2€ de chez Free (faut bien qu'ils se fassent du fric partout), sinon la réception de SMS à l'étranger est quasi-toujours (je met "quasi" pour les cas bizarre) gratuite (pareil pour "l'option monde" que tu oublies peut-être d'activer car tu voulais pas payer je sais pas quoi, mais c'est ton problème la). Faux exemple, à part quelques mecs bizarres, personne ne s'en plaint. Faudrait arrêter un peu avec les 0.1% de gens qui se mettent eux-mêmes des bâtons dans les roues. Tu as une autre idée pour authentifier facilement des gens? Celle-ci marche très bien en tous cas pour pas mal de monde (de la même manière, je peux passer mes virements bancaires ou mes paiement par carte bancaire avec la réception d'un SMS, si pas de SMS pas de virement/paiement)

                • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

                  Posté par (page perso) . Évalué à  3 .

                  La réception de SMS en roaming (avec ton mobile sur un réseau à l'étranger) est gratuite : la norme GSM indique qu'il n'y a pas de garantie de réception du ticket de taxation de terminaison (SMS-MT), ce qui fait que la plupart des opérateurs ont traduit cela par la gratuité de réception des SMS. En revanche quand tu reçois un appel, effectivement tu paies.

                  C'est aussi un peu pour cela que dès que tu te retrouves sur un réseau différent du tiens, tu reçois une floppée de SMS de ton opérateur (en tout cas, c'est le cas chez BouygTel).

                  • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

                    Posté par (page perso) . Évalué à  2 .

                    la norme GSM indique qu'il n'y a pas de garantie de réception du ticket de taxation de terminaison (SMS-MT), ce qui fait que la plupart des opérateurs ont traduit cela par la gratuité de réception des SMS. En revanche quand tu reçois un appel, effectivement tu paies.

                    Rajoute aussi que ça coûte plus cher de demander le consentement du receveur (un SMS pour demander si on acceptes, heu…), au contraire d'un appel (l'opérateur "dépense" pour faire sonner le téléphone, mais le client peut refuser l'appel et ça ne lui coûte alors rien), donc risque de facturation non acceptée par le client, bref ça fait que le SMS n'est pas facturé en réception même à l'autre bout de la planète.

                    • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

                      Posté par (page perso) . Évalué à  3 .

                      Rajoute aussi que ça coûte plus cher de demander le consentement du receveur (un SMS pour demander si on acceptes, heu…)

                      Pourtant, les MMS sont bien facturés à la réception (enfin, c'est ce qui est spécifié, je n'en ai jamais envoyé ni reçu).

                      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                      • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

                        Posté par (page perso) . Évalué à  2 .

                        La dernière (et seule fois) que j'ai testé le MMS, il t'envoie un SMS et te demande si tu acceptes les MMS (accord donc du client). Ca vaut le coup de d'envoyer un SMS pour facturer un MMS (c'est plus cher). Mais pas d'envoyer un SMS pour facturer un SMS. Maintenant, je suis toute ouïe : vous avez un nom d'opérateur et de contrat avec les SMS reçus facturés? Parce que la, on parle dans le vent, de la pure théorie et je n'ai jamais croisé personne que ça dérange de recevoir des SMS à l'étranger…

                        • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

                          Posté par . Évalué à  3 .

                          Maintenant, je suis toute ouïe : vous avez un nom d'opérateur et de contrat avec les SMS reçus facturés?

                          La quasi-totalité des opérateurs canadiens !
                          Là-bas, la réception gratuite des SMS est une option payante…

                          Il faut faire gaffe à ne pas généraliser trop vite notre système français !

                          • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

                            Posté par (page perso) . Évalué à  2 .

                            Je regardais pas que français, mais Allemand, suisse, etats-uniens…
                            Quel prix pour la réception?
                            Comment ils font pour gérer les SMS non solicités? Je vais me faire un plaisir d'envoyer des SMS ;-)
                            Un lien sur les conditions tarifaires?

                            • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

                              Posté par . Évalué à  1 .

                              J'étais au Québec en 2007, et je me souviens qu'alors il y avait de grande pubs annonçant des nouveaux forfaits "Appels entrants illimités", chose qui pour moi allait de soi !

                              En bref, là bas, sans un forfait de ce type, si quelqu'un t'appelle pour te faire de la pub, tu payes également !

                              Ça a sûrement évolué depuis.

                            • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

                              Posté par . Évalué à  1 .

                              Il va falloir que je fouille pour retrouver ça, je ne suis resté que deux mois chez un opérateur canadien (KOODO Mobile).
                              Leur principal argument de vente était justement celui-ci : être le seul opérateur du pays à proposer la réception gratuite des SMS sans besoin de payer un supplément sur l'abonnement.

                      • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

                        Posté par (page perso) . Évalué à  2 .

                        les MMS ne passent pas par le SMS-C (centrale de gestion des SMS) à ma connaissance, c'est apparu avec le Edge et le GPRS (2,5G…) je n'ai plus trop suivi à cette époque :-)

                        Si tu mets la main sur une des dernières versions de la TADIG 57 (flemme de m'inscrire à http://www.gsma.com/aboutus/gsm-technology/roaming/billing-standards/what-is-tap-3/ :p) cela devrait être décrit (en tout cas, le volet interopérabilité et facturation). Je ne me rappelais plus qu'avec le TAP3 on était passé du format texte à l'ASN.1 (iirc c'est la DataClearingHouse qui avait géré la transition).

          • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

            Posté par (page perso) . Évalué à  1 .

            Je ne sais pas pour Toulouse […] envoi dans code d’authentification par SMS

            Pas le cas à Toulouse lors mon dernier passage: rien n'est demandé, c'est "libre" accès.

        • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

          Posté par (page perso) . Évalué à  7 .

          En même temps « wifi gratuit » ça veut juste dire que le wifi est gratuit, pas qu'il y a un accès à du vrai Internet derrière.

    • [^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure

      Posté par . Évalué à  4 .

      Sauf une une gentille moule lui propose un accès en tethering après l'avoir reconnu ;)
      ça serait la grande classe.
      " j'ai contribué à la publication du denier noyau :o "

  • # Nouveau rédacteur

    Posté par (page perso) . Évalué à  10 .

    Tiens, patrick_g passe la main. Et Antistress reprend la suite avec brio ! Bravo !

    • [^] # Re: Nouveau rédacteur

      Posté par (page perso) . Évalué à  7 .

      Ben en fait j'ai été grandement aidé, merci à tous les contributeurs.
      D'ailleurs seul patrick_g est capable de faire une dépêche comme ça tout seul (il vient du futur).
      Cela dit je m'y suis collé cette fois : qui s'y collera la prochaine fois ?

  • # Btrfs

    Posté par . Évalué à  2 .

    Donc Btrfs n'est pas encore stable ? Je crois qu'Oracle espérait le stabiliser pour fin 2012.

    Je ne peux par contre m'empêcher de voir un écho entre les nouveautés de cette version et le bench qui est passé dans les journaux il y a peu : https://linuxfr.org/users/xunfr/journaux/filesystem-benchmark-ssd-vs-hdd

    Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

    • [^] # Re: Btrfs

      Posté par . Évalué à  6 .

      Rien n'est perdu, il reste encore dix-neuf jours. Courage, Oracle !

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Btrfs

        Posté par . Évalué à  7 .

        Sachant que Chris Mason ne bosse plus chez Oracle, Oracle n'a plus grand chose avoir avec BTRFS. Ils ont ZFS depuis le rachat de SUN.

        • [^] # Re: Btrfs

          Posté par . Évalué à  4 .

          Tiens je n'étais pas au courant. C'est une bonne nouvelle de ne pas avoir deux des grands FS libres chez la même PME.

          Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

          • [^] # Re: Btrfs

            Posté par (page perso) . Évalué à  3 .

            à plus de 100000 employés, j'espère que tu ne comptes plus vraiment Oracle comme une PME

            « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

    • [^] # Re: Btrfs

      Posté par (page perso) . Évalué à  1 .

      phoronix a fait quelques bench, ext4 est loin de tout le reste
      btrfs est à la traine

      j'avais un hd en btrfs, je l'ai remis en ext4, j'avais trop de lag… le tout sur un core 2 duo

      • [^] # Re: Btrfs

        Posté par . Évalué à  5 .

        ext4 est loin de tout le reste

        C'est-à-dire ? Devant ou derrière ?

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Btrfs

        Posté par (page perso) . Évalué à  5 .

        phoronix

        LOL

        * Ils vendront Usenet quand on aura fini de le remplir.

        • [^] # Re: Btrfs

          Posté par (page perso) . Évalué à  9 .

          toujours plus intéressant à les lires que te lire…

          • [^] # Re: Btrfs

            Posté par (page perso) . Évalué à  10 .

            Faut quand même avouer que les benchmarks de Phoronix sont une vaste blague. Les devs Linux n'en tiennent aucun compte (cela a été dit plusieurs fois sur la LKML).

            • [^] # Re: Btrfs

              Posté par (page perso) . Évalué à  5 .

              si tu peux me donner d'autre source pour comparer ce que vaut linux sur différent cpu arm vs intel, je suis preneur

              je rajouterais que s'il faudrait se fier qu'a ce que les devs linux tiennent compte, il n'y aurait peut-être pas d'utilisateur…

              • [^] # Re: Btrfs

                Posté par (page perso) . Évalué à  5 .

                "Les gens de chez Gnome sont des nazis de l'interface!"

                Moi je trouve qu'ils ont des opinions mesurées et réfléchies.
                Mais moi, je sors… ------->[ ]

            • [^] # Re: Btrfs

              Posté par . Évalué à  7 .

              Faux, ils en tiennent compte quand ceux-ci sont faits proprement (rare) ou quand il y a régression manifeste, c'est arrivé plusieurs fois.

  • # Device tree

    Posté par . Évalué à  9 .

    Le travail réalisé consiste à sortir la description du matériel du noyau et à la reporter dans un fichier texte qui lui sera transmis lors du démarrage

    Une simplification un peu rapide. Les device tree ont été abordé précédemment:
    https://linuxfr.org/news/sortie-du-noyau-linux%C2%A02639#toc_34
    https://linuxfr.org/news/le-noyau-linux-est-disponible-en-version%C2%A030#toc_25

    En gros, le fichier de description est bien un fichier texte(platforme.dts), mais il est compilé en une structure de donnée binaire (platforme.dtb), et c’est ce qui est passé par le bootloader. Pour le cas où le bootloader est trop vieux et ne supporte pas le passage de dtb, celle-ci peut-être concaténée à l’image noyau, et celui-ci la charge de lui même. Mais on perd l’intérêt d’avoir une seule image pour plusieurs plateformes.

    • [^] # Re: Device tree

      Posté par (page perso) . Évalué à  7 . Dernière modification : le 12/12/12 à 12:51

      Merci pour la précision, on aurait bien besoin de toi pour les prochaines versions : tu veux bien signer ?
      (question sérieuse)

  • # Bravo pour cette news !

    Posté par . Évalué à  3 .

    Quelqu'un saurait-il si les modification sur NTFS viseraient à l'augmentation des perfs en écriture ? (ou si c'est prévu) je pleure à chaque fois que je dois remplir le disque d'un collègue (10-12Mo/s).
    Et aussi sachant que Linus à une Nexus7, est ce que le support du MTP en natif a des chances de fonctionner (un Galaxy Nexus semble supporté sans rien toucher).

    Encore merci :)

    • [^] # Re: Bravo pour cette news !

      Posté par (page perso) . Évalué à  2 .

      c'est pas déjà supporer?

      mon lecteur mp3 qui employait mtp fonctionnait sous amarok…

      il y avait tout de même une rom pour le transformer en mass storage…

      • [^] # Re: Bravo pour cette news !

        Posté par . Évalué à  1 .

        Bah apriori avec le Nexus7 ça passe pas aussi bien.
        (testé rapidement sur un Galaxy Nexus, il a été monté directement)
        j'ai encore quelques tests à faire avec un dérivé de mtpfs..
        Sinon il y a un petit outil QtAdb qui est assez pratique. (mais nécessite ADB)

    • [^] # Re: Bravo pour cette news !

      Posté par . Évalué à  10 .

      Sans vraiment regarder le changelog ou le code, je dirais que non pour la simple raison que le driver ntfs du kernel est read-only et qu'en gros personne ne l'utilise.
      Tu utilises surement ntfs-3g en espace utilisateur qui se connecte à FUSE au niveau du noyau, mais ntfs-3g n'est pas du ressort de Linux. Il me semble qu'il y a une version commerciale de ntfs-3g plus performante (à vérifier).

      • [^] # Re: Bravo pour cette news !

        Posté par . Évalué à  1 .

        Oui c'est exact! c'est ntfs-3g qui s'occupe de l'écriture.
        Le FAT32 allait pas trop mal il y a quelques temps, mais avec la limitation des 4Go par fichier c'est devenu incompatible avec l'utilisation que je fais des disques externes :/

        • [^] # Re: Bravo pour cette news !

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

          J'ai formaté un disque externe USB en NTFS au lieu de FAT32 pour éviter d'être limité à 4GB par fichier.
          L'étape de formatage était très longue (plus d'une heure de mémoire avec un disque 500GB), et le disque à la fin était protégé en écriture…
          Du coup, je l'ai formaté en Ext4… Comment tu fais pour parvenir à écrire sur tes disques externes NTFS ?

    • [^] # Re: Bravo pour cette news !

      Posté par . Évalué à  1 .

      10-12Mo/s

      Il y a d'ailleurs un truc étrange : c'est entre 10 et 15 Mio/s depuis des années alors que les CPU/RAM/bus/disques sont nettement plus rapides.
      Il y a un limiteur de débit ou quoi ?

      • [^] # Re: Bravo pour cette news !

        Posté par (page perso) . Évalué à  4 .

        Il y a d'ailleurs un truc étrange : c'est entre 10 et 15 Mio/s depuis des années alors que les CPU/RAM/bus/disques sont nettement plus rapides.

        Le disque dur a sa vitesse qui a stagné depuis plus de 5 ans, c'est lui le facteur limitant. Que le CPU, la RAM ou les bus soient plus rapides ne changent pas grand chose à l'affaire du coup sauf dans les disques durs haute performances.
        Car regarde les débits du SSD, c'est tellement rapide que de nombreux bus ne sont pas adaptés pour suivre la cadence… c'est bien la preuve que le facteur limitant se trouve au niveau du disque dur et qu'ailleurs il y a de la marge de manœuvre. ;)

        • [^] # Re: Bravo pour cette news !

          Posté par (page perso) . Évalué à  4 . Dernière modification : le 12/12/12 à 23:52

          Il y a d'ailleurs un truc étrange : c'est entre 10 et 15 Mio/s depuis des années alors que les CPU/RAM/bus/disques sont nettement plus rapides.

          Le disque dur a sa vitesse qui a stagné depuis plus de 5 ans, c'est lui le facteur limitant.

          Vu qu'un pauvre disque 5400 tours que j'ai peut écrire (en NTFS par le driver de chez Microsoft) à 100 Mo/s en NTFS, permet-moi d'éclater de rire devant cette assertion (je ne me permettrai pas de comparer avec des disques 7200 tours).
          Si il y a une limite à 15 Mo/s, ce n'est certainement pas au niveau du matériel.

          • [^] # Re: Bravo pour cette news !

            Posté par . Évalué à  6 .

            Vu qu'un pauvre disque 5400 tours que j'ai peut écrire (en NTFS par le driver de chez Microsoft) à 100 Mo/s en NTFS, permet-moi d'éclater de rire devant cette assertion (je ne me permettrai pas de comparer avec des disques 7200 tours).
            Si il y a une limite à 15 Mo/s, ce n'est certainement pas au niveau du matériel.

            Ça peut être combiné entre matériel et pilote libre : si le pilote libre est codé de façon à faire plus d'accès que prévu (par exemple, il lit plein de données qu'il n'a pas besoin de lire), alors le facteur limitant reste le débit matériel du disque, quel que soit le reste de la machine.

            Ceci dit, étant donné la taille des caches sur les disques durs récents, ça voudrait dire que le pilote va vraiment chercher un gros paquet d'informations un peu partout sur le disque, pour en arriver là.

            THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: Bravo pour cette news !

          Posté par . Évalué à  4 . Dernière modification : le 13/12/12 à 00:13

          Le disque dur a sa vitesse qui a stagné depuis plus de 5 ans

          Il y a 5 ans, un Hitachi Deskstar faisait du 70 Mio/s en écriture séquentielle pour 60 € HT (disque dur d'entrée de gamme pour la bureautique).
          On est actuellement à plus de 120 Mio/s pour 45 € HT. À noter que ce n'est pas plus rapide pour 60 € HT.

          Par contre en aléatoire pur, ça n'a pas beaucoup bougé. Ou pas du tout, je n'ai pas les chiffres en tête.

          • [^] # Re: Bravo pour cette news !

            Posté par (page perso) . Évalué à  0 .

            Quand je parlais de vitesse, c'est la vitesse de rotation qui bouge assez peu et limite les progressions possible dans le domaine du débit.

            • [^] # Re: Bravo pour cette news !

              Posté par . Évalué à  6 .

              Quand je parlais de vitesse, c'est la vitesse de rotation qui bouge assez peu et limite les progressions possible dans le domaine du débit.

              Pas du tout , puisque les plateaux contiennent de plus en plus de données, sans compter qu'on peut aussi multiplier les plateaux.

            • [^] # Re: Bravo pour cette news !

              Posté par . Évalué à  2 .

              La vitesse de rotation est un des moyens d'augmenter le débit, mais le plus efficace reste plutôt la densité des données.
              C'est surtout ca qui progresse.
              De plus l'augmentation de la vitesse est tres fortement limitee par les contraintes physique. (voir les cds de mauvaise qualite qui explosaient dans les lecteurs) La densite des donnees par contre, a encore de belle marge de progression.

  • # md + trim/discard

    Posté par . Évalué à  4 .

    Le support de TRIM/discard pour les SSD dans md (RAID) avait été intégré pendant la merge window (voir http://lwn.net/Articles/519515/). À moins qu'ils n'aient été retiré pendant la phase de rc, ce noyau 3.7 supporte TRIM pour les volumes RAID :)

  • # MODSIGN

    Posté par . Évalué à  -7 .

    C'est marrant si je fais un ctrl+F sur cette page et que je cherche MODSIGN je n'ai rien que le titre qui ressort. A une époque cela aurait fait un boucan de tous les diables sur DLFP da linux french page :) LOL
    Je m'en vais reformater mon pécé uefi sous windows 8

    signé groconar

    • [^] # Re: MODSIGN

      Posté par . Évalué à  4 .

      C'est une option, c'est le propriétaire de la machine (ou son administrateur) qui choisit ce qui peut s'exécuter dans l'OS qu'il a installé. Je suppose qu'il peut lui même choisir les signatures autorisées, par exemple la sienne. Ça n'empêche pas d'installer un autre OS, ou de retirer la vérification des signatures (ou plutôt de ne pas l'installer)

      Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

      • [^] # Re: MODSIGN

        Posté par . Évalué à  3 .

        je voulais juste faire remarquer le delta entre ce que l'on en pensait il y a des années (rappelez-vous de l'histoire de windows vista x64 qui interdit le chargement des pilotes non signés par défaut) et ce que tout le monde à l'air d'en penser aujourd'hui
        Il n'y a personne !

        • [^] # Re: MODSIGN

          Posté par . Évalué à  2 .

          Ça ne me semble pas comparable : là la signature est calculée lors de la compilation. N'importe qui peut télécharger les sources, coller son driver (qu'il soit propriétaire ou non), compiler, et tadam, ça marchera, même avec la signature. Cette signature sert uniquement à limiter le chargement des modules prévus dès la compilation.

          Sauf erreur, la fonctionnalité Vista de son coté t'empêche de charger un driver sans l'accord préalable de Microsoft, qui est d'ailleurs probablement payant.

          Ça me semble radicalement différent, même si le but est probablement similaire.

        • [^] # Re: MODSIGN

          Posté par . Évalué à  3 .

          La différence principale, il me semble que dans un cas c'est Microsoft qui décide qui a le droit de faire un module, et dans l'autre cas c'est celui qui installe l'OS.

          Cela dit je ne vois pas pourquoi tu as été moinssé si violemment.

          Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

    • [^] # Re: MODSIGN

      Posté par (page perso) . Évalué à  3 . Dernière modification : le 14/12/12 à 15:27

      Dans une interview récente que je n'ai pas sous la main, Linus explique que ça fait longtemps que ça aurait dû être fait et que c'est utile d'un point de vue sécurité

      Allez je pertinente tous les intervenants de ce thème car il le vaut bien

      • [^] # Re: MODSIGN

        Posté par . Évalué à  3 .

        Il y a par contre une imprécision dans la dépêche (qui est levée par l'article de lwn lié) : même si la famille d'algo de hash SHA-x est utilisée, il manque la partie signature. SHAx va générer un hash du module, mais ce hash doit ensuite être signé sinon n'importe qui pourrait le régénérer car il n'y a pas de secret dans SHA (contrairement aux HMAC).
        Ici, en fait, à la compilation, make va appeler GPG pour signer avec RSA les modules avec un biclef qui est stocké sur le disque. Le noyau embarque une compréhension limitée du format GPG ainsi que RSA, SHAx et la partie publique du biclef ayant servi à la signature, ce qui lui permet de la vérifier au chargement du module.

  • # A noter pour ceux qui ont du vieux matos

    Posté par (page perso) . Évalué à  7 .

    Le support du 386DX/SX vient d'être supprimé :)

    Commit

    • [^] # Re: A noter pour ceux qui ont du vieux matos

      Posté par (page perso) . Évalué à  5 .

      Ça veut dire que Linux ne tourne plus sur l'archi pour laquelle il avait été créé, originellement ?

      cf. https://www.cs.cmu.edu/~awb/linux.history.html

      […] I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386 […]
      […] It is NOT protable (uses 386 […]
      […] locked into the 386 […]
      […] and it specifically needs a 386 […]
      […] that makes it REALLY 386 dependent […]
      […] I'm working on a free version of a minix-lookalike for AT-386 computers […]
      […] It uses every conceivable feature of the 386 I could find, as it was also a project to teach me about the 386 […]

      ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: A noter pour ceux qui ont du vieux matos

        Posté par (page perso) . Évalué à  -6 .

        Ça veut dire que Linux ne tourne plus sur l'archi pour laquelle il avait été créé, originellement ?

        Comme quoi, l'argument "Linux marche même sur les vieilles machines, il n'enlève jamais une compatibilité" mise en avant contre le Méchant Microsoft qui ne supporte pas tout, ben… C'est faux, Linux fait pareil, il vire les vieilleries aussi, eh eh ;-).

        • [^] # Re: A noter pour ceux qui ont du vieux matos

          Posté par . Évalué à  6 .

          Moi je croyais que c'était l'inverse. On reproche généralement à Microsoft de devoir se trimballer de multiples couches dédiées à assurer la compatibilité avec des trucs antédiluviens.

          Par contre, c'est vrai qu'un Windows qui vient de sortir a toujours besoin du dernier matos à la mode. Sauf pour Windows 7, qui a un peu dérogé à la règle.

          • [^] # Re: A noter pour ceux qui ont du vieux matos

            Posté par (page perso) . Évalué à  9 .

            Moi je croyais que c'était l'inverse. On reproche généralement à Microsoft de devoir se trimballer de multiples couches dédiées à assurer la compatibilité avec des trucs antédiluviens.

            C'est pas sur les même plans en fait, Linux est réputé pour se trimballer le support de vieilleries matérielles (en modernisant continuellement le logiciel qui le contrôle), Windows est réputé pour se trimballer le support de vieilleries logicielles (en figeant les défauts).

            ce commentaire est sous licence cc by 4 et précédentes

          • [^] # Re: A noter pour ceux qui ont du vieux matos

            Posté par . Évalué à  1 .

            Windows 95, 98SE, et ME avaient des requis matériels bien inférieurs à ceux de Windows NT 4 (sorti en 1993), exprès.

            Windows 95 tournait avec 4 Mo de RAM (enfin juste l'OS tout seul). Windows NT 4 Workstation refuse de s'installer avec moins de 64 Mo de RAM.

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

            • [^] # Re: A noter pour ceux qui ont du vieux matos

              Posté par . Évalué à  2 .

              Windows 95, 98SE, et ME avaient des requis matériels bien inférieurs à ceux de Windows NT 4 (sorti en 1993), exprès.

              Sauf que Windows 95 ne succédait pas à NT 4 mais à Windows 3.11 qui avait moins de prérequis.

              Et pareil, 98 / 98SE avait des prérequis supérieurs à 95 (je le sais d'expérience car 95 se lançait sur mon 486 mais pas 98).

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: A noter pour ceux qui ont du vieux matos

            Posté par . Évalué à  -2 .

            Sauf pour Windows 7, qui a un peu dérogé à la règle.

            Euh non c'est juste Vista qui est anachronique. Ce truc a moitié fini à juste exister pour éviter que les entreprises commencent à s'intéresser sérieusement à Linux. Il y a eu en même temps la corruption de ISO pour forcer le format Microsoft OXML et les subventions pour soutenir SCO dans sa tentative de destruction de Linux.
            Et malheureusement on peut dire que cela à fonctionner!

        • [^] # Re: A noter pour ceux qui ont du vieux matos

          Posté par (page perso) . Évalué à  10 .

          Linux marche même sur les vieilles machines

          « sur de vieilles machines » != « sur toutes les vieilles machines »

          C'est toujours vrai, ce qui n'est pas vrai, c'est l'absolu que tu fais toi

          il n'enlève jamais une compatibilité

          Ah ça je ne l'ai jamais entendu ! J'ai toujours entendu que la compatibilité pouvais durer longtemps, ce qui n'est pas pareil, on dit surtout que « ça a encore beaucoup de chances de marcher encore »

          Et oui Linux vire le support de certains périphérique, ou tout simplement parfois il n'y a plus personne pour maintenir… ça n'empêche que bon, attendre 2012 pour supprimer le 386 ! Linux a supporté le 386 pendant 11 ans, on peut théoriquement utiliser le noyau 3.6 (le précédent) sur des machines sorties en 1986 (le 386 est sorti en 1986), des machines qui ont 26 ans aujourd'hui.

          Par contre on a déjà vu des périphériques microsoft ne plus être supportés sous windows et ne plus être fonctionnel que sous Linux (joysticks par exemple).

          Bref, c'est sympa de faire l'avocat du diable, mais je n'aimerai pas être le diable avec un si mauvais avocat !

          ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: A noter pour ceux qui ont du vieux matos

      Posté par . Évalué à  2 .

      Ça veut dire qu'il n'existe même plus de processeurs à la 386 dans l'embarqué ?
      Il y a quelques années c'était courant. Ils sont désormais remplacés par des modèles au dessus, ou des ARM j'imagine.

  • # La dépêche pour la version 3.8 est lancée

    Posté par (page perso) . Évalué à  5 .

    Avis à la population !!!

    https://linuxfr.org/redaction/news/sortie-du-noyau-linux-3-8

    (« Il faut battre le frère tant qu'il lèche haut » dit le sage)

  • # noyau unifié pour x86 ?

    Posté par . Évalué à  -2 .

    Pensez vous qu'un noyau commun pour les processeurs x86 serait faisable / utile ?

Suivre le flux des commentaires

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