Psychofox a écrit 11027 commentaires

La vérité c'est qu'ils s'en foutent d'avoir la dernière version, ils ne voient en général pas les nouvelles fonctionnalités, n'en ont rien à carrer de bugs qu'ils n'ont jamais rencontré (c'est pas parce qu'un bug existe qu'il touche tout le monde ou cas de figure) et si l'UI change un peu ils râlent (même s'ils finissent par s'y faire et à aimer ce changement sur le long terme et à ne pas vouloir revenir en arrière).

À part les power users qui sont une fraction des utilisateurs, les gens ne réclament pas de nouvelles versions et n'utilisent qu'une fraction des fonctionnalités des logiciels qu'ils utilisent.

Pourtant ca se passe trop mal sur Android avec les app distribuées sur le Play Store.

Ce n'est pas de ça que je parle.

Je sais pas, moi quand je fixe un bug je suis content de savoir que mes utilisateurs arrêtent de pester. A vrai dire, c'est même la seule satisfaction pour corriger les bugs, parce qu'intellectuellement en général c'est pas le kif. Si tu fixes un truc, mais la correction n'est jamais distribuée, c'est quand même démotivant non ?

Ce n'est pas non plus de ça que je parle.

Je dis juste que les utilisateurs, en général, ce ne sont pas eux qui réclament une nouvelle version.

Les couches graphiques, que ce soit le matériel comme la gestion sous Linux (genre l'arrivée de Wayland) a nécessité de gros ajustements. De la même façon que OpenGL a été mis au placard pour privilégier une nouvelle API : Vulkan.

Je serais tenté de dire que l'appli n'en a rien a carer de ce qu'il se passe derrière. Le toolkit pourrait évoluer et supporter un nouveau type d'affichage comme wayland, du hdpi et d'autres joyeusetés tout en maintenant une API stable.

Par exemple GNUSTEP a ajouté le support de wayland, mais n'a pas changé de version majeure et tu n'as pas à faire un effort de réécriture/portage de ton appli pour les nouvelles versions.

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.

• Les 900 Mo, c'est pas pour la calculatrice mais pour "la plateforme" (800 Mo pour GNOME 44)
• Il existe un système de dé-duplication dans Flatpak

remarque uniquement valable si tu utilises une distro immutable style silverblue, où que tu as installé le minimum sur ta distrib (un window manager à la limite mais pas un bureau complet). Autrement t'as beau avoir de la dedup, elle ne se fait qu'entre les solutions flatpak, tu te coltines et les libs, toolkits, frameworks de ton bureau, et ceux de flatpak.

Et j'ajouterai qu'en général les gens qui tiennent à avoir des paquets récents…choisissent des distribs qui fournissent des paquets récents, soit rolling release où distribs à rythme de release d'environ 6 mois. Ils ne sont pas sur ubuntu LTS ou rhel 7.

J'ai testé kiwix desktop en version packagée par Fedora, flatpak et la version windows, elles sont exactement à la même version.

Ben ton cas est celui d'une appli que l'on pourrait qualifier d'appli métier et qui a peut-être des critères différents. Mais cette idée de la quête de la dernière version par l'utilisateur final relève plus selon moi du fantasme de développeur qu'autre chose[1].

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.

[1] Probablement parce que les devs sont sujet au prisme des power users qui ouvrent des tickets ou gueulent sur les forums là où une majorité silencieuse des utilisateurs va pester sur un bug devant son écran et passer à autre chose.

Et donc tes utilisateurs de Corée du Nord téléchargent les nightly tous les matins?

C'est gens là, tu peux pas leur dire d'utiliser le paquets de leur distrib, de passer par wine

Ben avant d'écire mon commentaire précédent, j'ai quand même testé hein. Sur mon linux j'ai cliqué sur la version windows, décompressé le zip et double-cliqué kiwix-desktop.exe et ça l'a démarré comme n'importe quelle appli linux. J'ai comparé l'app au paquet fedora et à flatpak, t'as zero différence visible entre les 3 et elles sont toutes dans la même version.

Et au final, c'est la version flatpak qui a été la plus compliqué à utiliser car tu dois utiliser flatsral pour lui permettre de lire les fichiers dans un répertoire arbitraire du disque.

Du coup j'imagine que vous avez plein d'opérateurs déployés en afrique, amazonie et en corée du nord pour former les gens à utiliser flatseal =]

