benoar a écrit 4240 commentaires

et tu n’as pas à faire cette horreur qui consiste à avoir des dns qui ne renvoient pas les mêmes résultats en interne et en externe.

J'ai beau essayer de le faire comprendre à beaucoup d'admins, ils sont pour la plupart convaincus que c'est au contraire un très bonne pratique. Citer des RFC ne les fait que réagir par un « TL;DR » à peine caché.

Et il ne faut pas utiliser le .local soi-même (c’est réservé au mDNS et ça peut mettre un sérieux merdier à ce que j’ai compris).

Effectivement, mais un admin m'a dit que « c'est une recommandation de Microsoft » (cf. https://en.wikipedia.org/wiki/.local#Microsoft_recommendations) et du coup refuse de faire autrement… sachant que j'avais « implémenté » du mDNS correctement sur le réseau juste avant. Pareil, citation de RFC, mais aucun admin n'en a jamais rien à foutre des standard, ce sont les meilleurs alliés de MS dans le trashage des standards.

Bref, je pleure régulièrement de l'état des réseaux d'entreprise et de l'obstination insistante des admins dans leur nullité.

PS : tout ça accompagné de NAT à gogo et d'un gros firewall qui fait du DPI pour l'accès au Net, sinon ça ne serait pas drôle. Il (un Fortinet) va même jusqu'à examiner le handshake TLS pour refuser certaines signatures, comme un client Tor, qui du coup match toutes les Debian stable, mais pas les Ubuntu, du coup je suis le vilain petit canard.

Mais est-ce que Google m'a jamais pris un seul "vrai" euro? Je ne sais même pas.

Il t'en a pris un paquet, et sans que tu t'en rendes compte.

La publicité est une taxe globale sur l'ensemble des produits vendus. Donc les produits que tu achètes contiennent déjà un part qui va à Google.

Ensuite, il n'y a pas que les entreprises privées qui achètent les produits des GAFA : les institutions publiques en raffolent, et ta municipalité ou ton musée ou ta bibliothèque y a sûrement déjà eu recours (c'est le cas des miennes ; va interroger ceux qui y travaillent). Sans parler des financements publics divers et variés qui servent à acheter des services à Google (= des données à data-miner). Et combien de temps vont résister les municipalités aux données triées sur la fréquentation des routes ou des équipements publics ? (ce services est déjà proposé aux magasins par Google)

Enfin, le fait que ces entreprises fraudent l'impôt font qu'ils volent directement à l'État un bon paquet de sous.

Bref, tu ne le sais pas mais dans le « coût » de ta vie (achats et impôts, ainsi que services publics non rendus dûs aux coupes budgétaires à cause des fraudes fiscales) il y a une bonne partie qui va vers les GAFA.

Des principes, ce serait une liste d'axiomes que Git garantit à l'utilisateur. L'associativité serait un exemple.

On tourne en rond. Je te dis que git est génial pour des choses qui n'ont rien à voir avec la théorie des patchs, et tu me rétorques qu'il lui manque la théorie des patchs…

Je n'ai absolument jamais dit ça. J'ai peut-être suggéré d'écouter mes arguments avant de dire "Git sera de toute façon tellement mieux que je n'ai pas besoin de t'écouter".

Oui pardon, j'ai un peu exagéré une interprétation personnelle de tes écrits. Mais j'avoue que je n'aime pas trop tes arguments se rapportant à « on a discuté avec des gens qui savent, et vous ne pouvez pas comprendre leurs problèmes », en gros, si je caricature.

le fait qu'il t'affiche un diff et qu'il travaille sur un objet complètement différent n'est pas ce que ferait C ou Unix, qui n'ont pas ce type de décalage.

Bah si, pour moi, c'est du style Unix. On doit vraiment en avoir une interprétation différente.

En tous cas, la vision de la « perfection de la théorie » que tu sembles avoir me paraît elle loin d'Unix : généralement, c'est la simplicité d'implémentation qui prévaut, dans cette philosophie.

Plus de détails !

