[Comment removed by author]

La version d’origine est plus claire. Continuer à faire abstraction de la pile de protocoles IPv6 en 2025 n’est pas une bonne idée. Les gens ayant des connaissances sur les réseaux informatiques mais ne connaissant pas IPv6 devraient parcourir le MOOC « Objectif IPv6 » de l’Institut Mines-Télécom, au moins, pour avoir des notions et se faire une idée (voir les prérequis). IPv6 deviendra incontournable.

Voici quelques remarques sur la forme.

uci -q batch <<EOF
    set network.lan.proto='dhcp'
EOF

Le serveur DHCP du routeur peut configurer l’interface de gestion du point d’accès.

uci -q batch <<EOF
    set.wireless.wifi_device[0].country='YourCountryCode'
    set.wireless.wifi_device[1].country='YourCountryCode'

    set wireless.wifi_iface[0].ssid='YourSSID'
    set.wireless.wifi_iface[1].ssid='YourSSID'

    set wireless.wifi_iface[0].key='YourSecurePassphrase'
    set.wireless.wifi_iface[1].key='YourSecurePassphrase'
EOF

Exploiter uci batch serait plus efficace que de recopier intégralement des sections. On perçoit mieux les paramètres à modifier et on peut l’appliquer instantanément à sa configuration via la ligne de commande.

uci -q batch <<EOF
    set network.wan.disabled='1'
    set network.wan6.disabled='1'
EOF

Il est préférable de désactiver l’interface WAN plutôt que de la supprimer de la configuration. On pourrait ainsi potentiellement la réactiver pour mettre à jour le point d’accès.

De même, selon l’article, il est préférable de désactiver le serveur DHCP du point d’accès.

uci -q batch <<EOF
    set dhcp.lan.ignore='1'
EOF

À noter que l’équivalent en ligne de commande de l’opération LuCI correspondante serait :

service dnsmasq stop
service dnsmasq disable

On aurait également pu créer une image personnalisée ne contenant aucun serveur DHCP (c.f. sélecteur de micrologiciel). Dans ce cas, il aurait fallu configurer soi-même l’interface « locale au lien » du point d’accès.

Ton contenu est bien écrit. J’aime bien l’esthétique de ton site Web. Par contre, je désapprouve l’idée véhiculée sur la philosophie Unix. Cela relève d’une vision utopiste quelque peu passéiste. L’analogie avec la « clé tubulaire, un tournevis et une pince » est incomplète. Ce n’est pas en raccord avec mon expérience. Nombres d’utilisateurs « Unix » avertis sont reluctant à utiliser le Shell comme langage de programmation ou « boîte à outils ». Cette conception a des limites : maîtriser des utilitaires, créer de nouveaux programmes implémentés dans un autre langage (pour ajouter des commandes ou définir des interfaces), connaître plusieurs concepts inhérents à la conception d’un système d’exploitation et tordre un langage de commandes (le Shell) dans tous les sens pour les plus malchanceux. C’est une vision illustre des choses mais déplorable qui est érigée en mantra et qui contrevient au bon sens.

Je cite cet extrait du GNU Linux magazine n°277, de l’article « Programmation robuste avec Bash ».

« Développer avec Bash ? Impossible, ce n’est pas un véritable langage de programmation ! Et ce genre de scripts sont bien trop fragiles ! » Voilà des idées reçues sur l’un des plus célèbres interpréteurs Shell que nous allons tenter, aujourd’hui, dans cet article, de faire disparaître pour de bon !

[…]

« L’interpréteur Shell a de nombreuses fonctionnalités permettant de le rendre aussi robuste et fiable qu’un programme réalisé à l’aide de soi-disant [langages] plus évolués tels que Python ou Java, il suffit d’en avoir conscience et de les utiliser à bon escient. »

Voici la conclusion de ChatGPT 5 nano :

L’affirmation est trop générale et peut être trompeuse. Le shell peut être robuste dans des cadres limités et bien encadrés, mais il ne remplace pas les avantages des langages comme Python ou Java pour des applications plus complexes.

