est-ce qu'en commande (apt-get update / upgrade) ça fait pareil ?
il te prend 600Mo sur le réseau à chaque fois ?
ou c'est juste en graphique ?

Même chose en ligne de commande.

avec 1,4Go après une installation fraiche

Debian pèse plus que ça
là tu parles de l'installation sans interface graphique

Debian ne convient pas en graphique pour ton (très) petit disque dur

oui en gros c'est la force de Linux d'avoir tout qui marche presque partout dès le démarrage
mais ça ne prend pas de place dans le noyau

C'est valable pour toutes les distributions Linux? Ou alors juste Ubuntu?
Sur tous les linux, on met dans le noyau tous les drivers et firmware de tous les matériels courants des 20 dernières années?
C'est franchement pas clair pour moi, pas facile à comprendre.

Il y a plusieurs choses :
 - le kernel lui-même : il y a le code de base, et certains drivers que la distribution choisit d'intégrer directement, il peut y avoir plusieurs variantes (par exemple une version "cloud" allégée qui ne contient que ce qui est nécessaire pour les VM habituelles)
 - les modules (drivers compilés en fichiers séparés), qui sont en général regroupés en plusieurs paquets (au moins un de base, et un "extra" pour le matériel plus rarement utilisé)
 - les firmwares : il y en a de plus en plus, beaucoup de périphériques ne fonctionnent pas sans (ou de manière très limitée), les distributions commencent à découper un peu pour éviter de tout avoir
 - l'initrd : il doit contenir un certain nombre de programmes, et des modules nécessaires au boot (drivers pour le disque ou le réseau, le GPU, ...), il peut être déjà généré (donc gros), ou l'être au moment de l'installation du paquet (et là on peut parfois choisir la liste des modules intégrés, par exemple de faire une version la plus minimaliste possible sans les fonctionalités et drivers non nécessaires à une machine donnée, quitte à ce que ça pose problème en cas de changement de HW)

