Le noyau Linux 2.6.25 est disponible

Posté par patrick_g (site web personnel) le 17 avril 2008 à 11:35. Modéré par Pascal Terjan.

Étiquettes :

avr.

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 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.

Aller plus loin

Les nouveautés du noyau 2.6.25 (44 clics)
Le bilan des ajouts partie 1 (3 clics)
Le bilan des ajouts partie 2 (0 clic)
Le bilan des ajouts partie 3 (1 clic)
Les prévisions pour l'avenir de Linux (5 clics)

# Bel article

Posté par Mickaël Sibelle (site web personnel) le 17 avril 2008 à 12:05. É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 avril 2008 à 12:20. Évalué à 8.
  
  Comme d'hab avec les articles de releases du noyau de patrick_g.
- [^] # Re: Bel article
  
  Posté par Neilink le 17 avril 2008 à 12:20. É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 daemontux le 17 avril 2008 à 15:12. Évalué à 2.
  
  +1
  
  Superbe travail de patrick_g (et des dév du noyau aussi ^^). Clair, précis, concis, bref : parfait. Félicitations.
- [^] # Re: Bel article
  
  Posté par Christophe Duparquet (site web personnel) le 21 avril 2008 à 23:48. Évalué à 2.
  
  Oui, merci pour cet article remarquable.
  
  Juste une petite chose : sensor -> senseur capteur.
  « J'ai pas Word, j'ai pas Windows, et j'ai pas la télé ! »
- [^] # Re: Bel article
  
  Posté par snurpsss le 23 avril 2008 à 11:32. É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 Émilien Kia (site web personnel) le 17 avril 2008 à 12:15. É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 !
Un jour libre ?
- [^] # R: Merci Patrick_g
  
  Posté par Anonyme le 20 avril 2008 à 17:35. Évalué à 2.
  
  Je me joins à vous pour acclamer ce nouvel article de grande qualité.
  
  Encore merci.
# SMACK

Posté par IsNotGood le 17 avril 2008 à 12:19. É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 avril 2008 à 14:18. É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 avril 2008 à 15:37. Évalué à 6.
    
    Disons qu'une bécane sur 4 a selinux en mode "enforcing".
    
    Et 50%~ de désactivé.
  - [^] # Re: SMACK
    
    Posté par patrick_g (site web personnel) le 17 avril 2008 à 15:52. É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 avril 2008 à 16:11. É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 avril 2008 à 16:19. É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 (site web personnel) le 17 avril 2008 à 16:34. É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 avril 2008 à 17:21. É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 (site web personnel) le 17 avril 2008 à 17:32. É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 avril 2008 à 18:01. É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 (site web personnel) le 17 avril 2008 à 18:17. É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 avril 2008 à 19:33. É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 22 avril 2008 à 01:18. É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 avril 2008 à 16:37. É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, ...)
        
        [^] # Re: SMACK
        
        Posté par Sytoka Modon (site web personnel) le 24 avril 2008 à 00:51. É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 avril 2008 à 02:18. É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 (site web personnel) le 24 avril 2008 à 10:46. É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 avril 2008 à 23:29. É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 (site web personnel) le 25 avril 2008 à 12:07. É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 avril 2008 à 15:36. É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 avril 2008 à 16:21. É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 avril 2008 à 17:11. É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 avril 2008 à 18:04. É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 fusible le 19 avril 2008 à 04:32. É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🦥 (Mastodon) le 17 avril 2008 à 16:22. É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 avril 2008 à 12:30. É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 avril 2008 à 12:42. Évalué à 10.
  
  Si, mais tout n'est pas compilé pour tout le monde.
- [^] # Re: grosseur
  
  Posté par Snarky le 17 avril 2008 à 12:57. Évalué à 4.
  
  On te demande pas non plus de faire des noyaux monolithiques génériques.
- [^] # Re: grosseur
  
  Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 17 avril 2008 à 13:08. É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.
  « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
  - [^] # Re: grosseur
    
    Posté par IsNotGood le 17 avril 2008 à 13:29. É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 (site web personnel) le 17 avril 2008 à 13:47. É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...
    - [^] # Re: grosseur
      
      Posté par IsNotGood le 17 avril 2008 à 14:00. É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 (site web personnel) le 17 avril 2008 à 14:15. É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?
      - [^] # Re: grosseur
        
        Posté par argt (site web personnel) le 17 avril 2008 à 15:58. É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.
        
        [^] # Re: grosseur
        
        Posté par ZeroHeure le 18 avril 2008 à 00:36. É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
        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
        
        [^] # Re: grosseur
        
        Posté par argt (site web personnel) le 24 avril 2008 à 23:41. É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.
    - [^] # Re: grosseur
      
      Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 17 avril 2008 à 15:39. É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 ?
      « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
      - [^] # Re: grosseur
        
        Posté par Guillaume Knispel le 17 avril 2008 à 16:38. É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 fusible le 19 avril 2008 à 04:36. Évalué à 4.
        
        Et pourtant ça devrait : "640kb should be enough for everyone" (un homme célèbre)
- [^] # Re: grosseur
  
  Posté par ouah (site web personnel) le 18 avril 2008 à 11:43. É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 ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 19 avril 2008 à 12:45. É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 ?
    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
    - [^] # Re: grosseur
      
      Posté par rewind (Mastodon) le 21 avril 2008 à 15:14. É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 ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 21 avril 2008 à 17:32. É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 ?
        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
      - [^] # Re: grosseur
        
        Posté par argt (site web personnel) le 24 avril 2008 à 23:36. É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
# temps réel

