barmic 🦦 a écrit 5767 commentaires

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

Son principal avantage est d’être « normal » : un menu pour lancer des applications, une barre de tâches, un gestionnaire de fichiers, un panneau de configuration…

Dis de manière moins tortueuse : son principal avantage est d'utiliser les même métaphores et les mêmes concepts que Windows XP.

Mais quels sont les avantages sur Mate ? Ce dernier gère par exemple Hidpi depuis février 2018.

Il ne cherche pas à révolutionner le bureau, à en mettre plein la vue ou à supprimer des fonctionnalités à chaque version.

Ou alors ils tentent juste autre chose. Pourquoi ce serait négatif ?

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

Tu as une observation. Qu'est-ce qui te permet d'en faire une corrélation et à fortiori une cause ?

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