freem a écrit 5059 commentaires

Ah ok. C'est pour ça que ça marchait pas, j'utilise zsh :)

Ma foi, je croyait naïvement que l'avantage du web-based sur le natif était la portabilité et le rendu uniforme peu importe la machine… oups, pardon, je suis en avance de 5 jours :)

Je voudrai juste confirmation pour faire une entrée de suivi, ceci dit, tant que je tiens ce problème. Je l'ai déjà rencontré plusieurs fois et avec divers browsers, mais il est ici particulièrement évident et je voulais savoir si c'est lié à mon système avant de flooder.

Mais peut-être que ça cours les toits (enfin, si on ne considère que les watts électriques, bien sûr, et que l'on oublie qu'un chauffe-eau n'a pas de jambes ni de pattes)?

Je pense que ce thread est une bonne illustration de pourquoi j'aime tant linuxfr.

Post-edit: c'est aussi ce que j'ai avec firefox, je me demande si je suis le seul a avoir le problème avec d'autres navigateurs (basés sur le même moteur de rendu, pour le coup)?

Hop, suis con, j'ai pas mis de imgur du coup:

https://imgur.com/a/FTPKG

Question qui n'a rien à voir avec le sujet:

y'a que chez moi que c'est illisible?
Les mots sont séparés par des blancs de taille variable, qui semble dépendre de la taille de l'expression contenue par ce que je suppose être un type de rendu mathématique).

Je suis actuellement en train d'utiliser vivaldi, basé sur chromium, dans Devuan testing. Le résultat est identique quand j'utilise chromium. Je reboot le temps de tester avec voidlinux (la version basée sur musl pour le coup, pour laquelle j'ai au moins un firefox, et probablement un chromium)…. je risque juste de me faire jeter à l'édition.

[edit]
Aussi illisible via chromium sous void, mais pas sous firefox?

Ça tombe bien, le parsec n'est pas une unité du SI, qui reste donc bien cohérent (et non consistant).

J'ai lu trop vite donc, et avec trop de CTRL+F.

dans ce cas, […]

e ne vois pas en quoi […]

idem […]

J'ai l'impression que la plupart de tes points retombent sur mon avis, pour le coup :D
J'avais justement posé ces questions pour faire répondre quelqu'un qui considère le SI comme non pertinent.

Oui et non.

Il prétend remplir tous les points qui me séduisent chez runit, et que runit remplis la plupart, à un gros détail près:

Supervision suites should provide a basis for high-level service management.

Ici, je bloque.
De l'aveu de l'auteur du document, c'est le seul avantage par rapport à runit, qui est le successeur des daemontools (au sens unix du terme, pas windowsien, ou c'est juste un outil pour simuler un CD).
Mais justement, ce que moi j'apprécie, et qui est le tort de systemd à mon sens, c'est justement le fait qu'un système d'initialisation ne devrait pas contenir de code complexe, il doit être léger et prédictible.
Donc, pas «haut niveau» au sens administration système du terme.

Il reproche à runit d'être basé sur un système de polling? C'est un détail d'implémentation, de ce que j'ai vu du code, si ça pose problème, patcher ça pour un autre système ne serait pas trop long: reste à en voir l'intérêt? Parce que, pour moi, «polling» évoque l'appel système «poll», qui justement permets de faire de l'asynchrone bloquant sans multi-thread et en standard POSIX. Donc, ou est le problème?
Les scripts doivent être écrits pour chaque service? C'est justement un point que j'apprécie. Le problème potentiel que je vois ici, c'est que ces scripts vont partager du code, code dupliqué, le mal absolu. C'est vrai. Sauf que rien n'empêche d'écrire des binaires, qui utiliseraient la même lib partagée: le code serait pas dupliqué, il serait partagé, il serait compilé (donc plus rapide), il serait de plus haut niveau.
Pourquoi ne pas le faire? Parce que ça ne semble pas valoir le coup. J'ai lu les scripts d'init de la seule distrib que je connaisse qui s'en serve par défaut: remplacer un script de 10 lignes maximum pour pouvoir partager le code me paraît overkill.
La solution fournie par s6, c'est de faire dépendre directement, par l'ABI, du système d'init. C'est justement un truc que je regrette pour systemd.

Ceci dit, on va pas troller, c'est pas encore le jour, ton document est plutôt intéressant, même s'il semble un peu déprécié (j'aurai aimé quelques comparaisons avec systemd, justement, l'acteur majeur du moment) malgré que le manque de date empêche d'en être sûr.

Permets-moi de t'arrêter (enfin, rétrospectivement, et j'ai une bonne raison physique pour ça) sur ce point:

