La sortie de la version stable 3.11 du noyau Linux vient d’être annoncée par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable depuis les serveurs du site kernel.org. Pour l’occasion, l’espiègle Tux arbore le drapeau de Windows pour Workgroups 3.11 au démarrage du système.
Merci à tous les participants à la rédaction de cette dépêche, dont vous trouverez les noms en cliquant sur le lien des contributeurs, sous le titre de la dépêche !
Merci spécial à Martin Peres pour les passages graphiques sur les pilotes Nouveau et radeon (notamment pour ses explications sur la gestion de l’énergie).
Sommaire
- La phase de test
- Les nouveautés
- Les améliorations
- Statistiques
La phase de test
RC-1
La version RC-1 a été annoncée le 14 juillet par Linus :
Ça fait deux semaines et la fenêtre d’intégration est dorénavant fermée. Si j’ai oublié quelque chose, hurlez, mais il n’y a rien en attente à ma connaissance.
Cette fenêtre d’intégration était plus petite en termes de nombre de changements que celle de la 3.10, mais nous avons plus de nouvelles lignes. La plupart semblent être en « staging » — un tiers des changements en termes de lignes est « staging » et l’intégration de Lustre en est la principale raison. Nous verrons comment ça finira ; je dois dire que nous n’avons pas une grande expérience sur les systèmes de fichiers à travers « staging ».
Je pense que c’est une fenêtre d’intégration relativement calme, excepté pour celle de Lustre. Nous avons eu des problèmes sur quelques arborescences, et nous avons un débat en cours sur des correctifs stables déclenché par cette période de fusion ; nous devrions donc avoir un sujet de discussion pour le Kernel summit. Mais dans l’ensemble, je sens que nous devrions commencer à assister au calme estival habituel (excepté pour l’Australie).
Bien que plus petite que la dernière fenêtre d’intégration, ce n’est pas comme si elle était « minuscule », et comme d’habitude je fais uniquement un résumé du rapport de fusion de la -rc1 : comme d’habitude, les personnes nommées ici ne sont pas les contributeurs qui ont écrit le code (bien que dans certains cas cela soit vrai), mais les propriétaires des dépôts que j’ai récupérés.
Eh, commençons tous les tests,
Linus
Avant la RC-2
Avant la sortie de la RC-2, Linus se plaint du manque de correctifs. Les développeurs seraient‐ils partis en vacances ?
Nous sommes à mi‐chemin de la première semaine après la fermeture de la fenêtre d’intégration, et, normalement, je devrais être en train de me plaindre à propos du nombre de trucs que vous m’envoyez tous, et de vous rabâcher que vous m’avez envoyé quelques conneries à moitié terminées pendant la fenêtre d’intégration, qui auraient probablement dû attendre jusqu’à la prochaine version.
Mais, non. Tout le monde a préféré commérer autour de la fontaine, et j’ai eu une ou deux demandes d’intégration par jour de gens qui sont heureusement inconscients (ou trop intelligents pour s’impliquer) sur l’ensemble « Flame fest ».
Je suis acariâtre et difficile. Envoyez‐moi trop de choses et je crie. Envoyez‐en moi trop peu et je crie. Parce que je suis la Boucles d’or du développement du noyau, et je veux que mes demandes d’intégration soient bien, tout simplement. Et, clairement, toute l’énergie a été épuisée dans la discussion, pas dans le travail.
Ouste ! Retournez à vos bureaux. Ne vous rassemblez pas tous dans la salle de pause.
Linus
P.‐S. : Ou, peut‐être, vous êtes simplement professionnels et vous comptabilisez votre temps, et tout le monde a l’intention de m’envoyer son travail au moment de pointer, le vendredi à 17 heures ? Mais ce n’est pas ce qu’on ressent.
RC-2
La deuxième RC a été annoncée une semaine plus tard par Linus :
Voici donc une autre semaine, et la -rc2 est là.
Les changements sont un peu bizarres, car, en vrac, 95 % d’entre eux concernent uniquement la suppression du pilote « staging » CSR qui n’attirait personne, de sorte que le diffstat (et le dirstat en particulier) n’est pas très intéressant ni lisible à cause de la suppression du pilote qui éclipse pratiquement tout le reste. Mais, j’avoue aimer voir de la suppression de code.
Pour le reste des changements, une partie notable concerne la suppression des marques _cpuinit, dont les gens ont convenu qu’elles apportaient plus de difficultés que de gain à maintenir. Nous avions au préalable rendu les marqueurs inopérants, de sorte qu’ils n’aient pas d’importance pour la génération de code, et ici, pour la rc2, ils peuvent être effectivement supprimés.
Résultat : nous avons deux événements distincts qui génèrent beaucoup de bruit au sein de la liste des changements, mais ils ne sont pas très intéressants, et ne rendent la lecture de celle‐ci que plus difficile.
Si l’on ignore le bruit de fond susmentionné, il y a une ou deux choses à noter à propos de la rc2. Je pense que la plupart des changements sont de gentils correctifs, mais je voulais donner un peu plus d’importance à deux points que voici :
(a) le drapeau O_TMPFILE, nouveauté de la 3.11, a subi quelques nettoyages d’ABI / API (et également quelques correctifs d’implémentation), mais je pense que nous avons fini maintenant. Donc, si vous êtes intéressés par le concept de fichiers temporaires anonymes, allez de l’avant et testez‐le. L’absence de nom permet non seulement de se débarrasser de concurrences et complications avec la génération de fichier, mais ça peut aussi rendre le tout plus efficace, puisque vous n’avez pas les opérations d’annuaire qui peuvent causer de la sérialisation d’entrées‐sorties, entre autres.
(b) nous avons eu un changement de dernière minute sur la façon dont la gestion du rétroéclairage ACPI est faite sur certaines machines. Et, bien que ce genre de chose ne devrait pas vraiment être fait en dehors de la fenêtre d’intégration, j’ai fini par l’intégrer quand même. Mais je voudrais vraiment avoir des gens qui testent cette chose, en particulier sur les ordinateurs portables munis d’une carte graphique Intel. Ça ne devrait toucher (et améliorer les choses avec de la chance) que les ordinateurs les plus récents dont le BIOS a été conçu pour Windows 8. Mais, bon, plus il y a de tests, mieux c’est. La gestion du rétroéclairage a été difficile auparavant, donc je le mentionne explicitement.
Quoi qu’il en soit, en dehors de ces deux problèmes, je pense que le reste est assez normal pour une rc2. Ça a commencé un peu lentement, mais je pense que ça a fini normalement. Outre les trucs déjà mentionnés, nous avons des choses sur le DRM (radeon en particulier), quelques corrections de pilotes, des mises à jour s390, MIPS, ARM et x86, les pilotes audio, des corrections ext4 et Btrfs, bla bla.
Le résumé des modifications depuis la -rc1 est en pièce jointe.
Linus
RC-3
La troisième RC :
À nouvelle semaine, nouvelle -rc.
S’il vous plaît, oubliez ce que je vous ai dit la semaine dernière sur le fait de retourner au travail. Vous l’avez fait. La -rc3 a environ 50 % de changements de plus que la -rc2. C’est en partie dû au fait que quelques gens ont manqué la -rc2, mais aussi que des gens m’en ont envoyé plus. S’il vous plaît, arrêtez. C’est l’été. C’est agréable à l’extérieur. Emmenez les enfants à la piscine ou ailleurs. Envoyez‐moi seulement des correctifs de régressions.
Sinon, je vais devoir recommencer à crier sur les gens.
Quoi qu’il en soit, souvenez‐vous comment j’ai demandé aux gens de tester les modifications du rétroéclairage dans la -rc2 parce que des telles choses ont vraiment eu de mauvais antécédents ? Yep ! Tout ça a été annulé. Cela a corrigé les choses pour certaines personnes, mais ça a régressé pour les autres, et nous ne faisons pas « un pas en avant, deux pas en arrière ». Mais, n’ayez crainte, nous avons des super gens qui regardent ça.
Le prise en charge de la crypto crc t10 dif a été annulée aussi, parce qu’elle pose des problèmes avec l’infrastructure d’initrd.
Mais l’essentiel ici, concerne les mises à jour de pilotes de blocs (drbd, rsxx, xen, bcache et libata) et les changements de DRM (principalement qxl, mais il y a aussi des changements sur le « big tree » : radeon, intel et nouveau). Et, enfin, quelques pilotes — USB, SCSI, pincontrol, etc.
Il y a également des mises à jour classiques pour certaines architectures (principalement pour Alpha, ARM et PowerPC).
Le rapport complet des changements depuis la rc2 est en pièce jointe. C’est tellement gros que j’ai débattu le fait de faire uniquement un rapport d’intégration dans le style « période d’intégration », mais peut‐être que les gens apprécient ce genre de détails ?
Linus
RC-4
La quatrième RC a été annoncée avant la nuit du 4 août :
C’est à nouveau ce moment de la semaine…
« Appliquez 339 correctifs, qu’obtenez‐vous au final ?
Plus âgé d’une semaine et un peu plus redevable.
Saint Pierre, ne m’appelle pas, car je ne pourrais venir à toi.
Mon âme, au magasin de la compagnie, je la dois. »
J’avais espéré que les choses commenceraient à se calmer, mais la rc4 est à peu près de la même taille que la rc3. Ceci dit, les correctifs semblent un peu plus épars et moins intéressants — ce qui est une bonne chose. L’ennui, c’est bien. Maintenons les choses ainsi et essayons de faire moins de correctifs pour la rc5, d’accord ? Parce que nous avons parcouru la moitié du chemin maintenant, et je ne souhaite vraiment voir que des corrections.
Nous avons des mises à jour d’architectures (ARM et PA-RISC), mais la majorité concerne des pilotes (surtout du réseau, USB et DRM). Il y a également des changements profonds au niveau réseau. Et les mouvements du code printk semblent importants si vous n’utilisez pas git renames (c’est‐à‐dire comme les correctifs que j’envoie).
Linus
RC-5
La cinquième RC est sortie le 11 août, et Linus s’amuse avec la sortie de Windows 3.11 :
Malheureusement, la numérologie ne fonctionne pas si bien, et, alors que sortir la version 3.11 aujourd’hui serait une heureuse coïncidence (Windows 3.11 sortait ce jour même, il y a vingt ans), ce ne sera pas le cas.
À la place, nous avons une 3.11-rc5.
Cette dernière montre des signes d’accalmie et est nettement plus petite que les précédentes RC (autant en nombre de changements, qu’en taille desdits changements). Espérons seulement que ce n’est pas uniquement un coup de chance.
Il semblerait qu’il n’y ait aucun changement majeur. Les changements touchant radeon sont les plus notables, mais la majorité d’entre eux ne concerne que la gestion dynamique de l’énergie qui est désactivée par défaut… Mis à part ça, quelques corrections média, des mises à jour d’architectures, quelques petites mises à jour au niveau systèmes de fichiers, etc. Rien ne sort vraiment du lot.
Linus
RC-6
La version RC-6 a été annoncée le 18 août par Linus :
La semaine a été plutôt calme et les RC s’amenuisent, ce qui me satisfait.
Bien sûr, nous avons rencontré un bogue intéressant et bruyant dans le code d’invalidation de la TLB, mais c’était un bogue plus ancien et apparemment vraiment difficile à reproduire en pratique. Ceci dit, cela pourrait expliquer quelques SIGSEGV aléatoires, etc. Ainsi, si vous avez vu un comportement étrange, peut‐être que vous êtes tombé dessus, et la RC-6 corrigera cela. On touche du bois.
Sinon, ce sont plutôt des changements divers : réseau, pilotes, USB, son et quelques corrections pour les systèmes de fichiers. On retrouve également des mises à jour architecturales pour x86, ARM et m68k. Mais, c’était vraiment calme. Le résumé ci‐dessous donne les détails pour ceux qui sont intéressés.
Puisque les statistiques de cette rc étaient ennuyeuses, j’ai commencé à regarder des chiffres plus impressionnants. Cela fait maintenant huit ans que l’on utilise Git, et on a effectué plus de 400 000 changements durant cette période. C’est intéressant (du moins pour moi), puisqu’à l’époque où l’on utilisait BK (BitKeeper, de 2002 à 2005, NDT) on s’approchait de la limite des 65 000 changements en trois ans d’utilisation. Cela fait donc longtemps que l’on a pulvérisé cette limite.
Qu’en est‐il de ces 400 000 changements ? Ils tiennent tous dans un fichier empaqueté de 575 Mio (plus un index de 85 Mio). Après, c’est en forçant plus sur la compression du paquet de fichiers que la plupart des personnes doivent le faire, mais je pense qu’il est intéressant de voir comment huit années d’historique de développement actif ont la même taille que l’arbre des sources brut. En fait, je pense qu’il vous faut plus d’espace libre pour les fichiers objets lors de la compilation que l’espace nécessaire au stockage de tout l’historique.
J’essaierai de me souvenir de faire des statistiques plus intéressantes et pertinentes pour la sortie de la rc7, parce que cela coïnciderait avec le 22e anniversaire de l’annonce initiale de Linux sur comp.os.minix.
Comme le temps passe vite lorsqu’on s’amuse…
Linus
RC-7
La version RC-7 a été annoncée le 26 août sur Google+ par Linus :
Bonjour à tout le monde ici‐bas utilisant Linux,
Je fais un système d’exploitation (libre) (juste un passe‐temps, même si c’est important et professionnel) pour les clones d’AT 486+ et presque tout le reste ici‐bas sous le soleil. Le brassage est en cours depuis avril 1991, et ce n’est pas encore prêt. J’aimerais avoir des retours sur les choses que les gens aiment ou détestent dans Linux 3.11-rc7.
J’ai initialement porté bash _(1.08) et_ gcc (1.40), mais les autres ont repris l’espace utilisateur, et ça semble fonctionner. Ça indique que je vais avoir la version 3.11 finale d’ici une semaine, et j’aimerais savoir quelles fonctionnalités la plupart des gens voudraient. Toutes les suggestions sont les bienvenues, mais je ne promets pas que je les implémenterai. :-)
Puis il rajoute en commentaire :
Ouais, je ne veux vraiment pas avoir de demandes de fonctionnalités en cette fin de version RC…
Mais ça fait 22 ans aujourd’hui depuis cette annonce, et j’aimerais que les gens testent le noyau actuel 3.11-rc7 que je viens de téléverser aux emplacements habituels.
Linus
Les nouveautés
Zswap
Zswap est une fonctionnalité du noyau qui fournit la compression du cache pour le swap. C’est en développement depuis longtemps et le code est enfin disponible dans le développement principal du noyau Linux.
Zswap prend les pages qui sont dans le traitement d’évacuation du swap et essaie de les compresser dans un groupe de mémoire vive allouée dynamiquement. Et si l’espace ainsi gagné est suffisant, des écritures sur disque sont évitées. Zswap échange ainsi cela par des cycles processeur pour réduire potentiellement des écritures et lectures en swap. Cet échange peut améliorer de façon significative les performances si les lectures du cache compressé sont plus rapides que les lectures du swap.
Pour plus de détails sur Zswap.
Compression LZ4 pour le noyau
LZ4 est un outil de compression très rapide par rapport à gzip, bzip2, LZMA ou LZO. Il utilise les algorithmes de compression LZ77 et LZ78 (pour plus de détails sur le fonctionnement de LZ4 voir ici). Le nouveau noyau prend en charge la compression LZ4 du noyau. Il permet ainsi de faire un démarrage plus rapide du noyau Linux. Cette prise en charge est actuellement possible seulement pour l’architecture ARM. Il n’est pas à exclure que cela soit étendu à d’autres architectures dans une prochaine version.
Plus de détails sur LZ4 pour le noyau.
Sécurité : option O_TMPFILE
La nouvelle option O_TMPFILE pour les appels système open() et openat() permet aux systèmes de fichiers d’optimiser la création de fichiers temporaires (fichiers qui n’ont pas besoin d’être visibles dans le système de fichiers). Lorsque l’option O_TMPFILE est présente, le nom du chemin fourni est seulement utilisé pour trouver le répertoire le contenant (et donc le système de fichiers où le fichier temporaire devrait être). Ainsi, par exemple, les programmes utilisant O_TMPFILE devraient avoir moins d’inquiétudes concernant la vulnérabilité des attaques avec des liens symboliques.
Rapid Start
Matthew Garret, un spécialiste d’UEFI, est actuellement en train de regarder comment mettre en œuvre Rapid Start sous Linux.
Rapid Start est une technologie Intel ayant pour but de permettre à un système de sortir d’un profond sommeil en 5 ou 6 secondes, c’est‐à‐dire plus rapidement que la traditionnelle hibernation et bien plus efficacement qu’une réelle extinction de la machine. Elle mémorise dans une partition dédiée d’un SSD le contenu de la mémoire vive.
Au niveau technique, Rapid Start utilise un micrologiciel qui copie le contenu de la mémoire vive sur la partition spéciale du disque SSD avant d’entrer en sommeil profond, et inversement remet son contenu dans la mémoire vive lors du réveil. La différence avec l’hibernation classique est que le micrologiciel se situe dans le BIOS UEFI, permettant de gagner quelques secondes (pas de GRUB, etc.).
Matthew Garret a mis en place un changement permettant de mettre en œuvre ce mécanisme. Évidemment, il faudra aussi mettre en œuvre cette avancée en espace utilisateur. Les développeurs de la distribution Ubuntu commenceraient à travailler sur cela. Il est probable que cela soit fonctionnel pour la prochaine version LTS qui sortira en avril.
Pour plus de détails, voir son blogue.
Renesas R-Car
Pour finir concernant les nouveautés, nous pouvons noter l’arrivée d’un nouveau pilote graphique Renesas R-Car, qui est une puce à quatre cœurs ARM Cortex-A9. Cette puce est utilisée pour les systèmes embarqués dans les voitures haut de gamme.
Les améliorations
Architectures
ARM
De nombreux changements de ce nouveau noyau ont concerné les architectures ARM. On peut citer notamment :
- prise en charge minimale du processeur Texas Instruments Keystone ARM ;
- un début de prise en charge des calculatrices de la gamme TI-Nspire ;
- prise en charge du processeur Rockchips RK3xxx ARM ;
- la compression LZ4 du noyau (développée ci‐dessus) ;
- Samsung a ajouté la prise en charge des puces S3C64XX pour son pilote vidéo Exynos.
Voir plus de changements.
AArch64
Vous avez peut‐être déjà entendu parler de l’architecture ARM 64 bits ? C’est une architecture qui n’existe pas encore physiquement, mais seulement virtuellement. Il est maintenant possible de virtualiser cette architecture en utilisant KVM ou Xen. Au‐delà de cette possibilité de virtualisation, cette architecture a reçu des améliorations. Elle peut monter des partitions Hugetlbfs et utiliser des huge pages transparentes. Enfin, il est à noter une amélioration au niveau du vidage de la mémoire disque du noyau (Cache flushing).
Pour plus de détails.
Cryptographie
Voici la liste des changements concernant la cryptographie :
- prise en charge du SHA-224 et SHA-384 pour les processeurs utilisant le jeu d’instructions SSSE3 ;
- API du LZ4 ;
-
Instruction PCLMULQDQ pour accélérer CRC T10 DIF; - prise en charge du coprocesseur DCP de Freescale.
Audio
Rien de révolutionnaire dans cette section. Seulement des prises en charge de nouveaux périphériques. Par exemple :
- prise en charge de la radio pour la carte MediaForte M56VAP ;
- ajout du pilote pour le convertisseur numérique USB vers S/PDIF M2Tech hiFace, qui se charge d’améliorer la transmission des données audio ;
- amélioration de la prise en charge du pilote Intel Haswell.
Pour plus de détails.
Pilotes graphiques
Intel
Haswell est la nouvelle micro‐architecture, sortie début juin, qui succède à Sandy Bridge. Les premiers correctifs pour sa prise en charge datent d’Août 2012, 10 mois avant la sortie officielle du microprocesseur. Son prise en charge a été déclarée stable fin novembre 2012 à l’occasion du noyau 3.8, soit un peu plus de 7 mois avant sa sortie. Elle s’est encore améliorée dans les sorties suivantes. On peut donc dire qu’Intel fourni une prise en charge exemplaire, car il permet aux distributions grand public, telles qu’Ubuntu, de pouvoir prendre en charge les nouveaux processeurs graphiques Haswell dès leur sortie, sans avoir besoin de mettre à jour le noyau ou de rétroporter les modifications dans le noyau de la distribution.
Les nouveautés apportées à la prise en charge d’Haswell dans cette version sont :
- Intermediate Pixel Storage (IPS), qui permet de réduire le nombre de fois où le moteur graphique réveille la mémoire pour lire les pixels. Ainsi, cela fait diminuer la consommation électrique ;
- Frame-Buffer Compression (FBC), qui permet aussi d’économiser de l’énergie.
Pour plus de détails, voir ces courriels sur dri-devel en mai et en juin.
NVIDIA (pilote Nouveau)
Cette nouvelle version marque l’arrivée de la prise en charge de VP2, groupe de moteurs de décodage vidéo matériel pour les GeForce 8 et 9. Cette fonctionnalité a été développée par un ancien contributeur revenu travailler sur Nouveau, Ilia Mirkin. Son travail vient compléter la prise en charge déjà existante de VP4.2 et VP5, moteurs de décodage vidéo matériel respectivement pour les cartes de la famille Fermi et Kepler, qui permettent le décodage matériel des vidéos encodées en MPEG-1, MPEG-2 et H.264. La prochaine version de Linux verra l’ajout du VP3 et VP4 ce qui complétera le décodage vidéo pour pratiquement toutes les cartes GeForce 8 et supérieures.
Pour utiliser le décodage vidéo, il est encore nécessaire d’utiliser les microcodes de NVIDIA. Comme leur licence ne permet pas leur redistribution, c’est à l’utilisateur de faire l’effort de les installer. Cette opération a longtemps nécessité de faire une MMIOTrace (opération assez compliquée), mais Ilia a simplifié la procédure en permettant l’extraction automatique des microcodes directement depuis le pilote propriétaire de NVIDIA. Si vous utilisez ArchLinux, il vous suffit d’installer le paquet nouveau-fw pour en bénéficier. Pour les autres distributions ou si vous souhaitez en savoir plus, vous pouvez visiter la page Wiki dédiée au décodage vidéo qui vous indiquera le niveau de prise en charge actuel de chaque carte, la version logicielle de chaque composant que vous devez avoir, ainsi que la procédure à suivre pour extraire et installer les microcodes. Mais aussi, pour finir, comment utiliser l’accélération vidéo VDPAU.
Cette nouvelle version a aussi permis de corriger bon nombre de bogues et plantages. Ces bogues étaient majoritairement liés à l’imperfection du microcode libre qui permet d’effectuer le changement de contexte dans la carte, processus indispensable à l’accélération 3D dans l’architecture actuelle de Nouveau. L’amélioration de ces microcodes a rendu stable le (très problématique) processeur graphique NVD9. La tâche de débogage est encore en cours, ce qui devrait augmenter la fiabilité et la cohérence du pilote dans la prochaine version.
Pour finir, la prise en charge initiale pour les NVD7 a également été ajoutée.
ATI/AMD (pilote radeon)
Le pilote radeon a provoqué l’étonnement lorsqu’Alex Deucher, développeur chez AMD, a publié un jeu de 165 correctifs pour ajouter une prise en charge complète de la gestion d’énergie pour les cartes de la famille r6xx à SI (Southern Island). Comme la gestion d’énergie est un sujet complexe, voici une petite présentation sur les différents concepts présents.
La consommation des MOSFET
À l’échelle la plus basse, une carte graphique est majoritairement composée de transistors de type MOSFET. Ces transistors sont une des causes principales de la consommation énergétique. Cette consommation est découpée en deux parties :
- la consommation statique : à force de miniaturiser les transistors, ceux‐ci ne sont jamais complètement bloquants, il y a donc un courant de fuite lorsque le transistor est ouvert. Ce courant (Ileak) doit être multiplié avec la tension d’alimentation (Vdd) pour calculer la consommation statique (Pstatic = Vdd × Ileak) ;
- la consommation dynamique : cette consommation est liée au fait de changer l’état (ouvert/fermé) d’un transistor. Elle est généralement approximée par 3 facteurs, la fréquence de changement d’état (f), la tension d’alimentation (Vdd) au carré et la charge capacitive (C) qui empêche le changement d’état (Pdynamic = f × Vdd² × C).
Les 3 méthodes pour diminuer la consommation des MOSFET
En se basant sur ces équations, une des premières approches pour réduire la consommation énergétique est de diminuer la tension d’alimentation (Vdd). Cependant, si l’on diminue trop la tension d’alimentation, la charge capacitive (C) vient empêcher le changement rapide d’état, ce qui contraint à diminuer la fréquence de fonctionnement de la carte et affecte donc les performances. Il faut donc adapter dynamiquement la fréquence et la tension d’alimentation, en fonction de la charge du processeur graphique. Cette technique s’appelle le dynamic voltage and frequency scaling et utilise généralement les compteurs de performance matériels pour déterminer le niveau de performance requis.
Une autre solution pour diminuer la consommation énergétique est de couper l’horloge des blocs de transistors qui ne sont pas actuellement en cours d’utilisation. Cela permet de rendre nulle la consommation dynamique au prix d’une augmentation de la complexité de l’arbre d’horloge. Cette technique s’appelle le clock gating et peut théoriquement n’avoir aucun impact sur les performances.
Pour finir, la solution la plus efficace pour diminuer la consommation énergétique est de couper l’alimentation des blocs inutilisés de la carte. Cette technique, appelée power gating, a pour mérite de couper totalement la consommation énergétique au prix de la perte des informations stockées dans les registres des blocs concernés. Il est donc nécessaire de sauvegarder le contexte d’un moteur d’exécution avant d’utiliser le power gating et de recharger le contexte après son utilisation. Ces opérations sont lentes, ce qui limite la fréquence à laquelle le power gating peut être utilisé. Ces opérations sont généralement faites par un microcontrôleur dédié à la gestion d’énergie pour ne pas encombrer le processeur central (CPU).
Et DPM dans tout ça ?
Pourquoi parler de tout cela ? Tout simplement parce que derrière l’acronyme DPM (Dynamic Power Management), utilisé par AMD, se cache en fait les trois méthodes présentées. Cette gestion d’énergie implémentée par AMD est donc maintenant disponible pour toutes les cartes AMD, sauf celles de la prochaine génération (Sea Islands) où le travail a déjà commencé et, évidemment, sur les vieilles cartes où le DPM n’est pas ou peu pris en charge par le matériel.
Un premier banc d’essai sur la RC1 montre une amélioration des performances, notamment sur les jeux demandant beaucoup de ressources. DPM peut en effet améliorer les performances de la carte graphique, car le code agit sur sa fréquence et ses tensions d’alimentation (technique : Dynamic Voltage and Frequency Scaling). Jusqu’à présent le pilote libre AMD ne modifiait pas ces paramètres, et les valeurs par défaut n’étaient pas forcément celles permettant de profiter de toute la puissance de la carte. Un autre test montre que, sur un échantillon de trois cartes graphiques différentes, on constate une réduction de la consommation en Watts (jusqu’à 40 %) et une réduction de la température (de quelques degrés).
Notons tout de même que DPM n’est pas activé par défaut, du fait de la jeunesse du code.
ASPM : gestion d’énergie pour le bus PCI-Express
Pour rester dans l’énergie, ASPM (Active State Power Management) est une autre fonctionnalité utilisée pour gérer la consommation énergétique des périphériques PCI Express. Cette fonctionnalité introduit deux modes basse consommation, équivalents des C-States des CPU. Le niveau d’endormissement L0 est sélectionné dès que le lien devient inactif, alors que le niveau L1 est sélectionné après une période d’inactivité supérieure. Le niveau L1 permet d’économiser plus d’énergie, au prix d’une latence de sortie d’endormissement supérieure.
L’ASPM avait déjà fait parler de lui en 2011, lorsque sa politique d’activation a été modifiée dans Linux pour pallier les crashs rencontrés avec le matériel bogué. Cela s’était traduit par une distribution plus stable pour certains et une consommation énergétique bien supérieure pour certains autres malchanceux. Une meilleure politique d’activation a ensuite été ajoutée dans la version 3.3 de Linux.
La prise en charge de l’ASPM est maintenant gérée pour les familles R600 à Southern Islands. C’est‐à‐dire toutes les cartes récentes, sauf la toute dernière génération.
Prise en charge des cartes Sea Islands avant leurs sorties !
Comme si l’amélioration de la gestion d’énergie ne suffisait pas, AMD a aussi publié la prise en charge du KMS, de la 3D, du décodage vidéo (UVD) et d’OpenCL pour les cartes de la famille Sea Islands ! Outre le fait que la prise en charge presque complète pour une famille de cartes arrive d’un seul coup est impressionnant, c’est la première fois (pour Radeon) que cela arrive pour une carte qui n’est pas encore sortie !
En effet, les premières cartes de la famille Sea Islands devraient être disponibles en octobre 2013. Avec un peu de chance, la gestion d’énergie pour les cartes de la famille Sea Islands pourrait être ajoutée au prochain noyau Linux, ce qui amènera le même niveau de prise en charge à cette famille que pour les autres cartes modernes.
AMD a donc rattrapé son retard, et on peut supputer qu’il fera de même pour les prochaines familles de cartes. Dorénavant, il devrait être possible d’utiliser le pilote libre dès la sortie du matériel, en utilisant un noyau Linux stable (idéalement, toutefois, il faudrait qu’AMD prenne encore un peu plus d’avance pour que les différents composants — noyau, pilote, Mesa — soient à jour dans les dernières versions des distributions au moment de la sortie du matériel comme Intel essaye de le faire de son côté) !
Plus d’informations
Pour plus de détails sur les changements, voir ce courriel de dri-devel de juin et celui‐ci de juillet. Il est aussi intéressant de lire l’interview de Jérome Glisse, développeur des pilotes Radeon chez Red Hat pour comprendre les conditions dans lesquelles se fait le développement du pilote libre AMD Radeon.
Autre pilote vidéo
Le pilote QXL qui est apparu dans la précédente version a reçu des améliorations : redimensionnement dynamique, possibilité d’avoir plusieurs sorties vidéos et prise en charge de l’hibernation et de la mise en veille.
Systèmes de fichiers
Pas de grosses nouveautés dans les systèmes de fichiers grand public.
ext4
Concernant le système de fichiers ext4, qui est installé par défaut dans la plupart des distributions GNU/Linux, on peut noter beaucoup de corrections de bogues, de nettoyage de code et d’optimisations.
Au niveau des corrections de bogues, il en est une à noter concernant le redimensionnement à chaud des systèmes de fichiers où la taille des blocs est plus petite que la taille d’une page (sur une architecture x86, elle est de 1 Kio. Plus utile, sur une architecture IA-64 ou Power, où la taille est de 4 Kio).
Dans la catégorie nettoyage de code, la mise en œuvre de la perforatrice de l’ext4 a été vraiment améliorée et prend maintenant en charge les systèmes de fichiers de type bigalloc. Par ailleurs, Jan Kara a nettoyé de façon significative le nom d’accès du code de demande d’écriture. Enfin, la vérification d’erreurs a été améliorée et quelques vérifications de bonne santé du système de fichiers ont été ajoutées.
Concernant les optimisations, il y a deux points importants à mettre en valeur. La première est que ext4_writepages() est maintenant utilisé pour le mode sans allocation différée (nodelalloc) et pour le mode de compatibilité avec l’ext3. La seconde, si vous suivez encore, est que le mécanisme de réduction du cache extent qui a été ajouté dans le noyau 3.9, n’a plus de goulet d’étranglement au passage à l’échelle dû à un verrou tournant (ou spin lock). D’autres optimisations ont permis de réduire l’utilisation du processeur.
Comme vous le voyez, le système de fichiers ext4 est devenu un système mûr spartiate en nouveautés.
Pour plus d’informations, voir le pull Git.
Btrfs
Btrfs est en général présenté comme le successeur d’ext4. Mais son but principal est de fournir un système de fichiers pour les nuages qui concurrence, par exemple, XFS. Peu de nouveautés le concernant, seulement des améliorations de performance, des corrections de bogues et du nettoyage de code. Il est tout de même à noter la suppression de la structure btrfs_sector_sum qui permet d’améliorer la performance en écriture sur un disque SSD d’environ 70 %. Pour le moment seuls Oracle et SUSE supportent ce système de fichiers qui n’est toujours pas en version stable.
Pour plus d’informations, voir le pull Git.
Vous pouvez voir sur Phoronix une série de tests de performance sur Btrfs selon les options de montage. Cela met en évidence de grosses différences de performance en fonction des options que l’on utilise. Il est donc nécessaire de bien étudier cela avant de mettre en place Btrfs sur son infrastructure.
XFS
Concernant le système de fichiers XFS, il y a du nouveau : le travail pour le projet de quotas et de groupe de quotas pour qu’ils soient utilisés ensemble a commencé à être inclus dans le code. Ajout d’un compteur de changement d’inœuds et d’une transaction créant un inode.
Par ailleurs, il y a des améliorations de performance lors de la suppression et de la création d’inœuds, lors de la lecture à l’avance d’une ou plusieurs pages en mémoire cache (readahead buffer), et lors de bulkstat. Enfin, il y a des corrections de bogues et du nettoyage de code.
Pour plus de détails, voir le pull Git.
F2FS
F2FS (Flash-Friendly File-System) est un système de fichiers récent qui a été introduit dans le noyau 3.8. Il a été créé par Samsung pour les mémoires Flash de ses téléphones.
Peu de nouveautés le concernant. F2FS gère maintenant les attributs étendus xattr de sécurité. Il est maintenant possible de remonter à chaud (avec l’option remount) les partitions F2FS.
Pour finir, on peut noter un test de performance des différents systèmes de fichiers (ext4, Btrfs, XFS et F2FS) sur les noyaux 3.9, 3.10 et 3.11-rc1, en utilisant les options de montage par défaut. Il est difficile de troller faire la comparaison entre les différents systèmes de fichiers étant donné que les options de montage peuvent faire varier de façon sensible les résultats. Il est plus intéressant de voir l’évolution de chaque système de fichiers par rapport au noyau.
Lustre
Vous vous rappelez peut‐être de Ceph ? Ceph et Lustre sont des systèmes de fichiers distribués et parallèles utilisés sur les grappes de serveurs. Ceph est déjà intégré dans le noyau depuis des lustres (sic). Si l’on veut résumer grossièrement la différence entre Ceph et Lustre : Ceph est utilisé pour sa haute disponibilité, Lustre pour sa haute performance.
La partie client du système de fichiers Lustre est maintenant dans la section staging du noyau (emplacement pour du code en développement mais n’étant pas encore de qualité suffisante pour les exigences des développeurs du noyau). Cela permettra pour l’utilisateur final une facilité d’installation et de mise à jour. Cependant, pour éviter des problèmes de jeunesse de code, il a été désactivé pour cette version.
Autres améliorations
- On pourra à l’avenir utiliser des applications de Windows RT (le Windows qui utilise l’architecture ARM) en utilisant Wine ;
- Mise à jour de pilotes pour des appareils récents.
Statistiques
Voici les statistiques des nationalités des développeurs de Linux 3.0 à Linux 3.11 (rc7) pour le nombre de lignes modifiées :
Les nations importantes depuis le noyau 3.0 sont :
- les États‐Unis (moyenne : 20 %, en bleu foncé) ;
- l’Allemagne (moyenne : 8 %, en jaune) ;
- la Chine (moyenne : 7 %, en rouge) ;
- l’Angleterre (moyenne : 6,5 %, en vert) ;
- les Pays‐Bas (moyenne : 4,8 %, en orange).
La France et la Belgique ont chacune une moyenne de 1,3 %.
Il y a quelque chose de remarquable pour ce dernier noyau c’est le pourcentage de la Chine (en rouge) sur le noyau 3.11 (plus de 28 % contre moins de 18 % pour les États‐Unis). Est‐ce que les Chinois vont supplanter l’hégémonie américaine sur le noyau Linux ?
Peut‐être pas encore. Le système de fichiers Lustre a été intégré au noyau Linux 3.11 par Peng Tao, un développeur chinois. Cette modification représente 85 % des lignes modifiés par la Chine. Donc, a priori, c’est épisodique.
Il faut tout de même relever le nombre de personnes dont on ne connaît pas la nationalité (moyenne : 24,5 %, en noir).
Aller plus loin
- Sortie du noyau précédent (186 clics)
- [parityportal.com] Linux 3.11 features (171 clics)
- Noyaux précédents (100 clics)
- [LWN.net] The 3.11 merge window closes (56 clics)
- [LWN.net] The 3.11 merge window opens (29 clics)
- [h-online.com] “Linux for Workgroups”: Linux 3.11’s feature set now confirmed (101 clics)
- kernelnewbies.org (135 clics)
- [Phoronix] Recapping The Linux 3.11 Kernel Features (148 clics)
# Cartes graphiques AMD
Posté par Vinm (site web personnel) . Évalué à 3.
Les cartes graphiques "Southern Islands" sont-elles les r7*** ou les r6*** ?
[^] # Re: Cartes graphiques AMD
Posté par Moonz . Évalué à 7.
Ça correspond aux 7xxx
http://en.wikipedia.org/wiki/Radeon#Technology_Overview
[^] # Re: Cartes graphiques AMD
Posté par Vinm (site web personnel) . Évalué à 1. Dernière modification le 03 septembre 2013 à 17:06.
ok merci
# Sea Islands déjà sortie (HD 7790)
Posté par misaflo (site web personnel) . Évalué à 8.
La radeon HD 7790, sortie en mars 2013, est une carte (la seul actuellement) de la famille Sea islands d'après http://wiki.x.org/wiki/RadeonFeature/#index5h2
C'est la carte que j'ai, actuellement inutilisable (linux 3.10) avec le pilote libre. J'ai hâte de retester ça avec cette nouvelle version. :)
Et vivement la suivante pour la gestion dynamique de l'énergie, merci AMD.
# Tournure de phrase à revoir
Posté par windu.2b . Évalué à 5.
Je trouve cette phrase mal formulée, et ne suis pas sûr, du coup, de bien l'interpréter.
Il vaudrait mieux dire, soit "(fichiers qui n'ont pas besoin d'être visibles dans le système de fichiers)", soit "(fichiers qui ont besoin d'être invisibles dans le système de fichiers)", selon ce que l'on cherche à dire.
[^] # Re: Tournure de phrase à revoir
Posté par Benoît Sibaud (site web personnel) . Évalué à 2.
Corrigé, merci.
[^] # Re: Tournure de phrase à revoir
Posté par Nanawel (site web personnel, Mastodon) . Évalué à 3.
Coquille :
paLLier les
[^] # Re: Tournure de phrase à revoir
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# Beaucoup de boulot
Posté par ariasuni . Évalué à 9.
Tout d’abord je tenais à remercier les contributeurs pour la qualité de la dépêche.
On se rend mieux compte du boulot qu’a fournit AMD par rapport à l’entrevue de Jérome Glisse. Je n’utilise pas de carte AMD mais avant j’avais une ATI, et je n’ai jamais réussi à la faire fonctionner correctement sur Ubuntu, j’avais tout essayé jusqu’à péter mon serveur X.
Donc, merci AMD.
Maintenant j’ai une carte Nvidia, et le support de l’accélération vidéo pourrait bien me faire passer définitivement au pilote nouveau, je testerais comme je le fais à chaque sortie d’une nouvelle version de Linux pour voir si les performances me satisfont. C’est aussi sympa de savoir que de nombreux bugs ont été corrigé (j’en rencontraient déjà pas beaucoup), nouveau est vraiment un pilote mature maintenant.
Ensuite, même si ext4 n’évolue pas beaucoup, c’est toujours de plaisant de savoir qu’il est toujours maintenu et amélioré, surtout si c’est pour avoir un code plus simple à maintenir, plus de stabilité et consommer moins d’énergie.
Finalement, on peut saluer le fait que malgré l’âge et la maturité de Linux, des nouveautés concernant les performances continuent d’arriver (je pense notamment à Zswap et LZ4).
Pour le premier, est-ce activé par défaut? Si oui comment fait-on? Est-ce que c’est assez efficace pour «remplacer» la swap dans la plupart des cas? J’imagine que le gain de performance doit être appréciable, ainsi que l’augmentation de la durée de vie du SSD!
Pour le deuxième, j’attends avec impatience que ça arrive pour x86. Par contre il n’est pas expliqué pourquoi ça a été implanté en premier pour ARM. C’est juste parce c’est plus facile ou que personne ne voulait le faire pour x86?
P.-S.:
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Beaucoup de boulot
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Typo corrigée, merci.
[^] # Re: Beaucoup de boulot
Posté par ariasuni . Évalué à 3.
D’après le wiki de nouveau, il faut que j’attende Linux 3.12 et Mesa 9.3 pour avoir l’accélération graphique pour ma carte (moteur VP4). Doh.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Beaucoup de boulot
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Et aussi dans le paragraphe RC-7, je suppose qu'il faut lire :
au lieu de :
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Beaucoup de boulot
Posté par ZeroHeure . Évalué à 2.
corrigé, merci
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Beaucoup de boulot
Posté par Martin Peres (site web personnel) . Évalué à 4.
Et ça suffira que si tu veux accélérer le décodage mpeg1/2. Pour h264, ça marche pas encore et le dev sait pas encore pourquoi. Il devrait s'y re-pencher assez rapidement.
[^] # Re: Beaucoup de boulot
Posté par ariasuni . Évalué à 2.
Ouais j'ai vu, mais bon à part pour Youtube je pense que ça sera pas trop gênant. Je testerais quand le noyau sera dispo dans le dépôt [core] d'Arch Linux.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Beaucoup de boulot
Posté par Jarvis . Évalué à 1.
Je ne sais plus où j'ai lu qu'il n'y aura plus de nouveautés importantes pour ext4. On est plutôt en train de préparer ext5.
[^] # Re: Beaucoup de boulot
Posté par ariasuni . Évalué à 7.
Je ne sais pas où tu as lu ça, mais ici et là c’est plutôt le contraire (pas de ext5 en vue).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Beaucoup de boulot
Posté par MTux . Évalué à 9.
Et surtout ext4 est l'un des meilleurs FS du moment, le compromis stabilité/performances. Perso j'ai pas envie d'en changer pour le moment.
/me se souvient de l'époque ext3 où tous les 30 démarrages tu patientais 15min le temps qu'il fasse une vérification complète.
[^] # Re: Beaucoup de boulot
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
J'ai essayé ext4 mais pas moyen d'avoir des quotas par défaut (ou j'ai pas trouvé) donc je suis revenu sur les dossiers partagés à XFS qui a toujours très bien marché sur mes gros volumes.
[^] # Re: Beaucoup de boulot
Posté par Thomas Debesse (site web personnel) . Évalué à 6.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Beaucoup de boulot
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Je ne parle pas de cela que je sais faire. Tu a un dossier /data sur un volume séparé (type LVM) et tu veux avoir un quota par défaut sur une personne AVANT que celle-ci n'est crée le moindre fichier. Je ne sais faire cela qu'avec XFS.
xfs_quota -x -c 'limit -d bsoft=50G bhard=50G' /data
Idem avec /home, les sous dossiers se crée automatiquement et on a, via ce mécanisme, un quota par défaut sans rien faire. Sur les HOME, je sais que via pam, il y a une bidouille possible sur les Red-Hat mais cela reste une bidouille…
[^] # Re: Beaucoup de boulot
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Au temps pour moi, je n'avais pas compris. Mais cela m'étonne, il me semble qu'on peut affecter un quota à une personne qui ne possède aucun fichier, par contre, petit bug un peut gênant pour la supervision mais qui ne change pas le fonctionnement, repquota ne montrera le quota valide que si un fichier est créé par cet utilisateur. Enfin, tout d'un coup tu me fais douter…
Par contre ce que je ne sais pas faire, c'est attribuer un quota par défaut même pour les utilisateurs qui n'existent pas encore ou à qui on n'a pas affecté de quota particulier, mais en fait ce besoin ne m'est jamais apparu étant donné qu'il est simple de faire en sorte que le quota de chaque partition pour l'utilisateur soit renseignée à sa valeur par défaut à la création de l'utilisateur, ou bien de faire en sorte que le quota de chaque utilisateur soit renseignée à sa valeur par défaut à la création de la partition. La commande que tu cites est donc pratique, mais dans les faits je ne m'en suis jamais rendu compte de son absence. ^^
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Beaucoup de boulot
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Je (co)gère un laboratoire ayant plein de dossier partagé, exemple partition de données pour le calcul, espace personnel pour le web, home sur les postes de travail… Les doctorants entre et puis s'en vont, idem pour les stagiaires… Avec les quotas par défaut, les choses se font bien et quasiment toute seule sans erreur sur tout le parc, c'est plus que pratique ;-)
[^] # Re: Beaucoup de boulot
Posté par shbrol . Évalué à 2.
merci pour la syntaxe "<<\EOF patch", je connaissais pas, je gardes ça précieusement dans un coin.
[^] # Re: Beaucoup de boulot
Posté par Thomas Debesse (site web personnel) . Évalué à 6.
Oué, on appelle cela les Here Document ou heredoc, il y a moyen de faire des trucs passionnants avec, comme la possibilité d'inclure des fichiers complets à l'intérieur même de scripts !
Ce script complexe :
Donne cela chez moi :
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Beaucoup de boulot
Posté par ariasuni . Évalué à 4.
heretic doc? :p
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Beaucoup de boulot
Posté par Kerro . Évalué à 2.
Chez moi la syntaxe
ne fonctionne pas.
Il faut mettre des guillemets (simples ou doubles) :
Hélas, les guillemets impliquent que le contenu n'est pas interprété.
--> copié/collé de ton code ne fonctionne pas chez moi.
Mon Bash a un problème ?
[^] # Re: Beaucoup de boulot
Posté par Thomas Debesse (site web personnel) . Évalué à 4. Dernière modification le 06 septembre 2013 à 18:27.
Hum en effet, mais j'ai trouvé pourquoi :
l'erreur est ici :
Normalement ce doit être une tabulation en début de ligne, le <<-EOF cherche le "(zéro ou une infinité de tabulations)EOF" comme fin de fichier, alors qu'on lui donne "espace-espace-espace-espaceEOF", donc le document ne se termine jamais. C'est la faute à linuxfr qui transforme les tabulations en suite d'espaces ! de même il faut des tabulations en début de ligne du here doc pour qu'elles soient ignorées, si tu mets une tabulation avant le EOF mais des espaces avant le début des lignes du heredoc, ton heredoc aura des espaces en début de ligne !
C'est peut-être le seul cas en shell où l'indentation doit obligatoirement être faite avec des tabulations.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Beaucoup de boulot
Posté par Kerro . Évalué à 1.
Non non, j'ai fait le test avec uniquement des tabulations. Je suis bien obligé de mettre des guillemets.
… et là je refais le test et ça fonctionne.
J'ai merdé quelque part.
Je n'ai par contre pas besoin d'utiliser la structure "if then fi". Pour quelle raison l'utilises-tu ?
[^] # Re: Beaucoup de boulot
Posté par Thomas Debesse (site web personnel) . Évalué à 5.
Ça ne sert à rien un « if true », c'était juste une manière de mettre en situation une indentation. C'est un exemple de contexte, c'est cosmétique pour l'exemple. L'utilisation de
<<-EOFpour ignorer les indentations se rencontre très généralement dans des blocs indentés comme les blocs if, while, case, for etc. Donc j'ai fait un if, mais il est toujours vrai pour que l'exemple soit interprété.De toute manière l'ensemble du script ne sert à rien. Un
rot13 | rot13non plus. :) J'ai glissé pleins de trucs inutiles ou des constructions volontairement cryptiques, comme l'utilisation du s comme séparateur pour sed, dans'ss *$ss', au lieu du plus commun's/ *$//', commande sed qui remplace le motif' *$'par''(rien).Bon, cela dit, j'espère que tu as testé dans un environnement non privilégié et sur un système sans importance, parce qu'exécuter un code trouvé sur le net qui génère du code qu'il exécute, avec en plus des trucs comme
rm -rf /glissé dans les coins… C'est risqué ^^.ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Beaucoup de boulot
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9.
C'est la syntaxe heredoc en shell, mais écrite d'une façon assez inhabituelle. La plupart des gens placent plutôt les redirections, en heredoc ou non d'ailleurs, à la fin de chaque ligne de commande :
Mais tu peux tout à fait écrire cela ainsi, ce que je trouve moins évident à comprendre :
En fait on peut mettre les redirections où on veut sur une ligne de commande, même en plein milieu des arguments, lorsqu'il y en a.
# Btrfs
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
ZFS plutôt non ?
[^] # Re: Btrfs
Posté par goofy . Évalué à 1.
Cela apporte vraiment quelques chose niveau performances en desktop la compression LZO ?
Et space_cache et ou auto-defrag ?
Toujours niveau performances il vaut mieux une grosse partition et des subvolumes ou plusieurs partitions ?
Désolé, mais je ne trouve pas d'informations claires à ce sujet et surtout de confiance … (pas envie de bousiller mes données ;-) )
[^] # Re: Btrfs
Posté par Jarvis . Évalué à 2.
ZFS n'est pas intégré dans le noyau linux (pour des raisons de licences si je ne me trompe pas). Donc Btrfs ne concurrence pas directement ZFS vu qu'il faut installer un autre OS comme freeBSD. Après c'est vrai qu'il est possible d'installer ZFS sous Linux (cf ici)…
Quant à XFS, si j'en crois ce lien :
Je pense donc bien que Btrfs concurrence XFS.
[^] # Re: Btrfs
Posté par MTux . Évalué à 10.
Non btrfs concurrence bien ZFS :)
Il le concurrence justement car ZFS est utilisé par Solaris et FreeBSD. Sur Linux il faut donc une solution équivalente.
Les deux sont faits pour fonctionner dans du datacenter, avec une gestion native des redondances (raid, raidz…) checksum à la volée, et un max de consommations de ressources CPU & RAM dès que tu actives le cache.
[^] # Re: Btrfs
Posté par navaati . Évalué à 3.
Et surtout des fonctionnalités comme les subvolumes et le copy-on-write.
# Fichiers anonymes
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8. Dernière modification le 03 septembre 2013 à 17:39.
Si je comprends bien, il s'agit de pouvoir créer des fichiers anonymes, c'est à dire présents sur un système de fichier, mais avec zéro nom — ou zéro lien selon le terme que vous préférez —, et qui seront donc automatiquement détruits une fois refermés. Comme des fichiers qu'on aurait créés avec un nom, puis immédiatement unlinkés, c'est bien ça ?
Le rapport avec la sécurité, c'est que sans nom, il n'y a aucun risque de collision de nom, n'est-ce pas ?
[^] # Re: Fichiers anonymes
Posté par VinDuv . Évalué à 8.
C’est aussi pour éviter qu’un autre processus ne puisse ouvrir le fichier (entre sa création et sa suppression) pour aller lire ou écrire dedans. Le but recherché est que seul le processus qui a créé le fichier puisse le faire (il peut bien sûr une fois le fichier anonyme créé transférer cette possibilité à d’autres processus en transférant son descripteur de fichier, mais il a le contrôle).
À priori il est possible, lors de la création d’un fichier anonyme, de s’assurer que personne n’a ouvert le fichier entre sa création et sa suppression, mais ça peut être délicat (il faut récupérer après la suppression le nombre de fd ouverts sur le fichier et s’assurer qu’il est égal à 1—si ce n’est pas le cas, on réessaye). Au moins avec O_TMPFILE ça sera directement sécurisé.
[^] # Re: Fichiers anonymes
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
Et n'élimine pas la race condition, puisque ce n'est pas un appel atomique. Sauf à compter le nombre de fd après avoir unlinké ?
[^] # Re: Fichiers anonymes
Posté par goeb . Évalué à 2.
Est-ce que O_TMPFILE est conforme à POSIX ? ou autre standard ?
[^] # Re: Fichiers anonymes
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
Non, extension propriétaire.
[^] # Re: Fichiers anonymes
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Spécifique certes, mais propriétaire ?
[^] # Re: Fichiers anonymes
Posté par navaati . Évalué à 5.
Ben, oui, c'est le contraire de standard…
[^] # Re: Fichiers anonymes
Posté par Zylabon . Évalué à 2. Dernière modification le 04 septembre 2013 à 18:12.
Propriétaire… ou agraire. N'est-ce pas ?
À moins que ce soit psychologique…
Please do not feed the trolls
[^] # Re: Fichiers anonymes
Posté par Zenitram (site web personnel) . Évalué à 2.
Non standard (aka propriétaire pour ce sujet aka lié à une seule entité, ici Linux aka on s'en fout des autres ils ont qu'à faire comme nous) si tu préfères.
[^] # Re: Fichiers anonymes
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 4.
Je me disais bien que j'aurais des réactions ;) C'est à cause de ce genre de subtilité que RMS préfère parler de logiciels privateurs, puisque des logiciels sont la propriété d'une entité au final : la FSF.
Du coup, une extension spécifique qui n'a pas de réalité standard est forcément propriétaire.
# Zswap
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Il me souvient qu'il y a quelques mois, ou peut-être un an, un système plus manuel était apparu dans le noyau. À l'époque, il s'agissait d'allouer, manuellement donc, de l'espace mémoire pour former un périphérique bloc compressé, puis de l'utiliser comme swap. Ce nouveau système le remplacerait, mais avec un mécanisme automatique et adaptatif ?
[^] # Re: Zswap vs Zram
Posté par Kioob (site web personnel) . Évalué à 5.
Ce sont deux mécanismes complémentaires : l'autre donc, c'est "zram" : il permet de créer un blockdevice en mémoire, qu'on peut ensuite formater de type swap puis faire un "swapon" pour l'utiliser.
C'est un peu plus polyvalent, je m'en suis également servi pour gérer le /tmp/ de certains serveurs MySQL ayant des traitements de cochons (de gros volumes de données qui transitaient par le /tmp/).
Mais à l'usage j'ai quand même eu pas mal de problèmes de fuite mémoire avec "zram", si bien que je ne l'utilise plus du tout. Peut-être que zswap sera mieux suivi.
Le comble là dedans pour moi c'est qu'à moins que je confonde, "zram" était à l'origine Compcache, un module spécialisé dans la compression du swap. Et c'est lors de l'intégration upstream qu'ils l'ont fait évoluer vers quelque chose de plus générique.
alf.life
[^] # Re: Zswap vs Zram
Posté par barmic . Évalué à 4.
Pour faire ça j'ai plutôt tendance à utiliser tmpfs.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Zswap vs Zram
Posté par Kioob (site web personnel) . Évalué à 4.
Bien sûr, la principale différence étant la compression à la volée, que tmpfs ne fait pas.
alf.life
[^] # Re: Zswap vs Zram
Posté par Pierre Roc . Évalué à 1. Dernière modification le 05 septembre 2013 à 13:23.
Ah c’est donc ça… J’ai des fuites mémoires dont je n’ai jamais su trouver l’origine.
Toutefois, il me semble qu’il y a une nette différence d’usage entre les deux. Zram me permet de créer une zone de RAM compressée en plus du swap “dur” via :
(Au passage, on peut ensuite créer des tmpfs qui, je suppose, seront compressés au besoin…)
Tandis que zswap permettra de compresser uniquement la partie de la mémoire qui se trouve sur le disque dur.
# LZ4
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
Eh bien, LZO étant déjà optimisé pour la vitesse, ça doit être quelque chose, ce LZ4 ! En revanche, disponiblement uniquement pour ARM, ça c'est moche, très moche.
[^] # Re: LZ4
Posté par Loïc Blot (site web personnel) . Évalué à 4.
Je suis étonné. suite à cette dépêche je viens de recompiler le kernel pour mon PC portable (optimisations, nettoyages de drivers…), et je vois bien l'option LZ4 pour le kernel et le initramfs. C'est en cours de compilation, à voir d'ici 1h environ :)
Veepee & UNIX-Experience
[^] # Re: LZ4
Posté par Sidonie_Tardieu . Évalué à 9.
2h + tard.
Ça t'a aussi compressé ton cla ?
Pour un sextumvirat ! Zenitram, Tanguy Ortolo, Maclag, xaccrocheur, arnaudus et alenvers présidents !
[^] # Re: LZ4
Posté par Loïc Blot (site web personnel) . Évalué à 2.
Euh oui, désolé, en fait j'ai fini tard car j'avais des soucis avec le radeon.DPM sur ce kernel et j'étais en déplacement ensuite.
En fait, cela fonctionne bien, on peut compresser le noyau et le initramfs.
Pensez à installer lz4c si vous ne l'avez pas avant de compiler.
Veepee & UNIX-Experience
[^] # Re: LZ4
Posté par rogo . Évalué à 10.
Ce serait moche, mais ça me semble douteux. Quelle est la source de cette info ?
Parce que, sauf erreur, dans le commit qui ajoute la décompression LZ4, toutes les architectures semblent supportées :
Dans les commits qui complètent le support LZ4, à savoir la compression et le noyau LZ4, rien n'est écrit sur une particularité ARM.
[^] # Re: LZ4
Posté par Jarvis . Évalué à 1.
Ma source
Mais si on lit kernelnewbies, il ne parle pas d'architecture.
Donc je pense que vous avez raison : c'est pour toutes les architectures. Il faut donc corriger cela dans la dépêche.
[^] # Re: LZ4
Posté par claudex . Évalué à 3.
En lisant rapidemment les commits, je ne vois pas pourquoi l'article de Phoronix spécifiait que c'était spécifique à ARM. Il y a bien des bouts spécifique (pour le boot) mais ces parties sont aussi dans les parties génériques utilisées par x86 il me semble.
« 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: LZ4
Posté par JGO . Évalué à 6. Dernière modification le 04 septembre 2013 à 10:02.
LZ4 existe pour toutes les architectures, c'est la compression pour le noyau utilisant LZ4 qui d'après la dépêche☆ n'est disponible que pour ARM. L'intérêt est de gagner encore quelques millièmes de secondes à la décompresssion du noyau (au démarrage) alors que sur d'autres architectures plus puissantes la différence avec LZO est négligeable.
https://code.google.com/p/lz4/ (réorganisé par vitesse de décompression).
Name Ratio Compr DecompressionMB/s MB/sLZ4 HC (r101) 2.720 25 2080LZ4 (r101) 2.084 422 1820Snappy 1.1.0 2.091 323 1070LZO 2.06 2.106 414 600LZF 2.077 270 570QuickLZ 1.5.1b6 2.237 373 420zlib 1.2.8 -6 3.099 21 300zlib 1.2.8 -1 2.730 65 280☆ d'après mon
menuconfig, je peux choisir LZ4 (depuis cette version du noyau) alors que je suis en x86_64. D'habitude quand une option dépend de l'architecture il la désactive. J'ai pas encore essayé de booter avec compression LZ4 pour dire si ça marche…En outre d'après le lien fourni dans la dépêche, x86 est aussi supporté.
Kyungsik Lee (5):decompressor: Add LZ4 decompressor modulelib: Add support for LZ4-compressed kernelarm: Add support for LZ4-compressed kernelx86: Add support for LZ4-compressed kernelKconfig: Make x86 and arm kernels default to the LZ4-compressed[^] # Re: LZ4
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Mais c'est une tuerie, ce truc ! Ça défonce LZO presque à tout point de vue !
[^] # Re: LZ4
Posté par Symen . Évalué à 2.
Vu l'efficacité du truc, sera-t-il possible de l'utiliser pour ZSwap ?
[^] # Re: LZ4
Posté par navaati . Évalué à 4.
Nope, regarde : la vitesse de compression est horriblement lente.
[^] # Re: LZ4
Posté par grim7reaper . Évalué à 8. Dernière modification le 04 septembre 2013 à 11:54.
Uniquement en mode HC.
Le mode « standard » est plus rapide que LZO
[^] # Re: LZ4
Posté par navaati . Évalué à 1.
Ah wep, my bad.
[^] # Re: LZ4
Posté par windu.2b . Évalué à 2.
Le LZ4 HC est (beaucoup) plus lent à la compression, mais pas le LZ4, qui dépasse (de peu) LZO.
Du coup, qu'est-ce que "LZ4 HC", et pourquoi est-il si lent en compression, tout en étant meilleur en décompression ?
[^] # Re: LZ4
Posté par claudex . Évalué à 0.
Il va 3 fois plus vite en lecture, si c'est un peu pour toi, je ne sais pas ce qu'il te faut.
« 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: LZ4
Posté par JGO . Évalué à 5. Dernière modification le 04 septembre 2013 à 12:20.
LZ4 HC (r101) 2.720 25 2080LZ4 (r101) 2.084 422 1820LZO 2.06 2.106 414 600Il regardait la compression. En compression LZ4 HC est trop lent pour une utilisation dans un swap, en revanche LZ4 est un bon remplacement puisqu'il est à la fois un peu plus rapide que LZO en compression (422 au lieu de 414 Mo/s) et beaucoup plus rapide en décompression.
[^] # Re: LZ4
Posté par windu.2b . Évalué à 3.
Comme le dit le premier commentaire qui te répond, je comparais les débits en compression, puisque c'était le point abordé par le commentaire auquel je répondais.
# Goldilocks
Posté par NS8066 . Évalué à 10.
Bonjour,
Ce nom m'ayant intrigué, j'ai cherché à quoi il correspondait en fançais et j'ai fini par trouver qu'il s'agit de "boucle d'or" (celle des trois ours).
Mes deux cents.
[^] # Re: Goldilocks
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Précision ajoutée, merci.
[^] # Re: Goldilocks
Posté par coïn . Évalué à 4.
c'est je me rappelle bien l'histoire. c'est une petite fille qui profite du travail des ours (bouffe, lit, chaise) tout comme Linus récupère le taf des autres.
analogie marrante :)
# Hégémonie
Posté par Sytoka Modon (site web personnel) . Évalué à 10. Dernière modification le 04 septembre 2013 à 07:27.
Quand je vois les chiffres, pour moi c'est l'UE qui est en tête et pas les USA…
Si on veut faire avancer l'union, il faut commencer à prendre l'habitude de la double comptabilité, ce que le mouvement olympique nous refuse par ailleurs.
[^] # Re: Hégémonie
Posté par Maclag . Évalué à 10.
HS, mais pour le mouvement olympique, compter l'U.E. comme une seule entité n'aurait de sens que si les pays n'étaient pas représentés individuellement, donc avec plus d'athlètes en lice, et forcément plus de chances de décrocher une médaille.
À ce jeu là, les É.U. devraient pouvoir envoyer une équipe par état à chaque épreuve, et la Chine une par province.
[^] # Re: Hégémonie
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Les USA envoient plus d'athlètes que les français… A vrai dire, je n'ai pas fait le compte mais si quelqu'un a les chiffres, ce serait intéressant.
[^] # Re: Hégémonie
Posté par Renault (site web personnel) . Évalué à 2.
Justement, ce qu'on veut dire c'est que l'UE envoie plus d'athlètes que n'importe quel autre entité sportive pour une raison : chaque État envoie un contingent de taille très respectable pour se présenter sur un grand nombre d'épreuves. Si l'UE envoie sa propre équipe olympique, tu peux te douter qu'elle aura moins de place pour en envoyer car justement, l'UE aurait trop d'athlètes par rapport aux autres pays.
Du coup la comparaison des médailles UE-USA aujourd'hui n'a aucun sens, avec plus d’athlètes c'est facile d'en obtenir plus. Il faudrait attendre la fusion des équipes olympiques au sein de l'UE.
[^] # Re: Hégémonie
Posté par Creak . Évalué à 4.
Je me suis récemment expatrié au Canada et c'est marrant de voir qu'ici ils parlent rarement d'Allemands, Français, Italiens ou autre, ils parlent d'Européens, tout simplement.
[^] # Re: Hégémonie
Posté par DerekSagan . Évalué à 10.
C'est logique, ce sont des Américains.
[^] # Re: Hégémonie
Posté par barmic . Évalué à 3.
Idem avec les
asia…chinois.Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Hégémonie
Posté par Zenitram (site web personnel) . Évalué à 5.
Le mouvement olympique (et l'ONU aussi) ne fait que respecter les décisions des français, italiens, britanniques… de ne pas être considérés comme une entité étatique unique.
Un jour, on y arrivera à se présenter comme UE comme le font les américains ou les canadiens dans leur régions respectives. un jour… Encore lointain.
[^] # Re: Hégémonie
Posté par reynum (site web personnel) . Évalué à 3.
ça me fait encore étrange de lire des réflexions/commentaires comme celui-ci mais tout bien réfléchi j'approuve totalement. Car l'analogie est plus que correcte.
kentoc'h mervel eget bezan saotred
[^] # Re: Hégémonie
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 05 septembre 2013 à 09:15.
la, le G20 commence…
- Est-ce que tu entends parler du président de l'UE plus que du président de la GB ou de la France?
- Est-ce que tu entends parler du président des USA plus que du gouverneur de la Californie ou de New-York City?
Il faut m'expliquer comment on peut arriver à approuver totalement après réflexion car perso je ne vois vraiment pas comment on peut faire ça vu les affichages politiques actuels (que ce soit au niveau gouvernemental ou au niveau entreprises ou au niveau instituts de recherche).
Sytoka Modon a bien raison de dire "Si on veut faire avancer l'union (…)", mais c'est forcer l'analogie pour "vendre" l'UE, mais c'est bien aller à l'opposé (et c'est voulu) de l'analogie plutôt.
[^] # Re: Hégémonie
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Correcte en terme de taille, mais pas en terme d'identité nationale. Les États-Unis sont une nation, l'Europe un ensemble de nations.
[^] # Re: Hégémonie
Posté par reynum (site web personnel) . Évalué à 4.
Pour un chêne centenaire t'as beau mettre tout l'engrais que tu veux il faut 100 ans ! (trouvez la source :D)
Etats Unis = 230 ans (depuis l'indépendance)
Europe = ? je ne sais pas exactement car il y a plusieurs dates mais en tout cas beaucoup moins.
Il faut laisser le temps aux gens d'assimiler qu'en plus d'être des citoyen du monde ils sont aussi Européens. Peut être nos arrières petits enfants auront intégrés cela ? En tout cas j'essaye d'aller dans le sens ou les gens s'unissent plutôt que dans celui ou ils se tapent dessus.
PS : comme j'ai assez trollé aujourd'hui je désire que personne ne parle d'Europe économique en me contredisant dans les commentaires. Car je parle d'Europe géographique dans laquelle on se dit juste que le pays voisin n'est pas un ennemi mais simplement un pays d'Europe comme nous.
kentoc'h mervel eget bezan saotred
[^] # Re: Hégémonie
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7. Dernière modification le 05 septembre 2013 à 17:38.
Non, ça marche dans l'autre sens. Avant d'être citoyen du monde ou européen, on est d'abord français (correction : ou belge, ou suisse, ou canadien, ou d'un autre pays francophone selon le cas, puisque ce n'est pas Linux-France ici), avec des voisins, une administration, des collègues qui ont des références culturelles communes françaises et qui parlent français. Il faut d'abord apprendre à vivre avec son entourage proche, ou au moins à le supporter s'il est composé de gens chiants, pour pouvoir construire quelque chose ensemble, avant de s'imaginer une citoyenneté mondiale qui serait bien abstraite, puisque les autres gens du monde sont trop loin pour que cela puisse signifier grand chose.
Trop de gens se disent citoyens du monde sans que cela n'implique quoi que ce soit, et méprisent en même temps toute idée d'amour de leur patrie : quand on n'essaie pas d'aimer pas ce qui est proche et qu'on voit tous les jours, comment peut-on prétendre aimer ce qui est loin et qu'on n'a jamais vu ?
[^] # Re: Hégémonie
Posté par claudex . Évalué à 6.
Tu te dis donc plus proche des Guyanais parce qu'ils sont Français que des Espagnols, des Monégasques ou des Suisses ?
C'est marrant de dire ça alors que les trois pays que tu cite ne sont justement uniquement francophones et donc ne parlent pas uniquement français.
« 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: Hégémonie
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Le cas des colonies, même étroitement intégrées au point de ne plus être considérées comme telles, est très, très particulier, au point de constituer une exception, d'où la volonté de décolonisation lorsque l'intégration est trop faible pour justifier une unité nationale artificielle.
La langue n'est qu'une partie de l'identité nationale effectivement. Mais elle compte certainement, et on peut voir les problèmes d'unité que cause la différence culturelle et particulièrement linguistique en Belgique.
[^] # Re: Hégémonie
Posté par Thomas Douillard . Évalué à 3.
Il y a toujours eu des guerres de clocher, c'est moins le cas n'empêche que certains campagnards n'aiment pas spécialement les citadins et qu'une bonne partie de la françe n'est pas spécialement fan des Parisiens. Aux US il doit y (a) avoir des différences majeure entre New York et le sud profond. Ça a empêché la constitution des USA ou les français de constituer la france ? Non. La Belgique risque la césession, mais elle tient. L'allemagne est un état fédéral, un vrai. Chaque cas est différent, quoi. Des cas très particuliers ? Et si il n'y avait que des cas particuliers en la matière ?
[^] # Re: Hégémonie
Posté par Renault (site web personnel) . Évalué à 3.
C'est en ne peut plus vrai.
Un texan a une culture et vision des choses très différentes d'un new-yorkais ou d'un californien (et l'accent diffère aussi).
C'est bien la preuve qu'il est possible de vivre ensemble malgré des différences importantes.
[^] # Re: Hégémonie
Posté par antistress (site web personnel) . Évalué à 7.
mais qui a envie de vivre au milieu des texans ?!
[^] # Re: Hégémonie
Posté par reynum (site web personnel) . Évalué à 2.
En tout cas pas Lino Ventura :-D
kentoc'h mervel eget bezan saotred
[^] # Re: Hégémonie
Posté par barmic . Évalué à 4.
La phrase correcte ne serait pas :
?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Hégémonie
Posté par pasBill pasGates . Évalué à -2.
qu'une bonne partie de la françe n'est pas spécialement fan des Parisiens
Je te rassures, en Suisse non plus :)
[^] # Re: Hégémonie
Posté par barmic . Évalué à 6.
Donc tu défini l'identité nationale par :
Bref, je comprends ta définition et elle ne me paraît pas fausse, mais ce n'est à mon avis pas si simple que ça. Je dirais que tu as la bonne définition mais que toutes les identités nationales sont des cas particulier de cette définition.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Hégémonie
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4. Dernière modification le 06 septembre 2013 à 14:08.
Non, ce n'est pas simple, sinon il n'y aurait pas eu tant de guerres, entre autres. Tout ce que je voulais dire, c'est qu'avant d'être citoyen du monde ou simplement européen, on est d'abord de son pays, et dans pas mal de cas, de sa région.
Autant prendre un exemple concret : j'habite à Paris, capitale française avec des gens d'un peu partout en France. Ma famille vient également d'un peu partout en France : je me reconnais donc comme français, et relativement proche des autres français pour avoir envie de participer à la construction de notre pays.
Certaines régions ont une identité forte, par exemple la Bretagne, l'Alsace ou la Pays basque, ce dernier étant un cas très particulier dans la mesure où il est partagé entre deux États, la France et l'Espagne. Un bon nombre d'habitants de ces régions pourra se reconnaître breton, alsacien ou basque avant d'être français. S'ils aiment leur région, rien de plus normal.
En ce qui me concerne, suis-je proche des parisiens ? Oui, certainement. Suis-je proche des bretons ? Un peu moins, mais assez tout de même. Des guyanais ? Probablement beaucoup, beaucoup moins. Cette région fait partie de la France pour des raisons historiques, et j'ignore largement sa culture, donc je ne me permettrais pas d'avancer quoi que ce soit. S'agissant d'une petite région par rapport à la France métropolitaine, cette question les concerne d'ailleurs plus que moi : se sentent-ils, eux, proche des métropolitains ? Continuons : suis-je proche des népalais ? Non, sans le moindre doute, non.
Bref, ce que je voulais dire, c'est qu'avant d'être citoyen du monde ou membre d'une communauté large, pleine d'inconnus et de cultures différente de la nôtre, nous sommes d'abord de nos régions et de nos pays. Il faut assumer cela et agir en conséquence, parce que je vois mal comment on peut imaginer construire quelque chose avec des gens qu'on ne voit pas, qu'on ne connaît pas et qui n'ont pas ou peu de références communes avec nous, si on n'est pas capable de s'occuper d'abord de ce qui est proche.
Ça n'implique pas de ne rien faire à l'international, mais simplement de ne pas se contredire en prétendant par exemple aimer tous les peuples en admirant les traditions religieuses au cours d'un voyage en Inde, tout en criant « les curés, au bûcher, les grenouilles au bénitier » lorsqu'on croise des cathos un peu démonstratifs chez nous. C'est un exemple un peu extrême, donc en voici un autre : admirer une révolution arabe pleine de drapeaux tunisiens, tout en traitant de fachos un français qui mettrait un drapeau devant sa porte en dehors de la coupe du monde de foot.
[^] # Re: Hégémonie
Posté par barmic . Évalué à 10.
Ça va peut être te paraître un peu dur, mais c'est une vrai réponse de parisien que tu fais. Vous êtes le centre de l'univers en France. C'est un fait et c'est historique, mais quand on sort d'Ile-de-France, on voit des choses étranges comme des gens qui se sentent plus proches des italiens ou des allemands que des parisiens et qui en voit plus simplement parce que géographiquement c'est plus proche.
Je pense sincèrement qu'il faut abandonner l'idée d'une culture nationale comme si c'était un bloc. Ce qu'on appel l'identité national, c'est une sorte de grosse moyenne dans la quelle finalement soit on ne se retrouve pas dedans soit on y met se qu'on veut.
Je ne suis pas de culture française bien qu'ayant toujours vécu en France et ayant mes 2 parents français, j'ai une culture française (mais aussi geek, provençal, européenne, isèreoise, geek (libriste, jv,…), judokate, des années 90 et 2000, judéo-chrétienne…). Le fait que parmi ces cultures il y a la française ne la rend pas prévalente sur les autres.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Hégémonie
Posté par Jarvis . Évalué à 3.
Moyenne :
European : 31.2
Unknown : 24.5
American : 20.2
Asian : 17
Other : 7.2
Arbitrairement :
Asian (Chinese, Indian, Japan, Korean, Russian)
European (German, English, Netherland, Finlander, Polish, French, Belgian, Swede, Czech, Swiss, Austrian, Hungarian, Dane, Italian, Spanish, Ukrainian, …)
American j'ai laissé tel quel sans Canadian.
[^] # Re: Hégémonie
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
Pourquoi pas par continent effectivement ;-) Bizarre de ne pas mettre le canada avec les US et C'est vrai que l'asie fait alors fourre tout…
Il me semble qu'il y a un soucis sur la légende, le jaune marqué Asie ne devrait il pas être l'Europe ?
[^] # Re: Hégémonie
Posté par Jarvis . Évalué à 1.
La moyenne du Canada est de 0.6. Ça fait bizarre de rajouter cela aux États-Unis je trouve (ça change pas grand chose au graphique…). Après je comprends qu'il est difficile d'ajouter des chinois et des japonais.
Le but de ce graphique était surtout pour souligner exactement l'ampleur de l'hégémonie européenne au niveau du noyau par rapport aux États-Unis.
Il serait intéressant de connaître la répartition par état des États-Unis… J'imagine que beaucoup sont en Californie en Silicon Valley et peu de personnes développent dans le Texas. Mais si ça se trouve la répartition est meilleure…
Non non, c'est bien ça. Par exemple on voit bien que le jaune est dominant pour le dernier noyau grâce à la chine.
[^] # Re: Hégémonie
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
En fait, les chinois et les japonais se regardent depuis des siècles, cela ne me fait pas bizarre de les compter ensemble. c'est plus l'inde qui n'a pas grand chose à voir, l'Himalaya est une barrière bien plus imperméable que l'océan indien ;-) Enfin, les russes sont toujours inclassable mais il en faut toujours un ! Bref, jamais facile de grouper les choses…
Ceci, il faudrait transmettre l'idée à Jonathan Corbet.
# hmmm
Posté par mickabouille . Évalué à 1.
Goldilocks -> Boucle d'Or ?
[^] # Re: hmmm
Posté par Kioob (site web personnel) . Évalué à 1.
Il semblerait oui, cf au dessus : https://linuxfr.org/nodes/99078/comments/1481176
alf.life
# Les anonymes
Posté par Shunesburg69 . Évalué à 1. Dernière modification le 05 septembre 2013 à 15:49.
Dans les non identifiés, il doit y avoir pas mal de francophone. J'ai du mal à croire qu'on ait que 1%.
On est très branché anonymat en francophonie ;-)
[^] # Re: Les anonymes
Posté par claudex . Évalué à 7.
Je vois que tu ne compte pas la Belgique (ni les suisses) dans les francophones, la propagande flamande a encore bien marché.
« 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: Les anonymes
Posté par Shunesburg69 . Évalué à 0.
Bah si! La francophonie ça prend en compte tous ses pays vu qu'ils parlent français.
[^] # Re: Les anonymes
Posté par Zenitram (site web personnel) . Évalué à 2.
Il faut redescendre sur terre (et arrêter de penser que la francophonie se limite à la France).
[^] # Re: Les anonymes
Posté par Yth (Mastodon) . Évalué à 3.
C'est vrai : il y a aussi la Louisiane, Djibouti, et le Yukon.
Et quelques autres.
Ah, oui, j'oubliais les Seychelles !
Et les deux Congos.
Bref…
[^] # Re: Les anonymes
Posté par Shunesburg69 . Évalué à 0. Dernière modification le 03 octobre 2013 à 22:14.
Où voyez-vous que je parle de la France?
Francophonie = de langue française
Que je sache les Belges, les Québécois, les Suisses et les Luxembourgeois parlent également français (enfin pas tous).
[^] # Re: Les anonymes
Posté par Shunesburg69 . Évalué à 0. Dernière modification le 03 octobre 2013 à 22:19.
double post à supprimer
# radeon dpm c'est bien bugge
Posté par Albert_ . Évalué à 3.
Faites attention si vous avez une ati, le code pour le dpm est en effet bien jeune et bien bugge.
https://bugs.freedesktop.org/show_bug.cgi?id=66963#c94
Avec une R600 je suis tombe sur dessus. Pas de chance et c'est dommage car visiblement le drivers fonctionne mieux que celui de intel sur ma machine (le jeu torchlight sous intel seul le curseur est visible alors qu'il fonctionne sans probleme sous la ati mais bon avec une carte qui monte a plus de 100 degre je prefere eviter…).
[^] # Re: radeon dpm c'est bien bugge
Posté par deasy . Évalué à 2. Dernière modification le 08 septembre 2013 à 23:06.
Perso j'attends une révision .x avant de tester, c'est trop tôt.
Merci aux enthousiastes comme toi pour les tests !
hmm refroidi bien ta machine…j'ai déjà fait tourner ma 4870 à 100-115 degrés durant des heures mais bon…chaud quoi !
C'est quand elle avait du mal à prendre de l'air parce que j'avais une carte réseau juste en dessous.
C'est le haut de gamme de 2008 et elle tourne toujours, elle a d'ailleurs tourner plusieurs années après encore ;)
[^] # Re: radeon dpm c'est bien bugge
Posté par Albert_ . Évalué à 2.
Ne t'inquiete pas je suis vite repasse sur la carte intel qui elle a d'autre bug mais ne chauffe pas :)
De tout de facon, niveau chauffe, ati je connais et je reprendrais pas (si je peux eviter). J'ai un autre vieux portable avec la aussi une ati et bien c'est le meme topo ca chauffe enormement mais sous windows et sous linux…
[^] # Re: radeon dpm c'est bien bugge
Posté par deasy . Évalué à 3. Dernière modification le 09 septembre 2013 à 16:20.
Si tu crois que c'est de la faute d'ati/AMD tu te mets le doigt dans l'oeil…déjà faut comparer ce qui est comparable…les gpu intel sont bien en dessous des petits gpu amd sur laptop.
Ensuite si il chauffe même sur Windows, c'est le fabricant de ton laptop qu'il faut blamer pour avoir sous-dimensionner le refroidissement.
C'est courant sur laptop, peu importe la marque du GPU.
Mon cousin a un laptop récent avec une nVidia et ben pareil, l'air qui en sort est brulant.
[^] # Re: radeon dpm c'est bien bugge
Posté par Albert_ . Évalué à 2.
C'est courant sur laptop, peu importe la marque du GPU.
Oui enfin les thinkpad ne sont pas specialement repute pour etre mal foutus… mais je n'ai peut etre pas eu de chance.
[^] # Re: radeon dpm c'est bien bugge
Posté par deasy . Évalué à 1. Dernière modification le 09 septembre 2013 à 21:12.
Bah si ça chauffe fort(gpu au delà de 70-75degré?) peu importe l'os c'est que le refroidissement est un-beaucoup sous dimensionné.
Donnes nous les températures idle et charge.
[^] # Re: radeon dpm c'est bien bugge
Posté par Albert_ . Évalué à 2.
Je ne dis pas que le refroidissement n'est pas sous dimensionne mais que les ATI ne sont pas faites pour des laptops car il faut une usine derriere pour refroidir correctement le GPU.
[^] # Re: radeon dpm c'est bien bugge
Posté par deasy . Évalué à 1. Dernière modification le 10 septembre 2013 à 12:35.
Tu aura une dissipation thermique similaire pour une même puissance de gpu sur des générations similaires, peu importe la marque.
Si tu as des besoins basiques un gpu intel accolé au cpu peut suffire…si pas tu aura un apu ou un gpu externe sur carte mxm qui chauffera plus ou moins suivant le nombre d'unité de calculs qu'il a.
[^] # Re: radeon dpm c'est bien bugge
Posté par Albert_ . Évalué à 1.
Bon j'ai eu quelques laptop (presque tous des thinkpad), les seuls qui aient eu des problemes thermiques sont ceux avec des GPU ati (quand il est en utilisation naturellement). Donc bon je veux bien que les constructeurs soient pourris, que la dissipation thermique soit la meme (ce qui est faux vu que si tu n'as pas de dpm comme c'est le cas avec les ati jusqu'au noyau 2.12 et qui fonctionnera peut etre pour le 2.13) mais bon je prefere eviter cette marque.
# Logo débile...
Posté par gyom gyom . Évalué à -4.
Salut à tous-toutes,
Je suis désolé, mais même étant gros geek et ayant sourri à la vue du logo, je le trouve complètement débile d'un point de vue comm'.
En effet, la comm' de certaines grosses boîtes (qu'on ne citera pas mais que tout le monde aura reconnu) s'amusent à rabacher au pékin moyen que linux est un sous-OS, parce non développé par une multinationale. Tous ces gens, qui n'auront pas compris la blague du logo, qui vont juste se dire "tient, linux vient tout juste d'atteindre le niveau technologique du windows qui existait quand j'ai commencé l'info. Rah ils sont vraiment toujours en retard. Jamais je vais utiliser ça".
Soit les dev du noyaux sont des gros nazes en comm', soit ils veulent vraiment que la majorité des gens continuent de penser de travers à propos de linux :
- soit que linux est un sous-OS, à peine du niveau de NT3.11, alors qu'on en est à win8.1, i.e. que linux a 6 générations de retard (98, millenium, XP, 7, 8, 8.1)…
- soit que linux c'est-pour-les-pro. Le neuneu de base peut pas l'installer/l'utiliser, vu qu'il faut être un méga-geek confirmé, ne serait-ce que pour comprendre les logos
[^] # Re: Logo débile...
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Il faut arrêter de prendre le pékin moyen pour un con de base ;-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.