En lisant, cela donne l’impression d’aborder des sujets en profondeur tout en les survolant. Hum !

Je préfère apprendre en autodidacte. Et apprendre à utiliser efficacement un Shell Unix, je trouve cela difficile. J’aime bien le projet GNU pour les valeurs du projet et la documentation au format Info pour transmettre des connaissances (un savoir-faire). Mais la documentation de Bash est difficile à assimiler. On découvre souvent une multitude de manières, pour faire la même chose, lorsqu’on fait des recherches sur le Web sur l’invocation de commandes Shell. En fait, j’en suis venu à penser qu’il fallait bien connaître le fonctionnement du système d’exploitation pour savoir comment procéder. On ne peut pas deviner. Les gens qui concevaient les utilitaires Unix participaient aussi au développement du système Unix. Idem pour le projet GNU. Dans son livre Scripts Shell Linux et Unix, Christophe Blaess recommande d’ailleurs d’apprendre la programmation Shell par la pratique. J’ai l’impression que, à mon niveau débutant, programmer avec un Shell de type Unix peut entraîner une perte de temps. Cela nécessite de déployer trop d’énergie, de façon générale. Après, quand on maîtrise, aucun problème rédhibitoire : cela vient, ou pas (on perçoit intuitivement).

Depuis des décennies, le conseil a toujours été d’éviter d’utiliser les shells pour traiter des entrées de données non fiables, pour des raisons de sécurité. Tout le monde vous dira qu’utiliser des scripts shell pour des pages web CGI – c’est-à-dire générées dynamiquement par des programmes – est une très mauvaise idée. La principale raison est que la syntaxe des shells est complexe. Il est difficile d’écrire des scripts correctement.

Source : Stéphane Chazelas (article 01net.com, à propos de la faille Shellshock)

On peut dire que je ne suis pas vraiment un utilisateur confirmé du Shell Unix. Néanmoins, ZSH et Fish, ils me donnent l’impression que c’est trop sophistiqué comme outils (voire surfait), pour l’usage qu’on peut en faire. Quand j’aurais plus de temps, j’essayerais d’expérimenter avec Rash (The Reckless Racket Shell, implémenté en Racket Scheme). Je pense que c’est plus en phase dans ma ligne de conduite.

La personne ayant écrit l’article ne comprend pas la philosophie du logiciel libre. En principe, ce n’est pas de savoir qui en retire le plus (contributions, rétributions…) mais plutôt de savoir comment se baser sur l’existant. Les gens qui savent programmer peuvent créer des programmes et parvenir à faire fonctionner un ordinateur. Néanmoins, faire fonctionner des systèmes sophistiqués et complexes est loin d’être simple, voire possible.

Cela devient évident lorsqu’on devient incapable de faire des choses qu’on aurait pu faire autrement.

Pourquoi Linus Torvalds a t’il élaboré son noyau Linux ? Parce que les systèmes Unix étaient devenus inabordables.

Pourquoi Richard Stallman a t’il créé la fondation du logiciel libre ? Parce que les gens ne partageaient plus leurs codes sources.

Salut Cascador,

Moi aussi je vous remercie pour le service que vous rendez à la commu tech francophone. J’utilise JdH via glance https://github.com/glanceapp/glance grâce à la compatibilité lobste.rs.

J’aime le côté sobre, fiable et performant du JdH.

Je regrette que la communauté soit très silencieuse. Je constate la popularité du JdH par les pics de visite, pas par les commentaires ni les up. N’est-ce pas aussi ce qui facilite la modération ! C’est le principe de lobste.rs par rapport à un HN.

Pour l’avenir, je dirais de ne pas changer ce qui marche. J’ai du mal à évaluer dans quelle mesure l’impasse technique est difficile à gérer.

En tout cas, oui, il faut un deuxième compère pour répartir ça.

Je te propose d’accepter les dons pour aider au financement. Certaines entreprises seraient disposée à te soutenir, j’en suis certain ;-)

Je parcours le JdH pour trouver des sujets qui m’intéressent en toute simplicité. Le site est transparent, et c’est formidable d’avoir des gens pleinement investis dans leur activité et qui le font librement (avec un sens de la liberté).