Dans le monde de la finance, de l’assurance, de la gestion de stock, de la gestion commerciale, des ressources humaines/paye, de la comptabilité (société ou personnelle), la quasi-totalité des calculs sont faits en utilisant le type décimal.

Je doute qu'aucune erreur ou bug ne filtre dans «l'embarqué» pour ça. Les convertisseurs analogue-digital (et vice-versa) ont une résolution, et dans leurs specs (enfin, mon souvenir remonte à y'a longtemps) leurs règles sont claires.
Pourquoi dans les CPU on en chie à avoir un calcul exact, sachant qu'au final ça serai juste des 1 et des 0? Je n'en sais trop rien, sûrement parce qu'on a voulu imposer une représentation finie sans limitations d'un truc potentiellement infini (les nombres réels. Au final, c'est un peu comme la taille maximale d'une chaîne de caractère, mais pensé sur 64 bits je crois? Diantre! Et ça semble contraire à tout ce que j'ai vu à l'école, de préciser aucune information de façon explicite et simple sur la résolution des résultats finaux des calculs…)?

Et on se retrouve à travailler avec des langages où il faut passer son temps à instancier une classe dès qu'on veut faire un calcul de base pour contrôler l'arrondi pour soit être cohérent avec les règles légales/réglementaires, soit éviter les centimes perdus.

Ici, je ne vois pas le problème.
Pour ce type de fonctionnalités, il me semble évident que le modèle objet prend tout son sens. Ce qui me dérange le plus, à la rigueur, c'est que le float natif, lui, ne soit pas un objet, alors que justement, il s'agit d'un type pour lequel l'opérateur == devrait être illégal. D'ailleurs, mon compilo me colle un warning, soigneusement transformé en erreur par mes réglages perso, quand je fais ça.

Tu parles de règles légales, et un des problèmes est bien là: de la même manière que les chaînes de caractères ne devraient pas être considérées comme un type natif (ben oui: quel encode qu'il veut, le bon monsieur? Et comment que le programme il doit le savoir nativement? Ben il peut pas, mon bon monsieur…) ce genre de chose nécessite (au niveau financier du moins) un système pour que le comportement change selon les LOCALES de l'utilisateur.

Alors je pousse ici le cri de désespoir partagé par tous les développeurs de la finance ou de la compta : "je veux un langage qui fait ce dont j'ai besoin !".

Alors il te faut soit cesser d'utiliser un langage généraliste, soit implémenter un jeu de classes (une lib, quoi) qui fasse ce que tu veux suffisamment bien pour que tous les comptables autour du monde puissent s'en servir.
La tâche est ardue, mais avec assez d'argent à la clé, quelqu'un le fera sûrement.

me force à me poser la question dès que je risque de créer un problème d'arrondi ou de dépassement.

Tu lis dans mes pensées. Et pas pour de la compta & co: même pour du système, j'aimerai que mon compilo râle.
Bon, comme il est évident que ça serait hyper lent de vérifier chaque calcul, je me suis contenté de me faire un remplaçant pour static_cast<>() nommé safer_cast<>().
Ça ne gère malheureusement que le transtypage d'un entiers vers un autre, ça ne peux que faire un gros assert() de la mort qui tue en cas de dépassement en mode debug (et rien en release, mais je pense corriger ça en permettant le lancement d'exception ou un abort, le tout configurable via le template), mais ça reste nettement mieux que ce que le C++ me propose de manière native.
Cela dis, un langage comme Rust pourrait proposer mieux, vu que l'accent n'est pas mis sur les performances mais la fiabilité.

En tout cas, ne crois pas que le problème des dépassements et des arrondis est limité au tertiaire. Tous les programmes, sans exceptions, y sont soumis.

Hum… j'allais prendre un contre-exemple pour arguer du fait que le SI est consistant, mais en le prenant, j'ai fait l'«erreur» de me documenter pour me sourcer.

Il s'avère que, selon wikipedia toutes les unités ne sont pas basées sur une base 10. D'un autre côté, cet exemple (le parsec) pris au hasard peut être considéré comme une unité de base, l'équivalent du mètre, en somme.

À contrario, en informatique, ce sont les multiplicateurs que l'on altère, ce qui favorise l'incompréhension je pense.
Par exemple, SpeedCrunch m'indique que:

1Kio, soit 2¹⁰ octets => 1024, erreur de 2.4% par rapport à la norme
1Mio, soit 2²⁰ octets => 1048576, erreur de 4.8% par rapport à la norme

Bref, plus on augmente les valeurs (plus ça va, plus ça monte, on passe à pas loin de 7.3% pour le Gio, et presque 10% pour le Gio; notes que je n'ai pas trouvé de référence pour savoir si on écrit la 1ère lettre du multiplicateur en majuscule ou non: il me semble que si mais…), plus le risque d'erreur induit par l'interprétation classique est élevé.
D'ailleurs, même si je connais la valeur exacte de 2^10, d'un Kio donc, je serais incapable de dire combien vaut 1Mio, alors qu'un mo, selon le système international, si. Du coup, pour dimensionner des systèmes, c'est mieux de parler de Mo que de Mio à mon avis.

Du coup, la question, c'est pourquoi utiliser des puissances de 2? Pour l'adressage? Pour indiquer aux gens la capacité des machines qu'ils utilisent? Pour comprendre ce que peux contenir un disque dur que l'on va acheter?
Perso, quand on me parle de Kio, je sais que je vais devoir me méfier et recourir à une calculatrice si je veux manipuler de grands nombres. Avec des Ko, à moins que l'auteur n'ait explicitement exprimé qu'il utilise notre système historique (ou que je puisse le demander), je reste soumis au doute, et, un jour de fatigue, je pourrais faire une approximation fausse de plus de 4%, ce qui n'est pas spécialement faible pour moi.

Je ne saurais dire si un système me persuade alors que l'autre me convainc mais je balance entre les deux :)

Désolé, j'ai pas vu cette réponse.

pourquoi ne pas aller voir le code source de dpkg/aptitude pour voir comment il fait ?

Sincèrement, j'ai essayé. Pas pour les mêmes raisons à l'époque, mais pour tenter d'enrayer sa lenteur phénoménale quand un paquet est calculé (à raison) cassé: au moindre mouvement, à première vue, il recalcule toutes les raisons de la cassure, et compte tenu du nombre de noeuds…

De mémoire, dans le dépôt, il était déjà difficile de trouver le point d'entrée du binaire final (il semble y avoir eu 2 tentatives de portages, l'une vers GTK et l'autre vers Qt, dans la même branche de code.
Pour dpkg, pas de problèmes la-dessus, mais je n'ai quand même pas retrouvé le point d'entrée.

Ce genre d'expériences, tant niveau pro (au taf quoi) que amateur (rien à voir avec la qualité du code, mais le côté pour le fun) est justement ce qui me fait penser qu'un outil qui ne fasse qu'une chose est une bonne chose, et je me disais que, peut-être, il existait un outil qui se contente déjà de ne faire que permettre la navigation dans un arbre, moyennant un jeu de règles pas codées en dur. Avec un peu de bol, ce soft serait assez hackable pour être adapté à ce besoin.

c'est justement là la force du logiciel libre, avoir acces aux sources.

Ce n'est pas parce qu'on a accès aux sources qu'on peut y contribuer facilement.
Aptitude est hyper complexe, ce n'est pas juste un outil de parcours d'arbre, il cherche aussi automatiquement des solutions, est capable de mettre à jour une base de données qui est coupée en plusieurs parties dont l'une n'est utilisée que par lui, les autres par d'autres composants systèmes.
C'est d'ailleurs, j'imagine, la raison pour laquelle il est impossible de modifier les actions que l'on voudrait prévoir lorsque l'on fait une mise à jour de la DB ou que l'on télécharge des paquets destinés à être installés (non, on ne peut télécharger "dans le vent", tout comme on ne peut installer en étant utilisateur, alors que je ne suis pas persuadé que dpkg en est incapable. Je pense même que moyennant quelques hacks sans recompiler, dpkg peut installer en espace utilisateur!).

Bon, je suppose que je vais essayer de code mon propre outil, en espérant ne pas trop en baver.

Juste une question: c'est quoi, un ulp?

Serait-ce le bruit que fait le processeur quand on lui file des flottants, de la même façon que les personnages de BD font gulp quand il y a un truc qu'ils vont pas apprécier, mais en plus rapide donc on entend pas le g?
Je déconne, certes, mais pas sur la question originelle :) si quelqu'un peut vulgariser le terme… me suis toujours méfié des flottants comme de la peste, parce que je ne sais jamais comment déterminer le delta qui permets de considérer une égalité entre 2 flottants… d'ailleurs, on dit qu'il faut pas utiliser operator== entre 2 flottants, mais est-t-on bien assuré que 2 nombres, après 2 calculs complexes, soient correctement considérés inférieurs dans le bon ordre par le CPU? (j'aurai bien dis l'UA, mais je ne suis pas sûr que ça traite les flottants…)

Autre question, les flottants réels sont-ils bien plus rapides qu'une approche à virgule fixe? De mon petit bout de lorgnette, cette assertion que j'ai lue me semble étrange: au mieux, je crois savoir que ces nombres sont manipulés par des puces différentes, et donc en parallèle, mais de la à considérer ça comme plus rapide dans l'absolu? Et si ce n'est pas le cas, pourquoi toujours utiliser des flottants réels dans la 3D? La précision semble aléatoire, seule la vitesse semble potentiellement intéressante d'un point de vue factuel. Le manque de précision ne serait-il pas, justement, une fonctionnalité intéressante des réels (ça permets des optimisations, et puis, un flou, ça permets de donner une meilleure illusion de réalisme qu'une ligne bien nette)?