Ça serait trop long. Moi par exemple je kiffe le design orienté format de données plutôt qu'API, qu'utilise beaucoup Torvalds. J'aime les principes d'Unix comme évoqué plus haut, mais je vois que chacun peut avoir des interprétations différentes (dire qu'on ne retrouve pas les concepts d'Unix dans git, inventé par le créateur de l'Unix libre majoritaire aujourd'hui… je comprends pas). Ça serait trop long à développer ici.

C'est une raison légitime pour ne pas écouter ce que je dis, et c'est honnête de le reconnaître.

C'était une blague, même si elle n'était pas drôle. Désolé.

Une partie des "avantages géniaux" que tu évoques sont utiles uniquement parce qu'ils permettent de compenser les problèmes posés par le manque de principes solides dessous.

Comment les avantages que j'ai cités seraient là pour compenser un manque de principe solide ? Quels principes exactement, puisqu'ils ne sont pas en rapport avec la théorie des patchs, à priori ? Tu restes vague et ça ne me convainc pas.

Et chaque commit a besoin de calculer un hash de tout le dépôt

Heu… WTF ? Git ne recalcule jamais de « hash de tout le dépôt » ! Pour quelqu'un qui me sort qu'il connaît git mieux que tout le monde ici… C'est justement ce qui fait la vitesse de git, il a juste besoin d'aller chopper les objets en relation avec le(s) commit(s) précédent(s), et que tout est hashé et donc dépend pas du tout de la complexité de ton dépôt, mais légèrement du nombre d'objets.

ces concepts ne sont pas orthogonaux : par exemple, les commits sont souvent affichés (et représentés à l'intérieur) comme des patchs.

WTF² ?! Git ne stock aucun diff lié à un commit : il a juste un algo de packing qui dé-duplique, mais sans aucune relation avec un commit donné. Ce dernier ne contient que des SHA1 du/des tree(s) référencé.

les relations entre ces concepts sont compliquées et floues, voire incohérentes : par exemple, les fichiers sont rebricolés à partir du contenu par des heuristiques, et les merges entre branches sont faits par 3-way merge, qui n'est pas associatif (pas associatif = des lignes ajoutées par Alice se retrouvent dans un morceau que Bob a écrit indépendamment).

Heu… oui, les « fichiers » sont effectivement juste du contenu et la liaison avec un path donné n'est pas reverse-trackée et juste trouvée par heuristique, mais c'est plutôt très clair et simple comme concept. Oui, ça fait que les copies et déplacement de fichiers avec modification sont suivis par heuristique, mais c'est très cohérent en fait : il n'existe de « vrai » lien entre deux fichiers modifiés et déplacés que dans la tête du programmeur, et vouloir tracker ça en plus du contenu va pouvoir amener à des difficultés qui font que git préfère simplement ne pas le faire. Oui, les 3-way merge ne sont pas associatifs, mais pareil, je ne sais pas si chercher absolument un sens à toute combinaison de patch ne va pas t'amener vers des problèmes simplement insolubles. Ou alors qui de toutes façons amèneront une telle complexité que personne n'en voudra.

Bref, pour quelqu'un qui dit très bien connaître git, je trouve certains de tes arguments légers. Après, je vois qu'on a une idée du design logicielle assez différente, et donc qu'on aura du mal à réconcilier nos arguments là-dessus, mais perso avec l'expérience (je vais ajouter un argument d'autorité : tu as l'air plus jeune que moi, vu tes vidéos ;-)) je trouve les concepts d'Unix, qu'on retrouve dans Git, vraiment géniaux.

Des gens ont effectivement dit ça, mais en pratique plein de projets et d'entreprises sont encore sous CVS.

Quel rapport avec git ? La réticence au changement en entreprise va parfois contre toute logique. Il y aurait le meilleur VCS au monde qu'ils resteraient à CVS…

C'est vrai dans plein de cas. Dans le nôtre, c'est plutôt l'inverse qui est vrai : Pijul est capable de reproduire tous les workflows possibles de Git, et peut faire des choses largement plus puissantes, tout en restant simple.

