barmic 🦦 a écrit 6002 commentaires

C'est toi qui a parlé de crétin en premier. Son premier message ne laissait pas paraître autre chose que ne pas vouloir de logiciel en anglais.

Oui il a utilisé un avatar sexiste, mais le fais que ta première réponse soit directement dans une forme de lutte a braqué ton interlocuteur. Là où une réponse moins vindicative et plus pédagogique aurait je présume pas donné ce genre de tension.

On est tous humains et on s'énerve tous ou on est pas au top de la sérénité. Une idée pourrait être de te créer un message prédéfini pour les cas comme ça. Ça ne te demande pas d'effort et ça peut éviter les situations comme ici. Je pense en particulier comme exemple à un vieux meme qui proposait de découper son point Godwin au marteau et au burin sur son écran.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

J'utilise un Athlon X3 (je n'ai pas le modèle en tête). Je viens de la mettre à jour de 2 à 6 Gio ! Je me souviens de la première fois que je l'ai lancé, j'avais l'espoir de pouvoir faire démarrer le 4ème cœur… Mais non ça n'a jamais été possible.

Bref il tourne sur un disque à plateau branché en SATA. Sans carte graphique dédiée.

Installé sur une debian 10 toute neuve. C'est utilisable je trouve. On a évidemment certaine lenteur, mais j'ai vu bien pire. Je ne me souviens pas d'avoir eu particulièrement de problème avec YouTube.

Sur 2 Gio c'était compliqué par contre.

Notre différence de ressenti vient peut-être du parallélisme. Aujourd'hui (et Firefox en tête depuis Quantum) cherche à profiter au mieux du parallélisme offert par tous les processeurs actuels. Les K7 sont la toute première génération AMD de processeurs multicore. L'augmentation du nombre de tâches parallèles sur un nombre réduit de core pose peut-être des problèmes de pression sur l'ordonnanceur ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je suis intéressé pour avoir des pointeurs sur ce genre de choses. Comment on teste unitairement ce code ? Comment le mettre en place dans une intégration continue ?

J'ai vu pgTAP. C'est à ça que tu pensais ? C'est intéressant et ça montre qu'il y a enfin des gens qui s'intéressent à ce sujet. De ce que je vois il execute véritablement ses scripts sur la base. Ça a l'air sincèrement cool.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

L'outillage est peu normalisé, je te l'accorde. Mais ce n'est pas trop compliqué non plus à mettre en oeuvre. Etant proche des données, c'est assez naturel de tester unitairement les différentes phases d'un traitement complexe. Je suis moyennement convaincu par l'argument.

Je suis intéressé pour avoir des pointeurs sur ce genre de choses. Comment on teste unitairement ce code ? Comment le mettre en place dans une intégration continue ?

Le langage PL/pgSQL de PostgreSQL possède une gestion des exceptions ainsi qu'un système de diagnostique (une sorte de stack trace). Il est aussi possible d'utiliser d'autres langages (non spécialisés à la base de données) avec leur avantages et inconvénients.

Ton erreur doit passer du sgbdr à l'applicatif pour être remontée dans l'UI. Avoir déjà une conversion ce n'est pas toujours très bien fais alors en avoir 2…

Ce n'est pas non plus d'une facilité enfantine à traiter côté applicatif.

Ça dépend évidemment de ce que tu fais, mais il est possible d'avoir des services sans état ce qui n'a pas de sens d'un point dans un moteur de base de données. Tu peux trouver un paquet d'architectures pour ce genre de choses. Elles ne cherchent pas à minimiser la place de la base de données, mais donne à chaque élément une responsabilité plus simple et totalement dans son domaine. Tu peux voir l'architecture lambda, la stack SMACK,…

Après oui avec de petits projets (quand les index voir les données elles même tiennent en mémoire) tout marche, mais tu n'a alors aucune contraintes. N'importe quel moteur de données fonctionne et tu peux traiter la donnée où tu veux sans véritable problème.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je ne comprends pas vraiment ton propos. Je ne suis pas là pour dire qui est has been ou pas, à vrai dire, cela ne me concerne pas vraiment.

Désolé si notre conversation t'a agacée, j'ai voulu simplement expliqué ma remarque qui t'a fais réagir.
Je ne vois pas ce qu'il y a d'irritant à échanger sur nos pratiques.

Passe un bon week-end !

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

