La législation ne pourra pas faire grand chose contre le cuisant échec de l'ipv6
Bien au contraire, l’échec de l'IPv6 est surtout législatif et absolument pas technique.
Les différents acteurs en place n'ont aucun intérêt économique au changement IPv4 -> IPv6 : Ni les FAIs, ni les grands Cloud providers / hébergeurs. Pour eux c'est une source de coût, pas de bénéfices. Et ce sont déja les propriétaires des quelques tranches IPv4 existantes.
Le seul moyen réel de forcer réellement l'IPV6 est de manière politique en le forçant à la fois sur les FAIs et sur les hébergeurs.
Car au vu du status quo-actuel, on s'oriente à grande vitesse vers du NAT-Naté-dans-du-NAT. Dans un monde merveilleux où posséder une adresse IP sera un privilège de multi-nationale et d'universitaire.
Tu as quand même besoin d'un truc pour dire à ton firewall à un moment donné, "hey, je viens de lancer un client VoIP sur ma machine truc, laisse moi entrer les paquets à destination de tels ports serveur sur cette machine".
Ben non justement, c'est la tout l'intérêt de ce qu'on appelle le "hole punching".
Si tu as deux machines derrières leur firewall respectifs qui veulent se connecter entre elles, elles le peuvent le faire algorithmiquement sans intermédiaire en se connectant en ouvrant des connexions sortantes entre elles.
Chose beaucoup beaucoup plus compliqué à faire en cas de PAT address restricted sans upnp.
Tous ces points à part le dernier (et encore) sont des problèmes liés à l'UPNP qui est lui même lié au fait que le grand public n'est pas capable de configurer un pare feu. Ce n'est pas un problème de NAT.
Pas vraiment.
L'UPNP est le propre du PAT. Principalement du au fait qu'ouvrir une connection Pt2Pt entre deux machines derrière PATs est une sinécure. Faire du hole punching dans une config "ipv6 + pare-feu" est beaucoup plus simple: tu n'as même pas besoin de machine type intermédiaire externe type STUN/TURN et donc pas besoin d'UPNP.
Le NAT est un parasite réseau d'un point de vue L3 et l'UPNP/ PMP a juste été inventé pour le rendre un peu plus gérable.
Dans une architecture fully V6, Tu as besoin d'ouvrir un port réseau uniquement si tu veux exposer un serveur interne.
Dans une architecture à PAT, la moindre connexion P2P, même sans exposition de service est une expérience de magie noire, et l'UPNP est là pour rendre l'expérience un peu meilleur (et parfois pire)
Ça me fait beaucoup penser à du typage structurel, il y a une différence qui m'échappe ?
Ça l'est: Les concepts sont une forme de typage structurel si c'est ta remarque.
On peut voir les concepts comme des assertions sur du typage structurel exécuté à la compilation.
Le typage structurel a toujours existé en C++. Mais avant C++20, il était basé principalement sur des assomptions implicites et les : Il n'était pas déclaré de manière formelle.
Ce qui indirectement était souvent responsable des erreurs de compilation de 45km légendaires en C++
Si on parle du PAT pour les flux sortant, à part de rare attaques sophistiqué et qui nécessite une tonne de condition pour être possible, je ne vois pas de quoi tu parles.
99% des NATs grand publiques sont des PATs à flux sortant restricted cones. Oublions les vrai NATs qui font uniquement de la traduction d'addresse ici.
Un bon nombre de NATs fourni par les routeurs chinois pas chers ont un support UPNP ou PMP qui permet à n'importe quel machine interne d'ouvrir le NAT en mode Open bar. Les gadgets IoT ont d'ailleurs une bonne tendance à abuser de ceci.
Il y a eu des cas par le passé où certains NATs était mal configurés et répondait aux requêtes UPNP sur leur interface publique. Donc n'importe qui pouvait les ouvrir depuis l'extérieur.
Pour des raisons de compatibilités avec certains protocole P2P / hole punching/ STUN, certains PAT ne sont pas "address restricted". Un port ouvert par un flux sortant est accessible par TOUTES les machines externes et non pas uniquement la machine cible. Ce qui est un problème. C'est souvent très peu documenté pour les routeurs grand publique.
Mon point est le suivant: Oui un NAT apporte de la sécurité à un réseau interne. Mais cette "sécurité" est toute relative, mal définie et implémentation spécifique.
Donc non, un NAT n'est pas un pare-feu. Et en dehors d'un usage domestique simpliste, il ne doit jamais être considéré comme tel.
L'existence de méthodes qui, sous certaines conditions, permettent de by-passer une sécurité n'en fait pas un faux sentiment de sécurité. Tu n'utilise pas un cadenas inviolable pour ton vélo.
Un cadena est une cadena. Il a été conçu la sécurité.
Un NAT, spécialement celui d'un routeur chinois acheté pas cher, n'a jamais été conçu la sécurité. Il la fournit par effet de bord, et ça c'est une grosse différence.
La probabilité qu'un de ces services ait une faille? Très proche de 1. Donc oui je suis bien content que le comportement par défaut de ma box soit de bloquer les connexions entrantes.
Un NAT n'est pas un pare-feu. Et en IPv4, ce qui "bloquait" tes connexion entrantes étaient principalement le NAT pas un pare-feu.
Il y a une bonne dizaine de manière d'exploiter un NAT pour le forcer à ouvrir certains port ou d'abuser les ports déja ouvert. Spécialement si tu as du traffic UDP.
Donc ce que tu as perdu, c'était surtout un faux sentiment de sécurité.
Alors professionnellement, je suis biologiste… Le seul noyau qui m’intéresse professionnellement parlant, c’est le noyau cellulaire. ^
Trés belle curiosité. J'ai par le passé travaillé avec des biologistes et des "computational neuroscientistes" et je te garantie que j'aurai payer cher pour en avoir un capable de comprendre 1/100eme de ce que tu sais sur les générateurs de nombres aléatoires.
L'utilisation de mauvais RNGs, ou de bon RNGs mais mal gérés, est une source assez courante d'erreurs dans les résultats scientifiques. Il peut introduire de fausses corrélations qui sont assez délicates à trouver.
Question: Comment est tu arrivé à un tel niveau de connaissance avec autant de détails sur l'implémentation kernel ? Tu l'utilises professionnellement ou simple curiosité et tu as epluché LKML ?
C'est une information réservée à un cercle très très restreins, ta sécurité ne peut être garantie si nous te mettons dans la confidence….
Blague à part….
C'est communément admis dans la communauté HPC que la loi de Moore vit ses derniers beaux jours, ce n'est absolument pas un tabou (excepté pour commerciaux). La plupart des podcasts / interview de Hardware Engineers que tu peux trouver font également consensus sur le sujet.
La principale limitation étant énergétique. Même si la finesse de gravure s'améliore encore, il n'est pas envisageable (techniquement et économiquement) de faire des puces qui dissipent 400-500W en fonctionnement normale. C'est pourtant la voie empruntée actuellement par les puces actuelles par manque de solution technique alternative.
Dans le monde HPC, ça s'illustre principalement avec la métrique principal maintenant qui est devenu non plus le FLOPS-pure mais le FLOPS/Watt.
Car la difficulté n'est pas d'avoir une machine Exascale, mais d'avoir une machine Exascale qui peut tourner sans avoir sa propre tranche de centrale nucléaire pour l'alimenter et une deuxième tranche de centrale nucléaire pour la refroidir.
Oui l'avenir d'Intel semble assez sombre à moyen terme.
Il y a plusieurs raisons derrière le choix d'Apple et d'autres (Amazon, Marvell, Samsung, etc) à créer leur propre processeurs.
- Maturité de l'écosystème ARM
La démocratisation des processeurs ARM sur smartphones et les efforts de fondation comme Linaro (https://www.linaro.org/) ont fait que la software stack compatible ARM a énormément mûri ces dernières années.
Un bon 95% des logiciels Open Source Linux x86_64 (serveur & desktop) peuvent maintenant tourner sur ARM sans problème avec des performances similaires.
- L'émergence de processeur ARM Serveurs / puissants
Ceci sur un marché qui était la chasse gardé d'Intel et d'IBM : le processeur haut de gamme.
- La fin de la loi de Moore et l'émergence des architectures spécialisées
La fin de la loi de moore a fait que le monde du HPC s'est détaché des processeurs haut de gamme (historiquement IBM POWER ou Intel/ADM) pour s'orienter vers des architectures spécialisées. Soit des architectures avec GPU ou des architectures entièrement designé pour le HPC comme pour Fugaku (https://en.wikipedia.org/wiki/Fugaku_(supercomputer) ) avec A64 FX https://en.wikipedia.org/wiki/Fujitsu_A64FX ).
Le TOP 500 illustre bien le phénomène avec le top du classement presque entièrement dominé par les architectures hybride (GPU) ou spécialisées.
- Le degroupage entre designeur et fondeur
Historiquement, les gros designers de processeurs étaient également des fondeurs: Ce n'est plus le cas. Même les grands noms de se monde comme Intel, AMD ou IBM passent maintenant par des sociétés comme TSMC (Taiwan_Semiconductor_Manufacturing_Company) ou Global foundries (https://en.wikipedia.org/wiki/GlobalFoundries) pour réaliser leur chip.
Ce qui a eu comme effet, indirectement, de rendre plus accessible le marché de la création de processeurs avec des sociétés de toute taille qui s'y attaque de front (Huawei, Samsung, Qualcomm, Marvell, Nuvia, Amazon, Apple, Fujitsu) et donc de fortement secouer le monopole d'Intel.
Ceci est constaté avec des Benchs montrant qu'AVX2 a tendance à faire baisser les perfs générales du processeur quand on l'utilise conjointement avec autre chose.
C'est AVX512 à ma connaissance qui réduit la fréquence CPU quand on l'utilise intensivement, et non AVX2 :)
Comme fais-tu pour révoquer une clé dans une voiture non connectée ?
1- Via update des CRLs à chaque révision au garage
2- Toutes les voitures avec un support Bluetooth Smartphone sont indirectement connectées de nos jours, tristement, qu'on le veuille ou non. La mienne peut utiliser le data de mon smartphone pour mettre à jour sa DB audio (titres, jaquettes CD, etc) pour la lecture MP3.
3- Toutes les Tesla (ou Allemande haut de gamme) sont directement connectées pour leur système de géolocalisation.
Honnêtement je n'apprécie pas du tout cette mode d'utiliser son portable comme un terminal sécurisé de confiance.
Ça devient la norme actuellement, même les banques s'y mette. QRCode proprio/Google auth/SMS authentication au minimum.
Je ne fais pas confiance à mon téléphone. Et je ne le ferai probablement jamais. Ce n'est pas moi ni une personne de confiance qui contrôle mon téléphone mais Google ou Apple (+ un constructeur chinois). Et c'est bien la tout le problème.
Je préférerai 100x avoir un système de clé universelle style U2F / yubikey sans fil. Dédié uniquement à cette tâche mais qui le fait bien….
Actuellement on trouve de quoi voler dépanner une Tesla pour 1000 € (et nettement moins si on fait soi-même), ou de quoi voler en multimarque dépanner plusieurs voisins pour 500 € à 2000 € suivant la crédibilité du vendeur.
Ça me rappelle Volkswagen (car ils toujours dans les bons coups), il y a quelques années, qui avait transmis sur des laptop des garagistes la clé privée pour ouvrir la moitié de leurs modèles.
Clé qui avait évidement fuitée et s'était retrouvé sur les boards appropriées en moins d'une semaine.
Ce qui est assez lamentable dans tout ça, c'est que c'est un très bon exemple de négligence et d'incompétence:
1- Il n'y a aucune raison technique de transmettre une clé privée partagée bundlé dans un soft de garagiste à l'heure de la 4G.
2- La révocation des clés est un problème résolu dans l'informatique depuis 20 ans. Le fait que ça ne soit pas le cas dans le domaine automobile en dit déjà long sur les pratiques logiciels de certains constructeurs.
Ce n'est pas bien grave, il ne s'agit que de vols de voitures inutilement chères et polluantes, que leurs propriétaires pourront avantageusement remplacer par des modèles plus sobres et plus sûrs, genre Logan. Quand on achète une grosse bagnoles à 30.000 €, c'est qu'on a trop d'argent de toute façon.
Cette innocence
SUV qui seront remboursés à leur propriétaire à valeur neuve par leur assurance (car option qui va bien).
Ainsi leur ex-propriétaire pourront s'en aller polluer d'avantage le coeur léger dans un nouveau modèle sorti d'usine (plus large si possible).
Par contre tes cotisations d'assurance à toi augmenteront légèrement.
Il n'y a pas de cause à effet entre ce que je dis et le feu de paille.
La méthode Larache ne marche pas à moyen terme, donc tu fais de la merde aussi pour les utilisateurs.
Pas forcement, et c'est là tout le problème. Principalement à cause d'un point que tu mentionnes plus tard, la dette technique.
Tu peux très bien avoir un résultat satisfaisant pour tes utilisateurs, mais qui en pratique est un gros tas de code pas versionné, in-maintenable, qui a besoin de 100x de ressources que nécessaires pour fonctionner.
Ça sera financièrement désastreux, humainement horrible pour ta team mais tu auras tes "résultats". Ton management sera content, il pourront rajouter une petite check "ok" sur leur objectifs "OKr" ou similaire.
C'est tout à fait compatible.
En ingénierie, tout a un coup. Et le "comment" tu arrives à un résultat compte tout autant que le résultat lui même.
Le "comment" ayant également une dimension temporelle.
La dette technique est le prix que tu payes parce que le code est sale, peu lisible, peu clair, verbeux, trompeur, moche…
C'est vrai, mais partiel.
La dette technique ne s'arrête pas uniquement au logiciel et au code.
Une mise en prod rapide et sale mal configuré peut-être une forme de dette technique. Cela rendre la maintenance du service (E.g l'administration de sa database ) plus dur par la suite.
Je résumerai la dette technique pourrait être résumé en "Tout ce qui a été fait à crédit, c'est à dire mis en place de manière non durable, généralement due à des contraintes temporelles, et qui par conséquence devra être payé plus tard (avec les interets, le cout de maintenance) ".
On peut aussi se consacrer au résultat. Le but est de faire un système qui marche pour ses utilisateurs. Cela peut être très gratifiant.
'L’ingénieure logiciel est le développement logiciel intégré sur le temps'… Titus Winter
Une citation on ne peut plus vrai.
Se concentrer sur les résultats oui, se concentrer uniquement sur les résultats en négligeant tout le reste et comment on arrive à ses résultats: non.
C'est le meilleur moyen de créer des logiciels feu-de-paille in-maintenable qui s'écrouleront sous leur complexité aussi rapidement qu'ils sont apparus.
Il y a un juste milieu pour tout en ingénieurie, comme partout.
Je précise que je suis ingénieur soft et je fais surtout du C++, je connais le bas niveau et je comprends ce que tu ressens.
J'ai travaillé avec suffisamment de dev/pseudo-architecte qui ne comprennent absolument pas ce qu'ils font et qui vont pourtant militer avec toute la confiance du monde pour te déployer un kubernetes, un kafka, 5 bases de données et 150 micro-services pour faire tourner un blog.
1 - Ton profile n'est absolument pas en voie d'extinction
Toute structure suffisamment large a besoin de personnes qui comprennent l'infrastructure du top au bottom. Ils sont d'une valeur incommensurable à la boite car ce sont eux qu'on vient chercher en cas de pépin, de gros pépin. Si ta boite ne comprends pas ça, change de boite.
Je peux te donner une 10ene de secteurs et une 20ene de boites que je connais qui recherche des personnes avec ton profile. Hors France. La mienne inclue (on vient de terminer une campagne de recrutement avec 5 dev C++ )
2 - Nous vivons dans un monde où les bons éléments manquent d'assurances et où les imbéciles sont sur de soit
On appelle ça le syndrome de l'imposteur versus le narcissisme.
Tu auras toujours des imbéciles qui militeront dans ta boite avec toute la confiance du monde sur des technos qu'ils ne maîtrisent ni d'Eve ni d'Adam et qui voudront te pusher ça en production sans aucun garde fou.
Il faut apprendre à les gérer ou les raisonner. C'est le seul moyen de faire avec.
La clé pour ça c'est la communication.
Généralement pour le reste, le temps fait son office: les zélotes fanatiques finissent par se bruler trés bien tout seuls. Et finissent soit par se faire virer, soit par se faire promouvoir au placard à balai.
Et puis les jeunes loups de wall street du code ont les dents longues. Leur sport favori ? Cracher leur venin sur ce que l’on appelle communément le « legacy code ». D’ailleurs à partir de quand un code est-il legacy ?
Ce que tu décris là c'est de l'immaturité. Le développeur qui a suffisamment d'expérience comprend le légacy et le respecte. On ne remplace le légacy que si le cout de maintenance dépasse de loin le risque et les ressources pour la ré-écriture.
3- Relativiser
L'IT a besoin de personnes qui "move fast et break things", c'est nécessaire au progrés.
Toute entreprise pérenne a besoin de personne qui connaissent ce que c'est que de maintenir un service en production et le faire évoluer pendant 10 ans.
Les deux sont opposés mais les deux sont indispensables.
Les premiers font évoluer les seconds. Les seconds sont là pour raisonner les premiers.
Manager ça, c'est un boulot autant humain que technique.
4- Trouve toi une occupation en dehors du travail
Si tu es comme moi, et que l'informatique est à la fois une passion et un travail. Tu as très certainement une forte tendance à maximiser ton temps devant l'écran, même en dehors du travail. C'est encore pire en période de confinement.
Le boulot c'est le boulot, le plaisir c'est le plaisir. Je pars du principe que tout ce que je fais après les heures de travail ne touchent pas au travail (même de loin). C'est le seul moyen de ne pas finir en burnout.
Tout le monde est humain.
5- Ne pas se battre contre des moulins à vent
Ne change pas de métier, l'IT a besoin de personnes avec ton profile… qui aime comprendre les choses et pas seulement les utiliser.
Si par contre, c'est ton environnement qui est toxique, avec des personnes haineuses, agressives et méprisantes: Change d'environnement.
6- Conclusion: Ne pas prendre pas sur soit
Je pense pas le moindre du monde que ton profile soit 'en voie d’extinction'.
Que les gens avec ton profile soit une minorité: oui c'est certain.
Qu'ils soient inutile ou en voie d’extinction: non vraiment pas.
Aujourd'hui, on rale contre les jeunes qui hésitent pas à lancer une infra dans un cloud avec 128Go de RAM. Et si c'était pas un peu la même chose?
Il y a rien "d'évolution" là dedans. L’ingénierie est et a toujours été une manière de compromis.
Comment arriver à un but donnée en prenant un minium de resources : Physique, humaine et temporelle.
Si upgrader ta RAM est la solution la plus rapide et moins chère, court et long terme alors oui c'est la solution.
Si diminuer ta consommation de RAM multiplié par tes 200 serveurs et les 5 ans d'exploitation de ton programme justifie tes 2j de boulot, alors oui c'est la bonne chose à faire.
Ah mais faut venir aux Etats-Unis (pour le boulot, uniquement pour le boulot je precise !)
Ou en Suisse
Ou en Scandinavie
Ou en Allemagne
Ou en Irlande
Ou au Canada
Ou au Japon
Ou dans un peut prés tous les pays qui n'ont pas du management à la Française qui constitue à externaliser tout au moindre cout en passant par des boites de presta aux qualités plus que douteuses.
Point 1: même problème à la BNP
C'est partout pareil à mon avis.
Je rajouterai une petite correction à ça : C'est partout pareil en France
J'ai été frontalier Suisse pendant quelques années, donc avec un compte Suisse pour recevoir mon salaire. Je dois dire que les banques Suisse font nettement mieux que leurs consœurs Française en terme de gestion en Ligne et de service client.
Très peu de temps de maintenance / offline.
Meilleur sécurité avec 3FA authentication et code temporaire sans SMS
Ajout de nouveau bénéficiaire pour virement instantanné totalement en-ligne.
Virement sans limite de plafond par défaut.
Historique claire des cartes bancaires
Historiques des transactions sur plusieurs années
Choix précis du type de virement (immédiat, groupé, différé).
Calcul automatique du Budget par type de dépense avec prévision, etc.
Système intégré de facture que tu peux payer via ton interface en ligne.
et d'autres.
Pour le troll gratuit (même si c'est pas Vendredi), je dirai que, comme les banques Suisse, quand tu héberges la moitié de l'argent sale de la planète, tu peux probablement t'offrir un GUI correcte… Mais ça serait trop facile :D
Je me demande ce que nos amis Belges / Luxembourgeois / Canadiens ou expats dans ces pays pensent de leur propre banque : mieux ou moins bien ?
[^] # 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é à 10.
Bien au contraire, l’échec de l'IPv6 est surtout législatif et absolument pas technique.
Les différents acteurs en place n'ont aucun intérêt économique au changement IPv4 -> IPv6 : Ni les FAIs, ni les grands Cloud providers / hébergeurs. Pour eux c'est une source de coût, pas de bénéfices. Et ce sont déja les propriétaires des quelques tranches IPv4 existantes.
Le seul moyen réel de forcer réellement l'IPV6 est de manière politique en le forçant à la fois sur les FAIs et sur les hébergeurs.
Car au vu du status quo-actuel, on s'oriente à grande vitesse vers du NAT-Naté-dans-du-NAT. Dans un monde merveilleux où posséder une adresse IP sera un privilège de multi-nationale et d'universitaire.
[^] # Re: Modèle d’attaque
Posté par Firwen (site web personnel) . En réponse au journal free et ipv6. Évalué à 2.
Ben non justement, c'est la tout l'intérêt de ce qu'on appelle le "hole punching".
Si tu as deux machines derrières leur firewall respectifs qui veulent se connecter entre elles, elles le peuvent le faire algorithmiquement sans intermédiaire en se connectant en ouvrant des connexions sortantes entre elles.
Chose beaucoup beaucoup plus compliqué à faire en cas de PAT address restricted sans upnp.
[^] # Re: Modèle d’attaque
Posté par Firwen (site web personnel) . En réponse au journal free et ipv6. Évalué à 2.
Réponse tardive.
Pas vraiment.
L'UPNP est le propre du PAT. Principalement du au fait qu'ouvrir une connection Pt2Pt entre deux machines derrière PATs est une sinécure. Faire du hole punching dans une config "ipv6 + pare-feu" est beaucoup plus simple: tu n'as même pas besoin de machine type intermédiaire externe type STUN/TURN et donc pas besoin d'UPNP.
Le NAT est un parasite réseau d'un point de vue L3 et l'UPNP/ PMP a juste été inventé pour le rendre un peu plus gérable.
Dans une architecture fully V6, Tu as besoin d'ouvrir un port réseau uniquement si tu veux exposer un serveur interne.
Dans une architecture à PAT, la moindre connexion P2P, même sans exposition de service est une expérience de magie noire, et l'UPNP est là pour rendre l'expérience un peu meilleur (et parfois pire)
[^] # Re: Typage structurel
Posté par Firwen (site web personnel) . En réponse au journal C++ Hell/Heaven et les concepts. Évalué à 2. Dernière modification le 17 septembre 2020 à 15:44.
Ça l'est: Les concepts sont une forme de typage structurel si c'est ta remarque.
On peut voir les concepts comme des assertions sur du typage structurel exécuté à la compilation.
Le typage structurel a toujours existé en C++. Mais avant C++20, il était basé principalement sur des assomptions implicites et les : Il n'était pas déclaré de manière formelle.
Ce qui indirectement était souvent responsable des erreurs de compilation de 45km légendaires en C++
[^] # Re: Modèle d’attaque
Posté par Firwen (site web personnel) . En réponse au journal free et ipv6. Évalué à 6.
99% des NATs grand publiques sont des PATs à flux sortant restricted cones. Oublions les vrai NATs qui font uniquement de la traduction d'addresse ici.
Un bon nombre de NATs fourni par les routeurs chinois pas chers ont un support UPNP ou PMP qui permet à n'importe quel machine interne d'ouvrir le NAT en mode Open bar. Les gadgets IoT ont d'ailleurs une bonne tendance à abuser de ceci.
Il y a eu des cas par le passé où certains NATs était mal configurés et répondait aux requêtes UPNP sur leur interface publique. Donc n'importe qui pouvait les ouvrir depuis l'extérieur.
Pour des raisons de compatibilités avec certains protocole P2P / hole punching/ STUN, certains PAT ne sont pas "address restricted". Un port ouvert par un flux sortant est accessible par TOUTES les machines externes et non pas uniquement la machine cible. Ce qui est un problème. C'est souvent très peu documenté pour les routeurs grand publique.
Mon point est le suivant: Oui un NAT apporte de la sécurité à un réseau interne. Mais cette "sécurité" est toute relative, mal définie et implémentation spécifique.
Donc non, un NAT n'est pas un pare-feu. Et en dehors d'un usage domestique simpliste, il ne doit jamais être considéré comme tel.
[^] # Re: Modèle d’attaque
Posté par Firwen (site web personnel) . En réponse au journal free et ipv6. Évalué à 0.
Un cadena est une cadena. Il a été conçu la sécurité.
Un NAT, spécialement celui d'un routeur chinois acheté pas cher, n'a jamais été conçu la sécurité. Il la fournit par effet de bord, et ça c'est une grosse différence.
[^] # Re: Modèle d’attaque
Posté par Firwen (site web personnel) . En réponse au journal free et ipv6. Évalué à 1.
Un NAT n'est pas un pare-feu. Et en IPv4, ce qui "bloquait" tes connexion entrantes étaient principalement le NAT pas un pare-feu.
Il y a une bonne dizaine de manière d'exploiter un NAT pour le forcer à ouvrir certains port ou d'abuser les ports déja ouvert. Spécialement si tu as du traffic UDP.
Donc ce que tu as perdu, c'était surtout un faux sentiment de sécurité.
[^] # Re: Super
Posté par Firwen (site web personnel) . En réponse au journal Des nombres aléatoires dans le noyau Linux. Évalué à 5.
Trés belle curiosité. J'ai par le passé travaillé avec des biologistes et des "computational neuroscientistes" et je te garantie que j'aurai payer cher pour en avoir un capable de comprendre 1/100eme de ce que tu sais sur les générateurs de nombres aléatoires.
L'utilisation de mauvais RNGs, ou de bon RNGs mais mal gérés, est une source assez courante d'erreurs dans les résultats scientifiques. Il peut introduire de fausses corrélations qui sont assez délicates à trouver.
[^] # Re: Super
Posté par Firwen (site web personnel) . En réponse au journal Des nombres aléatoires dans le noyau Linux. Évalué à 4.
Ce journal est une pépite, Merci !
Question: Comment est tu arrivé à un tel niveau de connaissance avec autant de détails sur l'implémentation kernel ? Tu l'utilises professionnellement ou simple curiosité et tu as epluché LKML ?
[^] # Re: One Task One processor
Posté par Firwen (site web personnel) . En réponse au journal Le début de la fin pour Intel ?. Évalué à 10. Dernière modification le 03 septembre 2020 à 08:55.
C'est une information réservée à un cercle très très restreins, ta sécurité ne peut être garantie si nous te mettons dans la confidence….
Blague à part….
C'est communément admis dans la communauté HPC que la loi de Moore vit ses derniers beaux jours, ce n'est absolument pas un tabou (excepté pour commerciaux). La plupart des podcasts / interview de Hardware Engineers que tu peux trouver font également consensus sur le sujet.
La principale limitation étant énergétique. Même si la finesse de gravure s'améliore encore, il n'est pas envisageable (techniquement et économiquement) de faire des puces qui dissipent 400-500W en fonctionnement normale. C'est pourtant la voie empruntée actuellement par les puces actuelles par manque de solution technique alternative.
Dans le monde HPC, ça s'illustre principalement avec la métrique principal maintenant qui est devenu non plus le FLOPS-pure mais le FLOPS/Watt.
Car la difficulté n'est pas d'avoir une machine Exascale, mais d'avoir une machine Exascale qui peut tourner sans avoir sa propre tranche de centrale nucléaire pour l'alimenter et une deuxième tranche de centrale nucléaire pour la refroidir.
[^] # Re: One Task One processor
Posté par Firwen (site web personnel) . En réponse au journal Le début de la fin pour Intel ?. Évalué à 6.
Oui, et c'est justement une des raisons pour lesquelles ils ont tellement de difficulté à sortir du 7nm.
https://www.tomshardware.com/news/intel-announces-delay-to-7nm-processors-now-one-year-behind-expectations
Ironiquement alors que d'autres comme AMD le font déja via TSMC.
# One Task One processor
Posté par Firwen (site web personnel) . En réponse au journal Le début de la fin pour Intel ?. Évalué à 10.
Très bon article, sur un ressenti assez justifié.
Oui l'avenir d'Intel semble assez sombre à moyen terme.
Il y a plusieurs raisons derrière le choix d'Apple et d'autres (Amazon, Marvell, Samsung, etc) à créer leur propre processeurs.
- Maturité de l'écosystème ARM
La démocratisation des processeurs ARM sur smartphones et les efforts de fondation comme Linaro (https://www.linaro.org/) ont fait que la software stack compatible ARM a énormément mûri ces dernières années.
Un bon 95% des logiciels Open Source Linux x86_64 (serveur & desktop) peuvent maintenant tourner sur ARM sans problème avec des performances similaires.
- L'émergence de processeur ARM Serveurs / puissants
Plusieurs constructeurs ont commencer à faire des processeurs ARM serveurs et ont prouvé que ARM avait sa place sur le marché des processeurs "beefy".
Incluant les séries ThunderX de Marvell (https://www.marvell.com/products/server-processors/thunderx2-arm-processors.html) ou les machines ampère ( https://amperecomputing.com/).
Ce qui a ouvert la porte à plusieurs société spécialisées dans le hardware haut de gamme à faire la même chose comme récemment Amazon (https://www.anandtech.com/show/15578/cloud-clash-amazon-graviton2-arm-against-intel-and-amd), Nuvia (https://nuviainc.com/leadership) ou Apple (https://en.wikipedia.org/wiki/Apple_A13).
Ceci sur un marché qui était la chasse gardé d'Intel et d'IBM : le processeur haut de gamme.
- La fin de la loi de Moore et l'émergence des architectures spécialisées
La fin de la loi de moore a fait que le monde du HPC s'est détaché des processeurs haut de gamme (historiquement IBM POWER ou Intel/ADM) pour s'orienter vers des architectures spécialisées. Soit des architectures avec GPU ou des architectures entièrement designé pour le HPC comme pour Fugaku (https://en.wikipedia.org/wiki/Fugaku_(supercomputer) ) avec A64 FX https://en.wikipedia.org/wiki/Fujitsu_A64FX ).
Le TOP 500 illustre bien le phénomène avec le top du classement presque entièrement dominé par les architectures hybride (GPU) ou spécialisées.
- Le degroupage entre designeur et fondeur
Historiquement, les gros designers de processeurs étaient également des fondeurs: Ce n'est plus le cas. Même les grands noms de se monde comme Intel, AMD ou IBM passent maintenant par des sociétés comme TSMC (Taiwan_Semiconductor_Manufacturing_Company) ou Global foundries (https://en.wikipedia.org/wiki/GlobalFoundries) pour réaliser leur chip.
Ce qui a eu comme effet, indirectement, de rendre plus accessible le marché de la création de processeurs avec des sociétés de toute taille qui s'y attaque de front (Huawei, Samsung, Qualcomm, Marvell, Nuvia, Amazon, Apple, Fujitsu) et donc de fortement secouer le monopole d'Intel.
# Typo ?
Posté par Firwen (site web personnel) . En réponse au journal Le début de la fin pour Intel ?. Évalué à 5.
Sauf erreur de ma part tu as un typo ici :
C'est AVX512 à ma connaissance qui réduit la fréquence CPU quand on l'utilise intensivement, et non AVX2 :)
[^] # Re: C'était mieux à vent
Posté par Firwen (site web personnel) . En réponse au journal Sécurité ouverture/démarrage des nouvelles voitures. Évalué à 5.
Heartbleed a strictement rien à voir avec les CRLs ou OCSP qui sont les deux mécanismes principaux de revocations en X.509.
[^] # Re: C'était mieux à vent
Posté par Firwen (site web personnel) . En réponse au journal Sécurité ouverture/démarrage des nouvelles voitures. Évalué à 3. Dernière modification le 26 août 2020 à 14:52.
1- Via update des CRLs à chaque révision au garage
2- Toutes les voitures avec un support Bluetooth Smartphone sont indirectement connectées de nos jours, tristement, qu'on le veuille ou non. La mienne peut utiliser le data de mon smartphone pour mettre à jour sa DB audio (titres, jaquettes CD, etc) pour la lecture MP3.
3- Toutes les Tesla (ou Allemande haut de gamme) sont directement connectées pour leur système de géolocalisation.
[^] # Re: C'était mieux à vent
Posté par Firwen (site web personnel) . En réponse au journal Sécurité ouverture/démarrage des nouvelles voitures. Évalué à 10.
Très intéressant. Merci pour le lien.
Honnêtement je n'apprécie pas du tout cette mode d'utiliser son portable comme un terminal sécurisé de confiance.
Ça devient la norme actuellement, même les banques s'y mette. QRCode proprio/Google auth/SMS authentication au minimum.
Je ne fais pas confiance à mon téléphone. Et je ne le ferai probablement jamais. Ce n'est pas moi ni une personne de confiance qui contrôle mon téléphone mais Google ou Apple (+ un constructeur chinois). Et c'est bien la tout le problème.
Je préférerai 100x avoir un système de clé universelle style U2F / yubikey sans fil. Dédié uniquement à cette tâche mais qui le fait bien….
[^] # Re: C'était mieux à vent
Posté par Firwen (site web personnel) . En réponse au journal Sécurité ouverture/démarrage des nouvelles voitures. Évalué à 10.
Ça me rappelle Volkswagen (car ils toujours dans les bons coups), il y a quelques années, qui avait transmis sur des laptop des garagistes la clé privée pour ouvrir la moitié de leurs modèles.
Clé qui avait évidement fuitée et s'était retrouvé sur les boards appropriées en moins d'une semaine.
Ce qui est assez lamentable dans tout ça, c'est que c'est un très bon exemple de négligence et d'incompétence:
1- Il n'y a aucune raison technique de transmettre une clé privée partagée bundlé dans un soft de garagiste à l'heure de la 4G.
2- La révocation des clés est un problème résolu dans l'informatique depuis 20 ans. Le fait que ça ne soit pas le cas dans le domaine automobile en dit déjà long sur les pratiques logiciels de certains constructeurs.
[^] # Re: Pas grave
Posté par Firwen (site web personnel) . En réponse au journal Sécurité ouverture/démarrage des nouvelles voitures. Évalué à 10.
Cette innocence
SUV qui seront remboursés à leur propriétaire à valeur neuve par leur assurance (car option qui va bien).
Ainsi leur ex-propriétaire pourront s'en aller polluer d'avantage le coeur léger dans un nouveau modèle sorti d'usine (plus large si possible).
Par contre tes cotisations d'assurance à toi augmenteront légèrement.
C'est pas beau la vie ?
[^] # Re: et si c'était ... l'évolution ?
Posté par Firwen (site web personnel) . En réponse au journal Je fais partie d'une espèce menacée d'extinction. Évalué à 4.
Pas forcement, et c'est là tout le problème. Principalement à cause d'un point que tu mentionnes plus tard, la dette technique.
Tu peux très bien avoir un résultat satisfaisant pour tes utilisateurs, mais qui en pratique est un gros tas de code pas versionné, in-maintenable, qui a besoin de 100x de ressources que nécessaires pour fonctionner.
Ça sera financièrement désastreux, humainement horrible pour ta team mais tu auras tes "résultats". Ton management sera content, il pourront rajouter une petite check "ok" sur leur objectifs "OKr" ou similaire.
C'est tout à fait compatible.
En ingénierie, tout a un coup. Et le "comment" tu arrives à un résultat compte tout autant que le résultat lui même.
Le "comment" ayant également une dimension temporelle.
[^] # Re: Tu n'es en rien en voie d'extinction
Posté par Firwen (site web personnel) . En réponse au journal Je fais partie d'une espèce menacée d'extinction. Évalué à 3.
C'est vrai, mais partiel.
La dette technique ne s'arrête pas uniquement au logiciel et au code.
Une mise en prod rapide et sale mal configuré peut-être une forme de dette technique. Cela rendre la maintenance du service (E.g l'administration de sa database ) plus dur par la suite.
Je résumerai la dette technique pourrait être résumé en "Tout ce qui a été fait à crédit, c'est à dire mis en place de manière non durable, généralement due à des contraintes temporelles, et qui par conséquence devra être payé plus tard (avec les interets, le cout de maintenance) ".
[^] # Re: et si c'était ... l'évolution ?
Posté par Firwen (site web personnel) . En réponse au journal Je fais partie d'une espèce menacée d'extinction. Évalué à 4.
'L’ingénieure logiciel est le développement logiciel intégré sur le temps'… Titus Winter
Une citation on ne peut plus vrai.
Se concentrer sur les résultats oui, se concentrer uniquement sur les résultats en négligeant tout le reste et comment on arrive à ses résultats: non.
C'est le meilleur moyen de créer des logiciels feu-de-paille in-maintenable qui s'écrouleront sous leur complexité aussi rapidement qu'ils sont apparus.
Il y a un juste milieu pour tout en ingénieurie, comme partout.
# Tu n'es en rien en voie d'extinction
Posté par Firwen (site web personnel) . En réponse au journal Je fais partie d'une espèce menacée d'extinction. Évalué à 10. Dernière modification le 21 juillet 2020 à 21:55.
Je précise que je suis ingénieur soft et je fais surtout du C++, je connais le bas niveau et je comprends ce que tu ressens.
J'ai travaillé avec suffisamment de dev/pseudo-architecte qui ne comprennent absolument pas ce qu'ils font et qui vont pourtant militer avec toute la confiance du monde pour te déployer un kubernetes, un kafka, 5 bases de données et 150 micro-services pour faire tourner un blog.
1 - Ton profile n'est absolument pas en voie d'extinction
Toute structure suffisamment large a besoin de personnes qui comprennent l'infrastructure du top au bottom. Ils sont d'une valeur incommensurable à la boite car ce sont eux qu'on vient chercher en cas de pépin, de gros pépin. Si ta boite ne comprends pas ça, change de boite.
Je peux te donner une 10ene de secteurs et une 20ene de boites que je connais qui recherche des personnes avec ton profile. Hors France. La mienne inclue (on vient de terminer une campagne de recrutement avec 5 dev C++ )
2 - Nous vivons dans un monde où les bons éléments manquent d'assurances et où les imbéciles sont sur de soit
On appelle ça le syndrome de l'imposteur versus le narcissisme.
Tu auras toujours des imbéciles qui militeront dans ta boite avec toute la confiance du monde sur des technos qu'ils ne maîtrisent ni d'Eve ni d'Adam et qui voudront te pusher ça en production sans aucun garde fou.
Il faut apprendre à les gérer ou les raisonner. C'est le seul moyen de faire avec.
La clé pour ça c'est la communication.
Généralement pour le reste, le temps fait son office: les zélotes fanatiques finissent par se bruler trés bien tout seuls. Et finissent soit par se faire virer, soit par se faire promouvoir au placard à balai.
Ce que tu décris là c'est de l'immaturité. Le développeur qui a suffisamment d'expérience comprend le légacy et le respecte. On ne remplace le légacy que si le cout de maintenance dépasse de loin le risque et les ressources pour la ré-écriture.
3- Relativiser
L'IT a besoin de personnes qui "move fast et break things", c'est nécessaire au progrés.
Toute entreprise pérenne a besoin de personne qui connaissent ce que c'est que de maintenir un service en production et le faire évoluer pendant 10 ans.
Les deux sont opposés mais les deux sont indispensables.
Les premiers font évoluer les seconds. Les seconds sont là pour raisonner les premiers.
Manager ça, c'est un boulot autant humain que technique.
4- Trouve toi une occupation en dehors du travail
Si tu es comme moi, et que l'informatique est à la fois une passion et un travail. Tu as très certainement une forte tendance à maximiser ton temps devant l'écran, même en dehors du travail. C'est encore pire en période de confinement.
Le boulot c'est le boulot, le plaisir c'est le plaisir. Je pars du principe que tout ce que je fais après les heures de travail ne touchent pas au travail (même de loin). C'est le seul moyen de ne pas finir en burnout.
Tout le monde est humain.
5- Ne pas se battre contre des moulins à vent
Ne change pas de métier, l'IT a besoin de personnes avec ton profile… qui aime comprendre les choses et pas seulement les utiliser.
Si par contre, c'est ton environnement qui est toxique, avec des personnes haineuses, agressives et méprisantes: Change d'environnement.
6- Conclusion: Ne pas prendre pas sur soit
Je pense pas le moindre du monde que ton profile soit 'en voie d’extinction'.
Que les gens avec ton profile soit une minorité: oui c'est certain.
Qu'ils soient inutile ou en voie d’extinction: non vraiment pas.
My 2 cents.
[^] # Re: et si c'était ... l'évolution ?
Posté par Firwen (site web personnel) . En réponse au journal Je fais partie d'une espèce menacée d'extinction. Évalué à 3.
Il y a rien "d'évolution" là dedans. L’ingénierie est et a toujours été une manière de compromis.
Comment arriver à un but donnée en prenant un minium de resources : Physique, humaine et temporelle.
Si upgrader ta RAM est la solution la plus rapide et moins chère, court et long terme alors oui c'est la solution.
Si diminuer ta consommation de RAM multiplié par tes 200 serveurs et les 5 ans d'exploitation de ton programme justifie tes 2j de boulot, alors oui c'est la bonne chose à faire.
C'est pas plus compliqué que ça.
[^] # Re: Been there, done that
Posté par Firwen (site web personnel) . En réponse au journal Je fais partie d'une espèce menacée d'extinction. Évalué à 10.
Ou en Suisse
Ou en Scandinavie
Ou en Allemagne
Ou en Irlande
Ou au Canada
Ou au Japon
Ou dans un peut prés tous les pays qui n'ont pas du management à la Française qui constitue à externaliser tout au moindre cout en passant par des boites de presta aux qualités plus que douteuses.
[^] # Re: la pire banque
Posté par Firwen (site web personnel) . En réponse au journal Dans son barillet, l'écureuil ne met pas des noisettes.. Évalué à 10. Dernière modification le 30 juin 2020 à 19:20.
Je rajouterai une petite correction à ça : C'est partout pareil en France
J'ai été frontalier Suisse pendant quelques années, donc avec un compte Suisse pour recevoir mon salaire. Je dois dire que les banques Suisse font nettement mieux que leurs consœurs Française en terme de gestion en Ligne et de service client.
Très peu de temps de maintenance / offline.
Meilleur sécurité avec 3FA authentication et code temporaire sans SMS
Ajout de nouveau bénéficiaire pour virement instantanné totalement en-ligne.
Virement sans limite de plafond par défaut.
Historique claire des cartes bancaires
Historiques des transactions sur plusieurs années
Choix précis du type de virement (immédiat, groupé, différé).
Calcul automatique du Budget par type de dépense avec prévision, etc.
Système intégré de facture que tu peux payer via ton interface en ligne.
et d'autres.
Pour le troll gratuit (même si c'est pas Vendredi), je dirai que, comme les banques Suisse, quand tu héberges la moitié de l'argent sale de la planète, tu peux probablement t'offrir un GUI correcte… Mais ça serait trop facile :D
Je me demande ce que nos amis Belges / Luxembourgeois / Canadiens ou expats dans ces pays pensent de leur propre banque : mieux ou moins bien ?