En revanche ce qui sort du cadre habituel c'est la nouvelle mascotte qui a été adoptée pour cette version !
Dans le cadre de la campagne de sauvetage du diable de Tasmanie, les développeurs du noyau qui assistaient à la conférence LCA à Hobart ont participé à une vente de charité.
Linus Torvalds a promis de remplacer, pour une version, le brave manchot Tux par son diabolique cousin Tuz si la vente atteignait 3 500 dollars.
Comme le résultat final a été de près de 35 000 dollars nous pouvons profiter, juste pour ce 2.6.29 qui devient collector, de la présence de cet irascible marsupial dans le source du noyau.
Plus sérieusement vous trouverez le détail des évolutions, nouveautés et prévisions dans la seconde partie de la dépêche. La phase de test...
- La version RC-1 a été annoncée, dès le 10 janvier, par Linus du fait de la conférence LCA devant avoir lieu en Tasmanie :
"La période de merge est terminée (..) et maintenant il reste juste le petit détail consistant à s'assurer que tout est stable et prêt à être utilisé.
J'ai voulu publier la RC-1 suffisamment en avance pour que, quand il sera temps de partir pour la conférence LCA, nous ayons une RC-2 et que les plus horribles bugs de la RC-1 soient corrigés. Mais je sais bien que vous, les super développeurs, vous avez été tellement attentifs et soigneux qu'il n'y aura aucun bug n'est-ce pas ? Je suis certain que la RC-1 sera excellente. En quelque sorte...
(..) Ce qui ressort le plus c'est que nous avons intégré deux nouveaux systèmes de fichiers - btrfs et squashfs. Testez-les un bon coup et, s'il vous plaît, gardez en tête le fait que, si ces nouveaux systèmes de fichiers sont excitants, "nouveau" signifie aussi "pas vraiment testé". Je suis certain que les développeurs de btrfs vont apprécier vos tests mais je suggère que vous procédiez très prudemment (squashfs est en lecture seule, donc moins susceptible de boulotter vos données...mais qui sait ? La perversité de l'Univers est infinie)".
- Le 16 janvier c'est la RC-2 qui a pointé le bout de son nez :
"Environ la moitié des changements consiste en un merge tardif concernant MIPS (..) et il y a également quelques nouveaux pilotes. Le reste est vraiment petit.
Mais, en dépit du fait qu'ils soient petits, ces changements sont probablement plus importants et notables pour la plupart des gens : La première vague de corrections des régressions. Nous avons eu des bugs de l'accélération 3D sur de nombreuses machines (plus de compiz ! Que pourrions-nous faire sans ces fenêtres molles ?) qui devraient maintenant être corrigés.
Les corrections ne sont pas si importantes que ça mais franchement la RC-1 n'était pas très bonne. Certes il n'était pas prévu qu'elle le soit avec les vacances et tout ça. Donc j'espère que la RC-2 est revenue au niveau de qualité normale d'une RC-1, et peut-être un peu mieux".
- Il a fallu attendre le 28 janvier et le retour des développeurs de la conférence LCA (ou Linus a eu dans le cadre de la vente de charité en faveur du diable de Tasmanie, l'occasion d'exercer ses talents de barbier) pour que la version candidate RC-3 soit annoncée :
"C'est maintenant disponible et, bien que ce soit un peu gros par rapport à ce que je souhaiterais, cette taille est compréhensible car cela fait près de deux semaines entre la RC-2 et la RC-3 (du fait de la conférence LCA évidemment).
La partie la plus intéressante (au moins pour moi) des mises à jour de pilotes ce sont les corrections des fonctions PCI de mises en veille/réveil qui permettent enfin à l'un de mes portables d'avoir des fonctions _fiables_ de mise en veille/réveil.
Je ne surprends personne lorsque je dis que nous avons vraiment besoin des commentaires des utilisateurs sur tout les pilotes qui ne sont pas fiables aujourd'hui pour mettre en veille et réveiller proprement une machine.
Donc s'il vous plaît les gars — spécialement si vous utilisez la mise en veille — nous voulons avoir des rapports de régressions et nous avons besoin de savoir quel est votre matériel et quels sont les pilotes actifs.
Entendre parler des réussites est toujours agréable mais ce sont les régressions que nous voulons vraiment traquer".
- Le cycle s'est ensuite poursuivi sans histoire avec la RC-4 le 8 février :
"Encore une semaine (et demie) et encore une RC.
Des mises à jour d'architectures (sparc, blackfin), de pilotes (dvb, mmc, ide), d'ACPI, de systèmes de fichiers (ubifs, btrfs). Tout est là.
Mais le plus important c'est que les gens ont vraiment bossé sur les régressions et, espérons-le, cela résout les plus importantes sans, espérons-le aussi, en introduire d'autres".
- La version candidate RC-5 a été annoncée par Linus à peine cinq jours plus tard, un vendredi 13 :
"C'est un moment magique (complètement bidon) pour annoncer la sortie d'un noyau, donc le voici.
Pratiquement tous les changements concernent les pilotes et le reste est une collection de petites corrections triviales (juste comme j'aime). Alors allez-y et testez-le à fond parce que moi je vais passer ce week-end de trois jours complètement saoul à la plage. Quelqu'un doit bien se dévouer".
- Après cet intermède alcoolisé les RC-6 et RC-7 ont été annoncées et ont donné l'occasion d'une petite mise en garde :
"Le gros du patch consiste en l'ajout de deux nouveaux pilotes (le pilote réseau ATL1c et le pilote DVB Firewire FireDTV). C'est la nouvelle politique du "les nouveaux pilotes ne peuvent pas introduire de régressions", mais évidemment si vous choisissez de les compiler dans le noyau cela peut provoquer des problèmes (que vous ayez la carte en question ou pas) comme nous l'avons vu avec le pilote FireDTV ;)
A part ces deux nouveaux pilotes le reste n'est constitué que de petites corrections. J'espère qu'on s'approche de la version 2.6.29 finale mais vu la liste des régressions je suspecte qu'il y aura au moins une RC-8 avant ça".
- Il a effectivement fallu une version RC-8 annoncée le 12 mars pour corriger quelques problèmes de dernière minute dont l'un est assez inhabituel puisqu'il s'agit d'un bug matériel d'un processeur (reconnu par Intel dans sa documentation) :
"Ce que je trouve intéressant c'est que nous avons rencontré un bug lié à un erratum du processeur Atom, cela a pris un certain temps aux gens pour trouver la cause. C'est intéressant car c'est un cas assez rare.
Nous avons une correction (quoique peut-être pas définitive) dans cette version candidate, ainsi que pas mal d'autres petits changements".
Btrfs
Le système de fichiers de nouvelle génération Btrfs est entré dans le noyau officiel 2.6.29 afin de faciliter son développement et d'accélérer sa maturation.
Attention cela ne signifie pas que Btrfs est considéré comme stable ! Cette inclusion n'est effectuée que pour permettre à de nombreux utilisateurs de tester plus facilement et de rapporter les bugs et le chemin est encore long avant d'être déclaré stable. À titre de comparaison le système de fichiers Ext4 (beaucoup moins novateur) est entré dans le noyau à la version 2.6.19 (novembre 2006) mais n'a été considéré comme vraiment stable et pouvant être utilisé par tous qu'à la version 2.6.28 (décembre 2008).
Le format d'enregistrement sur le disque de Btrfs n'est pas encore officiellement déclaré comme figé (mais il ne sera changé que dans le cas de la découverte d'un bug imposant vraiment de le modifier).
Pour information Btrfs est un système de fichiers extrêmement moderne qui reprend toutes les bonnes idées apparues au cours des dernières années et en ajoute quelques unes.
- On y retrouve la notion de "Copy on Write" : lors de la modification d'un fichier ce dernier est simplement copié à un autre endroit du système de fichiers et les nouvelles données seront enregistrées sur la copie au lieu de l'être sur l'original. On bascule ensuite entre les deux de façon atomique ;
- Le stockage est basé sur les extents : on réserve un espace de stockage contiguë lors de l'enregistrement d'un fichier afin de pouvoir le faire grandir sans problème (taille de fichier maximum de 2^64 octets) ;
- La protection des données est améliorée par l'usage de sommes de contrôle sur les données et les méta-données ;
- Le système est redimensionnable (y compris pour le rétrécir) et ce redimensionnement peut se faire à chaud ;
- La compression des données (avec l'algorithme zlib) est transparente et s'active très simplement avec mount -o compress ;
- Possibilité de prendre des "instantanés" (snapshots) du système à un instant donné, ces snapshots étant même accessibles en écriture ;
- Vérification du système de fichiers, avec le programme btrfsck, tolérante aux erreurs et ultra-rapide ;
- Allocation retardée des blocs pour augmenter les performances.
Du coté des améliorations planifiées sur Btrfs lors des prochains cycles de développement du noyau, on peut citer l'allocation des extents qui n'est pas encore optimisée pour utiliser au maximum les machines multiprocesseurs. Le verrou va être finement décomposé pour augmenter les performances. L'état d'avancement de Btrfs peut être suivi sur le wiki du projet.
Squashfs
Aux côtés de Btrfs un autre système de fichiers fait son entrée dans le noyau 2.6.29. Il s'agit de Squashfs qui occupe la niche des systèmes compressés et en lecture seule.
Utilisé principalement dans les systèmes embarqués ou dans les live-CD, Squashfs a longtemps été développé en dehors du processus normal du noyau Linux. Bien entendu un tel modèle de développement à base de patch externe est difficile à soutenir à long terme du fait de la rapidité d'évolution de Linux. C'est ce qui explique le désir d'intégration dans la branche principale du noyau qui aboutit aujourd'hui.
Dans le monde du libre Squashfs est devenu la solution standard de systèmes de fichiers compressés et en lecture seule puisqu'il est utilisé par les versions live-CD de Debian, Gentoo, Ubuntu et Fedora. A partir du noyau 2.6.29 il ne sera donc plus nécessaire pour ces distributions de patcher leur noyau pour rajouter Squashfs.
La documentation présente dans les sources du noyau explique bien les spécificités de Squashfs et propose un comparatif avec Cramfs.
Squashfs permet de compresser les fichiers, les répertoires et les inodes et il autorise le choix d'une taille de bloc de 1 Mo afin d'améliorer le taux de compression.
Pour l'instant c'est l'algorithme gzip qui est utilisé mais il est probable qu'à l'avenir le projet va se tourner vers lzma qui est plus avancé techniquement. Des patchs existent déjà à cette adresse et le comparatif fait apparaître que, pour une taille non compressée de 668 Mo, on passe de 222 Mo à 167 Mo entre gzip et lzma.
KMS
Après l'entrée du gestionnaire de mémoire pour cartes graphiques GEM dans le noyau précédent c'est maintenant KMS (kernel-based mode-setting) qui arrive dans le nouveau noyau 2.6.29. Le mode-setting c'est tout simplement la configuration de la carte graphique pour qu'elle puisse afficher correctement les données graphiques sur l'écran. KMS permet d'effectuer ce travail dans le noyau ce qui apporte de nombreux avantages.
On peut citer tout d'abord le fait que le mode setting, puisqu'il est unifié dans le noyau, se retrouve donc partagé entre tous les pilotes. C'est la fin d'une multitude de lignes de codes redondantes au profit d'une seule implémentation plus robuste.
KMS permet également de pouvoir enfin faire tourner le serveur X sans les droits root ce qui est un énorme avantage sur le plan de la sécurité du système.
Enfin avec KMS le changement rapide d'utilisateur (fast user switching) est facilité puisqu'il n'y a plus besoin de changer de terminal virtuel, les phases de mise en veille/réveil sont plus simples donc plus fiables, le boot de la machine est plus agréable (plus de bascules des modes d'affichage) et les messages de panique du noyau peuvent éventuellement être graphiques.
Actuellement il n'y a que le pilote Intel qui fonctionne bien avec KMS mais on peut parier que les autres pilotes vont s'aligner rapidement du fait des nombreux bénéfices qui découlent de l'utilisation de KMS.
Ajout de "crochets" (hooks) dans LSM
Dans le domaine de la sécurité une nouveauté importante est l'ajout de "crochets" (hooks) dans LSM afin de permettre l'arrivée des modules de sécurité basés sur le chemin (pathname-based).
Dans le noyau Linux il existe une infrastructure unique sur laquelle viennent se greffer les modules de sécurité concurrents. Cette infrastructure se nomme LSM (Linux Security Modules) et elle est utilisée par les modules de sécurité SELinux et SMACK.
Pourtant cette infrastructure ne fait pas l'unanimité car elle est peu adaptée aux modules de sécurité très différents de SELinux et SMACK. Ces derniers utilisent l'approche basée sur des labels qui sont attachés à chacun des objets du système mais ce n'est pas la seule approche possible de la sécurité.
Une alternative consiste à se baser non pas sur des labels, mais sur le chemin d'accès aux objets (par exemple /usr/sbin/httpd) et de lister les restrictions de sécurité en fonction de ce chemin d'accès.
L'implémentation de cette approche basée sur le chemin (pathname-based) était rendue très difficile par LSM. Celui-ci n'avait pas de crochets (hooks) adaptés permettant à l'infrastructure de présenter des points d'entrée aux modules basés sur le chemin et de nombreux développeurs ont donc critiqué ces modules comme étant peu sûrs.
Le noyau 2.6.29 apporte donc enfin ces crochets spécifiques dans LSM ce qui va permettre l'inclusion dans la branche principale de modules de sécurité comme TOMOYO ou AppArmor.
Si AppArmor n'est peut-être plus vraiment d'actualité depuis le licenciement par Novell des développeurs du projet, en revanche TOMOYO à toutes ses chances de rentrer rapidement dans le noyau Linux, et ce dès la version 2.6.30.
Ce module basé sur le chemin apportera donc des avantages distincts de ceux des modules classiques basés sur les labels et les utilisateurs de Linux pourront donc comparer les approches et choisir le module qui leur conviendra le mieux.
RCU hiérarchique
Le mécanisme de RCU (Read-Copy update) devient hiérarchique dans le nouveau noyau 2.6.29.
La technique du Read-Copy update est un mécanisme de synchronisation ingénieux qui permet à de multiples threads de lire simultanément une donnée sans poser dessus un verrou coûteux. Le RCU autorise donc un processeur à lire une ressource partagée comme s'il était le seul à y accéder. Quand une opération d'écriture, et non plus de lecture, est demandée par un thread alors la ressource est copiée ailleurs avant d'être modifiée. L'original continue d'exister jusqu'à ce que les threads de lecture aient fini leur travail.
Ce mécanisme de RCU "classique" est donc très efficace mais le temps a montré qu'il souffre quand même d'un défaut important. La partie qui est chargée de déterminer la fin des diverses opérations de lecture sur la ressource ne fonctionne pas bien dans le cas de machines possédant des centaines de processeurs. L'algorithme a été conçu au moment où les ordinateurs n'avaient qu'un maximum de 32 cœurs et la montée en charge est perturbée par cette limitation. Il est possible de contourner partiellement cette barrière pour monter jusqu'à quelques centaines de cœurs mais la solution n'est pas vraiment naturelle ni propre.
Pour ajouter encore à ce défaut de montée en charge on peut relever que l'implémentation RCU "classique" nécessite un réveil fréquent des processeurs au détriment de l'économie d'énergie.
Afin de corriger ces défauts Paul McKenney a proposé une toute nouvelle implémentation du mécanisme RCU qui devient "hiérarchique".
L'idée est ici de créer des structures hiérarchiques (rcu_node) qui contiendront chacune leur propre verrou ce qui permettra de diviser les cœurs entre ces structures et d'éviter les problèmes de montée en charge.
Pour résoudre le problème de l'économie d'énergie des compteurs sont créés (rcu_dynticks) afin de savoir si le cœur est en sommeil ou pas. Le RCU "hiérarchique" évitera ainsi soigneusement de réveiller les processeurs qui sont endormis et ne consultera que ceux effectuant un vrai travail.
Ce nouveau mécanisme RCU a été testé intensivement avec l'outil rcutorture et il a été confirmé qu'il est très efficace sur des machines possédant des milliers de processeurs sans impacter la vitesse des machines plus traditionnelles. Il est possible de paramétrer la hiérarchie souhaitée avec l'option CONFIG_RCU_FANOUT et la limite est bien repoussée puisqu'on peut aller jusqu'à 16384 cœurs sur les machines 32 bits et jusqu'à 262144 cœurs pour les architectures 64 bits.
Selon les propres mots de Paul McKenney : "Je sais que je vais regretter d'avoir dit ça mais cela me semble plus que suffisant pour le futur prévisible".
"Geler" un système de fichiers
Il est maintenant possible de "geler" un système de fichiers afin de faire une sauvegarde.
Ce gel consiste essentiellement à interrompre toutes les opérations d'écriture en cours afin de garder un état stable du système de fichiers et de pouvoir lancer une sauvegarde. Cette fonction était déjà présente dans le système de fichiers XFS mais les développeurs du noyau, et en particulier Takashi Sato, se sont lancés dans la généralisation de cette possibilité à tous les systèmes de fichiers. Pour cela une nouvelle commande ioctl a été créée qui permet l'entrée dans le freeze du système avec la commande FIFREEZE ainsi que la sortie de l'état suspendu avec la commande FITHAW.
À propos de cette sortie de l'état "gelé" une précaution spéciale a dû être prévue au cas où le logiciel de sauvegarde ne fonctionnerait pas correctement. Un décompte de temps est lancé dès que le système est gelé et si à l'expiration du compteur le système est toujours gelé, la commande de réveil FITHAW est activée. Cela permet de ne pas se retrouver avec un système de fichiers en lecture seule par la faute d'un bug idiot dans son système de sauvegarde.
Bien entendu si la sauvegarde est très longue ce décompte de temps peut lui-même poser des problèmes… mais les développeurs du noyau sont des gens astucieux et il est possible à l'application de sauvegarde de réinitialiser périodiquement le compteur avec la commande FIFREEZE_RESET_TIMEOUT tant que son travail n'est pas terminé.
En définitive avec ce patch tous les systèmes de fichiers présents dans la branche principale (ext3, ext4, xfs, gfs2, jfs, reiserfs, etc.) peuvent maintenant profiter facilement de cette possibilité de "geler" le système pour faire une sauvegarde.
WIMAX
Une pile réseau supportant la technologie WIMAX est désormais incluse dans le noyau Linux 2.6.29.
Le WIMAX (Worldwide Interoperability for Microwave Access) est une norme de transfert sans fil à haut-débit. Connue également sous le nom de "Broadband Wireless Access" ou sous le numéro de norme 802.16, comme peut l'être le Wi-Fi avec la norme 802.11, le WIMAX promet de révolutionner les accès sans fil. Les débits peuvent atteindre plusieurs dizaines de Mbits sur des distances qui se comptent en kilomètres.
La firme Intel développe des périphériques WIMAX et a donc un grand intérêt à ce que cette technologie se répande et soit bien prise en charge par Linux. Intel a donc écrit la pile réseau générique WIMAX et un site web spécifique a été mis en place pour augmenter la visibilité du projet.
Pour l'instant un seul pilote de périphérique est entré dans la branche principale du noyau et ce pilote est destiné au support des cartes Intel de type Echo Peak. Malheureusement, comme souvent, ce pilote libre sous GPL est accompagné d'un micrologiciel redistribuable mais non libre (sous licence IFBDL) et d'un blob binaire d'authentification (supplicant) soit disant pour des raisons de respect de la loi dans les procédures d'authentification au sein du réseau WIMAX. Le blob binaire posera sans doute des problèmes aux distributions ayant une politique stricte au point de vue de la liberté du code aussi Intel a promis de libérer ce code dans le futur ("Du fait d'un ensemble de problèmes que nous sommes en train de résoudre nous ne pouvons pas ouvrir le code pour l'instant, mais ce sera fait").
En bref…
- La gestion des informations de sécurité sur les processus (credentials records) a été profondément réorganisée. Ces informations, par exemple l'ID du user, l'ID du groupe, le contexte de sécurité, les capacités, ont maintenant une structure dédiée (struct cred) séparée de la structure du processus en question. Ce patch des credentials records permet d'avoir une gestion plus logique des informations de sécurité et constitue un pré-requis pour le patch de mémoire cache des systèmes de fichiers réseaux qui arrivera dans les versions suivantes du noyau.
- La couche SCSI du noyau est maintenant compatible avec les périphériques de type Fibre Channel sur Ethernet (FCoE) grâce à la nouvelle bibliothèque libfc.
- La pile Wi-Fi mac80211 du noyau est désormais capable de prendre en charge le mode Wireless Access Point. Le code de ce mode WAP était présent dans les noyaux antérieurs mais il n'était pas activé. Maintenant que son niveau de maturation est jugé suffisant il peut être utilisé sans problème. À noter que la partie authentification est toujours déléguée au démon en espace utilisateur hostapd.
- Le système de fichiers Ext4 (détaillé dans un article du site developerWorks d'IBM) possède désormais, grâce aux développeurs de Google, une option permettant de ne pas utiliser de journal. Bien entendu on perd les bénéfices de la journalisation mais dans certain cas cela peut être utile et on y gagne sur les performances.
- Il est maintenant possible de faire des sommes de contrôle sur les métadonnées du système de fichiers ocfs2. Ce système de fichiers réparti est spécialisé dans les grappes de serveurs (clusters) et on comprends que l'intégrité des données est d'une importance cruciale pour ces imposantes machines. Au delà des sommes de contrôle ocfs2 gagne également le support des ACL, des attributs de sécurité et la possibilité de fixer des quotas.
- La solution de chiffrement de fichiers eCryptfs, incluse depuis le noyau 2.6.19, peut désormais chiffrer les noms des fichiers et non plus uniquement leur contenu.
- Après la technique de TSO (TCP segmentation offload) qui permet aux cartes réseaux de décharger le processeur de certaines tâches concernant la génération de paquets c'est au tour de LRO (Large receive offload) de faire son entrée dans le noyau. Cette fois-ci ce sont les machines recevant du trafic réseau qui se verront un peu déchargées. L'idée consiste en gros a agréger les paquets reçus dans un tampon afin de moins solliciter la pile réseau de la machine.
L'implémentation retenue pour le noyau 2.6.29 est très générique afin que les divers pilotes réseau possédant cette fonction puissent utiliser le code générique au bénéfice de la mutualisation du code.
- Les divers pilotes de la plate-forme Androïd de Google font leur entrée dans la branche -staging du noyau (rappelons que cette branche -staging est destinée à accueillir des pilotes non finalisés pour accroître leur visibilité et susciter l'intérêt des testeurs et des relecteurs de code… prudence donc).
- Le système de fichiers spécialisé dans la mémoire Flash UBIFS possède désormais des options de compression lors du montage. Il suffit de passer la commande -o compr= et de spécifier l'une des trois options entre "none", "lzo" et "zlib".
- Le code gérant les périphériques USB On-The-Go (c'est à dire les périphériques USB pouvant négocier pour échanger les rôles de maîtres/esclaves) a été largement factorisé. Cette amélioration permettra aux différents pilotes de ces périphériques d'avoir une plus grande quantité de code en commun ce qui est tout bénéfice pour la facilité d'écriture et la robustesse.
- Le système de fichiers virtuels sysfs (destiné à exporter vers l'espace utilisateur des informations concernant les périphériques du système) peut maintenant être utilisé pour savoir si le disque est de type rotatif ou pas. Ainsi les diverses applications en espace utilisateur pourront interroger ce paramètre et optimiser les accès selon qu'on est en présence d'un disque dur ou d'un disque SSD.
- Le noyau 2.6.29 introduit le début du support pour la console Pandora (basée sur un coeur ARM et DSP). Plus généralement le dernier noyau propose beaucoup d'améliorations sur l'architecture ARM (support du Cortex-A9, du SoC S3c24a0 et de bien d'autres encore).
- La mémoire flash de type LPDDR (Low power double data rate) est prise en charge par le noyau 2.6.29. Ce nouveau type de mémoire (aussi nommé Mobile-DDR) est destiné aux appareils sur batterie (téléphones et autres) qui peuvent ainsi profiter d'un débit atteignant 667 Mo/s sur un bus 16 bits.
- Comme cela avait été fait en son temps pour les architectures x86 et x86-64 une unification a eu lieu au sein des répertoires sources du noyau. Cette fois ce sont les architectures SPARC et SPARC64 qui sont unifiées avec les mêmes bénéfices qu'auparavant : une plus grande mutualisation du code qui implique des tests plus efficaces ainsi que moins de travail de maintenance et moins de bugs.
- Du côté de l'interface ieee1394 (plus connue sous le nom commercial de Firewire utilisé par Apple) les périphériques ayant un taux maximum de transfert de 1600 Mbits/s et 3200 Mbits/s sont maintenant pris en charge alors que la limite précédente se situait à 800 Mbits/s.
Pour le 2.6.29 on voit que le nombre de patchs est, au 19 mars, de 11 627 (9 045 pour le 2.6.28). En nombre de lignes modifiées cela représente 1 642 117 lignes et, une fois n'est pas coutume, c'est Novell qui est en tête des statistiques en tant que contributeur. Le résultat est toutefois biaisé car Greg Kroah-Hartman, développeur Novell, est responsable de la branche -staging qui accueille de nombreux pilotes. À lui seul il est crédité de 331
155 lignes modifiées mais c'est évidemment un artefact lié a son rôle de mainteneur de cette branche.
Le nouvel indicateur "Tested-By" qui indique qu'un patch a été testé par un développeur continue doucement sa progression puisqu'il passe de 173 occurrences dans le 2.6.28 à 275 pour le dernier noyau (il y en avait à peine 9 lors du cycle du 2.6.22).
C'est la même chose pour l'indicateur "Reported-By" qui vise à reconnaître, en citant leur nom, la contribution de ceux qui rapportent des dysfonctionnements. Là aussi on progresse petit à petit à mesure que ce nouvel indicateur est utilisé et on passe de 204 occurrences dans le 2.6.28 à 364 pour la dernière version du noyau (seulement 11 pour le 2.6.22).
Vous savez donc ce qu'il vous reste à faire si voulez voir votre nom apparaître dans le changelog d'un prochain noyau Linux !
Pour la suite…
En ce qui concerne les futures nouveautés des prochaines versions du noyau on peut se tourner vers la page spécifique de la Fondation Linux maintenue par Jonathan Corbet ainsi que vers le message récapitulatif de Stephen Rothwell (responsable de la branche linux-next).
- Le système de fichiers en réseau NFS dans sa version 4.1 propose une possibilité d'accès ultra-rapide aux données. C'est le mécanisme Parallel NFS (pNFS) qui permet cela en envoyant les données à partir de plusieurs disques en parallèle (technique de striping). Le noyau 2.6.30 est prévu pour accueillir les premiers patchs de l'infrastructure pNFS (initialisation des sessions, échange d'identifiants, etc.) et c'est le noyau 2.6.31 qui intégrera le gros du travail (commandes d'entrées/sorties, lecture et écriture des données, etc.).
- Dans le cadre du travail d'Arjan van de Ven destiné à améliorer la vitesse d'amorçage une infrastructure d'appels asynchrones a été développée. Avec cette infrastructure il est possible d'interroger les périphériques (device probing) de façon asynchrone lors de l'amorçage pour éviter de bloquer sur l'un d'eux. Cela permet de gagner du temps entre le démarrage du noyau proprement dit et le lancement du premier processus (init) même si ce temps dépend largement du type de machine.
Les patchs pour les périphériques SATA et pour les périphériques SCSI sont présents dans le noyau 2.6.29 mais la fonction a été désactivée à la demande d'Arjan qui ne trouvait pas le code assez mûr. L'activation de cette fonction de découverte asynchrone des périphériques lors de l'amorçage est prévue pour le noyau 2.6.30 et c'est cette version qui permettra de bénéficier d'une vitesse de démarrage améliorée.
- Un nouveau candidat au titre très disputé de meilleur allocateur mémoire a fait son apparition sous le nom de SLQB. Après SLAB (l'allocateur standard), SLOB (spécialisé dans l'embarqué) et SLUB (introduit dans le noyau 2.6.22 pour remplacer SLAB), le dernier venu (SLQB donc pour ceux qui suivent) a l'ambition de détrôner ses petits frères. Nick Piggin, le créateur de ce nouvel allocateur mémoire, a demandé l'inclusion de SLQB dans la branche de test -mm gérée par Andrew Morton mais celui-ci craint que peu de gens ne prennent la peine de faire des tests. Il est donc possible que SLQB fasse ainsi son entrée dans la branche principale afin d'augmenter sa visibilité et drainer des testeurs en ayant pour perspective de bouter ses concurrents hors du noyau.
Quand à savoir s'il est vraiment opportun à court terme d'ajouter encore un allocateur aux trois déjà présents, Andrew Morton a sa petite idée : "Moi je suis 100% derrière l'idée de réduire le nombre des implémentations d'allocateur mémoires. De toute façon notre convention de nommage nous limite à 26. Encore heureux que le noyau ne soit pas écrit en cyrillique !".
Aller plus loin
- Les nouveautés du noyau 2.6.29 (70 clics)
- Le bilan des ajouts partie 1 (6 clics)
- Le bilan des ajouts partie 2 (4 clics)
- Les prévisions pour l'avenir de Linux (12 clics)
# À noter que...
Posté par lejocelyn (site web personnel) . Évalué à 5.
[^] # Re: À noter que...
Posté par Ellendhel (site web personnel) . Évalué à 3.
Ou ai-je loupé quelque chose ?
[1] : http://www.utas.edu.au/foundation/devil.htm lien "donate by mail"
[^] # Re: À noter que...
Posté par kilian . Évalué à 4.
[^] # Re: À noter que...
Posté par Nonolapéro . Évalué à 0.
[^] # Re: À noter que...
Posté par thargos . Évalué à 1.
SarKophage (première de la playlist)
http://www.myspace.com/feuh
En tout cas, superbe news, bravo pour la traduction et les pointes d'humour (Linus barbier!).
Ça me donne presqu'envie de rebooter pour tester ce kernel!
# Merci pour la dépêche !
Posté par Omnisilver . Évalué à 7.
[^] # Re: Merci pour la dépêche !
Posté par Christophe Duparquet (site web personnel) . Évalué à -2.
Alors je sais que je peux lire tout ce qui suit sans risque d'être déçu.
Merci patrick_g !
« J'ai pas Word, j'ai pas Windows, et j'ai pas la télé ! »
[^] # Re: Merci pour la dépêche !
Posté par grid . Évalué à 5.
On a pas à Apple Expo, humidifiant son linge intime, et en espérant que dieu s'adresse à ses disciples.
patrick_g< fait du bon boulot, il le sait. Il n'attends surement pas les léchouilles des pisseuses qui viennent rafler des [:pertinent] sur son travail.
Mais je te rassure, ce qu'il fait. Tout le monde peut le faire, il suffit d'en avoir envie et d'un peu de volonté et de passion.
Paix sur la terre, et mort aux cons.
[^] # Re: Merci pour la dépêche !
Posté par biband . Évalué à 4.
[^] # Re: Merci pour la dépêche !
Posté par Victor STINNER (site web personnel) . Évalué à 10.
[^] # Re: Merci pour la dépêche !
Posté par Spack . Évalué à 1.
[^] # Re: Merci pour la dépêche !
Posté par Dr BG . Évalué à 5.
Oui, mais pas vraiment pour faire plaisir à l'auteur, mais plutôt pour indiquer au lecteur ne souhaitant pas tout lire ce qui est potentiellement intéressant de ce qui ne l'est pas. Évidemment, en théorie.
[^] # Re: Merci pour la dépêche !
Posté par Sylvain Sauvage . Évalué à 2.
(D’ailleurs, pour moi, le côté karma des notes, c’est accessoire ; la note du commentaire, c’est surtout « juste pour information ».)
[^] # Re: Merci pour la dépêche !
Posté par Christophe Duparquet (site web personnel) . Évalué à 3.
Très vaste programme, n'est-ce pas ?
« J'ai pas Word, j'ai pas Windows, et j'ai pas la télé ! »
[^] # Re: Merci pour la dépêche !
Posté par tuXico . Évalué à 3.
[^] # Re: Merci pour la dépêche !
Posté par Laurent Saint-Michel . Évalué à 10.
Peut-être un peu suicidaire, non ?
[^] # Re: Merci pour la dépêche !
Posté par Bob . Évalué à 2.
[^] # Re: Merci pour la dépêche !
Posté par Dup (site web personnel) . Évalué à -2.
[^] # Re: Merci pour la dépêche !
Posté par creak (site web personnel) . Évalué à 0.
# Copy On Write
Posté par Barnabé . Évalué à 5.
# Petites questions
Posté par patrick_g (site web personnel) . Évalué à 10.
Je poste ce commentaire pour avoir un peu un retour de la part des lecteurs des dépêches sur le noyau.
Je m'interroge pour savoir si il y aurait des trucs à changer et je vous demande votre avis sur ces points :
1) Est-ce que la première partie qui récapitule les diverses release candidates en traduisant une partie des mails de Linus est utile ou pas ? Qu'est-ce qu'il faudrait changer selon vous (fond, forme) ?
2) La seconde partie qui détaille les "grosses" nouveautés doit-elle être ullifiée ou pas ? Est-elle trop longue, pas assez longue, trop technique, pas assez technique, etc ?
3) Il y a beaucoup de d'hyperliens dans ces dépêches sur le noyau (une centaine dans celle-ci). Est-ce que vous cliquez sur ces liens ou pas ? Si oui sur combien en moyenne ? Est-ce qu'il y en a trop ou non ?
4) Le paragraphe sur le bilan statistique du cycle de développement avec les principaux contributeurs est-il utile ou pas ? Est-ce que ça vous intéresse ?
5) Est-ce que vous avez des idées pour améliorer ces dépêches sur le noyau ?
PS-1 : Ne vous sentez pas obligé de répondre à toutes les questions. Je n'ai fait cette liste que pour donner à réfléchir mais vous pouvez parfaitement faire une réponse globale ou même faire une suggestion sans répondre aux questions.
PS-2 : Évidemment je ne promets rien en ce qui concerne l'implémentation de vos suggestions et je me réserve le droit de ne rien changer du tout ;-)
[^] # Re: Petites questions
Posté par Larry Cow . Évalué à 9.
Utile, pas forcément. Agréable, surement : j'aime bien la prose de Linus en général. Maintenant c'est vrai que, parfois, mon premier réflexe c'est "chouette, un nouveau noyal, voyons voir ce qui a changé", et que sous leur forme actuelle, tes dépêches font un peu durer le suspense.
2) La seconde partie qui détaille les "grosses" nouveautés doit-elle être ullifiée ou pas ? Est-elle trop longue, pas assez longue, trop technique, pas assez technique, etc ?
En l'état elle me va bien. J'essaye de suivre l'actualité, mais je n'y arrive pas toujours, et tes rappels tombent généralement à point (et comme ils sont bien écrits et fort lisibles, ça n'est pas très grave lorsqu'ils enfoncent des portes ouvertes).
3) Il y a beaucoup de d'hyperliens dans ces dépêches sur le noyau (une centaine dans celle-ci). Est-ce que vous cliquez sur ces liens ou pas ? Si oui sur combien en moyenne ? Est-ce qu'il y en a trop ou non ?
Je les suis très peu. À titre d'exemple, j'ai du en suivre deux sur la présente nouvelle. Mais ça ne dérange pas franchement la lecture (je n'aurais jamais deviné qu'il y en avait tant!), et ça offre un plus pour ceux qui veulent aller plus loin. Donc encore une fois, pas forcément de raison de changer.
4) Le paragraphe sur le bilan statistique du cycle de développement avec les principaux contributeurs est-il utile ou pas ? Est-ce que ça vous intéresse ?
Personnellement, pas trop, je l'ai lu un peu en diagonale. C'est pour beaucoup des noms qui ne me disent pas grand chose, et je crains que les gens à qui ça parle aient déjà eu accès à ces statistiques par d'autres biais.
Juste pour avoir une idée : ça te prend combien de temps, de rédiger ce genre de choses?
[^] # Re: Petites questions
Posté par patrick_g (site web personnel) . Évalué à 4.
Je sais pas vraiment car ça s'étale sur deux bons mois...mais ça prend du temps !
[^] # Re: Petites questions
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 3.
Sinon pour répondre à tes questions :
1) Comme le commentaire précédent je trouve que ça fait plus "sympa", on a un peu le contexte, la ou les petites histoires. Moi j'aime bien.
2) C'est long, c'est technique, mais c'est bien. Après tout, on ne lit pas forcément toutes les parties, uniquement celles qui nous intéressent.
3) J'ai dû en ouvrir à peu près 10. Comme ça dépend ce qui nous intéresse, je pense que les liens sont biens.
4) C'est intéressant pour comparer et se rendre compte de l'ampleur du développement du noyau...après tu peux ptre faire un poil plus court.
Voilà :)
[^] # Re: Petites questions
Posté par IsNotGood . Évalué à 6.
C'est totalement inutile, totalement indispensable.
Ce qui compte, à mon avis, est qu'on ne soit pas obligé de lire cette partie pour connaitre les évolutions en fonctionnalité du noyau. Donc je vais toujours lire cette partie :-)
> 2) La seconde partie qui détaille les "grosses" nouveautés doit-elle être ullifiée ou pas ?
Pour moi non.
> Est-elle trop longue, pas assez longue, trop technique, pas assez technique, etc ?
Il y a toujours des parties que je ne comprend pas et je trouve ça normal !
On ne peut pas tout connaitre.
Est-elle trop longue ? Chaque partie est assez courte.
Est-elle trop technique ? Si c'est technique, c'est technique. Si c'est compliqué, merci à toi de toujours fournir un lien où on trouvera plus d'information.
> Est-ce que vous cliquez sur ces liens ou pas ?
Oui.
> Si oui sur combien en moyenne ?
C'est variable. 4 à 10 liens en général. Ça dépend de mes centres d'intérêts.
> Est-ce qu'il y en a trop ou non ?
Il n'y en a pas trop même si je n'en lis que 10 %.
Le problème est : est-ce que ça te fait beaucoup de boulot ?
> 4) Le paragraphe sur le bilan statistique du cycle de développement avec les principaux contributeurs est-il utile ou pas ?
Pas utile et indispensable :-)
> Est-ce que ça vous intéresse ?
Oui. Il faut mettre à l'honneur ceux qui contribuent. C'est important.
> 5) Est-ce que vous avez des idées pour améliorer ces dépêches sur le noyau ?
Tes dépêches sont formidables.
Évidemment, on peut demander mieux (moins de fautes, liens sur wikipedia, etc). Mais tes dépêches sont formidables et ma préoccupation est :
- Que veux-tu pour continuer à faire ces dépêches ?
- Que fais-tu sans plaisir, voire ne veux plus faire ?
- etc.
[^] # Re: Petites questions
Posté par fweisbec . Évalué à 8.
Non. Elle est bien comme ça, pas besoin d'unifier ou de faire des parties et sous parties je pense. Quand au niveau technique je pense aussi que c'est suffisant, ceux qui voudront aller plus loin peuvent cliquer sur les liens des articles Lwn.
3) Il y a beaucoup de d'hyperliens dans ces dépêches sur le noyau (une centaine dans celle-ci). Est-ce que vous cliquez sur ces liens ou pas ? Si oui sur combien en moyenne ? Est-ce qu'il y en a trop ou non ?
Selon moi c'est très bien comme ça. D'autant qu'il y a beaucoup de référence à Lwn, ce qui me semble être la source la plus judicieuse.
5) Est-ce que vous avez des idées pour améliorer ces dépêches sur le noyau ?
Oui.
Tu évoques bien les évènements les plus importants du cycle (Btrfs, etc...) mais ça manque de petites épices croustillantes. J'entends par là des événements qui sont majoritairement évoqués sur LKML et un peu Lwn mais qui tendent à passer à la trappe lors des annonces de sorties de version.
Par exemple un changement qui, selon moi est majeur, c'est le travail qui a été effectué sur les mutex par Peter Zijlstra en début de cycle (un poil avant la sortie de -rc1). Les mutex ont maintenant un comportement heutistique: tantôt ils drement, tantôt ils se prennent pour des spinlocks en bouclant si l'actuel possesseur du verrou est bien en train de s'executer sur un autre processeur. Si le possesseur du verrou change ou s'il est en train de dormir, alors celui qui requiert le verrou va pioncer.
Ca a beaucoup amélioré les performances. dans certains cas. Cette idée vient de la branche -rt.
Il y a plein de petit événements comme ça, comme l'exhumation du patch -rt, les irqs threadées soumises pour la branche principale et qui ont de grandes chances d'être mergée pour 2.6.30, ce qui est un énorme pas en avant pour la branche -rt (en partie).
Bref, il manque quelques petits trucs comme ça.
Bon en même temps c'est difficile de tout prendre en compte, j'admets :-)
[^] # Re: Petites questions
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Quand on vois cela, plus la roadmap de Xen, on se dis que Xen n'est pas si mort que cela ;-)
[^] # Re: Petites questions
Posté par IsNotGood . Évalué à 0.
Pas si sûr, mais beaucoup moins impossible aujourd'hui qu'hier.
> on se dis que Xen n'est pas si mort que cela ;-)
Il est moins mort que je le croyais. Les développeurs ont aussi pris la question de mettre Xen en upstream au sérieux. Enfin.
[^] # Re: Petites questions
Posté par Zorro (site web personnel) . Évalué à 10.
Je clique pas sur les liens car je comprends pas les discussions, sauf quand il y a des photos rigolotes (par ex. Linus qui joue au barbier).
Sinon, ce qui manque _peut-être_, uniquement s’il te reste un peu de temps, c’est un aperçu des critiques ou des discussions, voire des engueulades autour des choix du noyau. À te lire, on dirait que tous les choix faits sont systématiquement les meilleurs, et que tout va toujours bien, et que personne ne critique les directions prises ou les choix faits. Bon, peut-être que c’est la vérité, après tout, hein !
Merci et bravo en tout cas pour le temps que tu y passes.
[^] # Re: Petites questions
Posté par Thomas Douillard . Évalué à 3.
C'est écris petit, ça fait "pavé" avec la feuille de style par défaut, ça fait ramer firefox quand je scrolle ...
Rien de grave et j'ai pas de solution clé en main à proposer, c'est juste un constat et ce genre de dépêche est pas forcément suffisamment fréquente pour justifier un gros travail, mais c'est peut être a noter pour la prochaine version de Linuxfr ;)
[^] # Re: Petites questions
Posté par Axone . Évalué à 2.
2) très utile, bien comme cela
3) je ne clique jamais sur les liens, car ca pointe sur des discussions en anglais et trop techniques. C'est d'ailleurs pourquoi j'aime ce genre de news : un résumé en français.
4) informatif pour l'anecdote.
[^] # Re: Petites questions
Posté par dest . Évalué à 2.
Je lis toute la dépêche dans l'ordre et j'aimerais bien conserver ce côté suspense des nouveautés qui sont à suivre. Comme dit précédemment, pas spécialement utile mais apprécié.
2) La seconde partie qui détaille les "grosses" nouveautés doit-elle être ullifiée ou pas ? Est-elle trop longue, pas assez longue, trop technique, pas assez technique, etc ?
Personnellement, j'aime bien quand il y a de la technique alors s'il y en avait plus, je ne cracherai pas dessus. Sinon je pense que tu as trouvé un juste milieu entre trop technique et pas assez.
3) Il y a beaucoup de d'hyperliens dans ces dépêches sur le noyau (une centaine dans celle-ci). Est-ce que vous cliquez sur ces liens ou pas ? Si oui sur combien en moyenne ? Est-ce qu'il y en a trop ou non ?
Oui, je clique sur les liens. Environ 5 clics mais ca dépend des centres d'intérêts. Genre j'ai cliqué pour voir Linus en barbier :D
4) Le paragraphe sur le bilan statistique du cycle de développement avec les principaux contributeurs est-il utile ou pas ? Est-ce que ça vous intéresse ?
Oui, j'aime beaucoup ce paragraphe. J'y apporte vraiment d'importance. Ca m'apporte une vision différente du projet Kernel.Et j'aime voir le nombre de contributeurs/testeurs augmenter :D
5) Est-ce que vous avez des idées pour améliorer ces dépêches sur le noyau ?
Je pense que tu as fait le tour des choses à dire.
[^] # Re: Petites questions
Posté par Dup (site web personnel) . Évalué à 5.
2) La seconde partie est elle aussi importante, elle présente les nouveautés majeures ainsi qu'une présentation technique tout en restant abordable, les liens donnés permettent d'approfondir pour qui veut plus d'informations
3) Certes je ne clique pas sur tous les liens mais ils me sont utiles pour avoir un complément d'information selon l'intérêt que je porte à telle ou telle fonctionnalité présentée. Je dirais entre 5 et 10 liens en fait c'est selon le sujet auquel se rapporte le lien et aussi ma capacité à éventuellement comprendre le contenu du lien
4) Concernant les stats, il s'agit sans doute de la partie la moins utile mais n'est pas inintéressante pour autant, je suis toujours stupéfait du nombre de lignes modifiées entre 2 releases du kernel, s'il fallait amoindrir une partie des dépêches sur le kernel je choisirais celle-ci
5) Ce qui est sûr, les dépêches en l'état me satisfont pleinement. Etant donné que tu as l'air de "connaître" les développeurs, pourquoi pas de temps en temps ajouter une présentation à leur sujet (ou ils bossent, ce à quoi ils ont participé au niveau du kernel, ce genre de détail)
[^] # Re: Petites questions
Posté par Thomas Preud'homme . Évalué à 1.
Pour le reste vraiment rien à redire. Les stats et les mails de Linus ne sont pas vraiment indispensables mais agréables à lire. Cela permet de voir un peu l'ambiance et la dynamique du développement du noyau. La partie 2 est vraiment un must, mais c'est peut-être un avis purement personnel. De toute façon comme le disent les autres le problème n'est pas d'en avoir trop, rien n'oblige à tout lire, mais plus le temps que cela te prends. Avec une table des matières en avoir trop devient juste absurde puisqu'on peut aller directement à la partie qui nous intéresse.
[^] # Re: Petites questions
Posté par Pierre Jarillon (site web personnel) . Évalué à 8.
Structuré de la sorte, on peut lire tout ou partie de l'article en fonction de ses centres d'intérêt et du temps dont on dispose car les liens sont aussi intéressants (j'en ai ouvert quelques uns).
Bon, je l'avoue, j'ai pu profiter de cet article qui est resté disponible pendant deux mois pour les relecteurs de Linuxfr mais j'ai eu un grande satisfaction à le relire en entier ce matin.
Je pense même que tes articles devraient être conservés par les historiens du 21ème siècle.
[^] # Re: Petites questions
Posté par fweisbec . Évalué à 1.
[^] # Re: Petites questions
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
"La première sécurité est la liberté"
[^] # Re: Petites questions
Posté par bubar🦥 (Mastodon) . Évalué à 2.
Je demanderai bien d' ajouter des informations concernant les évolutions moins importantes, moins visibles (par exemple reprendre les infos sur Cgroup pour en faire un suivi de l' évolution ? ou encore comment le lock est aujourdhui géré, après la double branche entre le giant et celle de molnar qui le virait d' entrée ? etc etc). Mais bon, "just do it" me dirait on à juste titre.
Merci
(désolé "grid", on est pas à apple expo, yes bien d' accord, mais je vais être du côté des pisseuses en disant "merci" à patrick_g, ouaih. désolé "grid" je vois pas trop quoi faire de mieux. la fermer et se voiler d' un bel "ignore" ? ben je préfère les pisseuses et leur merci. Désolé. ) ;)
ps : non seulement pisseuse mais en plus fan-boy, tu va détester, "grid" (si tu t' arretes sur ça)
si en parlant de squashFS ça aurait été pas mal de citer Mandriva, non ? Avec par exemple ça comme source : http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-(...) pour les dernières, et l' historique de l' inclusion de SquashFS (mandriva a été la première il me semble). Là ça fait carrément anglo-saxons comme phrase "en dehors de redhat et ubuntu, y a rien... ha si tu as mis Débian quant même). Merci.
[^] # Re: Petites questions
Posté par bubar🦥 (Mastodon) . Évalué à 1.
Et ça, ça me fait penser à truc (que d' autres, comme moi, peuvent faire) : faire un historique des dépêches noyaux publiées sur DLFP et en produire un petit "index daté".
[^] # Re: Petites questions
Posté par wismerhill . Évalué à 2.
1) Ce n'est pas très utile, mais j'aime bien avoir cet historique de la vie d'un nouveau noyau, et les commentaires de Linus sont amusants à lire.
2) Très utile, ça c'est vraiment l'information que je cherche quand un nouveau noyau sort. Pour moi ça pourrait être encore un peu plus technique et détaillé, mais la dépèche est déjà très longue comme ça.
La liste des "en bref" est bien aussi.
3) Je pense que j'ai cliqué sur une quinzaine de liens de la dépèche, c'est intéressant quand on veut plus d'information.
4) Ce passage-là m'intéresse nettement moins.
[^] # Re: Petites questions
Posté par Bob . Évalué à 2.
Je me sens un peu obligé (malgré le PS-1) de te répondre vu la qualité de tes dépêches : tu dois y passer un temps monstre ! Ce message est en quelque sorte un remerciement déguisé.
Je préviens tout de suite que je n'ai pas lu les autres réponses pour ne pas polluer mes remarques. Excuse-moi pour les répétitions.
1) J'aime bien cette partie : ça permet de rappeler le contexte. Et puis, quel blagueur ce Linus !
2) C'est la partie qui me donne à chaque fois envie d'installer immédiatement la nouvelle version du noyau. J'apprécierais plus de grosses nouveautés et plus de détails techniques même si je me rends bien compte du boulot nécessaire...
3) Je dois avouer que je n'ai pas le temps de tout lire (ce qui est assez frustrant d'ailleurs). Je dois suivre à peine 10% des liens, que je ne lis qu'en diagonale.
4) Je trouve ce petit bilan fort intéressant. Je m'étonne à chaque fois du nombre croissant de contributeurs et de patchs. Je pense qu'on ne peut plus se poser la question de la maturité du noyau et du libre en général.
5) Je vois mal ce qui est améliorable dans tes dépêches. Je pense d'ailleurs que si tu veux prendre toujours autant de plaisir à les rédiger, il ne faut pas que tu te donnes trop de contraintes. Même si j'avoue que s'adapter à son lectorat est une très bonne chose.
Pour conclure ce message : quand je vois la qualité journalistique que peut atteindre un passionné, je me pose de plus en plus de questions sur la presse en général. De nombreux « journalistes » devraient se remettre rapidement en question.
# Re:
Posté par IsNotGood . Évalué à 1.
???
Si j'ai bien compris, lorsqu'il y a copie de fichier, en fait il n'y a pas copie physique du fichier (seulement deux façons d'accéder aux mêmes données). Lorsqu'il y a modification d'un fichier, sont enregistrés que les modifications (ce qui va être modifié est copié ; d'où le "Copy on Write").
Il y a aussi un ext3 CoW (qui permet entre autre de versionner un système de fichier), mais il ne marche pas comme tu le dis.
> Vérification du système de fichiers, avec le programme btrfsck, tolérante aux erreurs
C'est le minimum...
> On peut citer tout d'abord le fait que le mode setting, puisqu'il est unifié dans le noyau, se retrouve donc partagé entre tous les pilotes.
C'est un peu du pipo à mon avis. Avant tout était fait dans Xorg, donc c'était tout autant contralisé.
KMS est simplement plus propre d'un point de vu architecture (sécurité par exemple). C'est au noyau de configurer le matos.
> C'est la fin d'une multitude de lignes de codes redondantes au profit d'une seule implémentation plus robuste.
On évite la duplication du code côté client. Avant chaque client de carte graphique (Xorg, Xfree, etc) avait le driver. Maintenant ce n'est plus le cas (en parti).
> Enfin avec KMS le changement rapide d'utilisateur (fast user switching) est facilité puisqu'il n'y a plus besoin de changer de terminal virtuel
Sûr ?
A ma connaissance il y a toujours changement de terminal virtuel. Mais avec KMS ça se fait super rapidement (ce qui donne peut-être l'illusion qu'il n'y a pas de changement de terminal virtuel).
> Actuellement il n'y a que le pilote Intel qui fonctionne bien avec KMS
C'était vrai au tout début de KMS. Puis rien ne marchait avec KMS (Intel a fait de grosses modifications dans ses drivers). Puis il n'y avait que ATI qui marchait avec KMS (c'est le cas pour F10). Ajourd'hui ATI et NVidia (avec le driver Nouveau) marchent avec KMS. Intel marche à nouveau mais il reste beaucoup de bugs qui devraient être rapidement corrigés.
> Une alternative consiste à se baser non pas sur des labels, mais sur le chemin d'accès aux objets (par exemple /usr/sbin/httpd)
Juste pour information, car il semble que beaucoup l'ignorent, SeLinux affecte les labels de sécurité à la création des fichiers et ceci tient compte du chemin d'accès. Par contre la décision d'autoriser un accès ne tient pas compte du chemin d'accès (ce qui n'est pas un problème puisque le label de sécurité est définit en fonction du chemin).
> Si AppArmor n'est peut-être plus vraiment d'actualité
Diantre, il y a pourtant cette distribution hyper populaire qui l'avait adopté : Canonical.
Comme quoi, l'influence de Canonical...
Ben ça sera TOMOYO (ou autre) après AppArmor, mais pas SeLinux. Combien d'années vont se passer avant qu'il n'y ait pas que Red Hat qui propose un SeLinux (ou équivalent) satisfaisant...
C'est de la science fiction, et ça profite principalement, voire uniquement, qu'à Red Hat...
> les utilisateurs de Linux pourront donc comparer les approches et choisir le module qui leur conviendra le mieux.
C'est "tragique" de lire ça. Pourquoi ne pas donner le choix "compte utilisateur root + anti-virus (à la Windows)" comme choix à l'utilisateur...
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
Avec les noyaux Fedora. Peut-être qu'il n'y a que le driver Intel qui est upstream.
[^] # Re: Re:
Posté par niclone (site web personnel) . Évalué à 3.
> C'est un peu du pipo à mon avis. Avant tout était fait dans Xorg, donc c'était tout autant contralisé.
On peut changer de mode via la couche vga (avec par exemple vga=... en arguments du kernel, bien que cette méthode ne disparaîtra à priori pas)
On peut changer de mode via la couche framebuffer (toujours via le kernel)
On peut changer de mode via Xorg (ou autre serveurs graphique moins répandu)
Je crois pas que ce soit tant pipo
[^] # Re: Re:
Posté par patrick_g (site web personnel) . Évalué à 3.
C'est "tragique" de lire ça. Pourquoi ne pas donner le choix "compte utilisateur root + anti-virus (à la Windows)" comme choix à l'utilisateur...
Je n'ai pas compris ta remarque. C'est le fait d'avoir le choix qui te dérange ?
Est-ce que tu a cliqué sur les hyperliens que j'ai mis derrière les expressions "avantages distincts" et "comparer les approches" et qui expliquent l'utilité des divers modules en les comparant ?
[^] # Re: Re:
Posté par IsNotGood . Évalué à 4.
Petit coup de gueule : j'en ai marre qu'on sacralise le choix ce qui clos tout débat.
Quel choix ? Pourquoi ? Sur quelle expertise ?
On parle de sécurité, on ne parle pas d'un fond d'écran !
Tu parles de choix pour les "utilisateurs de Linux".
Qu'une équipe de développeurs (qui sait ce qu'elle fait) préfère TOMOYO à X car il a un besoin très précifique pour de l'embarqué et très peu de mémoire à disposition, ça c'est un vrai choix. Ce qui compte ici, ce n'est pas le choix, mais que Linux couvre une plus grande palette de besoins. Peut-être que dans mon exemple hypothétique, on est dans le TOMOYO ou rien (les autres bouffant trop de mémoire par exemple).
Laisser à l'utilisateur (on ne parle pas d'admins ou développeurs) de choisir sur des questions de sécurité est vraiment de la connerie.
L'utilisateur n'a tout simplement pas l'expertise pour faire des choix de sécurité.
Laisser à l'utilisateur la responsabilité de la sécurité est de la connerie. Peut-être que beaucoup veulent avoir cette responsabilité car ça les flatte, mais c'est de la connerie.
Qu'Ubuntu choisisse AppArmor et Fedora choisisse SeLinux est une chose. Mais la responsabilité reste chez le distributeur, pas chez l'utilisateur.
Si on regarde Fedora (mais ça doit être la même chose chez les autres), le firewall est activé par défaut (et on ne peut pas le désactiver à l'installation), idem pour SeLinux, root ne peut pas se connecter sous X11, etc. Les décisions de sécurité ont été faite par la distribution. Si on ne les aime pas, on change de distribution ou on se documente pour savoir comment les adapter.
> Est-ce que tu a cliqué sur les hyperliens que j'ai mis derrière les expressions "avantages distincts" et "comparer les approches" et qui expliquent l'utilité des divers modules en les comparant ?
Ce n'est pas le problème ici. Merci pour toutes ces informations.
Mais si on regarde ces liens (qui sont d'acteurs "pro-pathname-based") il n'y a qu'un argument à mon avis valide (parce que, par exemple, on peut faire un mode "policy learning" pour SeLinux, mais ses concèpteurs n'en veulent pas), c'est que les systèmes pathname-based n'ont pas de support du système de fichier. C'est aussi une préoccupation de SeLinux. Le reste un peu "bullshit".
[^] # Re: Re:
Posté par patrick_g (site web personnel) . Évalué à 6.
Ce sera la même chose quand TOMOYO sera dans le noyau.
Les distributions (qui savent prendre des décisions de sécurité) auront un choix plus large de module de sécurité pour répondre à leurs besoins particulier.
Les utilisateurs de base, qui ne savent pas vraiment faire un choix éclairé en matière de sécurité, utiliseront ce qui aura été configuré par leur distro.
Les power users, qui eux savent faire des choix éclairés, pourront changer de module si ils ont une préférence pour l'un ou l'autre.
Je ne vois pas de qu'il y a de néfaste là dedans.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 1.
> Les power users
Ce qui demanderait plus de précision. On voit beaucoup de "power users" en herbe se prendre pour des spécialistes en sécurité.
Tu me diras que rien n'arrête la connerie.
Ce qui séduit dans AppArmor, c'est sa simplicité, ce qui donne une occasion aux "power users" en herbe de trifouiller sous le capot. Pas la simplicité pour le vrai "power user", mais la simplicité pour le "power user" en herbe. En cela ça me cause soucis. La priorité n'est pas de faire de la sécurité avec rigueur, mais de faire "un jouet qui amusera les masses".
> Je ne vois pas de qu'il y a de néfaste là dedans.
Oui et non.
Le concept de sécurité pathname-based est si problématique (sécurité et/ou performance!) que les experts sécurité l'évitent. Il y a très peu de développeurs sur AppArmor. Si AppArmor était si brillant et simple, on devrait avoir plein de règle de sécurité. Mais il reste, après des années, toujours très loins de SeLinux.
Qu'es-ce que Linux y a gagné jusqu'à maintenant ? Rien du tout et même pire. A force de fuder sur SeLinux, les distributions l'évitent afin de soigner leur image et au final ne font rien. Combien d'années va durée cette situation grotesque ? Un paquet d'année si tous les 6 mois il y a un nouveau venu qui promet la lune.
Tout ceci ne profite qu'à un seul. A Red Hat. Je suis pro-Red Hat, mais gagner sur la stupidité des autres... Voire la situation ridicule où s'est mis Novell en passant à AppArmor pour des raisons ... pas très rationnelles. Et voila Novell qui ne peut plus répondre à certains appels d'offre (souvent juteux). C'est ballot. Et pour Ubuntu ? Ben c'est particuliairement discret depuis la 8.10...
Bref, on y a rien gagné. Le qualificatif "néfaste" est peut-être trop fort, mais il y a de ça. Smack est un cas à respecter même s'il est un cailloux dans la chaussure de SeLinux :-) Son principe est bon et il ne prétend pas être un système généraliste comme SeLinux, mais cible l'embarqué.
A part au niveau rhétorique ("le choix c'est bon") qu'a t'on gagné avec AppArmor ?
Qu'allons nous gagner avec TOMOYO ?
PS : http://lwn.net/Articles/277842/ est de Crispin Cowan (AppArmor/TOMOYO) qui à ma connaissance bosse maintenant chez Microsoft...
PS2 : je ne parle pas de TOMOYO car je ne connais pas.
[^] # Re: Re:
Posté par Ozz . Évalué à 5.
Je n'ai aucune intention de me spécialiser dans la sécu linux, je ne déploie pas de système critique, selinux ne vaut pas le mal de tête qu'il me donne, fin de l'histoire. Et il ne sera jamais implémenté dans les petites distros.
Le mode d'apprentissage de Tomoyo n'a d'intérêt que parce que je suis capable de comprendre les règles qu'il crache. A mon avis il vaut mieux ça que passer des trucs que j'ai à moitié compris à audit2allow.
La sécurité est toujours un compromis, et dans mon cas le contrôle et la compréhension que j'ai du système sont plus important qu'une solution parfaite sur le papier. Donc je veux un système KISS. Aujourd'hui le compromis pour moi, c'est pas de MAC du tout, l'arrivée de solutions intermédiaires (si validé par les devs linux, j'ai relativement confiance) est une avancée.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 1.
C'est quoi une petite distribution ?
> Aujourd'hui le compromis pour moi, c'est pas de MAC du tout,
AppArmor est MAC.
> l'arrivée de solutions intermédiaires (si validé par les devs linux, j'ai relativement confiance) est une avancée.
Quelle avancée ? Avoir seulement cups par défaut de "protégé" par AppArmor dans Ubuntu ? Avoir une communauté de développeur aussi fine que du papier à cigarette ? Faire que la sécurité dépendante des "power users" en herbe ?
Pas très ambitieux tout ça si on prétent que la sécurité est important.
Si la sécurité est important pour toi, passe une journée à te documenter sur SeLinux.
[^] # Re: Re:
Posté par Cédric Chevalier (site web personnel) . Évalué à 5.
Si la sécurité est importante, je pense que la documentation d'OpenBSD serait plus appropriée ;).
[^] # Re: Re:
Posté par IsNotGood . Évalué à 3.
Petite question en passant. Connais-tu vraiment SeLinux ?
J'ai remarqué que beaucoup de ceux qui critiquent SeLinux, ne connaissent pas SeLinux, pire ne veulent pas le connaitre. Après tout argument contre SeLinux, même bidon, est avalé comme du petit lait par ces derniers.
Au cas où ça t'intéresserait, une très bonne doc d'introduction (et plus) à SeLinux :
http://docs.fedoraproject.org/selinux-user-guide/
[^] # Re: Re:
Posté par patrick_g (site web personnel) . Évalué à 3.
Merci.
# Btrfs
Posté par alberthier (site web personnel) . Évalué à 9.
Genre j'ai un fichier de 2Go et mon disque est plein, il ne reste que 100Mo, avec le copy-on-write, je peux en faire une copie mais pas le modifier?
De même, si on compresse les données, Si il reste 100Mo sur le disque, je pourrais sans doute y placer un fichier texte de 120Mo qui se compresse bien mais pas une vidéo de 120Mo qui ne se compresse quasiment pas.
[^] # Re: Btrfs
Posté par herodiade . Évalué à 7.
> avec le copy-on-write, je peux en faire une copie mais pas le modifier?
Il y a une imprécision dans la description du COW de la dépêche qui peux induire en erreur: ce qui est "copié" à l'écriture (en fait, tout simplement : écrit ailleurs qu'à l'emplacement d'origine), c'est le bloc écrit, pas le fichier lui-même. Copie un fichier complet aurait un cout énorme.
> on pert la notion d'espace maximal de stoquage d'un disque, non ?
Sur un système de fichier posix traditionnel, la taille d'un fichier et son occupation disque sont déjà des notions relativement indépendantes.
$ dd if=/dev/zero of=fichier count=1 seek=10M
$ du -h fichier
16K fichier
$ ls -lh fichier
-rw-r--r-- 1 pouet pouet 5,1G 2009-03-24 20:42 fichier
[^] # Re: Btrfs
Posté par reno . Évalué à 2.
# petits frères...
Posté par JB. Giraudeau . Évalué à 9.
Le dernier venu ne serait-il pas plutôt le petit frère... (pour ceux qui suivent vraiment ;)
# LRO n'est pas nouveau...
Posté par Brice Goglin . Évalué à 10.
> [...]
> L'implémentation retenue pour le noyau 2.6.29 est très générique
> afin que les divers pilotes réseau possédant cette fonction puissent
> utiliser le code générique au bénéfice de la mutualisation du code.
C'est complètement faux...
LRO est dans le noyau depuis très longtemps. Il a été standardisé dans 2.6.23 justement pour mutualiser du code que certains drivers avaient écrit de manière proprio. Depuis, il y a plein de drivers modernes qui l'utilisent (myri10ge, pasemi, igb, benet, sfc, enic, cxgb3, mlx4 et ehea). D'ailleurs le lien LWN date de 2007.
2.6.29 ne fait qu'ajouter une nouvelle implémentation plus propre et plus facile à appliquer aux drivers basiques (le vieux LRO était plutôt conçu pour les drivers récents). D'ailleurs ca s'appelle GRO et plus LRO maintenant.
> L'idée consiste en gros a agréger les paquets reçus dans un tampon
> afin de moins solliciter la pile réseau de la machine.
En moins gros: On n'agrège pas les paquets dans un tampon (sinon ca ferait une copie mémoire très chère), on ne fait que chaîner des socket buffers pour les passer tous d'un coup à la pile TCP/IP.
[^] # Re: LRO n'est pas nouveau...
Posté par patrick_g (site web personnel) . Évalué à 3.
D'après http://lwn.net/Articles/244295/ je crois que la situation de LRO n'étais pas si rose que ça.
Le lien explique que LRO a été introduit par le pilote Neterion a l'époque du 2.6.17 et que quand les devs du pilote Myri-10G ont voulu introduire LRO dans leur pilote à eux cela a été rejeté car évidemment personne ne souhaitait avoir une implémentation différente pour chaque pilote.
La solution passait par un code LRO générique qui serait réutilisé par tous les pilotes.
L'ennui c'est que le pilote NetXen a été intégré par erreur avec son implémentation LRO spécifique dans le noyau 2.6.20 et donc tout le monde a gueulé.
La nouveauté du noyau 2.6.29 c'est l'entrée de cette implémentation complètement générique (qui a été nommée, tu a raison, GRO pour Generic Receive Offload).
Maintenant je me suis basé sur LWN pour écrire ça mais il a peut-être des erreurs dans l'article ou alors j'ai mal compris.
[^] # Re: LRO n'est pas nouveau...
Posté par Brice Goglin . Évalué à 10.
La situation n'était pas rose avant 2.6.23. Depuis 2.6.23, ca va.
[^] # Re: LRO n'est pas nouveau...
Posté par patrick_g (site web personnel) . Évalué à 10.
Arf j'avais même pas réalisé.
Bon ben j'ai l'air couillon maintenant ;-)
# le BKL
Posté par Henry-Nicolas Tourneur (site web personnel) . Évalué à 5.
Qu'en est-il du BKL ? Dans la dépèche traitant le sujet il avait été dit (si j'ai bonne mémoire) qu'une suppression progressive aurait lieu au fil des releases.
Et donc maintenant quel est l'état du kernel par rapport à cela ?
[^] # Re: le BKL
Posté par fweisbec . Évalué à 5.
Il a été supprimé de l'appel système fasync() par Jonathan Corbet. Il me semble aussi qu'il a été supprimé à certains endroits de la couche tty.
De toutes façons c'est une priorité pour la branche -rt, donc il finira par être éradiqué.
Ingo molnar avait fait une sous branche exprès ("Kill-the-bkl") dans sa branche -tip:
http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.(...)
Dans cette branche, le bkl est transformé en Mutex (c'est un spinlock dans la branche principale). Il me semble que c'est pour faciliter le débuggage pour l'enlever.
Car pour l'instant c'est un raw_spinlock, c'est à dire un spinlock qui ne peut pas être tracé par lockdep (l'outil de vérification des verroux dans le noyau).
Mais j'ai l'impression que les foules ne se bousculent pas au portillon pour bosser dans cette branche. Ceci étant ça pourrait changer :-)
[^] # Re: le BKL
Posté par Henry-Nicolas Tourneur (site web personnel) . Évalué à 2.
Et, est-ce qu'il y a une timeline, des prévisions ou quoi que ce soit de ce genre pour un retrait complet du BKL ? Ou bien c'est uniquement au fil du temps, quand les développeurs sont inspirés pour une fonction en particulier ?
[^] # Re: le BKL
Posté par fweisbec . Évalué à 10.
Je pense que ça se fera au fur et à mesure, parce que aucune personne seule ne peut corriger chaque endroit où se trouve le Bkl.
Quand bien même il y a une aversion générale pour ce vérrou, son retrait dépend beaucoup de la motivation qu'ont les mainteneurs ayant des affinités avec les sous-systèmes concernés.
Je m'explique, le Bkl n'est pas seulement un verrou géant, c'est aussi et surtout une horreur sans nom:
- C'est un verrou qui peut être acquis et réaquis autant de fois par une même tâche autant de fois qu'elle le désire.
Par exemple, un spinlock ou un mutex du noyau linux n'autorisera _jamais_ un usage récursif.
L'usage typique est:
mutex_lock(&lock);
//code partie protégée
mutex_unlock(&lock);
Mais si tu essaies:
mutex_lock(&lock)
//gnagnagna bidule chouette
mutex_lock(&lock); <--- ici un blocage (deadlock)
//gnagnagna2 prout
mutex_unlock(&lock);
mutex_unlock(&lock);
On pourrait éventuellement s'attendre à ce que ce code soit légal dans un même
thread, car c'est possible de l'implémenter. Mais non et heureusement.
Or le Bkl autorise ça pour une même tâche, il y a même un indicateur dans la structure des tâches du noyau pour indiquer la profondeur courante du Bkl pour une tâche donnée
// current->lock_depth = -1
lock_kernel(); // current->lock_depth = 0
//pouet
lock_kernel(); // current->lock_depth = 1 (on ne deadlock pas)
//flet
unlock_kernel(); // current->lock_depth = 0
unlock_kernel(); // current->lock_depth = -1
C'est horrible parce que le code qui a été écrit en suivant cette liberté désinvolte est maintenant très difficile à corriger. Il ne suffit plus de remplacer le bkl par un simple verrou normal, il faut carrément parfois réorganiser le code.
Un cas typique c'est reiserfs qui possède des pans entiers dépendants de cette logique de récursivité.
- Le bkl est libéré pour la tâche courante lorsque celle-ci appelle schedule() O_o
Ca signifie qu'à chaque fois qu'une tâche détenant le bkl veut dormir, elle lâche le bkl et n'importe qui peut le reprendre. Et quand la tâche se réveille (quand schedule() retourne) le bkl est relocké pour la tâche courante.
Ca non plus ça n'a rien à voir avec un mutex ou spinlock normal. Ca veut dire que si l'auteur du code a prévu un appel à schedule(), qu'est ce qu'il avait en tête: dormir en attendant une ressource? Dormir pour relâcher un peu le verrou et le donner à quelqu'un d'autres pendant quelques temps?
- $ git-grep -E "[^n]lock_kernel\(\)" | grep -v "Documentation" | wc -l
590
Il y a 590 appels au bkl egrainés un peu partout dans le noyau. Souvent, chaque sous-système possède ses propres spécialistes qui sont les plus compétents pour résoudre ce vieux schéma de synchronisation, pour intégrer un vrai schéma de protection des données bien réfléchi.
Mais le problème c'est que c'est chiant. Il faut parfois repenser la structure du code, repenser des interdépendances avec d'autres zones qui détiennent le Bkl etc...
Je pense que si tout le monde s'y mettait, ça se passerait bien mais bon c'est tout simplement chiant.
Ceci étant la branche kill-the-BKL d'Ingo Molnar est plutôt bien vue.
Il s'agit de transformer le bkl en un mutex géant (faisant ainsi perdre les propriétés de récursivité et de relâche par schedule()) et donc permettre à lockdep de vérifier les problèmes qui surviennent. Ca permet d'identifier les zones à problèmes particulières.
[^] # Re: le BKL
Posté par Henry-Nicolas Tourneur (site web personnel) . Évalué à 1.
Ce qui serait sympa d'ajouter aux dépèches dans ce cas, c'est l'état d'avancement de la branche kill-the-BKL d'Ingo (dans le cas ou il y a des changements).
[^] # Re: le BKL
Posté par fweisbec . Évalué à 2.
Je pense que les choses y évolueront par petites étapes. Est ce que ça vaut le coup d'écrire des dépêches là dessus?
Traduction: est ce que des lecteurs seraient interessés?
[^] # Re: le BKL
Posté par Henry-Nicolas Tourneur (site web personnel) . Évalué à 2.
Je pensais plutôt à une rubrique "état du BKL" dans les dépèches de patrick_g.
Mais je ne doit pas être le seul à m'y intéresser je pense, on pourrait en faire des journaux si ça t'intèresse d'écrire sur le sujet (déjà ton commentaire précédent était fort claire et intéressant).
En fait moi ce qui me dérange dans le BKL c'est pas juste sa présence (bien qu'on aime aussi que les softs qu'on utilise soit propre ce qui ne semble pas être le cas de ce composant - le BKL), c'est plutôt ce genre de problème :
http://lkml.indiana.edu/hypermail/linux/kernel/0504.0/1838.h(...)
Vu que j'utilise également du NFS chez moi. Dans ce thread, la personne qui répond explique que le soucis peut être du à une concurrence entre bdflush et rpciod (pour avoir le BKL) ce qui résulte en un load élevé (ce que j'observe effectivement).
Il conseille de modifier les valeurs vm.dirty_writeback_centisecs ainsi que vm.dirty_expire_centisecs (sur les postes clients autant que sur le serveur je présume) mais je ne sais vraiment pas quel impact ce genre de mesure aura sur mon laptop (si j'écrit plus souvent de petites quantités de données ça devrait être pas très bon pour l'autonomie non ?).
En gros, c'est pour ça que j'aimerai que le BKL disparaisse au profit d'une meilleur solution comme expliquée dans la dépèche de patrick_g traitant du sujet.
# Quid de la recompilation du noyau...
Posté par Spack . Évalué à 3.
Du coup, ma première impression est un noyau qui grossit avec des choses qui sont la plus part du temps inutiles pour un utilisateur lambda. Dans le cas d'une distribution, la création d'un noyau générique est normal afin de supporter un certain nombre de cas de figure et le maximum de matériel possible.
Mais, pour un utilisateur avancé, qui connaît sont matériel (et ses éventuelles évolutions ;), n'est-il pas bénéfique de compiler son noyau avec juste ce qui est essentiel ?
Oui mais avec la puissance actuelle, cela ne se voit pas. J'aime à penser que plus le noyau est petit et plus vite il est lancé même si cela ne change que de très peu.
Vous me direz que l'on peut faire un petit noyau avec des modules qui gravitent autour. Mais cela revient à avoir beaucoup de modules dans ce cas, et donc de la place perdue sur le disque.
Oui mais avec la taille des disques actuelles, est-ce vraiment gênant ? Je n'aime pas cette idée de gaspiller les ressources. Ce n'est pas parce qu'il y a de la place que l'on se doit de tout utiliser. Regardons "la prise de conscience" (surtout dû à la pénurie prochaine de pétrole et que ça fait gagner des sous) concernant l'écologie de nos jours.
Un noyau plus petit donc moins de place consommée, une empreinte mémoire plus petite, plus d'espace pour les autre, chargement moins long, puissance nécessaire réduite ?
[^] # Re: Quid de la recompilation du noyau...
Posté par Dup (site web personnel) . Évalué à 4.
Y a t-il quelqu'un pour nous pondre une traduction des messages d'aide du kernel lol
Autant j'apprécie la distribution Archlinux autant son kernel est minimaliste. Tout les modules pour la gestion du matériel sont présents mais des technos telles que CGROUP, ou encore SMACK sont absentes. Il est du coup nécessaire de faire son kernel maison :p
Et bon compiler son kernel ca reste une geekerie donc nécessaire.
[^] # Re: Quid de la recompilation du noyau...
Posté par Spack . Évalué à 5.
[^] # Re: Quid de la recompilation du noyau...
Posté par Epy . Évalué à 2.
Y a-t-il un projet disponible pour cela ? (C'est une vraie question)
Si il y a quelque chose permettant cette traduction aisée (donc sans récupérer toutes les sources et chercher à la main dedans, j'avoue je ne sais même pas comment ça marche) je pourrais m'y intéresser :)
Est-ce que les anglophones et les devs noyau seraient intéressés d'avoir cette aide en multilangue ? Sachant que si ça n'a pas déjà été prévu, ça peut leur faire un boulot monstre en plus :/
[^] # Re: Quid de la recompilation du noyau...
Posté par Spack . Évalué à 2.
Il "suffirait" donc de traduire ces fichiers.
[^] # Re: Quid de la recompilation du noyau...
Posté par Epy . Évalué à 1.
Je peux toujours commencer à mes heures perdues (euh), et les tenir à dispo pour quand ce sera disponible officiellement :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.