Firwen a écrit 562 commentaires

Même Amazon qui fabrique du VPC comme d'autres mangent des cacahuètes préconisent IPv4 dès que ton archi devient un peu complexe niveau flux.

Amazon a toujours traîné les pieds pour IPV6, ils sont d'ailleurs le seul entre Microsoft, Google, Facebook, Amazon and Cloudflare qui ne resolve pas en v6 actuellement.

Même les gens qui font de l'IOT utilisent IPv6 pour l'adressage mais passent en ZigBee dès que possible pour le transport.

ZigBee a rien avoir avec IPV6. ZigBee c'estp as du layer 3 mais quasiment un protocol full stack L2 -> L7. Spécialisé dans le low-power, middle range, il joue clairement pas dans la même cours.

La plupart de l'IOT domotique et autre de nos jours n'utilise plus ZigBee mais IPv4/V6 avec MQTT ou CoAP en layer 7

Donc si on résume : IPv6 fonctionne très bien et peut tout faire, c'est juste que les constructeurs, les opérateurs, les développeurs de softs, les fournisseurs de solutions de virtualisation - que ce soit propriétaire ou libre, coté client ou coté réseau - ne veulent pas, ou ne pannent rien ou les deux.

Il y a du vrai mais c'est clairement exagéré. Chez moi (home), au alentours de 30% du traffic sort et rentre en IPv6… Car GAFA… Car wikipedia… car IoT… Car server perso.

Merci de ton commentaire. 👍
Ton commentaire nous rappelle que, nous, développeurs (surtout ceux, comme moi, qui viennent du C++), avons tendance à nous focaliser sur la performance au lieu de prendre de la hauteur et de lister les priorités du projet, les fonctionnalités attendues…

Je suis dev C++ depuis plus de 10 ans et ce n'est pas mon approche sur la performance. Ce que tu décris la ressemble surtout à de l'inexpérience en tant que software architecte.

C++/Rust sont des langages unique en leur genre car il te donne la puissance d'utiliser ta machine jusqu'au dernier bit si tu en as besoin. Ça ne veut pas dire que tu dois le faire, et dans 99% des cas, tu ne dois pas le faire.

En premier vient les features, en deuxième vient comment implémenter ces features en identifiant les besoins et les chemins critiques, et les évolutions de ses chemins critique ( scalabilité) en terme de performance.

Dans une grande majorité des cas (en dehors du monde HPC), ce qui t'évite les problèmes de performances viennent de ton architecture ( persistence, latence appels réseau, back-pressure, bottle-neck caché, ), et non des micro optimisations de tes frameworks.

Les préfixes privés dans IPv6 sont par définition unicast.

Yep, comme en v4 où les prefix de multi-cast sont spécifiques.

Ma question est plus : en quoi avoir un préfix v6 privé t'empèche d'avoir du multi-cast dessus ?

Déjà IPv6 a 25 ans. Donc je ne sais pas trop combien de temps il va falloir pour amener la convergence

La convergence apparait quand tu l'utilises à l'échelle généralement. IPv6 a été pendant 20 ans à -2% d'adoption car tout le monde s'en foutait: "c'était pour demain".

SIP au passage est de 1999. Donc pas si loin, et pourtant c'est toujours le bordel pour avoir un système de join / notifications qui marche cross soft-phone et des implémentations qui traversent les NAT correctement.

Ça devrait marcher, mais ça marche pas. Tu te creuse la tête, tu cherches - tu apelles Arista/Juniper/Cisco et ils te disent tous "Pour le multicast, n'utilisez pas l'overlay, utilisez l'underlay".

Ça selon moi c'est une fausse excuse. Si le constructeur est pas foutu de se justifier sur "pourquoi" ça marche pas, c'est sa faute, pas celui du standard.

J'ai du mal à voir pourquoi le multi-cast serait un problème en V6, quand le multi-cast lui même est utilisé pour les fonctionalités coeur du standard, incluant RA et NDP. Ça ressemble plutot à une faute constructeur qui s'est foiré lamentablement en implémentant son overlay maison.

