barmic 🦦 a écrit 5214 commentaires

Et vous, qu’en pensez-vous ?

C'est un risque que le développeur de SQLx a pris. Il le savait. Et toi tu a priorisé le fait que ton logiciel se comporte comme avant plutôt que de t'adapter aux changements la bibliothèque.

Que veut-tu qu'on te dise ? C'est tes choix. Si ça te pose un cas de conscience ne le fait pas, si tu veux le faire fais-le.

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

La partie où il affirme que gtk3 est abandonné alors que le support existe toujours ?

Oú il préfère penser à un complot plutôt que de chercher la vérité ?

Celui où il fait des procès d'intention ?

Celui où il préfère tordre le bras des développeurs gtk et des mainteneurs de distribution plutôt que de simplement choisir un toolkit graphique qui lui convient mieux ?

C'est de cette partie là que tu parle ?

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

La bonne pratique maintenant c'est d'utiliser browserlist qui permet de cibler les navigateurs (voir dans la partie bests practices).

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

Grand remplacement

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

Je ne vois pas de contre argument. Tu affirme des choses. Tu fais des parallèles qui n'existent que dans ta tête. Tu esquive quand tu semble être au pied du mur. Et tu t'attaque à ma personne quand tu ne sais plus quoi répondre.

Parce qu'inventer des concepts et donner à des bibliothèques des responsabilités qu'elles n'ont pas, c'est facile mais ça ne va pas t'aider si effectivement, tu cherches à faire du maintiens long-terme. Passer plus de temps à comprendre l'écosystème que tu utilise et moins de temps à se morfondre que les autres ils font tout pour t'embêter sera bien plus bénéfique à pour résoudre tes difficultés de support.

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

Arrête avec Angular, tu mélanges cadriciel de haut niveau et API de base, je te l'ai déjà dit plusieurs fois :-)

Répéter des bêtises ne les rendra pas plus vraies pour autant. Gtk est une bibliothèque au même titre que vue par exemple (dont le passage de la 2 à la 3 à demandé à tout récrire). Gtk n'est pas une api de base de linux. C'est l'un des différents toolkit graphique au même titre que tcl ou qt. Xlib ou xcb sont déjà plus incontournables en étant la partie cliente des serveurs graphiques là on est dans des api de base.

Mais surtout surtout. La critique c'est d'avoir à récrire son application quand tu dois le faire si c'est à cause de ton langage, d'une "api de base", d'une bibliothèque, etc n'a pas vraiment de différences. C'est la fréquence de tes réécritures qui est un problème. Ah ce petit jeu tu aura pu utiliser gtk2 20 ans et plus encore car elle est toujours dans debian et rhel.

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

gtk n'est pas un succès ?

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

une API de base qui casse, ton programme ne se lance même plus

Elle ne change pas par magie. Tu met à jour gtk et paf. Je te propose d'essayer de prendre un projet angular pré-ivy et de le mettre à jour ou de changer de version majeure de bootstrap pour voir si ça continue de se lancer.

un framework de haut niveau qui casse, tu peux vivre longtemps avec une vieille version tant que les API de base qu'il utilise ne bouge pas.

Pour le moment tu en est à pouvoir vivre 21 ans avec gtk2.

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

Le premier évènement qui est généralement associé au mouvement des gilets jaunes c'est la pétition de Priscillia Ludosky. Ce n'est pas cette pétition qui a créé le mouvement. C'est toujours une succession de hasard qui amène un mouvement à prendre de l'ampleur, mais ça a fait parti de ce qui l'a créé (on parle généralement de cette pétition et des vidéos d'Éric Drouet et de Jacline Mouraud).

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

Oui mais c'est à toi que je répond.

Quand je dis que ce serait bizarre que les développeurs fuis la volatilité pour avoir la même chose sur le web, me dire que eux au moins même les trucs moribonds ont encore un peu de développement. C'est pareil pour gtk qui lui a du coup un support qui est plus vieux que Phoenix ne soit lancé.

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

Dire que c'est un choix, le répéter ad nauseam en ignorant sciemment que tout choix se fait dans un contexte et dire plus haut (ce n'est pas toi mais ça fait partie de la discussion) qu'ils n'en n'ont rien à faire, contribue à pousser ce genre d'idée.

