Beaucoup ne sont pas à 3 km d'une autre habitation, mais tout simplement dans le quartier d'une ville, ou deux ou trois habitations dans un quartier, qui n'ont pas été déclarés éligibles, alors qu'autour tout le monde l'est...

Voir le cas de Wntix à l'origine de ce sujet.

L'histoire est bien plus géniale que ça.

Le site en question c'est la centrale nucléaire de Three Mile Island. C'est le lieu du plus grave incident du nucléaire commercial US, et de facto l'origine du mouvement global contre le nucléaire. En réalité ce sont deux réacteurs, TMI-1 et TMI-2, qui appartiennent à deux entreprises différentes. C'est le second qui a subit une fusion partielle et qui est à l’arrêt depuis 1979. Le premier, qui est détenu par Constellation Energy, est dormant depuis Septembre 2019. Actif depuis 1974 avec une autorisation de 40+20 ans, il était utilisable légalement jusqu'en avril 2034. Il avait été fermer pour des raisons de cout (pertes d'exploitation) à une époque ou les USA pétait leur record de production d'hydrocarbures (12.3 million baril par jour, depuis battu). Sa déconstruction était prévue pour être complète en 2079 avec une facture de plus d'un milliard à la clef.

La deal avec Microsoft promet une réouverture pour 2028 avec le retour de 835 MW d'énergie propre à la clef - peu importe son usage.

Fessenheim c'était 1760 MW, on fait pareil ? 

Ce serait une excellente idée, ça permettrait peut etre de baisser le kwh. D'après ce que j'ai vu ces derniers jours, il parait qu'il y aura une flambée genre x5 de l'électricité en 2026 ? 

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...
• 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.

En phase, si tu as du réseau câblé qui parcourt la maison c'est l'idéal pour y connecter les bornes Mesh 

Merci pour les précisions, j'ai envoyé un message pour un tunnel L2TP avec ipv4 publique du coup