Note : J’ai relevé un usage à contre-emploi. Cela paraît intuitif de combiner la commande grep avec xargs car l’utilisateur peut vouloir afficher la liste des fichiers correspondant puis ensuite vouloir éditer automatiquement ces fichiers. Néanmoins, on recherche un motif deux fois successivement en lançant deux processus : grep et sed.

grep -rl "srobert@example.com" . | xargs sed -i 's/srobert@example.com/MY_EMAIL_ADDRESS/g'

Les lignes de commande suivantes me paraissent plus justes.

find . -type f -exec sed -i 's/srobert@example.com/MY_EMAIL_ADDRESS/g' {} +
find . -type f -print0 | parallel -m -0 sed -i 's/srobert@example.com/MY_EMAIL_ADDRESS/g' {}

Votre documentation m’apparaît comme un condensé d’expériences et de techniques. C’est très bien car cela a pour but d’éclairer les choses. Néanmoins, je suis moins convaincu par la méthode en général. J’ai un livre sur le langage Python qui est élaboré suivant le même principe, et au final, je n’y ai pas compris grand chose. Ce qui me chagrine un peu c’est la mise en perspective, avec des contradictions apparentes.

C’est l’outil idéal dans telle ou telle situation mais … l’élaboration d’un motif peut devenir complexe et peut aboutir malencontreusement à des erreurs. C’est l’outil idéal pour manipuler du texte mais … il existe aussi divers autres outils.

Efficacité : Les regex permettent de réaliser des opérations complexes sur des chaînes de texte avec un minimum de code. Ce qui pourrait prendre des dizaines de lignes de code en logique conditionnelle peut souvent être accompli en une seule ligne avec une expression régulière bien construite.

Laisser penser que le concept apporte de la performance est maladroit.

Unlike several other scripting languages, Lua uses neither POSIX regex nor Perl regular expressions for pattern matching. The main reason for this decision is size: a typical implementation of POSIX regular expressions takes more than 4000 lines of code, which is more than half the size of all Lua standard libraries together. In comparison, the implementation of pattern matching in Lua has less than 600 lines. Of course, pattern matching in Lua cannot do all that a full POSIX implementation does. Nevertheless, pattern matching in Lua is a powerful tool, and includes some features that are difficult to match with standard POSIX implementations.

Extrait du livre : Programming in Lua, 4th edition.

On imagine notre future et d’autres le font aussi, voire même à notre place. Quand je pense qu’on veut nous implanter des puces électroniques dans le cerveau pour ne pas être mis au rebut de l’évolution (humain augmenté), ou fabriquer des robots humanoïdes à partir d’organismes vivants. Tant qu’il nous reste de la liberté.

Ce serait le comble que les hébergeurs de contenu freinent l’utilisation de l’IPv6. D’un autre côté, les réseaux des opérateurs ne leur appartiennent pas. Il suffit de leur couper l’accès à l’Internet en IPv4 s’ils se refusent à migrer vers IPv6. Du coup, leur connectivité IPv4 en serait dégradée. Cela vaut pour les organisations voulant faire profit de la situation ou ceux faisant preuve de mauvaise foi (aucun effort). Pénaliser cela pour défendre l’intérêt général.

QUELS SONT LES « SCÉNARIOS DE SORTIE » D’IPv4 PLAUSIBLES ?

Le scénario de sortie d’IPv4 n’est pas connu et est très difficile à prévoir à ce jour. Si l’on essaie malgré tout d’imaginer les différentes étapes d’un tel scénario, on arrive par exemple à une séquence telle que celle-ci :

1. La quasi-totalité des offres d’accès internet grand public commercialisées proposent de l’IPv6 activé par défaut en plus de l’IPv4.

2. La quasi-totalité des offres d’accès internet grand public, pro et entreprise proposent de l’IPv6 activé par défaut. Une connectivité IPv4 est toujours proposée.

