La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux => Discussion démarrée par: vivien le 10 septembre 2024 à 15:35:25
-
Inflation de la taille du noyau Linux et de ses pilotes
Il est loin l'époque où le noyau Linux et ses pilotes prenaient moins de 1 Mo.
Depuis des années, la taille double tous les 1 à 2 ans.
Par exemple, avec Ubuntu 24.04 le noyau et ses pilotes (le gros paquet linux-firmware) pèsent maintenant 675 Mo !
(https://lafibre.info/testdebit/ubuntu/202409_ubuntu_2404_taille_noyau_linux.webp)
Je ne sais pas s'il y a une solution possible.
En même temps, le très bon support matériel de Linux est aujourd'hui une force.
On peut acheter un PC de dernière génération et on sait que tous les périphériques vont fonctionner directement.
-
@vivien :
On peut compiler son noyau et ne sélectionner que les modules requis pour faire fonctionner sa machine. Ce n'est définitivement pas à la portée de tous.
Les Anciens qui utilisent Gentoo le font certainement. Peut-être aussi les développeurs Linux.
Il y avait aussi le livre de Greg Kroah-Hartman mais je trouve qu'il est devenu trop ancien. (http://www.kroah.com/lkn/)
-
Ca paraît plus granulaire sur fedora (mais je ne m'amuse pas non plus à enlever des packages)
$ sudo dnf list installed *firmware |wc -l
22
$ sudo dnf repoquery --qf "%{size} %{name}-%{version}" *firmware* |wc
Last metadata expiration check: 0:18:57 ago on Tue 10 Sep 2024 03:48:50 PM CEST.
87 174 3027
$ sudo dnf repoquery --qf "%{size} %{name}-%{version}" *firmware* |head
Last metadata expiration check: 0:19:11 ago on Tue 10 Sep 2024 03:48:50 PM CEST.
10044983 brcmfmac-firmware-20240312
10050097 brcmfmac-firmware-20240811
103794 r5u87x-firmware-0.2.0
104715 ivtv-firmware-20080701
1143586 cirrus-audio-firmware-20240312
1148248 cirrus-audio-firmware-20240811
1182829 crystalhd-firmware-3.10.0
12492 linux-firmware-vendor-20231219.1
12525700 mt7xxx-firmware-20240811
12602703 mt7xxx-firmware-20240312
-
On peut compiler son noyau et ne sélectionner que les modules requis pour faire fonctionner sa machine.
Oui, c'était nécessaire il y a de nombreuses années (il y a plus de 20 ans).
Cela me rappelle de vieux souvenirs...
J'y ai passé du temps.
-
Cela me rappelle de vieux souvenirs...
Et pour des souvenirs encore plus lointains, ça me rappelle l'époque où j'installais des "UNIX" sur PC-AT avec un jeu de disquette 5" 1/4. On "croisait" les doigts au moment du reboot, après avoir installé une vingtaine de disquettes. Parfois, ça ne démarrait pas ...
A l'époque, c'était évidemment sur architecture 16 bits, noyau monolithique, mais il était assez facile d'écrire des drivers et de recompiler le noyau. On le faisait pour des cartes d'interface (multiport RS 232), des disques durs, etc ou tout simplement pour changer des paramètres du noyau (pas de sysctl)
-
Et pour des souvenirs encore plus lointains, ça me rappelle l'époque où j'installais des "UNIX" sur PC-AT avec un jeu de disquette 5" 1/4. On "croisait" les doigts au moment du reboot, après avoir installé une vingtaine de disquettes. Parfois, ça ne démarrait pas ...
A l'époque, c'était évidemment sur architecture 16 bits, noyau monolithique, mais il était assez facile d'écrire des drivers et de recompiler le noyau. On le faisait pour des cartes d'interface (multiport RS 232), des disques durs, etc ou tout simplement pour changer des paramètres du noyau (pas de sysctl)
Il y a eu des Unix en 16 bits sur x86? Sur PC-AT 286? Je ne savais pas.
C'était quoi comme Unix, stp? Tu te souviens? Ca m'intéresse.
Tous les Unix que je connais sont en 32 bits ou 64 bits. Donc 386 au pire.
Leon.
-
Il y a eu des Unix en 16 bits sur x86? Sur PC-AT 286? Je ne savais pas.
C'était quoi comme Unix, stp? Tu te souviens? Ca m'intéresse.
Tous les Unix que je connais sont en 32 bits ou 64 bits. Donc 386 au pire.
C'est que je suis encore plus vieux que toi ... mais je me souviens, la sénilité ne m'a pas gagné.
En 1986, j'ai commencé à travailler dans le cadre de mon service national sur un système Unix sur PC (Goupil G40), donc sur processeur 80286.
On était 3 "scientifiques du contingent" à développer en Pascal, qui était en fait un traducteur Pascal - C sur cette machine.
On s'y connectait avec des terminaux (type VT) branchés en série sur ligne RS 232.
A cette époque, l'espace adressable par un programme était 64 kO, ce qui nous posait quelques difficultés (même pour des programmes en "curses").
J'ai ensuite, en 1987, rejoint la société qui importait en France cet OS fabriqué par la société VenturCom. Le produit s'appelait Venix. Le concurrent principal était Xenix distribué par SCO.
Peu de temps après sont apparues des versions 32 bits effectivement (un concurrent connu : Interactive Systems 386 ix).
(et pour finir sur ce rappel historique : dès 1987, la société dans laquelle je travaillais importait des "packages TCP/IP" pour apporter des couches "réseau" sur des OS qui n'en disposaient pas en standard, comme les VAX VMS de DEC. Le câblage se faisait en Thick Ethernet).
J'arrête ici pour mes histoires de vétéran ...
-
Oui, c'était nécessaire il y a de nombreuses années (il y a plus de 20 ans).
Cela me rappelle de vieux souvenirs...
J'y ai passé du temps.
Pour ma part, l'intérêt de l'exercice s'était renouvelé avec la possibilité des noyaux EFI STUB.
Beau souvenir que le premier boot direct sur un kernel monolithique aux oignons. Derrière un clavier, l'épure est la seule quête qui vaille ! ;D
-
Compiler soi-même son noyau, c'est généralement ne plus y toucher de nombreux mois, et donc ne pas corriger les failles de sécurité, non ?
-
Compiler soi-même son noyau, c'est généralement ne plus y toucher de nombreux mois, et donc ne pas corriger les failles de sécurité, non ?
Un script de mise à jour est facile à mettre en place. Et puis limiter les options, c'est aussi théoriquement limiter les possibilités de bugs et donc de failles non ?
J'ai toujours considéré le noyau comme un logiciel comme un autre pour les mises à jour : paradoxalement, mettre à jour souvent limite la casse. Rien de pire que de sauter 5 versions majeures et de bâcler la mise à jour.
Entre une config standard de debian avec 6k lignes dans le .config et une config custom 1-2k lignes, le choix est vite fait.
-
Bonjour,
Est-ce que cette taille de noyau grandissante pourrait finir par être un problème vu l'évolution des capacités des SSD ? Mon 1er portable avec un SSD avait une capacité de 120Go. Maintenant 256 ou 512 semble être la norme.
Comme indiqué dans le 1er post, si cela permet d'avoir la quasi assurance que tout fonctionne "out of the box" c'est quand même sympa.
Même si bien sûr cela ne met pas à l'abri des erreurs ou bug. J'ai le cas sur ma machine actuelle : Le driver nécessaire à la gestion de l'écran est absent des dernières versions. Ceci depuis au moins 6.2 de mémoire. Donc ma config est plus fonctionnelle avec le kernel GA de Ubuntu 22.04 plus ancien mais plus petit en taille. Et cela me "bloque" sur cette version.
Est-ce qu'il est imaginable, dans le futur, qu'avant l'installation la machine soit "évaluée" par le programme d'installation lors de la session live pour ne télécharger/installer que le nécessaire ? Avec les capacité disques et les connexions fibres, je suis pas certain que l’intérêt soit énorme pour les particulier en tout cas.
Bonne journée
-
Le noyau compilé ne prends pas beaucoup de place. C'est l'ensemble des firmwares le problème. Mais il est possible d'avoir une gestion plus fine. C'est le cas de certaines distributions. Après, il suffit de pas prendre le paquet et de chercher manuellement les quelques fichiers nécessaires. A part les microcodes de processeurs qui ont des paquets à part, les mises à jours ne sont pas courantes non plus.
-
Ça bouge quand même régulièrement https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/ (https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/)
C'est aussi pour ça que garder un noyaux fourni avec la distribution qui fourni aussi les firmware c'est quand même préférable hors cas très spécifique.
-
A part les microcodes de processeurs qui ont des paquets à part, les mises à jours ne sont pas courantes non plus.
14 jours plus tard, on passe de la version 2.3 à la version 2.4, avec de nouveau 484 Mo de firmware à télécharger sur tous les postes (la taille a augmenté de 500 Ko).
(https://lafibre.info/testdebit/ubuntu/202409_ubuntu_2404_taille_noyau_linux_2.webp)
-
Cela mériterait quand même une gestion plus fine franchement.
Ubuntu n'a pas un système de delta entre les versions de paquets comme opensuse ? (EDIT : oups https://fedoraproject.org/wiki/Changes/Drop_Delta_RPMs)
-
j'ai du mal a voir en quoi c'est un probleme
500Mo ou 2go franchement, osef non ? Ou ca change quelque chose pour quelqu'un ?
-
Les mises à jour représentent un poids non négligeable.
Imagine que tu as 500 postes, cela fait du volume.
C'est également le cas de Windows.
Je viens de changer de PC préinstallé Windows 11 (il va bientôt passer sous Ubuntu), j'ai regardé : Le démarrage et les mises à jour de toutes les applications ont pris 10 Go sur ma connexion.
-
d'où ma question : qu'est ce que ca change ?
J'ai aussi quelques dizaines de linux en prod et la consommation de bande passante pour telecharger les mise a jour...... heu, comment te dire que c'est le dernier de mes soucis ?
qu'on me reponde "moi je dors mieux la nuit si le kernel fait 10mo de moins", ok je peux comprendre, mais a part ca ?
-
Les aficionados du logiciel libre ont souvent fait référence aux blobs propriétaires (notamment les micrologiciels, alias firmwares) dans leur système d'exploitation.
En fait, c'est assez drôle en y pensant, car blob signifie « objet binaire large » (binary large object).
-
Le support des pilotes des périphériques sous Windows est assuré par le fabriquant. Une fois le matériel en fin de vie, le support finit par ne plus être assuré. Il peut y avoir des traces sur le net, mais on finit un jour par devoir croiser les doigts pour espérer faire fonctionner un périphérique sur un Windows récent. Je pense par exemple à certains périphériques à longue durée de vie sur Windows serveur. Je ne peux manquer de sourire en écrivant ces 2 mots collés l'un à l'autre, mais nombreuses sont les sociétés prisonnières (in)volontaires de cet écosystème toxique.
Sous linux, par contre, les pilotes disposent de sources, dans la très très grande majorité des cas. Il se peut que, parfois, pour pouvoir utiliser un équipement aux performances particulièrement brillantes, suivez mon regard sur la carte vidéo RTX de nos rêves, on sacrifie au rite pour compiler un très très gros binaire propriétaire linké dans un pseudo pilote interface aux sources ouvertes. Dans la très grande majorité des cas, les pilotes sont open source, et peuvent se compiler depuis un noyau vétuste jusqu'aux plus récents.
Le noyau linux, qui embarque les sources de tous ces pilotes de périphériques, et dieu sait qu'ils sont nombreux, voit donc sa taille enfler sans arrêt.
Les firmware, qui sont des pilotes de plus bas niveau injectés par le pilote noyau dans le périphérique pour en assurer le démarrage et le fonctionnement, voilà encore un blob propriétaire. Plus les périphériques sont nombreux, plus on compte de firmware. Un firmware de périphérique entre dans le noyau pour, pour ainsi dire, n'en plus jamais sortir.
Je ne trouve absolument pas hors de propos de compiler son noyau, même sur une Debian. Nombreux sont les outils qui permettent de le faire de façon remarquablement automatique. La gymnastique consiste fondamentalement à garder une vision globale des différents composants du noyau, et à, une fois l'effort de compiler une fois un noyau adapté à une configuration matérielle donnée, lire attentivement les indications d'aide d'un "make oldconfig" pour évaluer rapidement si la nouveauté mérite d'être intégrée ou pas.
Pour ma modeste part, tant que je ne vole pas sur MSFS, je reste sous linux, distribution Gentoo, avec un noyau très récent, compilé en statique sauf le pilote nvidia.
J'ai eu jusqu'à récemment des bases de données relativement volumineuses et à trafic soutenu, sur un système Debian auquel j'avais ajouté un noyau minimaliste aux options sélectionnées à la main. Les performances s'en ressentaient.
La compilation du noyau Linux de sa station, il ne faut pas en avoir peur. Une machine récente 16C/32T boucle l'affaire en moins de 1'30''.
Si on a pas fait ça depuis très longtemps, au début, ça pique, mais pour aider à produire une configuration utilisant juste les pilotes adaptés à une configuration matérielle, sans support des chargement de module dynamique, des pistes sont prévues dans le noyau standard.
Prenez une machine linux, lancée, téléchargez les sources du noyau identique au noyau actif, branchez tous vos périphériques, tous, et rendez vous à
#cd /usr/src/linux
Lancez un
# lsmod > /tmp/mylsmod
# make LSMOD=/tmp/mylsmod localmodconfig
# make localmodconfig
Cette option :
- Analyse les modules actuellement chargés sur le système (via la commande lsmod).
- Crée une nouvelle configuration du noyau qui n'active que les options nécessaires pour ces modules chargés.
- Désactive toutes les options de modules qui ne sont pas nécessaires pour les modules actuellement chargés.
- Conserve les paramètres des modules (compilés en tant que modules ou intégrés) tels qu'ils sont dans la configuration actuelle.
L'objectif principal est de créer une configuration minimale du noyau adaptée au matériel et aux fonctionnalités actuellement utilisés sur le système.
Déjà, avec ça, on a juste le nécessaire.
On peut pousser plus loin:
# make localyesconfig
Cette option fonctionne de manière similaire à localmodconfig, mais avec une différence clé :
- Elle configure tous les modules actuellement chargés pour être compilés directement dans le noyau (built-in) plutôt que comme modules chargeables.
- Cela peut permettre de se passer d'un initramfs dans certains cas
Là, on a juste géré ses pilotes de périphériques. On peut choisir spécifiquement de nombreuses options dans d'autres parties, comme:
- Options générales
- Configuration générale du système - Osons rentrer dedans
- Support des architectures matérielles - générer un binaire non générique, plus adapté à son processeur top sexy
- Options de débogage et de profilage - parfois utiles quand ça plante. On remonte un bug upstream
- Gestion du matériel
- Pilotes de périphériques (disques, cartes réseau, cartes graphiques, etc.)
- Support des bus et interfaces (PCI, USB, SCSI, etc.) - ATA, souvent encore présent, SCSI, à évincer
- Gestion de l'énergie (ACPI, APM) - Indispensable sur un laptop, éventuellement une station, moins utiles sur un serveur à charge constante
- Systèmes de fichiers
- Systèmes de fichiers natifs (ext4, XFS, Btrfs, etc.) - Autant j'en mets un paquet sur mon laptop qui sert de couteau suisse, autant on peut se passer de reiserfs ou d'autres
- Systèmes de fichiers réseau (NFS, CIFS, etc.) - idem
- Systèmes de fichiers virtuels (procfs, sysfs) - attention avec ceux là
- Réseau
- Protocoles réseau (IPv4, IPv6, etc.)
- Pare-feu et filtrage de paquets (Netfilter)
- Support des technologies réseau sans fil - désactivé sur ma station connectée en 10Gbps, par exemple
- Sécurité
- Contrôle d'accès (SELinux, AppArmor) - vade retro la NSA. En aucun cas je ne prête la moindre confiance dans le moindre bout de code fournit par eux. Déjà qu'ils ont la Trusted Platform...
- Chiffrement et cryptographie - beaucoup moins inutile qu'on ne pense.
- Audit de sécurité - diminuer l'exposition aux attaques par canaux auxiliaires, durcissement de pile, etc
- Virtualisation et conteneurisation
- Support des hyperviseurs (KVM, Xen)
- Conteneurisation (cgroups, namespaces)
- Multimédia et son
- Pilotes audio
- Support des codecs et frameworks multimédias
- Optimisation des performances
- Ordonnanceurs CPU et I/O - haaa, l'ordonnanceur Brain Fuck Scheduler de Con Kolivas (https://ck-hack.blogspot.com/)...
- Gestion de la mémoire et du swap
Bref, il n'y a que du bon à gratter à compiler son noyau Linux.
Il faut se lancer.
-
Ubuntu 24.10 passe la barre des 500 Mo : (c'est le noyau Linux 6.11 qui est utilisé)
(https://lafibre.info/testdebit/ubuntu/202411_ubuntu_2410_taille_noyau_linux_6-11.webp)
-
Ubuntu 24.10 passe la barre des 500 Mo : (c'est le noyau Linux 6.11 qui est utilisé)
Ce sont tous les firmware bouts à bouts, de tous les périphériques en ayant besoin, qui pèsent 500Mo, dans ce cas.
Dans tous les cas, vu que les sources du noyau contiennent les sources des pilotes eux mêmes, la tendance va légitimement vers l'inflation.
Fondamentalement, la somme des firmware de périphériques divers augmente plus vite que les sources même du noyau.
Pour Gentoo
# emerge -pv sys-kernel/linux-firmware sys-kernel/gentoo-sources
These are the packages that would be merged, in order:
Calculating dependencies... done!
Dependency resolution took 3.08 s (backtrack: 0/20).
[ebuild U ] sys-kernel/linux-firmware-20241110::gentoo 396 088 KiB
[ebuild NS ] sys-kernel/gentoo-sources-6.12.1:6.12.1::gentoo 144 451 KiB
Total: 2 packages (1 upgrade, 1 in new slot), Size of downloads: 540 539 KiB
Si l'on prend le dernier kernel disponible sur kernel.org, le 6.12.1 à cette heure, le tarballen .xz pèse 147,9Mo, et l'archive dépliée atteint 1.5Go
-
A part les microcodes de processeurs qui ont des paquets à part, les mises à jours ne sont pas courantes non plus.
Décembre 2024
(https://lafibre.info/testdebit/ubuntu/202412_ubuntu_2410_taille_noyau_linux_6-11.webp)
Janvier 2025
(https://lafibre.info/testdebit/ubuntu/202501_ubuntu_2410_taille_noyau_linux_6-11.webp)
Mars 2025
(https://lafibre.info/testdebit/ubuntu/202503_ubuntu_2410_taille_noyau_linux_6-11.webp)
Avril 2025
(https://lafibre.info/testdebit/ubuntu/202504_ubuntu_2410_taille_noyau_linux_6-11.webp)
Ubuntu 25.04
Mai 2025
(https://lafibre.info/testdebit/ubuntu/202505_ubuntu_2504_taille_noyau_linux_6-14.webp)
Juin 2025
(https://lafibre.info/testdebit/ubuntu/202506_ubuntu_2504_taille_noyau_linux_6-14.webp)
-
Vivien,
Pourquoi mettre cette citation à chaque fois ? ...
Forcément, avec le grand nombre de firmwares, il y a de quoi faire des mises à jour tous les mois.
Mais si tu prends un système donné, il y a peu de mises à jour par composant.
Par exemple pour cirrus, qui apparait souvent dans tes screenshots. Si on sélectionne un firmware et qu'on regarde les logs :
path: root/cirrus/cs35l41-dsp1-spk-cali-103c896e-l0.bin
Age Commit message (Expand) Author Files Lines
2024-04-23 linux-firmware: Remove Calibration Firmware and Tuning for CS35L41 Stefan Binding 1 -0/+0
2022-10-14 linux-firmware: Add firmware for Cirrus CS35L41 on HP Laptops Stefan Binding 1 -0/+0
Tu prends un firmware ath9k/ath10k, même chose, une mise à jour par an max.
-
Le système n'est pas bien fait pour la mise à jour de quelques centaines Ko de drivers, on doit mettre à jour chaque mois (ou presque) un fichier de plus de 500 Mo.
-
Bonjour connaissez vous GNU Hurd, la collection de serveurs qui utilise le micronoyau Mach ?
-
Debian GNU/Hurd reste un système expérimental, dont la stabilité et les performances sont loin de celles de Debian GNU/Linux.
Il y a également les BSD en alternative, mais cela a un impact fort sur la compatibilité matérielle et la simplicité.
-
GNU Hurd, combien de divisions ? Je ne connais personne qui l'utilise.
Le noyau monolithique de Linux a au moins un mérite, c'est que tout est sous licences GPL v2. Avec un micronoyau, il pourrait y a voir des modules sous différentes licences. Je n'imagine même pas les problèmes de licences incompatibles, ou demandant d'utiliser tel module sous telles conditions.
A côté des options techniques, on oublie trop souvent le problème des licences.
-
Bonjour connaissez vous GNU Hurd, la collection de serveurs qui utilise le micronoyau Mach ?
Haiku, le système héritier de la lignée BeOS, par jean louis gassée, ancien président d'apple france qui avait tenté de faire virer steve jobs dans les années 80, est certainement plus utilisé que hurd, qui tire dans ses racines le noyau Mach d'Avie Tevanian, qui est à la base, avec des ptits bouts de freebsd, de darwin, le système dans macos/ios.
On pourrait se demander quel OS grand public pourrait utiliser hurd aujourd'hui : à part des chercheurs par ci par là, je crois que juste personne connait. Même plan9 est davantage utilisé que hurd ;)
-
On sait aussi sous Linux les difficultés à mettre à jour le noyau quand un module est externe est inclus, en particulier un driver blob de carte graphique. Donc si tous les drivers étaient comme cela, j'aurais les plus grosses craintes.
-
Bonjour,
Peut-être un premier pas vers une (légère) réduction de la taille des noyaux avec l'arrêt du support des anciens matériels : https://macbidouille.com/news/2025/05/11/le-kernel-linux-va-abandonner-le-486
Bonne journée