Parce que la réaction du projet "je suis libre mais quand même" pourrait être de compliquer la vie aux pilotes tiers en cassant la rétrocompatibilité régulièrement ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
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.
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.
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.
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.
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.
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.
[^] # Re: Heu, et la quatrième voie ?
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche Désolé, j'ai forké. Évalué à 2.
Parce que la réaction du projet "je suis libre mais quand même" pourrait être de compliquer la vie aux pilotes tiers en cassant la rétrocompatibilité régulièrement ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: L'histoire se répète
Posté par devnewton 🍺 (site web personnel) . 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.
Tu ne veux pas admettre que Gtk a des soucis avec la rétrocompatibilité.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: L'histoire se répète
Posté par devnewton 🍺 (site web personnel) . 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.
Relis la partie "The GTK problem" dans le lien.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: fork
Posté par devnewton 🍺 (site web personnel) . En réponse au lien Pétition de Mozilla pour empêcher la France d’obliger les navigateurs tels que Firefox à censurer . Évalué à 4.
Tout cramer?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: L'histoire se répète
Posté par devnewton 🍺 (site web personnel) . 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. Dernière modification le 24 août 2023 à 21:47.
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.
[^] # Re: L'histoire se répète
Posté par devnewton 🍺 (site web personnel) . 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. Dernière modification le 24 août 2023 à 18:31.
( 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.
[^] # Re: L'histoire se répète
Posté par devnewton 🍺 (site web personnel) . 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.
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.
[^] # Re: L'histoire se répète
Posté par devnewton 🍺 (site web personnel) . 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.
Ce n'est pas du tout le même problème.
Encore une fois tu mélanges les couches:
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.
[^] # Re: L'histoire se répète
Posté par devnewton 🍺 (site web personnel) . 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.
Tu mélanges les couches. Le "socle" html/js/css est au même niveau que gtk et est très rétrocompatible.
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.
[^] # Re: L'histoire se répète
Posté par devnewton 🍺 (site web personnel) . 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.
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.
[^] # Re: L'histoire se répète
Posté par devnewton 🍺 (site web personnel) . 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.
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.
[^] # Re: Flatseal
Posté par devnewton 🍺 (site web personnel) . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. Évalué à 3.
Ben non c'est décidé au COMEX !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Flatseal
Posté par devnewton 🍺 (site web personnel) . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. Évalué à 7.
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.
[^] # Re: L'histoire se répète
Posté par devnewton 🍺 (site web personnel) . 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.
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.
[^] # Re: Flatseal
Posté par devnewton 🍺 (site web personnel) . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. Évalué à 5.
Ma théorie, confirmé par la pratique, c'est que la complexité de toutes les couches hardware/firmware/OS/softs a explosé.
Exemple:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Flatseal
Posté par devnewton 🍺 (site web personnel) . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. Évalué à 10.
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.
[^] # Re: Flatseal
Posté par devnewton 🍺 (site web personnel) . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. Évalué à 6.
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.
[^] # Re: L'histoire se répète
Posté par devnewton 🍺 (site web personnel) . 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é à 4.
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.
[^] # Re: Flatseal
Posté par devnewton 🍺 (site web personnel) . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. Évalué à 6.
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.
[^] # Re: L'histoire se répète
Posté par devnewton 🍺 (site web personnel) . 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é à 6.
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.
[^] # Re: Flatseal
Posté par devnewton 🍺 (site web personnel) . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. Évalué à 5.
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.
[^] # Re: Flatseal
Posté par devnewton 🍺 (site web personnel) . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. Évalué à 3.
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.
[^] # Re: Dériveur
Posté par devnewton 🍺 (site web personnel) . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. Évalué à 9.
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.
[^] # Re: Flatseal
Posté par devnewton 🍺 (site web personnel) . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. Évalué à 10.
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.
[^] # Re: Sécurité
Posté par devnewton 🍺 (site web personnel) . En réponse au lien Red Hat cesse tout développement sur le Bluetooth et le multimédia de GNOME. Évalué à 3.
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.