barmic 🦦 a écrit 5976 commentaires

  • [^] # Re: GPS

    Posté par  . En réponse à la dépêche Contribuer à OpenStreetMap avec l'éditeur iD. Évalué à 1.

    Ou bien l'utiliser pour voir ce qui manque dans OSM ?

    Hein ? Tu achète un garmin pour connaître les manques d'osm et les reporter dans osmand ? C'est farfelu et tout à fait inutile.

    Personnellement, j'ai tendance à faire sans GPS, c'est plus amusant (similaires aux géo caches mais en plus utile), ça fait travailler la cognition spatiale ce qui doit être bon contre la maladie d'Alzheimer,

    C'est une référence à la vieille manie "dis moi ce dont tu as besoin et je te dis ~comment~pourquoi t'en passer" ?

    ça vide moins les batteries.

    C'est l'inverse amha. Ce qui consomme de la batterie c'est l'affichage de la carte et tu la manipule bien plus quand tu t'en sers sans GPS (et potentiellement plus longtemps). D'autan que l'on parle de matériel qui ne sert qu'à cela donc ça n'a pas vraiment de sens.

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

  • [^] # Re: GPS

    Posté par  . En réponse à la dépêche Contribuer à OpenStreetMap avec l'éditeur iD. Évalué à 7.

    Il est possible d’avoir des cartes à jour du monde entier

    OSM n'est à jour que dans certains endroits au gré des contributions. Tu le vois au volume des cartes. L'Allemagne et la France sont bien cartographiées par exemple, mais ça n'est pas le cas partout. Tupeux contribuer, mais pour les endroits vraiment mal cartographiés tu connaîtra suffisamment le lieu pour ne plus avoir besoin de GPS avant d'avoir fini. Bref regardez le contenu d'OSM avant d'acheter.

    Pour ceux qui seraient génés de ne pas payer un centime pour une cartographie à jour

    Il est aussi possible de donner de l'argent. https://openstreetmap.assoconnect.com/billetterie/offre/61684-j-faites-un-don-a-openstreetmap-france

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

  • [^] # Re: 16 bits & EXIF

    Posté par  . En réponse à la dépêche 25 ans de GIMP et version de développement 2.99.2 : premiers pas vers GIMP 3 !. Évalué à 2.

    Aaaah. Je viens (peut-ĂŞtre?) de comprendre. En fait, tu voulais me parler de l'ordre inverse (tu vois, quand je disais que d'indiquer l'ordre clairement, c'est important!):

    C'est ça ! (mais l'ordre est indiqué é_è)

    Si tu dis: je multiplie par 2 toutes les valeurs, ça ne dépend pas de la plage.

    C'est toi qui est passé de « je divise par 2 je multiplie par 2 en 8 bits » à «  je divise par 4 je multiplie par 4 en 9 bits ». J'ai mal compris ton premier commentaire, comme tu as commencé avec *2/2 et que tu as ensuite fait *4/4 j'ai pensé que tu avais modifié aussi les opérations en changeant de codage.

    Ensuite tu as tout de même raison que dans ton cas extrême, tu perds quand même énormément de couleurs.

    Yep c'est bon j'ai compris.

    Enfin, il faut voir que cela reste des exemples extrĂŞmes que tu nous sors

    Tout à fait. Je suis ne mis connaît que très mal en manipulation d'image. C'est purement l'aspect mathématiques (et comprendre son fonctionnement dans la vraie vie) qui m'a titillé. Gimp 2.8 n'avait pas de problème de cet ordre c'est bien que ça n'arrive pas si souvent. Je présume que c'est ce qu'on trouve quand on laisse un paramètre de la fonction mathématiques à l'utilisateur et qu'il s'amuse à aller au bout de la plage de valeur qu'on lui donne, mais là c'est charge à l'utilisateur de correctement utiliser l'outil.

    Donc ton exemple, bien qu'extrême, reste en plein dans le mille et montre bien ce qu'est l'édition raster.

    Merci :)

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

  • [^] # Re: 16 bits & EXIF

    Posté par  . En réponse à la dépêche 25 ans de GIMP et version de développement 2.99.2 : premiers pas vers GIMP 3 !. Évalué à 3.

    P.S.: les flottants ont aussi un gros avantage qui est de pouvoir aller sous zéro et au dessus de 1.0. Puisqu'on rappelle que le min et max sont juste un choix arbitraire, les couleurs hors de cette plage sont des couleurs tout à fait valides. Simplement elles ne sont pas autorisées dans l'espace de couleur en cours ("hors gamut"). Mais il est super intéressant de pouvoir les garder jusqu'au bout parce que — qui sait — certains effets ramèneront peut-être la couleur des pixels hors-gamut à l'intérieur. Or supposons qu'on ait tronqué les couleurs plus tôt, ben là encore, on a mis plein de couleurs à la même couleur trop tôt et donc perdu énormément de précision (i.e. bandes de couleurs, etc.). Alors que si on les garde jusqu'au bout, on a une chance de garder la précision (on ne tronque qu'au moment de l'export).

    Hum en flottant la précision de tes opérations mathématiques baisse beaucoup. Tu as une approximation qui est faite à chaque opération. Pour ce qui est de la plage, je comprends donc que lorsque l'on utilise les flottants on utilise une toute petite partie on utilise de [0; 1.0] pour représenter les couleurs visibles au sein d'une plage de valeur allant de -126 à 127. Ça évite le problème dont je parlais pour d'écrasement.

    C'est à ça que servent les calques d'effet notamment[…]

    D'acc je comprends. J'ai pas compris si ça existe dans gimp ou si ça va exister ?

    Euh… je comprends pas du tout tes maths là. Bon déjà quand on fait des maths en informatique, on perd l'associativité, donc faut mettre des parenthèses (c'est à dire que (255 / 2) × 2 = 254 mais (255 × 2) / 2 = 255 en calcul entier, sans perte de précision dans cet ordre!) sinon je comprends pas là où tu veux en venir.

    Euh… Le numérateur se calcul avant, il n'y a pas besoin des parenthèses avec la représentation que j'utilise.

    Mais surtout, ils sortent d'oĂą tes 128?

    Excuse-moi je me suis dis après coup qu'il falait que je détail et puis j'ai validé trop vite. Je vais utiliser une représentation en ligne pour m'aligner sur ta façon et détailler. On est en 8bits donc avec des valeurs de 0 à 255.

    (255 * 2) / 2 = 255 / 2

    Tu ne peux pas représenter de valeur au dessus de 255 donc je présume que toutes les opérations sont toutes calculées en prenant le minimum entre la résultat et la borne haute et le maximum entre le résultat et la borne basse. Si ça n'est pas le cas c'est que l'overflow est laissé tel quel est ça donne

    (255 * 2) / 2 = 254 / 2 → c'est à dire 510 mod 256

    Par contre il y avait une erreur dans mon calcul ça donne dans les 2 cas 127 et pas 128.

    En supposant que tu essayais de reproduire mes exemples oĂą tu fais la division d'abord.

    J'ai volontairement inversé les opérations pour dépasser la borne haute sans supposer qu'il s'agissait de la même opération que toi.

    Je ne vois aucun problème particulier dans tes exemples.

    Mes exemples visaient à montrer que quelque si ton gammut (si j'ai bien compris) correspond aux bornes de ta représentation toute multiplication va avoir des conséquences problématiques. Tu va overflow ton entier et tomber sur une valeur que ta représentation ne sait pas représenter (je parle bien de l'aspect mathématiques). Ça n'est pas pire en 9 qu'en 8bits. Tu as répondu à cette question en parlant plus haut du codage flottant qui n'utilise qu'une toute petite parti de l'espace pour code le gammut.

    à propos, note que j'utilise 9 bits pour l'exemple car ça permet un exemple simple où tu multiplie ta plage pour 2.

    Tout à fait c'est la manière de passer du 8 bits à une autre représentation qui m'a intriguée.

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

  • [^] # Re: 16 bits & EXIF

    Posté par  . En réponse à la dépêche 25 ans de GIMP et version de développement 2.99.2 : premiers pas vers GIMP 3 !. Évalué à 3.

    D'abord transformons nos valeurs dans le format de travail 9-bit:

    Juste au cas où pour améliorer ton explication, cette transformation m'a fait tiquer au premier abord. 2 reste 2 en 8, 9, 16, 32 ou 1 millions de bits normalement. Ici les valeurs sont réparties. On pars d'une plage de [0; 256[ et on arrive à [0;512[ on multiplie par 2 pour laisser un espace entre les couleurs. Comme tu le montre il faut retraduire toutes les opérations pour ce format. J'imagine que c'est pour ça qu'avec GEGL vous travaillez exclusivement en 32bits si j'ai bien compris. Comme ça les opérations n'ont pas à être implémentée pour tous les encodages possibles de couleur.

    • \frac{2}{2}2 = 1 \times 2 = 2
    • \frac{3}{2}2 = 1 \times 2 = 2

    Là c'est même pire que tout, on a carrément deux opérations qui auraient dû s'annuler mais qui à la place ont juste fait perdre des couleurs. Ça veut notamment dire que tous les 3 de l'image ont d'ailleurs disparu (en fait tous les nombres impairs dans cet exemple), on a vraiment perdu en précision !

    J'ai l'impression que cet exemple montre surtout qu'il faudrait n'appliquer les opérations qu'au moment de l'export et utiliser une résolution des opérations "intelligente". C'est j'imagine très compliqué car les pixels ne sont souvent calculé en groupe. Donc chaque pixel devient non plus 3 valeurs, mais un système de 3 opérations qui sont perpétuellement recalculés pour l'affichage. Ça rend caduque toutes les formes d'optimisations classiques à coup de SIMD par exemple.

    Par contre ça me pose une dernière question. Utiliser le codage 9bits que tu décris n'est pas exempte de problème. Si je reprend tes opérations, mais dans l'ordre inverse (et avec d'autres valeurs), sur 8 bits :

    Sur 16 bits :

    128 en 9bits donc 64bits en 8bits. Ici ce n'est même plus une perte de précision ça a annihilé la moitié de la plage de couleur. Pour gérer ce genre de cas de manière total il faudrait que les entiers soient représentés en taille arbitraire (ou à minima que ce soit le cas lorsque l'on détecte un overflow), mais ça casse encore toute optimisation… Pou mitiger un peu ces problèmes est-ce que la représentation 32bits utilise toute la plage ou est-ce que ça n'utilise pas qu'une partie ?

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

  • [^] # Re: Titre qui fait peur?

    Posté par  . En réponse au journal Android < 7.1 va refuser les connections TLS certifiées par Let's Encrypt. Évalué à 3. Dernière modification le 25 décembre 2020 à 18:59.

    Que des non connaisseurs puissent se poser des questions avant une études ça ne me paraît pas choquant. C'est en se basant sur des études qui, j'espère, s'appuient sur des connaisseurs plutôt que sur des aprioris de béotiens qu'il est possible de prendre des décisions éclairées. Je ne pense pas qu'insulter l'intelligence de quelqu'un qui demande à en savoir plus soit pertinent. Oui ça demande de l'argent de s'informer.

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

  • [^] # Re: ouf.

    Posté par  . En réponse au journal Android < 7.1 va refuser les connections TLS certifiées par Let's Encrypt. Évalué à 0.

    Pourquoi cette obsession à vouloir me faire dire tout le contraire de ce que j'écris ? Je m'exprime probablement en marsien ?

    Quand je lis :

    Du coup je vois d'un mauvais œil quand c'est par le logiciel qu'on veut me faire jeter un truc qui tourne encore bien.

    J'entends que tu reproche à celui qui est responsable de la partie logicielle qui ne marchera plus et c'est IdentCA qui a décidé de rendre son certificat invalide. Encore une fois je ne te reproche rien, car le logiciel ici c'est 4 acteurs : Google via android ou aosp, ton constructeur via sa surcouche, LE via ses certificats et IdentCA avec son certificat racine. Il me semble intéressant de préciser la chaine de responsabilité vu que tu la voie d'un mauvais œil.

    Donc non je ne dirais pas que c'est du "marsien", juste que ça me semblait manquer cruellement de précision.

    Les certificats LE pourraient même être valides une semaine ou un seul jour que ce ne serait pas de l'obsolescence programmée.

    La loi française décrit l'obsolescence programmée ainsi :

    Art. L. 213-4-1.-I.-L'obsolescence programmée se définit par l'ensemble des techniques par lesquelles un metteur sur le marché vise à réduire délibérément la durée de vie d'un produit pour en augmenter le taux de remplacement.

    À moins de chercher à expliquer qu'un certificat n'est pas un produit ou qu'il n'y a pas de marché de certificat ça me paraît correspondre. Ça n'est pas pour autant un reproche.

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

  • [^] # Re: Titre qui fait peur?

    Posté par  . En réponse au journal Android < 7.1 va refuser les connections TLS certifiées par Let's Encrypt. Évalué à 3.

    Mais Apple a montré qu'il est possible de faire largement mieux car l'upgrade est géré.

    Je trouve au contraire qu'ils ont montré que c'était compliqué. Pour faire ça ils font des optimisations qui demandent à maitriser toute l'intégration OS/matériel (comme le fait de brider pour sauver la batterie). C'est évidement empiré par le fait que chaque constructeur va plus ou moins avoir sa couche pour se dissocier de google ou se démarquer des autres.

    Je trouve plutôt qu'android devrait être fait pour durer. Des mises à jour de sécurité distribuées sur play et un support de sécurité de plusieurs années. Je ne suis pas l'actualité mais de ce que je suis entrain de regarder une grande partie des nouveautés de chaque version n'est que des mises à jours logiciels.

    Je ne vois pas plus de problème au fait que les gens utilisent KitKat qu'au que d'autres utilisent RHEL 6 sorti en 2011.

    J'ose espérer qu'IdenTrust renouvellera pour 3 ans de plus; et je ne vois pas de problème de confiance, c'est un choix […]

    La solidité de SHA1, des clefs RSA 2048bits et d'autres algos ça n'est pas une question de choix. C'est pas comme si ça faisait 15 ans qu'on parle des problèmes de SHA1… DST Root CA X3 a était édité en 2000 avec les méthodes des années 2000. Il n'est pas acceptable de continuer à l'utiliser indéfiniment.

    et surtout Google et compagnie peuvent décider de refuser sur machine plus moderne si ils ont peur, bref tout est faisable.

    Ça signifie créer une exception pour accepter directement ISRG root X1 sans valider son signataire, c'est sans doute possible mais si on arriver à minimiser les exceptions de ce genre (il y en a déjà en cours pour des certificats sortis des trustores, mais qui sont utilisés par des services considérés comme trop importants pour être inaccessibles). Ça participe à réduire le niveau de sécurité et les attaques sont généralement de cet ordre : on utilise différentes choses qui chacune réduit pas suffisamment le niveau, mais qui bout à bout finissent par rendre le tout fragile.

    Bref, il va falloir sérieusement discuter (car les constructeurs seuls ne feront rien) développement durable si on veut éviter tous ces déchets…

    Ah on va pas te proposer des téléphones au même prix s'il faut maintenir une équipe de développeurs quelques années dessus même si elle n'est pas dédiée au téléphone en question. Il faut multiplier ce genre de situations :) Jusqu'à ce qu'une solution émerge pour de bon.

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

  • [^] # Re: Titre qui fait peur?

    Posté par  . En réponse au journal Android < 7.1 va refuser les connections TLS certifiées par Let's Encrypt. Évalué à 2. Dernière modification le 24 décembre 2020 à 16:48.

    En plus, ça pourrait réduire la confiance des systèmes dans leur gestion des certificats.

    C'est fait en accord avec les auditeurs, je pense pas qu'il y ai de problème.

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

  • [^] # Re: ouf.

    Posté par  . En réponse au journal Android < 7.1 va refuser les connections TLS certifiées par Let's Encrypt. Évalué à 3.

    Du coup je vois d'un mauvais œil quand c'est par le logiciel qu'on veut me faire jeter un truc qui tourne encore bien.

    Encore une fois ce n'est pas la faute des autorités de certifications. Des certificats ça vie et ça doit évoluer. Ça ne fais que révéler ce que ton constructeur ne fait pas.

    Je ne dirai pas non plus que LE fait de l'obsolescence de leur certificat

    C'est ce qu'il fait. Ça n'est ni un avis, ni un reproche de ma part. Les certificats émit par LE sont valables 3 mois. Ils le font pour de bonnes raisons, même si je ne doute pas que ça puisse être débattu.

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

  • [^] # Re: Pointeur neutre

    Posté par  . En réponse à la dépêche 25 ans de GIMP et version de développement 2.99.2 : premiers pas vers GIMP 3 !. Évalué à 5.

    Idéalement, il faudrait faire un sondage pour savoir si la chose serait bienvenue.

    Un ticket c'est fait pour ça. Ça permet de connaître l'opinion des développeurs et de garder les discussions pour l'avenir (si dans l'avenir quelqu'un se repose la question, il pourra le retrouver facilement et si les arguments changent ça pourra être fait en connaissance de cause).

    Le bug tracker de gimp est ici. Il y a un label featue qui me semble tout indiqué pour ça.

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

  • [^] # Re: 16 bits & EXIF

    Posté par  . En réponse à la dépêche 25 ans de GIMP et version de développement 2.99.2 : premiers pas vers GIMP 3 !. Évalué à 6.

    la non prise en charge d'une profondeur de couleur de 16 bits. Je sais, ça ne sert à rien et ça fait des fichiers énormes, mais lesdits photographes ne sachant pas régler l'exposition à la prise de vue, ils espèrent pouvoir rattraper les détails dans les ombres en post-traitement…

    Je sais pas si 16 bits ça sert à rien mais depuis gimp 2.10 et l'intégration de GEGL il est possible de travailler en 16 ou en 32 bits (GIMP 2.10 roule au GEGL > Haute précision des couleurs). Je crois que gimp a mis du temps à y passer non pas parce que ça n'a pas d'intérêt mais parce qu'ils voulaient le faire via GEGL.

    Pour l'exif je ne sais pas.

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

  • [^] # Re: Mageia

    Posté par  . En réponse à la dépêche CentOS se saborde‑t‑elle ?. Évalué à 3. Dernière modification le 24 décembre 2020 à 09:25.

    Hum, on attends tes contributions pour payer les sysadmins de mageia a mettre à jour des machines non critique de l'infrastructure…

    Ça questionne tout de même la durée de vie des versions si elle est trop courte même pour le projet, non ?

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

  • [^] # Re: Support rust

    Posté par  . En réponse à la dépêche 25 ans de GIMP et version de développement 2.99.2 : premiers pas vers GIMP 3 !. Évalué à 10.

    C'est un bot qui génére ces commentaires sur rust ?

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

  • [^] # Re: ouf.

    Posté par  . En réponse au journal Android < 7.1 va refuser les connections TLS certifiées par Let's Encrypt. Évalué à 5.

    je préfèrerais quand même qu'il y ait un support plus long (et non une course à la dernière qui ressemble à une obsolescence presque programmée)

    C'est ton fabricant qui a arrêté les mises à jour qu'il faut blâmer. Let's encrypt fait de l'obsolescence programmée de certificat, mais ça ne devrait pas poser de problème (et là ce n'est pas l'obsolescence de leur certificat dont il est question d'ailleurs). Après si ton Android est rooté, tu peux probablement juste ajouter le nouveau certificat.

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

  • [^] # Re: Super

    Posté par  . En réponse à la dépêche Quatre années de wallabag.it. Évalué à 2.

    C'est fou j'ai jamais vu rabbitmq stuck et on lui balance des dizaines de milliers de messages par secondes. Je serais intéressé de savoir ce qui se passe (un plugin peut-être ou l'OOM qui tue un process ?). Si ça te dit quand tu aura réglé le problème n'hésite pas à en faire un journal :)

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

  • [^] # Re: Super

    Posté par  . En réponse à la dépêche Quatre années de wallabag.it. Évalué à 2.

    Utiliser des queues lazy ça permet de réduire l'usage de la ram au détriment de la latence, mais je pense pas que la latence soit un réel problème.

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

  • # LimitĂ©

    Posté par  . En réponse au journal Toujours plus proche du Python avec C++. Évalué à 3.

    Tu documente le site appelant, mais la fonction elle-même y perd…

    • dans ton exemple je ne sais pas dire quels sont les types valides de keyword?
    • la dĂ©finition des paramètres n'est pas dĂ©claratives ce qui va complexifier de beaucoup l'analyse statique
    • ça gĂ©nère quoi comme erreur en cas d'erreur ? (mauvais type, mauvais nom,…)

    Ça me parait plus apporter de complexité que de solution.

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

  • # Super

    Posté par  . En réponse à la dépêche Quatre années de wallabag.it. Évalué à 3.

    Objectif pour 2021 : 15 000 € de CA et 1 500 factures ? Et ne pas trop augmenter mes frais mensuels. Ça s’annonce compliqué !

    Si mes calculs sont justes1 tu es à 0.99€/mois/client en moyenne cette année. Il faut voir si ça rentre dans tes frais.

    Tu as eu des difficultés cette année ? Tu tourne sur quoi comme infra ?


    1. CA divisé par le nombre de mois achetés ↩

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

  • [^] # Re: Ça s'entend...

    Posté par  . En réponse au journal Travis CI : aimer le libre (pour se faire connaître), mais pas/plus trop. Évalué à 3.

    S'acoquiner avec une boîte en mode SAAS c'est une stratégie à l'encontre de la liberté et de l'indépendance.

    Sans jugement, ce n'est pas le cas avec github et travis ?

    Perso je trouve la plupart des nouvelles solutions anémiques. La CI ce n'est pas que construire un binaire à partir du code, mais aussi tout un rapport d'exécution pour la couverture, le résultat de l'analyse statique, effectuer des actions périodiques ou déclenché manuellement,… Donc je pars généralement sur jenkins + sonarqube. Si je n'ai besoin que de builds la solution fournie par la forge c'est le plus simple et si tu as confience pour y mettre ton code, tu dois pouvoir lui demander d'exécuter un script.

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

  • [^] # Re: Aimer le libre mais en fait il fait chier Ă  filer trop de libertĂ©s

    Posté par  . En réponse à la dépêche CentOS se saborde‑t‑elle ?. Évalué à -2.

    C'est rigolo de donner des leçons sur le libre quand il y a quelques jours à peine tu amalgamais libre et gratuit ;p ("koa ?! Vous me dites de payer ? Mais c'est fou d'entendre ça sur un site de libriste ! Vous êtes contre le libre !")

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

  • [^] # Re: Et ils l'appliquent...

    Posté par  . En réponse au journal Travis CI : aimer le libre (pour se faire connaître), mais pas/plus trop. Évalué à 0.

    Tu ne te rends même pas compte que par cette manière tu les descends encore plus :-p

    Tu es simple. Je me dis de défendre travis, je ne les ai jamais utilisé. Quand on me propose quelque chose qui n'a pas de sens, je m'en écarte. Je ne fais pas comme si de rien n'était pour pleurer quand il se passe des choses que je n'aime pas.

    Encore un endroit sur internet où "open source" est mal utilisé ? (pour dire que c'est une condition nécessaire, mais pas suffisante) très bien. Mais ce n'est pas le sujet du journal qui parle de procès d'intention, d'utilisation du libre, etc

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

  • [^] # Re: Et ils l'appliquent...

    Posté par  . En réponse au journal Travis CI : aimer le libre (pour se faire connaître), mais pas/plus trop. Évalué à 3.

    Le fait d'avoir des committers payés ne rend pas un projet moins Open Source. Pour moi, il faudrait plutôt arriver à ce que ce soit plus courant que moins et que le maximum de gens intervenant autour des projets Open Source soient payés pour leur travail.

    On est d'accord et ce serait même super cool que les bénéfices diffusent vers les projets dépendant.

    Il faudrait aussi arrêter de penser que parce que Red Hat paie certains développeurs, il faudrait en plus payer la CI et tous les autres besoins du projet - et puis aussi mettre plus de développeurs parce qu'on ne corrige pas les bugs assez vite comme je peux le lire trop souvent…

    La question n'est pas de savoir ce qu'ils doivent faire. Ils font bien ce qu'ils veulent.

    Le fait que l'offre possède des contraintes ne me semble pas avoir vocation à définir le bien du mal.

    Il s'agit juste d'un bras de fer entre entreprises. Je ne connais pas OGM, mais je comprends tout à fait qu'une entreprise empêche des boites qui font des dizaines de fois leur bénéfice de profiter de leur offre gratuite. La majorité des développements de RedHat sont libres, ça les embêterais de les voir profiter, ça a même peut être déjà était le cas. On parle de RH, mais c'est logique.

    Oui ça crée des faux-positifs et des faux-négatifs, mais monter sur ses grands chevaux pour ce types de banalités, ça me semble exagéré. Ce n'est pas une insulte au Libre avec un grand "L". C'est juste le business d'une entreprise en difficulté.

    En l'occurrence dans le cas d'Hibernate, nous avons notre propre CI sur un Jenkins pour tester plein de SGBDR et nous utilisons Travis pour que les contributeurs externes puissent tester leur pull requests en avance.

    Donc uniquement par économie pour RH. Je suis sincèrement désolé pour RH. J'espère qu'IBM tiendra le coup.

    L'Open Source, ça a une définition précise.

    Celle de l'OSI c'est ça ? Mais ici même tu trouvera pleins de gens qui se battent sur cette définition (zenitram est d'ailleurs un habitué de la chose), tu trouvera même des gens utiliser le terme "Open Source" pour des choses qui n'ont pas grand chose à voir avec la définition de l'OSI. Comme quoi.

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

  • [^] # Re: Ça s'entend...

    Posté par  . En réponse au journal Travis CI : aimer le libre (pour se faire connaître), mais pas/plus trop. Évalué à -3.

    Imaginons que tu ne connais pas (admettons que tu ne te renseigne pas et défend sans connaître) : pour pouvoir utiliser Travis CI il faut mettre un fichier portant le nom de la marque dans la racine de ton projet. Impossible (à ma connaissance du moins) de ne pas afficher le nom. --> panneau publicitaire pour tous les projets l'utilisant (pas pour rien que GitHub fait pareil maintenant… Ils en trouvent une utilité alors même qu'ils ont déjà leur nom à beaucoup d'endroits sur la page de projet; oui l'utilité peut être de ne pas donner de visibilité à un concurrent).

    Et les fichiers c utilisent l'extension .c pour faire la pub du langage et pour utiliser make tu dois créer un fichier makefile, encore en de la pub. Ça n'est strictement rien et c'est plutôt une bonne pratique pour pouvoir justement faire ta migration ou utiliser un autre service sans risquer d'avoir de collision. Si tu compare ça, à GNU, Apache ou Eclipse qui pour être intégrer, tu dois préfixer le nom de ton projet par leur nom dans toute ta communication, ça c'est de la communication1. Là on parle d'ajouter un fichier caché à la racine de ton projet. Après libre aux projets de choisir de mettre un fanion pour dire que leur build travis est vert ou pas, mais c'est leur choix.

    Non ça n'est pas du marketing.

    tu fera un journal Caliméro à chaque fois

    Quand on n'a pas d'argument, on attaque la personne.

    Non c'est du comportement que je parle. Ça n'a rien à voir.

    Et pour CentOS, on verra, CentOS existait et donc pas/peu d'idée de faire pareil, mais il n'existe plus et ça se trouve un autre projet prendra le relai. Comme pour Travis en fait.

    C'est ce que je te dis. Tu ne prends pas soin de ta stack, très bien, mais du coup accepte que ça peut changer, qu'il va falloir régulièrement aller voir ailleurs, etc.

    En fait, des fois on peut aussi dire que les offres "gratuites" empêchent la concurrence ayant moins de moyens, toi tu fantasmes que c'est sens unique mais peut-être que sans l'offre gratuite de Travis ben Travis n'existerait juste pas faute d'offre intéressante et pas de pub des libristes qui auraient misé autre chose (gratuit ou pas)…

    C'est toi qui dis que c'est à sens unique, que le libre s'est fait utiliser. Par contre toi tu fantasme beaucoup sur l'honneur qu'on les services d'être utilisé par toi. Tu daigne leur donner de la visibilité.

    Il me semble que c'est travis qui a inventé le principe d'avoir la configuration de son build dans ses sources (il y avait peut être heroku qui utilisait ce principe là avant, mais c'était moins pour la CI que le déploiement). C'est une révolution pour toutes les CI (sous forme de services ou chez soit), ça aide vachement les alternatives à se créer.


    1. je ne critique pas cela, ils le font pour d'autres considérations. Par exemple pour Apache, c'est pour que la marque soit liée juridiquement à la fondation et qu'une entreprise ne puisse pas tout contrôler (oui CentOS c'est toi que je regarde). ↩

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

  • [^] # Re: Ça s'entend...

    Posté par  . En réponse au journal Travis CI : aimer le libre (pour se faire connaître), mais pas/plus trop. Évalué à 2.

    Ce n'est pas au libre de se soucier de la pérennité d'une offre mais à celui qui fait une offre, ne t'en déplaise.
    Merci d'éviter d'inverser les responsabilités.

    C'est à chaque projet de s'assurer de la pérennité de ce sur quoi il repose. C'est toi qui met les choses dans le mauvais ordre. Si tu ne t'y intéresse pas, il va se passer des choses qui ne te plaisent pas. Et ça marche aussi avec les logiciels libres, reposer sur des logiciels libres sans se soucier de l'état et de la pérennité de ses projets ça ne marche pas. Tu a l'air d'en faire un principe, moi je te montre comment ça marche. C'est comme ça que des gens se retrouve le bec dans l'eau avec Centos, c'est comme ça que travis se retrouve à tenter de trouver des financements, c'est comme ça qu'on se retrouve avec des colosses au pied d'argile qui tiennent sur une bibliothèque développé par un gars sur son temps libre.

    Tu ne veux pas t'en préoccuper très bien, tu fera un journal Caliméro à chaque fois. Les gens te veulent du mal, ils veulent profiter de toi, du libre, etc.

    Tu as profité de leur offre gratuite, c'est cool. Si tu veut te complaire dans le mode gratuit tu peut aller voir ailleurs. Soit content d'avoir eu une offre gratuit que tu as pu utiliser à loisir et dans quelques années, tu nous expliquera que celui que tu as choisi, il est tout méchant parce qu'il refuse de continuer à t'offrir une offre gratuite.

    Tu as l'air de considéré qu'être utilisé comme ils l'ont était est un honneur qui se suffit à lui même, cet honneur ne paie pas les machines, le temps CPU etc. Un énorme paquet de projets ont pu en profiter et je ne crois pas que tous ces projets se soient transformés en panneaux publicitaires pour autant.

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