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 !
Aller plus loin
- LWN : Les nouveautés du noyau 3.7 (978 clics)
- The H Open : Coming in 3.7 (Part 1): Filesystems & storage (332 clics)
- The H Open : Coming in 3.7 (Part 2): Networking (221 clics)
- The H Open : Coming in 3.7 (Part 3): Infrastructure (136 clics)
- The H Open : Coming in 3.7 (Part 4): Drivers (209 clics)
- The H Open : Coming in 3.7 (Part 5): CPU and platform code (233 clics)
# Déjà en test... et Linux a gagné !
Posté par Pierre Jarillon (site web personnel) . Évalué à 10. Dernière modification le 13 décembre 2012 à 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 ʭ ☯ . Évalué à 10.
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://afdgauch.online.fr
[^] # Re: Déjà en test... et Linux a gagné !
Posté par Pierre Jarillon (site web personnel) . É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 Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Re: Déjà en test... et Linux a gagné !
Posté par xcomcmdr . É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 Prae . É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
[^] # Re: Déjà en test... et Linux a gagné !
Posté par ʭ ☯ . Évalué à 2.
Et c'est peut-être dommage. Diogène nous a plus ouvert les yeux que tous les commentaires de LinuxFR ;-)
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
# Bravo!
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Encore une excellente dépêche de patrick_g!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bravo!
Posté par patrick_g (site web personnel) . É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 Joachim IONOFF . Évalué à 6.
Le compte patrick_g a maintenant 10 ans !
Joyeux anniversaire.
[^] # Re: Bravo!
Posté par patrick_g (site web personnel) . Évalué à 6.
Ah oui tiens bien vu.
Allez hop pour fêter ça, maintenant que les news noyau s'écrivent toute seule, je peux vraiment siroter mon jus de goyave !
[^] # Re: Bravo!
Posté par NeoX . É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 Kekun (site web personnel, Mastodon) . Évalué à 7. Dernière modification le 12 décembre 2012 à 14:19.
Tu te trompes, notre équivalent de Linux Torvald c'est Patrix_g (le gaulois).
[^] # Re: Bravo!
Posté par Aldoo . É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 BAud (site web personnel) . Évalué à 3.
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 antistress (site web personnel) . É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 maboiteaspam . Évalué à 2. Dernière modification le 13 décembre 2012 à 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 Katyucha (site web personnel) . É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 windu.2b . Évalué à 10.
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 Maxime (site web personnel) . É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 rogo . Évalué à 10.
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 Zenitram (site web personnel) . Évalué à 6.
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 NeoX . É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 Zenitram (site web personnel) . É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 NeoX . É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 Zenitram (site web personnel) . Évalué à 3.
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 NeoX . É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 ckyl . É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.
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 Zenitram (site web personnel) . Évalué à 3. Dernière modification le 12 décembre 2012 à 17:06.
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 detail_pratique . É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 Grunt . É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 Anonyme . Évalué à 3.
Ç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 Zenitram (site web personnel) . É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 fearan . É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 Zenitram (site web personnel) . Évalué à 1. Dernière modification le 12 décembre 2012 à 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 BAud (site web personnel) . É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 Zenitram (site web personnel) . Évalué à 2.
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 claudex . Évalué à 3.
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).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure
Posté par Zenitram (site web personnel) . É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 vv222 . Évalué à 3.
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 Zenitram (site web personnel) . É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 Strash . É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 vv222 . Évalué à 1.
En 2011 la situation n'était pas franchement différente ! ;)
[^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 13 décembre 2012 à 16:25.
Appels, oui. Comme les appels entrants internationaux en Europe (hors ton pays). L'avantage des appels c'est que tu peux les refuser.
Parlons SMS, le sujet!!!
Prix du SMS entrant? Lien vers les tarifs? Je veux bien croire que ça existe, juste que je ne connais pas (je connais les US/Canada qui facture l'appel entrant, je trouve ça même normal que celui qui a le réseau cher paye pour, et pas l'appelant comme en Europe) et ça ne me pose pas de problème, mais pour les SMS je ne connais pas.
[^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure
Posté par vv222 . Évalué à 1.
15 cents le message entrant chez Rogers, qui m'a paru un des opérateurs les plus répandus :
https://www.tmcnet.com/usubmit/2009/05/05/4164728.htm
Wikipédia présente le même tarif pour Bell Mobility et Telus Mobility, malheureusement le lien vers la source est mort et je n'ai pas réussi à en trouver de version archivée…
[^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure
Posté par Zenitram (site web personnel) . Évalué à 3.
Wow, et le prix n'est pas léger en plus… Merci pour l'exemple, on en apprend tous les jours. Donc il y a bien des exceptions, le Wifi de certains aéroports n'est donc pas totalement gratuit suivant le contrat de téléphone, c'est malin. Mais pour revenir sur le sujet initial, il reste libre as a speech, juste pas toujours as a beer ;-).
[^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure
Posté par vv222 . É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 BAud (site web personnel) . É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 Sylvain Briole (site web personnel) . Évalué à 1.
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 gnuzer (site web personnel) . É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 Zenitram (site web personnel) . Évalué à 1.
On est certes derrière un NAT, mais sinon je n'ai jamais constaté de ports bloqués (SMTPS/IMAPS/SSH….), Tanguy va certes dire que ce n'est pas Internet mais c'est pas que du port 80 non plus, il y a tout ce qu'on a besoin quand on est en déplacement (après, on veut la dispo de son serveur pendant le vol?)
[^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure
Posté par Anonyme . Évalué à 5.
Du NAT IPv4 ou du NAT IPv6 ? :)
[^] # Re: RC2 en-direct-de-l'aéroport-de-Portland-pourvu-que-ça-dure
Posté par Kytrix . É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 Tharkun2 (site web personnel) . Évalué à 10.
Tiens, patrick_g passe la main. Et Antistress reprend la suite avec brio ! Bravo !
[^] # Re: Nouveau rédacteur
Posté par antistress (site web personnel) . É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 barmic . É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
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Btrfs
Posté par zebra3 . É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 Albert_ . É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 barmic . É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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Btrfs
Posté par fravashyo . É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 collinm (site web personnel) . É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
www.solutions-norenda.com
[^] # Re: Btrfs
Posté par zebra3 . Évalué à 5.
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 collinm (site web personnel) . Évalué à 1.
devant
http://www.phoronix.com/scan.php?page=search&q=EXT4
www.solutions-norenda.com
[^] # Re: Btrfs
Posté par Tonton Th (Mastodon) . Évalué à 5.
LOL
[^] # Re: Btrfs
Posté par collinm (site web personnel) . Évalué à 9.
toujours plus intéressant à les lires que te lire…
www.solutions-norenda.com
[^] # Re: Btrfs
Posté par patrick_g (site web personnel) . É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 collinm (site web personnel) . É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…
www.solutions-norenda.com
[^] # Re: Btrfs
Posté par Maclag . É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 Xaapyks . É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 Aissen . Évalué à 9.
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 antistress (site web personnel) . Évalué à 7. Dernière modification le 12 décembre 2012 à 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 Kytrix . É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 collinm (site web personnel) . É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…
www.solutions-norenda.com
[^] # Re: Bravo pour cette news !
Posté par Kytrix . É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 Xaapyks . É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 Kytrix . É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 YuGiOhJCJ (site web personnel) . É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 Xaapyks . Évalué à 3.
Lis ce que je raconte un post au dessus…
[^] # Re: Bravo pour cette news !
Posté par Kerro . Évalué à 1.
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 Renault (site web personnel) . Évalué à 4.
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 Zenitram (site web personnel) . Évalué à 4. Dernière modification le 12 décembre 2012 à 23:52.
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 Grunt . Évalué à 6.
Ç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 Kerro . Évalué à 4. Dernière modification le 13 décembre 2012 à 00:13.
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 Renault (site web personnel) . É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 Prosper . Évalué à 6.
Pas du tout , puisque les plateaux contiennent de plus en plus de données, sans compter qu'on peut aussi multiplier les plateaux.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# md + trim/discard
Posté par Arcruxe . É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 groconar . É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
da linux french page :) LOL
Je m'en vais reformater mon pécé uefi sous windows 8
signé groconar
[^] # Re: MODSIGN
Posté par 2PetitsVerres . É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 groconar . É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 Kioob (site web personnel) . É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.
alf.life
[^] # Re: MODSIGN
Posté par 2PetitsVerres . É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 antistress (site web personnel) . Évalué à 3. Dernière modification le 14 décembre 2012 à 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 oinkoink_daotter . É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 Mali (site web personnel) . Évalué à 7.
Le support du 386DX/SX vient d'être supprimé :)
Commit
[^] # Re: A noter pour ceux qui ont du vieux matos
Posté par Thomas Debesse (site web personnel) . É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
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: A noter pour ceux qui ont du vieux matos
Posté par Zenitram (site web personnel) . Évalué à -6.
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 Dring . É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 Thomas Debesse (site web personnel) . Évalué à 9.
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 xcomcmdr . É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 zebra3 . Évalué à 2.
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 Albert_ . É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 Thomas Debesse (site web personnel) . Évalué à 10.
« 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
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 Albert_ . Évalué à 2.
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).
Webcam, imprimante et un sacré paquet de matos plus ou moins spécifique. Je connais une boite qui à toujours un vielle ordi sous … windows 98 pour utiliser une de leur machine…
[^] # Re: A noter pour ceux qui ont du vieux matos
Posté par Kerro . Évalué à 6.
1 - géré
2 - 21
[^] # Re: A noter pour ceux qui ont du vieux matos
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Euh oui merci, sus aux anglicismes et aux monstrueuses erreurs de calcul mental ;)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: A noter pour ceux qui ont du vieux matos
Posté par ymorin . Évalué à 3.
En même temps, pour le 386, on peut qu´il a été supporté.
Hop,
Moi --> []
[^] # Re: A noter pour ceux qui ont du vieux matos
Posté par Kerro . É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.
[^] # Re: A noter pour ceux qui ont du vieux matos
Posté par Zenitram (site web personnel) . Évalué à 2.
Ca fait longtemps que même l'embarqué utilise du i686 (1995 quand même).
[^] # Re: A noter pour ceux qui ont du vieux matos
Posté par Kerro . Évalué à 3.
En 2000 il y avait encore en fabrication des processeurs 386 pour l'embarqué. Ce n'est pas parcequ'il existe mieux qu'on n'utilise plus les vieilles choses.
[^] # Re: A noter pour ceux qui ont du vieux matos
Posté par ckyl . Évalué à 10.
Racontes pas de baliverne. Zenitram c'est l'expert de tout les domaines du monde; de la pétrochimie à la sociologie en papouasie en passant par l'embarqué. Moi je le crois !
[^] # Re: A noter pour ceux qui ont du vieux matos
Posté par Zenitram (site web personnel) . Évalué à 1.
Hint : le support i386 vient d'être enlevé de Linux.
Nous sommes en 2012, plus en 2000. La date 1995 est la date de sortie de i686, pas la date de mort de i386 (du i386 produit en 2000, clair que ça se faisait!).
Bon, un CPU i386 en vente aujourd'hui? C'est à celui qui dit que ça existe de prouver l’existence, dur de prouver une inexistence.
[^] # Re: A noter pour ceux qui ont du vieux matos
Posté par Strash . Évalué à 8.
Apparemment Intel a arrêté ses 386 et 486 en 2007 (source : http://www.reghardware.com/2006/05/18/intel_cans_386_486_960_cpus/ )
Plus de commande après mars 2007.
Arrêt total de la production en septembre 2007.
Après comme je n'y connais pas grand chose, je ne sais pas si d'autres processeurs de la famille i386 sont encore en vente dans d'autres boites.
[^] # Re: A noter pour ceux qui ont du vieux matos
Posté par antistress (site web personnel) . Évalué à 2.
cool le lien, on le reprendra pour la prochaine dépêche
[^] # Re: A noter pour ceux qui ont du vieux matos
Posté par Strash . Évalué à 1.
Attention par contre, il me semble que d'autres fondeurs ont aussi sorti des i386, dont (au moins) AMD et Ti.
[^] # Re: A noter pour ceux qui ont du vieux matos
Posté par Zenitram (site web personnel) . Évalué à 2.
AMD a rapidement sauté sur le Am486 (1992), mais pas facile de trouver la date d'arrêt de Am386. Néanmoins, vu qu'AMD est beaucoup beaucoup moins gros qu'Intel et donc encore moins d’effet volume, je suis prêt à parier qu'AMD s'est arrêté bien avant Intel de produire ces CPU.
Dur dur de trouver des modèles i386 encore en vente en 2012 même pour les remplacements de matos sensible. cykl se fout de moi, mais il n'en reste pas moins que personne ne peut démontrer qu'il peut encore acheter du i386 ou compatible même dans l'embarqué (non, l'occasion sorti du grenier du voisin ça ne compte pas! ;-) ).
[^] # Re: A noter pour ceux qui ont du vieux matos
Posté par detail_pratique . Évalué à 7.
Et si quelqu'un dans la salle à quelque chose à dire qu'il se lève ou se taise à jamais !
Timidement, detail_pratique se leva.
— Je crois que j'ai quelque chose à dire.
— Alors parle, amibe !
Et il parla :
«
http://pc104.winsystems.com/products/pcm-sx.cfm
http://www.nagasaki.com.tw/products/embedded/pc_104.htm
http://www.aton-sys.fr/English/produits/fiche_cpu386sxio.htm
»
[^] # Re: A noter pour ceux qui ont du vieux matos
Posté par antistress (site web personnel) . Évalué à 2.
C'est vendu quelque part où ils ont oublié de supprimer la page ?
[^] # Re: A noter pour ceux qui ont du vieux matos
Posté par detail_pratique . Évalué à 2.
Tu demandes ça parce que tu n'as pas vu de test passer chez Phoronix ?
Je dois confesser que je n'ai pas envoyé de demande de cotation. Mais ça a l'air commandable, non ?
[^] # Re: A noter pour ceux qui ont du vieux matos
Posté par antistress (site web personnel) . Évalué à 2.
tadam http://linuxfr.org/redaction/news/sortie-du-noyau-linux-3-8
[^] # Re: A noter pour ceux qui ont du vieux matos
Posté par Zenitram (site web personnel) . Évalué à 1.
La page peut avoir été oubliée et on n'a pas la vu sur les stocks, mais ça fait effectivement douter… Grrr… Le CPU viendrait d'où si il ne vient pas d'Intel? "386SX 40MHz" ou "386SX40" semble du Intel, donc ça éliminerait, mais rien n'est sûr (pas écrit "Intel" sur les pages). Grr, je doute maintenant!
[^] # Re: A noter pour ceux qui ont du vieux matos
Posté par detail_pratique . Évalué à 2.
J'espère que tu feras un cauchemar horrible, genre être obligé d'installer SLS sur un 386sx25 :D
Bouton turbo, Zenitram, bouton turbo !
[^] # Re: A noter pour ceux qui ont du vieux matos
Posté par antistress (site web personnel) . Évalué à 2.
je vous laisse vous mettre d'accord et compléter sur la dépêche de la 3.8 ?
[^] # Re: A noter pour ceux qui ont du vieux matos
Posté par Strash . Évalué à 2.
Intel n'a jamais fait de CPU 386 en 40MHz, mais AMD en a fait. Donc je ne pense pas que ce soit un Intel.
[^] # Re: A noter pour ceux qui ont du vieux matos
Posté par Mali (site web personnel) . Évalué à 6.
Un système embarqué sur 386, soit il est stable sur un 2.x depuis un bon moment, et on n'y touche plus ( au moins pour le système ) soit depuis le temps, il n'est pas stable et c'est mort, faut tout changer :)
[^] # Re: A noter pour ceux qui ont du vieux matos
Posté par groconar . Évalué à -1.
le 2.4.X tu veux dire plutôt car cette histoire d'unification de l'archi x86_64 et x86 qui casserait des trucs date un peu (2.6.jenemesouviensplus), et le fait d'ailleurs que cela a déjà été annoncé deux fois, prouve la confusion totale sur le sujet, d'ailleurs je me demande qui a vraiment mesuré l'envergure de ça
de toute façons la dernière fois (et c'était il y a bien longtemps) que j'ai lancé une simple commande bash sur mon 486, j'ai fini par faire ctrl+c, mais ça c'est parce que bash n'est pas du tout optimisé, tant qu'aux scripts de compilation…
C'est tout de même dommage, et c'est triste de voir l'opensource adopter les mêmes démarches que les "vendors"
# La dépêche pour la version 3.8 est lancée
Posté par antistress (site web personnel) . É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 mlinux . Évalué à -2.
Pensez vous qu'un noyau commun pour les processeurs x86 serait faisable / utile ?
[^] # Re: noyau unifié pour x86 ?
Posté par claudex . Évalué à 3.
C'est déjà possible.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: noyau unifié pour x86 ?
Posté par vv222 . Évalué à 1.
C'est déjà le cas, non ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.