Donc tu utilises des adresses privées. Sauf que du coup tu n'as pas le multicast

Tu as un cas en tête où utiliser un prefix privé cause un pb pour le multi-cast ? ( en restant dans un scenario où tu ne cast pas au delà du segment )

Chaque équipement, chaque système de virtualisation de réseau, chaque OS a une interprétation subtilement différente des parties de la norme qu'ils ont décidés d'implémenter avec la version en cours.

Ça j'ai envie de dire, c'est le cas avec toutes les normes réseaux. Il n'y a que le temps qui amène une convergence. Même en 2019, il n'y a pas un seul endpoint SIP qui implémente la norme complètement.

Faire de l'overlay non unicast en IPv6 (eVPN/VXLAN) est un casse tête sans fin

Tu peux expliquer pourquoi je suis curieux ? Le multicast en V6 est pas si différent du V4.

mais quand il s'agit de fusionner des branches réseaux entières (avec plusieurs plages, du routage, de la propagation DNS dynamique par segment etc.) c'est le mur.

Tu as un cas concret ?
En théorie en V6, tu es censé balancé le concept de plage privée tout ensemble et de rester sur des plages publiques avec un bon firewall. Donc fusionner des branches réseaux n'est pas censé être un cas courant non ?

Mais peut-être que, justement, GCC était l'un de ces «compilo dégeulasse»?

Non seulement c'est du troll, mais c'est irrelevant.

Je n'ai jamais critiqué les qualités techniques de LLVM/Clang qui est un excellent projet / compilateur.

Ce que je critique c'est la license du projet qui a permis de créé toute une génération de compilateurs proprio effectivement dégeulasses, mal supportés et intouchables. Tu l'as trés bien compris je pense d'ailleurs.

Ton commentaire sur GCC n'a aucun intérêt car GCC, comme Clang, comme tout compilateur Open Source n'a pas ce problème car il est Open Source, donc modifiable, donc évoluable.

À priori, Stallmann a accumulé les coquilles au fil des années et vu le rafut qu'à produit la dernière c'est normal qu'il perde son poste. C'est pas comme s'il n'avait pas déjà bénéficié de jokers.

C'est absolument pas ça que je critique.

Ce que je critique c'est la position précédente et ce qu'elle transmet

Et c'est aussi vrai pour la communauté virtuelle du libre, dont pas mal de membres le considèrent encore (on se dedisent que quand ils voient le vent tourner) comme une idole du libre.

Car c'est un non sens. Que l'homme ait fait une faute, soit. Et que ça soit le cas ou pas n'est pas le débat. Mais ça n’enlève rien à ce qu'il a accompli par le passé et à ce fait que ça soit et restera une figure du Libre.

Quelques opinions personnels qui n'ont rien à voir avec ses actions professionnelles ne doivent pas et ne devraient pas faire passer quelqu'un du status de "légende vivante" dans son domaine, à "erreur qu'on aimerait oublier".

Et de ce que je lis ici, ou sur mon fils twitter. Ils sembleraient que ses détracteurs aient un poil de mal à faire la différence. Pour lui, et pour beaucoup d'autres.

Mais surtout, ça montre le problème de fond : il aurait dû être viré depuis longtemps du fait de son comportement réel (et non fantasmé), et le fait qu'il ne l'ai pas été avant (ou au minimum de gros avertissements) peut amener beaucoup de questions sur… ceux toujours en place et n'ont pas agit avant.
Et c'est aussi vrai pour la communauté virtuelle du libre, dont pas mal de membres le considèrent encore (on se dedisent que quand ils voient le vent tourner) comme une idole du libre.

C'est ton avis, pas celui de tout le monde.

Je suis quelqu'un qui n'affectionne pas spécialement RMS et ses positions tranchés… MAIS

Je me fou éperdument de ce qu'il dit à titre personnel sur des sujets qui ne sont pas liés au logiciel libre, tant que ce qu'il dit sur le logiciel libre est consistent, utile et construit. ( ça on peut en débattre ).

