Après de multiples tentatives d’optimisation de mon kernel, je continue à trouver mon /boot/initrd.img lourd. La taille diminue seulement de 0,3Mb après “optimisation” par rapport au noyau standard, ce qui m’amène à 6,6Mb.
Je n’ai pas l’impression que ça ait déjà été débattu, donc je lance le sondage : quelle est la taille de votre /boot/initrd.img ?
Et si quelqu’un sait à quoi on doit s’attendre comme taille pour un noyau supposé optimisé, je suis tout ouïe.
Salut,
Sachant qu’un noyau ne dure que quelques jours si l’on veut qu’il soit à la pointe du progrès, faut-il optimiser sa taille à tout prix. La durée d’une compilation peut-elle être amortie en quelques jours ou même quelques semaines ?
Effectivement, je compile beaucoup plus dans un but ludique qu’utilitaire. Je m’étais fixé de passer sous la barre des 64Mb de RAM une fois X démarré, et j’ai juste “tout” fait pour y arriver. Le gain de RAM et de temps de boot est cependant immensément plus significatif en s’occupant de la séquence de boot que du kernel, comme il a déjà été souligné plusieurs fois.
Non, là c’est juste que j’ai aucune valeur de référence pour me faire une idée, donc je voulais connaître un peu vos valeurs, et si quelqu’un a une idée précise des valeurs théoriques attendues, ça m’intéresse pédagogiquement 
Bonjour,
Je n’ai pas optimisé mon noyau et je n’ai rien fait de special, mais là avec X démarré, un navigateur, un terminal et htop, je suis à 57Mb. 
Oui, je sais bien qu’on peut toujours descendre. Virer Openbox pour dwm, diminuer le nombre de services, … Mais pour moi ça représenterait des sacrifices et c’est pas le but non plus.
[quote=“ggoodluck47”]Salut,
Sachant qu’un noyau ne dure que quelques jours si l’on veut qu’il soit à la pointe du progrès, faut-il optimiser sa taille à tout prix. La durée d’une compilation peut-elle être amortie en quelques jours ou même quelques semaines ?[/quote]
On n’a vraiment pas la même conception d’une machine 
. J’ai un noyau compilé le 20 Juin 2004 (896514 octets) qui tourne encore et un autre compilé le 1 Juillet 2000 (446895 octets) qui tourne encore (respectivement un 2.4.19 et un 2.0.38)
Donc, pour tenter de recentrer le sujet sur la taille : tes noyaux, fran.b (ça fait drôle à dire tiens) font respectivement ~7Mb et ~3,5Mb. Tu les avais liftés ou ce sont ceux d’origine ?
J’ai lu y a un moment quelques mots de L. Torvalds qui déplorait justement l’augmentation de la taille du kernel, c’est à ce point-là réel ?
[quote=“seb-ksl”]Oui, je sais bien qu’on peut toujours descendre. Virer Openbox pour dwm, diminuer le nombre de services, … Mais pour moi ça représenterait des sacrifices et c’est pas le but non plus.[/quote]Je n’ai viré aucun service, j’ai hal, dbus, udev, wicd et quelques autres qui tournent, par contre tu as raison, ce sont des mesures effectuées avec dwm.
EDIT : désolé, je n’avais pas vu la demande de “recentrage”.
Pour la taille, le 2.6.32 que j’ai eu ans les dépôts Debian est nommé “trunk” (pour tronqué ?)
En tout cas mon 2.6.32 fait 7.77 Mb,
mon 2.6.30 fait 7.26 Mb,
mon 2.6.26 fait 6.17 Mb.
Ils sont tous “d’origine”, ce qui semble confirmer un grossissement en taille
avec chaque augmentation du n° de version.
En fait c’est plutôt moi qui en ai rajouté, des services 
. Peu, mais ce qu’il me faut pour monitorer les températures des procs’ et disques, utiliser ma carte nVidia et un firewall iptables.
J’attends toujours des mesures de tailles et autres infos, à votre bon coeur !
C’est surtout dans l’optique de me faire une idée de jusqu’où c’est possible et utile d’aller dans l’allègement d’un kernel.
Salut seb,
Je ne suis pas chez moi actuellement et donc je ne peux pas vérifier, mais il me semble que la “meilleure” taille que j’ai pu obtenir en optimisant un max tout ça, était de l’ordre de 3Mo. Seulement je n’ai jamais su le refaire…
Il faut faire le grand ménage pour obtenir une petite taille comme ça.
[quote=“fran.b”][quote=“ggoodluck47”]Salut,
Sachant qu’un noyau ne dure que quelques jours si l’on veut qu’il soit à la pointe du progrès, faut-il optimiser sa taille à tout prix. La durée d’une compilation peut-elle être amortie en quelques jours ou même quelques semaines ?[/quote]
On n’a vraiment pas la même conception d’une machine . J’ai un noyau compilé le 20 Juin 2004 (896514 octets) qui tourne encore et un autre compilé le 1 Juillet 2000 (446895 octets) qui tourne encore (respectivement un 2.4.19 et un 2.0.38)[/quote]
N’est-ce pas un cas exceptionnel, veux tu que nous fassions le tour des participants à ce site ? D’après ce que je lis la plupart d’entre eux sont à l’affut de la moindre nouveauté en matière de paquet et de kernel
[quote=“eol”]En tout cas mon 2.6.32 fait 7.77 Mb,
mon 2.6.30 fait 7.26 Mb,
mon 2.6.26 fait 6.17 Mb.
Ils sont tous “d’origine”, ce qui semble confirmer un grossissement en taille
avec chaque augmentation du n° de version.[/quote]
Ah oui, effectivement, et encore plus rapide que ce que j’aurais pensé.
Ok, donc j’en viens à penser que pour vraiment réduire la taille de son kernel, il faut s’acharner pour un résultat intéressant mais quand même pas transcendant.
Merci à vous pour vos mesures !
Quant au débat parallèle qui s’installe, personnellement j’aime bien avoir le dernier noyau même quand l’ancien fonctionnait déjà bien. Sûrement l’effet Kinder surprise, je m’attends à trouver quelque chose de tout neuf à l’ouverture…
Et si je devais parier, je pense que ce serait sur le fait que la majorité des users “standards” ne changent de kernel que lorsque l’upgrade leur est proposé par apt et pas avant.
[quote=“ggoodluck47”]
N’est-ce pas un cas exceptionnel, veux tu que nous fassions le tour des participants à ce site ? D’après ce que je lis la plupart d’entre eux sont à l’affut de la moindre nouveauté en matière de paquet et de kernel [/quote]
Il m’arrive d’utiliser encore ceci, c’était ma première installation de Debian :
[attachment=0]ebola.jpg[/attachment]
(le free est erroné, la machine a 12Mo de RAM)
C’est le noyau de hamm, avec quelques applications de slink et patate et une version beta de apt. Pour des raisons de sécurité il est hors réseau
Il me manque juste les onglets de vim (enfin, j’utilise elvis, plus léger), sinon je suis pas très dépaysé. Par contre avec squeeze je vais devoir faire du backport à l’envers - c’est pour ça que je cours pas après le neuf.
422754 octets (et le cauchemar du probe des cartes ISA, c’était formateur à l’époque 
).
704533 octets pour le noyau officiel 
[size=150]+[/size]
[quote=“ggoodluck47”]Salut,
Sachant qu’un noyau ne dure que quelques jours si l’on veut qu’il soit à la pointe du progrès, faut-il optimiser sa taille à tout prix. La durée d’une compilation peut-elle être amortie en quelques jours ou même quelques semaines ?[/quote]
On n’a vraiment pas la même conception d’une machine . J’ai un noyau compilé le 20 Juin 2004 (896514 octets) qui tourne encore et un autre compilé le 1 Juillet 2000 (446895 octets) qui tourne encore (respectivement un 2.4.19 et un 2.0.38)[/quote]
N’est-ce pas un cas exceptionnel, veux tu que nous fassions le tour des participants à ce site ? D’après ce que je lis la plupart d’entre eux sont à l’affut de la moindre nouveauté en matière de paquet et de kernel [/quote]
Bonjour,
Hep, hep; On pourrait faire touner des bécanes new-tech sur des dino-kernel a coup de compil’ maison ??
Dites dites ??? 
[quote=“ggoodluck47”]
N’est-ce pas un cas exceptionnel, veux tu que nous fassions le tour des participants à ce site ? D’après ce que je lis la plupart d’entre eux sont à l’affut de la moindre nouveauté en matière de paquet et de kernel [/quote]
Ce n’est pas de " l’affut ", simplement de la curiosité 
Coucou tout le monde (depuis le temps …)
Salut Zodar,
Toi qui est sous Sidux, c’est pour conserver ton noyau pendant combien de temps ?
2.6.32-4.slh.2-sidux-amd64
C’est ta signature qui n’est pas à jour sans doute
[quote=“Knucky”][quote=“ggoodluck47”]
N’est-ce pas un cas exceptionnel, veux tu que nous fassions le tour des participants à ce site ? D’après ce que je lis la plupart d’entre eux sont à l’affut de la moindre nouveauté en matière de paquet et de kernel [/quote]
Il m’arrive d’utiliser encore ceci, c’était ma première installation de Debian :
[attachment=0]ebola.jpg[/attachment]
(le free est erroné, la machine a 12Mo de RAM)
C’est le noyau de hamm, avec quelques applications de slink et patate et une version beta de apt. Pour des raisons de sécurité il est hors réseau
Il me manque juste les onglets de vim (enfin, j’utilise elvis, plus léger), sinon je suis pas très dépaysé. Par contre avec squeeze je vais devoir faire du backport à l’envers - c’est pour ça que je cours pas après le neuf.
422754 octets (et le cauchemar du probe des cartes ISA, c’était formateur à l’époque ).
704533 octets pour le noyau officiel [/quote]
C’est du luxe ta machine avec des bogomips à 37 et un coprocesseur flottant…:
processor : 0
cpu : 486
model : 486 SX
vendor_id : GenuineIntel
stepping : unknown
fdiv_bug : no
hlt_bug : no
f00f_bug : no
fpu : no
fpu_exception : no
cpuid : no
wp : yes
flags :
bogomips : 12.42
total used free shared buffers cached
Mem: 10624 9580 1044 8388 1248 4176
-/+ buffers/cache: 4156 6468
Swap: 15268 184 15084
$ cat /etc/debian_version
2.0
$
Re,
Vous jouez à la plus petite ou à la plus vieille. Parce que j’ai encore une règle à calcul
C’est un 486SX à 25 MHz je suppose, c’est en effet le jour et la nuit avec mon DX4 
[quote=“ggoodluck47”]Re,
Vous jouez à la plus petite ou à la plus vieille. Parce que j’ai encore une règle à calcul [/quote]
C’est de la triche la règle à calcul
Sinon le noyau de clefagreg fait 2292080 octets (2.6.31) et l’initrd fait 2143924 octets. L’initrd est gros à cause de la présence massive de modules inutiles. Mais ça n’a aucun intérêt de le supprimer, le gain à la lecture est infime, et la ram est libérée lors du pivot_root.