Il y a quelques années, j’avais été choqué quand en changeant de mot de passe, mon nouveau mot de passe était refusé car… faisant plus de 8 caractères ! A mes yeux, une telle contrainte ne pouvait signifier qu’une seule chose : un stockage en clair du mot de passe dans une colonne de 8 caractères maximum. A la lecture de cet article, mes soupçons étaient donc bien confirmés.
Au passage, j’avais aussi notifié la CNIL de cet état de fait (cela me semblait tellement incroyable il y a 4 ans…).
Une variante concernant Intermarché en 2020 : l’Impossibilité de saisir des caractères spéciaux
Tu ne comprends manifestement pas la différence qu’il peut y avoir entre une théorie et une information.
Ah on doit pas avoir la même définition de consensus alors.
Je crois que c’est surtout au niveau de la notion de divergence que nous ne sommes pas d’accord. Dire d’une théorie qu’elle diverge du consensus comme tu le fais, c’est signifier que la théorie prend un autre chemin totalement différent.
Ce n’est pas le cas de la théorie d’Einstein que tu prends en exemple. Elle ne diverge pas, elle va plus loin. C’est quand même bien différent.
Pour le reste, bonne continuation. Tu tentes de me faire dire des choses que je n’ai pas dites. Nous avons chacun exprimé notre opinion Je pense que nous sommes d’accord pour dire qu’elles sont incompatibles. Inutile de continuer à tourner en rond dans cette discussion qui devient stérile.
Le
10/09/2022 à
20h
57
eliumnick a dit:
C’est cette nouvelle approche qui justement était une information non vérifiée en 1916. Le concept de lentille gravitationnelle (qui découle directement de la relativité générale) était une information non vérifiée.
Toujours pas. Tu ne sembles pas comprendre la démarche scientifique en jeu ici. Einstein n’a pas dit “c’est ça qui se passe”. Il a dit, voici une explication plausible du phénomène. La notion de lentille gravitationnelle n’était pas une information non vérifiée. Il disait simplement : si ma théorie est juste, alors on devrait avoir des lentilles gravitationnelles.
Il n’a pas dit qu’il y avait des lentilles gravitationnelles. D’ailleurs, les lentilles gravitationnelles n’ont pas validées sa théorie. Car, une fois encore, on ne peut pas valider à coup sur une théorie. On ne peut que l’infirmer ou dire qu’elle n’a pas encore été prise en défaut.
Et c’est exactement ce qui s’est passée avec les théories concurrentes à la relative d’Einstein à l’époque. Il existait d’autres théories “alternatives”, qui ne prédisaient pas l’existence de lentilles gravitationnelles. En observant un phénomène non prévu, ces théories ont été invalidées.
Pour le dire autrement, une prédiction d’une théorie n’est rien d’autre qu’une information non vérifiée tant qu’aucune expérience n’a été réalisé pour tester cette prédiction et/ou cette théorie.
NON ! Car comme dis plus haut, quand on élabore une théorie, on n’affirme pas des choses de manière péremptoire. On donne des moyens de la vérifier, notamment à travers les prédictions qu’elles permettent.
Einstein n’a pas prétendu qu’il y allait y avoir des lentilles gravitationnelles. Il a prétendu que si sa théorie était juste (ou en tout cas, pas trop fausse), alors on observerait des lentilles gravitationnelles. Si elle était fausse, il n’y en aurait pas. Cette “information” ne change pas, qu’il y ait ou non des expériences, et qu’elles réfutent ou non la dite théorie.
Cela en fait un consensus. La théorie d’Einstein, apportant une nouvelle approche, divergeait donc du consensus établi.
Toujours non. Son approche était COMPATIBLE avec les théories existantes. Le consensus d’avant qui était que les équations de Newton étaient incomplètes sont au coeur même de la relativité d’Einstein !
La théorie d’Einstein avait cela de “beau” de permettre de retrouver le comportement des équations de Newton quand on savait que ces équations ne fonctionnaient pas trop mal (faible vitesse, faible masse).
Je pense que ce que tu as écrit n’est pas ce que tu voulais dire.
C’était exactement ce que je voulais dire. Une théorie n’est pas un fait. Sa réfutation ou confirmation oui.
Le
10/09/2022 à
14h
24
eliumnick a dit:
Donc en 1916, publier des travaux d’Einstein sur la relativité générale est constitutif de “publier des informations non vérifiées et divergentes par rapport au consensus”.
Non, car le consensus a l’époque était que la relativité de Newton fonctionnait bien dans beaucoup de cas, mais montrait des limites dans d’autres.
La théorie d’Einstein, était :
compatible avec l’existant (on retombe sur les équations de Newton dans les cas usuels)
comblait via une approche nouvelle les faiblesses des équations de Newton (où aucun consensus n’existait, sauf celui de dire que la théorie de Newton était incomplète).
Ensuite, ne pas oublier qu’une théorie reste… une théorie ! Ce n’est pas un fait en tant que tel. Rare en physique sont les théories dûment prouvées. Même pour les plus solides, il s’agit surtout de théories qui n’ont pas été mise en défaut par l’expérimentation. C’est très différent conceptuellement.
Publier la théorie d’Einstein, en 1916 n’est pas constitutif de publier une information non vérifiée. Dire que la théorie est vraie (ou fausse, peu importe) est un fait. La théorie en elle-même non.
Oh si justement il dit. Chrome par exemple hurle dès qu’on fait ça sur les domaines de Google et quelques autres.
Google a du mettre dans Chrome quelques signatures de clé pour détecter justement ces cas là. Mais il ne peut le faire que sur quelques domaines (notamment les siens).
Pour Firefox j’ai pas regardé.
Firefox va gueuler, car il vient avec son propre magasin de certificat. Il n’utilise pas celui du système. Ou alors il faut que l’antivirus installe aussi explicitement son certificat dans firefox.
Les choses évoluent chaque jour, ce billet évolue chaque jour. C’est une situation très difficile pour l’ensemble de l’équipe.
Je n’en doute pas. C’est aussi une situation délicate pour nous lecteur. Cette année voit le départ de 2 journalistes qui ont joué un rôle majeur dans ce qu’est NextINpact aujourd’hui. Les contenus qui se sont raréfiés ainsi que l’appel à l’aide du mois de juillet jettent un brouillard complet sur le devenir de NXI.
Comme je le disais, un billet, avec un rapide état des lieux rassurerait sans doute une partie du lectorat, à commencer par moi. Car comme tu le dis, “les choses évoluent chaque jour”. Si vous attendez de savoir où aller exactement pour écrire ce billet, alors il est à craindre qu’il ne verra jamais le jour…
Je suis de tout coeur avec l’équipe. Si je pouvais vous aider, je le ferai. Ce commentaire n’est vraiment pas un commentaire à charge, seulement celui d’un lecteur très inquiet…
Je rajouterai juste que des précisions sur la ligne éditoriale aiderait sans doute à éclaircir vos besoins pour le recrutement ;)
Le
07/09/2022 à
12h
39
Teuf a dit:
Merci pour ta réponse
Concernant le fond de dotation, il serait beaucoup trop coûteux de le mettre en place à moyen terme.
Une piste écartée donc.
Nous vous expliquerons tout dans un billet à venir.
Est-ce qu’on peut avoir au moins une idée de quand le billet sera publié ? Je me doute que ce n’est pas facile comme situation, mais le coup du billet à venir, on l’a déjà eu par le passé :/
Je ne me prétends nullement représentant des soutiens de NXI, mais un billet, même incomplet ou qui va évoluer, sur l’état des lieux, sur ce qui est envisagé, encore à l’étude, écarté, … pour faire preuve de transparence me conviendrait parfaitement à titre personnel
Le
07/09/2022 à
12h
26
Je ne veux pas faire mon rabat-joie, surtout que je suis un de vos soutiens indéfectible depuis plusieurs années, mais cet appel à contribution est un peu court.
Depuis le cri d’alerte lancé le 1er juillet, on nous promet de revenir vers nous, avec l’étude des différentes solutions, de la ligne directrice, du contenu, etc… Et là, on a un article, suite au départ de Marc, pour recruter journalistes et pigistes.
Où en sont les réflexions ? Serait-il possible d’avoir un véritable suivi ? Des sujets qui me reviennent en tête :
le fond de dotation. C’est à l’étude, mais on ne sait pas si c’est toujours d’actualité. Où en êtes-vous ?
la hausse des abonnements ?
de la publicité et/ou du community management pour vous faire connaitre et séduire de nouveaux lecteurs ? (je dis bien pub pour vous faire connaitre, pas pub sur le site)
des éclaircissements sur la ligne éditoriale visée ? C’est de plus en plus flou, surtout avec le départ de David en début d’année et celui de Marc aujourd’hui.
Il y avait eu d’autres suggestions, mais c’est tout ce qui me revient à chaud, et j’ai un peu la flemme de parcourir les plus 600 ou 700 commentaires
La spécification de la taille est en effet bien pratique mais, dans les fait, la plus part des programmeurs C et C++ (en embarqué comme sur PC), on fait des alias pour avoir les u8 s8 u16 s16 …. à la place des unsigned char et compagnie. Ce n’est donc pas bloquant en C/C++ A ce titre, j’adore les types rust.
Certes, mais beaucoup utilisent encore les int, long, short sans spécification de taille. C’est là qu’est le danger ;)
Le ramasse miette de JAVA est une horreur incontrôlable qui s’enclenche aux pires moments et rend impossible la maîtrise des temps d’exécution. C’est une mauvaise réponse à un vrai problème. Là dessus, rust apporte une solution qui me parrait correcte et d’autres languages comme le perl s’en tirent bien mieux depuis l’antiquité de l’informatique.
La gestion de la mémoire proposée par java et par rust n’ont absolument rien à voir. Java reste simple. Pour rust, il faut comprendre des notions comme la possession, la durée de vie, etc…
Il n’y a pas spécialement une approche qui est meilleure qu’une autre. Juste deux approches totalement différentes.
Le côté non prédictif du ramasse miette de java, hormis pour des questions de temps réel, n’est pas vraiment un souci.
Vu que de plus en plus de services tournent dans des conteneurs lancés dans des VM, c’est juste inutile.
Absolument pas inutile. C’est une vision très serveur que vous avez, et je devrais même dire très orchestrateur. Il y a encore beaucoup de VPS où toutes les applications ou services sont installées directement, sans cloisement, ou de client lourd sur les postes clients (le côté portable !).
Quand on sait que les exploits par buffer overflow/underflow représentent de 50 à 70% des failles de sécurités, c’est d’un grand intérêt que de s’en prémunir ! Les chiffres varient selon les études. Microsoft avait relevé jusqu’à 70% dans une étude en 2019
Cela passe par l’émulation d’un processeur R3000 (si j’ai bien compris), donc performances de merde assurées. Côté bonheur, j’ai pu avoir à faire avec des softs en java dans le passé et il y avait constamment des problèmes de version. Finalement, c’est un langage interprété qui ne veut pas s’assumer comme tel.
Cela fait bien longtemps que ce n’est plus le cas, et qu’avec les compilateurs JIT voir AOT les performances sont très respectables, d’autant plus pour des programmes comme des services qui sont censés tourner en permanence.
Maintenant , il y a le web assembly qui fait la même chose il me semble mais de manière plus ouverte. Il me semble qu’en C#, il y a aussi une compilation en byte code soit l’équivalent du java compilé.
Oui, C# et webassembly repose exactement sur le même principe.
Le
06/09/2022 à
08h
25
wanou a dit:
Que je suis ému de lire cela!!
Perso, j’y aurait ajouté JAVA pour l’escrcroquerie intellectuelle qu’il représente par rapport au c++
Pour le coup, je ne dirais pas escroquerie, car Java a de réels atouts intellectuellement parlant :
spécification de la taille des types (absente en C++, un int peut être 16, 32 ou 64 bits en fonction de l’architecture)
le ramasse-miette, évitant de nombreuses fuites de mémoire
un langage qui tourne sur une VM, protégeant contre les accès non-autorisé (dépassement de temps, utilisation d’une zone libérée, etc…)
portabilité binaire (compile once, run everywhere). D’un point de vue déploiement, c’est un pur bonheur
Bon, maintenant, je vais me flagéler, car en tant que C-Sharpiste, je viens d’évangéliser java…
Le
02/09/2022 à
08h
32
RemyRaes a dit:
Javascript n’a le monopole ni de l’héritage par prototype, ni du fonctionnement asynchrone ; j’estime que les résultats catastrophiques sont plutôt dus à un manque de formation/connaissances de la part des développeurs.
Je n’ai jamais dis que javascript avait ce monopole :) Je dis juste que beaucoup de dev ont effectivement du mal avec ces notions (j’ai presque envie de dire normal, puisque ce qui est enseigné c’est souvent de la programmation synchrone et de l’héritage polymorphique).
Quand un dev passe du front au back, sans formation adéquat, le résultat est encore pire…
Tiens, un vieux poste que j’avais déjà vu et commenté en plus :) Je n’étais déjà pas d’accord avec son analyse sur le moment. Et je ne le suis toujours pas aujourd’hui. Je mettais déjà en cause l’algorithmie et l’architecture dans les problèmes de performances plus que le problème de langage.
Le
02/09/2022 à
08h
22
(quote:2090872:brice.wernet) Je suis le premier à critiquer, mais je vais tempérer un peu: la consommation RAM n’est pas facile à évaluer réellement (notamment sous Windows et Linux - android il gère pas la RAM en fait) On peut avoir l’impression que la RAM est prise, mais elle est souvent libérée en cas de pression RAM.
Je suis d’accord. Le paradigme de gestion de la RAM a changé, notamment avec les langages à base de ramasse-miettes, où on exploite la mémoire tant qu’il y en a et on la libère si elle est demandée. Mais entre la théorie et la pratique…
Exemple : sur ma machine de dev, il m’arrive de ne pas pouvoir lancer une machine virtuelle, faute de mémoire vive disponible (car oui, la machine virtuelle a le bon gout de ne pas vouloir utiliser le swap pour éviter les problèmes de performance, en tout cas au démarrage !).
Dans ces cas là, je regarde les applications que j’ai d’ouvertes et celles qui consomme le plus. A chaque fois, c’est :
Google Chrome
Visual Studio Code
Visual Studio
Slack
Dans les applications, toutes utilisent le moteur V8 (V8 est issue de Chrome, Visual Studio Code et Slack sont des applications basées sur Electron (donc utilisent V8) et Visual Studio a je ne sais combien de process nodejs en cours d’exécution (donc du V8 également).
Je ferme Slack et Visual Studio Code (souvent ça suffit). Je peux allumer ma machine virtuelle. Je peux ensuite relancer les applications. Et tout fonctionne. Elles consomment souvent moins qu’avant, car la mémoire est plus vite saturée (je tourne à 95% de mémoire utilisée) sans pour autant swaper.
Donc oui, la consommation de RAM n’est pas évidente à évaluer, et la consommation relevée via l’OS n’indique qu’une consommation, pas ce qui est effectivement nécessaire. Dans la pratique, la libération théorique de la RAM n’a pas du tout l’effet escompté, et plomber une machine avec 16Go de RAM avec 4 applications reste, selon moi, problématique.
Le
02/09/2022 à
07h
06
Nicky5 a dit:
Aujourd’hui ça ne choque pas grand monde d’avoir une app de news qui fait 80-100Mo pour une empreinte ram de plusieurs centaines de Mo et autant sur le disque
J’ai Slack d’ouvert. Une fenêtre, 3 zones :
1 menu à gauche
la liste des fils de discussion au milieu
le fil de discussion sélectionné à droite.
Consommation RAM : 300Mo.
Le
02/09/2022 à
07h
01
guithy a dit:
Pourquoi nodejs n’aurait jamais dû exister ? (C’est juste pour savoir)
Pour plein de raisons :
javascript est un langage côté client, et il aurait du le rester (il est mal foutu sous bien des aspects)
multithreading impossible
l’API de nodejs change régulièrement d’une manière non compatible
l’absence d’un framework fourni oblige à passer par une bibliothèque tiers pour quasiment tout (et malgré cela, ils arrivent à avoir une API instable !)
nodejs a transformé des développeurs frontend en développeur backend. Ce n’est absolument pas le même métier et il ne faut pas venir s’étonner si les performances derrières sont pourries (histoire de revenir au sujet de l’article)
comme nodejs ne supporte pas le multithreading, une manière de contourner le problème est de lancer plusieurs processus nodejs. Nodejs étant déjà un peu gourmand en RAM de base, le lancer plusieurs fois ne fait qu’accentuer cette consommation
de nombreux développeurs ont déjà du mal avec la conception logicielle “classique”, alors une programmation basée sur des paradigmes un peu différent (asynchrone, héritage par prototype) donne des résultats souvent catastrophiques.
Le
01/09/2022 à
15h
24
Plusieurs choses pour expliquer cela à mon sens :
l’informatique, et particulièrement le développement logiciel, est devenu une voie de reconversion pour beaucoup. Les bootcamps et autres formations qui promettent en quelques mois de devenir un “expert”
n’importe qui peut se prétendre développeur
les effets de mode (comme, le cloud, le nosql, les architectures microservices) qui font que des techno sont choisies parce qu’elles sont “cool” plutôt sur la considération de véritable contrainte technique
la démocratisation des ORM, qui fait qu’il n’y a plus de réflexion sur les données
les gestionnaires de paquets, qui peuvent induire dépendance sur dépendance de manière assez profonde (et c’est parfois assez marqué pour des langages comme javascript, où avec juste quelques paquets de base, on peut se retrouver avec plus de 1000 paquets installés)
le manque de formation au design logiciel
des trucs qui n’auraient jamais, je dis bien JAMAIS, du exister, comme nodejs (sans même chercher à troller). Tout ça pour avoir un langage unique côté front et côté back.
ce que j’ai pu constater aussi, c’est que le turnover sur certains projets est clairement un élément pénalisant (les dev changeant beaucoup, ne connaissent que superficiellement le projet et son fonctionnement)
le manque de bonnes pratiques comme le TDD, qui facilite grandement le refactoring (du coup, quand on a un code historique, ou legacy, beaucoup évite d’y toucher (à raison !) de peur de casser quelque chose)
Sans même parler d’optimisation, simplement savoir programmer (pas juste être capable d’aligner 2 lignes de code mais bien de connaître le métier) permettrait déjà de résoudre nombres de problèmes.
Car là où je rejoins l’article, c’est qu’avant, les ressources étaient limités (CPU, RAM, disque dur). Il fallait donc faire avec et une personne sachant bidouiller du code se retrouvait vite limitée par son propre manque de connaissance. Aujourd’hui, cette barrière n’existe malheureusement plus…
Pour donner quelques exemples de mon expérience professionnel :
lors d’un stage (je n’étais même pas encore un pro de l’IT à cette époque tout en étant passionné de développement déjà), j’avais développé un code de calcul qui fonctionnait en 5s. Le code de mon prédécesseur nécessitait plus de 2h (je me souviendrais toujours de la tête de ma maître de stage quand je revenais au bout d’une minute avec les nouveaux résultats xD)
des connaissances en SQL me permettent plus ou moins régulièrement d’augmenter d’un facteur très conséquent des requêtes lentes (x10, x100, x1000 tout dépend de la requête et de la taille des données). Parfois, c’est simplement un ajout d’index, ou le respect des formes normales (rien de compliqué en soi) et juste ce qui est considéré comme des “bonnes pratiques”.
savoir quand se passer d’un ORM permet aussi de booster les performances.
quelques techniques de mise en cache simple (une simple variable !) permette d’éviter de réexécuter des calculs coûteux (je me souviens d’une double boucle for imbriquée d’un collègue, qui pouvait atteindre plus de 100000 itérations. Une des données était fixe mais calculée à chaque fois. Le simple fait de la sortir de la boucle, et le calcul a été optimisé d’un facteur x30. Et ça, même pas besoin de benchmark ou autre pour s’en rendre compte, juste de la lecture de code.
Je ne dis pas que le choix du langage n’est pas sans conséquence sur les performances d’un programme. Je pense seulement qu’aujourd’hui, le problème n’est pas tant le langage utilisé, que les compétences de ceux qui développent. Si la personne derrière ne sait pas ce qu’elle fait, elle peut toujours changer de langage, cela ne changera absolument pas le problème de performance…
Dans les faits, peut-être. Je suis sûr qu’il existe la petite backdoor qui va bien dans les produits Microsoft. Par ailleurs, je suis également sûr qu’une petite injonction à la maison mère forcera une petite action d’extraction de données sans que personne ne le sache.
Cela me rappelle cette vidéo avec Linus Torvalds, quand on lui demande s’il a déjà été approché pour installer une porte dérobée
Il manque quand même un élément important de l’avis de passage : l’adresse de destination, incluant notamment l’identité du destinataire !
C’est la base, surtout pour un recommandé avec A/R. C’est dommage de parler d’indices indirects (absence de possibilité de récupérer le recommandé dans un bureau de poste, numéro de suivi obsolète et pour un colissimo) dans l’article mais de ne pas parler de celui là
Tu te contredis en deux paragraphes. Si c’est une compétence (un ‘art’ même, soyons fous), c’est plus rare donc plus cher.
Absolument aucune contradiction. Si tu t’arrêtes au TJM, oui, c’est sûr, un expert coûtera plus cher qu’un débutant.
Si tu regardes sur le coût du projet, tu verras qu’un expert mettra moins de temps et fera un meilleur travail sur du long terme qu’un débutant.
En tant que product owner d’une app non perf critical, j’ai le choix entre 5 devs à 1k€ par jour et 10 devs à 500€ par jour (quitte à ce que les seconds nécessitent les ressources d’un ou deux serveurs supp à 4k€ amortis sur trois ans). Ben sauf a être suicidaire, je prends la seconde option sans la moindre hésitation.
Je suis suicidaire alors. Le TJM ne fait pas tout. Il vaut mieux 5 dev experts qui iront 10x plus vite que tes 10 dev débutants. Tu seras gagnant car :
les fonctionnalités seront développées plus vite (si si)
la maintenance à long terme sera facilité.
J’ai pu le constater à de nombreuses reprises, notamment au niveau des startups, mais pas que. Bien sûr, ce n’est basé que sur mon expérience personnelle et je me targuerais bien d’en faire une généralité. Mais même de grands groupes peuvent rencontrer ce genre de problème. Exemple de témoignage chez Amazon, où une équipe, composée de jeunes recrues a littéralement échouée pendant 3 mois à mettre au point un algorithme de détection de fraude efficace. Un nouvel arrivant analyse le problème, passe quelques heures et pond un algorithme très efficace en moins d’une journée.
Un expert coûte cher, mais un incompétent (dans son sens le plus littéral “ne sachant pas” et sans connotation négative) encore plus. Alors plusieurs…
Le
27/08/2022 à
07h
55
brazomyna a dit:
Certains ici qui pensent que la finalité d’un dev est la ‘beauté du code’ (et se persuadent à peu de frais au passage de “savoir - eux - mieux coder que le reste de la plèbe”).
Non, la finalité d’un dev, c’est d’écrire du code.
Quand on parle d’optimisation dans le langage courant, c’est améliorer les performances. Mais il faut connaitre les sources des problèmes de performances pour comprendre qu’il se cache en réalité, derrière ce concept plus choses.
La première (et la plus grosse), c’est une application mal codée et/ou mal structurée. Là, il ne s’agit pas de faire un “code aux petits oignons”, simplement savoir coder. Tout le monde est capable de poser un parpaing. Faire un mur complet, droit et sans défaut, c’est autre chose. C’est exactement pareil pour le code. Ecrire une ligne de code est à la portée d’un grand nombre de personnes, écrire un code efficace et fonctionnel non.
Et un logiciel bien fait ne coute pas forcément plus cher. C’est même bien souvent le contraire sur le long terme. Mais c’est un art, qui nécessite compétence et expérience.
Le deuxième type d’optimisation, c’est l’optimisation en tant que telle. Pas pour avoir un code “plus performant”, mais bien pour obtenir “les meilleures performances possibles”, car cela représente un réel avantage (par rapport à la concurrence, sur le traitement des données, moteur de jeux vidéos, etc…). Utiliser un algorithme plus performant, utiliser des astuces pour consommer moins de RAM ou de CPU, utiliser des caches, etc… Ca oui, ça coute du temps de dev (et donc de l’argent). Mais contrairement à beaucoup d’idées reçues, ce type d’optimisation est très rarement nécessaire.
Le
26/08/2022 à
08h
39
ForceRouge a dit:
sauf que le premier truc qui saute, c’est l’optimisation, donc on met des machines surdimensionnées alors que ca pourrait tourner sur un raspberry pi, et j’exagère à peine.
Le problème est souvent pire que ça. C’est rarement un problème d’optimisation en tant que tel. C’est très souvent un problème de conception foireuse et d’usage d’outils inappropriés.
Mais c’est pas grave, le matériel ne coûte pas cher… contrairement à un dev (même mauvais, alors ne parlons pas des bons !)
Le
26/08/2022 à
08h
08
ForceRouge a dit:
Quand je vois les requêtes SQL qui arrivent de framework où les développeurs ne manipule que des objets « magique »… y a largement moyen d’optimiser par 10 ou 100 l’efficacité…
Voir bien plus. Mon record perso est à 37000 et des brouettes
Tout à fait, et vue le contexte, cela m’a semblé approprié. Un film d’avant garde sur la surveillance de la population, le sujet qui traite de la surveillance de ceux qui vont aux toilettes… le lien était fait :)
et pourquoi pas une laisse dans le cul c’était plus simple ? biiiip John Spartan, vous avez une amende d’un crédit pour infraction au code de moralité du langage.
Le
26/08/2022 à
07h
41
En attendant… je ne sais toujours pas comment fonctionnent ces foutus coquillages…
Hmm, il faudrait que je vérifie mais il me semble que l’on peut envoyer à @mss.santé.fr mais cela ne sera pas chiffré.
Non non. Le mécanisme de base de la MS-Santé, c’est une liste blanche de domaines autorisés. Quasiment tous les domaines sont des sous-domaines de .mssante.fr, sauf apicrypt (dont la v2 est compatible MSS sans être un sous-domaine de mssante.fr).
En tous cas, avec l’espace de santé, un patient peut recevoir un courriel de son médecin puis engager une discussion par la suite (testé).
Oui, l’espace de santé est fait pour ça (entre autre) :)
Le
25/08/2022 à
08h
14
Soriatane a dit:
Regarde le nombre d’ordonnance ou c’est noté @gmail.com,@hotmail.fr ou @orange.fr C’est rarement mss.sa.te.fr (et dans ce cas ce n’est alors pas utilisé).
En même temps, les adresses MSS (en mssante.fr) ne peuvent pas communiquer avec des adresses e-mails “classiques” (gmail, hotmail, orange, free, nextinpact, etc…). Ce sont des adresses pour les professionnels de santé pour communiquer avec d’autres professionnels de santé. Pas avec les patients.
Pour les patients, on est en attente de la MSS patient, qui se fera sur la base du NIR a priori
Le
24/08/2022 à
11h
41
Mouwawawawa !
J’avoue ne pas comprendre ta réaction…
Le
24/08/2022 à
08h
04
Tu n’as rien contre la pedopornographie ? C’est bien ce qu’il faut lire ?
Bien sur que je suis contre la pédopornographie. Je n’ai rien contre le fait qu’elle soit banni (d’autant plus que c’est illégal dans nombre de pays)
Tout à fait ! Merci !
Le
23/08/2022 à
08h
47
Tu ne comprends pas ce qu’est un “role judiciaire” ou alors tu te trompes de termes.
L’autorité judiciaire fait appliquer la loi en jugeant (afin de trancher les litiges et de déterminer la sanction).
La justice a tranché en faveur des personnes en disant non, ce n’est pas de la pédopornographie.
Google a dit non, j’en ai rien à faire de l’avis de la justice et pour moi c’est de la pédopornographie (jugement). Donc je coupe et point barre (sanction).
Si ce n’est pas s’octroyer un pouvoir judiciaire, je ne sais pas ce que c’est…
Le
23/08/2022 à
08h
19
carbier a dit:
Google dans l’histoire ne joue pas le role du judiciaire: c’est une entité privée qui n’est en RIEN garante de quoi que ce soit et qui a des CGU. Point. Si les CGU de Google ne plaisent pas, tout le monde a le loisir de ne pas utiliser ses services.
Bien sur que si elle a un rôle judiciaire. Elle banni la pédopornographie (je n’ai rien contre).
Elle dit que c’est de la pédopornographie et banni le compte AVANT que la justice n’ait pris une décision (bye bye la présomption d’innocence).
La justice a dit non, ce n’est pas de la pédopornographie, mais Google persiste dans sa décision. Cela va donc au delà du simple respect de CGU.
Le
23/08/2022 à
07h
42
Qu’on demande à une entité de respecter la loi me parait normal (la loi est la loi, même si on n’est pas d’accord).
Qu’une entité endosse d’elle-même le rôle de l’exécutif ET du judiciaire est complètement anormal, qui plus est sans recours possible, y compris pour la justice elle-même !
Il serait temps que les législateurs interviennent pour limiter tout cela, surtout vu les conséquences que cela peut avoir sur la vie des gens.
Tout à fait. L’idée, c’est d’avoir une estimation. Et mon message était pour dire que l’estimation initiale était plus qu’erronée d’un bon facteur 70 au moins.
J’ai fait pareil avec les données de AccuWeather, et entre mai et septembre 2021, je compte 14 jours où la température est au delà des 25 degrés dans cette ville. On est loin des 6 jours de l’article.
Et pour continuer dans votre sens (manque de précision sur les données) mais à contre courant de votre argumentaire, Il faudrait aussi savoir où la température est prise au niveau de AccuWeather. Est-ce en coeur de ville ou à proximité ? Car il fait généralement plus chaud de quelques degrés en ville ;) Et si on regarde sur une carte, le datacenter est plutôt situé en campagne.
Et on peut aussi se dire que lorsque la température a été de 24 ou 25 degrés exactement, Microsoft a pu avoir besoin de refroidir plus efficacement son data center également. Et on trouve 25 jours où la température maximale a été de 24 ou 25 degrés. Ce sont donc potentiellement 39 jours l’année dernière où Microsoft a pu utilisé le water cooling.
De plus, parmi les 84 millions de litre, 9 millions ont été utilisé pour autre chose que le refroidissement, donc diviser 75 par ce nombre aurait plus de sens dans le calcul. Et rien ne nous dit non plus que les 75 millions de litres n’ont servi intégralement que pendant ces jours-là non plus…
Il ne faut pas surinterpréter non plus. Certaines données proviennent de Weather Data, d’autres de Microsoft lui-même. Donc quand Microsoft dit qu’il n’utilise de l’eau que s’il fait plus que 25°, inutile d’aller chercher les températures de 24°.
Pour les 9 millions, qu’importe. Il y a un flou sur son utilisation, puisque d’un côté, ces 9 millions de litres servent à autre chose qu’au refroidissement, mais que de l’autre, Microsoft précise qu’il n’utilise pas d’eau en deça de 25°C. Quoi qu’il en soit, ça va changer le chiffre global de 10%, mais l’ordre de grandeur restera le même malgré tout.
Maintenant, on peut aller plus loin, et rapporter la consommation par rapport à la commune de Hollands-Kroon (commune où est installée le data center), qui était d’un peu moins de 50 000 habitants en 2012 d’après Wikipédia. On arrive quand même à une consommation qui est 2 à 3x supérieure à celle de la commune. C’est donc loin, très loin d’être négligeable.
Le
23/08/2022 à
15h
37
(quote:2089834:33A20158-2813-4F0D-9D4A-FD05E2C42E48) Évidemment que le datacenter concentre la consommation et cela la rend considérable, mais est-ce que la consommation aurait réellement été moindre si tous les clients avaient refroidi leurs serveurs sur leurs propres sites ?
C’est justement le problème. Qu’importe le nombre final de clients, la concentration fait que la consommation d’eau se fait localement au datacenter, tandis que les clients eux peuvent être partout dans le monde…
Je suis français de France. Comme beaucoup de mes congénères, je ne parle ni ne lit le néerlandais
Le
23/08/2022 à
10h
09
84 millions de litres, c’est juste la consommation annuelle d’un peu plus de 2 000 personnes. En moyenne, un européen consomme 100 L par jour, donc cela fait 36 500 L par an pour chacun d’entre nous, soit un peu plus de 2 000 personnes pour arriver à 84 millions. Et on parle d’un data center qui sert à des millions de personnes, voire des dizaines de millions.
Est-ce vraiment si énorme que ça ? Oui, si on réduit l’utilité des data center à faire tourner Office 365 en cloud mais c’est évidemment bien plus que ça. On ne peut pas faire de miracle, tu mets un champ de blé à la place du data center, tu consommeras des dizaines de millions de litre d’eau aussi.
Et puis l’eau n’est pas perdue non plus. Elle n’est surement plus potable à la sortie, mais elle ne disparaît pas, et elle est probablement bien moins polluée à la sortie que dans l’évier de chez pas mal de gens.
Pas vraiment d’accord sur le calcul. Comparer une consommation annuel avec une consommation de 6j, c’est biaisé ! Il faut tout mettre par jour pour pouvoir faire des comparaisons :
Les datacenters de Microsoft ont donc, par jour, consommés autant que 146 000 personnes. On est bien loin des justes 2 000.
Qui plus est, cette consommation supplémentaire n’intervient pas à n’importe quelle moment, elle intervient à des moments où il fait chaud, donc plus enclin à être en période de sécheresse, où on “chasse” le gaspillage.
Mais du coup, cela soulève également une autre question : que se passerait-il s’il y avait pénurie et que priorité était donné aux personnes. On arrête le datacenter ?
Je sais bien tout cela. L’idée s’était de souligner que le dialogue pouvait se faire sans passer par IP. Mais on est d’accord que l’IP reste le moyen le plus répandu (car traverse les différents équipements réseau).
Après, une grosse partie des hacks utilisent des failles dans des fonctionnalités disponibles, et il existe de nombreuses fonctionnalités qui n’utilisent pas IP (le wake on lan déjà cité, ARP, etc…)
Le
23/08/2022 à
06h
40
Il est bien possible de réveiller une machine éteinte par le réseau (wake on lan), donc sans IP.
Infecter un équipement sans IP est donc potentiellement possible, bien que loin d’être trivial…
Par rapport au SPF et au ?all, c’est malheureusement une pratique qui reste courante car l’usage de -all complique beaucoup l’utilisation d’outil d’envoi de mail (pour des notifications, les campagnes de promotion, les newsletter, etc…) dès qu’on passe par un outil en ligne (Mailchimp et compagnie).
Dans un monde idéal, il faudrait modifier le SPF pour ajouter les serveurs qui vont bien. En pratique, c’est le ?all qui est mis, car cela évite de faire des demandes aux services techniques dès qu’un nouvel outil est mis en place…
Non, l’UDP c’est pour avoir une meilleure réactivité, c’est pour ça que des jeux tournent en UDP. Si un paquet est perdu, tu ne veux pas attendre une retransmission de TCP qui va te mettre en retard et te fournir une info périmée. Autant attendre le paquet suivant qui, lui, aura une info à jour.
Histoire de compléter un peu UDP/TCP :
Le TCP est un protocole orienté communication. Il garanti la bonne transmission des données, l’ordre et la non duplication des données. Les données peuvent être de taille arbitraire, le matériel réseau se chargeant alors de redécouper les paquets si nécessaire, de les réordonner correctement, de redemander les paquets non reçus, etc…
L’UDP est un protocole orienté datagramme, c’est-à-dire un envoie de données. En fonction des utilisations, il est généralement conseillé d’avoir des datagrammes suffisamment petits pour éviter de la fragmentation au niveau IP (sinon, un seul paquet manquant signifie que la trame entière est rejetée). Les données sont limitées à un peu plus de 65000 octets (2^16 - taille des entêtes IP et UDP pour être précis). L’UDP ne dispose pas de moyen pour s’assurer qu’un datagramme est bien arrivé à destination, ni même l’ordre d’arrivée des datagrammes.
Le choix TCP/UDP devrait donc se faire en fonction des besoins et des contraintes. En simplifiant beaucoup :
besoin d’une connexion sûre (pas de perte non détectée de paquets) => TCP
besoin de garantir l’ordre d’arriver des informations => TCP
taille des données importantes => TCP
besoin de latence minimum => UDP
Il reste bien sûr possible de se servir d’UDP en tant que base pour fournir un protocole qui offrirait des garanties supplémentaires se rapprochant de TCP sans besoin d’avoir toutes les garanties de TCP.
Par exemple, si on a besoin d’une latence très faible et de garantir un ordre d’arrivé chronologique, on peut définir un protocole basé sur UDP qui ne tiendrait pas compte d’une donnée antérieure à la dernière déjà reçue, comme la valeur d’un capteur ou la position d’un personnage dans un jeu vidéo.
En fait, la cryptographie quantique peut désigner deux choses :
l’utilisation de propriétés quantiques pour la transmission des données (sécurisation du canal)
l’utilisation de propriétés quantiques pour décrypter des données chiffrées par des moyens “classiques”
La sécurisation du canal ne parle pas de cryptographie. Il s’agit de rendre l’interception impossible, via notamment l’intrication quantique. Point qui semble correspondre à votre commentaire. Dans ce cas, si j’ai bien compris aussi (car je ne suis pas spécialiste quantique !) il y a un émetteur qui discute avec un récepteur. Ils sont couplés et on ne peut pas les dissocier pour les appareiller à d’autres. Un avantage de l’utilisation de l’intrication quantique, c’est qu’elle fonctionne à distance “sans support”. Pas besoin de câble, de fibre optique ou ondes radio. L’inconvénient, c’est qu’il faut un émetteur/récepteur par “interlocuteur”. En l’état actuel des choses, autant dire que la sécurisation d’un canal via ce mécanisme ne sera utilisé que dans des cas bien particuliers.
Quand les propriétés quantiques sont utilisées pour décrypter les données, les données sont chiffrés par un moyen traditionnel comme le AES, RSA, etc… Le quantique n’est utilisé que pour “casser” la clé. L’intégrité des données n’est donc pas touchée.
Et des travaux sont en cours pour mettre au point des algorithmes “classiques” (dans le sens, qui s’exécute sur un processeur traditionnel non quantique) qui puissent résister aux attaques quantiques.
En tout cas rien techniquement n’aurait empêché sur ARM ou autre de faire plus malin et standard niveau description du matériel: Tous les outils sont là, ils sont juste mal utilisés faute que le législateur y ait imposé la motivation requise pour la maintenance/suivi logiciel.
Tu as touché le noeud du problème. Pour le cas du PC, le standard IBM/PC s’est imposé comme un standard de fait (c’est pas un réel standard à la base, il s’est juste “imposé” à l’usage).
Maintenant, ARM est un standard qui décrit juste un processeur. Est-ce son rôle de normaliser la description du matériel ? Pas vraiment. En fait, la situation actuelle est juste issu d’un manque de concertation (très certainement favorisé par le fait que la plupart des acteurs qui auraient du/pu se concerter trouvaient de nombreux avantages à ne pas le faire, en commençant par une durée de vie réduite des appareils, et donc un remplacement plus fréquent).
Le
18/08/2022 à
07h
54
Il y a eu pendant des années des smartphones avec des processeurs Intel. Le problème résidait sur le support de la plateforme x86 plus qu’autre chose. Ils étaient aussi autonomes et aussi performants que les processeurs arm de l’époque.
A batterie équivalente ? Cela serait étonnant tant la consommation entre un processeur x86 et ARM est différente. Le choix d’ARM reposait principalement sur deux aspects :
consommation moindre (donc autonomie supérieure)
dégagement de chaleur moindre (mieux adapté au refroidissement passif).
Par contre, ces choix se faisaient souvent au détriment de la puissance de calcul…
Le
18/08/2022 à
07h
18
Ah ben merci pour l’explication, je comprends mieux. Et il n’y a pas moyen de faire en sorte que ce soit automatique ? (ou passer les smartphone sur x86 )
Pour que cela soit automatique, il faudrait définir une “norme” au niveau architecture système qui le permette (ce qu’est le IBM/PC, un “standard de fait”). ARM est une norme architecture processeur.
passer les smartphone sur x86
Le choix de l’ARM c’est un choix vis-à-vis de la consommation énergétique. Pas impossible techniquement, mais très impactant pour l’autonomie !
Le
17/08/2022 à
08h
32
eglyn a dit:
Je ne comprends pas la difficulté des maj sur smartphone… Le parc de PC est bien plus hétérogène au niveau matériel, et pourtant on peut installer la plupart des OS. Il peut arriver qu’un pilote ne soit pas disponible, mais c’est plutôt rare.
Cela vient de l’architecture même des smartphones. Sur un PC, on ne le dit plus depuis des lustres, mais à l’origine, c’est des ordinateurs compatibles IBM/PC. Sur ces architectures, la détection de la configuration matérielle est “automatique” : détermination des bus présents, interrogation pour déterminer les périphériques connectés aux bus, etc…
Sur un smartphone, orienté architecture ARM, cela ne se passe pas du tout ainsi, justement à cause de l’architecture ARM. Grosso modo, il y a un fichier de configuration qui décrit la configuration matériel du smartphone. Du coup, le système d’exploitation n’a pas de possibilité de déterminer automatiquement la configuration. Il faut donc passer cette configuration au moment même de l’installation du système d’exploitation.
C’est pour cela que les ROMs alternatives comme lineage n’ont pas une ROM générique pour les smartphones, mais autant de ROMs par smartphone et déclinaison de smartphone : chaque ROM intègre la configuration matériel spécifique au smartphone ciblé.
Ce n’est pas une question de ne pas voir la censure, c’est une question de ne pas voir de la censure PARTOUT.
C’est une chose de dire qu’il y a tromperie lorsque d’un côté, on affiche 1200000000 résultats, mais qu’on ne peut accéder qu’à 44 pages. Des sujets comme “changement climatique” ou “6 janviers” (assaut du Capitole) sont effectivement touchés. Mais en creusant… c’est TOUS les sujets qui sont touchés (pancake, haricot vert, tartanpion, … bref tout !).
Présenter de manière incomplète des faits en occultant (volontairement ou non) que TOUTES les recherches sont touchées, ça, c’est un raisonnement biaisé.
Je ne rentrerai pas dans le débat des discours (“dissident”, “officiel”, etc…) tant c’est subjectif et trollesque, et surtout inutile dans le contexte du nombre de résultats affichés / effectivement retournés d’un moteur de recherche.
Le
16/08/2022 à
20h
40
On est totalement en phase :)
Le
16/08/2022 à
20h
38
Plusieurs points intéressants dans cette histoire.
D’abord, la plus grande question qui me taraude est : Marc, as-tu systématiquement tapé OCLCTIC et non copié/collé cet illisible nom de Haute Autorité ? 😆
Ensuite, je suis quand même d’accord avec la décision du Conseil Constitutionnel sur le fait que le règlement européen étant plus précis et borné, le risque d’une interprétation trop hasardeuse se voit réduit mais il reste tout de même présent hélas. Le formalisme de la notification est également spécifié en annexe du règlement ce qui permet d’aider à la contestation en cas de problème de forme.
Egalement, j’ai l’impression que ce qui a joué en faveur de cette décision c’est aussi la notion de contre pouvoir et recours qui semblaient absents de la Loi Avia.
Au final il n’y a pas vraiment de surprise, surtout que le Conseil Constitutionnel n’est pas vraiment compétent en matière de recours vu qu’on parle d’un règlement européen.
Clairement, la plus grosse inquiétude est d’étendre le périmètre d’un tel règlement et il ne faut surtout pas que ça devienne n’importe quoi sinon les valeurs de l’UE deviennent caduques. Ce règlement me paraît, à priori, plutôt bien borné et cible un contenu très spécifique et il doit le rester. Là où la Loi Avia était justement le fourre-tout à ne pas faire.
L’article 3 et 15 du règlement en parlent.
Article 3
Ladite autorité compétente transmet l’injonction de retrait au point de contact visé à l’article 15, paragraphe 1, par des moyens électroniques permettant de produire une trace écrite dans des conditions qui permettent d’authentifier l’expéditeur, y compris l’exactitude des dates et heures d’envoi et de réception de l’injonction.
Article 15
Chaque fournisseur de services d’hébergement désigne ou établit un point de contact pour la réception des injonctions de retrait par voie électronique et pour assurer un prompt traitement de ces injonctions, conformément aux articles 3 et 4. Le fournisseur de services d’hébergement veille à ce que les informations relatives au point de contact soient rendues accessibles au public.
En somme c’est similaire aux coordonnées du DPO (et encore, dans le cas de ce dernier, c’est parfois bien planqué).
Le point 19 du constat donne également la spec. De ma compréhension, charge donc à l’autorité compétente de mettre en oeuvre le moyen qui garantira la traçabilité et l’authenticité des injonctions de retrait. Le coup de fil pour prévenir le contact reste possible, mais celui-ci ne serait là que pour dire “Hey Jean Michel Hosting, vous avez une notification à prendre en charge dans le suivi” et non dire “Hey Jean Michel Hosting, il faut virer http:///blabla.. et fissa”.
Oui, ça pue le risque de sous traitance foireuse, comme souvent hélas.
Merci pour les infos. Du coup, c’est une procédure qui doit être propre à chaque hébergeur. Bref, un beau bordel quoi
Le mail ne permettant pas de tracer les date et heure de réception est écarté d’office. Un simple formulaire en ligne est inadapté (impossibilité de certifier l’identité de l’expéditeur).
Bref, à part un système genre gestion de ticket avec validation préalable du compte, je ne vois pas trop ce qu’il est possible de mettre en place… (et du coup, chaque hébergeur va avoir son système…)
2765 commentaires
Pourquoi la CNIL inflige à Infogreffe une amende de 250 000 euros
13/09/2022
Le 13/09/2022 à 13h 05
Ah ben quand même !!
Il y a quelques années, j’avais été choqué quand en changeant de mot de passe, mon nouveau mot de passe était refusé car… faisant plus de 8 caractères ! A mes yeux, une telle contrainte ne pouvait signifier qu’une seule chose : un stockage en clair du mot de passe dans une colonne de 8 caractères maximum. A la lecture de cet article, mes soupçons étaient donc bien confirmés.
Au passage, j’avais aussi notifié la CNIL de cet état de fait (cela me semblait tellement incroyable il y a 4 ans…).
Une variante concernant Intermarché en 2020 : l’Impossibilité de saisir des caractères spéciaux
La Quadrature du Net fête ses 15 ans dans un livre… papier
13/09/2022
Le 13/09/2022 à 11h 59
Seulement sur eMule
La ligne éditoriale de France Soir à l’épreuve des CGU Google
09/09/2022
Le 12/09/2022 à 09h 48
Tu ne comprends manifestement pas la différence qu’il peut y avoir entre une théorie et une information.
Je crois que c’est surtout au niveau de la notion de divergence que nous ne sommes pas d’accord. Dire d’une théorie qu’elle diverge du consensus comme tu le fais, c’est signifier que la théorie prend un autre chemin totalement différent.
Ce n’est pas le cas de la théorie d’Einstein que tu prends en exemple. Elle ne diverge pas, elle va plus loin. C’est quand même bien différent.
Pour le reste, bonne continuation. Tu tentes de me faire dire des choses que je n’ai pas dites. Nous avons chacun exprimé notre opinion Je pense que nous sommes d’accord pour dire qu’elles sont incompatibles. Inutile de continuer à tourner en rond dans cette discussion qui devient stérile.
Le 10/09/2022 à 20h 57
Toujours pas. Tu ne sembles pas comprendre la démarche scientifique en jeu ici. Einstein n’a pas dit “c’est ça qui se passe”. Il a dit, voici une explication plausible du phénomène. La notion de lentille gravitationnelle n’était pas une information non vérifiée. Il disait simplement : si ma théorie est juste, alors on devrait avoir des lentilles gravitationnelles.
Il n’a pas dit qu’il y avait des lentilles gravitationnelles. D’ailleurs, les lentilles gravitationnelles n’ont pas validées sa théorie. Car, une fois encore, on ne peut pas valider à coup sur une théorie. On ne peut que l’infirmer ou dire qu’elle n’a pas encore été prise en défaut.
Et c’est exactement ce qui s’est passée avec les théories concurrentes à la relative d’Einstein à l’époque. Il existait d’autres théories “alternatives”, qui ne prédisaient pas l’existence de lentilles gravitationnelles. En observant un phénomène non prévu, ces théories ont été invalidées.
NON ! Car comme dis plus haut, quand on élabore une théorie, on n’affirme pas des choses de manière péremptoire. On donne des moyens de la vérifier, notamment à travers les prédictions qu’elles permettent.
Einstein n’a pas prétendu qu’il y allait y avoir des lentilles gravitationnelles. Il a prétendu que si sa théorie était juste (ou en tout cas, pas trop fausse), alors on observerait des lentilles gravitationnelles. Si elle était fausse, il n’y en aurait pas. Cette “information” ne change pas, qu’il y ait ou non des expériences, et qu’elles réfutent ou non la dite théorie.
Toujours non. Son approche était COMPATIBLE avec les théories existantes. Le consensus d’avant qui était que les équations de Newton étaient incomplètes sont au coeur même de la relativité d’Einstein !
La théorie d’Einstein avait cela de “beau” de permettre de retrouver le comportement des équations de Newton quand on savait que ces équations ne fonctionnaient pas trop mal (faible vitesse, faible masse).
C’était exactement ce que je voulais dire. Une théorie n’est pas un fait. Sa réfutation ou confirmation oui.
Le 10/09/2022 à 14h 24
Non, car le consensus a l’époque était que la relativité de Newton fonctionnait bien dans beaucoup de cas, mais montrait des limites dans d’autres.
La théorie d’Einstein, était :
Ensuite, ne pas oublier qu’une théorie reste… une théorie ! Ce n’est pas un fait en tant que tel. Rare en physique sont les théories dûment prouvées. Même pour les plus solides, il s’agit surtout de théories qui n’ont pas été mise en défaut par l’expérimentation. C’est très différent conceptuellement.
Publier la théorie d’Einstein, en 1916 n’est pas constitutif de publier une information non vérifiée. Dire que la théorie est vraie (ou fausse, peu importe) est un fait. La théorie en elle-même non.
Pornhub, trouble-fête du blocage des sites pornos voulu par l’Arcom
06/09/2022
Le 08/09/2022 à 09h 11
Google a du mettre dans Chrome quelques signatures de clé pour détecter justement ces cas là. Mais il ne peut le faire que sur quelques domaines (notamment les siens).
Firefox va gueuler, car il vient avec son propre magasin de certificat. Il n’utilise pas celui du système. Ou alors il faut que l’antivirus installe aussi explicitement son certificat dans firefox.
Next INpact recrute des journalistes en CDI et des pigistes
15/09/2022
Le 07/09/2022 à 12h 52
Je n’en doute pas. C’est aussi une situation délicate pour nous lecteur. Cette année voit le départ de 2 journalistes qui ont joué un rôle majeur dans ce qu’est NextINpact aujourd’hui. Les contenus qui se sont raréfiés ainsi que l’appel à l’aide du mois de juillet jettent un brouillard complet sur le devenir de NXI.
Comme je le disais, un billet, avec un rapide état des lieux rassurerait sans doute une partie du lectorat, à commencer par moi. Car comme tu le dis, “les choses évoluent chaque jour”. Si vous attendez de savoir où aller exactement pour écrire ce billet, alors il est à craindre qu’il ne verra jamais le jour…
Je suis de tout coeur avec l’équipe. Si je pouvais vous aider, je le ferai. Ce commentaire n’est vraiment pas un commentaire à charge, seulement celui d’un lecteur très inquiet…
Je rajouterai juste que des précisions sur la ligne éditoriale aiderait sans doute à éclaircir vos besoins pour le recrutement ;)
Le 07/09/2022 à 12h 39
Merci pour ta réponse
Une piste écartée donc.
Est-ce qu’on peut avoir au moins une idée de quand le billet sera publié ? Je me doute que ce n’est pas facile comme situation, mais le coup du billet à venir, on l’a déjà eu par le passé :/
Je ne me prétends nullement représentant des soutiens de NXI, mais un billet, même incomplet ou qui va évoluer, sur l’état des lieux, sur ce qui est envisagé, encore à l’étude, écarté, … pour faire preuve de transparence me conviendrait parfaitement à titre personnel
Le 07/09/2022 à 12h 26
Je ne veux pas faire mon rabat-joie, surtout que je suis un de vos soutiens indéfectible depuis plusieurs années, mais cet appel à contribution est un peu court.
Depuis le cri d’alerte lancé le 1er juillet, on nous promet de revenir vers nous, avec l’étude des différentes solutions, de la ligne directrice, du contenu, etc… Et là, on a un article, suite au départ de Marc, pour recruter journalistes et pigistes.
Où en sont les réflexions ? Serait-il possible d’avoir un véritable suivi ? Des sujets qui me reviennent en tête :
Il y avait eu d’autres suggestions, mais c’est tout ce qui me revient à chaud, et j’ai un peu la flemme de parcourir les plus 600 ou 700 commentaires
Au revoir et merci Next INpact
07/09/2022
Le 07/09/2022 à 10h 38
C’est la CADAstrophe
(désolé, elle était facile celle-là !)
Bonne continuation à toi Marc. Tes articles vont me manquer. Ils font partie de ceux pour lequel j’ai le plus d’intérêt !
Voici l’USB4 version 2.0 jusqu’à 80 Gb/s… et plus si affinité ?
07/09/2022
Le 07/09/2022 à 06h 38
A ce rythme là, la RAM sera bientôt connectable en USB !
Au CNRS, l’importante question de la sobriété énergétique des applications
01/09/2022
Le 06/09/2022 à 18h 34
Certes, mais beaucoup utilisent encore les int, long, short sans spécification de taille. C’est là qu’est le danger ;)
La gestion de la mémoire proposée par java et par rust n’ont absolument rien à voir. Java reste simple. Pour rust, il faut comprendre des notions comme la possession, la durée de vie, etc…
Il n’y a pas spécialement une approche qui est meilleure qu’une autre. Juste deux approches totalement différentes.
Le côté non prédictif du ramasse miette de java, hormis pour des questions de temps réel, n’est pas vraiment un souci.
Absolument pas inutile. C’est une vision très serveur que vous avez, et je devrais même dire très orchestrateur. Il y a encore beaucoup de VPS où toutes les applications ou services sont installées directement, sans cloisement, ou de client lourd sur les postes clients (le côté portable !).
Quand on sait que les exploits par buffer overflow/underflow représentent de 50 à 70% des failles de sécurités, c’est d’un grand intérêt que de s’en prémunir ! Les chiffres varient selon les études. Microsoft avait relevé jusqu’à 70% dans une étude en 2019
Cela fait bien longtemps que ce n’est plus le cas, et qu’avec les compilateurs JIT voir AOT les performances sont très respectables, d’autant plus pour des programmes comme des services qui sont censés tourner en permanence.
Oui, C# et webassembly repose exactement sur le même principe.
Le 06/09/2022 à 08h 25
Pour le coup, je ne dirais pas escroquerie, car Java a de réels atouts intellectuellement parlant :
Bon, maintenant, je vais me flagéler, car en tant que C-Sharpiste, je viens d’évangéliser java…
Le 02/09/2022 à 08h 32
Je n’ai jamais dis que javascript avait ce monopole :) Je dis juste que beaucoup de dev ont effectivement du mal avec ces notions (j’ai presque envie de dire normal, puisque ce qui est enseigné c’est souvent de la programmation synchrone et de l’héritage polymorphique).
Quand un dev passe du front au back, sans formation adéquat, le résultat est encore pire…
Tiens, un vieux poste que j’avais déjà vu et commenté en plus :) Je n’étais déjà pas d’accord avec son analyse sur le moment. Et je ne le suis toujours pas aujourd’hui. Je mettais déjà en cause l’algorithmie et l’architecture dans les problèmes de performances plus que le problème de langage.
Le 02/09/2022 à 08h 22
Je suis d’accord. Le paradigme de gestion de la RAM a changé, notamment avec les langages à base de ramasse-miettes, où on exploite la mémoire tant qu’il y en a et on la libère si elle est demandée. Mais entre la théorie et la pratique…
Exemple : sur ma machine de dev, il m’arrive de ne pas pouvoir lancer une machine virtuelle, faute de mémoire vive disponible (car oui, la machine virtuelle a le bon gout de ne pas vouloir utiliser le swap pour éviter les problèmes de performance, en tout cas au démarrage !).
Dans ces cas là, je regarde les applications que j’ai d’ouvertes et celles qui consomme le plus. A chaque fois, c’est :
Dans les applications, toutes utilisent le moteur V8 (V8 est issue de Chrome, Visual Studio Code et Slack sont des applications basées sur Electron (donc utilisent V8) et Visual Studio a je ne sais combien de process nodejs en cours d’exécution (donc du V8 également).
Je ferme Slack et Visual Studio Code (souvent ça suffit). Je peux allumer ma machine virtuelle. Je peux ensuite relancer les applications. Et tout fonctionne. Elles consomment souvent moins qu’avant, car la mémoire est plus vite saturée (je tourne à 95% de mémoire utilisée) sans pour autant swaper.
Donc oui, la consommation de RAM n’est pas évidente à évaluer, et la consommation relevée via l’OS n’indique qu’une consommation, pas ce qui est effectivement nécessaire. Dans la pratique, la libération théorique de la RAM n’a pas du tout l’effet escompté, et plomber une machine avec 16Go de RAM avec 4 applications reste, selon moi, problématique.
Le 02/09/2022 à 07h 06
J’ai Slack d’ouvert. Une fenêtre, 3 zones :
Consommation RAM : 300Mo.
Le 02/09/2022 à 07h 01
Pour plein de raisons :
Le 01/09/2022 à 15h 24
Plusieurs choses pour expliquer cela à mon sens :
Sans même parler d’optimisation, simplement savoir programmer (pas juste être capable d’aligner 2 lignes de code mais bien de connaître le métier) permettrait déjà de résoudre nombres de problèmes.
Car là où je rejoins l’article, c’est qu’avant, les ressources étaient limités (CPU, RAM, disque dur). Il fallait donc faire avec et une personne sachant bidouiller du code se retrouvait vite limitée par son propre manque de connaissance. Aujourd’hui, cette barrière n’existe malheureusement plus…
Pour donner quelques exemples de mon expérience professionnel :
Je ne dis pas que le choix du langage n’est pas sans conséquence sur les performances d’un programme. Je pense seulement qu’aujourd’hui, le problème n’est pas tant le langage utilisé, que les compétences de ceux qui développent. Si la personne derrière ne sait pas ce qu’elle fait, elle peut toujours changer de langage, cela ne changera absolument pas le problème de performance…
Les « clouds de confiance » Bleu et S3ns seront bien soumis au Cloud Act américain
02/09/2022
Le 02/09/2022 à 09h 07
Cela me rappelle cette vidéo avec Linus Torvalds, quand on lui demande s’il a déjà été approché pour installer une porte dérobée
Présidentielle : 3 000 signalements à la CNIL
01/09/2022
Le 02/09/2022 à 07h 29
Tentative d’arnaque avec un faux avis de passage de La Poste, un code QR et une faille
31/08/2022
Le 01/09/2022 à 08h 27
Il manque quand même un élément important de l’avis de passage : l’adresse de destination, incluant notamment l’identité du destinataire !
C’est la base, surtout pour un recommandé avec A/R. C’est dommage de parler d’indices indirects (absence de possibilité de récupérer le recommandé dans un bureau de poste, numéro de suivi obsolète et pour un colissimo) dans l’article mais de ne pas parler de celui là
OVHcloud : hausse des tarifs « de l’ordre de 10 % », démission du directeur financier
26/08/2022
Le 27/08/2022 à 19h 31
Absolument aucune contradiction. Si tu t’arrêtes au TJM, oui, c’est sûr, un expert coûtera plus cher qu’un débutant.
Si tu regardes sur le coût du projet, tu verras qu’un expert mettra moins de temps et fera un meilleur travail sur du long terme qu’un débutant.
Je suis suicidaire alors. Le TJM ne fait pas tout. Il vaut mieux 5 dev experts qui iront 10x plus vite que tes 10 dev débutants. Tu seras gagnant car :
J’ai pu le constater à de nombreuses reprises, notamment au niveau des startups, mais pas que. Bien sûr, ce n’est basé que sur mon expérience personnelle et je me targuerais bien d’en faire une généralité. Mais même de grands groupes peuvent rencontrer ce genre de problème. Exemple de témoignage chez Amazon, où une équipe, composée de jeunes recrues a littéralement échouée pendant 3 mois à mettre au point un algorithme de détection de fraude efficace. Un nouvel arrivant analyse le problème, passe quelques heures et pond un algorithme très efficace en moins d’une journée.
Un expert coûte cher, mais un incompétent (dans son sens le plus littéral “ne sachant pas” et sans connotation négative) encore plus. Alors plusieurs…
Le 27/08/2022 à 07h 55
Non, la finalité d’un dev, c’est d’écrire du code.
Quand on parle d’optimisation dans le langage courant, c’est améliorer les performances. Mais il faut connaitre les sources des problèmes de performances pour comprendre qu’il se cache en réalité, derrière ce concept plus choses.
La première (et la plus grosse), c’est une application mal codée et/ou mal structurée. Là, il ne s’agit pas de faire un “code aux petits oignons”, simplement savoir coder. Tout le monde est capable de poser un parpaing. Faire un mur complet, droit et sans défaut, c’est autre chose. C’est exactement pareil pour le code. Ecrire une ligne de code est à la portée d’un grand nombre de personnes, écrire un code efficace et fonctionnel non.
Et un logiciel bien fait ne coute pas forcément plus cher. C’est même bien souvent le contraire sur le long terme. Mais c’est un art, qui nécessite compétence et expérience.
Le deuxième type d’optimisation, c’est l’optimisation en tant que telle. Pas pour avoir un code “plus performant”, mais bien pour obtenir “les meilleures performances possibles”, car cela représente un réel avantage (par rapport à la concurrence, sur le traitement des données, moteur de jeux vidéos, etc…). Utiliser un algorithme plus performant, utiliser des astuces pour consommer moins de RAM ou de CPU, utiliser des caches, etc… Ca oui, ça coute du temps de dev (et donc de l’argent). Mais contrairement à beaucoup d’idées reçues, ce type d’optimisation est très rarement nécessaire.
Le 26/08/2022 à 08h 39
Le problème est souvent pire que ça. C’est rarement un problème d’optimisation en tant que tel. C’est très souvent un problème de conception foireuse et d’usage d’outils inappropriés.
Mais c’est pas grave, le matériel ne coûte pas cher… contrairement à un dev (même mauvais, alors ne parlons pas des bons !)
Le 26/08/2022 à 08h 08
Voir bien plus. Mon record perso est à 37000 et des brouettes
Un laissez-passer numérique pour aller aux toilettes, et surveiller pendant combien de temps
26/08/2022
Le 26/08/2022 à 14h 31
Tout à fait, et vue le contexte, cela m’a semblé approprié. Un film d’avant garde sur la surveillance de la population, le sujet qui traite de la surveillance de ceux qui vont aux toilettes… le lien était fait :)
Et bientôt, pour reprendre les propos de John Spartan :
Le 26/08/2022 à 07h 41
En attendant… je ne sais toujours pas comment fonctionnent ces foutus coquillages…
Accusés à tort de pédophilie pour des photos faites à la demande de médecins
23/08/2022
Le 25/08/2022 à 08h 34
Non non. Le mécanisme de base de la MS-Santé, c’est une liste blanche de domaines autorisés. Quasiment tous les domaines sont des sous-domaines de .mssante.fr, sauf apicrypt (dont la v2 est compatible MSS sans être un sous-domaine de mssante.fr).
Oui, l’espace de santé est fait pour ça (entre autre) :)
Le 25/08/2022 à 08h 14
En même temps, les adresses MSS (en mssante.fr) ne peuvent pas communiquer avec des adresses e-mails “classiques” (gmail, hotmail, orange, free, nextinpact, etc…). Ce sont des adresses pour les professionnels de santé pour communiquer avec d’autres professionnels de santé. Pas avec les patients.
Pour les patients, on est en attente de la MSS patient, qui se fera sur la base du NIR a priori
Le 24/08/2022 à 11h 41
J’avoue ne pas comprendre ta réaction…
Le 24/08/2022 à 08h 04
Bien sur que je suis contre la pédopornographie. Je n’ai rien contre le fait qu’elle soit banni (d’autant plus que c’est illégal dans nombre de pays)
Tout à fait ! Merci !
Le 23/08/2022 à 08h 47
L’autorité judiciaire fait appliquer la loi en jugeant (afin de trancher les litiges et de déterminer la sanction).
La justice a tranché en faveur des personnes en disant non, ce n’est pas de la pédopornographie.
Google a dit non, j’en ai rien à faire de l’avis de la justice et pour moi c’est de la pédopornographie (jugement). Donc je coupe et point barre (sanction).
Si ce n’est pas s’octroyer un pouvoir judiciaire, je ne sais pas ce que c’est…
Le 23/08/2022 à 08h 19
Bien sur que si elle a un rôle judiciaire. Elle banni la pédopornographie (je n’ai rien contre).
Elle dit que c’est de la pédopornographie et banni le compte AVANT que la justice n’ait pris une décision (bye bye la présomption d’innocence).
La justice a dit non, ce n’est pas de la pédopornographie, mais Google persiste dans sa décision. Cela va donc au delà du simple respect de CGU.
Le 23/08/2022 à 07h 42
Qu’on demande à une entité de respecter la loi me parait normal (la loi est la loi, même si on n’est pas d’accord).
Qu’une entité endosse d’elle-même le rôle de l’exécutif ET du judiciaire est complètement anormal, qui plus est sans recours possible, y compris pour la justice elle-même !
Il serait temps que les législateurs interviennent pour limiter tout cela, surtout vu les conséquences que cela peut avoir sur la vie des gens.
Au Pays-Bas, les data centers de Microsoft ont consommé 4 à 7 fois plus d’eau potable que prévu
19/08/2022
Le 24/08/2022 à 14h 01
Tout à fait. L’idée, c’est d’avoir une estimation. Et mon message était pour dire que l’estimation initiale était plus qu’erronée d’un bon facteur 70 au moins.
Et pour continuer dans votre sens (manque de précision sur les données) mais à contre courant de votre argumentaire, Il faudrait aussi savoir où la température est prise au niveau de AccuWeather. Est-ce en coeur de ville ou à proximité ? Car il fait généralement plus chaud de quelques degrés en ville ;) Et si on regarde sur une carte, le datacenter est plutôt situé en campagne.
Il ne faut pas surinterpréter non plus. Certaines données proviennent de Weather Data, d’autres de Microsoft lui-même. Donc quand Microsoft dit qu’il n’utilise de l’eau que s’il fait plus que 25°, inutile d’aller chercher les températures de 24°.
Pour les 9 millions, qu’importe. Il y a un flou sur son utilisation, puisque d’un côté, ces 9 millions de litres servent à autre chose qu’au refroidissement, mais que de l’autre, Microsoft précise qu’il n’utilise pas d’eau en deça de 25°C. Quoi qu’il en soit, ça va changer le chiffre global de 10%, mais l’ordre de grandeur restera le même malgré tout.
Maintenant, on peut aller plus loin, et rapporter la consommation par rapport à la commune de Hollands-Kroon (commune où est installée le data center), qui était d’un peu moins de 50 000 habitants en 2012 d’après Wikipédia. On arrive quand même à une consommation qui est 2 à 3x supérieure à celle de la commune. C’est donc loin, très loin d’être négligeable.
Le 23/08/2022 à 15h 37
C’est justement le problème. Qu’importe le nombre final de clients, la concentration fait que la consommation d’eau se fait localement au datacenter, tandis que les clients eux peuvent être partout dans le monde…
Je suis français de France. Comme beaucoup de mes congénères, je ne parle ni ne lit le néerlandais
Le 23/08/2022 à 10h 09
Pas vraiment d’accord sur le calcul. Comparer une consommation annuel avec une consommation de 6j, c’est biaisé ! Il faut tout mettre par jour pour pouvoir faire des comparaisons :
Les datacenters de Microsoft ont donc, par jour, consommés autant que 146 000 personnes. On est bien loin des justes 2 000.
Qui plus est, cette consommation supplémentaire n’intervient pas à n’importe quelle moment, elle intervient à des moments où il fait chaud, donc plus enclin à être en période de sécheresse, où on “chasse” le gaspillage.
Mais du coup, cela soulève également une autre question : que se passerait-il s’il y avait pénurie et que priorité était donné aux personnes. On arrête le datacenter ?
Google Cloud ciblé par la « plus grande » attaque DDoS : 46 millions de requêtes par seconde, certaines via Tor
19/08/2022
Le 23/08/2022 à 09h 00
Je sais bien tout cela. L’idée s’était de souligner que le dialogue pouvait se faire sans passer par IP. Mais on est d’accord que l’IP reste le moyen le plus répandu (car traverse les différents équipements réseau).
Après, une grosse partie des hacks utilisent des failles dans des fonctionnalités disponibles, et il existe de nombreuses fonctionnalités qui n’utilisent pas IP (le wake on lan déjà cité, ARP, etc…)
Le 23/08/2022 à 06h 40
Il est bien possible de réveiller une machine éteinte par le réseau (wake on lan), donc sans IP.
Infecter un équipement sans IP est donc potentiellement possible, bien que loin d’être trivial…
Cybersécurité au CERN : plus de 1 800 personnes sont tombées dans le piège d’un faux email
22/08/2022
Le 23/08/2022 à 06h 48
Par rapport au SPF et au ?all, c’est malheureusement une pratique qui reste courante car l’usage de -all complique beaucoup l’utilisation d’outil d’envoi de mail (pour des notifications, les campagnes de promotion, les newsletter, etc…) dès qu’on passe par un outil en ligne (Mailchimp et compagnie).
Dans un monde idéal, il faudrait modifier le SPF pour ajouter les serveurs qui vont bien. En pratique, c’est le ?all qui est mis, car cela évite de faire des demandes aux services techniques dès qu’un nouvel outil est mis en place…
Gigabyte annonce son SSD AORUS Gen5 10000 : 12 Go/s en lecture, 10 Go/s en écriture
22/08/2022
Le 22/08/2022 à 07h 35
Avec de tels débits, ces disques ont des performances du même ordre de grandeur que de la RAM. Whaoo
Les temps ont bien changé
Internet fixe : tour d’horizon des offres et promotions du moment (dès 9,99 euros par mois)
12/08/2022
Le 19/08/2022 à 12h 57
Histoire de compléter un peu UDP/TCP :
Le TCP est un protocole orienté communication. Il garanti la bonne transmission des données, l’ordre et la non duplication des données. Les données peuvent être de taille arbitraire, le matériel réseau se chargeant alors de redécouper les paquets si nécessaire, de les réordonner correctement, de redemander les paquets non reçus, etc…
L’UDP est un protocole orienté datagramme, c’est-à-dire un envoie de données. En fonction des utilisations, il est généralement conseillé d’avoir des datagrammes suffisamment petits pour éviter de la fragmentation au niveau IP (sinon, un seul paquet manquant signifie que la trame entière est rejetée). Les données sont limitées à un peu plus de 65000 octets (2^16 - taille des entêtes IP et UDP pour être précis). L’UDP ne dispose pas de moyen pour s’assurer qu’un datagramme est bien arrivé à destination, ni même l’ordre d’arrivée des datagrammes.
Le choix TCP/UDP devrait donc se faire en fonction des besoins et des contraintes. En simplifiant beaucoup :
Il reste bien sûr possible de se servir d’UDP en tant que base pour fournir un protocole qui offrirait des garanties supplémentaires se rapprochant de TCP sans besoin d’avoir toutes les garanties de TCP.
Par exemple, si on a besoin d’une latence très faible et de garantir un ordre d’arrivé chronologique, on peut définir un protocole basé sur UDP qui ne tiendrait pas compte d’une donnée antérieure à la dernière déjà reçue, comme la valeur d’un capteur ou la position d’un personnage dans un jeu vidéo.
Inria se demande « ce que le quantique va changer à l’ordre mondial »
18/08/2022
Le 19/08/2022 à 07h 40
En fait, la cryptographie quantique peut désigner deux choses :
La sécurisation du canal ne parle pas de cryptographie. Il s’agit de rendre l’interception impossible, via notamment l’intrication quantique. Point qui semble correspondre à votre commentaire. Dans ce cas, si j’ai bien compris aussi (car je ne suis pas spécialiste quantique !) il y a un émetteur qui discute avec un récepteur. Ils sont couplés et on ne peut pas les dissocier pour les appareiller à d’autres. Un avantage de l’utilisation de l’intrication quantique, c’est qu’elle fonctionne à distance “sans support”. Pas besoin de câble, de fibre optique ou ondes radio. L’inconvénient, c’est qu’il faut un émetteur/récepteur par “interlocuteur”. En l’état actuel des choses, autant dire que la sécurisation d’un canal via ce mécanisme ne sera utilisé que dans des cas bien particuliers.
Quand les propriétés quantiques sont utilisées pour décrypter les données, les données sont chiffrés par un moyen traditionnel comme le AES, RSA, etc… Le quantique n’est utilisé que pour “casser” la clé. L’intégrité des données n’est donc pas touchée.
Et des travaux sont en cours pour mettre au point des algorithmes “classiques” (dans le sens, qui s’exécute sur un processeur traditionnel non quantique) qui puissent résister aux attaques quantiques.
Android 13 disponible en version finale, la fragmentation est toujours importante
16/08/2022
Le 18/08/2022 à 09h 06
Tu as touché le noeud du problème. Pour le cas du PC, le standard IBM/PC s’est imposé comme un standard de fait (c’est pas un réel standard à la base, il s’est juste “imposé” à l’usage).
Maintenant, ARM est un standard qui décrit juste un processeur. Est-ce son rôle de normaliser la description du matériel ? Pas vraiment. En fait, la situation actuelle est juste issu d’un manque de concertation (très certainement favorisé par le fait que la plupart des acteurs qui auraient du/pu se concerter trouvaient de nombreux avantages à ne pas le faire, en commençant par une durée de vie réduite des appareils, et donc un remplacement plus fréquent).
Le 18/08/2022 à 07h 54
A batterie équivalente ? Cela serait étonnant tant la consommation entre un processeur x86 et ARM est différente. Le choix d’ARM reposait principalement sur deux aspects :
Par contre, ces choix se faisaient souvent au détriment de la puissance de calcul…
Le 18/08/2022 à 07h 18
Pour que cela soit automatique, il faudrait définir une “norme” au niveau architecture système qui le permette (ce qu’est le IBM/PC, un “standard de fait”). ARM est une norme architecture processeur.
Le choix de l’ARM c’est un choix vis-à-vis de la consommation énergétique. Pas impossible techniquement, mais très impactant pour l’autonomie !
Le 17/08/2022 à 08h 32
Cela vient de l’architecture même des smartphones. Sur un PC, on ne le dit plus depuis des lustres, mais à l’origine, c’est des ordinateurs compatibles IBM/PC. Sur ces architectures, la détection de la configuration matérielle est “automatique” : détermination des bus présents, interrogation pour déterminer les périphériques connectés aux bus, etc…
Sur un smartphone, orienté architecture ARM, cela ne se passe pas du tout ainsi, justement à cause de l’architecture ARM. Grosso modo, il y a un fichier de configuration qui décrit la configuration matériel du smartphone. Du coup, le système d’exploitation n’a pas de possibilité de déterminer automatiquement la configuration. Il faut donc passer cette configuration au moment même de l’installation du système d’exploitation.
C’est pour cela que les ROMs alternatives comme lineage n’ont pas une ROM générique pour les smartphones, mais autant de ROMs par smartphone et déclinaison de smartphone : chaque ROM intègre la configuration matériel spécifique au smartphone ciblé.
Contenus terroristes : comment le Conseil constitutionnel a validé le retrait en une heure
16/08/2022
Le 18/08/2022 à 07h 43
Ce n’est pas une question de ne pas voir la censure, c’est une question de ne pas voir de la censure PARTOUT.
C’est une chose de dire qu’il y a tromperie lorsque d’un côté, on affiche 1200000000 résultats, mais qu’on ne peut accéder qu’à 44 pages. Des sujets comme “changement climatique” ou “6 janviers” (assaut du Capitole) sont effectivement touchés. Mais en creusant… c’est TOUS les sujets qui sont touchés (pancake, haricot vert, tartanpion, … bref tout !).
Présenter de manière incomplète des faits en occultant (volontairement ou non) que TOUTES les recherches sont touchées, ça, c’est un raisonnement biaisé.
Je ne rentrerai pas dans le débat des discours (“dissident”, “officiel”, etc…) tant c’est subjectif et trollesque, et surtout inutile dans le contexte du nombre de résultats affichés / effectivement retournés d’un moteur de recherche.
Le 16/08/2022 à 20h 40
On est totalement en phase :)
Le 16/08/2022 à 20h 38
Merci pour les infos. Du coup, c’est une procédure qui doit être propre à chaque hébergeur. Bref, un beau bordel quoi
Le mail ne permettant pas de tracer les date et heure de réception est écarté d’office. Un simple formulaire en ligne est inadapté (impossibilité de certifier l’identité de l’expéditeur).
Bref, à part un système genre gestion de ticket avec validation préalable du compte, je ne vois pas trop ce qu’il est possible de mettre en place… (et du coup, chaque hébergeur va avoir son système…)