En annonçant la sortie de Linux 2.5.70, Linus nous informe qu'il va rentrer dans la série des pre-2.6. Ce serait aussi le dernier noyau « pur Linus » puisqu'il compte y intégrer les modifications d'Andrew Morton.
Par ailleurs le 2.5.70 est un gros patch qui entre bonnes choses ajoute enfin le support de l'AGP Uninorth pour les Mac :-))).
La liste (voir le lien : L'annonce) des derniers changements v2.5.69 à v2.5.70 est impressionnante tant par le nombre de personnes que par le nombre de corrections.
Même si on ne comprend pas tout, ça vaut la peine d'y jeter un coup d'oeil. On peut alors deviner à quel point Linux est un monument fabuleux et pourquoi aucun industriel ne peut plus suivre la vitesse d'évolution de Linux.
faudrait preciser qu il sa git d andrew morton , connu entre autre pour des patchs lowlatency , par contre depuis quelques temps il a a du prendre de la drogue vu tout la quantité de code qu il a pondu ;)
Testé hier soir sur mon AthlonXP 1700 sur CM Asus NForce 1 avec batterie de périphérique USB (clavier, souris, tablette graphique, imprimante, scanner, modem, zip).
Premier verdict :
- Le pilote SCSI Adaptec ne compilait pas. Je n'ai pas de carte Adaptec mais comme il est sélectionné par défaut, ca a fait planter mon premier essai. Après déselection, ca marche.
- le support USB, soit c'est pas ca, soit quelque chose m'échappe. Au boot tout semble détecté mais /proc/bus/usb/devices ne liste que les deux premiers hubs de la carte mère, commence un troisième périphérique mais semble s'arrêter comme si le pilote avait segfaulté. Et devfs ne rapporte aucun périphérique USB. Je suis déçu. :-(
Bon, notez que je compile le tout sur une Slackware Current avec le dernier gcc 3.3, la dernière glibc 2.3.2. A croire qu'il fait tout pour que ca plante!
Pour le reste, en plus des grandes innovations déjà bien connues, il y a plein de petits ajouts de ci de là. Il y a par exemple un support du GART pour nForce, et un support du controleur IDE nForce intégré, plutôt que le support générique qui met tout en PIO par défaut. Je parle de ce qui me concerne directement mais il y a pas mal d'autres choses du même type.
Bref, je pense que ca sera pas mal.
A noter que jusqu'a preuve du contraire, quand tu compile un kernel la version de glibc qu'utilise ton systeme a peu d'influence sur le resultat (le kernel ne depend pas de la glibc).
mes 2cents.
compile avec gcc 3.2.x, le 3.3 a quelques problèmes: etant plus stricte, certains bouts de code passe à la trappe. Soit la compilation échoue, soit c'est la surprise à l'exécution
Bon, j'ai testé avec gcc 3.2.3 et même problème. Soit mes options choisies dans mon .config sont foireuses, soit il y a effectivement encore quelques bugs gênants.
A noter que je l'utilise à mon boulot compilé avec gcc 3.3 et que ca fonctionne très bien. Mais je n'utilise pas de périphérique USB au boulot...
à noter que le support IDE pour nforce est aussi dans le 2.4 depuis la 2.4.21pre5, où il était inclus dans un module spécifique (nforce IDE), avant d'être intégré aux modules gérant les IDE des chipsets AMD (CONFIG_BLK_DEV_AMD74XX) dès le 2.4.21pre6.
Il a la particularité de résoudre les problèmes de blocage temporaire asynchrone du système lors de mouvements de fichiers (genre la décompression des sources du noyau) sur les HD (problème typique de l'IDE mal pris en charge).
Quant à l'USB du nforce, c'est de l'OHCI, ne vous trompez pas, je me souviens que le manuel de ma carte mère indiquait que c'était de l'UHCI, ce qui était faux.
Enfin, le support du gart nforce n'a pas été backporté à ma connaissance.
De toute façon, j'ai changé de CM hier, j'suis en KT400 maintenant, et toutes les fonctions intégrées sont parfaitement prises en charge, à l'exception de l'AGP 8x :)
Il a la particularité de résoudre les problèmes de blocage temporaire asynchrone du système lors de mouvements de fichiers (genre la décompression des sources du noyau) sur les HD (problème typique de l'IDE mal pris en charge).
Il ne s'agit pas tout simplement de l'activation ou non du DMA ? Je n'ai jamais eu de blocages temporaires lors de gros transfert avec le DMA activé et un disque dur lent. Sans le DMA il y'a des blocages temporaires de quelques secondes toutes les dix secondes.
http://members.optusnet.com.au/ckolivas/kernel/
Outre deux-trois petites choses (preempt, low latency...), il propose un patch pour pouvoir compiler le kernel avec gcc3.3 (pas essayé)
J'avais lu qu'ils avaient de grosses évolutions sur les threads dans le 2.5 / 2.4. Quelqu'un les connaît?
De plus, je voudrais savoir à quel niveau est attaché un PID? au thread (chaque thread a son PID propre) ou au processus père (un peu comme solaris).
est super instructif !! J'ai appris pas mal de truc et ca m'a vraiment l'eau a la bouche si je puis dire ;)
Je pense que je vais tester le 2.5.70 juste pour voir ca...
enfin pour bientot.... vu la longueur de la liste "must-fix list for 2.6.0" de andrew morton c'est quand même pas pour tout de suite... (moins de 2 mois ca me parait pas possible)
mais bon, je teste assez régulierement les kernel 2.5 et ca c'est pas mal amélioré !!! plus on le testera et plus on fera de retour plus vite ca sortira
Y a pas le feu au lac ! Le but est de sortir un kernel stable. Linux n'est plus un bricolage de geeks depuis un bon bout de temps. Si il sort en septembre ce sera très bien. Il vaut beaucoup mieux avoir quelque semaines de retard et des bugs en moins que l'inverse.
"In fact, judging by past performance, a lot of things won't get
fixed before the actual vendors have made _releases_ that use
2.6.x [...] This is not just a core kernel issue - we've seen this
with subsystems like ext3 and ReiserFS: they were "finished'
and "stable", but what made them _really_ stable was a
release or two on vendor kernels, and thousands of users."
-- Linus
Y'a enfin des drivers libres pour l'AGP de Nvidia ! ^_^ (les précédents faisaient partie des drivers de leurs cartes graphiques...)
Quelqu'un sait si ils seront backportés vers les 2.4.x ?
Tu confond surement les nForce avec les gForce.
Les nForce sont des chipsets sur la carte mère qui gère tout. Ils intégrent l'équivalent d'un MX400 comme carte graphique, mais ça fait aussi le son, la gestion mémoire, l'ULTRA DMA, etc.
Non, il ne confond pas, le driver AGP pour les nForce est dans les driver nVidia. Ce qui pose problème si tu utilise une autre carte que nvidia avec un chipset nforce ...
Je vais peut-être encore poser une question con. Après tout, vous en avez l'habitude... ;-)
L'un d'entre vous sait-il si il existe une option du make qui permette de positionner toutes les options par défaut, suivant le matériel sur lequel il est lancé ? Par exemple, j'aimerai bien, moi, que quand je lance un make menuconfig sur mon LFSKernel, que le make broute les ressources CPU le temps qu'il lui faut pour chercher ce qui lui semble correct (processeur, chipset, type de clavier, cartes d'extension installées, etc.). Après, je vais fouiller dans les menus pour lui dire : ma carte réseau, je ne la veux pas en module, mais la carte son, oui ; bref, ce genre de chose. Un peu comme un cat /proc récursif intelligent. Si ça n'existe pas, est-ce dans les wish list ?
Je sais, ça parrait être une option de feignant (je sais, j'en suis un !), mais d'un autre côté, ça laisserait la possibilité à l'utilisateur "moyen" de se compiler un kernel supportant son matos, et un tant soit peu optimisé, sans trop d'effort. Moi, y'a plein d'options auxquelles je ne touche pas de peur de tout foutre par terre et de ne plus pouvoir booter. De plus, j'ai pas trop de temps à perdre à essayer d'améliorer le système, donc, quand ça fonctionne, je ne touche plus à rien. Ce qui est peut-être une connerie, car rien n'est vraiment optimisé ! Enfin ce que j'en dit.
Merci pour vos éclaircissements en tout cas.
Oui, je sais bien, c'est pour ça que je parle de LFSKernel. Et puis si j'ai bien compris le fonctionnement des kernels fournis pas les distribs, ils collent un max de modules, c'est un fait, et des drivers génériques pour le chipset par ex. De ce fait, ça fonctionne, mais c'est pas optimum.
Je pensais vraiment à une compile à la mimine du kernel. C'est pas donné à tout le monde de soulever le capot pour aller voir le n° du chip sur la carte Tv ou la carte son. Si on veut ouvrir Linux au grand public, au contraire, il me semble qu'une reconnaissance auto du matos à la compil serait idéale. Après tout, c'est pas parce que je sais Kompiler KDE avec Konstruct que je sais compiler un kernel proprement. Vous saisissez la nuance ?
Et puis, on pourrais mettre en regard Xp par ex et Linux. "Moi, j'ai branché mon truc dans la boîte, j'ai fermé et XP a reconnu le matos tout de suite", vs "Moi, j'ai branché le truc dans la boîte, et j'ai du recompiler un kernel pour que ça marche, mais comme il me posait pleins de questions gênantes (options du module, n° de chip, etc.), ben j'ai mis 3 mois pour que ça marche...".
Y'a pas photo....
- Des modules non chargés en mémoire ne causent pas de pertes de performance (ca prend juste un peu d'espace disque dans /lib/modules...)
- Concernant l'autodétection du matériel, celle ci n'est pas automatique sous Linux (et plein d'autres OS) et c'est tant mieux: l'installation de drivers sous Linux est peut être difficile (mais c'est subjectif et c'est surtout une question d'habitude) mais au moins c'est fait une bonne fois par toute, et il n'y a pas besoin de jouer dans le panneau de config. d'XP, qui SEMBLE être une référence dans le domaine de la simplicité d'utilisation... Cela n'est pas l'avis des neu²^Wutilisateurs qui n'arrivent pas à installer leur imprimante sous Ickspai.
- De toute manière pas mal de distribs proposent aujourd'hui l'autodétection du matériel "à la Windows", ca peut être un premier pas dans la découverte de Linux, mais par la suite, un utilisateur digne de ce nom doit AMHA savoir recompiler un noyau sans tout casser (je me rappelle personnellement avoir tout cassé à de nombreuses reprises mon système [en 1998, sous un redhat 5.1 :)] en tentant de recompiler la bestiole).
Ouhlà, on est mal partis là !!!!!
- Des modules non chargés en mémoire ne causent pas de pertes de performance (ca prend juste un peu d'espace disque dans /lib/modules...)
Mais je suis bien d'accord ! Loin de moi l'idée de te contredire là dessus. Mais une fois encore, je parle d'un kernel compilé à la mimine, pas d'un kernel fourni par une distrib.
(...(Je ne vais pas tout recopier) ;-)
Je pensais juste à un genre de pré-configuration par défaut personnalisée. Je me souviens que lorsque j'ai compilé mon dernier kernel, il y a des options auxquelles je n'ai pas touché, car je sais par expérience que ça fout le bordel (tout simplement parce que je ne vois pas trop à quoi ça fait référence).
[*] CMD640 chipset bugfix/support
[ ] CMD640 enhanced support
[*] RZ1000 chipset bugfix/support
[*] Generic PCI IDE chipset support
Voilà, j'ai retrouvé ce que je ne touche surtout pas. C'est peut-être un bien, peut-être pas. Si le make détectait mon chipset correctement, je serais plus tranquille. Car là, le généric PCI IDE ...; ça me fait penser que c'est pas optimisé du tout ce truc. Quant-au reste, ben je ne sais pas trop.
Enfin, et pour qu'on se comprenne bien, je suis loin de penser que Linux devrait se comporter comme XP pour la détection du matos. Je pense comme toi, que puisque c'est fait une bonne fois pour toute, autant conserver ce mode de fonctionnement. Je pensais juste à un pré-remplissage des cases du make menuconfig avec les options qui *semblent* correctes. Libre à l'utilisateur de les utiliser ou non ensuite.
Je sais recompiler un kernel *kivabien* sur une machine, ayant commencé a utiliser linux avec le noyau 0.99pl5 c'etait plus que necessaire et bien moins facile (interface rudimentaire en mode texte ...)
Et bien figure toi que je ne recompile quasiement jamais de kernel maintenant et ce depuis quelques annees. Et quand je recompile, c'est pour passer des patchs (carte wireless en mode monitor ...) et recompiler a l'identique avec le .config fourni par la distrib.
a une epoque j'avais fait des mesures de perfs entre un noyau compile pour le bon cpu (PII) et celui par defaut (i386) sur un serveur samba over chargé. pas de différence significative. En fait, ma théorie c'est qu'a recompiler toi meme ton noyau tu va lire de la doc et apprendre beaucoup. te tromper, relire de la doc et apprendre encore. Mais crois moi, le *gain* en performance ne sera pas au rendez vous d'un tunning de .config. A une epoque il fallait changer des valeurs dans les includes du kernel pour le tuner, maintenant on a /proc/sys pour quasiement tout modifier (file handles, vm, network ...) bref plus besoin de recompiler a tout va.
aujourd'hui le tunning c'est donc /proc/sys , hdparm, ...
Disons que laisser la machine choisir toutes seules les options du noyeau peut, je pense, etre désastreux. Mais, il est exact qu'avoir juste un petit script récupérant ce qui va bien, plaçant les bonnes options au bon endroit AVANT le make menuconfig pourrait faire gagner du temps.
D'un autre coté, gagner du temps sur un truc que l'on fait une fois....
Ce qui me semble plus pratique, que fait la Debian (et d'autres peut-etre, je l'ignore) est de fournir le .config ayant servi lors de la compilation, permettant ainsi une recompilation en ayant pas trop de choix à faire (make oldconfig et ça plan... marche presque toujours)
Maintenant, est-on réellement obligé de recompiler son noyeau? Les noyeaux des distrib récentes intégrent presque tous la majorité des modules possibles. Aprés, avec une bonne interface (graphique ou non), l'installation d'un module peut se révéler trés facile.
# Re: Linux 2.6 est pour bientot...
Posté par fosco . Évalué à -2.
[^] # Re: Linux 2.6 est pour bientot...
Posté par Pierre Jarillon (site web personnel) . Évalué à 8.
Même si on ne comprend pas tout, ça vaut la peine d'y jeter un coup d'oeil. On peut alors deviner à quel point Linux est un monument fabuleux et pourquoi aucun industriel ne peut plus suivre la vitesse d'évolution de Linux.
[^] # Re: Linux 2.6 est pour bientot...
Posté par Olivier Cahagne . Évalué à 10.
<cramerj@intel.com>
[PATCH] TSO fix
* Premature write-back of descriptors during TSO causing
resources to be returned too early on ppc64.
[^] # Re: Linux 2.6 est pour bientot...
Posté par redguts . Évalué à 3.
[^] # Re: Linux 2.6 est pour bientot...
Posté par _seb_ . Évalué à 4.
François Romieu:
* USB: patch to fix up coding style violations
http://linuxfr.org/~Ueimor/(...)
Un grand bravo tout de même !
# Re: Linux 2.6 est pour bientot...
Posté par Prosper . Évalué à 10.
# Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Linux 2.6 est pour bientot...
Posté par yugz . Évalué à 4.
[^] # Re: Linux 2.6 est pour bientot...
Posté par Spermatozoide . Évalué à -2.
[^] # Re: Linux 2.6 est pour bientot...
Posté par yves a (site web personnel) . Évalué à 1.
# Re: Linux 2.6 est pour bientot...
Posté par Richard Van Den Boom . Évalué à 10.
Premier verdict :
- Le pilote SCSI Adaptec ne compilait pas. Je n'ai pas de carte Adaptec mais comme il est sélectionné par défaut, ca a fait planter mon premier essai. Après déselection, ca marche.
- le support USB, soit c'est pas ca, soit quelque chose m'échappe. Au boot tout semble détecté mais /proc/bus/usb/devices ne liste que les deux premiers hubs de la carte mère, commence un troisième périphérique mais semble s'arrêter comme si le pilote avait segfaulté. Et devfs ne rapporte aucun périphérique USB. Je suis déçu. :-(
Bon, notez que je compile le tout sur une Slackware Current avec le dernier gcc 3.3, la dernière glibc 2.3.2. A croire qu'il fait tout pour que ca plante!
Pour le reste, en plus des grandes innovations déjà bien connues, il y a plein de petits ajouts de ci de là. Il y a par exemple un support du GART pour nForce, et un support du controleur IDE nForce intégré, plutôt que le support générique qui met tout en PIO par défaut. Je parle de ce qui me concerne directement mais il y a pas mal d'autres choses du même type.
Bref, je pense que ca sera pas mal.
Cordialement,
[^] # Re: Linux 2.6 est pour bientot...
Posté par PLuG . Évalué à 7.
mes 2cents.
[^] # Re: Linux 2.6 est pour bientot...
Posté par TazForEver . Évalué à 5.
[^] # Re: Linux 2.6 est pour bientot...
Posté par Richard Van Den Boom . Évalué à 1.
A noter que je l'utilise à mon boulot compilé avec gcc 3.3 et que ca fonctionne très bien. Mais je n'utilise pas de périphérique USB au boulot...
Cordialement,
[^] # Re: Linux 2.6 est pour bientot...
Posté par N/A . Évalué à 1.
Il a la particularité de résoudre les problèmes de blocage temporaire asynchrone du système lors de mouvements de fichiers (genre la décompression des sources du noyau) sur les HD (problème typique de l'IDE mal pris en charge).
Quant à l'USB du nforce, c'est de l'OHCI, ne vous trompez pas, je me souviens que le manuel de ma carte mère indiquait que c'était de l'UHCI, ce qui était faux.
Enfin, le support du gart nforce n'a pas été backporté à ma connaissance.
De toute façon, j'ai changé de CM hier, j'suis en KT400 maintenant, et toutes les fonctions intégrées sont parfaitement prises en charge, à l'exception de l'AGP 8x :)
[^] # Re: Linux 2.6 est pour bientot...
Posté par Benoît Déchamps (site web personnel) . Évalué à 1.
[^] # Re: Linux 2.6 est pour bientot...
Posté par taiwan . Évalué à 2.
[^] # Re: Linux 2.6 est pour bientot...
Posté par Rin Jin (site web personnel) . Évalué à 2.
# Petit question sur les threads
Posté par Jérôme LAFORGE . Évalué à 2.
De plus, je voudrais savoir à quel niveau est attaché un PID? au thread (chaque thread a son PID propre) ou au processus père (un peu comme solaris).
merci
[^] # Re: Petit question sur les threads
Posté par Christian Gagneraud (site web personnel) . Évalué à 1.
arch/i386/process.c
kernel/fork.c
[^] # Re: Petit question sur les threads
Posté par Christophe Lucas (site web personnel) . Évalué à 2.
--
http://titux.tuxfamily.org(...)
[^] # Re: Petit question sur les threads
Posté par oliv . Évalué à 2.
http://lwn.net/Articles/10378/(...)
En plus brut mais à jour, il y a le post-halloween doc de Dave Jones:
http://www.codemonkey.org.uk/post-halloween-2.5.txt(...)
et les deux documents précédents se réfèrent à celui ci:
http://people.redhat.com/drepper/nptl-design.pdf(...)
[^] # Re: Petit question sur les threads
Posté par Damien Pobel (site web personnel) . Évalué à 1.
est super instructif !! J'ai appris pas mal de truc et ca m'a vraiment l'eau a la bouche si je puis dire ;)
Je pense que je vais tester le 2.5.70 juste pour voir ca...
https://damien.pobel.fr
[^] # Re: Petit question sur les threads
Posté par patrick_g (site web personnel) . Évalué à 1.
# Re: Linux 2.6 est pour bientot...
Posté par etienne_basset . Évalué à 1.
mais bon, je teste assez régulierement les kernel 2.5 et ca c'est pas mal amélioré !!! plus on le testera et plus on fera de retour plus vite ca sortira
[^] # Re: Linux 2.6 est pour bientot...
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
[^] # Re: Linux 2.6 est pour bientot...
Posté par manuel . Évalué à 2.
# Re: Linux 2.6 est pour bientot...
Posté par un_brice (site web personnel) . Évalué à 1.
Dave Jones:
[AGPGART] Merge NVIDIA nForce / nForce2 AGP drive
</blockquote>
Y'a enfin des drivers libres pour l'AGP de Nvidia ! ^_^ (les précédents faisaient partie des drivers de leurs cartes graphiques...)
Quelqu'un sait si ils seront backportés vers les 2.4.x ?
[^] # Re: Linux 2.6 est pour bientot...
Posté par Christophe Merlet (site web personnel) . Évalué à 2.
[^] # Re: Linux 2.6 est pour bientot...
Posté par couriousous . Évalué à 3.
# Re: Linux 2.6 est pour bientot...
Posté par Gyro Gearllose . Évalué à 1.
L'un d'entre vous sait-il si il existe une option du make qui permette de positionner toutes les options par défaut, suivant le matériel sur lequel il est lancé ? Par exemple, j'aimerai bien, moi, que quand je lance un make menuconfig sur mon LFSKernel, que le make broute les ressources CPU le temps qu'il lui faut pour chercher ce qui lui semble correct (processeur, chipset, type de clavier, cartes d'extension installées, etc.). Après, je vais fouiller dans les menus pour lui dire : ma carte réseau, je ne la veux pas en module, mais la carte son, oui ; bref, ce genre de chose. Un peu comme un cat /proc récursif intelligent. Si ça n'existe pas, est-ce dans les wish list ?
Je sais, ça parrait être une option de feignant (je sais, j'en suis un !), mais d'un autre côté, ça laisserait la possibilité à l'utilisateur "moyen" de se compiler un kernel supportant son matos, et un tant soit peu optimisé, sans trop d'effort. Moi, y'a plein d'options auxquelles je ne touche pas de peur de tout foutre par terre et de ne plus pouvoir booter. De plus, j'ai pas trop de temps à perdre à essayer d'améliorer le système, donc, quand ça fonctionne, je ne touche plus à rien. Ce qui est peut-être une connerie, car rien n'est vraiment optimisé ! Enfin ce que j'en dit.
Merci pour vos éclaircissements en tout cas.
[^] # Re: Linux 2.6 est pour bientot...
Posté par N/A . Évalué à 0.
[^] # Re: Linux 2.6 est pour bientot...
Posté par Gyro Gearllose . Évalué à 1.
Je pensais vraiment à une compile à la mimine du kernel. C'est pas donné à tout le monde de soulever le capot pour aller voir le n° du chip sur la carte Tv ou la carte son. Si on veut ouvrir Linux au grand public, au contraire, il me semble qu'une reconnaissance auto du matos à la compil serait idéale. Après tout, c'est pas parce que je sais Kompiler KDE avec Konstruct que je sais compiler un kernel proprement. Vous saisissez la nuance ?
Et puis, on pourrais mettre en regard Xp par ex et Linux. "Moi, j'ai branché mon truc dans la boîte, j'ai fermé et XP a reconnu le matos tout de suite", vs "Moi, j'ai branché le truc dans la boîte, et j'ai du recompiler un kernel pour que ça marche, mais comme il me posait pleins de questions gênantes (options du module, n° de chip, etc.), ben j'ai mis 3 mois pour que ça marche...".
Y'a pas photo....
[^] # Re: Linux 2.6 est pour bientot...
Posté par Pierre Tramal (site web personnel) . Évalué à 2.
- Concernant l'autodétection du matériel, celle ci n'est pas automatique sous Linux (et plein d'autres OS) et c'est tant mieux: l'installation de drivers sous Linux est peut être difficile (mais c'est subjectif et c'est surtout une question d'habitude) mais au moins c'est fait une bonne fois par toute, et il n'y a pas besoin de jouer dans le panneau de config. d'XP, qui SEMBLE être une référence dans le domaine de la simplicité d'utilisation... Cela n'est pas l'avis des neu²^Wutilisateurs qui n'arrivent pas à installer leur imprimante sous Ickspai.
- De toute manière pas mal de distribs proposent aujourd'hui l'autodétection du matériel "à la Windows", ca peut être un premier pas dans la découverte de Linux, mais par la suite, un utilisateur digne de ce nom doit AMHA savoir recompiler un noyau sans tout casser (je me rappelle personnellement avoir tout cassé à de nombreuses reprises mon système [en 1998, sous un redhat 5.1 :)] en tentant de recompiler la bestiole).
[^] # Re: Linux 2.6 est pour bientot...
Posté par Gyro Gearllose . Évalué à 1.
[^] # Re: Linux 2.6 est pour bientot...
Posté par PLuG . Évalué à 1.
Je sais recompiler un kernel *kivabien* sur une machine, ayant commencé a utiliser linux avec le noyau 0.99pl5 c'etait plus que necessaire et bien moins facile (interface rudimentaire en mode texte ...)
Et bien figure toi que je ne recompile quasiement jamais de kernel maintenant et ce depuis quelques annees. Et quand je recompile, c'est pour passer des patchs (carte wireless en mode monitor ...) et recompiler a l'identique avec le .config fourni par la distrib.
a une epoque j'avais fait des mesures de perfs entre un noyau compile pour le bon cpu (PII) et celui par defaut (i386) sur un serveur samba over chargé. pas de différence significative. En fait, ma théorie c'est qu'a recompiler toi meme ton noyau tu va lire de la doc et apprendre beaucoup. te tromper, relire de la doc et apprendre encore. Mais crois moi, le *gain* en performance ne sera pas au rendez vous d'un tunning de .config. A une epoque il fallait changer des valeurs dans les includes du kernel pour le tuner, maintenant on a /proc/sys pour quasiement tout modifier (file handles, vm, network ...) bref plus besoin de recompiler a tout va.
aujourd'hui le tunning c'est donc /proc/sys , hdparm, ...
[^] # Re: Linux 2.6 est pour bientot...
Posté par Rin Jin (site web personnel) . Évalué à 4.
[^] # Re: Linux 2.6 est pour bientot...
Posté par benja . Évalué à 1.
Dans la pluspart des cas, un bon lspci suffit...
# Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.