benoar a écrit 4240 commentaires

Oui mais monter le volume en read-only, c'est pas drôle. Je pense que raphj parlait de monter en R/W…

Avoir une résolution DNS relative à un réseau et non globale a toujours été un problème car le DNS n'a pas été fait pour ça à la base. Toutes les solutions de DNS « privés » ou en split-view sont des gros hacks qui fonctionnent vaguement mais butent toujours à la conception même d'Internet : le DNS a une seule arborescence globale, et tout le monde devrait avoir un adressage global dans l'Internet pour ne pas avoir à faire des résolutions DNS relatives. Ce sont des fondements essentiels d'Internet qui sont cassés par le NAT et dont tout le monde espère trouver des workaround qui marchent toujours à moitié mal depuis 20 ans. Peut-être qu'un jour certaines personnes décideront de faire la bonne chose.

Une description un peu plus formelle du genre de problème auquel tu fais face : https://tools.ietf.org/html/rfc6418

Si tu veux vraiment du DNS sur un réseau isolé, le mieux est mDNS comme cité plus haut. Ça marche à peu près partout (c'est standard https://tools.ietf.org/html/rfc6762 et implémenté de base dans pleins d'endroits) sauf sur les OS qui refusent le réseau décentralisé, et il se trouve que ce sont les majoritaires, Windows et Android. C'est malheureux mais je ne connais pas d'autre solution qui soit standard et pas trop crade.

Étrangement, il y a quelques jours j'ai vu un autre bug volontairement non-résolu dans Chromium, autre produit anti-décentralisation, qui casse volontairement les déploiements IPv6 isolés : https://bugs.chromium.org/p/chromium/issues/detail?id=530482
On comprend mieux cet état de fait quand on voit l'état d'esprit des devs Google : « can you explain more about why your configuration does not have a IPv6 global route? ». Ça fait peur de voir ce genre de commentaire par quelqu'un qui est censé implémenter et connaître IPv6 (il site plus haut les adresses site-locales, dépréciées depuis 15 ans…). Voir également le test de connectivité avec les adresses de Google hardcodées dans Chromium…

