Reprise du message précédent :
Tiens ... http://linuxfr.org/2007/01/16/21910.html

et si c'etait parceque la recompilation est inutile qu'elle est indispensable?

Tout à fait, compiler son kernel ce n'est pas sale !
Et puis d'abord comment je fais pour avoir mon zoli logo perso tout chaud sans compiler moi-même ?! Hein ? non mais des fois !

 
Ça requiert mon attention une grosse minute et ça attire les filles comme du miel
 
EDIT : pour narguer les frileux :

Ok pour dire qu'effectivement, des "nouveaux" utilisateurs de Linux qui sont sur Linux par raisons "financières" on va dire, n'ont que peu d'intérêt à recompiler leur noyau
 
Ceci dit, je suis de ceux qui pensent que si l'on va sur Linux pour apprendre, alors l'apprentissage passe par la recompilation du noyau ...
 
Maintenant il y a un argument qu'il ne me semble pas avoir lu ici :
recompiler son noyau avec toutes les options en dur pour sa machine perso qui a priori ne change pas plus que cela a aussi l'avantage de supprimer la gestion des modules, ainsi que le besoin éventuel d'une image initrd.
Outre le gain (certes assez ridicule) de place disque ou de temps d'accès, cela a surtout le net avantage de s'affranchir pour de bon de tout rootkit qui prendrait l'apparence d'un module ou d'une image initrd ...

Sauf si t'es admin, ça n'a aucun intérêt. Les noyaux de distribs sont bien et régulièrement mis à jour. Il n'y a beaucoup plus utile et intéressant à apprendre que ça. La BD plus haut est exacte : il n'y a rien à en tirer. Et je ne vois aucun avantage à supprimer les modules. D'ailleurs sauf cas spécial, recompiler son noyau ça ne veut pas dire ne pas avoir de module. Et le mytho du rootkit ...
 
Bref, sauf bricolage, tests ou configuration manquante, ne pas utiliser le noyau de sa distrib, c'est du NIH.
 
Personnellement, sur mon portable, le noyau debian fonctionne très bien. Si je fais tourner un noyau vanilla, c'est pour essayer différents modules de la stack IP qui n'ont pas d'intérêt pour un poste/serveur/routeur_classique.

 
Suis pas vraiment d'accord là dessus, voir ma réponse plut haut, vais pas me répéter

 
Pas d'accord ...
en tant qu'étudiant en informatique, ou par curiosité tout simplement (ça existe aussi ...) savoir comment fonctionne un OS ça a de l'intérêt ...
je ne dis pas de lire et comprendre tout le code source, mais configurer son noyau et le recompiler permet déjà de voir certains trucs
(tiens pour accéder à mon disque il faut un driver de chipset ide + un driver disque + un gestionnaire de périphérique block ...
et puis ah tiens le noyau en fait ce n'est qu'un jeu de fonction dont les points d'entrée se retrouvent dans le System.map
... )
 
En gros pour moi, mais ça n'engage que moi, tu n'es pas un vrai pingouin tant que tu n'as pas recompilé ton noyau, même si je trouve l'image de Bigon assez vraie, mais au moins après tu sais de quoi on parle ...

'tain bonjour la vision élitiste.

Dommage. Parce qu'à l'époque où je taquinais sous Linux, j'avais comparé la lecture d'un gros divx sur un PIII 500 (oui ça fait pas mal de temps), verdict:
 
1) Sur Debian avec le package Mplayer, la lecture était viollement saccadée avec des bugs d'affichage de partout, son et image (là on ne parle même plus de vidéo) totalement désynchro.
 
2) Sur Gentoo avec Mplayer compilé, lecture impeccable.
 
 
Résultat, j'ai gardé cette bécane sous Gentoo pendant plusieurs années à l'heure où tout le monde éclatait les gigahertz.  
 
 
EDIT: en cherchant vite fait sur le net. Apparemment, parfois gentoo est plus rapide, parfois c'est plus lent. Idem avec les hisoitres de recompilation de noyau et de modules.

   
autant j'aurais compris si tu avais dit qu'il fallait partir de la lfs , autant recompiler le kernel pour faire vrai pinguoin c'est plus pour faire 'croire' que tu sais faire quelque chose ...

Oui voila je sais faire un truc super complexe... qui sert absolument rien.
 
Si t'as envie d'apprendre des chose, lance toi sur ldap, buildbot, postfix en cluster ou je ne sais quoi, mais une compile de kernel franchement

 
j'ai pas dis que je me contenté de ça ...
c'est un 1er pas c'est tout
 