Alors j'avoue c'est bien présenté, et que ça donne envie d'aller voir. C'est bien d'avoir une certaine assurance comme tu le fais, et je vois que tu as la théorie derrière pour soutenir ton truc. Mais fais attention à ne pas voir toujours les défauts de git qui t'arrangent : tu pourrais passer à côté des choses géniales que tu ne remarques même pas. Genre le système sous-jacent exposé et exploitable, les formats de données simples et centraux, l'état du VCS exposé dans le filesystem, l'utilisation en shell facile (pas mal de fonctions de merge de git sont même juste du shell !). Plein de trucs sûrement « pas propres » et pas prouvés ni sûrs, mais qui le rendent génial.

Ce genre de trucs a déjà existé avant en informatique : dans les années 70, plein de gens adoraient la courbe d'apprentissage de leur langage préféré (et étaient très créatifs pour inventer de nouveaux langages obscures chaque semaine). Et à un moment, tout le monde s'est rendu compte que C offrait au moins la même puissance que les autres, en beaucoup plus souple et facile.

C'est drôle que tu prennes l'exemple du C, parce que justement il a une courbe d'apprentissage un peu rude quand même, il n'est pas parfait, et j'aurais donc fait le parallèle avec git…

Ce n'est pas du tout le principal problème de ces gros utilisateurs. Leur principale préoccupation est bien le passage à l'échelle : Git devient très lent sur les très gros dépôts,

Parce qu'il développent du soft d'une manière qui n'a aucun sens pour le libre. Souvent parce qu'ils ne veulent pas modulariser, parce qu'ils l'utilisent comme outil d'intégration, etc (c'est la liste que j'ai déjà citée). Et qu'aucun outil apportant les fonctionnalités de git ne pourra faire mieux en perf ; ils auront donc des très plus pourris, mais qui tiennent leur taille de projet. Ou alors ça serait une vraie révolution, mais j'y crois très peu. Pijul le serait, d'après toi ?

parce qu'il a besoin de tout l'historique de tout pour fonctionner.