Tout comme je m'en bas joyeusement que Polanski soit accusé de viol, ça ne change strictement rien à ses qualités de réalisateur.

Tout comme je m'en cogne royalement que certains physiciens / scientifiques Allemands étaient nazis pendant la 45, ça ne change rien au génie dont ils ont fait preuve dans leurs inventions et au fait qu'ils ont laissé leur nom dans l'histoire.

Ce culte de l'homme parfait, irréprochable qui se doit d'être Brillant au travail, et totalement impeccable sur tous les plans : famille, social, éloquence, état d'esprit, et pourquoi pas aspect physique… me donne envie de vomir.

C'est du puritanisme américain pure souche avec sa concentration de connerie: Personne n'est parfait, et c'est souvent les personnes qui pensent en dehors des clous et qui sont socialement inacceptable qui changent réellement les choses. Pour le meilleur et pour le pire. Le monde en est tellement bourré d'exemple.

La majorité des rock's star et des génies de la musiques des années 60-70 étaient presque tous des drogués, asociales, insupportables, punk au mieux, violents voir violeurs au pire….
Ça n’empêche en rien que c'était des génies incontestable dans le domaine de la musique, et qu'ils ont laissé leur trace dans l'histoire.

Il en va de même dans tous les domaines, incluant le monde logiciel n'en déplaise aux juges improvisés des réseaux sociaux (et tabloides pas de gamme) : Personne n'est parfait, vous y compris.

Bah bien sûr une entreprise qui vend des processeurs elle a tout intérêt à te filer un compilateur qui marche pas avec, comme ça tu ne peux pas utiliser leur matériel correctement et tu finis par acheter celui du concurrent. C'est pas du tout suicidaire comme approche.

C'est pourtant ce qu'a fait IBM avec le marché du HPC et XLC pendant pratiquement 10 ans avec un compilo complétement aux fraises.

Il y a la théorie et il y a la pratique.

La pratique c'est que celui qui achète du hardware, c'est rarement celui qui code sur la platforme. Et le nombre de bugs associé au compilateur pourri, proprio, que tu ne pourras jamais toucher car non Open Source, il n'est pas marqué sur le power point du type qui te vend le hardware.

Par le passé, beaucoup de vendeurs se sont pliés à fournir un backend GCC pour leur platforme car:

1- C'était ce que les clients voulaient.
2- Créer son propre compilateur C/C++/Fortran from scratch était beaucoup trop cher.

Maintenant, ils pourront éviter ça en forkant leur propre bouse à partir de LLVM et re-brander ça comme un "compilateur" maison.

Oh surprise, c'est déja ce qui se fait avec :

• Le compilateur "ARM", car c'est connu un compilo platforme specifique c'est toujours mieux.

• XLC, qui aprés avoir faillit mourrir pour le bien commun, malheureusement est réssussité derrière LLVM.

• Nvidia, qui n'attend qu'une chose c'est de dropper le frontend GCC à CUDA pour fournir son propre tool proprio "key in hand" avec toutes les merdes en terme de compatibilités qui vont avec.

• Apple qui vampirise déja clang et LLVM pour son compilo maison, propriétaire et qui respecte à moitiés les standards.

• Sony, pour son compiler Playstation.

• Et un peu prés tous les fournisseurs de platformes embarquées chinoises qui fournissent leur propre compilo.

Le vieux dogme BSD "vous verrez, ils reviendront au libre quand ils verront que c'est mieux pour eux" ne marchent pas et n'a jamais marché et ne marchera jamais.

Car ce n'est pas comme ça que le monde du business marche.
Car les gens qui prennent les décisions de sous quelle licence sera ton soft ne comprennent rien au logiciel libre et ça ne les intéresse absolument pas d'ailleurs.

LLVM est une toolchain géniale. Mais la license ultra-permissive made-in-apple de LLVM a juste ouvert la porte a une génération entière de compilo dégeulasse qui resteront imbuvables et buggés alors que ces même compilateurs étaient sur la voie de l'exctinction, pour le bien commun.