1er pas que j'ai fais il y a longtemps ...
et lfs je connais aussi mais ce n'est encore pas le même truc ...
 
compiler le noyau perso ça m'a appris des trucs sur le fonctionnement interne et donc sur les OS en règle général ...
et je comprendrai tout à fait même si ça l'air de "choquer" certains que l'on ait envie de recompiler son noyau justement pour voir ces trucs

le fait de compiler le noyau t'aurait appris des trucs sur le fonctionnement interne
tu veux plutôt dire que le faite de lire le code et les divers appels t'as permit cela non ?
car bon si c'est simplement choisir les modules a compiler en dur ou pas , il suffisait de lire la documentation fourni avec le kernel , a aucun moment la compilation est nécessaire.
Bien sur si tu as été modifié le code d'un nombre certains de modules , virer un certain nombre de warnings et autres joyeusetés apparaissant lors de la compilation c'est autre chose ...

exactement ce que Mme Dupont a besoin de savoir.

 
D'où ce que j'ai dis :

ça, ça n'existe pas

Tu oublies les cas pour lesquels tu es obligé de recompiler ton kernel, par exemple matériel supporté uniquement avec un patch kernel

alors ça, c'est à mettre sur le podium des citations à la con de l'année

 
 
À nouveau on aimerait que tout soit blanc ou noir, mais la réalité se veut plus complexe, y compris lorsqu'il s'agit de déterminer si la compilation (ou recompilation) de noyau est utile ou non...    
 
 
Clairement à ce niveau mon point de vue est le suivant :
 
 
1) le cas du noob total, de l'utilisateur lamda ou initié :
 
La compilation du noyau est très certainement inutile : dans ce cas de figure il s'agit d'optimiser ou d'ajouter des fonctionnalités qui n'auront un réel intérêt que pour les utilisateurs expérimentés. Les versions précompilées du noyau contiennent largement ce qui est nécessaire pour une utilisation courante et on peut faire confiance aux réglages effectués par les mainteneurs de sa distribution.
Pour les périphériques non supportés ou seulement par l'ajout de pilotes externes, le problème vient de l'achat de matériel auprès de constructeurs qui refusent de fournir les spécifications permettant de développer des pilotes libres de sorte à ce qu'ils puissent être intégrés au noyau et aisni fonctionner d'office sans aucune intervention que ce soit.
 
 
2) le cas du 'power-user', du 'geek'
 
Passer une nuit blanche à naviguer dans les centaines d'options de configuration du noyau avant de voir défiler les milliers de lignes de code pendant la compilation provoque en vous un irrésistible attrait ? Vous rêvez de percer les secrets du noyau en étudiant les arcanes mystérieuses entretenues par vos barbus préférés ? Vous êtes perfectionniste dans l'âme et seule l'idée d'un noyau réglé au millimètre parvient à vous satisfaire ? Les 0,4% de performances en plus obtenus et la sortie personnalisée du uname sont votre fierté par rapport à la masse commune de noyaux précompilés de base ? Vous suivez quotidiennement la LKML, votre passion est de tester les options les plus expérimentales possibles en combinant une demi-douzaine de patchs ?
 
... inutile, donc indispensable !
 
 
3) le cas de l'admin ou de l'intégrateur système
 
Dans le cas de l'administration d'un petit réseau ou serveur, toute distribution qui se respecte fournira régulièrement des versions précompilées de noyau à jour, ce qui suffira et sera convenable au niveau de la sécurité. Pour des milieux plus critiques, tout admin valable mettra en place une politique adaptée : suivi particulier des mises à jour, configuration noyau et déploiement d'outils en vue du renforcement de la sécurité (compilation en dur du strict nécessaire, SELinux ou GRsecurity...).
Pour l'intégrateur spécialisé, notamment dans le domaine de l'embarqué, vu que son offre de service est essentiellement axée sur le sur-mesure, la compilation de noyau fait un peu partie de son fond de commerce, donc il va de soi que ce savoir-faire est incontournable, s'il veut correctement manger en fin de mois.
 
 
   

 
Je suis complètement d'accord, même si je nuancerais un peu pour le coté admin mais c'est chacun sa façon de faire son métier

 
Recompilé ton kernel invalide grandment le support chez des boites comme RedHat ou SUSE. Donc même si tu as un admin avec tout un tas de machines critiques qui sont sous support, ben tu gardes ton kernel de la distrib et tu as foi dans la rapiditié de sortie des versions corrigées