J'ai pas dis que c'était un bug, mais c'est absolument pas amical avec les utilisateurs. D'autant que je suis persuadé que quelqu'un qui souhaite naviguer dans la version Kotava du site sera capable de naviguer avec la version Kotava du wiki.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Mais c'est pas pour autant forcément ta machine de dev. Et bon 4Gio ça vient de sortir, hein ? Un RPi 3 c'est 1Gio, de quoi affamer Firefox ou Chrome en moins de temps qu'il n'en faut pour le dire. Tout le monde n'y branche pas un écran et un clavier et n'y installent pas leur build tools. D'ailleurs même sur des gros serveurs plus puissant que ma machine de dev, je n'installe pas mes outils de build.

C'est has been comme pratique ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je ne code pas sur le Pi. Coder à travers une connexion ssh ou un dossier partagé ne me plaît pas des masses.
Je ne suis pas sûr que coder en local sur le Pi soit si majoritaire (et c'est clairement pas l'usage classique en embarqué).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Première fois où je suis allé là (tout à l'heure) : https://wiki.documentfoundation.org/Main_Page

J'ai du cliquer sur le changement de langue en haut à droite (à coté du lien de connexion).
→ Ça a changer la langue de la structure MediaWiki (la side bar à gauche par exemple), mais pas celle de la page wiki (j'avais toujours Latest News and Upcoming Events)

J'ai donc cliqué sur le lien FR dans la page de wiki
→ Elle m'a redirigée vers https://wiki.documentfoundation.org/Main_Page/fr et là tout est en français

En réessayant pour te répondre je n'ai pas eu besoin de la première étape (il ne semble pourtant pas y avoir de wiki).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Beaucoup de développeurs ne maîtrisent pas bien les possibilités des bases de données. La plus part (architecte applicatif ou un urbaniste compris) considèrent la base de données comme un data stores, c'est-à-dire un simple entrepôt de données.

Je ne sais pas s'il s'agit d'une pique à mon encontre, mais j'utilise le terme data store parce que je ne parle pas de RDBMS, mais de n'importe quel forme de moteur de stockage du système de fichier à l'IMDG (In Memory Data Grid) et non pour le limiter à du stockage de données.

C'est essentiellement la non connaissance des bases de données des développeurs qui pousse à choisir une solution technique côté applicatif. Je ne vois pas d'autres arguments forts à ne pas choisir de faire les traitements de données au plus proche de la base de données. Je suis preneur de tout contre-argument.

Le manque de connaissance est un argument en soit important. Faire des traitements du coté de ton moteur de stockage peut engendrer des effets de bord des fois très subtiles. Par exemple quand tu exécute une fonction dans redis, il faut qu'elle soit pure, car il ne réplique pas les données résultantes, mais exécute la fonction sur chaque nœud. La gestion des transactions peut être un peu différentes.

Mais ce qui me gêne le plus c'est :

• la difficulté de tester : on trouve de plus en plus l'usage du js ce qui aide un peu, mais ça ne fait pas tout. Écrire des tests unitaires sur ce code est bien plus compliqué que dans ton code applicatif ;
• la gestion des erreurs est plus complexe : à minima tu as une étape de mapping en plus de tes erreurs ce qui augmente encore le risque que ça soit mal fait. Encore une fois c'est complexe à tester. Tu ne peux pas forcément tester ce mapping facilement.

D'un point de vu d'administrateur système, tu as aussi d'autres arguments :

• les machines de calcul et les machines de stockage n'ont pas forcément le même profile et tu prévois pas forcément d'être CPU intenssive sur tes machines de base de données. C'est un problème qui est pris en compte par certains comme couchdb qui a des nœuds spécifiques pour le traitement ;
• tu peut vouloir être élastique (→ ajouter/supprimer des instances en fonction de la charge) sur ton applicatif et tu l'es rarement sur tes bases de données.

Je ne dis pas qu'il ne faut pas faire de traitement coté données, mais qu'il y a des contre arguments.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

La cross compilation go sur ma machine est plus rapide que le lancement du runtime (+JIT) python sur RPi. C'est choquant ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ils auraient pas eu besoin du 49.3 aussi souvent si y'avait pas eu autant de gaminerie dans leur propre camp. Les fameux "frondeurs" sont responsables de la ruine du PS (je sais, le PS n'est pas ruiné… n'empeche que c'est quasiment plus rien dans le paysage politique).

Qu'est-ce qui te permet de dire que c'est ça et pas quelque chose comme : « C'est d'avoir dévié des valeurs du parti qui les a poussé à utiliser le 49.3 pour mettre des coup de pression à leur propre parti. Ces chocs ont étaient tellement violent que le PS a perdu beaucoup de son aura dans le paysage politique. » Par exemple ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Après c'est vrai j'avoue que pour des captures en première pages ça fait tache quand c'est pas dans notre langue, mais faut quand même pas oublier que la version 4.14 vient de sortir et ils vont peut-être le faire après coup (ils ont mis 4 ans à faire cette version).

Je ne critique pas le projet mais ton argumentation ;)

il y a qu'à voir les "notes de version" de LibreOffice ou toutes les captures sont en anglais avec le descriptif dans la bonne langue et personne dit rien

Je ne suis pas sûr qu'un projet dont la page d'accueil non content de ne pas avoir réussi à détecter ma langue demande à passer d'abord l'interface MediaWiki en français en haut à droite puis la page d'accueil elle-même dans la barre au milieu, soit une référence en terme d'accueil des utilisateurs dans différentes langues…

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Python a une latence au démarrage que je trouve perceptible (j'aime pas attendre !).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu as des sauts/conditions en moins la CPU et le compilateur peuvent utiliser efficacement le pipeline ou faire du SIMD effectivement.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'est très contraignant le C dans ce contexte je trouve. Le fait d'avoir à manier des toolchaines complexe pour pouvoir démarrer ou à devoir faire son build sur la board elle-même ce qui (demande à installer des choses inutiles pour le run et c'est bien plus lent et il faut pousser les sources sur la board…).

Pour moi le bon compromis, c'est le go. La cross compilation est triviale, tu as des bibliothèques qui font le job et la différence de performance avec le C a toujours était négligeable pour mes usages. Cerises sur le gâteau : le langage est sympathique (je trouve) et le build est très rapide.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

L'ouvrage est orienté vers le développeur, avec le parti pris assumé de (dé)montrer qu'il aurait tout intérêt à laisser PostgreSQL effectuer le maximum de travail pour lui, en utilisant au mieux SQL et les fonctionnalités du SGBD.

C'est un peu plus compliqué que ça je trouve. Il est généralement difficile de tester unitairement une procédure stockée par exemple, l'utilisation des triggers doit être limité à des cas proches de la donnée,… et probablement d'autres choses. À mon humble al faut s'appuyer sur le data store quand :

• c'est naturel :
  • on évite des aller-retour
  • c'est déjà le moteur qui connait l'information pertinent
  • c'est complexe de garantir la cohérence
• on a un gros volume de données
  • il vaut mieux déplacer le traitement vers les données que les données vers le traitement

Mais dans le cas général il vaut mieux faire des choses simples dans les data stores : avoir un système complexe qui échange avec un second système complexe ça devient un enfer à tester.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je ne comprends pas l'explication :

La définition légale exclut l'intention homicide, mais les violences demeurent volontaires, et ce crime, loin d'être une exception, démontre le principe : entre celui qui frappe à la tête pour assommer et tue, et celui qui frappe à la tête et tue, la seule différence est l'intention, et elle fait toute la différence.

On considère bien la mort de la victime comme quelque chose d'aggravant. C'est d'ailleurs ce qui fait passer de délit à crime donc on juge bien l'accusé sur les conséquences (on accuse de meurtre et pas d'agression) de ses actes même si l'on sait que les conséquences ne sont pas volontaires (c'est un meurtre et pas un assassinat).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

En plus, l'anglais est quasiment de faite la langue international.

Pourquoi se tuer à traduire logiciels et site du coup ? Je veux dire soit on reconnait l'intérêt et ça vaut le coup de le mettre en avant. Ne serais-ce que par égard aux contributeurs sur le sujet. Soit on dit qu'on s'en fout et autant ne pas gâcher de l'effort là dessus, il y a pleins d'autres choses à faire.

Imagine toutes les captures qu'ils devraient faire et la place que ça prendrait juste pour quelques mots qui son en plus déjà traduit dans l'explication.

La page d'accueil c'est 5 captures de 72Kio. Pour les 33 langues, ça fait monter le stockage du tout à 11Mio. Bien trop pour leur CDN, donc ils pourraient ne le faire que pour la première histoire d’accueillir plus amicalement le badaud.

Qu'ils ne l'aient pas encore fait pour pleins de raison peut se comprendre. Ce n'est probablement pas la priorité. Mais argumenter que ça ne sert à rien, ça me paraît un peu fort.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Et bien pas complètement, parce que ça veut dire que la suite de validation de Pythran ne passe pas que sur l'architecture x86_64, mais aussi sur armv7hl, i686, aarch64, ppc64le, s390x, comme l'illustre ce build.

J'ai dû lire un certain nombre de fois cette phrase pour la comprendre.

C'est une preuve que ça pythran était multiplateforme ou ça vous a demandé du travail de portage ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Mais ici c'est le rendu des pages qui paraît le plus lent. Par exemple, si je scroll de plusieurs pages d'un coup, j'aurai des écrans vides pendant 2-3 secondes le temps que firefox redessine la page. Ce ralentissement là, je ne l'avais pas autrefois (y'a 15 ans).

CSS3 c'est un gros morceau et si ça apporte vraiment beaucoup au développeur ça donne du travail au navigateur.

Le site oui-sncf :[…]

Tu as essayé l'extension OUI Light pour voir ce que ça donne ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Effectivement, en 64 bits l'utilisation mémoire augmente.

Les pointeurs mémoire sont plus gros pour les 2.

Mais l'usage mémoire réèl de Firefox est difficile à suivre[…]

about:performance (ce que j'utilise au dessus) n'est pas bon ? Depuis electrolysis ça doit être bien il doit être bien en mesure de savoir ce qui fait parti de l'onglet ou pas

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Intéressante question. Chez moi :

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

il est reconnu qu'un programme python s'exécute plus lentement (parfois beraucoupo plus lentement selon le programme) que le même programme écrit dans un langage compilé - exemple: le C). Mais ce problème ne concerne pas que Python: un site écrit en Ruby/Rails est assez lent (parfois plus lent qu'un site écrit en python). Le seul à bien s'en sortir à ce niveau (à ma connaissance), c'est le Perl ( dans une de mes missions, un outil avait été écrit en Perl plutôt qu'en python car Python s'en sortait pas niveau perfs). Et je ne parle pas de PHP qui n'a pas forcément une bonne réputation (mais que je ne connais plus suffisamment pour en parler). La lenteur ne vient pas du fait que les cycles CPU sont plus lent à s'exécuter pour un probramme python ou Ruby que pour un programme Perl ou C. Le fait est bien que Python ou Ruby utilisent plus de cycle CPU (donc plus d'énergie).

Ici tu décrit beaucoup de « on dit » et de généralités…

Un programme peut être bridé par 3 choses différentes :

• la CPU, on parle de CPU bound (ou intensive)
• la mémoire, on parle de memory bound
• les entrée/sortie, on parle de IO bound

Pour chacun des cas on peu distinguer plusieurs limites différentes possibles.

Un "deamon" ça n'a pas de profile de performance particulier. Ça peut demander du CPU, mais ça peut par exemple poser des problèmes de mémoire. Par exemple, un programme qui aura une longue durée de vie peut souffrir de fragmentation de sa mémoire. Au cours de sa vie il va utiliser et libérer de la mémoire, mais il doit faire attention :
- les fuites mémoire (qui existent avec des garbage collector comme sans) peuvent faire consommer énormément de mémoire à un tout petit programme
- la fragmentation de la mémoire au fur et à mesure de son exécution le programme laisse des "trous" non-utilisé de mémoire qui ne sont pas forcément réutilisés (trop petits, non adressables,…)

Il y a différentes façons de mitiger ses problèmes (pour ce dernier point il est possible de créer des pools de structures qui seront réutilisées plutôt qu'allouer ou il est possible d'avoir un garbage collector qui vient compacter la mémoire à son passage entre autres stratégies).

Tout ça pour dire qu'affirmer que tel langage n'est pas performant en général est plutôt succin et demande à regarder plus en avant quel genre de performance on souhaite et quels algos sont mis en place. Enfin il est fréquent qu'un programme soit fait de différents langages. CPAN contient énormément de code C qui possède juste une API perl. Je ne connais pas ussi, mais ce serait intéressant de savoir ce que fait wicd lorsqu'il utilise autant la CPU.

---

nlgranger, pourquoi utilise-tu 2 boucles imbriquées ? Tu pourrais n'en utiliser qu'une seul ça éviterais de te répéter.

D'autre part ton code de la ligne 78 à 86 me semble pouvoir être écrit plus simplement. prefix est sensé être une clef de ton dictionnaire bindings donc tu peux le récupérer et s'il existe lancer tes commandes sans avoir à itérer sur bindings :

# Process command
if prefix in bindings:
    logger.debug(f"handling {'+'.join(prefix)} on {device.path}")
    for cmd in bindings[prefix]:
        command_queue.put_nowait(cmd)

C'est moins pour moi une question de performance que de simplicité du code (pour totof2000 en terme de performance la différence entre les 2 codes sont non seulement que l'un fait un petit peu moins de choses, mais aussi qu'il fait moins de saut (moins de boucle, moins de if/continue/break), les sauts sont une plaie pour la CPU qui essaie de commencer son travail en avance (pipelining) et doit donc jeter tout le décodage qu'elle a fait pour rien).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Avec une dépêche plus en retard et bien moins détaillée que celle de développez.com. Rendre linuxfr great again c'est moins de contenu plus de troll ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll