Logiciel : Le noyau Linux 2.6.25 est disponible
Posté par patrick_g (page perso, ). Modéré le 17 avril 2008.
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.
![[en]](../images/en.png)
Les nouveautés du noyau 2.6.25 (3384 hits)-
Le bilan des ajouts partie 1 (508 hits)
-
Le bilan des ajouts partie 2 (325 hits)
-
Le bilan des ajouts partie 3 (331 hits)
-
Les prévisions pour l'avenir de Linux (1172 hits)
> Lire la dépêche (134 commentaires, moyenne: 4,1).
Vous avez demandé le commentaire #923502.
Run by 
Cette page a été générée par Templeet en 0.0779s (dont 0.0072 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
grosseur
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
Si, mais tout n'est pas compilé pour tout le monde.
You got the money, I got the soul.
[^]Re: grosseur
On te demande pas non plus de faire des noyaux monolithiques génériques.
Milite pour un about:black sur les navigateurs ! (Sauvons la planète)
[^]Re: grosseur
1) Le diff est sur les sources du noyau. Ca n'est pas directement proportionnel à la taille d'un noyau compilé. Donc de ce coté pas d'inquiétudes.
2) Quand tu compiles ton noyau (ou quand les préparateurs de ta ditribution le font pour toi) tu peux choisir les choses qui seront incluse dans le noyau. Donc quelque soit la taille des diffs il est possible de fournir des noyaux de taille constante.
3) De nombreux éléments du noyaux (la plus part) peuvent être compilé sous forme de modules. Ils sont alors chargés en fonction de la machine utilisée et ne viennent pas alourdir le noyau de l'ensemble des utilisateurs. Ils prennent juste un peu de place dans ton arborescence de fichiers.
4) Le code de linux comporte effectivement de très nombreuses choses totalement inutilies sur un PC. En effet il supporte une très large variété de machine. Mais ça ne doit pas t'inquiéter puisque ce support existe essentiellement au niveau des sources (il ya probablement bien quelques conséquences dans la manière dont le noyau est programmé, pour que l'on puisse choisir l'architecture, mais ces choes sont assurément négligeables). Ensuite une fois le noyau préparé pour une machine donnée, par exemple ton PC, il ne reste plus grand choses (rien) destiné à le faire fonctionner sur DEC, PPC, ARM où autre plateforme un peu exotique.
PMA
[^]Re: grosseur
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
C'est vrai que ça n'implique pas que la taille du noyau augmente, mais je trouve que c'est quand même un (petit) problème que les sources soient de plus en plus grosses. Un coup d'oeil dans /usr/src/linux et je me rends compte que si je ne fais pas le ménage régulièrement, les sources prennent de la place.
Par exemple, les sources, compressés en bzip2, du dernier noyau font 47 Mo. Les sources d'une des premières versions du noyau (2.4.20) que j'ai compilé, font 27Mo en bzip2. ça fait quand meme une augmentation de 47% en taille. C'est tout à fait logique vu le nombre de pilotes et de fonctionalités que contiennent les sources aujourd'hui, mais je trouve que c'est embetant sur des machines qui ont un (très) faible disque dur. Il me semble qu'il serait utile dans ces cas-ci de pouvoir télécharger des sources épurées des derniers pilotes, des pilotes exotiques, des parties nécessaires au debuggage etc...
Aaaaaaaaaaaaaaaaaaaaaaaaargt
[^]Re: grosseur
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
J'ai du mal à voir l'intérêt d'avoir les sources de Linux sur une machine ayant un si petit disque dur, tu as un exemple?
Je connais bien l'algèbre de Boole, et j'ai même vu tous ses flims.
[^]Re: grosseur
J'ai un viel ordi avec un disque dur de 4Go. Il est équipé d'un proc à 600Mhz, d'une vielle carte vidéo et de 384Mo de ram, bref que de la récup. Il me sert de passerelle et j'ai branché aussi un viel écran dessus, car je trouve sympa parfois de pouvoir travailler avec 2 écrans.
J'ai installée une distribution assez petite, mais meme ainsi, je me retrouve vite à cours de place et sauver quelques Mo par-ci par là est toujours le bienvenue. Bien sur, je pourrais acheter un plus gros disque, mais l'idée était d'avoir un pc pour 0 sous et donc je préfère bricoler.
J'ai mis en place un environnement de cross-compilation (en fait c'est meme pas vraiment de la cross-compilation vu que les deux architectures sont les memes) vu les capacités de la machine, mais malheureseument, mon autre pc n'est pas sous la meme distribution (bon je sais je les accumule) donc je dois d'abord récupèrer les sources avec le vieux pc. Pour la compilation, je monte tout en nfs sur le pc plus récent mais tous les fichiers reste sur le vieux pc.
Bref, je sais pertinemment que c'est un cas ultra spécifique et que ça ne doit pas concerner beaucoup de monde. Il y a certainement plein de manière de contourner le problème, mais c'est encore mieux quand il n'y a pas de problème.
Aaaaaaaaaaaaaaaaaaaaaaaaargt
[^]Re: grosseur
Pour la compilation, je monte tout en nfs sur le pc plus récent mais tous les fichiers reste sur le vieux pc.
c'est curieux, pourquoi pas l'inverse ?
tu partage un dossier du nouveau pc via nfs, que tu monte sur ton vieux pc pour y déposer les sources
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm
[^]Re: grosseur
parce que je récupère les sources via le logiciel qui gère les paquets de ma distribution, et que je n'ai pas trouvé (cherché) comment faire pour lui dire ne pas installer les sources dans /usr/src/linux
Les deux ordis sont sur deux distributions différentes et les sources sont légèrements patchées dans les deux cas, ce qui expliquent le pourquoi du comment.
Une solution serait de partager un dossier du nouveau pc en nfs, mais de le monter sur /usr/src/linux, avant de récupérer les sources.
je ne vois pas de problème, je n'y avais juste jamais pensé avant maintenant.
Aaaaaaaaaaaaaaaaaaaaaaaaargt
[^]Re: grosseur
Pour des machines très limiter en espace mémoire non volatil on utilise en général un processus de cross-compilation: tu prépares tes sources sur une bécane normal et tu les compiles à destination de ta platforme légère. Au final tu te retrouve avec un tout petit noyau Linux... Peut-être même que ça pourrait tourner sur 640 kO de mémoire. Qui sait ?
PMA
[^]Re: grosseur
Peut-être même que ça pourrait tourner sur 640 kO de mémoire. Qui sait ?
Nan ça pourrait pas.
[^]Re: grosseur
Et pourtant ça devrait : "640kb should be enough for everyone" (un homme célèbre)
[^]Re: grosseur
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
Sauf qu'on va avoir du mal à definir les échanges ou la création de chaleur pour le noyau. Alors l'entropie...
Moi je verrais plutôt ça comme une logique d'ingénierie : Pour les petits systèmes on cherche toujours les algos avec les préfacteurs d'occupation des ressources les plus faibles. Pour les gros systèmes, au contraire, on préfère les algo dordre faible. En effet, qu'est ce que O(N⁹) quand N=1. Et comme linux est beaucoup plus orienté grosses bécanes (pentium II, K6 :-) que petit appareil photo, le choix semble logique. Surtout quand on voit le nombre de process que crées par défaut certains environnements de bureau.
Cependant par rapport rapport à la remarque :
« scheduler O(1) du 2.6 prenait 3x plus de place que le précédent scheduler » je me demande: il me semblait qu'en général on garde pas le choix des algos dans le noyaux à la compilation si l'un peut être préférer à l'autre dans certaines circonstances ?
PMA
[^]Re: grosseur
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
En considérant l'entropie au sens de Shannon, le post initiant la discussion sur l'entropie est faux où tout au moins contradictoire :
- Le noyau serait plus gros pour faire la même chose (scheduler) -> diminution de l'entropie au sens de Shannon
- Le post parle de la 2nd loi de la thermo : augmentation de l'entropie dans un système clos. Au sens de Shannon -> diminution de la taille du code compilé à fonctionalités constantes.
Je crois que j'ai donc raison de considérer qu'il s'agissait de l'entropie restreinte à sons sens thermodynamique ;-)
Par ailleurs j'ai lu avec beaucoup d'intérêt l'article de wikipedia ainsi que l'article de Myron_Tribus qui y est cité. C'est excellent. Il y a là matière à penser étant donné la complexité du sujet et surtout la variété des milieux scientifiques impliqués. Quelqu'un connaît-il des ouvrages de vulgarisation moderne à destination des profs de physique sur le sujet ?
PMA
[^]Re: grosseur
il y a une notion d'entropie en géométrie riemmanienne qui est super à la mode en ce moment. C'est notamment gràce à elle que la conjecture de Poincaré n'est plus une conjecture mais un théorème. En gros, elle dit que si l'on part de certains espaces courbées et qu'on les transforme continuellement dans certaines directions alors, la courbure de ces espaces doit s'homogénéiser, c'est à dire que l'espace se rapproche d'une sphère.
9 papiers sur 10 en ce moment en géométrie sont fondés sur cette notion d'entropie.
Le rapport avec la physique ou la théorie de l'information ? Il y a vaguement une fonction de type -x log x qui se ballade dedans et il y a aussi le fait que le flot qui transforme l'espace courbée est similaire à une équation de la chaleur.
Bref, pour des explications plus claires: http://fr.wikipedia.org/wiki/Flot_de_Ricci
Aaaaaaaaaaaaaaaaaaaaaaaaargt