Oups… c'est fourre-tout du coup. Mea culpa.

L'argument se tient.
Mais, dans ce cas, pourquoi je n'ai pas d'informations précises dans mon /proc/cpuinfo quant au CPU?
Je veux dire, on sait que l'algo de prédiction (hyper bas level quand même) est vulnérable à des failles actuelles et que le kernel est patché (ou pas) en conséquence (et je doute que la vulnérabilité soit testée par le noyau, à mon avis, c'est juste du bon gros hardcode pas propre, à vérifier) mais on ne sait même pas combien de niveau de cache il y a, ni leur répartition par coeur, ni… la liste est longue. D'ailleurs, elle inclue la longue liste des firmware plus ou moins planqués sur la carte mère ou le CPU, qui peuvent receler des backdoors et failles bien pire que spectre et meltdown.

Pour moi, le rôle du kernel n'est pas d'informer sur les failles du hard, mais d'en permettre l'usage (du hard, hein) de manière uniforme sans (trop) s'inquiéter de comment fonctionne le matériel (parce que je pense qu'il est quand même bon de connaître l'archi globale d'un PC, info qui n'est d'ailleurs dans aucune page de manuel de mon système, à moins que je ne sois passé à côté…).
Ça, et d'être performant sans mentir (et je crains qu'un jour, mon kernel pas compilé à la main mais chopé d'une distro ne mente, si je me fie à ces informations qui seront potentiellement corrigées dans 10ans).

