[kernel] Jusqu'où ira le bloat ?

[catwell]

J'adore GNU/Linux et Arch en particulier principalement parce que ça me permet d'avoir un système relativement "KISS", en installant les bons logiciels. Il n'y a qu'une seule partie de tout ça qui ne l'est pas vraiment... le noyau !

En effet, le nombre de lignes de code dans le noyau ne cesse d'augmenter, et ses performances décroissent parfois. Mais surtout, il est maintenant si complexe qu'il est impossible de comprendre comment il fonctionne pour un informaticien moyen.

Alors bon, il y a des raisons d'avoir peur quand Linus déclare ça :

We’re getting bloated and huge. Yes, it’s a problem.
I’d like to say we have a plan [audience laughs].
Sometimes it’s a bit sad that were are definitely not the streamlined, small hyper efficient kernel I envisioned 15 years ago. The kernel is huge and bloated and our iCache footprint is scary. There’s no question about that, and whenever we add a new feature, it only gets worse.

Ça pourrait presque me pousser à me demander si un fork qui ne se soucie que du support de x86_64 sur des machines "normales" (ie. ni de l'embarqué ni des clusters) ne serait pas une bonne chose.

[farvardin]

où est le problème ? Lors que la compilation il n'y a que les parties qui concernent ton architecture qui sont incluses dans le noyau qui se retrouvera sur ton ordinateur. Et le reste du support matériel arrivera dans les modules. Donc ton noyau (qui fait sans doute dans les 1,5 ou 2 Mo) n'incluera pas du code pour Arm ni le support du système de fichier amiga.
Et si tu veux vraiment épurer encore plus, tu peux recompiler ton propre noyau pour le réduire encore.

[catwell]

Bien sûr que le noyau compilé n'inclut pas tout. Mais ce n'est pas parce que tu mets des #ifdef que tu réduis la complexité du code, ça ne règle pas le problème de compréhension.

En plus, le support d'autres architectures oblige à toujours découpler ce qui dépend de l'architecture de ce qui n'en dépend pas. Ça a un impact sur la complexité du code et sur ses performances. Sans parler des choix par défaut qui sont faits pour contenter tout le monde (on fait au "moins pire"), comme le scheduler par exemple...

[farvardin]

je n'y connais pas grand chose dans ce genre de programmation, mais du peu que j'ai fait dans un autre domaine, il était plus simple d'avoir un seul code avec des conditions, plutôt que plusieurs versions impossibles à synchroniser.

Je pense qu'un fork du noyau n'irait pas très loin. En plus tu parles de x86_64, ce qui veut dire que si seule cette archi est supporté, si tu as un ordinateur en x86_64 ça ira, mais si tu récupères un netbook en x86 de base, tu devras prendre un autre type de noyau ?

Si tu veux quelque chose de plus simple, pourquoi ne pas lorgner du côté de Haiku ? Là cela ne vise que le x86 et qu'une utilisation (bureau).

[catwell]

Ouaip, je connais Haiku, depuis la sortie de l'alpha j'envisage de l'installer mais c'est trop graphique pour moi. J'utilise déjà Minix3 sur une autre machine aussi...

Le x86_64 était une typo, je voulais juste dire x86.