"avoir foi", il faut avec RH

pas seulement la partie admin, je suis peut etre un "power user"+admin et je ne recompile
pas specialement les kernel, sur les distrib "modernes" le support est maintenant suffisant.
qd à l'embarqué ==> je plussoie par contre  
pour terminer : cela dépend grandement à quoi va servir le kernel finalement

il faut combien de temps pour recompiler un kernel avec une machine ... disons actuel ? (core duo intel par exemple)
Combien coûte l'heure de travail d'un informaticien français ?
 
Est ce que la dépense vaut les 40Mo de module épargné sur un DD qui ne coûte plus grand chose maintenant ?
Ou les quelques % d'optimisation au démarrage de la machine ?
 
Sans compter que la machine chôme pendant qu'elle recompile ... inutilisable en production.
 
A moins que de faire recompiler son kernel en chine ...  

 
heu... screen, nice toussa...

 
tmpfs

moi je recompile !    
 
c'est juste pour dire !

Tout dépend du type de prestation dont dépend la boîte :  
soit on fait confiance à un prestataire externe (gros constructeur par exemple) avec des contrats de leasing + maintenance, auquel cas les interventions de l'admin sur le serveur ne concerneront pas des tâches sensibles comme la configuration/compilation du noyau
soit on fait confiance à un admin compétent (espérons-le du moins   ) embauché spécialement pour gérer la maintenance et le suivi informatique dans tout son ensemble
 
Après vient également le fait que toutes les boîtes n'utilisent pas forcément RH ou SUSE non plus    
 
 

Ben ça se compte en minutes (moins d'une dizaine de minutes sur un core duo, bien que je n'ai pas encore eu l'occasion de compiler un noyau dessus pour l'instant).
 
 

cf. ce que j'ai dit plus haut, si un admin est spécialement embauché, cette tâche fait, entre autres, partie de son boulot et il est payé pour ça.
Ensuite une boîte ne compile pas pour les mêmes raisons que pour le particulier ; dans le cas d'une entreprise, ce sont les besoins spécifiques ou une politique particulière pour le suivi de la sécurité qui déterminent cela, dans le cas du passionné Linux, c'est avant tout une question de plaisir.
 
 

On peut effectuer une compilation en douceur, de sorte à ce que les ressources ne seront pas monopolisées si une autre tâche en a besoin, mais généralement dans l'idéal c'est un buildd (machine dédiée pour la compilation) qui sera utilisé ; de plus le noyau sera testé avant mise en production, forcément.

 
Nuance un peu moins alors
 
Pense par exemple au cas du support MPPE, qui n'a été intégré qu'à la 2.6.12 (ou .15 je sais plus); y'a plein de petits exemples dans le genre

 
Ça intéresse donc de grosses sociétés avec des parcs informatiques qui justifient un administrateur, il est normal qu'on lui demande de faire son boulot.
Ou un particulier pour le plaisir de compiler.
 