Il me semble que B majuscule est pour byte (= 1 octet si la taille du bytes est de 8 bits, ce qui est quasiment vrai tout le temps) et le b minuscule pour bit.

Je t'avoues que je trouverais plus simple de parler de bauds et d'o/s, mais c'est vrai que le baud est plutôt une mesure à très bas niveau.
D'ailleurs, je ne comprendrai jamais pourquoi on parle de débit réseau (souvent internet/GPRS/whatever) en bits ou bytes par seconde, et non de bauds, mais c'est différent, puisque le baud est trop proche du matériel pour être pertinent dans le cas d'un accès à de la RAM j'imagine.

On devrait même écrire […] mais c’est complètement débile

Bah non, la norme ISO se base, je pense, sur des puissances de 10, pour être consistante sur le système métrique. C'est vrai que c'est un peu étrange au début, mais quand on y pense, si l'objectif est d'avoir un truc qui tiens la route pour toutes les disciplines tout autour du monde, le fait que tous les systèmes adoptent la même base pour les puissances est une excellente chose.
C'est vrai, moi aussi je trouve ça un peu ridicule, de parler de puissances qui ne sont pas elle-même des puissances de 2 en informatique, parce que ça ne marche pas comme ça dans le bestiau (quoique, pour les disques durs, si on regarde la quantité réelle utilisable par l'interface normale, qui permets d'avoir des secteurs de secours notamment, c'est pas si sûr)… mais dans ce cas, on pourrait nous rétorquer que les kilomètres, ça ne fait 1000 mètres que parce qu'on en a décidé ainsi.