Tu ne questionne pas le pourquoi est-ce qu'ils cassent la compatibilité, d'où est-ce que ça vient, non tu me présente comme un choix indépendant de toute contrainte technique. Au mieux tu dis que gnustep le fait ils doivent pouvoir le faire comme si les 2 bibliothèques avaient les mêmes objectifs/scopes/projets.

Pour ta pique personnelle, j'essaie de ne pas critiquer les personnes mais les discours. On pourrait discuter pour devnewton, mais c'était une manière de parler du fameux rasoir d'ockham (je conviens que ça n'était pas parfait). Tu remarquera l'ironie de demander un débat sain, juste après avoir lancer une attaque ad hominem.

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

Combien de ces frameworks webs ont été complètement abandonnés et ne reçoivent plus de support?

Comme je l'ai dis une bonne moitié sont soit abandonnés soit en passe de l'être depuis un certains temps. Ils sont considérables comme de la dette technique et peuvent te claquer dans les doigts du jour au lendemain. Ne pas avoir de plan de migration (et la commencer), serait vraiment s'acheter des problèmes.

Parce que sinon à se train là continue d'utiliser gtk2, elle est toujours disponible dans les distributions (debian ou arch par exemple) et la dernière version n'a que 2 ans

React a 10 ans et sort des versions majeures régulièrement, qui introduisent des breaking changes mais qui n'imposent pas forcément de tout réécrire.

Je ne connais pas bien React, mais pour angular ils ont changé plusieurs fois de compilateurs et c'est loin d'être sans conséquence le dernier en date, Ivy, est arrivé par défaut avec la version 9 de début 2020.

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

Tu es le seul à parler d'irrationnalité.

J'ai mis un moment sur les comportement décrit. Les développeurs d'application continueraient d'utiliser gtk car les développeurs de gtk les braqueraient. Les développeurs de gtk prendraient casseraient la compatibilité par inconvenance presque par plaisir et n'auraient rien à faire des conséquences. etc

Soit dit en passant, tu mentionnes les utilisateurs.

Pardon je parlais des utilisateurs de la bibliothèque gtk. Personne n'avait encore parlé des utilisateurs finaux donc ça me paraissait clair.

Les gens s'en contrecarrent que kde plasma est en QT4/QT5 ou QT6.

Alors pour le coup je pense que oui parce que QuickTime sur Mac et KDE sur linux c'est pas vraiment la même chose. Mais on est complètement d'accord, pourquoi en avoir du coup fais mention quand on parle de web ?

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

Note que du côté de l'utilisateur final

Du coup on passe du point de vu du développeur d'application à l'utilisateur final.

les autres frameworks sont abandonnés par leurs mainteneurs/devs

De ce que j'ai cité à la va vite tu en a tout de même une petite moitié qui sont soit abandonnées soit dans un état de maintenance à peine en vie et ça ne compte pas les bibliothèques qui ajoutent du bruit à ça comme moment par exemple.

tous les developeurs abandonnent les autres du jour au lendemain pour réécrire leur app sur celui à la mode.

Qu'est-ce que ça change aux utilisateurs finaux ?

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

Tu mélanges les couches. Le "socle" html/js/css est au même niveau que gtk et est très rétrocompatible.

Ou c'est l'assembleur du web ?

Ce qui est reproché à gtk c'est d'obliger les développeurs à réécrire tout ou parti au fil des versions. Si tu n'utilise pas de manière vanilla la stack web tu aura le même problème avec tes frameworks et toolkit. C'est bien beau que l'assembleur soit le même mais il n'est pas réutilisable d'une version à l'autre. Donc les développeurs ne sont pas plus avancés.

Si les gens utilisaient

Tu raisonnes souvent par supposition :-)

J'utilise des tournures qui mettent en évidence que j'en fais. Parce que ni toi ni moi n'avançons d'éléments plus concret.

La rétrocompatibilité est capitale dans le succès de pleins de technos (html/js/css, java, postgresql, android, opengl…).

Et x86, amd64,… La critique porte sur la qualité de vie des développeurs. Le développeurs web qui utilise la stack web vanilla n'aura pas de problème dès qu'il utilise un truc genre bootstrap ça va devenir coton. Pour java et postgresql ça va, pour android par contre le sdk a pas mal changé et maintenant google te pousse à aller vers kotlin pour se débarrasser de leur ersatz de java, pour opengl pendant longtemps c'était déjà la compatibilité qui était compliquée…

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

La majorité des utilisateurs que je vois, les mises à jour les emmerdent royalement et s'ils ont la possibilité de le faire il les annulent. Seule la peur d'avoir un système pas sécurisé les incite à le faire, et encore. Ce n'est pas pour rien que des boites comme Microsoft et les IT des entreprises rendent les maj de plus en plus difficile à annuler/réagender.

Les utilisateurs que tu vois, ils se plaignent de leur navigateur qui fait des mises à jour jour quand il veut sans leur demander leur avis silencieusement ?

J'ai l'impression que c'est de la procrastination qui les fait retarder, que c'est jamais le bon moment, que c'est toujours quand il y a un truc en cours et que tu ne sais pas combien de temps ça va te prendre ni si tu va pas perdre ce que tu es entrain de faire.

Bref que le problème n'est pas une question de vouloir ou non la dernière version (la plupart te diraient qu'ils veulent la dernière), mais le processus de mise à jour qui fait peur (et de la procrastination)

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

je ne signerai évidemment pas cette pétition, bien entendu si les pétitions servaient à quelque chose, ça serait interdit… Vous croyez réellemment que le gouvernement va se dire "mince, y'a 4000 geeks qui sont fachés des dérives possibles, on va faire machine arrière et limiter nos possibilités de censure" ?

Ce n'est pas à ça que ça sert, ça n'est pas comme ça que ça marche.

Une pétition n'est pas un référendum d'initiative populaire, c'est un outil médiatique. Il permet d'un côté de faire parler et d'un autre côté pour ceux qui signe de se compter et d'avoir une idée du mouvement. C'est un autre outil dans l'arsenal des grèves, manifestations et happenings comme on voit régulièrement maintenant. Des outils politiques qui mènent servent la contestation. Pas une manière de court-circuiter les institutions.

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

Affirmation sans preuve peut être nié sans argument et tout ce qui utilise un framework par dessus (incluant les bootstrap, less, sass, tailwind…) ne rentre pas dedans vu qu'il faut les maintenir. Si les gens utilisaient réellement vanilla la stack web, on ne parlerait pas de javascript fatigue. C'est le seul écosystème où le problème est devenu suffisamment pesant pour qu'ils l'identifient comme ça.

D'ailleurs tu ne me fera pas croire quelque chose au quel tu ne crois même pas toi-même puisque tu appel de tes vœux un "low javascript"

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

Ce que tu dis n'a aucun sens.

Résultat, tout le monde fait des applis web.

Parce que sur le web c'est mieux avec jquery, dojo, coffeescript, dart, angularjs, angular, react, vue, svelte,… ? Les développeurs fuient le manque de rétrocompatibilité pour encore plus de changements ?

C'est soit gtk soit le web ? Les autres toolkit graphiques sont vraiment si mauvais qu'ils ne sont pas une option ?

Les développeurs de toutes les plateformes font du web, c'est quoi gtk est entraine avec lui toute la profession ?

La stratégie de l'échec?

Quand on suppose qu'autant de gens ont des comportements irrationnels (à la fois les développeurs de gtk et leurs utilisateurs voir tout développeur ?) c'est :

• soit qu'on a un angle mort
• soit qu'on est un gros troll qui pue
• soit qu'on est soit-même irrationnel

Je ne me permettrais pas d'émettre d'hypothèse.

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

Si GTK casse la compatibilité tous les 4 à 10 ans c'est par choix, pas par obligation. Un choix qui a sans doute ses avantages mais personne ne leur mets un flingue sur la tempe en leur disant de tout casser.

C'est probablement plus par nécessité. Casser la compatibilité c'est devoir de nouveau documenter, faire du support en plus, se prendre un paquet de remarques dont les plus bruyantes seront les plus offensantes, se tenir une réputation,… Vu le peu de monde qui tiennent la baraque ils ont parfaitement conscience de ce que ça entraîne et pleins de gens prennent sur eux de leur rappeler régulièrement.