Je ne suis ni l'un ni l'autre. Donc je ne compile pas. (je n'y ai aucun plaisir)

moi non plus ça ne me fait pas plaisir, mais quand tu vois que sur ta Ubuntu 6.10 le DMA n'est pas géré par défaut par le kernel d'origine pour les chips IDE Via, un 2.6.17, 2.6.19 ou 2.6.20 n'arrageant rien, t'as pas trop le choix
 
je sors de quelques années de Gentoo, et je suis passé à Ubuntu parce que j'en avais marre des compils à rallonge, et j'ai été agréablement surpris, tout marche tout de suite, sauf cette histoire de DMA (que je n'avais pas avec la 6.06 et le 2.6.15, où ça marchait très bien)
 
compil obligatoire, car dans un make menuconfig je me suis aperçu que le contrôleur IDE Via n'était même pas coché, que ce soit en dur ou en module (2.6.17, 2.6.19, 2.6.20 installés avec les sources Ubuntu et donc ses patchs allant avec - y'a une ligne dans le menuconfig qui s'appelle "Ubuntu patches" ou un truc comme ça -)
 
en attendant, je regrette qu'il n'y ait pas un outil du type genkernel fort pratique sous Gentoo pour cette distrib, donc obligé de se taper les sources directes de kernel.org, et j'ai beau ne pas être un noob, c'est pas facile d'arriver à quelque chose de fonctionnel
 
je précise que j'ai fait un rapport sur launchpad.net pour ce problème, et je me suis aperçu que tout le monde avec le même matériel que moi était dans ce cas
 
je dirais que c'est pas vraiment génant, à l'exception de la gestion de mon graveur DVD, qui grave ce qu'il peut sans DMA activé, donc, OUI, il peut y avoir certaines raisons qui nous amènent à DEVOIR compiler son kernel, outre le fait que ce soit indispensable en prod, ou pour le simple plaisir de dire "Je sais compiler mon kernayl"
 
en attendant, je m'en suis toujours pas sorti de cette histoire de DMA

Juste une petite remarque au passage : ça parait gros quand même de la part d'Ubuntu d'avoir oublié d'activer le DMA pour les chipset Via, d'autant que tu indiquait que c'était le cas auparavant avec un 2.6.15. Amha, il peut s'agir d'un problème de gestion du DMA avec les chipset Via dans les versions récentes du noyau, ce qui aurait obligé les mainteneurs du noyau chez Ubuntu à désactiver cette option.
 
 

Et dans ce cas là... on fait quoi?  
http://forum.hardware.fr/forum2.ph [...] w=0&nojs=0
 

je t'ai répondfu ça : http://kmuto.jp/debian/d-i

perso, j'arrive pas non plus a voir l'interet de compiler un kernel, a part cas extrenement rares.
Pour dire je l'ai fait une fois, oui pourquoi pas.
Pour dire que j'apprend le fonctionnement du système, alors la, c'est l'excuse la plus bidon que j'ai entendu.
J'appuie les dire de jesaisplusqui: si tu veux apprendre comment fonctionne le système, tu te fais une LFS <u>sans</u> te contenter de betement copier/coller le code, mais en coprenant ce que tu fais.
J'ai jamais autant appris qu'à ce moment la. (même si au final, par faute de temps, j'ai jamais réussi à la faire fonctionner )

 
Je n'ai pas critiqué ta réponse, je voulais montrer que c'est parfois nécessaire...

 
   
Je suis désolé mais c'est pas si bidon que ça. Quand tu cherches à activer un option particulière et qu'elle est non accessible à ce moment là, tu te rends compte qu'en fait elle dépend d'un option plus haut que tu n'a pas activée etc etc ... Et c'est là que tu comprends le système.
Quand tu actives l'ide pour ton disque dur sata et que tu te retrouves avec un taux de transfert à 500k/s sans possibilité d'activer le DMA, puis que par la suite tu désactives l'ide et que tu passes à 35Mo/s, tu comprends que sata = scsi sous linux.
 
Et ce n'est qu'un petit exemple, j'en ai plein d'autres comme ça.
Donc non, ce n'est pas bidon ... et si tu penses ça, c'est que tu n'as pas du regarder en détail comment fonctionnait le système de configuration du kernel

c'est un développeur debian qui te le met à dispo

je ne vois pas le probleme de recompiler son noyau , personnellement je l'ai fait pour plusieurs raisons :  
 
-beaucoup de gens disent que Debian est plus rapide qu'Ubuntu , si c'est vraiment le cas cela peut venir soit du noyau, soit des services lancés , donc j'ai essayé avec un kernel recent et compilé a la main. Le problème etant que ma distrib Ubuntu de base de rame pas donc difficile de voir une différence.
 
-j'ai eu beaucoup de problemes avec les drivers officiels NVidia sous Debian et Ubuntu , depuis que je suis en 2.6.19 ces problèmes ont disparus
 
-ma webcam marche bien mieux maintenant
 
-j'ai recompilé pas plus tard qu'hier pour avoir le support d'Hiddev permettant d'utiliser l'afficheur de mon clavier MX5000 (il me manque encore le pilote dans /dev/hiddev ... si quelqu'un peut aider)
 
-je vais surement recompiler encore une fois pour corriger un bug du bluetooth qui m'oblige a debrancher et rebrancher le dongle BT pour utiliser mon kit clavier / souris
 
Apres je suis d'accord avec le fait que recompiler son kernel juste pour la gloire n'apporte rien

 
Voila ...
 
Et le jour ou tu supporteras plus ce ùç$ùà de bug de DMA, tu vas commencer à insérer des printk dans le code pour voir ce qui déconne. Quand tu auras trouvé une solution, tu posteras sur la kernel mailing list un petit patch et tu auras l'immense honneur d'avoir rendu un peu à linux ce qu'il t'a offert
 
Je dirais même que c'est l'idéal pour "apprendre le kernel". En tout cas, c'est comme ca que j'ai fait