Mais on fait quand même un binaire pour que les gens normaux (pas les gens qui participent à cette discussion ici) puisse utiliser kiwix sans avoir à tout recompiler.

Ben justement, les gens normaux utilisent les paquets de leur distrib il me semble, non?

Au final je me demande pourquoi vous vous emmerdez à faire un appimage ou un flatpak si votre métier est développeur et que vous ne voulez pas gérer toutes les distribs. Vous avez une version windows. Ça vous fait déjà un binaire universel qui va tourner sous tous les linux, macOS, Haiku, reactos, FreeBSD, NetBSD, DragonflyBSD, même Hurd, sans à vous préoccuper de la libc, des différentes versions de QT, etc.

Et ceux qui veulent absolument la version native prennent le package de leur distrib.

Je crois que vu qu'ils ne connaissent pas la signification normale de "algorithme", ils lui donnent un sens nouveau qu'ils comprennent comme programme qui fait du ciblage à partir des historiques de connection de l'utilisateur.

Mais la recette de build doit pas vraiment changer d'une release à l'autre non?

J'ai l'impression que des fois vouloir avoir un binaire qui satisfait à toutes les distribs est plus compliqué que profiter des infras comme le opensuse build service qui te permet de faire des paquets individuels pour toutes les grandes distribs.

Je parle surtout de question d'échelle. Les automobiles ont pris du poids en 20 ans. Leur poids et leur consommation d'essence n'a pas été multiplié par 150 par contre. La contrainte à la réparation c'est surtout sur la filière des garages multimarques que ça pose problème, moins sur l'utilisateur final. Et c'est surtout un business model. Les voitures se réparent toujours, faut juste passer à la caisse pour avoir droit au manuel.

Alors oui des sales pratiques ça existe dans toutes les industries mais en général on essaie de vendre un produit dont les nouvelles caractéristiques plaisent à l'utilisateur…

Alors on va me dire, si c'était si bien avant, pourquoi les utilisateurs n'utilisent pas encore leur vieux pentium 233mhz d'il y a 25ans. La vérité est que beaucoup le feraient si les mises à jour logiciels n'avaient pas rendu leur machine de plus en plus lente. La plupart des gens remplacent leur PC parce qu'ils y ressentent une lenteur qu'il n'avait pas au début, pas parce qu'ils ont besoin de fonctionnalité supplémentaires.

J'ai eu la même discussion avec un developpeur d'un logiciel, leader dans son domaine et il était aussi affaré et honteux de l'état de l'art dans son industrie/domaine. Alors certe dans certains domaines on fait des trucs qu'on ne faisait pas du tout avant, traitement d'image, vidéo, son, deep learning… Mais ce qu'on faisait déjà bien à l'époque, on est incapable à niveau de fonctionnalité égale de faire aussi économe, même pour des outils qui ne nous rendent pas plus productifs qu'avant à moins de réutiliser les languages et toolkits de la même époque. On arrive à justifier qu'une calculatrice ou un éditeur de texte doive peser plusieurs dizaine voire centaines de MB alors que la même chose tenait dans quelques centaines de KB il y a quelques années.

Ce même développeur m'avouait qu'en dehors de son travail il developpait des petits logiciels sur son temps libre sur un vieux windows 2000 ou XP avec un visual studio d'époque car ça lui permet d'avoir un IDE + documentation complète en locale et que ses logiciels pesaient beaucoup moins lourd qu'avant et fonctionnaient sur toutes les plateformes grace à wine[1]. Et il utilisait le moins possible de libs et frameworks clés en mains qui te permettent de gérer le vol d'une fusée jusqu'à Jupiter tout gérant la domotique de ta mason alors que toute ce que t'as besoin c'est d'une petite fonction de hashage [2].

[1] alors oui certe, si on veut décompter le poids totale de son appli autre chose qu'un windows, faut compter wine/libwine, qui de nos jours est devenu aussi assez gros.
[2] j'exagère à peine

À part ça comment fait firefox, qui ne fait pas du toute dans l'application légère, pour proposer des binaires qui marchent sur n'importe quel distrib, dans une tarball de 73MB qui en fait 234MB décompressé sans passer par appimage ou flatpak et pourquoi ça pose autant de problème à l'équipe de Kiwix de faire la même chose?

C'est justement ce qu'on lui reproche*. Ça sert à faire un gros binaire et au dev de faire le boulot pour s'assurer que ce binaire fonctionne correctement.

Le monde du developpement logiciel est quand même incroyable.

C'est une des seules industries où le fabricant te justifie de créer des produits inférieurs pour l'utilisateur parce que c'est plus commode pour lui.

Si les autres industries faisaient pareil, on aurait des réfrigérateurs qui font des bruits de bombardier et font vibrer toute la cuisine, une voiture individuelle pèserait le poids d'un 38 tonnes et consommerait du 100L au 100km, un vélo serait tellement lourd qu'on ne pourrait pas monter une côte avec, une télé…ben elle ne serait pas plate déjà, pour un écran de 100cm tu aurais 3-4 mètres de profondeurs. Et ils seraient en train de pleurnicher comme des développeurs oh vous savez intégrer tous ces composants dans quelque chose de compact c'est compliqué, pis si faut prendre en compte toutes vos contraintes de comfort utilisateur on ne va pas y arriver, gnagnagni gnagnagna…nan on sait mieux que vous tenez on va vous vendre cette grosse merde énorme, lente, énergiquement inefficace.

GIMP est scriptable…

oui je sais mais tu vas rarement utiliser les fonctionnalité de scripting pour dessiner, faire des sélections manuelles, etc.

Nous sommes d'accord.

zut, il y'a les devs COBOL/TK et Fortran/motif qui moinssent. On les a oublié.

Je n'ai jamais lu la doc de Gimp hein. Et tu n'as surement jamais utilisé photoshop ou aucun autre logiciel métier si tu penses que tu ne te retrouves jamais dans les situations mentionnée où tu ne comprends pas ce qu'il se passe. Même sur des trucs très très grand public comme OFfice, vas éditer un powerpoint ou un document word remplis de captures d'écrans réalisé par une autre personne, tu vas aussi rire un bon coup si tu crois qu'en quelques clics tout va s'aligner comme tu l'imaginais au début. C'est essentiellement une des tarres du concept WYSIWYG et la plupart des logiciels ont leurs souçis à ce niveau. Le truc c'est qu'à part de l'édition basique typique de ce que tu ferais avec imagemagick, c'est assez compliqué d'étiter des images en WYSIWYM, à part pour les générer via deep learning.

Alors qu'en fait depuis tout ce temps, il fallait simplement utiliser TK et si possible avec un langage stable comme tcl ou perl5[1] qui ne cassent pas la compatibilité tous les 4 matins.

Le problème c'est que seuls les dinosaures continuent à les utiliser.

[1] la communauté a même préféré changer le nom de perl 6 pour que perl reste perl

On a déjà adopté cette démarche avec Pulseaudio par le passé et en ce moment avec Wayland.

À côté pipewire c'est passé crème non?

Bon le fait que l'auteur ait travaillé avec les auteurs de pulseaudio, jack et ardour pour assurer la compatibilité n'y est sans doute pas pour rien.

…l'article est de 2021.

Certains sont contre:

https://linuxfr.org/users/psychofox/liens/flatpak-is-not-the-future-et-pourquoi-l-auteur-pense-qu-on-devrait-developper-pour-gtk3-et-pas-gtk4

Ouais j'entendais par là ce qui est proposé par défaut via l'installation de base, pas le support via le paquet snap.

Beaucoup de distribs installent le backend flatpak pour kde discover et gnome software via l'install du bureau par défaut. Peu le font pour les snaps il me semble.

Il existe firejail pour sandboxer une application avec les cgroups.

Comme souvent le wiki archlinux est très complet à ce sujet.

Après il ne faut pas prendre le sandboxing pour de la poudre magique. Ça permet de limiter les privilèges d'une application, ça permet d'isoler l'une de l'autre, mais au final si tu lui donnes accès à tes données, l'application en fait ce qu'elle veut, et d'autant plus si elle a accès à tes données, et au réseau.

Du coup c'est pas une raison pour faire tourner tout et n'importe quoi.