Posté par B16F4RV4RD1N le 17 avril 2008 à 12:53. É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 ?
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
- [^] # Re: temps réel
  
  Posté par bad sheep (site web personnel) le 17 avril 2008 à 14:33. É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.
  - [^] # Re: temps réel
    
    Posté par bubar🦥 (Mastodon) le 17 avril 2008 à 16:20. Évalué à 5.
    
    Avbec Mandriva par exemple, il n' est pas nécessaire d' installer un noyau RT.
    Sur le noyau classique, Jack est heureux comme un poisson dans l' eau.
    
    Si tu le souhaites, tu peux
    urpmi kernl-rt-latest
    et les sources
    afin d' avoir un RT préparée pour ta distrib.
    
    Ceci n' a de sens, pour l' audio, que si tu es amené à utiliser Ardour avec 10 musiciens dans un studio, pour un enregistrement simultanée, chacuns dans leur propre box.
    - [^] # Re: temps réel
      
      Posté par Christophe Merlet (site web personnel) le 17 avril 2008 à 19:08. Évalué à 6.
      
      Je signale d'ailleurs que Linux est largement en avance sur Vista dans le domaine de la MAO.
      
      J'ai testé un clavier maitre MIDI sous Vista.
      Lorsque l'on joue de la musique en utilisant Anvil Studio et le synthetisuer intégré "Microsoft GS Wavetable Synth", non seulement Il y a un lag de presque une demi seconde, mais en plus le son est pourri. De plus, il n'y a AUCUNE interface pour configurer les périphériques MIDI sous VISTA.
      
      Sous Linux, Jack, Qsynth, une soundfont et c'est parti mon kiki !! Pas de lag et une tres bonne qualité de son.
      
      Malheureusement, les musiciens, c'est comme le reste de la population, il vont préférer rester sous XP plutot que de tenter Linux. Par contre, il sont pas pressé à migrer sous Vista... c'est toujours ça !
      - [^] # Re: temps réel
        
        Posté par B16F4RV4RD1N le 17 avril 2008 à 21:59. Évalué à 2.
        
        Dommage que ma Debian n'intègre pas tout cela... :(
        
        avec ardour et 2 pistes audio j'ai de la latence (je suis obligé de corriger la piste genre de 150 ms)
        Sous windows, avec audacity qui est pourtant moins optimisé qu'ardour, aucune latence (je ne parle même pas d'audacity sous linux, la catastrophe)
        
        Sous linux les synthés virtuels, idem, grosses latences.
        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
        
        [^] # Re: temps réel
        
        Posté par Jean-Michel Philippe (site web personnel) le 23 avril 2008 à 11:52. Évalué à 1.
        
        L'astuce avec Debian c'est d'utiliser le noyau temps réel d'une distribution MAO dérivée de Debian. J'avais fait ça sous Sarge avec Demudi du temps où elle existait encore. Avec Etch il y a 2 ou 3 distributions orientées MAO qui font l'affaire, dont UbuntuStudio et 64Studio. Il suffit de récupérer le *.deb du noyau, de l'installer et de vérifier qu'il apparaît dans /boot/grub/menu.lst. Ça évite d'avoir à patcher le source du noyau pour le recompiler. Sans le temps réel, c'est quasi impossible de faire de la MAO.
        
        Le seul problème que j'ai avec Etch est qu'en temps normal j'utilise Compiz sur carte nVidia, donc avec le pilote de chez nVidia. Et ce foutu pilote n'est pas capable de gérer plusieurs noyaux. Donc si je démarre sur le noyau temps réel, il faut que je change de pilote dans xorg.conf et que je désactive Compiz… La prochaine fois, je ne prendrai pas de carte nVidia !
      - [^] # Re: temps réel
        
        Posté par BAud (site web personnel) le 17 avril 2008 à 22:02. Évalué à 6.
        
        Malheureusement, les musiciens, c'est comme le reste de la population, il vont préférer rester sous XP
        Le site http://linuxmao.org pourrait pourtant les aider à faire la migration (outre la non disponibilité de pilotes corrects pour pas mal de produits sous vista...).
# Laver son linge

Posté par vincent_k (site web personnel) le 17 avril 2008 à 13:05. Évalué à 8.

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).
Cool !!! on va pouvoir laver son linge avec Linux, la lessive libre.
Le geekscotte :
http://www.nojhan.net/geekscottes/index.php?strip=77
- [^] # Re: Laver son linge
  
  Posté par fenril le 17 avril 2008 à 20:14. Évalué à 4.
  
  Tu ne crois pas si bien dire:
  http://www.bric-a-brac.org/humour/images/informatique/linux_(...)
  - [^] # Re: Laver son linge
    
    Posté par IsNotGood le 17 avril 2008 à 20:22. Évalué à 9.
    
    Adapté pour le multi-tache.
  - [^] # Re: Laver son linge
    
    Posté par vincent_k (site web personnel) le 17 avril 2008 à 21:00. Évalué à 0.
    
    Tu me prends pour un pain de six semaines ? :)
    - [^] # Re: Laver son linge
      
      Posté par dguihal le 18 avril 2008 à 10:53. Évalué à 4.
      
      s/pain/lapin/ autant que je la sache
  - [^] # Re: Laver son linge
    
    Posté par BAud (site web personnel) le 17 avril 2008 à 22:06. Évalué à 4.
    
    tu en trouveras encore plus sur http://folk.uio.no/hpv/linuxtoons/ (outre un baril de micro & soft)
- [^] # Re: Laver son linge
  
  Posté par Pierre Jarillon (site web personnel) le 18 avril 2008 à 04:54. Évalué à 4.
  
  Si Linux, c'est de la lessive, Unix est un extincteur espagnol : http://pjarillon.free.fr/docs/humour/unix-espagnol.jpg
  
  J'ai récupéré de ci et de là quelques sources de distraction. À vous de les compiler, elles sont dans le même répertoire.
# Les bonnes nouvelles:

Posté par liberforce (site web personnel) le 17 avril 2008 à 13:31. Évalué à 4.

Pour moi c'est l'intégration des statistiques d'utilisation mémoire qui fait à présent ce que exmap et exmap-console faisaient: http://labs.o-hand.com/exmap-console/
L'écriture d'un frontend graphique est devenue triviale, et il sera plus facile de comparer les chiffres d'utilisation mémoire.