Bref, Google et consorts pèsent de tout leur poids politique pour casser les déploiements non-centralisés (ça me rappelle https://bugzilla.mozilla.org/show_bug.cgi?id=14328 où les devs qui déconseillent la résolution chez Mozilla viennent de… Google), et il est difficile de trouver des solutions dans ce cas-là.

attention, ce 2x le plafond c'est uniquement pour la convention Syntec. Pour les autres (métalurgie,…) ce n'est pas le cas.

Pour les autres, c'est au moins une fois le PMSS, effectivement. Soit 40 k€ brut par an, ce qui n'est souvent même pas ce que gagnent certains qui se disent au forfait.

Petit rappel à tous les ingés Syntec ou assimilé : vous n'êtes sûrement pas au forfait jour, comme j'entends beaucoup de salariés dire. C'est la substance du jugement condamnant Altran cité dans ce journal, qui indique que c'était pour « non-paiement d'heures supplémentaires », mais sans expliquer comment c'est arrivé (si je me souviens bien de l'histoire) : c'est parce-que les contrats soit-disant « au forfait » de beaucoup de salariés ont été requalifiés (après avoir été poursuivis en justice) en contrats classiques car ils ne satisfaisaient pas du tout les conditions nécessaires (grande autonomie, responsabilités) et les obligations (niveau salaire), et que donc toutes les heures effectuées en plus de la durée légale du travail (35h) sur les deux ou trois dernières années ont été comptées en tant qu'heure supplémentaires. Je suppose qu'Altran a également accepté de requalifier ces contrats car ils ne voulaient se plier aux obligations salariales requises pour un vrai forfait jour : un salaire d'au moins deux fois le PMSS (Plafond_de_la_Sécurité_sociale https://fr.wikipedia.org/wiki/Plafond_de_la_S%C3%A9curit%C3%A9_sociale 39 732 € en 2018), soit environ 80 k€ par an…

Une très bonne lecture sur le sujet : https://blog.zwindler.fr/2017/12/12/convention-syntec-le-cadre-autonome-au-forfait-jour/

Je dirais dos d'âne ou ralentisseur, ce qui semble correspondre à la signification originale.

Non, c'est l'inverse, le but n'est pas de dire qu'un ralentisseur ralentit ton trafic, mais qu'un mécanisme « élève » (du verbe « to bump ») ton trafic réseau (le titre original est « A little bump in the wire that makes your Internet faster »). Ça a moyennement du sens ici pour la modification de scheduling, mais à l'origine c'était pour l'ajout d'un header IPsec (qui élève le contenu du paquet original).

Le terme « bump-in-the-wire » devrait plutôt être traduit, je pense, par « élévation sur la ligne », ou un truc du genre. Ça vient du monde IPsec, cf. https://en.wikipedia.org/wiki/Bump-in-the-wire qui référence la RFC 4301 https://tools.ietf.org/html/rfc4301 mais on peut remonter à la RFC 2767 https://tools.ietf.org/html/rfc2767 qui cite un papier de 1996 (sur une implémentation MS-DOS d'IPsec !!). On en parle par opposition au « bump-in-the-stack », ou « élévation dans la pile », dans lequelle c'est la pile logicielle qui est modifiée pour inclure l'amélioration ; de sécurité dans le cas d'IPsec, ici de réactivité, même si le « bump » est lié à l'ajout d'un header IPsec AH/ESP dans le premier cas et n'a pas ici vraiment de sens. On en parle également dans les différentes méthode de transition IPv4/IPv6.

Quant au bufferbloat, on pourrait éventuellement dire « ballonnements dû aux tampons » ; bon, je suis vraiment mauvais en francisation je crois.

Le pire est que l'industrie des télécoms toute entière refuse toujours obstinément de reconnaître ce problème, et le poids de l'existant est tellement énorme qu'il est en effet aujourd'hui impossible d'avoir une infrastructure DSL avec des tailles de buffer correctes, tellement c'est enraciné dans les équipements et les gens.

À chaque fois c'est le même débat qui tourne en boucle, sans jamais personne qui n'ait réellement eu entre les mains un tel système à gérer…

Avoir des bases de mot de passe chiffrées empêche toute authentification interactive « classique », qui permet de ne pas faire circuler le mot de passe sur le réseau, genre CHAP (rappelez-vous que Free à la base offrait des accès RTC où on s'authentifier avec du CHAP sur PPP…). Idem pour toute authentification interactive incluse dans EAP, pour reprendre un protocole un peu plus moderne. C'est également, je pense, une raison pour laquelle les gens semblent aimer le LDAP qui impose la méthode d'authentification avec une méthode de hashage fixée, et ne permet pas l'authentification interactive comme le permettrait RADIUS, qu'on mettrait normalement devant un LDAP.

Certes, aujourd'hui pour palier à la non-confidentialité des protocoles de vérification de mot de passe faisant passer le secret en clair comme PAP et pratiquement toutes les authentifications web « modernes », on ajoute du TLS en dessous et « tout va bien » ; c'est valable aussi bien pour le web que pour tout un paquet d'autres protocoles (comme EAP-TLS pour celui cité ci-dessus). Mais ces protocoles d'authentification sans gestion de la confidentialité étaient à l'origine pas très bien vus, et tous basés sur le principe de partage de secret identique, sans challenge.

Sans parler du fait qu'il existe des protocoles modernes (d'ou mon qualificatif de « classique » utilisé plus haut, par opposition) basés sur les mot de passe fait expressément pour ne pas avoir de base en clair, comme SCRAM https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism mais que tout le monde a l'air de s'en foutre.

Et bien sûr, tout cela en évitant l'éléphant dans la pièce : pourquoi a-t-on toujours autant d'histoires de mot de passes, avec une croissance et une complexité grandissante dans leur gestion, quand depuis des décennies on annonce l'avènement de l'authentification par cryptographie asymétrique ?!

Les deux images que j'ai postées se contentaient de montrer que Kate pouvait procéder à une part de cette abstraction mais de façon imparfaite : les longueurs des espaces insérés étaient certes dynamiques mais plusieurs espaces étaient quand même insérés.

Ce qui est exactement le fonctionnement d'une tab normale tel qu'implémenté dans tous les éditeurs depuis 30 ans. Ceci n'a rien à voir avec les tabulations élastiques, tu te méprends.

S'il fait référence aux logiciels de traitement de texte, évidemment que ceux-ci peuvent insérer des espaces de longueurs variables pour des besoins d'alignement. Seulement, aux dernières nouvelles, Kate ne fait pas de traitement de texte.

N'importe quel éditeur de texte qu'il soit « traitement de texte » ou pas a ce comportement que tu présente. Va vérifier. Encore une fois, rien à voir avec les tabulations élastiques, qui concernent le fait de faire de l'alignement de lignes adjacentes avec uniquement une seule tab (ce qui n'est pas le cas de ton exemple).

Heu… c'est exactement le comportement d'une tabulation normale. Rien d'étonnant là-dedans.

Note
Pour ce que ça vaut, mon opinion personnelle est que je préfère un jeton m’offrant une protection peut-être imparfaite mais dont je connais le code et les mécanismes, à une carte à puce m’offrant une protection certainement imparfaite également mais qui dépend d’informations que le constructeur de la puce refuse de dévoiler.

J'ai lu (il me semble) dans les publications de Gniibe qu'il préférait également l'utilisation d'un STM32 « standard » plutôt que d'un autre chip spécialement orienté crypto avec des fonctions « spécialisées » (et fermées), car il expliquait qu'on ne sait jamais ce que ça cache, et que ça finit toujours par être craqué un jour. Il est très orienté « liberté avant le reste », et comme tu le dis bien, la liberté et la documentation est préférable à tout autre argument de sécurité, même si le choix peut sembler moins sécurisé au début. Je partage cet avis aussi.

Et pour l'anecdote, j'ai connu GnuK à l'époque où pour le tester seul le kit Discovery STM8S était vraiment accessible niveau prix (et ça le reste encore : 7,55 € chez Farnell, mais la différence avec le F103 est négligeable aujourd'hui) :
https://www.st.com/en/evaluation-tools/stm8s-discovery.html
Oui, le chip est un 8 bit, mais le chip qui fait l'interface UART-USB est un STM32F103, beaucoup plus puissant que la cible en question… Il contient moins de flash que le kit Nucleo, mais Gniibe a rajouté un hack car à priori, il aurait plus de flash que ce qu'indique la datasheet (perso, j'ai un patch pour désactiver des bouts afin que ça tienne dedans). Bon, ça reste un peu galère (en plus du port USB B assez gros), et je suis passé par un BusPirate pour le flash SWD, mais c'est drôle et pas cher.

En bossant sur les LNS de FDN, où arrivent toutes les connexions ADSL, je testais le fail-over de L2TPNS avec mes modifications pour annoncer les LNS en BGP aux routeurs upstream. Bien sûr, je teste depuis une ligne ADSL de chez FDN. Les deux serveurs sont up, les connexions sont réparties sur les deux, je coupe le premier : victoire, celles sur le premier basculent sur le second, ça fonctionne bien ! C'est vraiment époustouflant comme mécanisme, c'est quasi-instantané (quelque secondes) et toutes les lignes (environ 250 à l'époque, je crois) migrent sans problème. Confiant dans le système, je redémarre ce premier serveur, et « pour la forme » teste en coupant le second : allo ? Ya quelqu'un ? Ah, le fail-over n'a pas l'air d'avoir marché dans l'autre sens… Toutes les lignes sont tombées, y compris la mienne, et ça n'a pas l'air de redémarrer.

Bien sûr, on est dimanche soir minuit, et je n'ai donc plus d'accès au Net. Je ne suis pas à Paris ni Amiens, mais heureusement geb est dans le coin, lui pourra sûrement m'aider, je pars toquer à sa porte. En arrivant chez lui, il rigole bien, à priori la nouvelle s'est répandue assez vite sur IRC. C'est un autre Benjamin (bien nommé pour un dimanche) qui a vu la coupure et a redémarré les serveurs le temps que je fasse ma petite marche.

J'ai aussi appris plus tard par Domi que j'aurais pu me logger sur les serveur avec un realm et un login propre à notre fournisseur le collecte, vu l'architecture assez « open » du DSL en France.

Ça sent le cas d'utilisation pour git-replace(1), ça…

un avis sur ce type de migration qui me semble, à moi, problématique, surtout avec l'arrivée du RGPD.

Dans un cas que je connais, c'est même au contraire l'arrivée du RGPD qui incite certaines boîtes à se jeter dans les bras des GAFAM ! Car oui, Amazon a toutes les certifications qu'il faut pour être RGPD-compliant, alors que le service informatique interne, non…

Du coup, de ce que j'observe, le RGPD va encore plus favoriser le stockage « danse les nuages », au grand dam des citoyens européens soucieux de leur vie privée.

Moi aussi j'ai bossé pour un projet FP7 où il était demandé, pour ce cas, de rajouter une mention de copyright à tous les fichiers des softs réutilisés (plein de softs libres GPL et/ou BSD), même si dans mon cas on ne changeait pas la licence. Ce n'est pas moi qui ait fait ça, du coup je n'ai pas pu trop juger de la légalité du truc, mais c'était une « obligation » du financeur (l'Union Européenne) et même si c'était débile, il « fallait » le faire.

Bref, oui les projets européens sont gérés par des ignorants des spécificités du droit de la propriété intellectuelle concernant le Libre, et il faudrait les éduquer un peu là-dessus. Mais en arriver à conclure qu'il faut plutôt changer la manière de faire du Libre en général et de généraliser les CLA… je trouve que tu vas dans le mauvais sens.

Sans bien sûr parler du fait que ce projet a été fait sans jamais pouvoir remonter les changements upstream pendant 4 ans, parce que les questions de licences n'ont été résolues qu'à la fin (personne ne veut s'occuper d'une telle « connerie ») et que du coup le code contribué n'a servi à rien puisque bien trop éloigné du projet originel qui avait avancé sans nous.

Donc oui, il faut éduquer l'UE sur la bonne manière de faire des contributions libres, et ça ne passe pas forcément par se plier à leurs règles débiles en profitant de l'opportunité des CLA.

On peut encore aller le loin… Tout est fichier ! On peut généraliser ce comportement ! On peut aller jusqu'à envoyer toutes les requêtes sur la même boucle d'événement.

Et cette « boucle d'évènement » unique, elle s'appelle… ton noyau. Démultiplexer des « requêtes » selon un sélecteur donné, c'est ce que fait le noyau quand il répartit les paquets reçus du réseau selon l'adresse et le port de destination du paquet (oui, je me suis placé à un niveau « en dessous »). Forcément, quand tu as oublié qu'il existait autre chose que le Web et le port 80, ça peut faire bizarre comme sensation.

Ainsi à chaque IO, on donne éventuellement à une autre requête (ou une autre IO) la possibilité de s'exécuter. On minimise encore le temps d'attente des fils d'exécution. Cette démarche permet de tirer parti des infrastructures du noyau et de tenter de maximiser le temps d'exécution utile du CPU.

Moui… tu viens de décrire l’ordonnanceur du noyau, quoi, qui répartit les tâches entre différents processus représentant différentes applications qui écoutent sur des ports différents, non ?

En fait, la manie du tout-Web a amené de gros anciens SPOF sous forme dispatchers de requêtes HTTP.

Alors imagine quand ton sélecteur est à un offset donné dans ton paquet (= port de destination), facile à parser, qu'en plus en cas de problème de charge tu veuilles pouvoir répartir les requêtes avec l'assistance du client (= adresse IP de destination, obtenue par la base géante clé-valeur qui s'appelle DNS parmi un ensemble façon round-robin avec priorités, autrement appelés enregistrements SRV), ou alors si tu gardes une seule IP mais que tu veux pouvoir faire de la répartition de charge y compris sur ton architecture réseau amont (= flow ID ; seulement en IPv6), tu auras alors l'architecture ultime, distribuée, et qui en plus n'aura pas d'état incrusté dedans (= connexion HTTP ; la connexion n'a de sens que pour nœuds aux extrémités) et qui scalera à mort. Et tu pourras l'appeler « Internet ».

Sans parler de comment tu gères ta file quand elle est pleine, parce que le tail-drop ça fait plus de 20 ans qu'on sait que c'est mauvais.

Merci ! C'est bon. Même si au final je ne vois pas le source et ne sait pas comment tu as fait ;-)

Pour les masochistes comme moi qui veulent rester dans les « vrais » technologies du Web, en XSLT, plus long mais qui n'est pas un one-liner sans contexte qui aura perdu son sens dans le future quand javascript aura disparu (ahah!) :

<xsl:stylesheet
    version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    >

<xsl:template match="a">
    <li>
    <xsl:copy>
        <xsl:copy-of select="@href"/>
        <xsl:value-of select="@href"/>
    </xsl:copy>
    </li>
</xsl:template>

<xsl:template match="/">
        <html><body><ul>
        <xsl:apply-templates select="//a"/>
    </ul></body></html>
</xsl:template>
</xsl:stylesheet>

Donc en plus la sortie est du standard réutilisable, si vous voulez chaîner les transformations, et ne dépend pas d'un browser hyper complexe avec sa fonction de highlihting « géniale ». Et c'est forcément du HTML correct, sans même que je vérifie. Et les sélecteurs c'est du XPath, comme dit plus haut c'est très pratique.

Edit : et que dire des autres technologies « modernes » comme markdown qui ne te laisse pas écrire du XML (un langage à balise, la base de chez base du web) directement dans un commentaire sur Linuxfr ?…

D’ailleurs impossible de remettre la sourie sur ce site web où j'avais trouver ce cours. C'était un site en français, traitant de pas mal de sujet orientés réseaux (le NAT par exemple)dans les tons beiges et dans un "design" assez vieillot. La remarque qui va suivre n'est pas un reproche, il est bien comme il l'est; dans le genre de linufr.org ^

Le livre du G6 ?
http://livre.g6.asso.fr/
C'est vaguement beige, un peu vieillot (et pas très à jour), par contre ça ne traite pas d'autre chose que d'IPv6. Mais c'est une très bonne source d'information.

et qu'à côté il ya une IPv6 avec séparation identificateur-localisateur standardisée par l'IETF

Ça s'appelle Mobile IPv6 https://tools.ietf.org/html/rfc6275, ça a en plus été porté sur IPv4 (mais forcément, c'est moins bien fait), et ça n'intéresse que peu de monde. Donc non, compter sur une « killer feature » ne fonctionne pas.

Effectivement, c'est un modèle que j'avais également repéré. C'est une gamme « en-dessous » de la MB472dnw (résolution deux fois moindre, 600×600 au lieu de 1200×1200), mais la différence en qualité ne doit pas être gigantesque. Par contre, c'est 10 kg de plus : je pense que je ne pourrais pas la porter seule, contrairement à celle que j'ai acheté. C'est l'aspect qui m'a rebuté, en plus du coût de l'impression couleur (+300%, en gros).

Sinon en soldes sur RDC il y a également un modèle encore plus haut de gamme de la marque, couleur aussi, pour 324 € :
https://www.rueducommerce.fr/produit/oki-mc562dnw-imprimante-multifonctions-couleur-led-a4-210-x-297-mm-original-a4-support-jusqu-a-30-ppm-copie-jusqu-a-30-ppm-impression-350-feuilles-33-6-kbits-s-usb-2-0-lan-hote-usb-11796190/offre-68964560

Ça n'est pas la même gamme : déjà elle pèse deux fois moins lourd, donc ça doit être rempli de plastique plutôt que du métal. C'est plus une imprimante grand public.

Ensuite, niveau driver, aucune indication de standards pros supportés -> galère assurée. Pour moi ça vaut largement le coup de mettre deux fois plus pour un truc qui marchera à coup sûr.

Tout à fait possible. D'après Wikipédia, une MBR a une limitation à 2 To https://en.wikipedia.org/wiki/Master_boot_record
Après, pourquoi le disque lui-même… perso j'avais déjà vu un boîtier externe faire apparaître mon disque comme 8 fois moins grand, mais c'est parce qu'il rapportait son compte de secteur en blocs de 512 octets alors que c'était un disque 4 Ko. J'avais eu le même genre de problème avec LVM, que j'avais compris au final en voyant la taille de bloc différent.

Je sais que la touche « pause » fonctionne dans le BIOS, je ne sais plus pour le kernel.

Ou alors jouer sur le contrôle de flux avec Ctrl+s/Crtl+q ?

Note que j'ai testé l'ADF pour de la copie, pas pour du scan, qui comme je le relate plus haut je n'arrive pas encore à faire marcher. J'espère que ça fonctionnera bien.

J'oubliais, très important : elle a un ADF (Automatic Document Feeder) qui permet de faire des scans recto-verso automatiquement, par paquet de feuilles, et imprime bien sûr en recto-verso aussi. Je l'ai juste expérimenté une fois, mais c'est très utile !

Et en passant, sous son interface utilisateur très bouton (et pas tactile, j'adore !) avec son LCD graphique monochrome (vive les années 80, pour de vrai) se cache même un clavier complet pour taper des adresses & configurations, même si on a accès aux même menus (presque) par interface web.

Bref, elle est vraiment complète.