Avant udev/dbus/Hal la reconnaissance automatique du matériel relevait plus du coup de chance et du savoir faire des distributeurs.
Aujourd'hui grâce à udev/dbus/Hal à peu près toutes les distributions se valent en terme de reconnaissance matérielle. Cela est à payer au prix fort: Le démarrage est devenu lent car les distributions sont conçues de telle sorte qu'à peu près tout ce qui est supportable est supporté y compris les pilotes propriétaires.
Pour en arriver la, les périphériques sont systématiquement compilés sous forme de modules et chargé à la demande en fonction des résultats de l'évaluation faite par udev. Sur des machines ayant mémoire à profusion et des CPUs dernier cri cela ne se sent pas trop. Par contre sur des machines anciennes c'est un frein considérable.
Pour remédier à cet état de fait, recompiler le kernel est une option qui apporte énormément. Pour ma part je compile mon kernel de telle sorte que le matériel non amovible (CPU type, ACPI, Ethernet, Carte graphiques, etc...) est directement intégré au noyau et non sous forme de modules. Un gain sensible de performance est indéniable.
D'autre part et cela pour satisfaire tout un chacun tous les services existants sont démarrer par défauts dans la plupart des distros grand public. Si les utilisateurs de tels ou tels services seront satisfaits, ceux qui ne les utilisent pas traine un ballast inutile ralentissant le démarrage et consomme de la mémoire pour rien. Une revue des scripts de démarrage apporte aussi un gain de performance non négligeable surtout sur les machines un peut juste en mémoire et au processeur plus très frais.
[^] # Re: C'était mieux avant.
Posté par Unixfix le Gaulois . En réponse au journal Gestion du matériel gourmande en resources (udev, hal) ?. Évalué à 4.
Aujourd'hui grâce à udev/dbus/Hal à peu près toutes les distributions se valent en terme de reconnaissance matérielle. Cela est à payer au prix fort: Le démarrage est devenu lent car les distributions sont conçues de telle sorte qu'à peu près tout ce qui est supportable est supporté y compris les pilotes propriétaires.
Pour en arriver la, les périphériques sont systématiquement compilés sous forme de modules et chargé à la demande en fonction des résultats de l'évaluation faite par udev. Sur des machines ayant mémoire à profusion et des CPUs dernier cri cela ne se sent pas trop. Par contre sur des machines anciennes c'est un frein considérable.
Pour remédier à cet état de fait, recompiler le kernel est une option qui apporte énormément. Pour ma part je compile mon kernel de telle sorte que le matériel non amovible (CPU type, ACPI, Ethernet, Carte graphiques, etc...) est directement intégré au noyau et non sous forme de modules. Un gain sensible de performance est indéniable.
D'autre part et cela pour satisfaire tout un chacun tous les services existants sont démarrer par défauts dans la plupart des distros grand public. Si les utilisateurs de tels ou tels services seront satisfaits, ceux qui ne les utilisent pas traine un ballast inutile ralentissant le démarrage et consomme de la mémoire pour rien. Une revue des scripts de démarrage apporte aussi un gain de performance non négligeable surtout sur les machines un peut juste en mémoire et au processeur plus très frais.