Bref, perso j'aime bien la solution employée par l'ISO: elle nous permets de garder la spécificité technique (et relativement historique), tout en ayant une mesure qui nous permets d'être compris et uniforme avec d'autres domaines.
Après, non, c'est sûr, c'est pas aussi précis, mais de mémoire, on me disais à l'école d'arrondir les résultats sur les copies (on s'amusait pas à écrire les 20 chiffres du nombre exact, on mettais, en gros, 3 chiffres pour former un nombre entier, avec 2 chiffres pour les flottants, et une puissance… de 10, elle-même multiple de 3. C'était de l'électronique.).

Ça fait quoi, CTRL+R?

Parmi la liste des inits que j'ai découvert pendant l'init-war, il y avait runit, et je dois bien le dire: je ne vois pas quoi lui reprocher.

Du coup, je suis plutôt sv restart foobar, même si je pense qu'il ne serait pas compliqué de faire une commande proxy qui s'appellerait service et qui gérerait service foobar restart (ou l'inverse).
À noter tout de même, je me demande si c'est une bonne chose, ces commandes avec des sous-commandes qui se basent sur un ordre fixe d'arguments différents pour faire leurs tâches.
Perso, je préférerai, dans l'absolu, une syntaxe de type service --restart=foobar -rwhatever --restart=foobar,whatever plus simple à comprendre quand on mets le nez dans les scripts qui l'utilisent (sachant que le -rwhatever serait juste un alias court à --restart=whatever). M'enfin, je crois pas qu'un seul init implémente un truc de ce genre?

Il y a ça, mais aussi la question de la pertinence: déjà, les vulnérabilités sont adressées par leurs noms de baptême et non leurs CVE (je suppose qu'elles en ont?) donc au niveau maintenance sur le long terme ça risque d'être un peu chiant.
Et si c'est juste pour spectre et meltdown, alors c'est dommage, mais d'un autre côté, maintenir ce genre de choses pour l'ensemble des vulnérabilités risque d'être très coûteux en temps humain et aussi en code sur la longueur.

Du coup, je ne suis pas convaincu du tout que ce soit une bonne idée. Pour les gens soucieux des CVE potentielles sur leurs systèmes, il me semble qu'il existe déjà des paquets pour ce type de problématiques (celui de debian ne semble pas contenir "cve" dans son nom, ou alors aucun paquet ne me rappelle des souvenirs).

Concernant les failles, à priori, connaître la version du noyau est suffisant.

Si je ne m'abuse, il y a moyen de désactiver les patchs avec des paramètres en ligne de commande (ligne passée au noyau par le boot, hein, pas via un prompt urxvt) donc, non, la version ne suffit pas (quant à pourquoi désactiver, à priori, me semble que pour certains usages les correctifs peuvent avoir un impact non négligeable sur les perfs, même si ça sera pas le cas de nos machines de bureau).

500KB/s

Kilo Bits, ou Kilo Bytes, du coup? Je ne suis jamais sûr de comprendre quelle unité est la bonne quand c'est un b…

je n'utilise pas le chiffrement de mes email car personne dans mon entourage n'utilise le chiffrement d'email tout simplement parce que ce n'est toujours pas en 2018 accessible, utilisable et fonctionnel a 100% du temps en un clic pour l'utilisateur lambda,

De ce que j'ai testé, envoyer des messages signés et chiffrés avec thunderbird et claws-mail est simple comme bonjour. Pour la réception, je ne sais pas, à part les tests que j'ai faits en m'envoyant un mail à moi-même pour le fun.

La création du couple de clés est prise en main automatiquement quand on active les extensions, et la configuration pour activer (ou non) automatiquement l'un, l'autre, ou les deux, en fonction du message auquel on répond est également très simple (quelques options sans détails techniques dans une section de l'interface de configuration qui semble logiquement dédiée à ça), et pour le cas par cas, il y a des icônes parlantes (en tout cas, pour thunderbird, pour claws, on dirait que je les ai désactivées s'il y en a?) dans l'interface pour envoyer un message.

Les seuls problèmes que je vois, mais peut-être parce que je n'ai reçu des mails signés et chiffrés que de moi-même (pour tester) c'est qu'il ne semble pas possible d'assigner une clé publique à une adresse mail particulière, et donc vérifier si en plus d'être bien signé, le message l'est par la bonne personne.
Et je suis persuadé que c'est lié au fait que, justement, ma clé est déjà connue du système (puisque c'est ma clé d'origine).
Du coup, je veux bien que tu détailles ce que tu trouves compliqué? Peut-être le fait que la clé ne soit pas générée automatiquement en fonction du mot de passe utilisé pour imaps/smtps? Le fait que ces outils ne soient pas installés par défaut dans les clients (c'est peut-être le cas avec tails, remarques)?

On peut toujours trouver à redire

Perso, je l'ai réessayé récemment au boulot. Voici quelques inconvénients (par ordre d'importance, de majeur à négligeable) que je lui trouve:

• html obligatoire. Pour moi, c'est bloquant, je hais les mails en HTML. Et pour ajouter au problème, l'espèce de mise en page automatique est merdique (j'ose espérer que ça se configure, mais j'ai pas trouvé).
• temps de démarrage trop élevé. Désolé, pas de SSD au taf, et de manière générale, j'aime pouvoir utiliser les mêmes logiciels sur les PCs, parfois avec des contraintes de performances (ben oui, booter depuis un disque externe via USB, c'est moins rapide
• moins de lignes dans mon pstree. Il est déjà assez saturé comme ça avec le navigateur internet et cette cochonnerie de slack (pour le taf…). C'est peut-être un détail mais moi j'utilise très souvent cette commande.
• j'aime pas l'interface. Mais c'est une question de goût à l'état pur. Mention spéciale pour l'interface de configuration que je supporte difficilement, mais vu que c'est aussi valable pour firefox, ce n'est pas surprenant.

Bon, après, il a des points forts aussi, je pense notamment au fait d'être très simple à configurer (il est manifestement capable de se configurer automatiquement en fonction de certains fournisseurs) et supporte les agenda google (via plugins), choses dont claws ne semble pas capable.

En tout cas, je te rejoins que pour du mail pro ou qui sert réellement, un mail lourd est bien plus pratique:

• pas besoin d'être connecté pour avoir accès aux mails,
• pas besoin de lancer le navigateur internet pour si peu (~enfin, sauf dans le cas de thunderbird qui en est un~ oups, pas trolldi)
• possibilité d'intégrer avec un éditeur de texte local (entres autres), ça peux être utile pour diverses choses
• réactivité, y compris sur du matériel qui date de plus de 3 ans
• mises à jour intégrées au système, donc meilleur contrôle sur la sécurité voir même l'utilisabilité (j'ai utilisé pendant pas mal de temps un webmail qui n'étais pas à jour… ça n'a jamais posé problème en soit, mais je n'ai aucune garantie que les MàJ de sécurité de l'interface web étaient effectuées)

Et je suis sûr que j'en oublie.

Pour répondre à la problématique mot-à-mot de l'auteur, en langage compilé pour modifier le comportement d'un objet selon son instance, j'aurais soit utilisé:

• un tableau associatif "nom=>callback" (si on parle d'ajouter à la volée et en fonction de l'instance, mais je trouve ça sale)
• plus probable, un design pattern, probablement le décorateur: en gros, on ajoute à la classe «maîtresse» une instance (on un conteneur d'instances) d'une classe dont dérivent d'autres classes implémentant les comportements souhaités,
• des fonctions qui manipulent la classe, plutôt qu'embarquer un comportement volatile directement.

Tout ça pour dire que ce n'est pas un problème de langage compilé, et ce genre de techniques sont très utiles dès lors que l'on implémente des mécanismes de plug-ins, par exemple.

Le problème semblerait plutôt être que beaucoup de programmes écrits en C pourraient avantageusement être écrits dans un autre langage de programmation, qui ne soit pas un langage de bas niveau.

Ou alors, on pourrait considérer que le C pourrait fournir un minimum de support pour les chaînes de caractères dans le modèle length+data. Sauf que l'on s'expose alors à un autre problème, qui n'est pas si simple qu'il n'y paraît: dans l'article, l'auteur indique

Using an address + length format would cost one more byte of overhead than an address + magic_marker format

Traduction grossière: «Utiliser un format adresse + taille ne coûterait qu'un octet de plus par rapport au format adresse + valeur_magique».
C'était vrai à une époque donnée, sur un CPU donné, mais dans la pratique, les CPUs n'utilisent pas la même taille de mots, du coup, cette assertion est fausse dans pas mal de cas aujourd'hui. Accessoirement, ça limiterait la taille des chaînes de caractère à 65535 octets. Difficile, avec des fichiers de log ou des données XML un peu volumineux (avec UTF8, ça passera encore, mais en unicode 32, on a moins de 17000 caractères)…

Du coup, même si c'est vrai que ça pose des problèmes de sécurité quand on ne fais pas gaffe, et que c'est facile de ne pas faire gaffe, je pense que c'est un sacré raccourcis que de dire que c'est l'erreur la plus coûteuse.
Le C n'est pas juste fait pour tourner sur du matériel grand public, mais pour écrire du code portable (et pas forcément porté), efficace et puissant. Avec ces contraintes, le choix «null-terminated» était plus logique que celui d'utiliser des tailles: la taille des mots change avec les processeurs et le temps, les besoins aussi.
Du coup, le choix avec le moins d'impact sur les conceptions futures est bien le marqueur de fin: ce mécanisme marche juste sur la totalité des architectures sans la moindre modification de code, est indépendant du compilateur (quelle est la taille standard de size_t? Sur n'importe quel compilo ou CPU?).
Si l'on à besoin de manipuler beaucoup de chaînes de caractère, on prend un outil fait pour, quitte à introduire une dépendance (qui aurait éventuellement pu être incluse dans le standard, depuis, mais passons).

J'ai vu dans les commentaires que tu utilises apt-get, mais quelle distro? As-tu fait une mise à jour récemment? Je pose la question parce qu'il se peut que le nom de l'interface réseau ait changé si une MàJ majeure est passée par la (normalement, non, mais on sait jamais).
Tu indiques avoir fait ip link show mais tu n'indiques pas le retour complet, qui permettrait d'invalider la possibilité ci-dessus.

Quel gestionnaire réseau utilises-tu? Tu indiques ne pas utiliser d'interface graphique (bien que je doute que sois en TTY) mais ça n'indique pas comment le réseau est configuré chez toi. Personnellement, je n'utilise pas de daemon pour gérer le réseau, je le fais manuellement à partir de /etc/network/interfaces (avec le wpa_supplicant.conf qui va bien et mets les clés non dans la config mais dans le $HOME de mon utilisateur, histoire de pouvoir ajouter un réseau wifi sans être root…).
Si tu n'utilises pas de gestionnaire, peut-on voir le contenu de ce fichier?

Tu peux ping ta box, mais arrives-tu à ping une autre machine sur le LAN sur l'ethernet (donc, quand tu n'es séparé d'une autre machine que via un switch, ta box faisant potentiellement office de switch. Il n'y a pas de raison que non, mais ce petit test permettrais déjà de vérifier qu'il n'y a pas de problème de ce côté: peut-être n'est-ce pas du côté de ton PC, que ça merde)?

Une hypothèse qui n'a pas été abordée: un problème de routage? Que donne la commande route?

Notes: pour l'histoire de resolf.conf, un moyen relativement simple pour vérifier si c'est une merde dans le DNS est de balancer un simple # echo 8.8.8.8 > /etc/resolv.conf. Vu que ce fichier est de toute façon régénéré par le système… (par contre c'est pas propre de squatter le DNS de google, j'ai cru lire à plusieurs reprises que niveau sécurité c'est douteux, mais pour du test, ça ne devrais pas poser de problème j'imagine)

je ne pense pas que les charges soient le seul probleme, la peur de perdre le controle et la fierte du boulot bien fait (risque que ca cesse si les 1ers employes s'impliquent pas) sont probablement de tres gros freins aussi. en france on semble avoir tendance a se faire la guerre entre patron et employe, et dans les grosses boites je pense que c'est possiblement justifiable (des 2 cotes) mais dans les petites? j'en doute. il y a des francais bosseurs et employes, et de bons patrons, meme si tous ont leurs travers: on reste humains, et pour rien arranger, y'a histoire de fric