samedi 06 septembre

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Logiciel

Liens connexes

Les nouveautés du noyau 2.6.25 (3414 hits)
Le bilan des ajouts partie 1 (516 hits)
Le bilan des ajouts partie 2 (330 hits)
Le bilan des ajouts partie 3 (337 hits)
Les prévisions pour l'avenir de Linux (1181 hits)

Dépêche modérée par

pterjan

Dépêche éditée par

Logiciel : Le noyau Linux 2.6.25 est disponible

Posté par patrick_g (page perso, ). Modéré le 17 avril 2008.

La toute dernière version du noyau Linux stable est maintenant téléchargeable sur les serveurs du site kernel.org. Cette version 2.6.25 a suivi le processus de développement devenu maintenant classique.

Peu avant la sortie du 2.6.24 les divers mainteneurs des sous-systèmes ont indiqués sur la liste de diffusion du noyau leurs intentions sur les patchs suffisamment stables pour pouvoir migrer de la branche de test d'Andrew Morton (la -mm) vers la branche de Linus. La période d'intégration de ces milliers de patchs doit durer deux semaines et elle permet l'ajout de toutes les nouveautés prévues dans le nouveau noyau.

Cette fois-ci le démarrage a été rendu un peu plus lent car la plupart des développeurs participaient à la conférence Linux en Australie à la fin du mois de janvier. Une fois la fenêtre d'intégration d'environ quinze jours refermée la saga des "releases candidates" a pu commencer.

Les nouveautés du noyau 2.6.25 (3414 hits)
Le bilan des ajouts partie 1 (516 hits)
Le bilan des ajouts partie 2 (330 hits)
Le bilan des ajouts partie 3 (337 hits)
Les prévisions pour l'avenir de Linux (1181 hits)

> Lire la suite (134 commentaires, moyenne: 4,1). [dépêche : 34938 caractères]

Les versions candidates

La version RC-1 est donc apparue juste dix-sept jours après la sortie du noyau stable précédent. Linus s'est amusé dans son annonce à faire quelques statistiques sur le nombre de changements:
"C'est une RC sacrément grosse (comme le fut la RC1 du noyau précédent) probablement parce que le cycle de sortie du 2.6.24 a été plus long que prévu et que les gens avaient pleins de choses en attente. Le diff est d'environ 11 Mo et représente 1,4 millions de lignes, avec la majorité concernant les pilotes et les mises à jour d'architectures.
Juste pour le fun j'ai fait quelques statistiques triviales et, sur les 1,4 millions de lignes, 38% (soit 530.000) concernent les diverses architectures et 44% (soit 610.000) concernent les pilotes. Le reste est bien plus petit mais on peut noter le réseau (8% pour 110.000 lignes), les systèmes de fichiers (4%) et la documentation pour environ 2%."
Pour la RC-2 Linus nous a sorti un de ses mails "spéciaux" et je ne résiste pas à la tentation de le citer largement:
"OK ce noyau est un "winner". Juste pour vous montrer à quel point c'est un "winner", il lui a été décerné un très convoité nom de série basé sur "belette", ce qui vous indique la qualité que va avoir ce noyau. C'est un nom révéré dans l'histoire du noyau Linux et, en tant que tel, il ramène aux bons vieux jours ou si vous trouviez un bug c'était presque certainement une erreur due au fait que vous aviez fait quelque chose de travers.
Mais bon, vous pouvez essayer de me prouver que j'ai tort si vous l'osez.
Pour avoir une vue des diff on peut utiliser la fonction git "dirstat" qui donne un bon aperçu général. En particulier cela montre que presque la moitié des mises à jours concernent les pilotes, avec les pilotes réseau représentant un tiers du patch global.
C'est vraiment une super fonctionnalité de git. Cela me permet de gagner une heure par semaine à rester avachi en sirotant une boisson tropicale (ce qui porte mon total hebdomadaire de stupeur alcoolique à environ 168,5 heures) puisque je n'ai plus à faire manuellement le travail des statistiques de diff.
Enfin bon voilà le résultat :2.1% Documentation/ 3.7% arch/cris/ 7.0% arch/sh/configs/ 4.4% arch/sh/kernel/ 4.9% arch/sh/mm/ 17.8% arch/sh/ 23.8% arch/ 33.5% drivers/net/ 6.0% drivers/scsi/lpfc/ 7.1% drivers/scsi/ 4.5% drivers/sh/maple/ 49.5% drivers/ 8.1% fs/ 2.5% include/linux/ 4.5% include/ 7.2% kernel/ 2.0% net/ 509 files changed, 14470 insertions(+), 6986 deletions(-)

Vous devez admettre que cela fait très manager, même si vous n'avez absolument aucune foutue idée de ce dont il est question (ce qui fait également très manager). Maintenant il ne me reste plus qu'à transformer tout ceci en quelques camemberts dans une présentation Powerpoint bien colorée et alors je pourrai _vraiment_ éteindre mon cerveau.
J'ai confiance dans le fait que ce cycle noyau ne sera pas aussi douloureux que le précédent et c'est pour ça que je vais profiter de ce long week-end et rester sur la plage. Soyez gentils pendant que je sirote mon Mai Tai. Celui avec un parasol.
Linus
PS : En Oregon nous n'utilisons pas ces mignons petits parasols en papier. Nous on a les bons gros parasols pour être sûr et certain que nos boissons ne sont pas trop délayées par de l'eau. Ah les plages de l'Oregon en février !
Linus a eu raison et les releases candidates suivantes sont apparues à l'heure dite sans problèmes particuliers. Entre le 24 février et le 9 mars les RC-3, RC-4 et RC-5 ont été annoncées avec à chaque fois la visualisation "managériale" générée par Git que Linus semble apprécier particulièrement.
La RC-6 a été un peu plus longue: "Bon j'ai perdu un jour et demi cette semaine à cause d'un de mes disques qui a décidé d'avoir des erreurs de lecture à la suite d'une malencontreuse coupure de courant. J'ai dû passer pas mal de temps à reconstruire mon environnement normal mais je ne pense pas avoir perdu le moindre mail."
Le 25 mars Linus a annoncé la sortie de la RC-7 et a demandé un dernier effort sur les tests pour que le noyau 2.6.25 définitif soit vraiment bien stable.
Le premier avril a été annoncée la RC-8 qui devait être la dernière version candidate avant que Linus n'annonce le 11 avril la sortie d'une RC-9:
"Je n'ai vraiment pas envie de faire ça et j'avais en fait l'espoir de fournir le noyau 2.6.25 le week-end dernier (ce qui explique pourquoi la RC-9 a quelques jours de retard - c'est parce que j'espérais ne pas avoir à la sortir du tout) mais j'ai été obligé de sortir une RC-9. La raison de ce retard du 2.6.25, c'est que certaines personnes se sont inquiétés à propos de l'allocateur mémoire SLAB. Je voulais sortir quelque chose cette semaine mais je ne me sentais pas confiant au point de faire une version finale.
Cela dit, je pense que, quoi qu'il en soit, je vais sortir le 2.6.25 au début de la semaine prochaine parce que nous ne pouvons tout simplement pas retenir éternellement les choses. À un moment donné cela devra devenir une question relevant des versions 2.6.25.X et les développeurs ayant du code de prévu pour la prochaine version pourront commencer à l'envoyer.
Linus
PS. La dernière semaine a été un peu frustrante. Donc, si je me suis comporté de façon encore moins polie que d'habitude en public ou dans des e-mails privés, je vous fait mes excuses. Les intéressés se reconnaîtront.

Les nouveautés