Sérieux, c'est vraiment le genre de commentaire qui incite à s'éloigner de la GPL, à la vue de l'extrémisme quasi religieux de ses défenseurs contre ce qui ne plaît pas…

Il a raison et ça n'a rien d'extrèmisme.

Une bonne partie des grandes compagnies, spécialement dans le hardware, ne publient en OSS que parce qu'elles y sont forcées, pas par plaisir.

NVidia, Qualcomm, Broadcom entre autres.

Et il y a des raisons à ça, car d'un point de vue managériale, défendre sa propriété intellectuelle est plus important que la substituabilité d'un écosystème et d'une plateforme.

Le résultat, c'est des compilateurs propriétaire, périmés, buggé, et plus supportés depuis 10 ans car pas rentable… Et des drivers binaires inutilisables, impossible à faire évolués qui te lock sur des versions préhistoriques.

Ça n'a rien de "théorique", je peux te donner une bonne dizaine d'example… Et la gueule / le status des drivers des BSD comparé à Linux parle de lui même sur le sujet.

Ca permettra juste aux fabricants de puces de modifier les compilos et de ne pas devoir donner les sources.

Ça se fait déja.

Les dernières versions du compilateur XLC d'IBM sont basées sur LLVM. Et tu pourras toujours te brosser pour avoir les modifications apportées Martine.

Bref, je vais m’arrêter, ni vous, ni moi ne changerons d'avis sur cet homme, le reste serait du troll sans intérêt.

[troll]

Tu ne parlais pas de "changer", "d'acceptance" et de "nuances" ? Juste avant ?

L’extrémisme et les opinions tranchées, ça va dans les deux sens il semblerait :)

[/troll]

Quoi ? Comment ça c’est pas comparable ? :p

