windu.2b a écrit 4399 commentaires

Quel est l'intérêt du CPU à ne pas dire qu'il sait gérer le PAE ? Comment trompe-t-on /proc/cpuinfo, dans ce cas ?

Il aurait pu être bronsonisé !

Pas exactement : Français (avec une majuscule) s'il s'agit du gentilé. Mais français (sans majuscule) s'il s'agit de la langue ou de l'adjectif.

Pourquoi ne pas être passé à une autre LTS (16.04), depuis ?

Sa phrase est à double-sens : dit-il que le budget de la défense est le 1er budget ? En ce cas, il a tort, comme l'indique ton lien.
Ou bien dit-il que c'est le plus gros budget défense que la France ait adopté ? En ce cas, il semble qu'il ait raison : depuis 2015 au moins, le budget de la défense n'a cessé d'augmenter. Et la LPM en préparation est aussi sur cette tendance.

Et dans "The Big Bang Theory"

Ça veut dire quoi "bronsoniser" ? Je crois avoir déjà vu ce terme, sur linuxfr.org, mais pas moyen de trouver une définition…

Pas le choix : il faut que tu coupes ton mot en 3 parties, séparées par des espaces, et que tu mettes en gras la partie concernée.
(si tu supprimes les espaces, la mise en gras ne va pas se faire)

mon go db

La majeure partie du noyau fait au contraire usage de barrières charger/enregistrer, plus strictes et bidirectionnelles. Une écriture en mémoire avec la sémantique relâcher ne se finalisera qu’une fois que toutes les opérations préalables de lecture ou d’écriture sont visibles du système, mais permet à d’autres opérations, logiquement faites après l’écriture, d’être réorganisées de façon à advenir avant cette même écriture.

Dans quel cas un tel réordonnancement se justifie-t-il ?

Merci pour ce retour.
Pourrais-tu nous dire quels furent les points bloquants/compliqués de la migration MySQL => Postgres ? À la fois d'un point de vue techniques (types de données, …), mais aussi humain (habitudes, méconnaissance des possibilités offertes par Postgres) ?

Ou même mieux : tu voudrais pas nous faire un journal à ce sujet ?
(j'en demande trop ?)

[MySQL] était dans le lot mais il rentrait clairement en concurrence avec leur ô combien vénérable et ô combien rentable SGBD bien connu… Ils ne pouvaient vraiment pas faire autrement que laisser pourrir MySQL.

Question sérieuse : MySQL est (était) vraiment un concurrent sérieux d'Oracle ? Je pensais que les 2 ne jouaient pas dans les mêmes cours (sans vouloir dire pour autant que MySQL n'est bon que pour les blogs avec 3 articles…).

Merci pour ces remontées, je vais regarder tout ça :-)

Si, sans doute.
Je dois t'avouer que je n'ai pas trop eu envie de lancer ce débat, craignant de voir poindre une discussion sans fin sur "les chaaaaaarges" qui nous étranglent, ou je ne sais quoi.

Si j'en crois l'expérience de mon boucher, personne ne veut reprendre son exploitation (il devrait partir à la retraite dans quelques années).
Ce n'est pas un problème de clientèle (il est bien situé, à peine à l'extérieur du centre-ville de Caen), ce n'est pas un problème de revenus (l'actuel a été plusieurs fois médaillé pour ses saucisses, très bonnes, notamment. Donc, si le repreneur ne fait pas de conneries, il ne devrait pas perdre la clientèle), …
Non, c'est un problème d'horaires : découper la viande, cuisiner les plats (comme souvent chez les bouchers/charcutiers, il fait aussi traiteur), gérer ses stocks et ses commandes, … en plus du temps pour servir les clients, c'est très chronophage (il me parle de 70h/semaine).

Golang consomme 10 fois plus d'électricité que PHP ?!? :-O

Si on veut passer des 5 ou 10% d'acheteur qui achètent en pensant développement durable à 90%, il faut contraindre plus les choses avec des critères plus sévères