Le module SMACK (Simplified Mandatory Access Control Kernel) a été ajouté au noyau 2.6.25 afin d'offrir une alternative simplifiée à SELinux.
Ces deux modules de sécurité utilisent l'infrastructure LSM afin de permettre des restrictions d'accès très spéciales pour améliorer la résistance aux attaques et définir des politiques de sécurité lors de l'utilisation. Traditionnellement les systèmes de type Unix se basent sur des architectures DAC (Discretionary access control) c'est à dire que les actions sont autorisées en fonction de l'identité du demandeur ou du groupe auquel il appartient. Avec les architectures MAC (Mandatory access control) on ne se base plus sur l'identité du demandeur mais sur des attributs étendus qui sont attachés aux différents objets du système (les fichiers, les répertoires, les ports...etc). SELinux est un module très puissant mais il est malheureusement assez complexe à configurer et à gérer au quotidien. En dépit des efforts méritoires de ses promoteurs pour simplifier son utilisation au fil du temps, il y a toujours eu un mécontentement chez une partie des utilisateurs. Ces derniers ont exercé une pression afin qu'une solution plus simple apparaisse et SMACK est le résultat de cette pression. Bien entendu la complexité de SELinux est inhérente à la définition d'une politique de sécurité complète et cohérente et SMACK paye sa simplicité par une moindre puissance et une moindre généralité. Techniquement SMACK fonctionne, comme SELinux, en écrivant des labels (des chaines ASCII) qui sont attachés aux différents objets du système. Il lit ensuite les règles d'accès qui sont présentes dans dans /smack/load et ont une syntaxe de type label-du sujet label-de-l'objet droit-d'accès.
SMACK restreint l'accès en fonction du label attaché au sujet et du label attaché à l'objet auquel le sujet essaye d'accéder. C'est cette syntaxe qui constitue la grande simplification par rapport à son concurrent SELinux (avec également la disparition de la possibilité du contrôle d'accès à base de rôles). Seule la comparaison de règles est possible et il n'y a pas de caractère joker ou de gestion des expressions régulières. Ce fichier pdf de Casey Schaufler, l'auteur de SMACK, explique plus en détail le fonctionnement de cette nouvelle architecture.
Les développeurs de SELinux, qui étaient jusqu'à présent les seuls utilisateurs de l'infrastructure LSM, ont opposé une âpre résistance à l'inclusion de SMACK dans le noyau. Selon eux il suffisait d'encapsuler SELinux dans une couche destinée à cacher sa complexité plutôt que d'ajouter une toute nouvelle infrastructure de sécurité. Les discussions sur la liste de diffusion ont été chaudes et James Morris, l'un des développeurs de SElinux, a été particulièrement opiniâtre. Il a fallu que Linus siffle brutalement la fin de la récréation en décrétant que SMACK avait sa place dans le noyau et que l'infrastructure LSM resterait aussi: « Quand je verrai les spécialistes de la sécurité utiliser des arguments rationnels et se mettre d'accord sur un truc les choses changeront peut-être. Mais franchement je m'attends à ce que l'enfer gèle et que les cochons nichent dans les arbres avant que cela n'arrive. Mais bon, je peux toujours espérer. »
Toute cette controverse a fait l'objet d'un article détaillé du site Linux Weekly News.
Le mécanisme de Read-copy update a été significativement amélioré afin de pouvoir répondre aux exigences du temps réel. La technique RCU, introduite en 2002 dans le noyau, permet de synchroniser rapidement les accès à des données dans un environnement multiprocesseurs. Les processus légers vont par exemple pouvoir lire ces données sans poser de verrou spécial (un lock) ce qui est très intéressant en terme de charge processeur car un verrou est coûteux en ressources. Si un autre processus léger veut modifier les données alors une copie de ces données est faite et la modification s'effectue sur la copie. L'original, lui, ne sera effacé qu'au moment ou le dernier des processus lecteurs aura terminé son travail.
La technique Read-copy update avait néanmoins un désavantage significatif puisqu'il n'était pas possible d'avoir des garanties sur les latences introduites lors de la phase d'update. Le noyau 2.6.25 introduit donc la possibilité de "préempter" le RCU, c'est à dire qu'un processus prioritaire peut prendre la main et passer devant les autres ce qui n'était pas possible avec les implémentations RCU antérieures. Le code, écrit par Paul McKenney, a maturé un certain temps au sein de la branche -rt maintenue par Ingo Molnar et son introduction dans la branche principale permet de se rapprocher un peu plus d'une capacité complète à supporter le temps réel avec le noyau Linux.
Toujours dans le domaine du temps réel plusieurs avancées sont apportées par le nouveau noyau 2.6.25. L'ordonnanceur CFS a été rendu plus agressif dans le déplacement des processus entre les coeurs de calcul. Maintenant, dans le cas d'une compétition entre des tâches temps réel pour accaparer un seul coeur, le noyau migrera plus efficacement certaines tâches vers les autres processeurs afin d'éviter les temps d'attente. D'autre part le verrou global du noyau (big kernel lock) est maintenant préemptible par défaut et l'option permettant de ne pas le rendre préemptible va sans doute disparaître. Les timers à haute résolution peuvent maintenant être utilisés pour calculer les priorités entre les processus ce qui rend l'ordonnanceur plus précis lors de ses allocations de temps. On peut également noter que la fonction d'ordonnancement de groupe, introduite dans le noyau précédent, gagne des fonctions de support du temps réel.
La mesure de la consommation mémoire des processus a été raffinée par l'introduction de plusieurs patchs de Matt Mackall. La situation jusqu'à présent était peu satisfaisante puisque le mécanisme de cache proposée par le noyau, très efficace, brouillait les statistiques sur la consommation mémoire réelle des applications.
Avec la nouvelle technique disponible dans le noyau 2.6.25 un fichier est créé (dans /proc/$PID/pagemaps) pour chaque processus en cours. Le fichier contient la localisation physique des pages mémoires de l'application ce qui permet de comparer avec les autres et de déduire les pages partagées en mémoire et les pages spécifiques utilisées par un seul processus. On obtient ainsi de nouvelles statistiques précises pour l'occupation mémoire. Le PSS (proportional set size) d'un processus est le nombre de pages qu'il utilise avec chaque page divisée par le nombre de processus la partageant. Par exemple un processus ayant 1000 pages uniques et 200 pages partagées avec 4 autres processus aura un PSS de 1040 (1000 + (200/5)). Une autre statistique est le USS (unique set size) qui compte uniquement les pages non partagées d'un processus. Ce sont en fait les pages mémoires qui redeviendront vraiment disponibles en cas de fermeture du processus. Matt Mackall travaille dans le domaine de l'embarqué où la mémoire est souvent une ressource rare et précieuse. Ses patchs vont certainement aider à mieux estimer la taille des applications et donc à permettre de prendre des décisions plus judicieuses sur les compromis à effectuer.
Le système de fichier Ext4 continue d'être amélioré afin de pouvoir, dans quelques mois, être activé par défaut dans toutes les distributions Linux. Dans la version incluse dans le noyau 2.6.25 on peut noter que la taille des blocs mémoires, qui était auparavant fixée à 4 Ko, est maintenant adaptable et peut atteindre 64 Ko au maximum. Des sommes de contrôle sont effectuées sur le journal du système de fichier afin d'augmenter la résistance aux corruptions de données. L'allocation des blocs pour les extends se fait maintenant par groupe de plusieurs blocs. Cette allocation multiple des blocs est très complexe et de nombreuses heuristiques sont utilisées afin d'optimiser au maximum les performances. Selon Thed Ts'o, qui dirige l'effort de développement d'Ext4, ces changements sont les derniers à impacter le format des systèmes de fichiers Ext4 sur les disques durs. Toute future modification sera sans conséquences sur le format ce qui est le signe que les choses commencent à se stabiliser et qu'Ext4 sera bientôt disponible pour tous.
L'implémentation des verrous tournants a été revue. Jusqu'à présent ce système de "spinlock" permettait à un processus léger de tourner dans une boucle infinie en attendant patiemment que le verrou sur la ressource auquel il voulait accéder soit libéré. L'ennui avec ce mécanisme c'est qu'il n'est pas équitable. Expliquons pourquoi: Quand une ressource est libre elle a une valeur égale à 1 et ce nombre est décrémenté de 1 quand un processus pose un verrou sur elle en utilisant l'appel système spin_lock(). Si un nouveau processus arrive et veut utiliser la ressource il va faire son spin_lock() et se rendre compte que le résultat n'est pas 0 (ce qui indiquerait une ressource disponible) mais -1. Il va donc se mettre dans une boucle et attendre la libération de la ressource. Plusieurs processus peuvent ainsi tourner en attendant la libération et il est facile de voir que plus la valeur sera négative et plus cela indique que la compétition est rude pour utiliser cette ressource. Quand enfin le tout premier processus libère la ressource (en repositionnant la valeur à 1) c'est le premier thread tournant à tester la valeur qui va réussir à poser son verrou. Ce petit chanceux passe ainsi devant tous les autres mêmes si ces derniers tournaient dans la boucle depuis plus longtemps que lui. Cet état de fait, outre qu'il choque notre sens inné de la justice, conduit à une forte réduction des performances (jusqu'à une multiplication par deux du temps d'exécution d'un thread).
Le noyau 2.6.25 introduit donc un mécanisme destiné à résoudre ce problème fondamental. Nick Piggin a proposé et implémenté la notion de "verrous tournants avec tickets" qui consiste à utiliser une valeur de 16 bits pour stocker l'ordre d'arrivée des processus et ainsi permettre de prioriser ceux qui sont en attente depuis plus longtemps que les autres (le même système que les tickets d'attente dans les guichets de l'administration). On utilise 8 bits pour le processus courant et 8 bits pour le processus suivant dans la file d'attente. Bien entendu une valeur stockée sur 8 bits limite à 255 le nombre de processus pouvant utiliser le nouveau mécanisme des "verrous tournants avec tickets". Pour les machines ayant plus de 255 coeurs de calcul une version spéciale du patch est disponible. Elle stocke la valeur sur 32 bits (soit 16 bits pour le processus courant et 16 bits pour le suivant) ce qui permet aux machines ayant moins de 65536 coeurs de calcul de profiter des "verrous tournants avec tickets". En cas de besoin futur cette valeur sera une nouvelle fois agrandie mais pour l'instant il y a de la marge.
Le support des bus de données de type CAN (Controller Area Network) a été ajouté au noyau 2.6.25. Ce format de transfert de données est utilisé dans l'industrie automobile et a été développé spécifiquement pour répondre à la problématique du temps réel embarqué dans un environnement perturbé electro-magnétiquement. Les données sont complètement protégées par des sommes de contrôle et le protocole est simplifié au maximum afin d'éviter les erreurs. Pour implémenter le bus CAN la première solution avait été de passer par le bus série traditionnel et de mettre les détails spécifiques au protocole en espace utilisateur. C'est la solution rapide et vilaine car elle ne permet pas de profiter de tous les avantages de la pile réseau Linux (mise en queue, maintien de la qualité de service, utilisation de l'API socket traditionnelle...etc) et elle oblige le développeur à coder toutes ces fonctions lui-même. La vraie solution est bien entendu d'implémenter ce format CAN de transfert de données au sein même du noyau et c'est à cette tâche que se sont attelés des ingénieurs de la société Volkswagen. Les patchs implémentant la nouvelle infrastructure PF_CAN ont été réécrits plusieurs fois car les développeurs noyau et les ingénieurs automobiles viennent de deux mondes différents et ont eu des difficultés à communiquer.
Jonathan Corbet a demandé à l'auteur principal de PF_CAN de résumer ses problèmes: "Plusieurs développeurs de CAN avaient l'habitude des micro-contrôleurs et avaient des difficultés à comprendre l'approche orientée réseaux. D'un autre côté les gens des réseaux ont souvent trouvé le design de PF_CAN étrange et difficile à comprendre (pas d'adresses, pas vraiment de couches) par rapport aux autres protocoles. En conséquence, cela nous a pris plus d'un an de discussion sur la liste de diffusion socketcan avant de nous mettre d'accord sur l'architecture actuelle."
Naturellement, étant donné les cycles longs de l'industrie automobile, il va falloir attendre un certain temps avant de trouver du Linux+PF_CAN dans nos autos mais on ne peut que se féliciter de l'approche choisie par Volkswagen de collaborer avec le monde du libre au lieu de développer ses outils dans le secret et sous une licence propriétaire.
Les patchs permettant à l'outil LatencyTOP de fonctionner sont maintenant intégrés dans la branche principale du noyau Linux. Proposé par Arjan van de Ven en janvier, LatencyTOP est un programme en espace utilisateur qui mesure les temps de latence et des patchs noyau qui permettent d'annoter les diverses opérations du kernel pour pouvoir ensuite les compter. Ce sont ces patchs qui, après relectures, corrections et améliorations, font maintenant partie du noyau 2.6.25. Cet outil permet de présenter de façon très simple les processus en les classant par ordre décroissant de temps de latence (en millisecondes). Comme son prédécesseur PowerTOP, le nouvel outil LatencyTOP a déjà permis de détecter plusieurs situations de latences anormales et de corriger des bugs gênants.
Le noyau 2.6.25 permet de gérer l'utilisation de la mémoire dans des containers. Pour pouvoir exécuter des applications dans des boites virtuelles séparées, que l'on nomme "containers", la communauté Linux a choisi d'implémenter progressivement les diverses briques technologiques. Le noyau 2.6.25 apporte donc la capacité de gérer la quantité de mémoire qui est utilisée par chaque container en fixant des limites et en contrôlant l'usage de la mémoire par les applications qui s'exécutent dans le container. Bien entendu cette gestion s'effectue à l'aide de l'infrastructure générique "Control Group" qui a été introduite dans le noyau 2.6.24 (l'option est sélectionnable avec CONFIG_CGROUP_MEM_CONT). La syntaxe utilisée, bien expliquée dans la documentation fournie, est très simple puisque pour limiter à 400 Mo la mémoire utilisée par le groupe de contrôle 0 il suffit de faire un:
echo -n 400M > /cgroups/0/memory.limit_in_bytes
Avec cette gestion de la mémoire c'est une nouvelle partie de l'infrastructure globale des containers qui prend sa place dans le noyau.
Davide Libenzi, l'auteur du mécanisme de notification eventfd, a retravaillé l'API du l'appel système timerfd. Ce dernier avait été introduit dans le noyau 2.6.22 mais immédiatement désactivé dès le noyau suivant pour cause d'interface mal conçue. En effet, lors de l'écriture des pages man de cette interface, il est apparue que celle-ci pouvait poser des problèmes et qu'une désactivation/refonte était nécessaire. Cette désactivation visait à empêcher l'écriture de programmes se basant sur l'API fautive et de devoir ensuite vivre éternellement avec le nécessaire maintien de la compatibilité. Maintenant que l'API timerfd refondue est bien propre les utilisateurs sont de nouveau invités à utiliser sereinement timerfd. Selon Jonathan Corbet la morale de cette histoire est qu': « un des meilleurs moyens de trouver les problèmes d'une API consiste à tenter de la documenter complètement. Si la communauté du noyau Linux veut résoudre ce genre de choses à l'avenir elle ne devra plus accepter aucune nouvelle API sans une documentation complète. »
Outre les nouveautés décrites ci-dessus, une multitude d'autres nouveautés sont présentes dans ce noyau.
- La régulation thermique proposée par la norme ACPI 2.0 est dorénavant complètement implémentée dans le noyau 2.6.25. Cette interface permet de gérer, à l'aide de divers senseurs, des zones thermiques différentes au sein de la machine et de réguler finement leur température. Une documentation est disponible qui explique de façon détaillée toute cette machinerie complexe de la gestion des zones de températures par la norme ACPI.
- Le noyau 2.6.25 voit, pour la première fois, l'inclusion des pilotes 2D pour les cartes AMD Radeon de type R500.
- La mise en veille ou en hibernation des systèmes ayant une carte Intel i915 fonctionne désormais correctement.
- De nombreux pilotes OSS de cartes son (comme par exemple i810_audio ou via82cxxx_audio) ont été supprimés du noyau car ils ont été remplacés par des pilotes utilisant l'architecture ALSA.
- L'algorithme de chiffrement de flux proposé par Daniel J. Bernstein, Salsa20, est ajouté à la pile cryptographique du noyau. On note également l'inclusion de l'algorithme de compression de données LZO qui est conçu pour être particulièrement rapide lors de l'opération de décompression.
- Le protocole réseau ISATAP est maintenant intégré dans le noyau 2.6.25. ISATAP est un mécanisme de transition permettant de faciliter le passage à IPv6. Contrairement à 6over4 il ne nécessite pas que le réseau IPv4 sous-jacent supporte le multicast.
- Le travail de fusion des fichiers de la nouvelle branche arch/x86 continue (plus de 1200 changements depuis le noyau 2.6.24).
- Les exécutables de plus de 2 Go sont maintenant utilisables par le noyau.
- Après Ext3 et Ocfs2 c'est au tour du système de fichiers XFS de devenir compatible avec le nouvel appel système fallocate() ayant été décrit dans le compte-rendu du noyau 2.6.23.
- Le test des fonctions de mise en veille ou d'hibernation est rendu enfantin dans le nouveau noyau du fait de l'introduction d'une infrastructure spécialisée. Il suffit d'écrire différents mots clés dans /sys/power/pm_test pour déclencher des actions précises portant sur les processus ou les périphériques...etc. Cette infrastructure de test permettra d'améliorer rapidement ce qui reste à l'heure actuelle un des points faibles de Linux.
- Une nouvelle architecture fait son entrée dans le noyau. Il s'agit des processeurs Panasonic 32 bits de la série MN103 qui sont utilisés dans le monde de l'embarqué (lecteurs de disques, systèmes de navigation, machines à laver...etc).
- De même les SoC (System On Chip) de type Orion, qui sont largement présents dans les disques durs reliés par le réseau (network-attached storage), sont maintenant parfaitement gérés par le nouveau noyau 2.6.25. Cet article du site Linuxdevices fait le point sur la situation et liste les nombreux matériels utilisant la puce Orion.
- Dans la grande tradition libriste de support des matériels anciens on peut noter que le noyau 2.6.25 gère maintenant officiellement les lecteurs propriétaires GD-ROM présents dans les consoles de jeu Sega Dreamcast.
- Diverses fonctionnalités de sécurité issues de la branche exec-shield maintenue par Ingo Molnar font leur entrée dans le noyau officiel. On peut citer, pour l'architecture x86, la randomisation de la pile ou encore celle des exécutables. Comme cette mesure de sécurité empêche quelques vieux logiciels de fonctionner il faut explicitement décocher l'option CONFIG_COMPAT_BRK pour qu'elle soit effective.
La liste détaillant de nombreuses autres nouveautés (réseaux, systèmes de fichier, pilotes disques, cartes son, vidéo, Bluetooth, etc.) est disponible sur le site de Kernelnewbies. En revanche l'inclusion de KGDB, dont il avait un temps été question, semble s'être fracassée sur la résistance acharnée de Linus et son dédain pour les debogueurs intégrés au noyau.

Le site Linux Weekly News propose une analyse statistique faisant le point sur les multiples contributions durant le cycle du noyau 2.6.25.
Alors que les changements du noyau précédent étaient considérés comme inhabituellement nombreux il semble qu'il va falloir modifier nos critères de ce qui est normal et de ce qui ne l'est pas. En effet la tendance semble se poursuivre et même s'accélérer puisque le noyau 2.6.25 intègre plus de 12000 patchs écrits par 1174 développeurs différents (10000 patchs écrits par 950 développeurs pour le noyau 2.6.24 ce qui avait été qualifié de "monstrueux" par Linus).
Ce déluge de contributions est néanmoins relativisé par le léger allongement des délais entre les versions (ce qui mécaniquement augmente le nombre de patchs inclus dans chaque nouveau noyau).
En définitive le développement de Linux fonctionne donc à plein régime et l'organisation du travail mise en place permet d'intégrer rapidement toutes les nouveautés sans compromettre la stabilité et la fiabilité.
Mais la plus belle réussite est que le noyau: "incorpore le travail d'une communauté de plus en plus large de développeurs qui sont vraiment capables de travailler en coopération en dépit du fait que leurs employeurs sont en compétition acharnée. Il y a très peu de projets qui sont dans ce cas."

Pour la suite
En ce qui concerne les évolutions futures du noyau Linux on peut se tourner avec profit vers la page de prévisions maintenue par Jonathan Corbet.

L'outil de tracing de nouvelle génération utrace, destiné à remplacer le peu apprécié ptrace, a une nouvelle fois été retardé et n'a pu embarquer dans le noyau 2.6.25. Il reste des problèmes de gestion des verrous mais le travail continue vigoureusement car utrace serait un apport de qualité pour l'outil SystemTap (le concurrent du DTrace de Sun).
Pour continuer dans la problématique de traçage de l'activité du noyau, Mathieu Desnoyers a proposé plusieurs patchs pour intégration dans le nouveau noyau 2.6.26. Ces patchs permettent l'intégration de marqueurs statiques légers afin d'instrumenter le fonctionnement de Linux. Cette intégration reste néanmoins aléatoire depuis la forte opposition qu'a soulevé Ingo Molnar. Selon lui ces marqueurs n'ont de "légers" que le nom puisqu'ils induiraient un surcoût inacceptable (4 bytes per marker per fastpast is _NOT_ acceptable in any way). La discussion est ensuite devenue très technique entre Mathieu et Ingo mais cela augure mal de l'intégration rapide des marqueurs statiques dans le noyau.
Enfin le travail sur le système de fichier btrfs continue et la version 0.13 apporte de nombreuses optimisations de performances. Une première comparaison avec le système de fichiers XFS a été effectuée et les résultats semblent plus que prometteurs.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

Bel article

Posté par Mickaël Sibelle (page perso, ) le 17/04/2008 à 10:05. (lien). Évalué à 10.

Précis, équilibré et consis. Merci !

Cela me permet de savoir et comprendre ce qui se passe dans la vie du Noyal, en ne rentrant que ce qu'il faut dans la technique.
Je ne dois pas être le seul ;)

Bravo pour cet article !

[^]Re: Bel article

Posté par ethtezahl () le 17/04/2008 à 10:20. (lien). Évalué à 8.
Comme d'hab avec les articles de releases du noyau de patrick_g.

--
http://ethtezahl.over-blog.com/

http://www.grattadom.com

[^]Re: Bel article

Posté par Neilink () le 17/04/2008 à 10:20. (lien). Évalué à 6.
En effet, patrick_g tes articles sont excellents, merci !
A quel endroit est l'inscription au fan-club ? :)

[^]Re: Bel article

Posté par jon207 (Jabber id, page perso, ) le 17/04/2008 à 13:12. (lien). Évalué à 2.
+1

Superbe travail de patrick_g (et des dév du noyau aussi ^^). Clair, précis, concis, bref : parfait. Félicitations.

--
"La liberté ne peut être que toute la liberté ; un morceau de liberté n’est pas la liberté." -- Max Stirner

[^]Re: Bel article

Posté par Christophe Duparquet (page perso, ) le 21/04/2008 à 21:48. (lien). Évalué à 2.
Oui, merci pour cet article remarquable.

Juste une petite chose : sensor -> senseur capteur.

--
Christophe Duparquet
« J'ai pas Word, j'ai pas Windows, et j'ai pas la télé ! »

[^]Re: Bel article

Posté par snurpsss () le 23/04/2008 à 09:32. (lien). Évalué à 1.
idem

Article parfait.

Si LinuxFR offre toujours des cadeaux aux meilleurs redacteurs, j espere que patrick_g en recevra un.

Merci Patrick_g

Posté par Emilien Kia (Jabber id, page perso, ) le 17/04/2008 à 10:15. (lien). Évalué à 4.

Encore une fois un article complet, clair net et précis de Patrick_g pour la release du noyau.
Un seul mot : Merci !

--
Qu'est-ce qui est petit, rond et vert, qui monte et qui descend ?
Yoda qui fait le con avec la force.

[^]R: Merci Patrick_g

Posté par Stéphane Aulery () le 20/04/2008 à 15:35. (lien). Évalué à 2.
Je me joins à vous pour acclamer ce nouvel article de grande qualité.

Encore merci.

SMACK

Posté par IsNotGood () le 17/04/2008 à 10:19. (lien). Évalué à 6.

Dépêche impeccable.

Il n'y a qu'un truc qui m'énerve.

> Le module SMACK (Simplified Mandatory Access Control Kernel) a été ajouté au noyau 2.6.25 afin d'offrir une alternative simplifiée à SELinux.

Au lieux de "alternative simplifiée à SELinux", pourquoi pas un "système simple de protection" ?

> SELinux est un module très puissant mais il est malheureusement assez complexe à configurer et à gérer au quotidien.

Ceci est une sorte d'incompréhension de l'objectif de SELinux.
Maîtriser SeLinux est très très complexe. Mais pour l'utilisateur final et avec une bonne intégration de SeLinux ce n'est pas le cas.
Aujourd'hui il y a de nombreux utilisateurs avec SeLinux et ils n'y pensent quasiment jamais. Enfin c'est une très mauvaise idée de demander à l'utilisateur de bidouiller avec la sécurité.

> En dépit des efforts méritoires de ses promoteurs pour simplifier son utilisation au fil du temps

Ces efforts ne sont pas terminés.
Il y a SeLinux et les règles SeLinux. Fedora utilise les règles NSA qui sont les plus complètes et les plus fines (il y a aussi les règles mls pour le "workflow"). Elles sont complexes car le défit sécurité est complexe. Elles ne le sont pas d'elle même. Il y a un autre projet qui offre des règles simplifiées (désolé, j'ai oublié le nom de ce projet).
SMACK ne prétend pas simplifier SeLinux (et ses règles NSA). Il y a des choses qu'on peut faire avec SeLinux et qu'on ne fera jamais avec SMACK. SMACK a une autre approche, d'autres objectifs.

Au "désespoire" des développeurs SeLinux, SMACK a été intégré. Il faut donc se trainer LSM. M'enfin, il n'y a pas de problème bloquant SMACK qui est bien conçu (contrairement à AppArmor). Linus a fait un choix, techniquement son choix est irréprochable.

> Ces derniers ont exercé une pression afin qu'une solution plus simple apparaisse et SMACK est le résultat de cette pression.

Ces derniers qui ne doivent probablement pas utiliser SeLinux...
Et pression sur qui ?
SMACK n'est pas lié a des pressions. SeLinux n'existerait pas, il y aurait peut-être SMACK. La sortie de SMACK ne remet pas en cause SeLinux (et ses règles NSA).
SeLinux est un projet très ambitieux et il y a des trucs sucks encore. Mais ça s'arrange.

> Les développeurs de SELinux, qui étaient jusqu'à présent les seuls utilisateurs de l'infrastructure LSM, ont opposé une âpre résistance à l'inclusion de SMACK dans le noyau.

Je n'ai pas suivit en détail les discussions. Mais elles ne portaient sur des problèmes techniques qu'a SMACK. Mais plus globalement sur la gestion du projet Linux. Ce que fait SMACK, SeLinux peut le faire. SMACK fait donc un peu doublon avec SeLinux et c'est malheureux.

> Quand je verrai les spécialistes de la sécurité utiliser des arguments rationnels et se mettre d'accord sur un truc les choses changeront peut-être. Mais franchement je m'attends à ce que l'enfer gèle et que les cochons nichent dans les arbres avant que cela n'arrive. Mais bon, je peux toujours espérer.

Si j'ai bonne mémoire, c'était surtout par rapport à AppArmor vs SeLinux. Globalement SMACK et SeLinux pour les aspects techniques sont sur la même longueur d'onde et SMACK ne prétend pas remplacer SeLinux. L'auteur de SMACK a aussi dit qu'il bosserait sur SeLinux si LSM était abandonné.
Linus estime qu'il n'y a pas qu'une approche pour la sécurité et donc qu'il doit garder LSM.

> Toute cette controverse a fait l'objet d'un article détaillé du site Linux Weekly News.

Et la contreverse porte plus sur LSM que sur SMACK vs SeLinux. La contreverse est LSM.

[^]Re: SMACK

Posté par IsNotGood () le 17/04/2008 à 12:18. (lien). Évalué à 3.
> Aujourd'hui il y a de nombreux utilisateurs avec SeLinux et ils n'y pensent quasiment jamais.

Il y a quelques chiffres sur smolts depuis peu. Mais ils me sont pas très claires :
http://smolts.org/static/stats/stats.html (onglet selinux)
Disons qu'une bécane sur 4 a selinux en mode "enforcing".

> Il y a un autre projet qui offre des règles simplifiées (désolé, j'ai oublié le nom de ce projet).

C'est Seedit :
http://seedit.sourceforge.net/
- [^]Re: SMACK
  
  Posté par kowalsky () le 17/04/2008 à 13:37. (lien). Évalué à 6.
  Disons qu'une bécane sur 4 a selinux en mode "enforcing".
  
  Et 50%~ de désactivé.
  
  --
  You got the money, I got the soul.
- [^]Re: SMACK
  
  Posté par patrick_g (page perso, ) le 17/04/2008 à 13:52. (lien). Évalué à 8.
  >>> Il y a quelques chiffres sur smolts depuis peu. Mais ils me sont pas très claires :
  Disons qu'une bécane sur 4 a selinux en mode "enforcing".
  
  Une bécane sur 4 ayant smolt d'installé !
  Comme smolt est un outil Fedora et que Fedora pousse SELinux on ne peux pas dire que ce soit représentatif des machines Linux en général.
  - [^]Re: SMACK
    
    Posté par IsNotGood () le 17/04/2008 à 14:11. (lien). Évalué à 2.
    > Comme smolt est un outil Fedora et que Fedora pousse SELinux on ne peux pas dire que ce soit représentatif des machines Linux en général.
    
    Certe. Mais RHEL est la distribution entreprise la plus utilisée et elle a SeLinux activé par défaut (depuis RHEL 4). Pour un serveur, SeLinux ne va pas être désactivé à la légère. Donc il ne serait vraiment pas étonnant que plus de 80 % des RHEL aient SeLinux d'activé (et en mode enforcing). Et tout cas très probablement plus de 50 %.
    - [^]Re: SMACK
      
      Posté par IsNotGood () le 17/04/2008 à 14:19. (lien). Évalué à 3.
      En passant, SeLinux est très certainenement le système de sécurité le plus utilisé. Il a aussi sans problème la plus grosse communauté derrière lui et il est le plus perfectionné.
      Bref, il serait très hazardeux de qualifier SeLinux d'échec même s'il n'est pas sur 50 % des postes.
      Ce qui est dommage est que SeLinux demande un gros effort pour être exploitable dans une distribution. Cet effort il n'y a pratiquement que Red Hat/Fedora qui l'a fait. Les autres distributions ne sont pas dans un état qui permet d'avoir SeLinux activé par défaut. M'enfin, c'est aussi presque un choix des autres distributions.
      - [^]Re: SMACK
        
        Posté par patrick_g (page perso, ) le 17/04/2008 à 14:34. (lien). Évalué à 9.
        >>> En passant, SeLinux est très certainenement le système de sécurité le plus utilisé
        
        En passant c'était le seul système de sécurité disponible en mainline jusqu'à présent. Pas étonnant qu'il soit le plus utilisé ;-)
        
        >>> Bref, il serait très hazardeux de qualifier SeLinux d'échec
        
        Je n'ai jamais écrit ça et j'ai même pris grand soin de dire que SELinux était plus puissant et plus complet et que ses devs bossaient dur sur la simplification de son utilisation.
        Personne de dit que SELinux est un échec. Au contraire.
        
        [^]Re: SMACK
        
        Posté par IsNotGood () le 17/04/2008 à 15:21. (lien). Évalué à 2.
        > Je n'ai jamais écrit ça
        
        Oui.
        Ta dépêche est d'excellente qualité.
        Je trouvais dommage que tu insistes sur une sorte de combat entre Smack et SeLinux. Tu as probablement remarqué que SeLinux critique très peu Smack et qu'il est même bien jugé. On avait eu des critiques au vitriol pour AppArmor. Ce n'est absolument pas ça pour Smack. Ce qui montre bien que les critiques anti-AppArmor n'était pas un "tout sauf SeLinux".
        
        Enfin il ne faut pas croire que SeLinux est uniquement préoccupé par SeLinux. SeLinux est préoccupé par la sécurité sous Linux (où il reste encore beaucoup a faire dans le desktop). Si Red Hat (et d'autres) prend SeLinux, ce n'est pas pour SeLinux, mais pour avoir un bon niveau de sécurité sous Linux. Donc SeLinux, et plus largement ceux qui veulent un bon niveau de sécurité sous Linux, ne veulent pas de LSM car c'est très pénalisant. SeLinux n'est pas contre Smack. Ce dernier a été très peu critiqué (voire pas du tout). SeLinux est contre LSM (et depuis bien avant Smack ou que AppArmor devienne vaguement populaire).
        
        On a eu un SeLinux vs AppArmor et plus largement un "système de sécurité bien conçu" vs "système de sécurité qui veut seulement être populaire". On n'a pas de SeLinux vs Smack. Mais ta dépêche n'est presque que sous cet angle (pression, Smack car Selinux, etc). Je pense que c'est une erreur d'avoir présenté les choses sous cet angle.
        Ceci dit, je ne doute pas de ton honnèteté et je ne pense pas un instant que tu avais des arrières pensées "machiavéliques".
        
        [^]Re: SMACK
        
        Posté par patrick_g (page perso, ) le 17/04/2008 à 15:32. (lien). Évalué à 5.
        >>> Donc SeLinux, et plus largement ceux qui veulent un bon niveau de sécurité sous Linux, ne veulent pas de LSM car c'est très pénalisant.
        
        Sauf que Linus a décrété que LSM resterait dans le noyau car il pense que les devs spécialistes de sécurité ne sont jamais d'accord entre eux (et il a pas tort sur ce point).
        LSM est là pour permettre à différentes solutions de cohabiter.
        
        A noter qu'aujourd'hui un article sur TOMOYO est présent sur le site LWN.
        TOMOYO est, comme l'était AppArmor, basé sur le pathname ce qui va sans doute provoquer des hurlements du coté des devs SELinux. On verra bien ce qui va se passer pour l'inclusion en mainline ou pas.
        
        Je ne sais pas si tu est abonné à LWN alors je te colle un extrait :
        
        "Casey Schaufler's persistence finally resulted in the merging of the SMACK security module for 2.6.25; it is the only such module, other than SELinux, ever to get into the mainline. Now that SMACK has paved the way, talk of removing the LSM framework (which had been strongly vetoed by Linus in any case) has ended and the next security module should have an easier time of it.
        Linus has also decreed that pathname-based security modules are entirely acceptable for inclusion into the kernel."
        
        [^]Re: SMACK
        
        Posté par IsNotGood () le 17/04/2008 à 16:01. (lien). Évalué à 2.
        > Sauf que Linus a décrété que LSM resterait dans le noyau
        
        Et comme j'ai dit, si c'est pour avoir SeLinux et Smack, c'est techniquement logique. Ces derniers étant respectés par les experts en sécurité (et les experts SeLinux respectent Smack et vice versa). Dans une politique à long terme, c'est plus discutable (James Morris l'a très bien expliqué).
        
        > car il pense que les devs spécialistes de sécurité ne sont jamais d'accord entre eux
        
        Mais lesquels ?
        Ceux qui comme Linus s'y intéresse quasi jamais ?
        Linus a au moins le mérite de le reconnaitre. En passant Linus dit que SeLinux est la première chose qu'il vire sinon rien ne marche (selon lui) et ne manque pas une occasion pour critiquer SeLinux. Mais il a installé une F9 pour sa femme avec SeLinux activé (et en mode enforcing) sans s'en rendre compte...
        
        Quels experts en sécurité ?
        Ceux qui se proclament expert car ils trouvent l'interface graphique d'AppArmor séduisante ?
        
        Smack prouve que Linux a des vrais experts en sécurité. Pas des experts qui ne sont que pro SeLinux (ou que pro-AppArmor).
        
        > Linus has also decreed that pathname-based security modules are entirely acceptable for inclusion into the kernel.
        
        On peut trouver une tripoté de grand nom de Linux qui sont contre cette idée. Dont Alan Cox par exemple.
        Pour ma part je pense que Linus a manqué de courage en gardant LSM (c'est un demi reproche).
        Et actuellement, même si AppArmor a fait beaucoup de bruit, il n'y a pratiquement que SeLinux qui tient la roule : expertise, communauté, niveau d'utilisation/support par les distributions qui ont eux la volonté de l'utiliser (RHEL et Fedora ce n'est pas rien, et Ubuntu va peut-être y venir).
        Linus a décidé de laisser la compétition ouverte. M'enfin, pour les systèmes a usage général SeLinux a déjà quasi gagné. Smack sera peut-être utilisé pour l'embarqué et d'autres systèmes spécifiques.
        
        En passant, il serait bien d'éviter l'anti-SeLinux primaire. Je viens d'avoir l'impression que tout ce qui dérange SeLinux te fait plaisir...
        Je ne fais pas d'anti-Smack primaire. Par contre je suis clairement anti-AppArmor.
        
        [^]Re: SMACK
        
        Posté par patrick_g (page perso, ) le 17/04/2008 à 16:17. (lien). Évalué à 4.
        >>> En passant, il serait bien d'éviter l'anti-SeLinux primaire. Je viens d'avoir l'impression que tout ce qui dérange SeLinux te fait plaisir...
        
        Bof non je m'en fous je ne l'utilise pas. Maintenant si Debian/Ubuntu arrivent à l'intégrer et à en simplifier l'utlisation (en reprenant peut-être des outils RedHat) alors je l'utiliserai volontiers car c'est toujours bien d'avoir une machine mieux sécurisée.
        Ce qui m'a un peu étonné c'est l'attitude de James Morris sur la lkml qui donnait vraiment l'impression de vouloir barrer l'inclusion de tous les concurrents de SELinux. Je n'ai pas la moindre compétence pour juger techniquement ses arguments mais à le lire on se dit "Ce mec se bat pour sa chapelle ce qui me rend soupçonneux pour ses arguments".
        
        >>> Par contre je suis clairement anti-AppArmor.
        
        Est-ce que tu est assez calé techniquement pour vraiment juger de la qualité d'AppArmor ? A lire les articles sur le net on comprend qu'AppArmor est moins bien/moins sécurisé que SELinux...mais il est aussi beaucoup plus simple. Peut-être a-il sa place en tant que solution "pas parfaite mais bien suffisante pour la majorité des gens" ?
        Moi j'en sais rien donc je n'en pense rien. Je me contente de regarder les gens débattre.
        
        [^]Re: SMACK
        
        Posté par IsNotGood () le 17/04/2008 à 17:33. (lien). Évalué à 2.
        > Est-ce que tu est assez calé techniquement pour vraiment juger de la qualité d'AppArmor ?
        
        Non. Mais j'ai lu une série de 4 (ou 5) articles sur AppArmor (comparé à SeLinux). Des articles très techniques et parfaitement argumentés. J'ai la flemme de les chercher, désolé.
        
        > A lire les articles sur le net on comprend qu'AppArmor est moins bien/moins sécurisé que SELinux...mais il est aussi beaucoup plus simple.
        
        Ce n'est pas la simplicité de AppArmor qui m'énerve, c'est sa façon simpliste, voire marketing, de faire de la sécurité. Par exemple l'auto-apprentissage est de la connerie. Il implique une mauvaise pratique de la sécurité. C'est séduisant, mais c'est de la connerie.
        Unix (et donc Linux) a toujours été le développement de solution juste même si c'est long et difficile. Unix ne cède pas à la facilité comme peut le faire Windows (d'où les anti-virus, d'où les 50 000 options pour "sécuriser", etc).
        Avec AppArmor on cède à la facilité pour ne pas dire l'audimat. Cette dérive est inquiétante.
        
        > Peut-être a-il sa place en tant que solution "pas parfaite mais bien suffisante pour la majorité des gens" ?
        
        C'est non (sauf système spécifique avec un admin qui sait ce qu'il fait). Les protections Unix classiques, c'est "pas parfaite mais bien suffisante pour la majorité des gens" ? Mais dans ce cas, es-ce que les gens bidouilles avec les protections classiques où es-ce qu'il font confiance (dans la limite de ses capacité) aux protections classiques ?
        
        Ce n'est pas car on a un système de protection, que pour mieux se protéger le premier venu doit le bidouiller. Comme pour le système de protection classique, ce qui est fournit doit être OK et on n'a pas à y toucher sauf cas exceptionnel. Il est OK car des experts ont bossé dessus. SeLinux c'est parail. SeLinux (avec ses règles) est fait pour marcher de suite et sans bidouiller (sauf cas très particulier).
        
        Ce que fait AppArmor, c'est séduire les gens en disant "Vous allez sécuriser Votre système". Mais ce n'est pas de ça qu'a besoin Linux ni aucun système. Ce type de truc, c'est du Windows avec 50 000 options pour "sécuriser" + un abonnement à un anti-virus. Une fois que t'as installé ton anti-virus et fouillé toutes les options de IE, t'es super content, t'as sécurisé ta bécane. C'est flatteur. Que voit-on dans la pratique ? Ben que compter sur l'utilisateur pour sécuriser une bécane est une très mauvaise idée. Que c'est quelque chose seulement à la porté des admins dans ce scénario.
        
        C'est assurément flatteur de sécuriser sa bécane. Mais c'est trop compliqué et mieux vaut laisser ça à des spécialistes. Et dans ce cas, ces derniers ont besoin d'outils évolués afin qu'ils expriment toute leur compétence et non être limité par un outil ... limité/mal foutu.
        
        J'utilise SeLinux. Désolé, c'est trop fort. Ma bécane a SeLinux et je m'en fous. Je ne m'occupe pas de la sécurité, d'autres le font (SeLinux). C'est ceci qu'il faut pour la grande majorité des gens. Pas d'un outil pour faire "magiquement" de la sécurité.
        
        [^]Re: SMACK
        
        Posté par pasBill pasGates () le 21/04/2008 à 23:18. (lien). Évalué à 5.
        Ce n'est pas la simplicité de AppArmor qui m'énerve, c'est sa façon simpliste, voire marketing, de faire de la sécurité. Par exemple l'auto-apprentissage est de la connerie. Il implique une mauvaise pratique de la sécurité. C'est séduisant, mais c'est de la connerie.
        
        Dis moi mon cher, c'est quoi le probleme avec le mode d'auto-apprentissage de AppArmor ? C'est quoi la mauvaise pratique de securite la-dedans ?
        
        Ce n'est pas car on a un système de protection, que pour mieux se protéger le premier venu doit le bidouiller. Comme pour le système de protection classique, ce qui est fournit doit être OK et on n'a pas à y toucher sauf cas exceptionnel. Il est OK car des experts ont bossé dessus. SeLinux c'est parail. SeLinux (avec ses règles) est fait pour marcher de suite et sans bidouiller (sauf cas très particulier).
        
        Ca c'est sur, SELinux avec des regles minimales il n'y a pas besoin d'y toucher, il marche.
        Le probleme c'est qu'il ne couvrira que les softs pour lesquels il a des regles, et si tu veux etendre la couverture, ben faut le configurer.
        Et AppArmor c'est la meme chose, ce mode d'auto-apprentissage ne sert a rien d'autre que creer des profiles pour des softs qui n'en ont pas encore. Il y a un serveur contenant des profiles pour plein de softs, ce mode d'auto-apprentissage est la pour les softs qui n'en ont pas encore et sert a creer des profiles bien plus rapidement que si c'etait fait a la main uniquement.
        
        T'as une certaine habitude a avoir des positions tres tranchees, et il me semble que regulierement tu n'es pas en position de defendre ces positions par autre chose que l'utilisation de mots tels que "magique".
        Au hasard ton point de vue sur le modele de securite dans Windows, qui est pourtant absolument identique a celui dans Linux (a la difference pres qu'il y a des ACLs par defaut), mais que tu denigres constamment sans jamais pouvoir donner d'element technique.
        
        [^]Re: SMACK
        
        Posté par briaeros007 () le 22/04/2008 à 14:37. (lien). Évalué à 2.
        Au hasard ton point de vue sur le modele de securite dans Windows, qui est pourtant absolument identique a celui dans Linux (a la difference pres qu'il y a des ACLs par defaut),
        et moi qui croyais que justement il y avait plusieurs modèles de sécu dans linux (smack, selinux, apparmor, ...)
        
        --
        Subete ga wakatta toki…watashi ga anta wo korosu.
        
        [^]Re: SMACK
        
        Posté par Sytoka Modon (page perso, ) le 23/04/2008 à 22:51. (lien). Évalué à 5.
        > Au hasard ton point de vue sur le modele de securite dans Windows,
        > qui est pourtant absolument identique a celui dans Linux
        
        FAUX.
        
        Le modèle UNIX a des variables d'environnement attachées aux processus et qui s'hérite de père en fils, mais non l'inverse. Un fils ne peut influencer le fils d'un autre processus. Cette indépendance est fondamentale pour la stabilité et la simplicité de l'ensemble et c'est pourquoi je déteste gconf. Lorsque je modifie un paramêtre important, je préfère relancer les applications. En plus, cela n'arrive pas souvent.
        
        Sous Windows, les variables d'environnement sont globales par utilisateurs, voir pour le système. D'ailleurs, tout cela est stockée dans la base de registre qui est un énorme système de variable globale. C'est exactement ce que l'on déconseille à tout programmeur.
        
        Sous UNIX, root avait (c'est en train de changer) tous les pouvoirs, ce n'est pas le cas sous Windows. Sous Windows, le root ne peut pas faire un chown...
        
        Sous Windows, avec le système kerberos, on n'a pas de système équivalent a su, sudo... Bref de bit suid. Bilan, c'est une usine à gaz et une vrai daube lorsqu'on veut lancer en batch des choses sous un autre compte. Il suffit de voire le nombre de service qui tourne sous root sur un Windows pour voir l'échec de cette architecture de sécurité.
        
        Je ne parle pas du compte SYSTEM qui existe sans exister et dont les scripts .bat ont un comportement parfois plus qu'étrange...
        
        Alors oui, il y a des ACL sur les fichiers sous Windows et sous Linux. Ce n'est pas suffisant pour dire que la sécurité est basée sur le même modèle. Surtout qu'encore une fois, les ACL de Windows sont une telle usine à gaz qu'il y a tant de réglage possible que je n'ai pas encore rencontré une seule personne capable de faire des réglages beaucoup plus pointus que s'il y avait 4 ou 5 réglages possibles, comme sous UNIX ! La encore Windows à tuer les ACL avec leur complexité. D'ailleurs, lorsqu'on n'est pas en domaine, Microsoft a préféré les cacher aux utilisateurs, c'est tout dire.
        
        [^]Re: SMACK
        
        Posté par pasBill pasGates () le 24/04/2008 à 00:18. (lien). Évalué à 1.
        Le modèle UNIX a des variables d'environnement attachées aux processus et qui s'hérite de père en fils, mais non l'inverse. Un fils ne peut influencer le fils d'un autre processus. Cette indépendance est fondamentale pour la stabilité et la simplicité de l'ensemble et c'est pourquoi je déteste gconf. Lorsque je modifie un paramêtre important, je préfère relancer les applications. En plus, cela n'arrive pas souvent.
        
        Sous Windows, les variables d'environnement sont globales par utilisateurs, voir pour le système. D'ailleurs, tout cela est stockée dans la base de registre qui est un énorme système de variable globale. C'est exactement ce que l'on déconseille à tout programmeur.
        
        Tu as tout faux. http://msdn2.microsoft.com/en-us/library/ms682009.aspx
        
        Altering the environment variables of a child process during process creation is the only way one process can directly change the environment variables of another process. A process can never directly change the environment variables of another process that is not a child of that process.
        
        Sous UNIX, root avait (c'est en train de changer) tous les pouvoirs, ce n'est pas le cas sous Windows. Sous Windows, le root ne peut pas faire un chown...
        
        Faux encore, cf. http://support.microsoft.com/kb/308421
        
        Sous Windows, avec le système kerberos, on n'a pas de système équivalent a su, sudo... Bref de bit suid. Bilan, c'est une usine à gaz et une vrai daube lorsqu'on veut lancer en batch des choses sous un autre compte.
        
        Equivalent de su : runas.exe
        sudo il n'y a pas d'equivalent par defaut, mais ca existe separament
        
        Et tu m'expliqueras le rapport entre su et des services tournant sous root...
        
        Je ne parle pas du compte SYSTEM qui existe sans exister et dont les scripts .bat ont un comportement parfois plus qu'étrange...
        
        Perso, et au vu de ta meconnaissance du systeme, je pencherai pour une autre explication.
        
        Surtout qu'encore une fois, les ACL de Windows sont une telle usine à gaz qu'il y a tant de réglage possible que je n'ai pas encore rencontré une seule personne capable de faire des réglages beaucoup plus pointus que s'il y avait 4 ou 5 réglages possibles, comme sous UNIX ! La encore Windows à tuer les ACL avec leur complexité.
        
        Que tu ne les comprennes pas ne veut pas dire que personne ne les comprend. Il suffit de comprendre que les ACE sont executees dans l'ordre et que l'evaluation stoppe a la premier entree qui match pour comprendre comment ca fonctionne ,ca n'a rien de sorcier.
        
        D'ailleurs, lorsqu'on n'est pas en domaine, Microsoft a préféré les cacher aux utilisateurs, c'est tout dire.
        
        Effectivement, ca en dit long sur la finition de Windows pour le desktop, car ta grand-mere (et la mienne) n'ont aucune idee de ce qu'est une permission.
        Au passage, tu noteras que Windows XP Pro n'a pas cette configuration, c'est uniquement la version Home.
        
        Bref, je te conseille de lire le bouquin "Windows Internals" ...
        
        [^]Re: SMACK
        
        Posté par Sytoka Modon (page perso, ) le 24/04/2008 à 08:46. (lien). Évalué à 6.
        Sur les variables d'environnements, certes les modèles se ressemblent mais non les usages. En pratique sous Windows, elles sont stockés dans la base de registre et comme on lance dans 99% des cas des binaires, on utilise ces variables comme des variables globales. Il est vrai cependant que depuis quelques années, c'est mieux et un peu moins le zouk. Il y a encore peu, un sacré paquet de programme allait rajouter leur chemin dans la variable PATH par exemple.
        
        AU niveau des droits et de http://support.microsoft.com/kb/308421, c'est toi qui n'a pas compris à mon sens. En root, je peux faire sous UNIX
        
        chown toto:titi un_fichier
        
        Sous Windows, tu as le droit de t'approprier un fichier mais tu ne peux pas le rendre a son propriétaire. Windows a été conçu pour protéger les utilisateurs de l'administrateur. Ainsi, l'admin ne peut pas prendre un fichier que l'utilisateur ne veut pas qu'il prennne sans qu'il le sache (changement du propriétaire a sens unique).
        
        Pour su, tu me sors runas ! Cela n'a rien à voir, vas faire un runas sous admin pour lancer un executable sous le compte toto ! Cela ne marche pas car tu n'as pas le ticket kerberos. Tu es obligé d'avoir le mot de passe de toto. Comment tu fait pour avoir des services qui tournerait sur un parc de 100 machine sous un compte toto sans que celui-ci n'ai le même mot de passe, tu déploie comment ?
        
        Moi je dis que ne pas avoir de bit suid fait que c'est la merde. Bilan 99% des services tourne sous admin. On pourrait imaginer autre chose que le bit suid mais qui soit opérationnel simplement.
        
        > Et tu m'expliqueras le rapport entre su et des services tournant
        > sous root...
        
        Regardes les script d'init sous une debian et tu verras... Je veux lancer par exemple un service flexlm sous le compte matlab pour un serveur de licence matlab. Je fait comment sous Windows ? Et bien, dans 99% des cas, il tournera sous root. Sous linux, il tournera sous un compte qui ne sers qu'a cela,
        
        C'est pas que cela soit impossible à faire sous WIndows, c'est qu'en pratique, ce n'est pas fait car c'est une usine à gaz pour faire des choses simples.
        
        > Perso, et au vu de ta meconnaissance du systeme, je pencherai
        > pour une autre explication.
        
        Je viens de tomber sur un bogue bien étrange avec pskill.exe ! Et des spécialistes Windows autour de moi n'y comprennent rien ! Le compte SYSTEM n'est pas un vrai compte car il n'a pas de ruche... C'est toi qui est mauvaise langue, il y a des choses parfois bizarre lorsqu'on lance des choses sous SYSTEM à cause de cela. Mais lancer des trucs sous SYSTEM est une des seules méthodes pour les lancer sans avoir à stocker le mot de passe dans le registre...
        
        Au niveau des ACL, j'ai très bien compris comment cela marche et pour cause, je fait des ACL depuis des années sous UNIX. Je te dis que beaucoup de personnes sous Windows n'y comprennent rien, c'est différent. Le fait d'avoir mis une tripoté d'ACL fait qu'en pratique, c'est très peu utilisé. Il faut voir le nombre de logiciel qu'on installe et ou on est obligé d'aller bidouiller les ACL pour que cela marche pas lorsqu'on n'est pas admin.
        
        Tu vas me dire, les logiciels sont mal fait. Je te dis oui et c'est mal fait car le système d'ACL est trop complexe et que, n'ayant pas de sudo et de su correct, les dévelppeurs sont tous admin de leur poste. Bilan, c'est mal dévleloppé et cela, depuis des années... heureusement, les choses de ce coté là aussi sont moins pire qu'il y a quelques années.
        
        Enfin, sur la finition de XP, il n'y a pas d'onglet sécurité sur XP Pro ! Ce n'est que lorsque tu intègre XP pro en domaine que tout change et que tu te retrouves avec une interface comme 2000.
        
        Donc pas d'ACL pour l'utilisateur lambda s'il n'est pas en domaine...
        
        Pour tout cela, je continue de penser que le modèle de Microsoft est mal pensé car presque 10 ans après la sortie de 2000, c'est encore mal intégré par plein de développeur.
        
        [^]Re: SMACK
        
        Posté par pasBill pasGates () le 24/04/2008 à 21:29. (lien). Évalué à 1.
        Sous Windows, tu as le droit de t'approprier un fichier mais tu ne peux pas le rendre a son propriétaire. Windows a été conçu pour protéger les utilisateurs de l'administrateur. Ainsi, l'admin ne peut pas prendre un fichier que l'utilisateur ne veut pas qu'il prennne sans qu'il le sache (changement du propriétaire a sens unique).
        
        Sisi tu peux : http://wwwthep.physik.uni-mainz.de/~frink/chown/readme.html
        
        Pour su, tu me sors runas ! Cela n'a rien à voir, vas faire un runas sous admin pour lancer un executable sous le compte toto ! Cela ne marche pas car tu n'as pas le ticket kerberos. Tu es obligé d'avoir le mot de passe de toto. Comment tu fait pour avoir des services qui tournerait sur un parc de 100 machine sous un compte toto sans que celui-ci n'ai le même mot de passe, tu déploie comment ?
        
        Ah, j'ai mal compris ce que tu demandais effectivement.
        Ben tu crees un compte local sur chaque machine et tu generes le mot de passe de maniere aleatoire pour chaque machine, mot de passe que tu utilises quand tu specifies le compte sous lequel le service demarre. A faire une fois (assez simple a faire avec WMI) et c'est tout.
        Sinon, il y a deja les comptes LocalService et NetworkService que tu peux utiliser, la moitie des services sous Windows tournent avec un de ces 2 comptes, pas avec LocalSystem.
        
        Je viens de tomber sur un bogue bien étrange avec pskill.exe ! Et des spécialistes Windows autour de moi n'y comprennent rien ! Le compte SYSTEM n'est pas un vrai compte car il n'a pas de ruche... C'est toi qui est mauvaise langue, il y a des choses parfois bizarre lorsqu'on lance des choses sous SYSTEM à cause de cela. Mais lancer des trucs sous SYSTEM est une des seules méthodes pour les lancer sans avoir à stocker le mot de passe dans le registre...
        
        C'est quoi une ruche ?
        Sinon il y a les comptes LocalService et NetworkService qui sont fait pour ca hein.
        Quand au mot de passe , il est encrypte et accessible uniquement au systeme(si t'es admin tu peux l'avoir, mais si t'es admin tu peux faire ce que tu veux donc pas grave), bref si tu arrives la le lire, c'est que t'es deja admin sur la machine, pas tres utile.
        
        Sinon, c'est quoi le bug ?
        
        Tu vas me dire, les logiciels sont mal fait. Je te dis oui et c'est mal fait car le système d'ACL est trop complexe et que, n'ayant pas de sudo et de su correct, les dévelppeurs sont tous admin de leur poste. Bilan, c'est mal dévleloppé et cela, depuis des années... heureusement, les choses de ce coté là aussi sont moins pire qu'il y a quelques années..
        
        Desole mais sudo / su sont a peu pres inutiles pour le developpeur moyen, Visual Studio, un debuggeur, ... tournent sans probleme en user local, tu lances une console ou autre avec runas.exe, tu peux ensuite lancer tes softs en admin(ou autre) si necessaire, mais dans la plupart des cas(applis non-systeme) c'est totalement inutile car l'appli tourne en user local.
        
        Le probleme c'est que bcp de gens, y compris developpeurs, sont passes directement de Win9x a la lignee NT et ont amenes leurs habitudes avec eux. MS 'est mis a casser leurs habitudes avec UAC sur Vista, car leurs softs continuent de tourner mais il y a des pop-ups (voulez-vous autoriser xyz), et resultat les utilisateurs se plaignent aux developpeurs qui doivent fixer leurs softs.
        
        Enfin, sur la finition de XP, il n'y a pas d'onglet sécurité sur XP Pro ! Ce n'est que lorsque tu intègre XP pro en domaine que tout change et que tu te retrouves avec une interface comme 2000.
        
        Nope, il y a un bouton qui te demande si tu veux les permissions ou pas. Ma machine a la maison n'est pas dans un domaine, et j'ai mon tab de permissions avec les ACLs dedans.
        
        [^]Re: SMACK
        
        Posté par Sytoka Modon (page perso, ) le 25/04/2008 à 10:07. (lien). Évalué à 2.
        > Sisi tu peux :
        > http://wwwthep.physik.uni-mainz.de/~frink/chown/readme.html
        
        Je ne connaissais pas. Très bien même si cela n'a aps l'air tout jeune. Enfin, c'est pas très Microsoft comme solution...
        
        > C'est quoi une ruche ?
        
        Un bout de la base de registre.
        
        Mon bogue avec pskill, je fait un script .bat avec un
        
        pskill.exe -t -accepteula thunderbird;exe
        
        Juste avant d'installer ensuite la dernière version de celui-ci. Le script marche super en inetractif. Je le lance le script sous OCS avec la commande
        
        START /B /I mon_script.bat
        
        Et bien, cela ne marche pas. Le script ouvre une fenêtre au pskill et s'arrête dessus. J'ai essayer avec d'autre option de START et en mettant du START et du CMD devant pskill, mon script OCS ouvre toujours un fenêtre et se bloque dessus, soit au niveau de la commande pskill, soit à la fin de mon_script ! Je suis passé à la commande prcview (pv.exe) et la, cela marche.
        
        Bref, je ne sais pas ce qui se passe avec pskill et le compte sous lequel tourne l'agent OCS.
        
        Sinon, on niveau des comptes, effectivement tu peux créer des comptes avec des mots de passe par machine de manière automatique et un mot de passe de 200 caractères inviolable... ce que je vois en pratique, c'est que les développeurs ne le font pas.
        
        Je n'ai pas dis que la sécurité n'était pas possible sous Windows, je dis que comme c'est une usine à gaz, les personnes l'utilisent mal (en plus Microsoft ne nous aide pas car les outils en ligne de commande de bas niveau ne sont pas livré avec les versions de base du système, ce qui ne leur couterait rien). Du coup, comme tu le dis toi même, tous les services tournent sous le même compte...
        
        Effectivement, c'est une mauvaise tradition qu'on pris les développeurs et cela s'améliore avec le temps. Un développeur n'a pas besoin d'être admin du poste pour développer sauf s'il veut aller jusqu'au bout et faire l'empaquetage. Et a ce niveau là, pour tester, il doit être root donc il l'est en permanence. Tant qu'il n'y aura pas un équivalent de 'sudo' pour installer et supprimer un logiciel sous un compte normal, il y aura des soucis à ce niveau à mon sens.
        
        Enfin, je sais bien que sur un XP pro qui n'est pas en domaine, on peux faire apparaître l'onglet sécurité (mais que celui-ci apparait tout seul si on rentre en domaine). Combien de personne ont trouvé cette option, comme de personne l'on activé ?
        
        [^]Re: SMACK
        
        Posté par reno () le 20/04/2008 à 13:36. (lien). Évalué à 5.
        >Mais il a installé une F9 pour sa femme avec SeLinux activé (et en mode enforcing) sans s'en rendre compte...
        
        Sans s'en rendre compte, c'est vite dit: je me souviens d'un rapport d'erreur de Linus sur un problème d'affichage de vidéo qui était lié a une mauvaise interaction entre VLC et SELinux.
  - [^]Re: SMACK
    
    Posté par IsNotGood () le 17/04/2008 à 14:21. (lien). Évalué à 3.
    > Une bécane sur 4 ayant smolt d'installé !
    
    Zut, j'avais mal compris la remarque. Effectivement les stats de smolt ne conserne que Fedora (malheureusement). On peut le confirmer en regardant l'onglet "OS".
    J'aurais dû le préciser.
  - [^]Re: SMACK
    
    Posté par GeneralZod () le 17/04/2008 à 15:11. (lien). Évalué à 2.
    smolt était un outil Fedora (comme l'était PackageKit, Codeina, system-config-printer, etc ...), depuis sa conception, il est ouvert à toutes les distributions.
    Actuellement, smolt supporte OpenSuSE, Debian, Ubuntu, Archlinux, Frugalware et normalement toute distribution utilisant HAL.
    - [^]Re: SMACK
      
      Posté par IsNotGood () le 17/04/2008 à 16:04. (lien). Évalué à 3.
      Certes, mais même si les stats smolt sont pour toutes les distributions, force est de constater que Fedora y fait plus de 99,5 % des stats.
      Je le regrette bien.
      - [^]Re: SMACK
        
        Posté par arno () le 19/04/2008 à 02:32. (lien). Évalué à 1.
        J'aurais bien contribué a baisser la proportion de fedora mais pas moyen de trouver de doc sur l'installation de smolt. Non, franchement, yum ceci ou rpm celà ça ne sert pas à grand chose. C'est dommage de ne pas trouver cette information ni sur le wiki ni dans les sources.

[^]Re: SMACK

Posté par bubar () le 17/04/2008 à 14:22. (lien). Évalué à 2.
100% dakodak
Une fois son noyau recompilé avec SElinux en dur, plus besoin de lsm.
De plus, les outils graphiques de gestion de la configuration de Selinux permettent vraiment à tout le monde de """"s'amuser"""" simplement avec SElinux (je pense surtout aux types boleens, maitrisable par tous rapidement)

grosseur

Posté par FabienC () le 17/04/2008 à 10:30. (lien). Évalué à 5.

Je ne m'y connait pas assez en ce qui concerne les noyaux, mais une question me turlupine. Juste par curuiosité : à force d'avoir des diff de plusieurs Mo. est ce qu'à moyen terme on en risque pas de se retrouver avec un noyau trop lourd, imposant ? avec des fonctionnalité inutile à certains PC ?

[^]Re: grosseur

Posté par kowalsky () le 17/04/2008 à 10:42. (lien). Évalué à 10.
Si, mais tout n'est pas compilé pour tout le monde.

--
You got the money, I got the soul.

[^]Re: grosseur

Posté par Snarky (Jabber id, page perso, ) le 17/04/2008 à 10:57. (lien). Évalué à 4.
On te demande pas non plus de faire des noyaux monolithiques génériques.

--
Milite pour un about:black sur les navigateurs ! (Sauvons la planète)

[^]Re: grosseur

Posté par Anglade Pierre-Matthieu (page perso, ) le 17/04/2008 à 11:08. (lien). Évalué à 10.
1) Le diff est sur les sources du noyau. Ca n'est pas directement proportionnel à la taille d'un noyau compilé. Donc de ce coté pas d'inquiétudes.
2) Quand tu compiles ton noyau (ou quand les préparateurs de ta ditribution le font pour toi) tu peux choisir les choses qui seront incluse dans le noyau. Donc quelque soit la taille des diffs il est possible de fournir des noyaux de taille constante.
3) De nombreux éléments du noyaux (la plus part) peuvent être compilé sous forme de modules. Ils sont alors chargés en fonction de la machine utilisée et ne viennent pas alourdir le noyau de l'ensemble des utilisateurs. Ils prennent juste un peu de place dans ton arborescence de fichiers.
4) Le code de linux comporte effectivement de très nombreuses choses totalement inutilies sur un PC. En effet il supporte une très large variété de machine. Mais ça ne doit pas t'inquiéter puisque ce support existe essentiellement au niveau des sources (il ya probablement bien quelques conséquences dans la manière dont le noyau est programmé, pour que l'on puisse choisir l'architecture, mais ces choes sont assurément négligeables). Ensuite une fois le noyau préparé pour une machine donnée, par exemple ton PC, il ne reste plus grand choses (rien) destiné à le faire fonctionner sur DEC, PPC, ARM où autre plateforme un peu exotique.

--
PMA
- [^]Re: grosseur
  
  Posté par IsNotGood () le 17/04/2008 à 11:29. (lien). Évalué à 4.
  La majorité se retrouve en module. Les modules sont chargés si nécessaire.
  $ ll -h /boot/vmlinuz-2.6.24.4-64.fc8 -rw-r--r-- 1 root root 1,9M mar 29 14:30 /boot/vmlinuz-2.6.24.4-64.fc8 $ du -s /lib/modules/2.6.24.4-64.fc8/ 77960 /lib/modules/2.6.24.4-64.fc8/ $ find /lib/modules/2.6.24.4-64.fc8/ -iname "*.ko" -print | wc -l 1591 $ wc -l /proc/modules 84 /proc/modules
  
  J'utilise un peu plus de 5 % des modules disponibles. Ou plus de 94 % des modules ne me conserne pas (pour ma bécane).
- [^]Re: grosseur
  
  Posté par argt (page perso, ) le 17/04/2008 à 11:47. (lien). Évalué à 3.
  C'est vrai que ça n'implique pas que la taille du noyau augmente, mais je trouve que c'est quand même un (petit) problème que les sources soient de plus en plus grosses. Un coup d'oeil dans /usr/src/linux et je me rends compte que si je ne fais pas le ménage régulièrement, les sources prennent de la place.
  
  Par exemple, les sources, compressés en bzip2, du dernier noyau font 47 Mo. Les sources d'une des premières versions du noyau (2.4.20) que j'ai compilé, font 27Mo en bzip2. ça fait quand meme une augmentation de 47% en taille. C'est tout à fait logique vu le nombre de pilotes et de fonctionalités que contiennent les sources aujourd'hui, mais je trouve que c'est embetant sur des machines qui ont un (très) faible disque dur. Il me semble qu'il serait utile dans ces cas-ci de pouvoir télécharger des sources épurées des derniers pilotes, des pilotes exotiques, des parties nécessaires au debuggage etc...
  
  --
  Aaaaaaaaaaaaaaaaaaaaaaaaargt
  - [^]Re: grosseur
    
    Posté par IsNotGood () le 17/04/2008 à 12:00. (lien). Évalué à 3.
    Ben tu ne compiles pas sur ces bécances (ce qui t'économise la place des *-devel, gcc, etc).
    Autant réclamer que Linux tourne avec 640 Ko de mémoire...
  - [^]Re: grosseur
    
    Posté par Dinofly (page perso, ) le 17/04/2008 à 12:15. (lien). Évalué à 3.
    J'ai du mal à voir l'intérêt d'avoir les sources de Linux sur une machine ayant un si petit disque dur, tu as un exemple?
    
    --
    Je connais bien l'algèbre de Boole, et j'ai même vu tous ses flims.
    - [^]Re: grosseur
      
      Posté par argt (page perso, ) le 17/04/2008 à 13:58. (lien). Évalué à 4.
      J'ai un viel ordi avec un disque dur de 4Go. Il est équipé d'un proc à 600Mhz, d'une vielle carte vidéo et de 384Mo de ram, bref que de la récup. Il me sert de passerelle et j'ai branché aussi un viel écran dessus, car je trouve sympa parfois de pouvoir travailler avec 2 écrans.
      
      J'ai installée une distribution assez petite, mais meme ainsi, je me retrouve vite à cours de place et sauver quelques Mo par-ci par là est toujours le bienvenue. Bien sur, je pourrais acheter un plus gros disque, mais l'idée était d'avoir un pc pour 0 sous et donc je préfère bricoler.
      
      J'ai mis en place un environnement de cross-compilation (en fait c'est meme pas vraiment de la cross-compilation vu que les deux architectures sont les memes) vu les capacités de la machine, mais malheureseument, mon autre pc n'est pas sous la meme distribution (bon je sais je les accumule) donc je dois d'abord récupèrer les sources avec le vieux pc. Pour la compilation, je monte tout en nfs sur le pc plus récent mais tous les fichiers reste sur le vieux pc.
      
      Bref, je sais pertinemment que c'est un cas ultra spécifique et que ça ne doit pas concerner beaucoup de monde. Il y a certainement plein de manière de contourner le problème, mais c'est encore mieux quand il n'y a pas de problème.
      
      --
      Aaaaaaaaaaaaaaaaaaaaaaaaargt
      - [^]Re: grosseur
        
        Posté par zero heure (Jabber id, page perso, ) le 17/04/2008 à 22:36. (lien). Évalué à 6.
        Pour la compilation, je monte tout en nfs sur le pc plus récent mais tous les fichiers reste sur le vieux pc.
        
        c'est curieux, pourquoi pas l'inverse ?
        tu partage un dossier du nouveau pc via nfs, que tu monte sur ton vieux pc pour y déposer les sources
        
        --
        J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm
        
        [^]Re: grosseur
        
        Posté par argt (page perso, ) le 24/04/2008 à 21:41. (lien). Évalué à 2.
        parce que je récupère les sources via le logiciel qui gère les paquets de ma distribution, et que je n'ai pas trouvé (cherché) comment faire pour lui dire ne pas installer les sources dans /usr/src/linux
        Les deux ordis sont sur deux distributions différentes et les sources sont légèrements patchées dans les deux cas, ce qui expliquent le pourquoi du comment.
        
        Une solution serait de partager un dossier du nouveau pc en nfs, mais de le monter sur /usr/src/linux, avant de récupérer les sources.
        je ne vois pas de problème, je n'y avais juste jamais pensé avant maintenant.
        
        --
        Aaaaaaaaaaaaaaaaaaaaaaaaargt
  - [^]Re: grosseur
    
    Posté par Anglade Pierre-Matthieu (page perso, ) le 17/04/2008 à 13:39. (lien). Évalué à 5.
    Pour des machines très limiter en espace mémoire non volatil on utilise en général un processus de cross-compilation: tu prépares tes sources sur une bécane normal et tu les compiles à destination de ta platforme légère. Au final tu te retrouve avec un tout petit noyau Linux... Peut-être même que ça pourrait tourner sur 640 kO de mémoire. Qui sait ?
    
    --
    PMA
    - [^]Re: grosseur
      
      Posté par Guillaume Knispel () le 17/04/2008 à 14:38. (lien). Évalué à 4.
      Peut-être même que ça pourrait tourner sur 640 kO de mémoire. Qui sait ?
      
      Nan ça pourrait pas.
      - [^]Re: grosseur
        
        Posté par arno () le 19/04/2008 à 02:36. (lien). Évalué à 4.
        Et pourtant ça devrait : "640kb should be enough for everyone" (un homme célèbre)

[^]Re: grosseur

Posté par ouah (page perso, ) le 18/04/2008 à 09:43. (lien). Évalué à 6.
La remarque est assez judicieuse car hormis la prise de poids due aux nouvelles features et autres nouveaux matériels supportés, le noyau a une réelle tendance à prendre du gras. Cela pour des raisons de performances et de robustesse. Par exemple, l'ancien scheduler O(1) du 2.6 prenait 3x plus de place que le précédent scheduler!

N'oublions pas que le software aussi est soumis à la deuxième loi de la thermodynamique (augmentation de l'entropie).
- [^]Re: grosseur
  
  Posté par Anglade Pierre-Matthieu (page perso, ) le 19/04/2008 à 10:45. (lien). Évalué à 5.
  Sauf qu'on va avoir du mal à definir les échanges ou la création de chaleur pour le noyau. Alors l'entropie...
  
  Moi je verrais plutôt ça comme une logique d'ingénierie : Pour les petits systèmes on cherche toujours les algos avec les préfacteurs d'occupation des ressources les plus faibles. Pour les gros systèmes, au contraire, on préfère les algo dordre faible. En effet, qu'est ce que O(N⁹) quand N=1. Et comme linux est beaucoup plus orienté grosses bécanes (pentium II, K6 :-) que petit appareil photo, le choix semble logique. Surtout quand on voit le nombre de process que crées par défaut certains environnements de bureau.
  
  Cependant par rapport rapport à la remarque :
  « scheduler O(1) du 2.6 prenait 3x plus de place que le précédent scheduler » je me demande: il me semblait qu'en général on garde pas le choix des algos dans le noyaux à la compilation si l'un peut être préférer à l'autre dans certaines circonstances ?
  
  --
  PMA
  - [^]Re: grosseur
    
    Posté par rewind () le 21/04/2008 à 13:14. (lien). Évalué à 5.
    L'entropie n'est pas qu'une fonction de physique !
    
    En théorie de l'information, il y a aussi la notion d'entropie :
    http://fr.wikipedia.org/wiki/Entropie_de_Shannon
    - [^]Re: grosseur
      
      Posté par Anglade Pierre-Matthieu (page perso, ) le 21/04/2008 à 15:32. (lien). Évalué à 3.
      En considérant l'entropie au sens de Shannon, le post initiant la discussion sur l'entropie est faux où tout au moins contradictoire :
      - Le noyau serait plus gros pour faire la même chose (scheduler) -> diminution de l'entropie au sens de Shannon
      - Le post parle de la 2nd loi de la thermo : augmentation de l'entropie dans un système clos. Au sens de Shannon -> diminution de la taille du code compilé à fonctionalités constantes.
      Je crois que j'ai donc raison de considérer qu'il s'agissait de l'entropie restreinte à sons sens thermodynamique ;-)
      
      Par ailleurs j'ai lu avec beaucoup d'intérêt l'article de wikipedia ainsi que l'article de Myron_Tribus qui y est cité. C'est excellent. Il y a là matière à penser étant donné la complexité du sujet et surtout la variété des milieux scientifiques impliqués. Quelqu'un connaît-il des ouvrages de vulgarisation moderne à destination des profs de physique sur le sujet ?
      
      --
      PMA
    - [^]Re: grosseur
      
      Posté par argt (page perso, ) le 24/04/2008 à 21:36. (lien). Évalué à 3.
      il y a une notion d'entropie en géométrie riemmanienne qui est super à la mode en ce moment. C'est notamment gràce à elle que la conjecture de Poincaré n'est plus une conjecture mais un théorème. En gros, elle dit que si l'on part de certains espaces courbées et qu'on les transforme continuellement dans certaines directions alors, la courbure de ces espaces doit s'homogénéiser, c'est à dire que l'espace se rapproche d'une sphère.
      9 papiers sur 10 en ce moment en géométrie sont fondés sur cette notion d'entropie.
      Le rapport avec la physique ou la théorie de l'information ? Il y a vaguement une fonction de type -x log x qui se ballade dedans et il y a aussi le fait que le flot qui transforme l'espace courbée est similaire à une équation de la chaleur.
      Bref, pour des explications plus claires: http://fr.wikipedia.org/wiki/Flot_de_Ricci
      
      --
      Aaaaaaaaaaaaaaaaaaaaaaaaargt

temps réel

Posté par Farvardin (page perso, ) le 17/04/2008 à 10:53. (lien). Évalué à 9.

est-ce que les musiciens ici savent si les améliorations du côté temps réel / preempt ("Le noyau 2.6.25 introduit donc la possibilité de "préempter" le RCU") vont permettre de faire de la musique facilement sous linux, sans avoir besoin de recompiler un noyau spécifique avec des patch ou d'utiliser une distribution adaptée ?

--
You can't grep dead trees...

[^]Re: temps réel

Posté par bad sheep (page perso, ) le 17/04/2008 à 12:33. (lien). Évalué à 3.
C'est déjà le cas : à l'heure actuelle, sur une Ubuntu par exemple, il suffit d'installer un noyau RT au lieu d'un generic.

Sinon, il reste la solution du module realtime.

Articles précédents : Logiciel

Liens connexes

Dépêche modérée par

Dépêche éditée par

Logiciel : Le noyau Linux 2.6.25 est disponible

Bel article

[^]Re: Bel article

[^]Re: Bel article

[^]Re: Bel article

[^]Re: Bel article

[^]Re: Bel article

Merci Patrick_g

[^]R: Merci Patrick_g

SMACK

[^]Re: SMACK

[^]Re: SMACK

[^]Re: SMACK

[^]Re: SMACK

[^]Re: SMACK

[^]Re: SMACK

[^]Re: SMACK

[^]Re: SMACK

[^]Re: SMACK

[^]Re: SMACK

[^]Re: SMACK

[^]Re: SMACK

[^]Re: SMACK

[^]Re: SMACK

[^]Re: SMACK

[^]Re: SMACK

[^]Re: SMACK

[^]Re: SMACK

[^]Re: SMACK

[^]Re: SMACK

[^]Re: SMACK

[^]Re: SMACK

[^]Re: SMACK

[^]Re: SMACK

grosseur

[^]Re: grosseur

[^]Re: grosseur

[^]Re: grosseur

[^]Re: grosseur

[^]Re: grosseur

[^]Re: grosseur

[^]Re: grosseur

[^]Re: grosseur

[^]Re: grosseur

[^]Re: grosseur

[^]Re: grosseur

[^]Re: grosseur

[^]Re: grosseur

[^]Re: grosseur

[^]Re: grosseur

[^]Re: grosseur

[^]Re: grosseur

[^]Re: grosseur

temps réel

[^]Re: temps réel