3. Une part non négligeable des sites web sont hébergés en IPv6 uniquement, malgré des poches de résistances à l’IPv6 pour l’accès proposés par quelques entreprises à ses salariés. Ces sites ne sont plus accessibles depuis une entreprise qui bloque l’IPv6.

4. Une part non négligeable des offres des fournisseurs d’accès à internet ne proposent plus de connectivité IPv4. Il n’est plus possible de consulter des sites web hébergés en IPv4 uniquement.

5. La majorité des sites web abandonnent IPv4, devenu inutile. IPv4 n’est plus utilisé sur internet, mais peut continuer à être utilisé pour des réseaux privés.

Source : arcep.fr

IPv4 nuit à la compétitivité ou à l’esprit d’innovation. Avec la croissance mondiale de l’accès à l’Internet, on a plus assez d’adresses. Cela remet en question le modèle de l’Internet. Raison pour laquelle on a inventé IPv6 dans les années 90 et dont l’usage est encore à appréhender. On a eu le Web, l’union de l’informatique et des télécommunications, l’apparition des objets connectés (informatique embarquée dans des systèmes électroniques reliés à un réseau informatique), les réseaux sociaux (les espaces d’échanges virtuels ou le phénomène accru de dématérialisation). Ce n’est pas tant le partage de contenu ou la version 6 du protocole IP qui change quoi que ce soit par rapport à l’usage de l’IPv4. Conceptuellement, on échange des données. Mais la version 4 du protocole IP a indubitablement des problèmes inhérents comme celui de l’épuisement de l’espace d’adressage. Ce n’est probablement pas une question de perspective mais de passage à l’échelle.

Que pensez-vous des Shell « Unix » embarqués dans un langage de programmation ? Je n’ai pas un niveau suffisant pour tester mais je trouve que Rash (Reckless Racket Shell) présente un certain attrait. On inverse le raisonnement en maîtrisant d’abord un langage de programmation puis en y intégrant ensuite un langage de commandes. Je serais plus orienté vers Rash que vers Xonsh parce que Racket (variante Scheme) intègre la métaprogrammation.

Un problème, avec la programmation Shell, et non des moindres, est que chacun doit faire sa propre tambouille. J’appréciais beaucoup l’aspect graphique de l’installateur Feliz pour Arch Linux. L’auteur de l’application a arrêté de le maintenir pour problème de santé et dans la dernière version s’était rabattue sur Dialog. Whiptail est une alternative à Dialog. Je trouve qu’il faut contraster les choses par rapport à l’usage du Shell car c’est ardu.

Deux poids, deux mesures.

Le problème fondamental de Gemini n’est pas tant le facteur minimaliste que le gel des fonctionnalités. Ce n’est pas je le pense dans cet espace que l’on va intégrer de nouvelles idées ou de différentes manières, on les échange tout au plus. C’est également important de pouvoir réaliser des choses et d’expérimenter, et pas seulement les exprimer ou les retranscrire à travers un texte. Chacun pourrait se réapproprier le Web mais c’est difficile et l’évolution a passé avec son lot de nouveaux défis. Rien que créer un site c’est complexe. Ensuite, il y a le partage d’information qui devient une véritable diffusion ou publication. Pour finir, c’est un peu bateau, mais il faut avoir un sens général ou tracer son chemin.

Ironiquement, certains veulent admettre (ou faire admettre) que IPv6 est une régression de IPv4 : (en substance) IPv4 serait une valeur sûre, la durée du déploiement de IPv6 au fil du temps serait un signe évident de l’échec de l’IPv6, le passage à l’IPv6 serait forcé à cause de motifs politiques, ou encore, que l’IPv6 est moins sécurisé que l’IPv4. Arguments ayant été réfuté par des personnes qui maîtrisent leur sujet.

C’est bizarre. Explorer des modèles sous-jacents dont l’ensemble des possibles n’apparaît pas. Cet ensemble qui finit par occulter les modèles sous-jacents. En automatisant, on peut perdre les choses. C’est une grande crainte que de tout perdre ou de perdre sans crainte de ne rien perdre. Trouver le sens de la vie avec l’IA.