Latencytop aussi est une bonne nouvelle: powertop avait déjà bien permis de trouver les points d'engorgement pour diminuer la consommation électrique. Latencytop en rajoute une couche pour encore améliorer les applications. La rapidité d'exécution des programmes étant très étroitement liée aux temps d'accès aux données, cela deviendra rapidement un outil indispensable.

Bref, que des bonnes nouvelles pour ce 2.6.25 !
- [^] # Re: Les bonnes nouvelles:
  
  Posté par gasche le 17 avril 2008 à 19:17. Évalué à 5.
  
  Oh oui, je vois d'ici les nouveaux trolls Qt/GTK Emacs/Vim KDE/Gnome KDE3/KDE4 (new !) Firefox/Konqueror/Epiphany sur la consommation mémoire.
  
  Ça sera peut-être utile aux développeurs, ou au moins tout à fait excitant.
# exécutables

Posté par jll_ le 17 avril 2008 à 13:47. Évalué à 9.

Les exécutables de plus de 2 Go sont maintenant utilisables par le noyau.

Le projet Kde a décidé de regrouper tout ces programmes en un seul binaire ?

[/tentative d'humour]
- [^] # Re: exécutables
  
  Posté par dguihal le 17 avril 2008 à 14:07. Évalué à 10.
  
  Complètement minable comme troll humoristique,
  
  t'aurais plus au moins penser à quelque chose de plus réaliste comme par exemple emacs
  
  ~~~~>[]
  - [^] # Re: exécutables
    
    Posté par B16F4RV4RD1N le 17 avril 2008 à 15:38. Évalué à 9.
    
    vous rigolez, vous rigolez, mais si cela se trouve bientôt gnome pourra se charger en module du noyau tellement ce projet devient dépouillé...
    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
    - [^] # Re: exécutables
      
      Posté par kowalsky le 17 avril 2008 à 15:53. Évalué à 10.
      
      ça c'est pour Gnome4.
      
      Gnome sera le premier Gestionnaire de Bureau en ligne de commande.
      Pour Gnome5, ils vont réduire le nombre de touche du clavier.
      - [^] # Enchères
        
        Posté par Jean B le 18 avril 2008 à 01:09. Évalué à 7.
        
        Gnome 6 est prévu uniquement pour l'Altair 8800..
        
        [^] # Re: Enchères
        
        Posté par wismerhill le 18 avril 2008 à 20:56. Évalué à 4.
        
        Et je vous offre en exclusivité le design épuré et hautement convivial du futur "Gnome Revolution"
        http://upload.wikimedia.org/wikipedia/commons/2/23/Bleistift(...)
        
        Enfin un environnement de bureau compréhensible par tous!
    - [^] # Re: exécutables
      
      Posté par liberforce (site web personnel) le 17 avril 2008 à 16:03. Évalué à 10.
      
      Vu ce que j'ai vu comme consommation mémoire de nautilus dans GNOME 2.22, je pense que je peux te rassurer, ce n'est pas près d'arriver...
  - [^] # Re: exécutables
    
    Posté par vincent_k (site web personnel) le 17 avril 2008 à 15:41. Évalué à -1.
    
    Mais admire la rigueur du code de EMACS, c'est pas comme Gnome.
- [^] # Re: exécutables
  
  Posté par Maclag le 17 avril 2008 à 17:24. Évalué à 5.
  
  Franchement n'importe quoi!
  
  Voilà à quoi ça va servir:
  - si on peut avoir un binaire plus gros, ça veut dire qu'on peut gérer des modules plus gros!
  - avec les progrès de la virtualisation, il faut voir ça de façon complètement différente:
  
  - un linux + module X11 + module openoffice
  - un linux + module X11 + module firefox
  - un linux + module X11 + module porte, bye! []
# Processus léger

Posté par LupusMic (site web personnel, Mastodon) le 17 avril 2008 à 16:27. Évalué à 2.

Je suis le seul a avoir longuement hésité avant de comprendre à quoi correspondait un « processus léger » ? Parce que bon, un thread, ce n'est pas un processus léger, pas plus qu'une brique n'est un mur...

Un « fil d'exécution » serait bien plus à propos.
- [^] # Re: Processus léger
  
  Posté par rewind (Mastodon) le 17 avril 2008 à 17:02. Évalué à 6.
  
  Non, les threads sont bien appelés processus légers en français à l'opposé des processus (lourds).
  
  En revanche, le terme de "verrou tournant" pour spinlock m'a surpris. Je ne connais pas le terme à utiliser mais j'aurais dit un truc du genre "verrou à attente active".
  - [^] # Re: Processus léger
    
    Posté par briaeros007 le 17 avril 2008 à 17:15. Évalué à 0.
    
    dans mes cours on parlait simplement d'"attente active".
    (parce que le spinlock en réalité est un verrou seulement parce qu'il attend).
- [^] # Re: Processus léger
  
  Posté par Fred BM le 17 avril 2008 à 18:37. Évalué à 3.
  
  Thread qui se traduit d'ailleurs en français par .... "Fil d'execution" ^^
  - [^] # Re: Processus léger
    
    Posté par olosta le 18 avril 2008 à 16:42. Évalué à 0.
    
    J'ai toujours trouvé cette traduction pourrie. comment comprenez vous "les fils du processus" ?
    
    Je verrais plutôt un truc du genre "flot d'exécution".
    - [^] # Re: Processus léger
      
      Posté par lasher le 20 avril 2008 à 05:41. Évalué à 1.
      
      Le problème avec "processus léger", c'est quand on se retrouve avec des bibliothèques à 2 niveaux. Genre les anciens threads sur Solaris.
      
      Ça donne :
      processus lourd -> processus léger ("thread noyau") -> flot d'exécution ("thread utilisateur" [1])
      
      [1] En pratique, un thread (au sens où la plupart des gens l'entendent) est effectivement un simple flot d'exécution.
# Faux ami

Posté par Sylvain Sauvage le 17 avril 2008 à 16:33. Évalué à 10.

s/label/étiquette/

Label, c’est pour les éditeurs musique ou (exclusif) la qualité.

(Et aussi s/...etc/, etc./ au passage.)
- [^] # Re: Faux ami
  
  Posté par patrick_g (site web personnel) le 17 avril 2008 à 17:01. Évalué à 5.
  
  >>> (Et aussi s/...etc/, etc./ au passage.)
  
  Je n'en croyais pas mes yeux mais Wikipedia te donne raison :
  "Cette expression n’a nullement besoin d’être répétée. Elle a le même sens que les points de suspension (…) : ils ne doivent donc pas être employés ensemble. Dans une énumération, etc. est nécessairement précédée d’une virgule."
  
  ça va être dur pour moi car je suis super habitué au "....etc"
  - [^] # Re: Faux ami
    
    Posté par benoar le 17 avril 2008 à 20:42. Évalué à 3.
    
    Mhhh, moi j'étais plus habitué au ", etc ..."
    Mais bon, les deux sont faux de toutes façons, je ne savais pas que ça avait la même signification que les points de suspension...
    - [^] # Re: Faux ami
      
      Posté par BAud (site web personnel) le 17 avril 2008 à 22:10. Évalué à 3.
      
      Ça veut surtout dire et caetera d'après le lien wikipedia Etc.
      Cela évite une virgule et trois petits points à la ligne, ... (<- à éviter on a dit... :p)
      - [^] # Re: Faux ami
        
        Posté par Sylvain Sauvage le 19 avril 2008 à 01:05. Évalué à 7.
        
        Pas de virgule avant les points de suspension. Sauf en maths dans les expressions du type 1, 2, …, n.
        
        Sinon, je n’ai rien contre les points de suspension, au contraire de etc. qui ne sert que pour les énumérations, les points de suspension servent à marquer n’importe quelle ellipse. Si vous voyez ce que je veux dire…
  - [^] # Re: Faux ami
    
    Posté par tiot (site web personnel) le 18 avril 2008 à 12:56. Évalué à 4.
    
    Tu as aussi parlé de « coeur » (prononcé coheur) au lieu de « cœur ». Le œ est sur alt-gr O ou à la place du ² .
  - [^] # Re: Faux ami
    
    Posté par Sylvain Sauvage le 19 avril 2008 à 01:09. Évalué à 8.
    
    Gnahaha ! Place manants ! C’est moi, celui qui vient d’apprendre quelque chose à patrick_g dans un de ses propres journaux ! Bon, ça n’a rien à voir avec le noyau. Et alors ?
    
    Plop ! … oups mes chevilles…
# Coder pour linux

Posté par Nicolas Boulay (site web personnel) le 17 avril 2008 à 16:36. Évalué à 8.

L'histoire de l'inclusion de la pile CAN me rappelle les problèmes que l'on a ici sur l'inclusion de chose dans Linux. Je me rappelle aussi les appels/voeux pieux de Linux concernant le fait d'intégrer de nouveau codeur plus gentiellement/facilement.

1 an, semble énorme pour beaucoup d'entreprise. J'ai lu un peu les threads d'échange pointé par les différentes articles.

So we have to be patient and i personally have to perform the task "It is therefore your responsibility to make the work interesting to the networking developers and fun to review." given by David Miller ...

But this task is hard to perform, when there's no feedback from the netdev guys and when it's not very interesting by design (of CAN) ;-( I have no idea when PF_CAN becomes that interesting to the major players like Patrik McHardy and David Miller, so that the code gets finally reviewed. I assume that is no sufficient answer for your question. Btw. i backed off for two weeks now and i'm patient.

J'aime particulièrement le passage ou il est dis que les nouveau venu doivent montrer du code intéressant pour être revu... J'imagine la tête des équipes soft avec ce genre de "requirement"....

J'ai vraiment l'impression qu'il y a une différence entre la volonté affiché d'intégrer et d'accueillir les nouveaux venu et la réalité. La réalité, c'est la liste des mainteneurs juste en dessous de Linus, qui décide réellement si votre sous-système est digne d'intérêt. Et si vous devez passer par plusieurs mainteneurs, vous êtres mal barré (au hasard: le mainteneur d'une sub-arch arm qui réfère au mainteneur arm qui réfère à Linus).

En gros, si la boite n'emploie pas un dev déjà reconnu au niveau de Linux, elle perd un temps fou pour son problème soit pris en compte ou son code revu.

En tout cas, cela n'encourage pas du tout à pousser sa boite à se mettre dans la boucle...
"La première sécurité est la liberté"
- [^] # Re: Coder pour linux
  
  Posté par IsNotGood le 17 avril 2008 à 17:34. Évalué à 3.
  
  En passant.
  
  De la dépêche :
  > c'est à cette tâche que se sont attelés des ingénieurs de la société Volkswagen.
  
  CAN est aussi utilisé par PSA et BMW. Je le sais car je l'ai vu.
  Mais probablement par beaucoup beaucoup d'autres pour ne pas dire tout le monde.
  Il y a un autre type de réseau qui marche une peu comme CAN, c'est le réseau VAN. Ce dernier n'est pas temps réel et selon mes derniers infos est utilisé par (seulement ?) PSA et Renault. Notons que PSA et Renault utilise CAN et VAN en même temps dans une voiture. CAN est pour le moteur, les trucs de sécurité, etc. VAN est pour le confort.
  L'industrie de l'automobile est énorme et si Linux s'y installe c'est formidable.
  - [^] # Re: Coder pour linux
    
    Posté par abramov_MS le 17 avril 2008 à 17:50. Évalué à 0.
    
    En tout cas il faut eviter les Ford vu que eux ils ont choisi Windows. De tout de facon avec la qualite et la consommation de cette marque on peut tout a fait utiliser l'expression: "Qui se ressemble, s'assemble!".
  - [^] # Re: Coder pour linux
    
    Posté par gpe le 17 avril 2008 à 19:30. Évalué à 1.
    
    Selon mes infos le VAN est en cours d'abandon même chez PSA au profit du CAN.
    - [^] # Re: Coder pour linux
      
      Posté par IsNotGood le 17 avril 2008 à 19:42. Évalué à 2.
      
      Ce n'est pas drame. J'imagine que CAN a aussi bien évolué. Je l'ai connu en 1998 :-)
  - [^] # Re: Coder pour linux
    
    Posté par vladislav askiparek le 18 avril 2008 à 21:53. Évalué à 3.
    
    Le CAN bus est aussi très utilisé dans l'automation industrielle.
    
    Et en automation, je sais qu'il existe des automates programmables (plutôt petits pc dédiés) qui tournent sous Linux, mais je n'ai jamais eu l'occasion d'en utiliser.
    J'ai par contre utilisé une marque concurrente qui n'utilise que win xp embeded, et bien comment dire... Ça plante, comme le pas embeded...
    Ha, la joie d'avoir un client qui attend impatiemment que sa machine toute neuve produise à 150% de rendement tout en regardant par dessus mon épaule pour constater que ce p...n de pc vient encore de se vautrer...
    
    http://www.linuxdevices.com/news/NS8034346535.html
- [^] # Re: Coder pour linux
  
  Posté par Zenitram (site web personnel) le 17 avril 2008 à 18:34. Évalué à 5.
  
  1 an, semble énorme pour beaucoup d'entreprise.
  Tu as déja essayé de proposer quelque chose pour Windows ou MacOS X?
  1 an, c'est rien pour une entreprise...
  
  Et si vous devez passer par plusieurs mainteneurs, vous êtres mal barré (au hasard: le mainteneur d'une sub-arch arm qui réfère au mainteneur arm qui réfère à Linus).
  Mais que proposes-tu à la place?
  Le noyau n'est pas un petit truc, et est utilisé par beaucoup de monde...
  Linux T. ne peux pas gérer >1000 développeurs.
  
  Pour info, en entreprise un chef à entre 5 et 20 personnes en dessous de lui (20, c'est déjà énorme!).
  Donc je ne vois pas ce qu'il y a de gênant pour une entreprise de devoir passer par x valideurs, ils ont l'habitude.
  
  En gros, si la boite n'emploie pas un dev déjà reconnu au niveau de Linux, elle perd un temps fou pour son problème soit pris en compte ou son code revu.
  Tu peux déja commencer par proposer un patch que tu maintiens toi-même, pour montrer qu'il est utile à plus de monde que toi-même.
  Et après, ca viendra avec le temps...
  
  Désolé, ce n'est pas rose certes, mais je ne vois pas de meilleure solution.
  C'est bien joli de critiquer, mais sans proposition (faisable hein) pour faire mieux, ça ne montre pas un réalisme...
  - [^] # Re: Coder pour linux
    
    Posté par abramov_MS le 17 avril 2008 à 19:06. Évalué à 4.
    
    ET oh il s'appelle LinuS avec un S pas un X. Ca fait plusieurs fois dans les commentaires sur une seule news que je vois l'erreur!
    - [^] # Re: Coder pour linux
      
      Posté par Zenitram (site web personnel) le 17 avril 2008 à 19:08. Évalué à 1.
      
      Arghhh... Les gens qui font ce genre d'erreur m'énervent un peu, c'est lourd qu'on prenne le droit de changer un prénom comme ça, et... je fais l'erreur.
      Arghhh... (bis)
  - [^] # Re: Coder pour linux
    
    Posté par Nicolas Boulay (site web personnel) le 17 avril 2008 à 20:37. Évalué à 3.
    
    "1 an, c'est rien pour une entreprise..."
    
    Tu me fais marrer (jaune) ! Et je bosse ou à ton avis dans mon garage ?
    
    Je bosse pour une boite pour qui 6 mois de plus est déjà trop, et la boite est énorme.
    
    Et après, ca viendra avec le temps...
    
    C'est bien ça le problème !
    
    Faire son truc dans son coin et balancer ce qui est fait en open source, c'est déjà fait. Mais il y a une perte en ligne monstrueuse sur les fonctionnalité par rapport à ce qui touche le kernel vanilia.
    
    Vu le niveau "générique" de ta réponse, je crois que tu es bien loin du dev kernel, et du dev dans une grosse boite qui aimerait avoir plus de code en mainstream.
    "La première sécurité est la liberté"
    - [^] # Re: Coder pour linux
      
      Posté par Zenitram (site web personnel) le 17 avril 2008 à 21:14. Évalué à 5.
      
      Et que proposes-tu pour que ton code soit intégré, tout en ne pourrissant pas le noyau avec le code de 10 000 autres gars comme toi qui veulent la même chose et qui font le truc crade car "pressé par Time-To-Market"?
      
      La critique est facile, mais ferais-tu mieux...
      La façon de faire actuelle a montré, elle, sa rentabilité.
    - [^] # Re: Coder pour linux
      
      Posté par pasBill pasGates le 20 avril 2008 à 09:39. Évalué à 7.
      
      Non il a raison, il n'y a rien de plus sensible qu'un kernel dans un OS. Tu ajoutes qqe chose qui parait insignifiant et hop tu te retrouves avec des perfs qui chutent dans des scenarios particuliers auquel tu n'as jamais pense mais qui sont courant dans certaines industries, des instabilites dues au manque de connaissance de certains concepts sur lesquels est base le kernel, ...
      
      C'est pas par hasard qu'un kernel bouge lentement et que les nouveautes cuisent pendant un moment avant d'etre autorisees partout, que ce soit dans le monde proprio ou OSS/libre
      
      Si on laissait le kernel etre dirige de la meme maniere que Gnome ou OpenOffice, tu te retrouverais regulierement avec un kernel de developpement qui plante ta machine, qui potentiellement te fait perdre tes donnees, ... et cela ralentirait le developpement tout en reduisant le nombre de testeurs car ils ne voudraient plus se retrouver si regulierement avec des problemes. Parce qu'avoir l'outil de configuration de Gnome qui explose c'est une chose, avoir ton kernel qui explose c'est autrement plus serieux.
      - [^] # Re: Coder pour linux
        
        Posté par Nicolas Boulay (site web personnel) le 21 avril 2008 à 02:18. Évalué à 3.
        
        Je comprends tout à fait les problèmes des dev de kernel. Mais sa réponse ne parlait pas vraiment de ça.
        
        De plus, le genre de code kernel dont tu parles est le coeur de Linux, pas vraiment les drivers par exemple. Or, c'est le plus gros du code.
        "La première sécurité est la liberté"
- [^] # Re: Coder pour linux
  
  Posté par gpe le 17 avril 2008 à 19:34. Évalué à 2.
  
  En gros, si la boite n'emploie pas un dev déjà reconnu au niveau de Linux, elle perd un temps fou pour son problème soit pris en compte ou son code revu.
  
  C'est exactement comme quand tu travailles avec un sous-traitant, tu n'accèdes pas directement au développeur, tu passes par un ou plusieurs niveaux de filtrage selon la taille du sous-traitant/fournisseur et ça n'a jamais empêché les boites de bosser. Je ne vois pas pourquoi ça serait différent dans ce cas ?
  - [^] # Re: Coder pour linux
    
    Posté par Nicolas Boulay (site web personnel) le 17 avril 2008 à 20:42. Évalué à 4.
    
    Parce que "l'autre" manière de travailler c'est de faire son patch dans son coin pour ses clients et ne pas perdre du temps à chercher à l'inclure.
    
    L'effort supplémentaire pour le faire inclure est souvent jugé hors de proportion et surtout ne respecte pas les planning des boites (même si je comprends que les mainteneurs s'en foutent).
    "La première sécurité est la liberté"
    - [^] # Re: Coder pour linux
      
      Posté par bertrand le 18 avril 2008 à 10:53. Évalué à 9.
      
      L'intérêt de faire inclure son patch, c'est aussi de refiler le bébé de l'adaptation aux versions successives du noyau à d'autres. On comprend que les autres exigent un niveau de qualité correcte.
      Pour l'entreprise c'est donc un investissement.
      Le problème c'est que pour beaucoup d'entreprise "la qualité", ne concerne pas le produit mais toute la paperasse lié au processus, à des normes ISO machin chose, ... Alors que pour le noyau la qualité ça concerne le code !
      - [^] # Re: Coder pour linux
        
        Posté par Nicolas Boulay (site web personnel) le 18 avril 2008 à 11:37. Évalué à 2.
        
        Je suis tout à fait d'accord, surtout avec ton dernier point :)
        
        Mais il y a des cas ou le premier point est moins vrai typiquement : le cas de CAN, ou les mainteneurs s'en foutent, ou le cas de hardware super complexe pour des gros drivers bas niveau, là il faut déjà avoir le matos et ensuite pourvoir comprendre la doc.
        "La première sécurité est la liberté"
        
        [^] # Re: Coder pour linux
        
        Posté par gpe le 18 avril 2008 à 15:46. Évalué à 1.
        
        Le monde de l'automobile intègre de plus en plus de systèmes informatiques complexes, aux mainteneurs de voir s'ils veulent abandonner ce secteur à Windows. Si la réponse est non ils ne vont pas se foutrent longtemps du CAN ...
        
        [^] # Re: Coder pour linux
        
        Posté par IsNotGood le 18 avril 2008 à 16:44. Évalué à 3.
        
        Il ne faut pas tout mélanger.
        Il y a aura (ou a déjà) des systèmes informatiques "lourds". Genre qui font lecture de DVD, etc.
        Mais il y a plein de système très léger et qui doivent le rester pour des raisons de fiabilité, de prix, de temps-réel, etc. Il est certain qu'un Windows ne va pas être utilisé dans ce cas.
        
        [^] # Re: Coder pour linux
        
        Posté par gpe le 19 avril 2008 à 05:29. Évalué à 1.
        
        Et en quoi j'ai dis le contraire?
        
        [^] # Re: Coder pour linux
        
        Posté par Guillaume Knispel le 20 avril 2008 à 01:05. Évalué à 6.
        
        En même temps des gens qui mettent Windows à toutes les sauces (même les plus inadaptées), ça existe. Même chose pour Linux d'ailleurs, sauf que ce dernier s'assaisonne plus facilement.
# Super article.

Posté par wr35nn89 le 17 avril 2008 à 16:54. Évalué à 1.

Merci pour cette synthèse.
# prochaine version avec suspend/hibernate qui fonctionne?

Posté par abramov_MS le 17 avril 2008 à 18:20. Évalué à 10.

Il semblerait que le boulot sur suspend et hibernate ait repris que, comme la demande Linus, les deux systemes vont etre separe.

D'ailleurs en cherchant plus d'info sur le sujet j'ai enfin compris pourquoi ACPI etait une un truc qui fonctionne super mal et bourre de probleme surtout sous Linux. Il a tout simplement ete fait dans cette optique!

Dixit Bill Gates:

It seems unfortunate if we do this work and get our partners to do the work and the result is that Linux works great without having to do the work

Maybe we can define the APIs so that they work weel with NT and not the others even if they are open. Or maybe we could patent something related to this.

http://antitrust.slated.org/www.iowaconsumercase.org/011607/(...)

Et apres ca il faudrait faire confiance aveugle a cette boite?

Au moins ca montre que c'est pas de hier que Redmond a les chocottes par rapport a Linux et que le coup du "meme pas dans le radar" etait un petit peu un enorme mensonge!
- [^] # Re: prochaine version avec suspend/hibernate qui fonctionne?
  
  Posté par patrick_g (site web personnel) le 17 avril 2008 à 18:26. Évalué à 10.
  
  Je trouve cet email de Gates absolument incroyable. Ce mec est vraiment une pourriture.
  - [^] # Re: prochaine version avec suspend/hibernate qui fonctionne?
    
    Posté par kowalsky le 17 avril 2008 à 18:56. Évalué à 3.
    
    ça a franchement l'air trop gros pour être vrai !
    - [^] # Re: prochaine version avec suspend/hibernate qui fonctionne?
      
      Posté par abramov_MS le 17 avril 2008 à 19:00. Évalué à 4.
      
      C'est clairement impressionnant. Je me demande quelles autres pepites nous reservent la lecture des autres documents du proces anti-trust.
      
      Ce n'est pas le premier email de ce style de la part de Billou, il en a ecrit exactement un equivalent sur les formats de documents d'ou le fait que je sois persuade que microsoft oxml ne pourra jamais etre implemente corectement dans aucune suite office libre.
  - [^] # Re: prochaine version avec suspend/hibernate qui fonctionne?
    
    Posté par IsNotGood le 17 avril 2008 à 19:37. Évalué à 3.
    
    > Ce mec est vraiment une pourriture.
    
    C'est pour ça qu'il affiche un visage mignon et souriant en permanence. C'est pour cacher sa nature.
    
    Ballmer doit aujourd'hui montrer le nouveau visage de MS (plus open et blablabla). Mais Ballmer n'est pas mieux que Gates.
  - [^] # Re: prochaine version avec suspend/hibernate qui fonctionne?
    
    Posté par B16F4RV4RD1N le 17 avril 2008 à 22:14. Évalué à 3.
    
    je n'irais pas jusque là. C'est son rôle. C'est windows qui est de la pourriture.
    
    Windows ne vit que grâce aux "pions" qui le font fonctionner, en particulier les développeurs indépendants, dixit l'ex chef de la propagande microsoftienne :
    http://www.computerworld.com/action/article.do?command=viewA(...)
    "So you can't win without them, and you have to take good care of them. You can't let them feel like they're pawns in the struggle."
    
    (et j'ajouterai : ses utilisateurs également)
    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
- [^] # Re: prochaine version avec suspend/hibernate qui fonctionne?
  
  Posté par arnaudus le 17 avril 2008 à 18:58. Évalué à 2.
  
  Rien à voir avec le fait que Bill Gates mériterait d'être %&/ avec une *¤% dans son ¤%& (bande d'obsédés, je suis sûr que vous avez pensé à un truc sexuel), mais avec evince je peux surligner le texte du pdf, alors que c'est le résultat d'un scan, sans aucun doute. Est-ce que l'information est déja dans le pdf, ou est-ce que Gnome a pris 27 ans d'avance technologique d'un coup?
  - [^] # Re: prochaine version avec suspend/hibernate qui fonctionne?
    
    Posté par Zenitram (site web personnel) le 17 avril 2008 à 19:00. Évalué à 2.
    
    C'est fait pendant le scan.
    Quand le scan est "limite", ben c'est comme pour un OCR de base : des fois le résultat est surprenant :)
    Mais c'est très très pratique!
  - [^] # Re: prochaine version avec suspend/hibernate qui fonctionne?
    
    Posté par seginus le 17 avril 2008 à 19:08. Évalué à 2.
    
    J'ai déjà vu cette fonctionnalité avec le format djvu.
    Dans le cas présent, je me suis dit que c'était peut-être tout simplement une lettre bidon écrite avec une police un peu fantaisiste.
    Cependant, le A par exemple n'apparaît pas partout pareil laissant présagé que c'est un réel scan (ce qui ne rend pas le document pour autant authentique).
    Cette fonctionnalité de rajouté le contenue du résultat d'un OCR dans le même format est-elle présente pour le PDF ?
- [^] # Re: prochaine version avec suspend/hibernate qui fonctionne?
  
  Posté par Nicolas Boulay (site web personnel) le 17 avril 2008 à 20:46. Évalué à 3.
  
  J'ai regardé quelques fonctions d'endormissement de certains drivers. Souvent ils sous-entendent uniquement du suspend-to-ram sans perte de l'état interne du périphérique. Ce qui est évidement absurde dans le cas du suspend to disk et pas franchement gagné pour le suspend to ram (ou tu coupes le jus de tout sauf la DDR qui est en auto refresh)
  
  Bref, il y a un gros soucis de sauvegarde et de restauration d'état dans beaucoup de drivers.
  "La première sécurité est la liberté"
  - [^] # Re: prochaine version avec suspend/hibernate qui fonctionne?
    
    Posté par IsNotGood le 17 avril 2008 à 20:51. Évalué à 2.
    
    > Souvent ils sous-entendent uniquement du suspend-to-ram sans perte de l'état interne du périphérique. Ce qui est évidement absurde dans le cas du suspend to disk
    
    J'y connais presque rien. Mais ce n'est pas forcément absurde si pour un hibernate Linux fait en premier suspend-to-ram (incomplet) puis un hibernate (qui va mettre sur disque ce qu'il y a en mémoire et donc l'état du périphérique).
    - [^] # Re: prochaine version avec suspend/hibernate qui fonctionne?
      
      Posté par Mildred (site web personnel) le 17 avril 2008 à 23:45. Évalué à 3.
      
      mais l'état interne du périphérique est il en RAM ? A mon avis il parlait de la mémoire interne au périphérique (qui n'est pas la RAM).
    - [^] # Re: prochaine version avec suspend/hibernate qui fonctionne?
      
      Posté par Raphaël G. (site web personnel) le 18 avril 2008 à 00:21. Évalué à 3.
      
      Le problème est que ça va marcher très bien pour les périphériques simplistes.
      
      Mais que se passera-t-il avec ta carte vidéo et ton jeux win32/wine en train d'utiliser ses fonctions 3D par exemple ?
      
      Ta carte 3D ne peux être considéré comme état dans le même état avant et après le power off !
      
      Tu as l'état de ses registres qui a pu changer (plein contre vide après le resume), sa ram, sans parler de choses importante comme la syncronisation de ses fréquences.
      
      En effet comment être sur que tu étais pas en vitesse économie d'énergie et a fond dans l'autre cas...
      
      Bref, il y a encore un sacré boulot là-dessus...
      
      Juste un exemple, mon asus laptop supporte a merveille le suspend to ram, en revanche l'hibernation + resume n'a jamais marché, donc j'ai laissé tombé.
  - [^] # Re: prochaine version avec suspend/hibernate qui fonctionne?
    
    Posté par M le 18 avril 2008 à 00:02. Évalué à 4.
    
    Bref, il y a un gros soucis de sauvegarde et de restauration d'état dans beaucoup de drivers.
    Encore faut il que ca soit possible : certains peripherique ne supporte pas simplement la sauvegarde/restoration de contexte en sauvant/restorant les registes.
    
    Il est parfois bien plus simple de faire un bon reset du controlleur et le reconfigurer.
    - [^] # Re: prochaine version avec suspend/hibernate qui fonctionne?
      
      Posté par Nicolas Boulay (site web personnel) le 18 avril 2008 à 12:38. Évalué à 1.
      
      Euh.... Fonctionelement c'est quoi la différence ?
      
      Au réveil, à l'appel de la fonction dédiées, le périphérique doit être dans le même état qu'avant que cela soit par copie recopie d'une plage de registre ou que cela soit par une phase d'init et de reconfiguration.
      
      Cela revient au même. L'état est sauvé en RAM et restaurer ensuite. Tous les périphériques passent de toutes façon par une phase de reset, le problème c'est que cela n'est pas forcément possible de reseter un module précis.
      "La première sécurité est la liberté"
      - [^] # Re: prochaine version avec suspend/hibernate qui fonctionne?
        
        Posté par M le 18 avril 2008 à 23:39. Évalué à 3.
        
        Euh.... Fonctionelement c'est quoi la différence ?
        Le périph a des états internes que tu ne connais pas, et que tu ne peux pas sauver en RAM.
        Tu es donc obligé de passer par une phase de reset et reconfiguration pour retomber sur tes pattes.
        
        [^] # Re: prochaine version avec suspend/hibernate qui fonctionne?
        
        Posté par Nicolas Boulay (site web personnel) le 19 avril 2008 à 14:32. Évalué à 1.
        
        Ce qui revient au même... L'origine de l'état change mais sinon, c'est la même chose.
        "La première sécurité est la liberté"
- [^] # Re: prochaine version avec suspend/hibernate qui fonctionne?
  
  Posté par M le 18 avril 2008 à 00:12. Évalué à 5.
  
  D'ailleurs en cherchant plus d'info sur le sujet j'ai enfin compris pourquoi ACPI etait une un truc qui fonctionne super mal et bourre de probleme surtout sous Linux. Il a tout simplement ete fait dans cette optique!
  
  Le gros pb de l'ACPI c'est que c'est du code proprio qui est écrit par les fabricants des chipsets des cartes mères.
  C'est du code fait à l'arrache, qui n'est testé que sous windows, et qui peut être compilé avec le compilo Microsoft (qui comme tout ses compilos ne suit pas les specs à la lettre).
  
  Pour certains truc les développeur Linux en sont rendu à copier le fonctionnement de Windows...
  
  Sinon à une époque Intel avait eu une grande idée (avec l'EFI ???) d'étendre ce mécanisme de code proprio interprété au code des drivers des composants de la carte mère.
  
  PS : tant que j'y suis, il parait que certaines stack réseau pour booter sur le réseau depuis le bios sont bien buggé. Le problème de fond est donc qu'avec la carte mère, on récupère du code proprio bas niveau tout pourris et sans specs.
- [^] # tuxonice
  
  Posté par jll_ le 20 avril 2008 à 14:30. Évalué à 4.
  
  La version pour le 2.6.25 n'est pas encore officiel mais on peut la trouver ici:
  
  http://user.it.uu.se/~mikpe/linux/patches/tuxonice/tuxonice-(...)
# sécurité

Posté par GNUtoo le 18 avril 2008 à 00:37. Évalué à 4.

namespace et cgroup continuent leurs inclusion dans le noyau...mais comment utilise t'on namespace dans cgroups?
quand je monte le cgroup avec l'option ns ça me donne ca:
je cree le cgroup ns(namespace)
# mount -t cgroup -o ns cpuset /dev/cgroup
# ls /dev/cgroup/
notify_on_release releasable release_agent tasks
# mkdir /dev/cgroup/restricted
la je sandbox un terminal
$ echo $$
8882
# echo 8882 >/dev/cgroup/restricted/tasks
ensuite je lance epiphany
ensuite dans le terminal soit disant sandboxe je peux voir epiphany...
$ ps -A | grep epiphany
8910 ? 00:00:01 epiphany

le problème est le suivant...j'aimerais sandboxer firefox et gnash pour augmenter encore plus ma sécurité(j'ai deja selinux,et les nouvelles options de sécurité présenté dans cette dépêche...mais pas sur tout les ordinateurs que "j'administre")
le problème est que j'aimerais avoir quelque chose du genre jail(FreeBSD),openVZ etc... d'inclus dans le noyau et ne pas dépendre de patch qui ne visent pas forcement le dernier noyau...(car je prefere avoir les toutes dernieres mises a jour et en cas de bug de sécurité c'est mieux car j'ai le patch tout de suite...)

sinon pour ceux que ca interesse les details des options de montage sont dans(ns etc...):
/usr/src/linux/include/linux/cgroup_subsys.h
- [^] # Re: sécurité
  
  Posté par bilboa le 18 avril 2008 à 20:47. Évalué à 3.
  
  RSBAC support les jails je lance firefox grosso-modo comme ca:
  
  rsbac_jail -i -M priority firefox
  
  et hop c'est sandboxé ;) (ca support aussi les namespaces)
  
  Ca ressemble aux jail de freebsd. Pour info c'est porté sur 2.6.25 depuis aujourd'hui dans le repository, donc ca n'est pas tellement en retard en fait sur le "mainline"
  
  Apriori ca n'est pas inclus dans le noyau a cause de LSM qu'ils ne desirent pas utiliser (pour des raisons similaires a celles evoqués par les dev SELinux)
# randomisation ?

Posté par Denis Montjoie (site web personnel) le 19 avril 2008 à 13:40. Évalué à 5.

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.

Ce sont les mêmes types de randomisation que offrent grsecurity/pax ?

Suivre le flux des commentaires

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