Tu peux créer un PEX ( https://github.com/pantsbuild/pex ) ou un nix-bundle (https://github.com/matthewbauer/nix-bundle) pour une vrai comparaison.

Mais je suis pas sur que tu veuilles poster le résultat ^{^}

C++ semble vraiment être un langage d'expert

C'est un language système, donc qui touche à tous les aspects de la machine (mémoire, …etc), donc complexe.

Est-ce qu'il faut être un expert pour l'utiliser, comme tous les langages de programmation: non.

Par ailleurs c'est une mauvaise idée de naviguer dans la stl, en tout cas celle de g++, le code est difficilement lisible, et tu pourrais prendre des choses comme acquises qui ne font pas partie de la norme.

Yep +10.

La STL (et boost ) ne sont clairement pas des exemple en terme de lisibilité.

Ça peut être posé à l'opposé pourquoi écrire un projet en C++ aujourd'hui, plutôt qu'en python et ne coder que la partie qui prend de la puissance de calcul/mémoire en C++ ?

C'est ce que fait une grande partie du monde du calcul scientifique et de l'artificial intelligence à l'heure actuelle ( tensorflow, pytorch ). C'est une approche valide pour certains champs d'utilisations.

Pour d'autres cas d'utilisation plus orienté "système" : coder une database, un broker, un FS, un game engine, un service lourd système à faible latence, forte charge. Le python apporte plus d'inconvenient qu'ils n'apportent d'avantages, à mon humble avis.

De faire des gros calculs numériques ? Python est très très bien équipé avec pandas, numpy, pytorch et autres projets de calcul scientifique. Ces projets sont écrits en C/C++, leur utilisation en Python te permet donc de bénéficier des perf d'une implémentation native. Il faut vraiment avoir besoin de calculs haute performance très très spécifiques pour tomber en dehors des service fournies par l'écosystème déjà présent.

Encore une fois tu confirmes ce que je dis. Tes performances "correcte" en python tu ne les a que parce que un bon gars est passé par la avant toi et a fait un module python en C++ qui va bien pour traiter ce cas d'utilisation en pybind11, boost.python ou autre.

Le python tu ne l'utilises que pour scripter au dessus de ça, et c'est trés bien.

Corrige moi si je me plante quelque part :

template<typename Proxified> class proxy : public Proxified {
public:
     explicit proxy(Proxyfied && origin) : Proxified(std::move(origin) {}

     // define here all my method orverride for my proxy
     virtual int my_proxy_method() override{};
};

Est-ce que ce snippet ne ferait pas le boulot pour une re-definition statique ET proxyfié que tu recherches en C++ ?

• L'intégralité des methodes et propriétés de "Proxified" sont disponible dans l'interface de ton objet proxy.

• Tu peux override à souhait toute methode de "Proxyfied".

• Le tout a un impact en terme de performance null si ta classe supporte correctement le move-semantic.

Ça m'est totalement obscur. Voir ça en 2019 m'a fortement déçu sur l'évolution de C++ et de son écosystème. Et le bout de code en exemple, je l'ai trouvé sur le net

J'ai du mal à voir l'obscurité dans ton snippet de code précédent: Tu construis un vector en utilisant deux iterators qui suivent le pattern [begin, end[ que la grosse majorités des API de la STL utilisent.

Ton iterator est dans ce cas un simple pointer. Ce sont des features simple du C++, voir même du C.

Il n'y a même rien de moderne dans ce snippet, ni C++11, ni C++20. C'est du bon vieux C++98 des familles.

Je suis désolé si je suis méchant, mais peut-être est-ce que le problème de base est ton niveau en C++ comparé aux deux autres languages.

Un chose que j'admet aisément sur C++, est que l'apprentissage est difficile.

La courbe d'apprentissage est non linéaire et implique un gros effort initial, des connaissances du C, du pré-processeur, des phases de compilations du C, des aspects bas niveau du memory management / layout. La phase d'entrée pour être "efficace" en C++ est longue et rebutante pour la plupart des développeurs.

A tel point que un de mes critère de recrutement quand j'interview un développeur C++ est comment il se qualifie lui même. Si il se qualifie "d'expert", il est directement disqualifié. Très peu de personnes peuvent se qualifier d'expert, à part certaines personnes du comité C++ lui même.

Mais ça ne change rien que pour moi, une fois maitrisé, C++ offre une puissance, une productivité et un écosystème que trés peu de langage peuvent se targer d'avoir. Si ce n'est aucun avec une tel maturité.

Sur les performances, tu te contredis toi même. Oui beaucoup de modules python sont en fait du code C/C++ donc pas de baisse de performances à prévoir…

Absoluement pas, car dans ce scénario tu fais du développement C/C++ un pré-requis au développement python pour les parties perf critical. Qui suivant ton secteur, peuvent arriver trés rapidement.

Désolé, mais je désapprouve un peu prés tous les arguments que tu avances

ton application C++ en 30ans tu l'a réécrite 2 fois au moins (une fois pour prendre en compte C++98 et une pour C++11) si tu t'en es bien sorti. Oui tu as aussi dû réécrire ton application python pour passer à python3 on est d'accord. C'est juste pour dire que la maintenance de ce genre de code même en C++ ce n'est pas trivial du tout.

En pratique tu ne fais jamais ça. Sauf si ton software lead est incompétent.

C++20 est toujours compatible avec C++98, tu ne réécris pas pour le plaisir de réécrire. Tu migres lentement la code-base pièce par pièce en utilisant les nouvelles fonctionnalités du C++ moderne quand requises.

Certaines code-base C++ dépasse plusieurs millions de ligne de code, ré-écrire ça tous les 6 mois est impensable.

il est beaucoup plus simple d'écrire des tests, mais vraiment beaucoup. Le duck typing (ou le typage structurel) est un bonheur pour ça

Boost.UnitTest ou Catch2 permet d'écrire des tests en 5 lignes de code.
Les templates te permettent de généraliser tes testes automatiquement à N types si nécessaire.

Le duck typing n'apporte rien ici, le duck typing et le typage dynamique ont généralement l'effet inverse. Ils rendent nécessaires des batteries de testes larges et complexes pour gérer le large eventail d'input / possibilité que le duck typing autorise sur ton code et tes fonctions.

il existe un outillage autour de python beaucoup plus riche que pour C++.

5 ans en arrière j'aurai dit oui. Aujoud'hui je dis non.

C++ a maintenant ses lintians, C++ a ses analyseurs statiques (plus puissants que en python car typage statique), C++ a ses auto-formateurs, remote-debugger, sanitizer, etc etc.

L'ecosystème n'a plus grand chose à envier à python si ce n'est son propre package manager, qui comme je l'ai déja dit X fois ici est une fausse bonne idée.

Avec le typage dynamique on a beaucoup plus d'informations de typage au runtime. C'est très utile quand tu fais des programmes configurés par les données par exemple.

Le typage dynamique est aussi un cauchemars à tester par sa nature.

Car tu n'as aucune garantie que l'objet qui t'est passé a les propriétés nécessaires à l'execution de ta fonction et des N fonctions qui lui sont imbriquées.

La seule manière de vérifier ça c'est justement de le tester, là où un typage statique te garantie qu'un object construit d'un type donné a effectivement les propriétés requises.

Après tu parle de cas général le typage du C++ est relativement pauvre, on peut faire des circonvolutions pour tenter d'encoder des choses en plus dans les types à coup de templating, mais plus aucun humain ne sera en mesure de reprendre le code en question.

Le typage en C++ est tout sauf pauvre, le typage du C est pauvre.

Il s'approche au fil des standard de ce que tu peux avoir en Haskell et OCaml, qui sont des références dans le domaine.

std::variant autorise même maintenant à avoir une forme de pattern matching.

std::optional apporte lui aussi son lot d'avantages.

Par contre on ne teste pas la cohérence de la mémoire en python. Donc pas besoin de valgrind et vu la complexité de mise en place de valgrind (il faut jouer des scénarios etc). Je pense que tu y gagne.

Presque plus personne n'utilise valgrind de nos jours, sauf pour du debugging. ASAN et BSAN de g++ et clang++ font 95% pourcent du boulot de valgrind, sans les problèmes de performances, et sans la complexité de mise en oeuvre.

Quand je lis ton poste, j'y vois beaucoup de confusion. Tu pointes de vrai problèmes mais passe à coté de solutions qui existent ou simplement que tu pourrais éviter.

On réfléchit à une solution de secours, et me voilà chargé de développer une application en Python en intégrant des briques sous licence libre.
Je travaille alors en étroite collaboration avec les utilisateurs finaux et on sort l’application en quelques mois.

Et Il y a aucun mal à ça. Un langage de script comme python se prêtera toujours mieux au prototypage. C'est par contre à proscrire pour toute application long terme. Car très vite impossible à maintenir dés que la code base d’élargie.
Tout dépend de la solution que ton client veut: Un petit tool de dépannage pour une chaine de prod où un service / client qui va être utilisé 10 ans et supporté en prod ?

En Python, Node.js, Ruby, Go, Rust on a pip, npm, gem, go-get, cargo qui simplifie le téléchargement des dépendances, et l’intégration au projet avec un import xxxx. De plus, certains IDE prennent en charge cette gestion des dépendances.

Tu confonds trois choses : Configuration, Compilation et Deploiement.

La configuration se fait avec un buildtool, la compilation se fait avec ton compilateur, le deploiement se fait avec un package manager. La seul différence en node.js, rust ou go est que la communauté te "cache" ses étapes derrière un tool "clé en main" pour le meilleur et pour le pire (il y a des threads entier sur internet sur les horreurs que peuvent faire npm ou pip…). A l'opposé, C++ te donne un contrôle total sur ta chaîne de tooling.

Si tu veux ta solution "clé en main", je te conseil simplement un combiné Nix + CMake + GCC et tu retrouveras le même modèle que celui que tu connais.

A mon humble avis, coupler package manager et build tool est une grave erreur. Car elle conduit a des îlots applicatifs isolés impossible à utiliser dans des langages tiers. ( e.g intégrer un tool Go dans un package python ).

La majorité des problèmes que tu décris dans ton poste: compilation lente, difficulté d'intégrer un composant, trop de build systèmes, mauvaise productivité, vient de ton problème de tooling.

Autrement dit : Essaie Nix, GUIX ou Spack.