Mais ils ont un ensemble de fonctionnalités et d'autres critères qui entrent en ligne de compte. Est-ce qu'il faut pour autant être outrancier comme on le voit plus haut en disant qu'ils n'en ont rien à faire ?

Comme tu le dis, gnustep fait mieux et je suis sûr que tcl/tk reste compatible avec les versions sorties sous Napoléon. Si personne ne met de gun sur la tempe des développeurs de gtk, personne ne met de couteau sous la gorge de leurs utilisateurs pour qu'ils continuent de l'utiliser. C'est qu'il doit bien avoir une qualité ou deux.

Tout projet propose un ensemble, des fonctionnalités, un support, des performances, un maintient dans le temps, etc. Juger sur un critère unique en ignorant la vue d'ensemble est par nature biaisée.

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

Ça se comprenait bien, mais il fallait que je bidouille mon xorg.conf. J'avais des parties commentées que j'(dés)activais en fonction de l'écran que je branchais (voir j'ai passé uné époque avec le driver nv dans certains cas et les propriétaires nvidia dans d'autres).

Aujourd'hui je branche un écran, éventuellement je lance arandr pour choisir où je situe l'écran, c'est terminé.

Il y a l'un des 2 situations où je ne me sens pas obligé de mettre des guillemets pour dire que ça marche.

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

Perso j'ai connu Slackware, avec ses paquets TGZ et les installations à faire à coup de configure/make/make install : je ne peux pas dire que ça marchait mieux ou moins bien qu'avant : c'était différent. Mais au final j'arrivais mieux à m'en sortir avant parce que je n'avais pas cette sensation de perte de contrôle que j'ai aujourd'hui. Les systèmes ont perdu la souplesse qu'ils avaient il y a quelques années.

La nostalgie brouille ta vision. Il n'y a aucun débat sur le fait que ça marche bien mieux aujourd'hui qu'avant. Avant on se posait pleins de questions avant d'acheter le moindre matériel, maintenant ce qui ne marche pas immédiatement est l'exception.

Quant à cette sensation de perte de contrôle, ma théorie c'est que ça vient du fait que ça marche. Il y a 15 ans tu n'aurait pas posté ce journal, tu aurais bouquiné tout ce que tu aurais pu et tu aurait trouvé les solutions qui t'ont étaient présenté dans les premières réponses et quand quelque chose ne marchait pas tu prenais sur toi.

D'une part l'habitude d'aller au fond des choses s'est perdu parce qu'on en a plus rarement besoin (et pour certaines choses qui sont plus sophistiquées mais rien d'insurmontable pour une moule).

D'autres par comme tout marche, on est moins indulgent quand quelque chose ne marche pas.

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

C'est une question super intéressante et oui c'est possible. Tu peux développer une application avec des méthodes formelles. L'ensemble du comportement sera spécifié. C'est chère et pas très amusant.

Mais plus simplement, ça dépend de ce que tu entend par stable, par performant et par mis en prod ;)

Tu peux diluer la mise en prod pour fortement limiter l'impact d'un éventuel problème.

Et tu as tout un tas de choses pour t'aider à être stable et performant des outils de benchmark, de fuzzing, tu as la possibilité d'utiliser des conteneurs pour faire des simulation d'attaques byzantines ou de différents type de problème réseau,… C'est généralement plus le manque d'investissement (ou une organisation problématique) que des limitations qui empêchent d'aller plus loin.

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

La notion de mise en prod n'est pas vraiment du fait des projets upstream c'est le choix des distributions, c'est même leur principal travail. C'est un grief a faire à ta distribution de faire tel ou tel choix.

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

D'ou l'intéret d'un paramétrage par défaut qui peut être surchargé par l'administrateur ou l'utilisateur en cas de besoin.

C'est exactement l'objet des standards dont tu dis te foutre sauf que ce n'est pas forcément l'administrateur mais aussi l'utilisateur qui peut le surcharger.

Encore une fois je ne sais pas si snap prends correctement en charge les standards freedesktop, mais c'est ce qu'il devrait faire et ça permettrait d'avoir la même configuration pour snap ou pour tout autre logiciel du même acabit.

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