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.
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).
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é.
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.
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.
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.
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.
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…
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)
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.
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.
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 :
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.
Ç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.
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.
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.
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.
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.
Je ne sais pas si ça aurait marché mieux, mais dire "je me fous des conventions" (qui permettent de faire ce que tu fais) puis reprocher aux logiciels de ne pas prendre en compte tes particularités c'est dommage.
Ces outils sont fait pour de la sécurité, ce n'est pas de la "dérive sécuritaire". Je ne connais pas snap, mais flatpack permet de modifier les droits sans outil supplémentaire https://docs.flatpak.org/en/latest/sandbox-permissions.html
Justement non. C'est tout mon argument. La justice ça ne consiste pas à venger les victimes. Je suis sincèrement désolé pour eux, mais c'est comme ça que ça marche. Ce ne sont pas de belles paroles c'est le fonctionnement de la justice. On cherche à ce que notre justice soit impartiale entre autre cela signifie que son jugement ne doit pas être pris sous le coup de l'émotion, que les droits des 2 partis doivent être respecter, etc.
Je t'arrête tout de suite. Si ça m'arrivait, je serais effondré et je souhaiterais probablement la mort du coupable, mais je ne veux pas vivre dans un pays ça serait le cas.
C'est le genre de choses qui est fait à bien plus haut niveau via des outils comme GNOME Tracker ou KDE Baloo. L'idée c'est d'aller plus loin. Comme tu va avoir la flemme de placer des labels manuellement (le label "type" le label "origine" etc) et tu risque d'utiliser doc/docs/document/documentation/documentations/spec/… ils vont pour toi te fournir des éléments de recherche variés dont une recherche fulltext dans le contenu (mais aussi les dossiers, les dates, les attributs étendus s'il y a). Jamais utilisé perso.
Je sais pas s'ils s'intègrent aux sélecteurs de fichiers par contre.
On peut quand même critiquer les valeurs par défaut.
AMHA il est plus simple de situer le problème que de faire converger vers une réponse. Reprendre un HFS par utilisateur a au moins le bon goût de s'appuyer sur un autre standard largement accepté.
Du coup pourquoi les distribs décident t'elles de maintenir le bordel à l'ancienne?
Demande à ta distrib', je vois 3 options :
personne ne s'en est occupé
ils n'ont pas de consensus
ils trouvent qu'il y a trop de logiciels qui ne le respect pas pour le faire
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . En réponse au lien Flatpak is not the future et pourquoi l'auteur pense qu'on devrait développer pour GTK3 et pas GTK4. Évalué à 2.
gtk n'est pas un succès ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . En réponse au lien Flatpak is not the future et pourquoi l'auteur pense qu'on devrait développer pour GTK3 et pas GTK4. Évalué à 2.
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.
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
[^] # Re: fork
Posté par barmic 🦦 . En réponse au lien Pétition de Mozilla pour empêcher la France d’obliger les navigateurs tels que Firefox à censurer . Évalué à 5.
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
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . En réponse au lien Flatpak is not the future et pourquoi l'auteur pense qu'on devrait développer pour GTK3 et pas GTK4. Évalué à 1.
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
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . En réponse au lien Flatpak is not the future et pourquoi l'auteur pense qu'on devrait développer pour GTK3 et pas GTK4. Évalué à 2.
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
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . En réponse au lien Flatpak is not the future et pourquoi l'auteur pense qu'on devrait développer pour GTK3 et pas GTK4. Évalué à 1.
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
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
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . En réponse au lien Flatpak is not the future et pourquoi l'auteur pense qu'on devrait développer pour GTK3 et pas GTK4. Évalué à 2.
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
Pardon je parlais des utilisateurs de la bibliothèque gtk. Personne n'avait encore parlé des utilisateurs finaux donc ça me paraissait clair.
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
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . En réponse au lien Flatpak is not the future et pourquoi l'auteur pense qu'on devrait développer pour GTK3 et pas GTK4. Évalué à 2.
Du coup on passe du point de vu du développeur d'application à l'utilisateur final.
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.
Qu'est-ce que ça change aux utilisateurs finaux ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . En réponse au lien Flatpak is not the future et pourquoi l'auteur pense qu'on devrait développer pour GTK3 et pas GTK4. Évalué à 1.
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.
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.
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
[^] # Re: Flatseal
Posté par barmic 🦦 . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. Évalué à 0.
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
[^] # Re: fork
Posté par barmic 🦦 . En réponse au lien Pétition de Mozilla pour empêcher la France d’obliger les navigateurs tels que Firefox à censurer . Évalué à 10.
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
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . En réponse au lien Flatpak is not the future et pourquoi l'auteur pense qu'on devrait développer pour GTK3 et pas GTK4. Évalué à 2.
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
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . En réponse au lien Flatpak is not the future et pourquoi l'auteur pense qu'on devrait développer pour GTK3 et pas GTK4. Évalué à 3.
Ce que tu dis n'a aucun sens.
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 ?
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 :
Je ne me permettrais pas d'émettre d'hypothèse.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'histoire se répète
Posté par barmic 🦦 . En réponse au lien Flatpak is not the future et pourquoi l'auteur pense qu'on devrait développer pour GTK3 et pas GTK4. Évalué à 3.
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
[^] # Re: Flatseal
Posté par barmic 🦦 . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. Évalué à 3.
Ç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
[^] # Re: Flatseal
Posté par barmic 🦦 . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. Évalué à 6.
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
[^] # Re: Dériveur
Posté par barmic 🦦 . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. Évalué à 3.
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
[^] # Re: Dériveur
Posté par barmic 🦦 . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. Évalué à 3.
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
[^] # Re: dossiers xdg-user-dirs
Posté par barmic 🦦 . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. Évalué à 4.
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
[^] # Re: dossiers xdg-user-dirs
Posté par barmic 🦦 . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. Évalué à 4.
Je ne sais pas si ça aurait marché mieux, mais dire "je me fous des conventions" (qui permettent de faire ce que tu fais) puis reprocher aux logiciels de ne pas prendre en compte tes particularités c'est dommage.
Ces outils sont fait pour de la sécurité, ce n'est pas de la "dérive sécuritaire". Je ne connais pas snap, mais flatpack permet de modifier les droits sans outil supplémentaire https://docs.flatpak.org/en/latest/sandbox-permissions.html
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: hans Reiser bientôt libérable
Posté par barmic 🦦 . En réponse au journal Bientôt un nouveau système de fichier pour Linux . Évalué à 2.
Justement non. C'est tout mon argument. La justice ça ne consiste pas à venger les victimes. Je suis sincèrement désolé pour eux, mais c'est comme ça que ça marche. Ce ne sont pas de belles paroles c'est le fonctionnement de la justice. On cherche à ce que notre justice soit impartiale entre autre cela signifie que son jugement ne doit pas être pris sous le coup de l'émotion, que les droits des 2 partis doivent être respecter, etc.
Je t'arrête tout de suite. Si ça m'arrivait, je serais effondré et je souhaiterais probablement la mort du coupable, mais je ne veux pas vivre dans un pays ça serait le cas.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: À quand un rangement thématique ?
Posté par barmic 🦦 . En réponse au lien $HOME, Not So Sweet $HOME. Évalué à 3.
C'est le genre de choses qui est fait à bien plus haut niveau via des outils comme GNOME Tracker ou KDE Baloo. L'idée c'est d'aller plus loin. Comme tu va avoir la flemme de placer des labels manuellement (le label "type" le label "origine" etc) et tu risque d'utiliser doc/docs/document/documentation/documentations/spec/… ils vont pour toi te fournir des éléments de recherche variés dont une recherche fulltext dans le contenu (mais aussi les dossiers, les dates, les attributs étendus s'il y a). Jamais utilisé perso.
Je sais pas s'ils s'intègrent aux sélecteurs de fichiers par contre.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ce troll de compèt c’est pour vendredi ?
Posté par barmic 🦦 . En réponse au lien $HOME, Not So Sweet $HOME. Évalué à 2.
Effectivement j'ai confondu 58 et 48
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: 🙄
Posté par barmic 🦦 . En réponse au journal Sortie de darktable 4.4.0, non, 4.4.1, pardon, 4.4.2. Évalué à 0.
☺️
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ce troll de compèt c’est pour vendredi ?
Posté par barmic 🦦 . En réponse au lien $HOME, Not So Sweet $HOME. Évalué à 5.
AMHA il est plus simple de situer le problème que de faire converger vers une réponse. Reprendre un HFS par utilisateur a au moins le bon goût de s'appuyer sur un autre standard largement accepté.
Demande à ta distrib', je vois 3 options :
Mais il peut y avoir d'autres raisons.
Au plaisir de le lire
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll