Si je ne me trompe pas l'opérateur en C++ te donnera toujours une valeur. En cas d'accès incorrect ça peut être la porte d'entrée pour une attaque. En Rust tu as une interruption du programme donc la pire attaque possible c'est un deny of service.
Les accès operator[x] en C++ sont l'équivalent de get_unchecked en Rust.
Dans les deux cas, c'est unchecked et sans interruption. Dans les deux cas, un accès out of bound est une porte d'entrée pour une attaque, même en Rust.
La différence est que dans le cas de Rust, tu dois explicitement déclarer le call en unsafe: c'est donc explicite et visible. Là où ça sera plus subtile à voir en C++.
Et avant que j'oublie: J'en rajouterais une autre plus récente: constexpr. constexpr En C++14/17/20 qui permet de garantir qu'une fonction est exécutée à compile time.
Tout ce qui est fait à compile time n'est plus à faire au runtime. Faire la même en C demande généralement de faire de la generation de code: c'est chiant, c'est casse gueule et ça ne se fait généralement que si c'est strictement nécessaire.
Un bon exemple de ça est la bibliothèque pour regex d'Hana qui détruit la majorité de la concurrence en terme de performance:
L'inlining qui est beaucoup-beaucoup plus agressif et puissant en C++ du au système de template: Ca permet de retirer des appels de fonctions là où ils ne sont pas utiles. Le prix a payé par contre c'est les temps de compilation.
Le système de type beaucoup plus puissant (lambda functions, Generics, strict aliasing) qui donne au compilateur les mains libres pour des optimisations là où un compilateur C aurait jeté l'éponge car il serait déjà dans une soupe de pointeurs void*.
Ces raisons sont plutôt bien illustrée par (C) qsort vs (C++) std::sort
Si tu sais que l'accès est bien dans le tableau mais que le compilateur ne peux pas le savoir, tu peux marquer l'accès unsafe et utiliser get_unchecked.
Je n'ai jamais dit que ça ne pouvait pas être évité, juste que c'est un coût par défaut :)
Oui en utilisant 'unsafe', donc en perdant la memory safety sur des sections spécifique, le coût au runtime peut être by-passé et en Rust on peut égaler le C++.
A noté que je dis C++ car C++ tend déjà a être plus rapide que du C.
Ça revient en pratique à la même différence que en C++ entre les accès .at() (safe) et les accès via opérateur .
L'avantage de Rust est que ce genre d'opération doivent être marquée de manière explicite et c'est une très bonne chose.
En C++ pour du code safety-critical, on tend à le faire via analyses statiques au niveau du CI, ça se fait mais ça reste moins "pratique" à utiliser
Sur nos cas d'évaluation, code bare-metal pour micro-contrôleurs à fonctionnalités strictement égales nous avions les mêmes performances en C et Rust à 0,1%
C'est aussi ce que j'ai remarqué entre C++ et Rust pour du code non-vectorisé.
Et quand grosse différence de perf il y a, ça vient principalement de l'auto-vectorization qui s'est appliqué dans un cas et pas dans l'autre.
Dans le cas du Kernel, ça n'a aucune importance car la plupart des instructions de vectorisations sont inutilisables (en auto-vec) en espace kernel.
Principalement le Bound checking: Le fait de vérifier qu'un accès se fasse bien dans les limites d'un vecteur, d'un tableau, d'un itérateur a un coût en terme d’exécution. C'est un problème que le C n'a pas vu que tous les accès mémoires se font en mode YoLo sans aucune vérification.
Rust a aussi une forte tendance à copier/bouger les choses en mémoires car c'est une manière de contourner les limitations du Borrow checker sans utiliser RC / ARC (du comptage de reference). Ça a un impacte en terme de performance, même si probablement minime comparé au C.
Rust utilise LLVM en backend, donc il a le niveau d'optimisation et la maturité de C et C++ pour la partie backend. Ça se voit assez bien sur le programming language bench game
On peut tout à fait ne pas être d'accord avec les arguments
C'est actuellement la raison de mon poste précédent:
L'auteur a tout à fait raison sur le caractère anormale de la richesse des multi-milliardaires actuels
Non ça ne change rien au fait que la fortune des multi-milliardaires est sur-évalués même si elle reste colossales à cause de la nature (stupidité) même du marché des actions.
Comme je le disais dans mon poste, aucun multi-milliardaire ne retire jamais l'intégralité de ses actions en cash. Ça ne leur est pas souhaitable économiquement voir impossible légalement.
Même les transactions honteusement élevées qu'il note dans son poste ne représente que quelques pourcents de leur fortunes totale.
Donc oui ça reste des fortunes virtuelles… Mais des fortunes virtuelles tellement colossales que même les quelques pourcents "réel" qu'ils en extraits représentent déjà une fortune honteusement élevée et complètement disproportionnées comparée au salaires de leur employés.
Et le fait qu'ils arrivent à éviter les impôts sur cette partie également est encore plus discutable.
Le fait que la fortune des multi-milliardaires sont sur évaluées par les analystes de tout bord ne change rien à la raison pour laquelle cette infographie a été crée: Oui l’extrême richesse des multi-milliardaires dans le monde actuel est un problème:
Ils contribuent à accroître les inégalités.
Ils concentrent beaucoup trop de pouvoir dans trop peu de mains.
Ils évadent massivement les taxes, voir contribue à développer l'optimisation fiscale et par conséquent ne paient pas leur due à la société.
Les associations / personnes qui dénoncent ça ont entièrement raison.
Au passage ton argumentaires foireux, ta vindication et ton agressivité ne les aident absolument pas dans leur tache.
Bah si, ça montre que tu sais pas de quoi tu parles, et que t’as (manifestement) toujours pas compris. Tu confonds PDG, actionnaire, CA, assemblée.
C'est surtout toi qui trolle sans savoir de quoi tu parles ou par pure mauvaise foi.
Allez dans l'ordre.
Il en résulte qu’un actionnaire majoritaire peut se nommer lui-même comme PDG
Bezos a 11% (environ) des shares d'Amazon, il n'est en rien actionnaire majoritaire. Bien loin de là, surtout quand il y a des boites comme Blackrock et Vanguard parmis les plus gros actionnaires.
Il y a effectivement des contraintes pour un PDG (ou tout autre haut cadre) s’ils veut vendre ses actions
Il y a souvent, voir même tout le temps, les même contraintes pour les membres du conseil d'administrations et les plus gros actionnaires. Sans même parler que toutes transaction majeures sont soumises à des regles et doivent généralement être annoncées à la SEC.
Après si tu me dis que dans les statuts ou le montage juridique mis en place par Bezos ou autres il y a dans ce cas particulier une règle qui l’empêche de tout vendre. Ok
C'est bien évidemment le cas pour la majorité des boites où des fonds d'investissement importants ont des parts. Pour des raisons évidentes Captain': Je ne suis pas sur que l'investisseur moyen apprécierait que son fond de pension se fassent dévaluer parce que Bezos a fait un vesting.
Si t’as toujours pas compris, je considèrerai que t’es de pure mauvaise foi (pour preuve : tu n’utilises plus le même argument, d’un purement économique tu passes à une contrainte qui serait contractuelle — que tu viens probablement d’inventer ceci dit
Ironie Ironie, tu racontes de la merde et tu viens te plaindre quand quelqu'un te debunk.
C'est ça, et ils ne peuvent tellement pas dépenser cet argent qui n'est pas à eux qu'ils doivent aller à la soupe populaire et faire la manche pour mettre du kérosène dans leurs jets privés.
Tu te trompes de cible là: je n'ai jamais dit qu'ils ne sont pas riche, ni qu'ils ne peuvent pas extraire bien plus que nécessaires des actions qu'on leur donne.
J'ai dit que leur évaluation de fortune ne représente pas la réalité, ce qui est vrai et c'est différent. Que ça te plaise ou pas.
Ils peuvent (dans le cas de Bezos) généralement toucher des sommes à 7 zeros chaque année. Et pire encore, ils peuvent souvent le faire sans payer de taxes.
Ils peuvent extraire du peu d'actions qu'ils échangent chaque année plus d'argent que tu ne gagneras (probablement) pendant toute ta vie. Et oui, je suis d'accord pour dire que c'est également un problème.
Même la vente de 100% des actions d’un actionnaire majoritaire est totalement possible.
On parle d'Amazon là, pas de la PME du coin:
Ce genre de personne / position ont généralement des clauses dans leur contrat qui leur interdit formellement de faire ce genre de chose
Toute decision du genre est prise par le conseil d'administration de l'entreprise, pas par Bezos lui même.
Les stocks que ce genre de haut exécutif possèdent sont généralement régulé par contrat: Ils doivent les garder pour des durées définies et ne peuvent en trader qu'un petit pourcentage défini justement pour éviter les mouvements de paniques sur les marchés.
Autant que je déteste les inégalités, je trouve ce genre de diagrammes trompeurs. Pour ne pas dire voir clairement de mauvaise foi.
Ni Jeff Bezos ni Bernard Arnaud ni Musk n'ont réellement cette fortune ni même proche de cette fortune.
Ce que beaucoup de personnes ignorent c'est la nature de leur fortune: Ce qu'ils ont c'est des actions, c'est tout (principalement).
On estime leur fortune totale uniquement sur la dernière valeur en bourse de cette action. Si ils essaimaient de "cash back" ces actions en liquide, le cours s'éffondrerait instantanément à cause du volume en jeu. Et la valeur réelle serait nettement moins que la valeur estimée.
Ils n'ont pas cette fortune, ce qu'ils ont c'est de l'argent virtuel sur lequel un marché a collé une valeur spéculative tout aussi virtuelle.
Ceci dit, ça n'excuse en rien les travers avec les super riches:
La plupart ne paient presque pas d’impôts à cause de la nature de leur fortune, des montages qu'ils font avec. Certaines années le FISC américain a même remboursé de l'argent à Bezos. C'est simplement Honteux.
Le fait que leur fortune vient de la valeur des actions font qu'ils ont intérêt à maximiser la valeur de l'action de l'entreprise souvent au détriment de l'entreprise elle même (stocks buy back en Anglais). Et c'est absolument terrible pour les salariés et l'entreprise sur le long terme (coucou GE et Boeing).
Et la liste serait très longue à détailler pour un Dimanche.
Vous enfoncez certainement tous les deux des portes ouvertes :) :
Le Google C++ style guide est vieux: pre-C++11. Il date d'une époque où la RAII n’était pas répandu et la majorité des code bases n'étaient pas exception safe. Dans ce cadre, oui l'exception ban était justifiée.
Pour information, Google est dit d'avoir une code-base C++ qui s'approche ou dépasse le milliard de ligne de C++, il est presque impossible de changer une règle sur les exceptions du jour au lendemain sur des code bases de cette taille sans grosses conséquences.
De l'aveu du Monsieur C++ Engineering chez Google, la policy serait certainement différente si c'était à refaire aujourd'hui.
Les exceptions (comme mechanisme, en dehors de C++) sont un excellent moyen de faire de l'error report de manière sure et concise sans un code trop verbeux.
En C++, l’implémentation actuelle du mechanisme d'exceptions souffrent de plusieurs problème ( RTTI, nécessite des allocations dynamiques, utilise l’héritage, UB quand appelée dans les destructeurs, nécessite un runtime, vulnerabilite DDOS, type leaking, etc… ) qui fait que même en 2022, certaines codebases ne peuvent pas se permettre de l'utiliser ( safety critical, kernel code, etc ).
Posté par Firwen (site web personnel) .
En réponse au journal tesla.
Évalué à 8.
Dernière modification le 27 décembre 2021 à 17:48.
Ceci dit s'il faut se baser sur les expériences personnelles… Mon « vieux » Diesel en est à 3 freinages d'urgences en 230000km.
Votre mauvaise foi n'a pas de limite kilométrique pas contre il semblerait.
Mais si il faut nourrir le troll: je qualifie de freinage d'urgence tout freinage qui n'était pas pleinement anticipé: un piéton qui traverse, la voiture de devant qui freine plus rapidement que prévu, un feu qui passe au rouge à la dernière minute, un ralentissement un peu fort sur autoroute, etc…). Pas le freinage automatique de la voiture en prévention d'accident.
Ce sont uniquement ces situations qui requièrent les freins en BEV, le restant se fait purement en freinage régénératif. La conduite se fait principalement avec une seule pédale.
Excepté si vous conduisez exclusivement votre vieux Diesel en plein Sahara (avec un poil d'aigreur il semblerait), je ne pense pas que vous n'ayez rencontrer ce genre de situation uniquement 3 fois en 230K Km.
Surtout que les accélérations violentes sont justement ce qui produit la pollution locale (poussières de pneumatiques et de plaquettes de freins).
Vous n'avez pas conduit beaucoup de VE pour sortir ce genre de conneries de tabloïd.
En VE (BEV), on ne touche quasiment jamais le frein. Le freinage re-generatif fait 95% du travail. A titre d'exemple, sur un trajet de 600km pendant la période de Noel, j'ai du toucher aux freins environ 5 fois ( freinage d'urgence uniquement ).
Les accélérations violentes et le 0-100 en 3s c'est fun 15 minutes devant les copains et pour ceux qui font du circuits. Pour le reste, tes cervicales et ton autonomie vont vite te faire comprendre que le mode "confort" et donc faible acceleration vont t'aider a dormir mieux.
C'est le proxy qui est connecté à internet et qui est chargé de délivrer un contenu filtré selon les politiques de l'entreprise à l'utilisateur.
Je ne vois pas d'aberration là dedans.
Soit le proxy est configuré sur du whitelisting-only ET sur un subset de service / addresse Cloud bien définis, nécessaire à l'entreprise et tout le reste est bloqué: c'est défendable.
Soit comme trop souvent, c'est juste là pour faire du Man-in-the-middle et le traffic HTTP/HTTPS est en open bar sur (presque) tout internet. Ça sert uniquement à ouvrir le traffic HTTPS et bloquer tout le reste: Et C'est c'est complètement con
1- Ça crée un bottleneck sur le trafique dans l'entreprise car tout le contenu HTTP/HTTPS sortant passe par là.
2- Ça crée un point de vulnérabilité gigantesque dans l'entreprise car toute personne qui prend le contrôle du proxy peut "ouvrir" le trafique et accéder aux logins / mots de passe de tout le monde, incluant même les second facteurs.
3- Ça rend excessivement chiant l'utilisation de tout logiciel qui utilise du trafique non-HTTP (Vidéo conférence, Messaging, client Email lourd, VPN ) et ça fait souvent buguer une bonne partie des sites web qui utilisent les Web Sockets.
4- C'est un faux argument de sécurité, car je peux te donner 20 manière d'exfiltrer des données en overlay sur du HTTPS et ni ton proxy ni toi n'y verront rien du tout.
5- A l'opposé, la majorité des malwares aujourd'hui n'ont aucun problème à bypasser ça.
Donc oui je réitère ce que j'ai dit: c'est complètement con.
C'est un théâtre de sécurité périmétrique qui réduira la productivité de vos utilisateurs sans fournir la moindre protection contre les attaques modernes ( crypto-lockers, phishing, social-engineering, etc ).
Nous sommes en 2021, la sécurité périmétrique est morte et enterrée. Apprenez à faire avec.
Joli mot pour désigné une grosse ignobilie qui ouvre du trafique sécurisé en faisant des attaques man in the middle sur TLS via un proxy et des certificats installés de force sur les machines clientes.
Ce genre de connerie est un trou de sécurité béant, un non-sens complet dans une politique de sécurité en 2021.
Ce sont les managers de tes sysadmins et leur consultants (ceux qui ont mis ça en place) qu'il faudrait brûler.
Quand je monte une instance chez OVH, l'IPv4 supplémentaire me coûte 2€ et elle est accessible partout et par tous.
J'ai vraiment du mal avec ce genre d'excuses.
90% des services accessibles de nos jours sont via HTTP et derrière CDN type Cloudflare (ou alternative) ou un cluster de reverse proxy.
Même si vous utilisez IPv4 en interne, ajouter le support IPv6 sur la gate du CDN et éditez les 4 entrées DNS qui vont bien c'est histoire de 20s.
Donc oui c'est souvent de la paresse, de la méconnaissance ou (en entreprise) la fuite de responsabilités. Mais l'argument est rarement technique ni financé.
Bref, le dual-stack c'est compliqué, c'est sûr, et quand on réalisera qu'on pourra simplifier l'applicatif avec un réseau plus simple, l'IPv6 commencera peut-être à prendre.
Exactement. Une bonne solution de transition serait de l'IPV6 only coté client avec un NAT64/DNS64 sur la box / passerelle maison pour la transition.
Une des raisons principale pour laquelle ça n'a jamais été fait est que jusqu’à encore récemment, le support IPV6 des smartphones / imprimantes lambda était encore relativement précaire.
Justement, le cgnat et autres, ça finit par couter, il vaut mieux faire du stateless. Et c'est sans doute ce qui fait bouger les FAI. Et je pense que c'est une des raisons qui va faire migrer vers IPv6, IPv4 finit par coûter
Tout à fait. Mais les FAIs ne sont pas les seuls dans la balance. Tant que les grands hébergeurs ne seront pas forcé à fournir un adressage V6 sur tout ce qui est publique, les FAIs devront garder leur X niveaux de NATs.
Les hébergeurs ne sont pas les seuls à blâmer d'ailleurs.
L'état de IPV6 dans le monde des "gadgets" IoT et périphériques grands publiques est ridicule alors que ce serait les premiers à en bénéficier.
[^] # Re: Performances
Posté par Firwen (site web personnel) . En réponse au journal Rust dans Linux, ça démarre fort!. Évalué à 4.
Petit exemple sur godbolt: https://godbolt.org/z/6Wfe17r8o
[^] # Re: Performances
Posté par Firwen (site web personnel) . En réponse au journal Rust dans Linux, ça démarre fort!. Évalué à 5.
Les accès operator[x] en C++ sont l'équivalent de get_unchecked en Rust.
Dans les deux cas, c'est unchecked et sans interruption. Dans les deux cas, un accès out of bound est une porte d'entrée pour une attaque, même en Rust.
https://doc.rust-lang.org/src/core/slice/mod.rs.html#398-400
La différence est que dans le cas de Rust, tu dois explicitement déclarer le call en unsafe: c'est donc explicite et visible. Là où ça sera plus subtile à voir en C++.
[^] # Re: Performances
Posté par Firwen (site web personnel) . En réponse au journal Rust dans Linux, ça démarre fort!. Évalué à 9.
Et avant que j'oublie: J'en rajouterais une autre plus récente: constexpr. constexpr En C++14/17/20 qui permet de garantir qu'une fonction est exécutée à compile time.
Tout ce qui est fait à compile time n'est plus à faire au runtime. Faire la même en C demande généralement de faire de la generation de code: c'est chiant, c'est casse gueule et ça ne se fait généralement que si c'est strictement nécessaire.
Un bon exemple de ça est la bibliothèque pour regex d'Hana qui détruit la majorité de la concurrence en terme de performance:
https://github.com/hanickadot/compile-time-regular-expressions
[^] # Re: Performances
Posté par Firwen (site web personnel) . En réponse au journal Rust dans Linux, ça démarre fort!. Évalué à 10.
Les principale raisons sont:
L'inlining qui est beaucoup-beaucoup plus agressif et puissant en C++ du au système de template: Ca permet de retirer des appels de fonctions là où ils ne sont pas utiles. Le prix a payé par contre c'est les temps de compilation.
Le système de type beaucoup plus puissant (lambda functions, Generics, strict aliasing) qui donne au compilateur les mains libres pour des optimisations là où un compilateur C aurait jeté l'éponge car il serait déjà dans une soupe de pointeurs void*.
Ces raisons sont plutôt bien illustrée par (C) qsort vs (C++) std::sort
https://www.geeksforgeeks.org/c-qsort-vs-c-sort/
https://martin-ueding.de/posts/qsort-vs-std-sort/
[^] # Re: Performances
Posté par Firwen (site web personnel) . En réponse au journal Rust dans Linux, ça démarre fort!. Évalué à 6. Dernière modification le 29 septembre 2022 à 12:00.
Je n'ai jamais dit que ça ne pouvait pas être évité, juste que c'est un coût par défaut :)
Oui en utilisant 'unsafe', donc en perdant la memory safety sur des sections spécifique, le coût au runtime peut être by-passé et en Rust on peut égaler le C++.
A noté que je dis C++ car C++ tend déjà a être plus rapide que du C.
Ça revient en pratique à la même différence que en C++ entre les accès .at() (safe) et les accès via opérateur .
L'avantage de Rust est que ce genre d'opération doivent être marquée de manière explicite et c'est une très bonne chose.
En C++ pour du code safety-critical, on tend à le faire via analyses statiques au niveau du CI, ça se fait mais ça reste moins "pratique" à utiliser
C'est aussi ce que j'ai remarqué entre C++ et Rust pour du code non-vectorisé.
Et quand grosse différence de perf il y a, ça vient principalement de l'auto-vectorization qui s'est appliqué dans un cas et pas dans l'autre.
Dans le cas du Kernel, ça n'a aucune importance car la plupart des instructions de vectorisations sont inutilisables (en auto-vec) en espace kernel.
[^] # Re: Performances
Posté par Firwen (site web personnel) . En réponse au journal Rust dans Linux, ça démarre fort!. Évalué à 5.
Principalement le Bound checking: Le fait de vérifier qu'un accès se fasse bien dans les limites d'un vecteur, d'un tableau, d'un itérateur a un coût en terme d’exécution. C'est un problème que le C n'a pas vu que tous les accès mémoires se font en mode YoLo sans aucune vérification.
Rust a aussi une forte tendance à copier/bouger les choses en mémoires car c'est une manière de contourner les limitations du Borrow checker sans utiliser RC / ARC (du comptage de reference). Ça a un impacte en terme de performance, même si probablement minime comparé au C.
[^] # Re: Performances
Posté par Firwen (site web personnel) . En réponse au journal Rust dans Linux, ça démarre fort!. Évalué à 2.
Rust utilise LLVM en backend, donc il a le niveau d'optimisation et la maturité de C et C++ pour la partie backend. Ça se voit assez bien sur le programming language bench game
https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html
[^] # Re: Super rich, super bullshit
Posté par Firwen (site web personnel) . En réponse au journal La richesse des ultra-riches, à raison de 1000 USD par pixel. Évalué à 6.
C'est actuellement la raison de mon poste précédent:
L'auteur a tout à fait raison sur le caractère anormale de la richesse des multi-milliardaires actuels
Non ça ne change rien au fait que la fortune des multi-milliardaires est sur-évalués même si elle reste colossales à cause de la nature (stupidité) même du marché des actions.
Comme je le disais dans mon poste, aucun multi-milliardaire ne retire jamais l'intégralité de ses actions en cash. Ça ne leur est pas souhaitable économiquement voir impossible légalement.
Même les transactions honteusement élevées qu'il note dans son poste ne représente que quelques pourcents de leur fortunes totale.
Donc oui ça reste des fortunes virtuelles… Mais des fortunes virtuelles tellement colossales que même les quelques pourcents "réel" qu'ils en extraits représentent déjà une fortune honteusement élevée et complètement disproportionnées comparée au salaires de leur employés.
Et le fait qu'ils arrivent à éviter les impôts sur cette partie également est encore plus discutable.
Bref, on enfonce des portes ouvertes ici.
[^] # Re: Super rich, super bullshit
Posté par Firwen (site web personnel) . En réponse au journal La richesse des ultra-riches, à raison de 1000 USD par pixel. Évalué à 10. Dernière modification le 28 août 2022 à 14:33.
Et au passage histoire d'enfoncer le clou:
Le fait que la fortune des multi-milliardaires sont sur évaluées par les analystes de tout bord ne change rien à la raison pour laquelle cette infographie a été crée: Oui l’extrême richesse des multi-milliardaires dans le monde actuel est un problème:
Ils contribuent à accroître les inégalités.
Ils concentrent beaucoup trop de pouvoir dans trop peu de mains.
Ils évadent massivement les taxes, voir contribue à développer l'optimisation fiscale et par conséquent ne paient pas leur due à la société.
Les associations / personnes qui dénoncent ça ont entièrement raison.
Au passage ton argumentaires foireux, ta vindication et ton agressivité ne les aident absolument pas dans leur tache.
Cordialement.
[^] # Re: Super rich, super bullshit
Posté par Firwen (site web personnel) . En réponse au journal La richesse des ultra-riches, à raison de 1000 USD par pixel. Évalué à 6.
C'est surtout toi qui trolle sans savoir de quoi tu parles ou par pure mauvaise foi.
Allez dans l'ordre.
Bezos a 11% (environ) des shares d'Amazon, il n'est en rien actionnaire majoritaire. Bien loin de là, surtout quand il y a des boites comme Blackrock et Vanguard parmis les plus gros actionnaires.
Il y a souvent, voir même tout le temps, les même contraintes pour les membres du conseil d'administrations et les plus gros actionnaires. Sans même parler que toutes transaction majeures sont soumises à des regles et doivent généralement être annoncées à la SEC.
C'est bien évidemment le cas pour la majorité des boites où des fonds d'investissement importants ont des parts. Pour des raisons évidentes Captain': Je ne suis pas sur que l'investisseur moyen apprécierait que son fond de pension se fassent dévaluer parce que Bezos a fait un vesting.
Ironie Ironie, tu racontes de la merde et tu viens te plaindre quand quelqu'un te debunk.
[^] # Re: Super rich, super bullshit
Posté par Firwen (site web personnel) . En réponse au journal La richesse des ultra-riches, à raison de 1000 USD par pixel. Évalué à -1.
Merci captain obvious mais ça ne change strictement rien à ce que je disais avant.
[^] # Re: Super rich, super bullshit
Posté par Firwen (site web personnel) . En réponse au journal La richesse des ultra-riches, à raison de 1000 USD par pixel. Évalué à 5. Dernière modification le 28 août 2022 à 12:56.
Tu te trompes de cible là: je n'ai jamais dit qu'ils ne sont pas riche, ni qu'ils ne peuvent pas extraire bien plus que nécessaires des actions qu'on leur donne.
J'ai dit que leur évaluation de fortune ne représente pas la réalité, ce qui est vrai et c'est différent. Que ça te plaise ou pas.
Ils peuvent (dans le cas de Bezos) généralement toucher des sommes à 7 zeros chaque année. Et pire encore, ils peuvent souvent le faire sans payer de taxes.
Ils peuvent extraire du peu d'actions qu'ils échangent chaque année plus d'argent que tu ne gagneras (probablement) pendant toute ta vie. Et oui, je suis d'accord pour dire que c'est également un problème.
[^] # Re: Super rich, super bullshit
Posté par Firwen (site web personnel) . En réponse au journal La richesse des ultra-riches, à raison de 1000 USD par pixel. Évalué à 2.
On parle d'Amazon là, pas de la PME du coin:
Ce genre de personne / position ont généralement des clauses dans leur contrat qui leur interdit formellement de faire ce genre de chose
Toute decision du genre est prise par le conseil d'administration de l'entreprise, pas par Bezos lui même.
Les stocks que ce genre de haut exécutif possèdent sont généralement régulé par contrat: Ils doivent les garder pour des durées définies et ne peuvent en trader qu'un petit pourcentage défini justement pour éviter les mouvements de paniques sur les marchés.
# Super rich, super bullshit
Posté par Firwen (site web personnel) . En réponse au journal La richesse des ultra-riches, à raison de 1000 USD par pixel. Évalué à 0. Dernière modification le 28 août 2022 à 11:52.
Autant que je déteste les inégalités, je trouve ce genre de diagrammes trompeurs. Pour ne pas dire voir clairement de mauvaise foi.
Ni Jeff Bezos ni Bernard Arnaud ni Musk n'ont réellement cette fortune ni même proche de cette fortune.
Ce que beaucoup de personnes ignorent c'est la nature de leur fortune: Ce qu'ils ont c'est des actions, c'est tout (principalement).
On estime leur fortune totale uniquement sur la dernière valeur en bourse de cette action. Si ils essaimaient de "cash back" ces actions en liquide, le cours s'éffondrerait instantanément à cause du volume en jeu. Et la valeur réelle serait nettement moins que la valeur estimée.
Ils n'ont pas cette fortune, ce qu'ils ont c'est de l'argent virtuel sur lequel un marché a collé une valeur spéculative tout aussi virtuelle.
Ceci dit, ça n'excuse en rien les travers avec les super riches:
La plupart ne paient presque pas d’impôts à cause de la nature de leur fortune, des montages qu'ils font avec. Certaines années le FISC américain a même remboursé de l'argent à Bezos. C'est simplement Honteux.
Le fait que leur fortune vient de la valeur des actions font qu'ils ont intérêt à maximiser la valeur de l'action de l'entreprise souvent au détriment de l'entreprise elle même (stocks buy back en Anglais). Et c'est absolument terrible pour les salariés et l'entreprise sur le long terme (coucou GE et Boeing).
Et la liste serait très longue à détailler pour un Dimanche.
[^] # Re: Pas de fumée sans feu
Posté par Firwen (site web personnel) . En réponse au journal De l'influence néfaste de Google sur les développeurs C++. Évalué à 8.
Vous enfoncez certainement tous les deux des portes ouvertes :) :
Le Google C++ style guide est vieux: pre-C++11. Il date d'une époque où la RAII n’était pas répandu et la majorité des code bases n'étaient pas exception safe. Dans ce cadre, oui l'exception ban était justifiée.
Pour information, Google est dit d'avoir une code-base C++ qui s'approche ou dépasse le milliard de ligne de C++, il est presque impossible de changer une règle sur les exceptions du jour au lendemain sur des code bases de cette taille sans grosses conséquences.
De l'aveu du Monsieur C++ Engineering chez Google, la policy serait certainement différente si c'était à refaire aujourd'hui.
Les exceptions (comme mechanisme, en dehors de C++) sont un excellent moyen de faire de l'error report de manière sure et concise sans un code trop verbeux.
En C++, l’implémentation actuelle du mechanisme d'exceptions souffrent de plusieurs problème ( RTTI, nécessite des allocations dynamiques, utilise l’héritage, UB quand appelée dans les destructeurs, nécessite un runtime, vulnerabilite DDOS, type leaking, etc… ) qui fait que même en 2022, certaines codebases ne peuvent pas se permettre de l'utiliser ( safety critical, kernel code, etc ).
[^] # Re: Cas d'usage
Posté par Firwen (site web personnel) . En réponse à la dépêche Compiler Explorer a 10 ans. Évalué à 4.
Je l'utilise régulièrement et ce n'est pas du tout réservé pour des cas extrêmes:
Quelques cas d'utilisation dans le désordre:
Vérifier le support d'une fonctionnalité d'un langage sur plusieurs compilateurs
Prototyper très rapidement une idée et l'envoyer à quelqu'un pour une demo / revue.
tester la portabilité d'un snippet de code sur plusieurs plateformes / OS / compilateur
Vérifier la vectorization / inlining d'un bout de code sur un ensemble de compilateur.
Tester l'impacte en terme de code généré / performance d'un flag de compilateur.
Et beaucoup d'autre.
Il n'y a rien qui ne peut pas être fait sans compiler explorer, mais c'est un trés bon tool qui rend simplement plus productif.
# Quid du debugging ?
Posté par Firwen (site web personnel) . En réponse à la dépêche MirageOS - un micro OS (unikernel) en OCaml. Évalué à 10.
Si je trouve le concept d'Unikernel intéressant sur de la virtualisation pour toute une série de raison:
Il y a un aspect qui m'a toujours bloque d'utiliser ça en production: Le debugging et profiling:
Simple curiosité: Qu'est ce que vous avez pour ça sous MirageOS par exemple ?
Sous Linux, je peux toujours compter sur GDB, perf, strace, l'OOM killer, les coredumps, les logs systems, etc.
Dans le cas d'un unikernel ? est-ce qu'il y a un tooling existant excepté la botte et le couteau ?
[^] # Re: video
Posté par Firwen (site web personnel) . En réponse au journal tesla. Évalué à 8. Dernière modification le 27 décembre 2021 à 17:48.
Votre mauvaise foi n'a pas de limite kilométrique pas contre il semblerait.
Mais si il faut nourrir le troll: je qualifie de freinage d'urgence tout freinage qui n'était pas pleinement anticipé: un piéton qui traverse, la voiture de devant qui freine plus rapidement que prévu, un feu qui passe au rouge à la dernière minute, un ralentissement un peu fort sur autoroute, etc…). Pas le freinage automatique de la voiture en prévention d'accident.
Ce sont uniquement ces situations qui requièrent les freins en BEV, le restant se fait purement en freinage régénératif. La conduite se fait principalement avec une seule pédale.
Excepté si vous conduisez exclusivement votre vieux Diesel en plein Sahara (avec un poil d'aigreur il semblerait), je ne pense pas que vous n'ayez rencontrer ce genre de situation uniquement 3 fois en 230K Km.
[^] # Re: video
Posté par Firwen (site web personnel) . En réponse au journal tesla. Évalué à 7.
Vous n'avez pas conduit beaucoup de VE pour sortir ce genre de conneries de tabloïd.
En VE (BEV), on ne touche quasiment jamais le frein. Le freinage re-generatif fait 95% du travail. A titre d'exemple, sur un trajet de 600km pendant la période de Noel, j'ai du toucher aux freins environ 5 fois ( freinage d'urgence uniquement ).
Les accélérations violentes et le 0-100 en 3s c'est fun 15 minutes devant les copains et pour ceux qui font du circuits. Pour le reste, tes cervicales et ton autonomie vont vite te faire comprendre que le mode "confort" et donc faible acceleration vont t'aider a dormir mieux.
[^] # Re: TLS or not TLS
Posté par Firwen (site web personnel) . En réponse au journal Certificat expiré. Évalué à 10. Dernière modification le 03 octobre 2021 à 16:18.
Soit le proxy est configuré sur du whitelisting-only ET sur un subset de service / addresse Cloud bien définis, nécessaire à l'entreprise et tout le reste est bloqué: c'est défendable.
Soit comme trop souvent, c'est juste là pour faire du Man-in-the-middle et le traffic HTTP/HTTPS est en open bar sur (presque) tout internet. Ça sert uniquement à ouvrir le traffic HTTPS et bloquer tout le reste: Et C'est c'est complètement con
1- Ça crée un bottleneck sur le trafique dans l'entreprise car tout le contenu HTTP/HTTPS sortant passe par là.
2- Ça crée un point de vulnérabilité gigantesque dans l'entreprise car toute personne qui prend le contrôle du proxy peut "ouvrir" le trafique et accéder aux logins / mots de passe de tout le monde, incluant même les second facteurs.
3- Ça rend excessivement chiant l'utilisation de tout logiciel qui utilise du trafique non-HTTP (Vidéo conférence, Messaging, client Email lourd, VPN ) et ça fait souvent buguer une bonne partie des sites web qui utilisent les Web Sockets.
4- C'est un faux argument de sécurité, car je peux te donner 20 manière d'exfiltrer des données en overlay sur du HTTPS et ni ton proxy ni toi n'y verront rien du tout.
5- A l'opposé, la majorité des malwares aujourd'hui n'ont aucun problème à bypasser ça.
Donc oui je réitère ce que j'ai dit: c'est complètement con.
C'est un théâtre de sécurité périmétrique qui réduira la productivité de vos utilisateurs sans fournir la moindre protection contre les attaques modernes ( crypto-lockers, phishing, social-engineering, etc ).
Nous sommes en 2021, la sécurité périmétrique est morte et enterrée. Apprenez à faire avec.
[^] # Re: TLS or not TLS
Posté par Firwen (site web personnel) . En réponse au journal Certificat expiré. Évalué à 5.
Il n'y a aucun cas particulier où ce genre d'aberration peut être justifié.
Soit l'environnement est considéré comme critique (armée, banque) et le poste client n'a rien à faire connecté à internet.
Soit il n' ai pas critique et ce genre de pratique n'a aucune raison d'être.
# TLS or not TLS
Posté par Firwen (site web personnel) . En réponse au journal Certificat expiré. Évalué à 10. Dernière modification le 01 octobre 2021 à 16:36.
"Passerelle de sécurité", la douce oxymore.
Joli mot pour désigné une grosse ignobilie qui ouvre du trafique sécurisé en faisant des attaques man in the middle sur TLS via un proxy et des certificats installés de force sur les machines clientes.
Ce genre de connerie est un trou de sécurité béant, un non-sens complet dans une politique de sécurité en 2021.
Ce sont les managers de tes sysadmins et leur consultants (ceux qui ont mis ça en place) qu'il faudrait brûler.
Cordialement
[^] # Re: Pour ce que ça change...
Posté par Firwen (site web personnel) . En réponse au journal Fini l'obligation de compatibilité IPv6 par la loi. Évalué à 7.
J'ai vraiment du mal avec ce genre d'excuses.
90% des services accessibles de nos jours sont via HTTP et derrière CDN type Cloudflare (ou alternative) ou un cluster de reverse proxy.
Même si vous utilisez IPv4 en interne, ajouter le support IPv6 sur la gate du CDN et éditez les 4 entrées DNS qui vont bien c'est histoire de 20s.
Donc oui c'est souvent de la paresse, de la méconnaissance ou (en entreprise) la fuite de responsabilités. Mais l'argument est rarement technique ni financé.
[^] # Re: Pour ce que ça change...
Posté par Firwen (site web personnel) . En réponse au journal Fini l'obligation de compatibilité IPv6 par la loi. Évalué à 3.
Exactement. Une bonne solution de transition serait de l'IPV6 only coté client avec un NAT64/DNS64 sur la box / passerelle maison pour la transition.
Une des raisons principale pour laquelle ça n'a jamais été fait est que jusqu’à encore récemment, le support IPV6 des smartphones / imprimantes lambda était encore relativement précaire.
[^] # Re: Pour ce que ça change...
Posté par Firwen (site web personnel) . En réponse au journal Fini l'obligation de compatibilité IPv6 par la loi. Évalué à 2.
Tout à fait. Mais les FAIs ne sont pas les seuls dans la balance. Tant que les grands hébergeurs ne seront pas forcé à fournir un adressage V6 sur tout ce qui est publique, les FAIs devront garder leur X niveaux de NATs.
Les hébergeurs ne sont pas les seuls à blâmer d'ailleurs.
L'état de IPV6 dans le monde des "gadgets" IoT et périphériques grands publiques est ridicule alors que ce serait les premiers à en bénéficier.