Option « --depth » de git-clone, et pour aller plus loin voir le fonctionnement du fichier « shadow » dans le .git (je ne vois pas de doc, mais en gros tu peux mettre n'importe quel nombre de ref dedans qui permettent de cacher des parties de la hiérarchie ; ça fait partie des trucs avancés peu exploités mais qui donnent des idées).

Torvalds lui-même le considère comme très imparfait, (…) Tu as le droit d'être sceptique, mais dans la vraie vie plein de gens sont insatisfaits de Git, y compris son inventeur.

Ça fait deux fois que t'en parles mais je ne l'ai jamais entendu dire ça… source ?

Si je comprends bien, le dongle est en réalité un adaptateur ethernet USB relié à un routeur 4G.
vu que le routeur a la capacité d'embarquer d'un petit serveur web, on a donc un périphérique qui contient un ordinateur.

Pour être plus précis (bon, je parle d'un E3372, mais ça doit être proche), la clé a un CPU ARM chinois avec RAM et Flash et tourne sous Android. C'est un Linux avec plein de logiciels à priori libres dessus, mais dont on ne sait pas où sont les sources. Il y a des russes sur un forum qui ont reverse-engineeré le bousin (pas de lien maintenant, boulot, toussa) et qui ont reprogrammé entièrement la clé, si ça vous intéresse de bidouiller.

Le dongle faisant routeur + NAT avec la 4G, ça veut bien sûr dire zéro contrôle réellement sur le medium, ça interdit l'IPv6, ou tout autre truc qui sort un peu de l'ordinaire (IPsec, etc). Il existe plusieurs modes de fonctionnement, dont un pour revenir en PPP « simple », très peu documentés, variant avec les versions du firmware et les version du hard, qui ne sont bien sûr pas identifiés, ni trop documentés. Il plante régulièrement (enfin, ça dépend des versions), et pompe souvent plus d'1A sur le port USB (il chauffe bien, touchez-le !), donc par exemple ça ne marche pas avec des ports trop faibles en puissance (RasPi).

Ce qui est drôle c'est de parler « d'environnement libre » avec ce genre de cochonnerie.

Il se passera quoi quand l'OS embarqué dans le dongle sera troué? Quelles sont les garanties de mises à jour proposées par le fabriquant? Je ne connais pas les réponses mais bizarrement j'ai un gros doute.

Effectivement, ta clé sera utilisée comme zombie, ou aura un ransomware pour retrouver ta connexion, ou plein d'autres trucs drôles. Les MàJ bien sûr c'est zéro. Et ce sont des clés officiellement poussées par Orange pour la 4G, pour info.

Pouvoir y mettre openwrt

Je crois qu'il parlait de brancher cette clé sur un routeur avec OpenWrt, pas de mettre OpenWrt dessus, ce qui est pour l'instant impossible à ma connaissance.

Oui, sauf que ce problème peut être utilisé pour créer des failles dans un logiciel

Mouarf, avec ton exemple, là ? Je veux bien un exemple concret, pour moi ça reste un cas irréaliste.

Sur les autres avantages et "Git va être le meilleur", c'est un peu ce qu'on disait de SVN quand Git est sorti.

Ah bon ? J'ai pas souvenir de ça. Dès le début, c'était le soft « codé par Torvalds » et même s'il était difficile d'accès, très vite les gens ont reconnu sa supériorité (et les problèmes de SVN) même si on imaginait une période de transition pendant laquelle SVN allait rester encore présent. Mais j'ai rarement vu un soft prendre de l'ampleur aussi rapidement que git !

Il n'est pas 100% honnête (et même pas 99,999% honnête) de dire "Git est supérieur" en oubliant les questions essentielles du temps d'apprentissage et du passage à l'échelle sur de gros dépôts et de grosses équipes.

Oui c'est vrai. Mais étant partisan des courbes d'apprentissage paraboliques, j'estime que ça vaut le coup à long terme.

Par contre, on ne l'a absolument jamais entendu des gens avec qui on a parlé qui travaillent sur de très gros trucs (par exemple chez Apple ou Facebook, ou même des gens qui gèrent les dépôts du noyau Linux).

Chez Facebook & co, et dans les entreprises en général, il y a des contraintes particulières qui font qu'il est moins adapté, mais ce sont pour moi de mauvaises raisons : soit ça donne trop de liberté aux devs et les chefs n'aiment pas ça (git c'est vraiment pour que chaque dev soit complètement indépendant, c'est très présent dans son idéologie, ya pas à dire), soit ça n'intègre pas tout le nécessaire d'intégration et on le tord pour en faire un outil d'intégration et ça marche mal, soit on fait des trucs crades parce que « on n'a pas le temps » et du coup ça foire parce que les branches deviennent n'importe quoi. Bref, oui, git impose une certaine méthodologie de développement (bien qu'il n'impose pas de workflow particulier), et c'est celle qui est au cœur du Libre : indépendance, fonctionnalités bien isolées (il y a d'autres outils pour l'intégration), et nécessité d'être plutôt propre et maintenable car c'est le seul moyen d'être gérable quand peu de gens contribuent.

C'est intéressant de se poser ces questions (même si pour « des gens qui gèrent les dépôts du noyau Linux », je suis sceptique), mais je pense que ça a très peu à voir avec la théorie des patchs. Après, si tu veux t'atteler à la résolution des autres « défauts » de git, pourquoi pas, mais à ce moment-là ça n'est plus une histoire de théorie des patchs, qui semble pourtant être ton cheval de bataille ici.

Et on soupçonne un tout petit peu que les gens qui nous disent ça "oublient" en général de mentionner qu'ils ont passé 10 ans à essayer de le comprendre, lus des quantités ahurissantes de livres, de blogs et de manuels pour essayer de forcer Git à rester dans les clous des axiomes que Pijul garantit au débutant qui fait son premier dépôt avec un pote, sans avoir la moindre idée de ces trucs ni de notre théorie.

Je pense rentrer dans ta description, effectivement, même si elle est légèrement exagérée sur les besoins de maîtriser git comme il faut ; on y arrive avant 10 ans en général :-) Cependant, je suis convaincu que ça en vaut la peine. Alors que souvent, les soft plus abordables, c'est agréable à utiliser au début, puis quand on les maîtrise bien, ils deviennent limitants et on passe à autre chose…

Plus tard je merge X dans master: il y a un conflit car X est appliqué deux fois, git ne réalise pas que c'est "le même commit".

Dans 90% des cas, git va réaliser que c'est le même commit (cf. git-patch-id(1)). Dans 9% des cas où il bloquera, on se rendra compte que le merge n'est pas si « évident » que ça en pratique, et peut-être qu'il va même nécessiter de le re-travailler. Et dans 1% des cas, peut-être que oui, il aurait pu s'en rendre compte et le faire tout seul mais n'y arrivera pas. Et pour augmenter encore la possibilité de résolution, utiliser git-rerere(1).

Bref, pour 99% des cas qui concernent ce problème précis, git va être le meilleur en pratique. Et vu que ce problème n'est pas rencontré si souvent, dans 99,999% des cas d'utilisation de git en général, il sera supérieur. À moins que tu arrives au même niveau sur tout le reste de git : fiabilité, communauté, évolution, rapidité, etc.

Ça n'est pas pour te décourager, tu dis toi-même que c'est un projet d'expérimentation, et c'est très bien. Dire que la théorie des patchs, « c'est bien », oui, peut-être, mais je ne vois pas en quoi en pratique ça changera quoi que ce soit : l'exemple donné dans ton premier commentaire est complètement tiré par les cheveux et n'arrivera jamais en pratique. Oui, c'est mieux quand un outil semble « parfait » jusqu'au bout, mais pour ce problème en particulier je pense qu'on n'arrivera jamais à une jolie théorie des patchs qui n'ait pas des perfs de merdes et une complexité ahurissante, tout ça pour un gain très très minime.

Bon courage pour l'expérimentation en tous cas, ça doit être marrant à coder !

Quand on y pense, git gère des « liens » placés dans un work-tree vers une version spécifique d'un fichier dans sa « base de données ». En pratique, ce sont des fichiers, mais l'opération de check-out correspond à une sort de « mise à jour des liens ». Bon, l'analogie est moyenne, mais chez moi ça a donné ça :

http://dolka.fr/code/gitweb/?p=dotfiles.git;a=summary

Bref, des dotfiles gérés réellement comme des fichiers (puisque j'ai juste déplacé le work-tree dans $HOME), et une utilisation à la git juste en changeant le nom de la commande, « dotg » (à part pour les commandes spécifiques de création initiale). Pour le code directement à lire, c'est ici :
http://dolka.fr/code/gitweb/?p=dotfiles.git;a=blob;f=bin/dotg;hb=HEAD

C'est sous GPLv3+.

est-ce que tu veux que tes utilisateurs puissent utiliser ton logiciel ou préfères-tu qu'ils ne puissent rien faire pour les protéger ?

Fausse dichotomie.

Pour eux, une suggestion directe de la bonne recherche dans la barre d'adresse est certainement une très bonne chose (ils ne savent pas ce qu'est une adresse).

Oui, avec un air paternaliste et en les prenant pour des cons. C'est comme dire que ça ne sert à rien de savoir lire, on va s'occuper de tout pour toi. Pour moi, dans une société libre, savoir ce qu'est une URL est la base que devrait connaître tout citoyen ; ça devrait s'apprendre à l'école. Alors forcément, il y aura toujours des entreprises pour prendre avantage des ignorants, mais ça n'est pas une justification, surtout quand on est Mozilla on qu'on a (il me semble) une volonté d'éduquer un minimum les gens sur le fonctionnement du Web.

TorBrowser est un fork de Firefox qui lui justement vise un marché d'utilisateurs plus expérimentés, qui comprennent ce qui se passe (et qui cherchent à comprendre ?) et qui préfèrent sacrifier une partie de leur confort pour mieux protéger leur vie privée.

TorBrowser c'est pour les terroristes et les pédophiles… (je caricature). Je ne vois pas pourquoi un utilisateur standard ne mériterait pas le droit à la protection de sa vie privée. Il ne devrait pas y avoir deux catégories de citoyen, à part si tu aimes bien te sentir dans la catégorie de « ceux qui savent » et que tu aimes bien entretenir les autres dans l'ignorance.

Ce que je trouve être des informations privée, c'est la communication de la moindre touche que tu appuies sur ton clavier à Google. Pour moi c'est une sorte de limite qu'il ne fallait pas dépasser. Depuis longtemps, j'ai un peu en tête une règle générale qui est « mes entrées sont envoyées lors de la validation par la touche entrée » ; c'est une sorte de règle implicite que je trouve valide dans plein de cas (OK, pas pour SSH…). Ici, Mozilla a cassé cet accord implicite.

Peut-être que c'est une question piège ? Il faudrait idéalement répondre que c'est une très mauvaise idée du point de vue sécurité d'essayer de réimplémenter un générateur pseudo-aléatoire quand on n'est pas un spécialiste hyper-pointu du domaine.

les suggestions de recherche sont activées par défaut pour les utilisateurs qui ne les ont pas désactivées explicitement (passage de opt-in à opt-out)

Alors ça c'est la modification qui me troue le plus le cul : je trouvais pas mal le comportement de demander à l'utilisateur lors de la première recherche dans la barre de navigation (elles étaient déjà actives pour la barre de recherche ; je ne l'utilise personnellement jamais) s'il veut activer l'auto-complétion ou non. C'était une des protections essentielles de la vie privée que je voyais encore active dans Firefox (et ça a l'air d'être encore vaguement dans leurs priorités vu que plus loin dans la dépêche ils semblent vouloir « protéger un peu mieux la confidentialité des données utilisateurs »).

Je vois bien que les priorités de Mozilla sur la vie privée changent un petit peu à chaque version, depuis longtemps, et qu'ils le font façon « fable de la grenouille », mais ça devient de plus en plus insupportable.

[Hors Sujet, un peu]

Sur PowerPC les différentes variantes du shift (comme le rotate, si on peut vraiment le considérer comme tel) sont synthétisées par une seule instruction « rlwirm » — dans la grande tradition du RISC — qui est juste paramétrée différemment. Cf. le Programming Environments Manual, dont le tableau F.4.2 trouvable ici http://www.csit-sun.pub.ro/~cpop/Documentatie_SMP/Motorola_PowerPC/PowerPc/GenInfo/pemappF.pdf résume bien la génialité de la chose : on pourrait presque imaginer, en regardant par exemple les tableaux détaillant le codage consécutif des instructions ici http://www.nxp.com/assets/documents/data/en/reference-manuals/MPCFPE32B.pdf, le câblage du CPU devant ses yeux (juste un bit change pour un paramètre différent qu'on retrouve dans plein d'instructions similaires, de manière à minimiser le coût en transistors).

Malheureusement, ça n'est pas exploitable directement en C, et le compilateur doit en déduire des manipulations d'entier si l'instruction unique est émissible.

Bon, ça c'était l'instruction avec une valeur de shift immédiate, mais il existe aussi les version indexées par un registre.

Et pour revenir au journal, arithmétique modulo ou pas, rotate ou shift, tout est géré par cette instruction magique comme vous le souhaitez : il n'y a pas un choix plus « logique » que l'autre.

le mandat de prélèvement est dorénavant le moyen standard pour transférer de l'argent entre un organisme ou entreprise et un particulier, et c'est le seul moyen qui permette un traitement automatisé des payements (sans envois de bouts de papier qui, de toutes façons, n'assurent aucune sécurité supplémentaire).

C'est complètement faux par rapport au journal que j'avais posté : le virement SEPA est également un moyen très standard de régler des dettes en Europe. C'est utilisé dans tous les autres pays, sauf la France… Comme tu précises plus bas, c'est peut-être « source d'erreur » pour l'état, mais pour le citoyen c'est un pouvoir de négociation non-négligeable qui lui permet de choisir si la demande de règlement est légitime ou non. Et ça ça n'est pas négligeable du tout : on inverse complètement le rapport de force qui existait jusqu'à présent.

Il y aurait peut-être un effort de normalisation à faire de la part des banques sur la référence du paiement, mais ça c'est un peu dû à l'incompétence des banques qui n'ont même pas été foutues d'avoir un format commun de référence SEPA à foutre dans les credit transfer/direct debit.

Moi ça fait des années que j'ai un setup avec un modem ADSL sur le même réseau que le LAN, et ça marche très bien. OpenWrt sait gérer ce genre de setup depuis bien longtemps.

Je n'ai pas le routeur sous la main, mais en gros, tu as ton LAN appelé « lan », et tu indique que ta connexion WAN en PPPoE passe également par ce réseau « lan ». Comme ça, hop, un modem avec un seul Ethernet, un routeur pareil, un gros switch au milieu, et tout roule.

Je ne comprends pas que tant de monde ait des problèmes avec des routeurs à un seul port Ethernet, même si je peux comprendre qu'au premier abord, un routeur avec seulement une prise Ethernet ça peut paraître étrange.

Ta question m'a intriguée, chez moi ça marche. En fait, c'est le nouveau format de fingerprint de ssh. Pour avoir l'ancien, en md5, il faut faire (avec la nouvelle version de ssh-keygen, que je n'ai pas en Debian stable) :

ssh-keygen -E md5 -lf ~/.ssh/id_rsa.pub
Cf. http://stackoverflow.com/questions/9607295/how-do-i-find-my-rsa-key-fingerprint

Récupérer ses programmes ouverts peut-être éventuellement ?

« Éventuellement » ? Pour moi c'est absolument indispensable ! J'utilise le suspend-to-ram et l'hibernation à fond, et ces fonctionnalités sont tout bonnement indispensables pour une utilisation correcte de mes machines.

Regardez comme Apple a même supprimé la modalité « d'alimentation » de sa machine : elles sont toujours allumées, vous ne pouvez même plus vraiment les « éteindre », et vous retrouvez toujours tous vos programmes disponibles sans avoir à les démarrer… C'est vraiment très bien fait !

J'ai l'impression de le répéter souvent : le swap est au contraire toujours très utile quand tu utilises beaucoup de programmes. Ton kernel va pouvoir mettre « de côté » certains programmes (sur le swap) pendant qu'il utilise plus de RAM pour un autre, que ça soit en mémoire allouée ou en cache disque. Sans swap, il devrait garder tous les programmes en RAM tout le temps, même ceux qui sont actuellement inutilisés. Vois ça comme une sorte « d'hibernation » pour programme peu utilisé.

Pour aller encore plus loin, idéalement, le swap permettrait de supprimer la modalité « programme chargé ou pas ». Dans l'idéal, on n'aurait pas à savoir si on doit « démarrer » un programme ou pas, il aurait un état « permanent » qu'on (enfin, le kernel) chargerait comme il veut. Allez voir le checkpoint/restore pour voir ce que ça donne quand on étend le principe du swap à un état partitionnable et transférable entre machines (le swap ça serait un état propre à une seule machine).

Notez aussi qu'il existe aussi déjà un « swap implicite » avec le mapping à la demande des programmes et bibliothèques présents sur le disque. Bref, le swap c'est utilisez à fond le principe de mémoire virtuelle, qui a été inventé il y a longtemps mais que j'ai l'impression les jeunes générations n'apprennent plus…

C'est une parodie de la vidéo « bien connue » (pas pour les français…) effectivement. Et une autre très bonne : https://www.youtube.com/watch?v=xuxO6CZptck.

en tout cas pour les clients pro

C'est également le cas pour les particuliers, et depuis un bout de temps.

Je ne l'utilise plus mais mon téléphone SIP Siemens marchait très bien derrière un NAT ipv4. Je crois qu'il utilisait STUN pour cela mais quoiqu'il en soit c'est possible. Le fait que le NAT est utilisé par défaut depuis 2 décennies pour l'acès internet des réseau domestique fait qu'on a depuis mis en place toute sorte de méthodes et que ça n'en fait pas un accès [i]minitel[/i].

Je pense que ton téléphone ne marchera plus aussi bien aujourd'hui, et ne marchera plus dans le futur, à cause des « CGN » et autres conneries pour minitéliser Internet. C'est le problème d'IPv4 : ça va marcher de moins en moins bien ; enfin, pour les protocoles qui exploitent vraiment l'architecture d'Internet. Pour consulter FB, forcément, oui, ça marchera toujours… Mais la non mise en place d'IPv6 va finir de tuer ces usages décentralisés.

Pour tes arguments sur la non-migration, bien sûr qu'ils sont valides et comptent aussi, mais le miens sur « l'ouverture » que permet IPv6 n'est pas anodin non plus, et prend de plus en plus d'importance au fur et à mesure que les premiers deviennent de moins en moins valable.

En général, derrière un NAT, on a accès à tout Internet…

Tu as accès au Minitel, oui, mais tu ne fais pas partie d'Internet. Donc tu n'auras pas de téléphone SIP qui marche (ton FAI se garde de la concurrence ainsi), tu ne pourras pas t'autohéberger facilement, tu ne pourras pas avoir de service de télévision multicastée (ton FAI te « l'offre », pourquoi aller voir ailleurs ?), etc.

Et en l'occurrence, concernant Linuxfr ou les VPS OVH, je ne vois même pas où est censé être ce « NAT protecteur ». Ce n'est pas parce qu'un hébergeur ne fournit pas IPv6 que l'IPv4 du serveur est NATtée.

Je pensais qu'on parlait des FAI pour le grand public, quand tu disais qu'ils étaient à la bourre sur IPv6. Je parlais du NAT sur le grand public, donc.

Tu ne serais pas en train de chercher à inventer des coupables ? Je n'ai jamais vu d'applications qui serait écrites en imposant à l'utilisateur d'être derrière un NAT.

Je n'ai pas dit ça. Je dis au contraire que les applications actuelles sont souvent codées pour s'accommoder du NAT, du coup les opérateurs les utilisent comme excuse pour ne pas proposer IPv6. En oubliant de parler des problèmes pour les applications qui tirent profit complètement de l'architecture d'Internet : SIP, P2P, etc.

Oui, enfin franchement, j'ai l'impression que tu as rencontré un jour dans ta vie un cas de framework mal codé, et que tu extrapoles à la Terre entière parce que ça t'arrange de croire que tous les autres codent comme des gorets alors que toi, tu as tout compris.

Je ne dis pas que « j'ai » tout compris, ça vient de l'IETF. Les applis étaient relativement bien codées jusqu'à maintenant, c'est juste qu'on vient mettre une couche avec les containeurs qui casse souvent ces applications. C'est cette régression que je déplore.

Franchement, je n'ai pas l'impression que les services logiciels les plus répandus ne soient pas compatibles IPv6.

Les services « les plus répandus », oui, mais ceux qui créent des services au-dessus et qui cassent tout en les utilisant mal…

Par contre, des opérateurs ou des fournisseurs d'accès qui ne fournissent pas de connectivité IPv6 correcte, ça existe encore

Oui ça c'est vrai que c'est l'autre gros point noir ; je m'y était juste tellement habitué que je n'y fais plus gaffe. Mais ça n'est pas près d'arriver, vu que c'est pour des raisons commerciales : offrir de l'IPv6, c'est ouvrir le marché de se abonnés captifs derrière leur NAT « protecteur »…

Je me doute bien qu'il y a quelques bouts de code de-ci de-là qui ne connaissent que AF_INET, mais ce n'est pas le problème dominant.

C'est le problème dominant de la couche « service » uniquement, mais ça n'est pas rien. C'est également une des excuses des opérateurs : les applications « n'en ont pas besoin », vu que tout est codé pour s'abstraire d'IP à cause des NAT et de réinventer des couches d'abstraction usine à gaz en-dessous.

Corrigeons : très peu de gens se soucient de l'API socket parce qu'ils développent des services réseaux à un plus haut niveau, en se basant sur un canevas logiciel ou au minimum une couche d'abstraction existante. On est en 2017…

Oui, mais souvent ils l'utilisent mal… Par exemple, au-delà des sockets pur, savoir utiliser getaddrinfo() : tu vas me dire que c'est abstrait par les framework, mais non, souvent soit ils ne l'utilisent pas, soient ils l'utilisent mal ; on doit normalement itérer sur les résultats pour jauger la connectivité, pour des raisons de transition, de répartition, et de disponibilité. Encore une fois, ces frameworks veulent souvent abstraire ça et rajouter un couche, et foutent la grouille parce qu'ils n'ont pas compris que seule l'application elle-même peut prendre des décisions sur le choix des destinations en fonction de leur atteignabilité.

Malheureusement, j'ai rarement (voire jamais) vu une bonne séparation des rôles comme tu le prônes en pratique. C'est dans quel genre de boîte que tu vois ça ?