Par rapport à un Windows, la philosophie est différente.
Même si c'est moins le cas aujourd'hui, Windows n'aime pas les changements de matériel : si on prend un disque et qu'on le met sur un autre PC, il n'est pas sûr qu'on puisse booter sans avoir à réinstaller (et dans tous les cas le premier boot sera long, et il faudra potentiellement rebooter ensuite avant de tout avoir de fonctionnel).
Linux au contraire a très peu de paramètres statiques liés au matériel, et a par défaut la majorité des drivers déjà installés, donc il est beaucoup plus simple de booter sur un autre PC (parfois c'est totalement transparent).
C'est notamment ça qui permet un Linux bootable depuis un DVD / une clé USB en étant très proche de la version installée, alors que les équivalents Windows sont pleins de contournements et loin d'être complets.

Rien n'interdirait de faire un Linux qui télécharge les drivers et firmwares de manière individuelle et à la demande, mais ce serait un énorme travail pour la distribution.
Il faudrait que les modules soient téléchargeables en tant que fichiers individuels, mais quand même mis à jour, avec un système pour suivre les dépendances et les modalias (d'une version à l'autre, le module à utiliser pour un contrôleur donné peut changer, ou se mettre à dépendre d'un module supplémentaire).
Et tout devrait être conservé sur les serveurs : si un utilisateur n'a pas mis à jour son kernel depuis 3 mois et branche un nouveau périphérique USB, il faudrait qu'il puisse télécharger le module (l'ABI n'étant pas stable, ça doit être celui qui correspond à la version et configuration du kernel qu'il a, ou presque).

Cela dépends des choix de ta distribution.
La stratégie la plus commune est de fournir un INITial RamDisk qui contient suffisamment de module critique pour trouver le volume système puis charger le reste.
La définition de "suffisamment de module critique" est différente entre Fedora (qui spécialise par défaut pour la machine) et Debian.

On parlait de drivers et firmware dans la discussion. Est-ce que ce sont des cas particuliers de "modules" dont tu parles?
Si oui, ça voudrait dire que Fedora n'installe que les firmware et drivers nécessaires pour chaque machine, alors que Ubuntu installe TOUT?

Par rapport à un Windows, la philosophie est différente.
Même si c'est moins le cas aujourd'hui, Windows n'aime pas les changements de matériel : si on prend un disque et qu'on le met sur un autre PC, il n'est pas sûr qu'on puisse booter sans avoir à réinstaller (et dans tous les cas le premier boot sera long, et il faudra potentiellement rebooter ensuite avant de tout avoir de fonctionnel).

Depuis les tous premiers Windows 10, la transplantation de disque dur / installation entre machines hétérogènes, ça fonctionne bien, de ce que j'ai constaté. Avant ça n'était pas le cas.

Rien n'interdirait de faire un Linux qui télécharge les drivers et firmwares de manière individuelle et à la demande, mais ce serait un énorme travail pour la distribution.
Il faudrait que les modules soient téléchargeables en tant que fichiers individuels, mais quand même mis à jour, avec un système pour suivre les dépendances et les modalias (d'une version à l'autre, le module à utiliser pour un contrôleur donné peut changer, ou se mettre à dépendre d'un module supplémentaire).

Travail énorme que Microsoft fait déjà?
Et il faut sans doute distinguer le fait de télécharger tout ou partie les drivers/firmwares et le fait d'installer tout ou partie de ces drivers/firmwares.

---

Parce que Linux, contrairement à Windows, ne garantit aucune stabilité de son ABI. Si un pilote est laissé en dehors du noyau, il devient incompatible très vite et se casse à la prochaine màj du noyau. En étant intégré aux mêmes dépôts de code source que le noyau, ça permet de s'assurer que les màj du noyau ne vont rien casser.

Et tout devrait être conservé sur les serveurs : si un utilisateur n'a pas mis à jour son kernel depuis 3 mois et branche un nouveau périphérique USB, il faudrait qu'il puisse télécharger le module (l'ABI n'étant pas stable, ça doit être celui qui correspond à la version et configuration du kernel qu'il a, ou presque).

On en revient à l'ABI Kernel linux instable entre les mises à jour. Est-ce qu'il faut comprendre que c'est le coeur du problème autour de Linux et des drivers? Qui oblige à embarquer les drivers avec le kernel? Si c'est confirmé, c'est quand même une sacrée contrainte, difficile à comprendre quand on vient d'un monde Windows.

Leon.

On parlait de drivers et firmware dans la discussion. Est-ce que ce sont des cas particuliers de "modules" dont tu parles?

Habituellement ce qu'on appelle un module, c'est du code qui peut être chargé dynamiquement dans le kernel, et qui est dans un *.ko (comme les *.sys sous Windows).
Mais en fait un module dont les sources sont dans le kernel peut être compilé en module, intégré au kernel, ou désactivé (c'est dans la configuration).
Il y a des modules qui ne sont pas des drivers de périphériques, mais des parties du kernel : des bases communes à plusieurs drivers, des algos (crypto, protocoles réseau, fonctions du firewall, ...), ...

Les firmwares, c'est habituellement du code exécuté sur un microprocesseur embarqué (dans le CPU, le chipset, un périphérique, ...).
Ce sont des fichiers qui sont dynamiquement chargés par les drivers, et qui sont envoyés au périphérique (qui va les garder dans sa RAM).

Si oui, ça voudrait dire que Fedora n'installe que les firmware et drivers nécessaires pour chaque machine, alors que Ubuntu installe TOUT?

Non, il y a un découpage base/extra qui n'est pas forcément le même, mais il n'y a aucun cas où Fedora filtre à l'installation (le /lib/modules de la partition principale contient un grand nombre de modules).
En revanche, dracut (l'outil de génération d'initrd utilisé par Fedora) permet de générer un initrd spécifique à la machine, dans lequel il n'y aura que les modules nécessaires au boot.

Travail énorme que Microsoft fait déjà?

Oui, pour les drivers qui sont sur Windows Update (donc pas la totalité).
Mais le kernel Windows a une ABI stable, donc un driver n'a pas besoin d'être modifié (ou même recompilé) à chaque version du kernel.

---

On en revient à l'ABI Kernel linux instable entre les mises à jour. Est-ce qu'il faut comprendre que c'est le coeur du problème autour de Linux et des drivers? Qui oblige à embarquer les drivers avec le kernel? Si c'est confirmé, c'est quand même une sacrée contrainte, difficile à comprendre quand on vient d'un monde Windows.

Ca a aussi des avantages, notamment :
 - le kernel peut évoluer plus facilement, en n'ayant pas besoin de versionner chaque changement et de garder d'anciennes APIs
 - le kernel peut être plus optimisé, notamment pour l'embarqué : des parties peuvent être désactivées en fonction de la configuration, en simplifiant les structures de données
https://www.kernel.org/doc/Documentation/process/stable-api-nonsense.rst

Pour Android, Google a developpé KMI (https://source.android.com/docs/core/architecture/kernel/stable-kmi) pour permettre de séparer d'un côté :
 - les mises à jour de sécurité sur le kernel GKI (qui est fourni par Google, et doit être utilisé tel-quel), qui peuvent se mettre à jour sur les branches stable du kernel (par exemple 6.1.x => 6.1.y)
 - les modules vendeur compilés par le fabricant (et dont les sources viennent souvent du vendeur du SoC)
Mais c'est avec beaucoup de contraintes : changements de configuration et de compilateur limités, listes de fonctions utilisables réduites (sur lequelles Google doit parfois adapter le code pour garder la compatibilité).