devnewton 🍺 a écrit 8778 commentaires

Si tu es persuadé que Vue et Gtk c'est pareil, que coder une appli avec xlib c'est la meme chose qu'utiliser html/js/css et que la rétrocompatibilité n'est pas importante, forcément tout va bien.

Les gens qui maintiennent des applis sur le long terme vivent dans un monde moins enchanté 🧙‍♂️.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

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

Gtk 2 sera maintenu jusqu'à 2044 ???

Je le croyais mort.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

J'ai pris plus loin d'autres exemples que le web (java, opengl, postgres…) qui montre qu'une bonne rétrocompatibilité fait beaucoup pour le succès.

Ce n'est bien sûr pas le seul critère de choix.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Si tu n'utilise pas de manière vanilla la stack web tu aura le même problème avec tes frameworks et toolkit.

Ce n'est pas du tout le même problème.

Encore une fois tu mélanges les couches:

• une API de base qui casse, ton programme ne se lance même plus ;
• 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 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…

Tu vois, tu reconnais que la perte de rétrocompatibilité est un problème :-)

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

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

Si les gens utilisaient

Tu raisonnes souvent par supposition :-)

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

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Tu peux faire plein de suppositions, mais html/css/js est aujourd'hui le "toolkit" le plus populaire et le plus rétrocompatible.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

personne ne met de couteau sous la gorge de leurs utilisateurs pour qu'ils continuent de l'utiliser.

En cassant la rétrocompatibilité de ton toolkit, tu pointes un fusil vers tes utilisateurs Marche avec moi ou casse toi faire des applis web.

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

La stratégie de l'échec?

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Mouais, je ne pense pas que l'éditeur ou développeur, en particulier pour un logiciel libre se lève un matin en disant "je vais limiter le contrôle des utilisateurs artificiellement"

Ben non c'est décidé au COMEX !

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Bien sûr qu'on demande plus de chose à l'affichage d'aujourd'hui, mais je réagissais à l'expression sensation de perte de contrôle qui est loin d'être d'une sensation, c'est une réalité, car tout est réellement plus complexe et que cette complexité vient avec des pertes de contrôle "normale" (on ne maîtrise plus tout de bout en bout, car il faut trop de temps pour tout comprendre), "anormale" (wtf pourquoi il faut autant de setup pour afficher un truc???) et "scandaleuse" (firmware GPU privateur, DRM dans le HDMI…)..

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

De la même façon que OpenGL a été mis au placard pour privilégier une nouvelle API : Vulkan

Gtk 4 dépends d'OpenGL, ça veut dire qu'il faudra le mettre au placard bientôt ?

https://docs.gtk.org/gtk4/overview.html

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Quant à cette sensation de perte de contrôle, ma théorie c'est que ça vient du fait que ça marche.

Ma théorie, confirmé par la pratique, c'est que la complexité de toutes les couches hardware/firmware/OS/softs a explosé.

Exemple:

• l'affichage avec DOS, une carte VGA et un peu d'assembleur : une page qui se comprends en 5 minutes ;
• l'affichage avec Linux, Wayland, un GPU et beaucoup de C: un document de 288 pages pour de nombreuses heures de lecture.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

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.

Un des seules industries avec le bâtiment (isoler les maisons? oh c'est chiant, on va leur mettre de la laine de verre premier prix facile à poser), l'agroalimentaire (c'est plus pratique avec ces pesticides, les gens survivront, faut bien mourir de quelque chose de toute façon), l'automobile (des voitures facile à réparer? non c'est plus simple qu'ils viennent dans notre garage certifié)…

C'est pareil dans les services publics (on va pas se faire chier à faire un accueil à l'école pour les parents, ils viennent juste 4 fois par jour, ils attendront les gosses sur le trottoir) et sans doute plein d'autres secteurs que j'oublie :-)

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

A ma gauche, je vois des outils comme appimage ou firejail qui font peu de choses, mais le font bien, mais demande aux applis un peu plus de code pour mieux s'intégrer aux distribs ;

A ma droite, j'ai Flatpak et Snap qui veulent tout faire et plus encore, mais le premier ne réponds pas à mon besoin (packager une appli java) et évolue très lentement, le second est privateur (côté serveur).

Peut être qu'on irait plus vite en comblant ce qui manque à gauche non?

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Chacun sa spécialité, moi je fais dans le retrogaming en ce moment : maintenir en vie des consoles qui ont 30 ou 40 ans, c'est pas rien niveau LTS !

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Appimage sert juste à générer un (gros) exécutable, il ne prends pas en compte l'intégration avec la distrib.

Il est même inutile pour les langages comme Go qui savent faire ça tout seul.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Et les gens qui ne disent rien vont juste cramer des années hommes à mettre à jour leurs applis parce que chez Gnome on s'en balec de la rétrocompatibilité.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Par curiosité, j'ai regardé où ça en était : empaqueter une application java compilée avec Maven semble possible via quelques bidouilles avec des limitations, mais rien d'officiel.

Mon dernier essai date de 2019.

Avec une évolution aussi lente, est-ce Flatpak réponds vraiment à des besoins impossible à gérer avec l'existant qui marche (appimage + sandbox) ?

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Et il fait aussi pousser les cheveux et revenir l'être aimé ?

Le premier test que j'en avais fait m'incite à la prudence 🐗, j'espère que ça a vraiment beaucoup évolué.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Si on pouvait éviter d'adopter une nouvelle fois une solution compliquée, mise en prod avant stabilisation et qui pose des soucis majeurs aux utilisateurs pendant des décennies avant de faire un peu semblant de marcher…

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

Je ne suis pas contre flatpak, mais qu'il revienne quand il sera mûr.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Appimage est vraiment une bonne solution pour gérer les paquets "de confiance hors distribution", car il n'essaie pas de faire plus que de l'empaquetage.

Le confinement des applications auxquelles on ne fait pas confiance devrait être pris en charge par une couche beaucoup plus "dure" que celles de snap/flatpak : si on ne fait pas confiance à une application, il faut la traiter comme malveillante :-)

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Je voudrais un PC portable avec Debian, un clavier et une souris sans fil, quatre manettes, un ecran de 60cm, 16 ports USB et une cafetière à grains.

Il doit rentrer un petit sac à dos, peser moins de 2kg et avoir 48h d'autonomie.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Avec une touffebleue fiable, on pourrait avoir un clavier/touchpad détachable.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Le problème d'une souris ou d'un clavier TouffeBleue, c'est qu'il faut un clavier/souris filaire pour le couplage et le dépannage…

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

C'était peut être trop ambitieux de vouloir des emplacements configurables…

Sinon il y a la technique du confinement à la Android: les applis n'ont pas le droit d'écrire où elles veulent.

Mais ce n'est pas très pratique sur une vraie station de travail…

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Ce dossier .ssh est un bon exemple de ce qu'il ne faut pas faire:

• on y mélange de la configuration et d'autres choses ;
• il est à la racine du $HOME en bordel avec le reste ;
• le nom est celui du protocole et pas de son usage ou du logiciel.

Bref c'est mal foutu et il faudrait ne rien changer jusqu'à la fin des temps?

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.