barmic 🦦 a écrit 5211 commentaires

  • # Merci

    Posté par  . En réponse au journal SeqTools 1.0.0: la programmation concurrente, c'est dur!. Évalué à 1.

    Merci pour le partage. Je fais très peu de python et je n'ai pas besoin de ton outil, mais je suis toujours intéressé par les commentaire d'autres développeurs :)

    La difficulté principale ne vient étonnement pas du caractère asynchrone des réponses qu'il faut réorganiser (ça se résout en une vingtaine de lignes), le problème c'est les problèmes!

    Ça m'étonne. Ta bibliothèque1 semble considérer l'ordre comme importante (le nom et cette citation). Mais l'API incite à avoir un accès aléatoire aux donnée.

    Tu as regardé du coté de RxPython ? Ça ne fait pas du tout la même chose (le modèle d'exécution n'a rien à voir), mais leur API est plutôt complète pour permettre à l'utilisateur de gérer les cas d'erreur (entre autre). Par contre Rx va fortement teinter le code qui l'utilise (ce sont des types à eux qui sont utilisé et non des simili tableau).


    1. je trouve bien plus sympa de parler de bibliothèque qui amha véhicule une notion de partage plutôt que le faux ami librairie qui fait plus référence à une relation de clientélisme ;) ↩

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

  • [^] # Re: Et merci pour Git

    Posté par  . En réponse au journal Le papa de Linux a 50 ans aujourd’hui… Merci Linus !. Évalué à 3.

    1. mercurial aujourd'hui, n'est pas le mercurial d'il y a quelques années
    2. facebook n'utilise pas ton mercurial que tu a installer avec tes petits doigts et un apt/yum, mais watchman qui en conjonction de mercurial est efficace pour eux
    3. tu confond vitesse et montée en charge, tu peux avoir des logiciels très rapide qui ne montent pas bien en charge et des logiciels qui montent très bien en charge mais plutôt lent. Utiliser un tableau en mémoire pour représenter toutes tes données est extrêmement rapide, mais ça ne monte pas du tout en charge. Utiliser une base de données externe pour gérer tes données monte bien mieux en charge, mais ajoute une lenteur

    C'est pour ça que quand quelqu'un me dit que quelque chose est lent, je me méfit. Il faut toujours savoir ce que l'on entends par lenteur (débit, latence, montée en charge,…) et les conditions de test.

    De ce que j’en comprends, le problème de git avec les géants c’est qu’il marche très très mal avec des repos gigantesque. Et la plupart sont dans un mode monorepo, donc forcément ça pose des problèmes.

    En fait ce qui pose problème avec git (mais c'est pareil pour tous) :

    • la gĂ©nĂ©ration de diff sur des formats binaires : git Ă©tant modĂ©liser comme une sĂ©rie de patch c'est très contraignant. On recommande de dĂ©sactiver le diff pour ce genre de fichier (mais du coup la moindre modification remplace tout le fichier)
    • les accès disques watchman ou VFSForGit sont des approches diffĂ©rentes pour rĂ©duire autant que possible les I/O et n'ont d'intĂ©rĂŞt que si ton repo est Ă©norome et manipuler par beaucoup de monde.

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

  • [^] # Re: lilo

    Posté par  . En réponse au journal Que penser du navigateur internet Brave ? (Et pourquoi je privilégie Firefox…). Évalué à 5. Dernière modification le 01 janvier 2020 à 22:41.

    Mais encore ? J’ai cherché, au cas où ce soit réellement faisable, mais pas trouvé. C’est pour la démonstration ? C’est une possibilité méconnue qui existe quelque part ? C’est le tarif pour les méta-moteurs ?

    Oui c'est le prix de l'API. Elle n'est pas particulièrement complexe à utiliser.

    Et pourquoi pas ? Lilo annonce reverser 50% des revenus publicitaires. Le reste paye les coûts, et procure ou non des bénéfices. C’est mieux que DuckDuckGo et compagnie qui gardent les 100%, point.

    Plus depuis 2017 apparemment. Vu que ce sont les documents qu'ils mettent en avant comme preuve, ne pas avoir mis Ă  jour cette page pour 2018 et n'avoir mis aucun message expliquant pourquoi me semble dommageable.

    Qwant s’y est mis avec Qwant Causes, preuve que la demande a dû être là, ou que la comparaison du moins leur faisait ombrage.

    Ça ne prouve rien du tout. D'une part ça peut être du marketing, d'autre part bien sûr que les gens sont contents quand tu leur dis qu'ils peuvent faire la même chose qu'avant en les déculpabilisant. C'est super agréable de ne plus se culpabiliser sans rien faire.

    Si on considère que la pub rapporte un montant fixe (ce qui, in fine, est forcément le cas – je parle de la taille du gâteau), encore une fois, oui, je préfère que ce montant soit divisé au profit d’entités plus proches (ce que n’est pas Brave) et/ou plus éthiques (ce que ne me semble pas être Brave).

    Moi je te donne une autre hypothèse qui me paraît beaucoup plus solide que la tienne : Microsoft ne perd aucun argent dans l'affaire. À partir de là, pour que lilo puisse fonctionner, il faut que les annonceurs chez lilo paient plus que les annonceurs de Microsoft. Hors j'ai un énorme doute que lilo ai suffisamment pignon sur rue pour pouvoir faire ce genre de deal. Surtout qu'ils ne traitent apparemment pas avec les annonceurs (je n'ai vu nul part comment devenir annonceur pour lilo).

    Je présume qu'ils utilisent un service comme celui de Microsoft. D'autant plus qu'ils annoncent que leur liens sponsorisés sont pertinents.

    Donc leur modèle c'est d'agréger un service de moteur de recherche + un service de publicité et espérer faire suffisamment de bénéfice pour dégager assez d'argent pour payer leur infrastructure, donner à emmabuntus et avoir de quoi manger chaque jour.

    Il faut minimiser le prix du moteur de recherche et maximiser les revenus publicitaire avec encore plus de pression que n'ont a le faire google, microsoft, qwant ou baidu. Ça amplifie le problème des publicités plutôt qu'essayer de le corriger (et je met de coté l'impact écologique d'un intermédiaire).

    Il faut aussi considérer l’effet de levier du méta-moteur. D’un côté, ils profitent certainement d’un tarif de gros auquel je n’aurais pas accès (dans l’hypothèse d’abonnement que tu formules), de l’autre ils fédèrent autour d’associations (on parle de plusieurs milliers d’euros déjà versés à Emma) en annonçant clairement la couleur d’entrée de jeu (et le tout sans se rémunérer avec nos impôts).

    Il est particulièrement simple de voir leur ce qu'ils utilisent et combien ils paient la recherche, mais ils sont totalement silencieux sur d'où viennent ces liens sponsorisés, ils ont semble-t'ils arrêté de donner les preuves de leurs dons à emma.

    Je vais pas me lancer dans une analyse plus poussée pour tenter d'estimer à quel point ça fonctionne ou pas. Personnellement je m'en fou, j'ai juste un vrai problème avec les logique de « je me met au milieu d'un truc qui fonctionne mal et j'arrive à créer du bénéfice » comme les boites qui achètent pour revendre de l'énergie ou des actions. Je ne vois pas la contribution de lilo (faire proxy à bing ? bof, faire de la pub pour des projets ? en 2017 ils ont donné à 1200 projets différents tu les connais ?). J'aime pas tout ces mécanismes où des gens se font de l'argent en expliquant qu'ils vont donner une partie de ton argent à droite ou à gauche. Si tu veux donner donne, c'est le plus simple et largement le plus efficace (et ça me fait bien moins peur que de passer par un intermédiaire qui ajoute un risque à la transaction).

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

  • [^] # Re: La fondation mozilla partage une lourde part de responsabilitĂ© dans le fait que blink

    Posté par  . En réponse au journal Que penser du navigateur internet Brave ? (Et pourquoi je privilégie Firefox…). Évalué à 4.

    On peut voir que dans la roadmap de servo l'idée d'une bibliothèque embarquable est évoquée. Je pense que tu n'as pas trouvé ce que tu recherchais car le projet n'a pas encore atteint cette étape (et produit la documentation associée) !

    Au vu de l'historique gecko et de l'historique du projet servo (il a d'abord était conçu comme une expérimentation), je préfère voir avant de faire des plans sur la comète et si ça arrive ça va mettre probablement pas mal de temps. D'une part le projet se tiens déjà un historique pas tout petit, les techniques ont évoluées entre la création du projet et maintenant. D'autre part ça n'est pas la priorité de Mozilla qui reste avant tout Firefox. Ce qui sert Firefox est important pour eux et le reste est secondaire. C'est ce que l'on voit avec la manière d'intégrer les travaux de servo dans Firefox.

    Il est par exemple beaucoup plus simple de documenter au fur et à mesure son API et pas tenter de faire une passe globale à la fin. L'API de WebRender ne semble tout simplement pas documentée.

    Remettre à plus tard c'est rigolo, mais c'est aujourd'hui que les navigateurs se mettent à utiliser webkit/blink et rien à part un « on fera plus tard » ne permet de dire que servo sera un jour utilisable en dehors de Firefox (la base de code ne suffit pas, il faut aussi avoir un cycle de développement géré, une documentation, etc).

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

  • [^] # Re: La fondation mozilla partage une lourde part de responsabilitĂ© dans le fait que blink

    Posté par  . En réponse au journal Que penser du navigateur internet Brave ? (Et pourquoi je privilégie Firefox…). Évalué à 7.

    Tout d'abord il y a au moins une autre application non liée à Mozilla qui s'en sert : Songbird.

    Plus de mise à jour depuis 6 ans à peu près au moment où Mozilla a expliqué (cf: Embarquer_Gecko) :

    Embedding of Gecko is no longer supported. If you currently embed Gecko, you should use an alternate solution, because you will not be able to pick up new security improvements.

    Donc la page technique de description de gecko dis « utilisez autre chose », il n'y en a pas des milliers dans la nature de ces bêtes là… Ils auraient mis un lien vers le getting start de blink que ça aurait était pareil (ou de webkit à l'époque).

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

  • [^] # Re: Et merci pour subsurface

    Posté par  . En réponse au journal Le papa de Linux a 50 ans aujourd’hui… Merci Linus !. Évalué à 3.

    Comme pour git Linus n'y contribue plus. Je ne sais par contre pas si ce projet a du succès ou pas, je n'en ai entendu parlé que parce que Linus l'a initié.

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

  • [^] # Re: lilo

    Posté par  . En réponse au journal Que penser du navigateur internet Brave ? (Et pourquoi je privilégie Firefox…). Évalué à 5.

    Je ne comprends pas la logique. Tu préfère des pubs qui paient emmabuntüs, lilo et microsoft à des pubs qui paient microsoft ? Ça me semble être un non sens total. Si tu as un souci avec les pubs, il vaut mieux limiter leur poids économique plutôt que l'augmenter. Surtout qu'il faut les payer les microsoft et lilo (rien qu'en frais de fonctionnement) donc je présume qu'emmabuntüs reçoit relativement peu d'argent.

    Tu peux simplement payer bing et ne plus avoir de pub. Pour une trentaine de recherche par jour ça revient à 6€/mois et là tu ne fait vraiment plus travailler la pub. Pour le prix d'un abonnement VOD, tu peux donner quelques euros à emmabuntüs directement si tu le souhaite ;) (probablement plus que ta contribution en utilisant lilo).

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

  • [^] # Re: La fondation mozilla partage une lourde part de responsabilitĂ© dans le fait que blink

    Posté par  . En réponse au journal Que penser du navigateur internet Brave ? (Et pourquoi je privilégie Firefox…). Évalué à 5.

    Maintenant je pense que la refonte technique qui est en cours permettrait peut-être de régler le problème? À l'heure actuelle, est-il possible d'embarquer le moteur de rendu de firefox dans une autre application?

    Le problème n'a jamais était technique, mais organisationnel. Mozilla voulait pouvoir refactorer le code de Firefox et de Gecko sans avoir à ce soucier de ce que ça va péter chez d'autres projets. Tout ça en gérant les documentation qui doit être mise à jour voir éventuellement documenter ce qu'ils ont cassé. Ça ça prend du temps et ça ne rapporte aucun dollars.

    Maintenant ils sont les premiers à se plaindre que tout le monde utilise le code d'un projet qui lui est documenté et dont l'API est stabilisée alors qu'eux t'expliquent qu'il faut surtout pas réutiliser leur bébé (et c'est compliqué chez Mozilla la documentat).

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

  • [^] # Re: Et merci pour Git

    Posté par  . En réponse au journal Le papa de Linux a 50 ans aujourd’hui… Merci Linus !. Évalué à 5.

    Je crois que Linus avait regardé du côté de hg, mais le trouvait trop lent. Trop lent pour le projet linux ça n'est pas représentatif pour tout le monde. Surtout que git qui a été pensé pour la vitesse d'abord reste trop lent pour Google et Microsoft qui utilisent des techniques à côté pour que ça puisse rester utilisable.

    Dans l'usage hg a toujours été au moins équivalent. Les gens étaient surpris au début quand pour créer une branche on leur proposait de checkout leur dépôt local dans un autre dossier, mais depuis il a eu pleins d'ajout. Maintenant il y a du choix.

    J'ai toujours trouvé l'aspect modulaire de hg plus intéressant que la recherche de performance de git.

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

  • [^] # Re: Ça coĂ»te un bras

    Posté par  . En réponse au journal une année de RGPD. Évalué à 3.

    Aucun traitement des données ? C'est impossible pour la cnil puisque leur stockage est déjà un traitement (d'après https://www.cnil.fr/fr/definition/traitement-de-donnees-personnelles). Leur utilisation aussi d'ailleurs. Donc pour la cnil soit tu fais un traitement des données, soit tu n'a rien à leur dire.

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

  • [^] # Re: Haskell super expressif ?

    Posté par  . En réponse au journal Comprendre Go en 5 minutes, en Haskell. Évalué à 1.

    Je pensais à un autre amoureux du paradigme fonctionnel mais aussi de philosophie (explique lui que Kant n'est pas parfait et il t'en coûtera) qui a su mal à ne pas glisser dans ses longues explications que l'orienté objet est fondamentalement défaillant.

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

  • [^] # Re: Et merci pour Git

    Posté par  . En réponse au journal Le papa de Linux a 50 ans aujourd’hui… Merci Linus !. Évalué à 10.

    Amha si git n'avait pas existé on utiliserait simplement mercurial qui fait très bien le taff.

    Sans vouloir remettre en cause la pertinence de git.

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

  • [^] # Re: Haskell super expressif ?

    Posté par  . En réponse au journal Comprendre Go en 5 minutes, en Haskell. Évalué à 1.

    Le point sous-jacent étant : est-ce que le développeur a besoin de savoir quelque chose à propos de la curryfication/décurryfication ?

    Oui c'est extrêmement pratique dans un paquet de situation. Par exemple à chaque fois que tu as une série de boucles imbriquées. Le code de la boucle la plus profonde est une fonction prenant en paramètre l'ensemble des éléments courants de chaque boucle.

    La décurryfication n'existe pas.

    Après je présume qu'avec les mots clefs haskell et curryfication, tu aura tôt fait d'invoquer un habitué du site qui se fera un plaisir de te faire un cours magistral sur la question (tout en laissant passer un ou 2 trolls sur l'orienté objet).

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

  • [^] # Re: Ça rapporte

    Posté par  . En réponse au journal une année de RGPD. Évalué à 3.

    Alors la j'ai définitivement rien compris…

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

  • [^] # Re: Ça rapporte

    Posté par  . En réponse au journal une année de RGPD. Évalué à 3.

    Tu as lu les textes ? La LCEN est à la limite compréhensible. Le RGPD, bon courage. Et ePrivacy… Donc pour le particulier, mis à part lui faire faire un clic de plus, bof.

    Ce n'est pas la compréhension des textes de lois qui va faire changer quoi que ce soit à la compréhension par les particuliers. Car non ils ne regardent pas les lois, ni les décrets d'application sauf quand ils en sont contraints. Par contre des pages comme celle de numerama qui vulgarisent le sujet il y en a pleins.

    À coté de ça la LCEN est connue car elle a réussi à mettre en rogne un paquet d'organismes de l'April à la ligue des droits de l'homme.

    Bref ce n'est pas que la qualité intrinsèque des lois qui compte, mais aussi sa perception.

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

  • [^] # Re: Ça rapporte

    Posté par  . En réponse au journal une année de RGPD. Évalué à 2.

    Et le marketing qui a était fait. La LCEN est bien moins connues, là où le RGPD a reçu une grande publicité. Cela permet aux particuliers de savoir que ça existe, de mieux connaître leur droit et de les faire respecter.

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

  • [^] # Re: lost in translation

    Posté par  . En réponse à la dépêche GCompris sort en version 0.97. Évalué à 4. Dernière modification le 28 décembre 2019 à 08:39.

    J'ai aussi bloqué sur l'indien en lisant. Je n'étais pas au courant pour la Norvège.

    Pour l'ordre j'ai aussi trouvé ça gênant, mais c'est un tri sur le taux de traduction qui m'a paru le plus logique (en plus il est indépendant de la langue de la news ;-)

    Où as-tu vu que c'était une traduction ?

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

  • [^] # Re: A court terme, pourquoi pas

    Posté par  . En réponse au journal Laminar: un outil d'intégration continue qui semble léger. Évalué à 2.

    Un bon système d'intégration continue, ça doit être bien documenté, facile à administrer, fiable, déterministe et ne doit pas rendre obligatoire de s'y coupler fortement.

    Je ne comprends pas bien ce dernier point. Le build doit être agnostique (pas dépendant d'un IDE ou d'une CI), mais la glue autour pour gérer un workflow/pipeline pour la CI/CD ça ne me gène pas que ce soit spécifique.

    une conso délirante de ressources (Gitlab).

    J'ai très peu utiliser gitlab CI et je n'ai jamais administré autre chose que des workers, je ne me suis pas rendu compte de souci de ressources.

    Teamcity est un plaisir Ă  utiliser et administrer, son offre gratuite est potable pour de petits projets.

    Il consomme pas trop de ressources ? Je ne m'en suis jamais servi, mais un ami, m'expliquait que c'était assez contraignant à ce niveau là (on utilise déjà intellij et upsource au boulot, passer de jenkins à teamcity pourrait être une bonne idée).

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

  • [^] # Re: Interface CSS

    Posté par  . En réponse à la dépêche darktable 3.0 : une version plus que majeure !. Évalué à 1.

    Merci j'avais raté cette possibilité :)

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

  • [^] # Re: Interface CSS

    Posté par  . En réponse à la dépêche darktable 3.0 : une version plus que majeure !. Évalué à 1.

    C'était plus pour la curiosité intellectuelle que pour chercher à créer un thème ;)

    Effectivement la possibilité d'utiliser CSS pour modifier l'interface date au moins de la version 2.4 (première version où il y est fait mention dans les dépêches ici).

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

  • # Interface CSS

    Posté par  . En réponse à la dépêche darktable 3.0 : une version plus que majeure !. Évalué à 2.

    Comment est implémenter l'interface CSS ? Les techno que je connais pour faire ça c'est electron ou xul ou gérer une webview à la main dans une fenêtre gtk/qt/whatever.

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

  • [^] # Re: La base de la base

    Posté par  . En réponse au journal Restaurer l’historique de zsh. Évalué à 4. Dernière modification le 29 décembre 2019 à 12:35.

    zsh a une option pour ça : incappendhistory. Conjugué avec appendhistory et sharehistory, tu obtiens quelque chose qui tient la route en termes de gestion d’historique.

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

  • [^] # Re: Ah !

    Posté par  . En réponse au journal kdenlive 19.12.0 et accélération matérielle. Évalué à 5. Dernière modification le 25 décembre 2019 à 16:53.

    Il y a des dalles de téléphones 4k ? Si non ils font probablement du downsize au moins pour l'édition.

    Que ça soit possible et qu'il faut entre autre repenser les algos (réévaluer le coût de chaque opération lorsque les images sont plus grosses), je n'en doute pas et c'est un avantage d'un nouveau logiciel que les plus anciens, mais de là à travailler entièrement en 4k sur téléphone ça m'étonnerait (rien que pour économiser la batterie).

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

  • [^] # Re: Il manque un s

    Posté par  . En réponse au journal Restaurer l’historique de zsh. Évalué à 7.

    Ça me fait penser que j'ai aucune nouvelles de mon pote shred…

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

  • [^] # Re: Ah !

    Posté par  . En réponse au journal kdenlive 19.12.0 et accélération matérielle. Évalué à 2.

    Enfin même sans cela, le calcul GPU n'est pas forcément plus rapide, par design. Il y a beaucoup de littérature sur le sujet qui explique que dans certaines conditions, le calcul CPU peut être plus rapide (en plus d'être plus précis, c'est à dire avec moins d'erreurs de calcul). Sans compter que développer pour le GPU est différent voire plus complexe, donc il peut y avoir plus facilement des bugs, et de manière générale ce n'est pas ce qu'on voudra faire en première version.

    Autant dans le cas général, je comprends autant dans le cas de l'édition vidéo, j'ai du mal à voir les cas. Là où un CPU est meilleur que le GPU c'est quand on a un traitement très "aléatoire" où la prédiction de branchement est très mauvaise ou quand le temps de calcul sera moins impactant que les temps de transfert sur le bus PCIe. Certains filtres demandant de l'aléatoire et tuant fortement le parallélisme pourraient donner ce genre de résultat, mais j'imagine que ça reste rare, non ?

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