Tout à fait. C'est, dans un tout autre registre, ce qui a été fait avec la TIPP (devenue TICPE, depuis) après le choc pétrolier. Elle a été considérablement augmentée !
À l'époque, ça n'était pas pour des raisons écologiques, mais pour limiter la consommation (donc l'importation) de carburants. En l'augmentant, on a dit aux automobilistes "Si j'étais toi, je m'achèterais une voiture qui consomme moins…". Et c'est ce que les automobilistes ont fait, forçant ainsi les constructeurs automobiles à proposer des modèles moins gourmands. Il n'y a qu'à comparer les consommations des voitures en France, avec celles des voitures aux États-Unis, pour s'en rendre compte.

Merci pour ces explications.
Si je comprends bien, la solution (matérielle ou logicielle) pour corriger ça reviendrait à désactiver cette exécution spéculative ? Et c'est la perte de cette optimisation qui coûterait 5% à 30% de plus de temps de traitement ?

Le fait qu'il ciblait tous les processeurs x86_64, dont les AMD, et pas seulement les fautifs, m'y laisse y penser

Ou, par sécurité, le développeur du patch s'est dit qu'il valait mieux viser TOUS les processeurs 64 bits, en attendant d'en savoir plus. Cf. le commentaire dans le patch :

/* Assume for now that ALL x86 CPUs are insecure */
+   setup_force_cpu_bug(X86_BUG_CPU_INSECURE);

Je vois plusieurs commentaires dire que cette faille n'aurait pas été utilisée.
J'aimerais bien qu'on m'explique comment on peut affirmer une telle chose, sachant que la faille serait dans les processeurs Intel depuis 10 ans (la faute aux architectures desdits processeurs, qui ont une partie commune depuis tout ce temps).

Puisqu'on en est à dire ce qu'on a pensé de tel plan/telle scène, je trouve que LA scène qui claque le plus, c'est celle ou la vice-amirale Holdo fonce, à vitesse-lumière, dans le cuirassé du Premier Ordre, le coupant littéralement en deux.

Le silence total (ni voix, ni explosion, ni musique), la lumière rasante sur le cuirassé, l'originalité et l'efficacité de la méthode (kamikaze) employée, … Tout tient en 3-4s. C'est beau !

Une procédure est en cours…

Comme je l'explique dans le journal, je me suis "contenté" d'un traitement durant 1h30 pendant des mois (de mars à cette semaine), parce que, comme tu le soulignes, le gain de temps que j'aurais pu avoir n'aurait pas apporté grand chose, si ce n'est une fierté personnelle.
C'est quand j'ai eu du temps "libre" (pris sur mon temps de travail, toutefois) que je me suis remis à optimiser ce script. Tout compris (donc en incluant le temps mis ce matin pour écrire ce journal), j'estime mon temps passé dessus à 1 journée, max.

là je perds mes petits parce qu'apparemment en interne ça utilise un SAX parser, qui n'est pas donc pas supposer charger le fichier en entier.

Je ne comprends pas ce qui te perturbe : les parsers DOM reposent (tous ?) sur un parser SAX. Ce n'est donc pas le fichier XML qui est chargé complètement en mémoire (SAX étant là pour éviter cela) : c'est sa représentation sous forme d'arbre DOM.

En effet, la suppression d'un grand nombre de COMMIT (à chaque requête SQL), au profit d'un seul COMMIT pour chaque cinéma (avec ses événements et horaires) traité a là encore permis de gagner de précieuses minutes (de 10 minutes, je viens de tomber à moins de 3).

On ne se contente pas d'être une base de données : notre créneau, c'est la promotion du cinéma indépendant.
Critiques de films (on assistes à quasiment toutes les projections presse des films indépendants qui vont sortir en France), interviews de réalisateurs/acteurs, débats filmés lors de projections dans des cinémas Art & Essai, …

Les horaires, c'est le truc qui nous met à égalité, si je puis dire, avec d'autre sites.