Hello.
Depuis maintenant quelques années, j'utilise pas mal le mind-mapping pour organiser mes idées. Je suis assez satisfait de cette méthode (bien que de mon point de vue, celle-ci nécessite un certain temps d'adaptation et présente quelques faiblesses, mais c'est un autre débat).
Je voulais utiliser le mind mapping pour organiser les idées afin d'écrire une petite page d'introduction à Forth, et je me suis servi de l'outil freeplane. Sous Ubuntu, je peux avoir une version native, et une version snap.
Comme la version fourni par la distribution était un peu ancienne dan les précédentes versions d'Ubuntu (20.04, peut-être même 18.04 quand je l'ai fait), j'ai donc décidé d'installer le snap. En terme d'édition et de fonctionnalités, je n'ai pas à me plaindre : je dispose d'une version récente, et je peux en faire ce que je veux.
Cependant, les choses se sont compliquées quand j'ai voulu sauvegarder mes données : en effet, sur mon ordinateur portable, je dispose d'un SSD avec un tas de choses que j'ai décidé de monter sur /data. ( Certains me diront que ça ne respecte pas des bonnes pratiques (FHS, XDG Base directory specification, ou autre truc, mais je m'en fous). Mon problème est que depuis le logiciel enfermé dans son environnement tel que défini par snap, je ne vois pas le point de montage /data (alors qu'avec un logicel natif, ou d'autres logiciels sous Snap, je le vois).
Du coup je commence à sérieusement m'inquiéter sur la généralisation de l'utilisation de ce genre de truc : autant pour un outil exposé tel qu'un navigateur, ou un serveur je peux comprendre l'idée de segmenter et de ne donner accès qu'au strict nécessaire, autant pour un outil tel que freeplane, j'ai un peu plus de mal à comprendre.
Peut-être qu'il y a moyen éventuellement d'ouvrir un peu plus les accès pour ce genre de truc, mais d'après ce que j'ai compris (et j'ai peut-être mal compris), ces restrictios sont mises en place à la génération du snap et je crains d'avoir besoin de regénérer un paquet pour pouvoir ouvrir l'accès à mon point de montage /data sur ma machine.
Tout ça pour dire qu'en soit, je ne suis pas un fervent opposé (ni un fervent promoteur ) à la fourniture de logiciels sous forme de snap ou flatpack ou autre truc du genre : je suis juste inquiet sur la généralisation de ce genre de chose, et par le fait que beaucoup ne se poseront pas de questions sur les conséquences réelles sur les utilisateurs. J'ai juste l'impression que ces trucs sont juste des outils "de confort" pour les devs (en soi c'est pas mal) qui si mal utilisés pourrnt générer des problèmes assez gênant aux utilisateurs finaux, du style de celui que je viens de vous citer.
Si toutefois il y a un moyen simple d'ouvrir les restrictions apportées à un paquet snap (ou flatpack) déjà installé, je suis preneur de l'info en commentaire.
# Flatseal
Posté par aboulle . Évalué à 10.
J’ai rencontré un problème similaire avec Flatpak il y a quelques temps. J’ai trouvé flatseal qui permet de modifier les permissions des paquets.
[^] # Re: Flatseal
Posté par gUI (Mastodon) . Évalué à 10.
Apparemment on trouve à peu près le même outil pour Snap :
snap connections.C'est censé permettre de modifier les autorisations (accès aux répertoires mais pas seulement).
Au final on retrouve plus ou moins le même mécanisme que sous Android (je ne connais pas iOS mais je me doute qu'il doit y avoir également le même type de permissions).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Flatseal
Posté par totof2000 . Évalué à 5.
Merci, je vais jeter un oeil. Si ça permet d'ouvrir les restrictions mises en place par défaut pour s'adapter au cas non pensé par les personnes qui ont mis les choses en place (ce que' je ne reproche pas car on ne peut pas penser à tout), ça me va. Ca lève mes inquiétudes.Ca nhe fait pas de moi un fervent admirateur de ce genre de solution (parce que je connais également les inconvénients de ce format de packaging), mais ça la rend suffisamment flexible pour que ce soit utilisable, et c'est ce que je cherche avant tout.
[^] # Re: Flatseal
Posté par totof2000 . Évalué à 10.
Bon .. j'ai jeté un oeil au lien, et j'ai tenter de regarder si je pouvais ouvrir un peu les droits via le gestionnaire de logiciels sous Ubuntu : malheureusement, je pense que je ne peux qu'ouvrir ce que le développeur me laisse ouvrir Et ça c'est pas du tout une bonne chose. Pour le snap firefox, je n'ai accès à rien. Pour freeplane, je n'ai que deux paramètres modifiables. Je vais regarder via la ligne de commande mais je n'y crois pas trop.
Je commence à fatiguer de cette ère ou les développeurs/éditeurs prennent le pouvoir sur nos systèmes. Qu'ils mettent en place des choses par défaut ne me choque pas, mais chaque utilisateur/administrateur devrait pouvoir gérer et adapter la couche par défaut : si l'outil Snap ne le permet pas, c'est que c'est un mauvais outil : il faut soit l'adapter pour pouvoir le faire, soit changer l'outil.
Pour moi les développeurs ne traiteront que les cas qu'ils pensent majoritaires, et les autres n'auront qu'à aller "se faire f*****" et s'arranger pour que leurs besoins s'adaptent à l'outil … Et même si les développeurs sont de bonne volonté, ça ajoute un niveau de dépendance non souhaitable à un tiers, avec tout ce que ça implique dans la réponse au besoin (nécessaire d'attendre un correctif pour pouvoir avancer dans son travail).
Je m'emballe peut-être , dans ce cas je l'écrirai ici même, mais honnêtement, je ne le sens pas très bien.
[^] # Re: Flatseal
Posté par zurvan . Évalué à 5.
la solution c'est d'éviter d'utiliser ces "solutions" bidon : flatpak, snap et peut-être que les dev arrêteront d'utiliser ces formats d'empaquetage si restrictifs (appimage est ok en revanche) et qui consomment tant de ressources.
Freeplane c'est juste du java, donc tu n'as même pas besoin d'avoir un paquet, tu télécharges l'archive freeplane_bin-1.11.5.zip et lance freeplane.sh
ça se compile même facilement avec gradle (c'est moi qui ait travaillé sur les nouveaux thèmes / styles colorés donc je me suis amusé à le recompiler il y a quelques temps)
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Flatseal
Posté par devnewton 🍺 (site web personnel) . É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: Flatseal
Posté par Psychofox (Mastodon) . Évalué à 7.
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.
[^] # Re: Flatseal
Posté par Xanatos . Évalué à 2.
Voir Bubblewrap sur lequel se base Flatpack.
J'avais commencé à sandboxer Firefox avec, c'est plus velu que avec firejail.
[^] # Re: Flatseal
Posté par gnumdk (site web personnel) . Évalué à 1.
Les devs te remercient mais ça va aller, flatpak répond à nos besoins et permet de sécuriser notre OS autant que possible, de faciliter le développement et la reproductibilité des erreurs.
[^] # Re: Flatseal
Posté par devnewton 🍺 (site web personnel) . É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: Flatseal
Posté par devnewton 🍺 (site web personnel) . É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 gnumdk (site web personnel) . Évalué à 3.
Perso, je suis sous Silverblue en 100% flatpak.
Et non il ne s'agit pas de limitation, si un outil n'est pas dans un SDK, oui il faut le builder… Appimage c'est pire, y'a pas de SDK….
[^] # Re: Flatseal
Posté par GaMa (site web personnel) . Évalué à 10.
Vous me faites rire avec "Flatpak c'est de la me**e, appimage ça marche très bien".
Chez kiwix, on fait les deux.
Pour flatpak, on a un fichier de config(https://github.com/flathub/org.kiwix.desktop/blob/master/org.kiwix.desktop.json) et c'est terminé (et encore, on génère ce fichier à partir de notre outils de build, donc c'est mis à jours tout seul)
Pour AppImage, ça se fait effectivement "facilement". Il faut tout (mais pas trop) copier dans un dossier et lancer un "linuxqtdeploy" (mais deux fois, parce qu'il faut patcher le RPATH de QTWebEngineProcess entre les deux). Le script est là: https://github.com/kiwix/kiwix-build/blob/main/scripts/create_kiwix-desktop_appImage.sh
Mais une fois que tu as ton appimage, c'est pas fini :
https://github.com/kiwix/kiwix-desktop/issues/871 : la connexion ssl ne s’établit pas sur certaine distrib à cause de différence de version de openssl. Pas possible d'embarquer la lib openssl parce que les chemins vers les certificats sont hard codé dans le binaire et ils changent d'une distrib à l'autre.
https://github.com/probonopd/linuxdeployqt/issues/554 : Pas d'affichage de la webview à cause de … on sait pas. Il y a un workaround qui désactive le rendu gpu, mais c'est un workaround.
Ou encore celui là : https://github.com/kiwix/kiwix-desktop/issues/393, si tu embarques la libstdc++ dans ton appimage, mesa n'arrive pas à charger les drivers opengl. Si tu n'embarques pas la libstdc++, il faut que tu utilises une vieille distrib avec une vieille version de qt (ou recompiler tout qt), mais qui potentiellement n'a pas les plugins pour les dernières variantes des drivers gl….
Et tu peux aller voir les issues, elles sont liées à pas mal d'autres d'autres projets qui ont les mêmes problèmes encore et encore. Alors oui, pour trois truc simple, appimage ça marche bien. Mais dès que c'est un peu complexe, que tu veux des dépendances à jours et que ça tourne sur toutes les distribs (y compris les vieilles), appimage c'est compliqué. Et chaque projet dois refaire le processus de trouver ce qu'il faut faire.
Alors c'est peut-être pas appimage le problème, c'est peut-être le packaging de qt dans appimage, ou l’outil linuxdeployqt ou encore un autre truc. Mais en attendant, ça se termine souvent en : "Utilisez flatpak, ou les paquets de votre distrib, si ils existent".
PS, je veux bien que vous me fixiez les deux premières issues.
Matthieu Gautier|irc:starmad
[^] # Re: Flatseal
Posté par zurvan . Évalué à 4.
j'ai également essayé de packager des trucs avec AppImage et n'y suis pas arrivé… cela me semblait assez compliqué (je ne suis pas dev non plus), même si en théorie il n'y avait qu'une paire de commandes à lancer… ben ça n'a pas fonctionné au final.
Que flatpak soit plus simple à générer, c'est possible, ceci étant, je parlais plus haut du fait que pour l'utilisateur final les AppImages sont pratiques, cela fonctionne comme une appli native, et même si le binaire est un peu plus gros qu'un .deb c'est quand même moins pire qu'un flatpak : l'exemple donné sur https://ludocode.com/blog/flatpak-is-not-the-future est édifiant : pour un programme de calculatrice, un appImage fait 150 Mo tandis que le même fera 900 Mo avec flatpak. D'un autre côté MuseScore en AppImage fait aussi 160 Mo donc ça reste acceptable.
Lorsque je recherche une appli plus récente que les deb de ma distribution, je regarde s'il y a une AppImage, sinon je préfère compiler le logiciel qu'utiliser snap ou flatpak…
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Flatseal
Posté par GaMa (site web personnel) . Évalué à 4.
Il est vrai.
Mais le appImage n'embarque pas tout. Il a besoin d'un ensemble de libs déjà présentent dans ton système (sinon on aurait pas les problèmes de compat que j'ai cité).
Quelle est la taille de ces libs ?
Tu me répondras qu'on s'en fout parce que c'est déjà là et que c'est partagé avec les autres programmes. Mais c'est exactement la réponse qui est donnée dans cet article: Le flatpak est gros parce qu'il vient avec un sdk, mais ce sdk sera partagé par d'autres appli aussi.
Et c'est un vrai problème quand tu packages un logiciel. Il faut décider d'une limite à partir de laquelle tu assumes que c'est un "standard" de ton système (et si il est versionné ou non).
Si la limite est trop basse, tu assumes trop et ton logiciel ne fonctionne que sur un petit nombre de distrib
Si la limite est trop haute, tu embarques beaucoup de choses qui vont être des duplications de ce qu'il y a dans le système (ou entre plusieurs packages).
AppImage te laisse choisir (pour le pire et le meilleur).
Flatpak prend un chemin intermédiaire:
- Prendre une limite haute et avoir des sdk qui "refont" un système.
- Avoir des applis qui se base sur ces sdk (et donc avoir une limite "basse" du point de vue appli)
- Parier sur la déduplication des données pour ne pas exploser en taille avec la multiplication des sdk.
Sur ce dernier point, je trouve aussi que c'est un peu limite. Flatpak prend effectivement beaucoup de place. Mais il reste quand même que ça "juste marche" contrairement aux autres solutions plus légères.
Matthieu Gautier|irc:starmad
[^] # Re: Flatseal
Posté par gnumdk (site web personnel) . Évalué à 3.
Sauf que le mec racontent n'importe quoi:
- 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
- J'ai une centaines d'applications installées via Flatpak, et pas que des calculatrices, je te laisse imaginé la taille du bousin avec appimage…
[^] # Re: Flatseal
Posté par Psychofox (Mastodon) . Évalué à 5.
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.
[^] # Re: Flatseal
Posté par devnewton 🍺 (site web personnel) . É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: Flatseal
Posté par GaMa (site web personnel) . Évalué à 2.
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.
Mais c'est un peu facile de venir poser la question de
est-ce Flatpak réponds vraiment à des besoins impossible à gérer avec l'existant qui marche (appimage + sandbox) ?et ensuite dire que "c'est juste un truc à générer des binaires, il faut pas comparer" quand on te montre que appimage + sandbox, ça marche pas si bien que ça.[*] Enfin, on lui reproche rien. C'est juste que c'est une limitation et que les outils comme flatpak ou snap prennent une autre approche pour essayer de combler cette limitation. (Et on est d'accord que cette approche a aussi des défauts)
Matthieu Gautier|irc:starmad
[^] # Re: Flatseal
Posté par devnewton 🍺 (site web personnel) . É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: Flatseal
Posté par gnumdk (site web personnel) . Évalué à 0.
C'est possible que tu arrêtes de répéter ça juste parce que tu n'a pas compris ce que tu as lu ?
[^] # Re: Flatseal
Posté par Psychofox (Mastodon) . Évalué à 10.
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.
[^] # Re: Flatseal
Posté par totof2000 . Évalué à 6.
Je ne voulais pas le dire comme ça, mais c'est bien l'impression que me laissent flatpack/snap: un truc pour faciliter la vie des devs, au détriment des besoins des utilisateurs.
Et encore une fois on va avoir des utilisateurs qui vont se retrouver à devoir inventer des astuces pourries parce que le logiciel leur mettra des barrières artificielles.
Alors certes, le dev n'aura peut-être plus à gérer la difficulté du packaging lié à la grande variété des distributions, mais il aura à gérer toutes les interactions possibles entre le système, l''environnement graphique, et avec les autres logiciels … Je ne suis pas sûr qu'il y gagne au change.
[^] # Re: Flatseal
Posté par Psychofox (Mastodon) . Évalué à 6. Dernière modification le 22 août 2023 à 16:00.
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
[^] # Re: Flatseal
Posté par totof2000 . Évalué à 4. Dernière modification le 22 août 2023 à 16:08.
Forth :
une calculatrice, un compilateur, un interpréteur, un assembleur, la possibilité d'éditer ton code online et de le sauvegarder sur disque, la possibilité de porter ton environnement sur une autre architecture, sur quelques centaines de kb, sans nécessité d'avoir un OS sous-jacent …
Bon c'est peut-être n peu l'autre extrême (pas de multitache préemptif, pas de protection mémoire via MMU et d'autres trucs qui manquent dans l'utilisation des systèmes modernes interconnectés pour être sécurisés), mais entre ça et ce qu'on a aujourd'hui, il y a certainement moyen de trouver un juste milieu.
[^] # Re: Flatseal
Posté par Okki (site web personnel, Mastodon) . Évalué à 8.
En tant que simple utilisateur, je suis bien content qu'on ait désormais Flatpak. De nos jours, plein de nouvelles petites applications sortent régulièrement. Ces dernières ne sont pas packagées par les distributions (trop récent, pas assez populaire, aucun bénévole pour s'en occuper…).
En proposant l'application sous forme de Flatpak, cette dernière est aussitôt facilement accessible à tout le monde, peu importe sa distribution. De ne plus avoir à récupérer les sources sur GitHub, devoir installer toutes les dépendances en espérant qu'il ne manque rien et que ça corresponde bien aux versions demandées, pour ensuite me taper une compilation qui échouera peut être, c'est une libération 🙂
[^] # Re: Flatseal
Posté par totof2000 . Évalué à 3.
C'est une des raisons quui font que dans l'absolu, je ne suis pas complêtement contre ce genre d'outils. J'ai compris ce que ça peut apporter. Mais je vois aussi très bien les problèmes qu'ils peuvent causer derrière.
[^] # Re: Flatseal
Posté par gnumdk (site web personnel) . Évalué à 1.
Mais quels problèmes?
La plupart des applications sur flatpak qui ne gèrent pas les portails et qui ont besoin d'accéder à ton OS, ben les restrictions sont explicitement ouvertes dans le paquet.
[^] # Re: Flatseal
Posté par devnewton 🍺 (site web personnel) . É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 Psychofox (Mastodon) . Évalué à 3.
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.
[^] # Re: Flatseal
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 6.
Ou parce que le logiciel n'est tout simplement plus maintenu/développé pour leur type de machine. Ce qui est rageant quand tu en as une qui fonctionne tout à bien, tu peux supporter un peu de lenteur (mais pas trop).
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Flatseal
Posté par Renault (site web personnel) . Évalué à 7.
Bah voyons. C'est rigolo car il y a plein d'usages basiques qui justifient une plus grande consommation. La sécurité informatique, loin d'être parfaite, s'améliore et cela passe notamment par des couches d'abstractions et le chiffrement opérations gourmandes en mémoires et en cycles processeurs. Bon peut être que tu es fan de l'époque des BSOD car une application tapait au mauvais endroit, ou que pour toi une application sur ta machine peut savoir tout ce qui s'y passe que tu le veuilles ou non. Pas moi.
C'était aussi la douce époque où le plug and play était très peu répandues, les configurations étaient statiques, pour le matériel aussi. Des protocoles et des disques durs qui mettent une plombe pour la moindre opération. Des dizaines de minutes pour télécharger un pauvre exécutable de quelques Mio, c'est vrai que c'est fun. Moi aussi je regrette l'époque du disque dur qui gratte pour juste lancer Firefox.
Le multimédia était aussi peu répandu. Des vidéos en ligne ? Des images haute définition ? Non les photos de famille pixelisées c'était la bonne époque, la vraie.
Puis bon, ça fonctionnait pas trop mal en Europe et encore mieux aux USA quand tout reposait sur l'anglais voire l'alphabet latin. La traduction en dehors de grandes langues occidentales c'était une vaste blague.
Et comme si les logiciels ne proposaient pas de nouvelles fonctionnalités depuis. Ils sont bien plus simples et robustes qu'à l'époque (en tout cas pour les grands noms).
Et j'en passe.
Non vraiment, l'époque de Windows 98-2000 ne me manque pas des masses. C'était bien limité et il y a de bonnes raisons pour faire mieux et donc plus gourmand. Alors tout n'est pas rose, il y a toujours des applications trop gourmandes pour ce qu'elles font, des développeurs Web ou d'applications qui codent n'importe comment et ne se préoccupent de rien. Mais des applications ou site web pétées à l'époque, ça existait aussi. Et les usages ont évolué avec, l'usage de l'informatique s'est aussi bien diversifié et l'usage du multimédia et du réseau ont bien explosés par exemple et ce sont des postes gourmands en ressources. Même si dans le lot il y a forcément des personnes qui seraient satisfaits d'un Windows 98 pas connecté à Internet, et ils peuvent toujours s'en servir s'ils le veulent, mais bon si tu veux la dernière version de Firefox ça sera forcément plus compliquée.
[^] # Re: Flatseal
Posté par gUI (Mastodon) . Évalué à 6. Dernière modification le 22 août 2023 à 21:01.
Oui mais es-tu plus heureux aujourd'hui devant ton ordi que hier ? J'en doute.
Parce que moi aussi j'ai vécu les premiers vrais sons sur PC (un copain me téléphone en me faisant écouter l'intro de X-Wing vs T-fighters après avoir acheté sa SoundBlaster), les premières vidéos sur CD-ROM (une image qui bouge !!! et pendant plusieurs minutes !!!), les premières 3DFX avec leur rendu de dingo (non mais sérieux, t'as joué avec Need4Speed avec le soleil dans la gueule ?)
Tu fais quoi de plus aujourd'hui qu'hier ?
Quand ton rendu 3D prenais 10h de calcul, tu faisais autre chose, bien obligé (puisque 100% de
teston CPUs était monopolisés). Aujourd'hui il prend 1h et tu restes comme un con à matter Youtube/Instagram/TikTok pendant 1h en attendant.Non je déconne, juste que faire des phrases à la con pour dire que "X est mieux que Y" c'est facile.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Flatseal
Posté par Renault (site web personnel) . Évalué à 5.
Oui.
Je me souviens de mes débuts avec Fedora Core 3 en 2005, c'était la vraie galère pour faire quoique ce soit. Passer des journées à configurer des trucs, à compiler des outils pas présents dans les dépôts, ça fonctionnait mal par dessus le marché avec une intégration très mauvaise. C'était clairement pas aussi stable, efficace et simple qu'aujourd'hui. Et ça prenait un temps de dingue pour beaucoup d'actions car le disque dur et le processeur étaient lents.
Et je fais des choses que je ne faisais pas à l'époque. Et je préfère mater les films / séries / vidéo de chatons dans les formats actuels que le 720p de l'époque (et encore, ça c'était 2005, je te laisse imaginer 7 ans avant).
Et à l'époque je ne faisais rien de sensible, je n'irais clairement pas sur le site de ma banque sans chiffrement, je n'irais pas non plus si les applications avaient un accès libre à la mémoire ou au buffer graphique, etc.
Et je joue à des jeux vidéos qui imposent un minimum de réalisme pour être immersif, j'aime bien les jeux de fins des années 90 aussi, mais clairement pour d'autres il faut bien plus que ce qui était possible à l'époque.
Des systèmes légers et très simples qui ont les possibilités des années 90 ou début des années 2000 il y en a, mais bizarrement pas grand monde ne semble si attiré que ça. D'ailleurs en général les gens qui semblent s'intéresser à l'usage de très vieilles machines le font plus pour une raison financière que par choix par rapport au cas d'usage.
Mais bon, classique, c'était mieux avant alors qu'en réalité c'est plus compliqué. Des cas d'usages nouveaux sont bien apparus, des tas de choses étaient vraiment pourries et limitées, parfois on s'en fout car on est pas concerné (type accessibilité, internationalisation, prise en charge de matériel plus exotiques) mais ça concerne des gens, ou alors oui c'était possible mais moins fiable, moins flexibles, moins joli / ergonomique. Perso je me souviens bien de ces difficultés et je constate avec plaisir les progrès opérés depuis.
Mais on est d'accord, il y a des logiciels ou site web trop gourmands pour ce qu'ils font, mais ce n'est pas le cas de tous.
[^] # Re: Flatseal
Posté par totof2000 . Évalué à 7.
Avant ça ne marchait peut-êtr pas e aussi bien qu'aujourd'hui, mais quand ça ne marchait pas, il y avait souvent moyen de corriger par soi-mốeme (au moins sur les systèmes de type Unix).
Aujourd'hui, il semble que ça marche mieux … c'est vrai pour certaines choses mais pas pour tout - mais quand ça ne marche pas, tu ne peux pas forcément corriger … tu dois ouvrir un rapport de bug parce que des choses qui étaient codés en script - que tu pouvais corrigetr - sont maintenant codés en binaire, et parce que les développeurs et éditeurs laissent de moins en moins de contrôle aux utilisateurs sur ce qu'ils peuvent faire sur leur matériel ou leur logiciel.
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.
[^] # Re: Flatseal
Posté par barmic 🦦 . É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: Flatseal
Posté par devnewton 🍺 (site web personnel) . É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 barmic 🦦 . É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 SpaceFox (site web personnel, Mastodon) . Évalué à 4.
Note que la complexité de ce que tu appelles « l’affichage » a aussi explosé, le service rendu par les deux documents n’a absolument rien à voir.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Flatseal
Posté par Thomas Douillard . Évalué à 6.
Imagine, Gimp et son problème de profil de couleurs de multiécrans pour restaurer des couleurs fidèles, mais en VGA … La question se serait évidemment même pas posé parce que c’était pas du tout envisageable avec les specs VGA probablement. C’est important pour les pros. Forcément que la complexité n’est pas la même. Les fonctionnalités et le détail dans lequel on a besoin d’aller n’est pas le même qu’à l’époque.
Comparer les choses à fonctionnalité équivalente, oui. A fonctionnalité non équivalentes, c’est pas pertinent. Sauf si t’es près à justifier l’absence d’une fonctionnalité au nom d’une simplification technique, mais ça va pas vraiment être la priorité d’un graphiste qui est totalement justifié à vouloir plusieurs écrans et un rendu des couleurs fidèles entre plusieurs périphériques qu’il utiliserait.
[^] # Re: Flatseal
Posté par devnewton 🍺 (site web personnel) . É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: Flatseal
Posté par Renault (site web personnel) . Évalué à 4.
Cela dépend du problème, le manque d'intégration ou certains bogues oui certainement, mais beaucoup de soucis étaient tout aussi insolubles qu'aujourd'hui, car si le logiciel n'en fait qu'a sa tête ou n'a pas la fonction désirée, bah tu l'as dans l'os aussi.
Je pense personnellement que c'est mieux qu'on ait moins besoin de connaître son système parfaitement pour s'en servir. Sauf cas spécifiques, un ordinateur est un outil pour effectuer des tâches, ce qui compte c'est de faire ces tâches. Bidouiller de partout pour faire en sorte de faire ces tâches restent une perte de temps et il est préférable de rendre l'expérience la plus fluide et simple pour la majorité des utilisateurs même si la complexité globale fait que les quelques bidouilleurs qui auraient pu éventuellement se débrouiller avant perdent un peu en capacité de résoudre les problèmes.
Mais notons que c'est aussi cette standardisation, ces tests automatiques et cette intégration qui permet aussi d'améliorer la qualité globale.
Franchement les scripts devenus des binaires cela concerne vraiment peu de composants en fait depuis 20-30 ans.
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". D'ailleurs je ne suis pas spécialement convaincu par l'argument, les fonctionnalités de la plupart des logiciels sont bien plus nombreuses depuis 30 ans, de nombreux outils restent très fins dans leur configuration et leurs possibilités avec des scripts ou addons quand c'est pertinent.
Mais la complexité du système et du matériel, en partie à cause de nouveaux usages (comme le multimédia) mais aussi des préoccupations "nouvelles" (sécurité, réseau, etc.) ne permet pas d'avoir tout qui soit intelligible et facilement résolu ou compréhensible par le bidouilleur du coin.
Pour moi ce sentiment de contrôle est trompeur. Et surtout je pense que même avec ce contrôle, tu perdais au final bien plus de temps et cela nécessitait beaucoup plus de compétences pour faire des choses finalement basiques et automatisables. Personnellement je suis bien content de l'informatique aujourd'hui malgré ces défauts par endroit évidemment. De toute façon si tu veux un système simple et léger, ça existe encore, tu es libre de t'en servir d'ailleurs. Mais bizarrement je pense que tu ne t'en contenteras pas.
[^] # Re: Flatseal
Posté par devnewton 🍺 (site web personnel) . É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 shbrol . Évalué à 4.
Ecouter l'intro de X-Wing vs T-fighters en entier, jusqu'à la fin, avant de démarrer chaque partie … grosse nostalgie ;-)
[^] # Re: Flatseal
Posté par Psychofox (Mastodon) . Évalué à 10.
À 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?
[^] # Re: Flatseal
Posté par GaMa (site web personnel) . Évalué à 5.
kiwix c'est un dev payé 2 jours par semaine (moi) et qq bénévoles (principalement des étudiants qui disparaissent au bout de qq mois).
Firefox c'est … beaucoup plus.
Matthieu Gautier|irc:starmad
[^] # Re: Flatseal
Posté par Psychofox (Mastodon) . Évalué à 6.
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.
[^] # Re: Flatseal
Posté par Xanatos . Évalué à 2.
En lisant le fil de commentaires je me faisais la même réflexion.
Les builds automatiques c'est éprouvé, la gestion des paquets par arch aussi, pourquoi ne pas avoir un mix des 2 qui irait chercher un appimage/flatpack/XYZ personnalisé en fonction des libs présentes et dans le cas échéant faire une demande de build qui resterait en tampon une durée déterminée ; ou alors build local partiel.
Bon ça serait extrêmement consommateur de ressources pour les fournisseurs, mais c'est ce que fait nodejs ou docker localement ?
[^] # Re: Flatseal
Posté par GaMa (site web personnel) . Évalué à 6.
Elle a pas beaucoup changé non. Mais c'est surtout le reste qui change.
Les problèmes qu'on a, c'est principalement avec des distrib récentes. C'est elles qui ont mise à jours leur lib (openssl, drivers, …).
Qt a évolué aussi, on pourrait builder avec la dernière version de Qt (ce qui corrigerait probablement les problèmes avec les distrib récentes). Mais c'est pas dispo en pré-compilé sur les anciennes distrib. Et on veut compiler sur une ancienne distrib pour avoir une vieille version des glibc et stdlibc++.
Alors on pourrait effectivement recompiler Qt dans notre CI sur en vieille machine. Mais ça passerait pas dans notre CI (on fait quand même des builds toutes les nuits et on publie les nigthly)
On pourrait avoir notre propre runner au lieu d'utiliser celui fournit par github mais il faut des €€ pour ça (et rajouter de la maintenance d'une nouvelle machine)
Ou alors je fais un build en local chez moi et on utilise ça dans notre CI… mais quid de la sécu et de la reproductibilité ?
Ou alors je change de métier et je deviens packageur (et plus développeur) et je m'amuse a maintenir une version récente de Qt sur des vieille distrib.
Ou alors …
Et puis il y a pas que Qt. gtest impose C++14 maintenant, mais on est encore en C++11. Il faut qu'on change on est d'accord. Mais en attendant on compile avec une vieille version de gtest. Sauf que les packageurs (merci à eux pour leur travail), ils utilisent le gtest de la distrib et bim, ça compile plus sur les machines récentes.
C'est pas compliqué à changer, c'est une ligne de config (et les packageurs patche cette ligne). Mais il faut vérifier que tous les compilo qu'on utilise font correctement du C++14 avant.
Au milieu de tout ça, il faut faire du code review, répondre aux issues sur github, faire la maintenance de tous les jours et rajouter des fonctionnalités et améliorer les perfs.
À un moment il faut faire des choix.
Le problème c'est qu'on est dans un monde qui bouge et on doit bouger avec lui. (Même si je préfèrerait faire les trucs dans mon coin sans jamais mettre à jour les dépendances).
J'ai jamais utilisé. Mais j'ai peur que ça soit là aussi pas la panacée. On va se retrouver avec plusieurs paquets, compilés avec différentes version des dépendances et différentes options. Et on sait qu'on a des bugs dans nos dépendances qui sont fixé avec des versions récentes. Donc on sait que nos logiciels vont se comporter différemment d'un paquet à l'autre. Il va falloir suivre tout ça. On va pas pouvoir tout tester, donc on va fournir des paquets pour une distrib spécifique sans vraiment savoir si ça fonctionne. Il va falloir comprendre ce qu'il se passe au prochain rapport de bug… et au final c'est la même chose que maintenant mais avec une couche de plus.
Mon métier c'est développeur. Pas packageur. C'est pas à moi de faire le packaging. 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.
Et du coup, on a des gens qui viennent nous dire qu'on est fainéant parce que le binaire est trop gros alors qu'on pourrait ne rien faire. D'ailleurs on leur impose rien, ils peuvent toujours recompiler, on fournit même kiwix-build pour ça.
Matthieu Gautier|irc:starmad
[^] # Re: Flatseal
Posté par Psychofox (Mastodon) . Évalué à 2.
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.
[^] # Re: Flatseal
Posté par Zenitram (site web personnel) . Évalué à 4.
Les gens normaux râlent (à raison) si une fonctionnalité est dispo sur la version Windows, et sur la version Linux mais pour la prochaine version pas encore sortie de la distro mais pas sur la version de la distro qu'ils utilisent.
C'est la vraie vie, et tant qu'on aura des gens qui n'arrivent pas à comprendre ça, on ne risque pas de parler de comment résoudre ça.
Snap/flatpack c'est pourri mais le "moins pire" pour les développeurs qui n'ont pas les ressources pour se coltiner les emmerdes que leur font les distributeurs Linux pas foutus de se mettre d'accord ni avoir une compatibilité binaire (c'est un choix voulu, ben faut assumer que les gens cherchent une solution alors).
Note : perso je maintiens en "natif" (même style que les repos de la distrib, tout en demandant aux gens des manips chiantes quand même car on peut pas sans manip) car je suis assez gros pour que ça soit utile et surtout parce que https://build.opensuse.org/ me facilite la tâche, ça ne m’empêche pas de comprendre le problème à la base.
Ben ils aimeraient bien, mais elle n'existe pas (il y a bien la vieille version, mais ce qui est recherché est la version sortie dernièrement; et ça c'est quand on a la chance d'avoir un mainteneur, hein, c'est pas du tout automatique malgré ton affichage que le package de leur distrib existerait comme une évidence).
[^] # Re: Flatseal
Posté par Psychofox (Mastodon) . Évalué à 6. Dernière modification le 23 août 2023 à 15:00.
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.
[^] # Re: Flatseal
Posté par Psychofox (Mastodon) . Évalué à 6.
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.
[^] # Re: Flatseal
Posté par flagos . Évalué à 5.
Pourtant ca se passe trop mal sur Android avec les app distribuées sur le Play Store.
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 ?
[^] # Re: Flatseal
Posté par Psychofox (Mastodon) . Évalué à 5.
Ce n'est pas de ça que je parle.
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.
[^] # Re: Flatseal
Posté par gnumdk (site web personnel) . Évalué à 1.
Quand il y'a un bug dans l'application, bien sur que si.
[^] # Re: Flatseal
Posté par barmic 🦦 . É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: Flatseal
Posté par Psychofox (Mastodon) . Évalué à 9.
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.
[^] # Re: Flatseal
Posté par greendev . Évalué à -5.
C’est quand même rigolo de lire votre discussion en 2023 où les store sont devenus la norme.
[^] # Re: Flatseal
Posté par Zenitram (site web personnel) . Évalué à -6. Dernière modification le 24 août 2023 à 14:50.
Tous les gens ayant vraiment des utilisateurs travaillent sur les MAJ les plus fluides possibles, mais toi un mec lambda n'ayant aucune base d'utilisateurs tu es là en disant que ça sert à rien, ok l' "expert".
En attendant, le monde avance malgré tout (en laissant de côté autant qu'ils peuvent les gens incapables de comprendre les besoins), avec entre autre Snap/Flathub comme solution (avec leurs défauts, mais bon les devs font avec les limites qu'ils ont de la part d'autres), ça fait râler certains mais bon ces gens ne trouvent comme réponse que "il n'y a pas de besoin", des boulets plus qu'autre chose, rien de nouveau certes (et du coup Linux Desktop va décoller… Demain, promis), juste chiant (mais ça fait les affaires des concurrents, surtout non libre en pratique, à croire que c'est voulu)
[^] # Re: Flatseal
Posté par Psychofox (Mastodon) . Évalué à 5. Dernière modification le 24 août 2023 à 15:48.
Non
à part des dizaines de milliers mais bon, Zenitram aimes bien inventer des pensées et dires au gens, alors parler sans savoir, on n'est plus à ça près!
Hors-sujet. On parlait ici du fait que les utilisateurs réclament des maj logicielles, pas si snap/flathub est la soution. Et en plus je ne râle pas. À priori ce sont les developpeurs qui ne savent pas faire des paquets qui râlent, pas moi.
Soit-dit en passant, j'en n'ai rien à carrer que le desktop linux décolle ou pas, mois je l'utilise depuis 25ans, si j'avais eu besoin de ça j'aurais déjà perdu patience.
Ce que je veux ce sont des standards et de l'interropérabilité entre les OS / programmes et des standards pour tout ce qui est accessible en réseau.
[^] # Re: Flatseal
Posté par GaMa (site web personnel) . Évalué à 10.
Ça dépends.
Le but du projet Kiwix, c'est fournir du contenu web hors ligne. En gros tu télécharges des gros snapshot des site web et tu les lis localement sans connexion.
Du coup nos utilisateurs (c'est très difficile de savoir en vrai), c'est des gens pas en occidents, qui parlent souvent pas anglais, sans connexions de qualité (quand ils en ont).
Ils sont sous linux pas obligatoirement pour le libre mais parce que c'est pas cher.
Où ils utilisent l'ordi qui a été utilisé par l'ONG ou le seul mec de la région qui s'y connait en informatique.
Ils se passent les binaires sur clés usb.
Tu retrouves du kiwix à Cuba, au fin fond du Népal, dans les prisons française, dans les camps de réfugier, sur les terrains de catastrophes naturelles ou non, en Russie (pas mal depuis le début de la guerre en Ukraine), en Chine, ou globalement dans tout les pays où internet est contrôlé/censuré.
Dans les retours d'usage on a:
- Les gens dans des villages d'Afrique qui font une journée de route pour aller à la grande ville pour mettre à jours les zims et les binaires et qui rentre au village pour tout mettre dans un réseau local.
- Quelqu'un qui récupère des clés usb en Corée du sud, mets du kiwix et du wikipedia dessus et ensuite vas "perdre" (sans se faire prendre) ces mêmes clés en Corée du nord en espérant que des gens les récupèrent et regarde ce qu'il y a dessus
- Ou encore des opérateurs en Afrique qui mette du kiwix en interne pour fournir "un accès à wikipedia en illimité" à leurs clients, parce qu'un seul câble qui sort du pays
C'est gens là, tu peux pas leur dire d'utiliser le paquets de leur distrib, de passer par wine ou de compiler eux même. Ce sont pas souvent des informaticiens et ils se débrouillent souvent avec ce qu'ils ont. Il faut que ça "juste marche" (et c'est hélas pas tout le temps le cas)
Avoir des paquets pour les grandes distrib c'est nécessaire (quoique) mais pas du tout suffisant.
On a tendance à facilement oublier qu'on est dans un petit entre-soi finalement. Mais la moitié des gens dans le monde n'ont pas accès à internet de manière régulière.
Matthieu Gautier|irc:starmad
[^] # Re: Flatseal
Posté par Psychofox (Mastodon) . Évalué à 5. Dernière modification le 23 août 2023 à 14:53.
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=][^] # Re: Flatseal
Posté par GaMa (site web personnel) . Évalué à 3.
Les packages n'existent pas pour les version nightly.
On publie les nigthly de kiwix-desktop tout les jours. En flatpak et appimage.
Et pour revenir un peu sur le sujet d'origine:
- Le appimage fait 146Mo
- Le flatpak fait 52Mo (et on se base sur le même runtime, donc rien de plus à dl)
Matthieu Gautier|irc:starmad
[^] # Re: Flatseal
Posté par Psychofox (Mastodon) . Évalué à 1.
Et donc tes utilisateurs de Corée du Nord téléchargent les nightly tous les matins?
[^] # Re: Flatseal
Posté par GaMa (site web personnel) . Évalué à 6.
Non. Comme à chaque fois, différents utilisateurs entrainent différents cas d'usage.
Je sais pas trop pourquoi je continue ici alors que tu sembles tout amalgamer mais bon:
- Les utilisateurs de Corée du Nord, ils téléchargent rien (et il vaut mieux pour leur vie), ils prennent je sais pas quoi (appimage je suppose)
- Les opérateurs, ils utilisent probablement kiwix-serve qui pop un server web et pas une appli graphique
- Les gens qui remontent des bugs parce qu'ils arrivent pas à lire l'archive de 40Go qu'ils viennent de dl, ils prennent effectivement la nightly avec le bug corrigé.
Mon point dans tout ça, c'est de dire que c'est pas aussi facile que Yakafairedespaquets.
Les paquets des distrib fonctionnent bien pour pas mal de monde, et ça tombe bien, il y en a. Pour les autres, ils y a d'autres solutions.
Matthieu Gautier|irc:starmad
[^] # Re: Flatseal
Posté par BAud (site web personnel) . Évalué à 3.
surtout qu'il est déjà empaqueté dans pas mal de distribs
cf. https://repology.org/project/kiwix-desktop/versions
# Flatseal ...
Posté par hgwells . Évalué à 8. Dernière modification le 20 août 2023 à 17:24.
Une précision avec Flatseal, qui n'est pas si évident à comprendre :
Tu seras en mesure d'ouvrir l'accès à /data à l'application Flatpak de ton choix, voire la totalité des applications via l'entrée "global" située en haut de la liste des applications (mais je ne recommanderais pas cette approche).
La déclaration de ton chemin à ouvrir sera à réaliser dans l'une des sections "filesystem" ou "Persistent".
On peut aussi retirer des autorisations.
Pour la sécurisation d'un navigateur web, je trouve avantageux de restreindre l'accès aux répertoires Documents et Bureau dans le "home"
Par exemple si un script java malveillant tentait d'aspirer mes fichiers, alors le navigateur ne pourrait simplement pas les atteindre.
# deb officiel
Posté par zurvan . Évalué à 10.
Il y a un .deb récent sur le dépôt de freeplane, autant utiliser ça.
J'évite également les snap.
https://sourceforge.net/projects/freeplane/files/freeplane%20stable/
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
# Autre anecdote
Posté par Ytterbium . Évalué à 10.
Dans le genre, j'ai découvert un blocage assez gênant au boulot. Pour des raisons historiques, la session personnelle des utilisateurs est dans /obs/~user avec un lien de /home vers /obs. En temps normal, ça ne pose aucun problème.
Sauf en mettant à jour l'Ubuntu de mon poste perso de 20.04 vers 22.04 : le paquet Firefox des dépôts officiels est passé d'un deb à un snap. Et le snap ne veut absolument pas se lancer dans une session utilisateur qui n'est pas dans /home.
Le problème se résous en réinstallant un paquet deb, mais c'est un peu bête pour une version officielle.
Tout ça pour te dire que je te rejoins sur ce manque de flexibilité de snap. Je comprends bien que sécurité et flexibilité peuvent être antinomique, mais ça donne vraiment l'impression que les développeurs de snap ont pris en compte les cas d'usages les plus courants qui arrivent dans 98 % des cas, mais en ignorant les 2 % qui sortent fatidiquement des clous en profitant de la flexibilité du logiciel libre.
# dossiers xdg-user-dirs
Posté par antistress (site web personnel) . Évalué à 10. Dernière modification le 20 août 2023 à 20:49.
totof2000, as-tu bien reconfiguré tes dossiers xdg-user-dirs ? J'ai moi aussi délocalisé des dossiers mais il faut les déclarer !
[^] # Re: dossiers xdg-user-dirs
Posté par totof2000 . Évalué à 3.
Je ne sais pas, je vais peut-être jeter un oeil, mais dans l'absolu je préfère ce genre d'outil qui lève mes inquiétudes (sous réserve que je puisse ouvrir les choses comme ça m'arrange). Mais merci pour l'info, je jetterai un oeil.
[^] # Re: dossiers xdg-user-dirs
Posté par barmic 🦦 . É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: dossiers xdg-user-dirs
Posté par totof2000 . Évalué à 3.
Les conventions ne doivent pas être un carcan: quand tu regardes le monde tel qu'il est fait, quand tu regarde tous les systèmes, tu te rend compte que tu tombes toujours un cas qui ne correspond pas au système. 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.
Je n'ai pas envie de déplacer mon point de montage juste pour un soft, ou pour un truc (snap ou flatpack) - juste parce que ce soft ou ce truc m'empêche de gérer mon système comme j'en ai envie parce que pas assez ouvert. J'ai en planification d'ici la fin de l'année une réorganisation de mes données (avec déplacement de certaines vers un NAS ou vers un cloud - et peut-être qu'à ce moment là je me poserai la question sur la réorganisation de mes points de montage et du respect des normes, et sur la pertinence de garder une distribution qui pousse le snap a tout va, mais aujourd'hui je n'ai pas vraiment le temps de faire ça. J'ai juste besoin de sauvegarder mon mindmap là ou je veux.
[^] # Re: dossiers xdg-user-dirs
Posté par barmic 🦦 . É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
# Possible avec Flatpak
Posté par Vincent Bernat (site web personnel) . Évalué à 10.
Sur Flatpak, c'est possible de changer les droits sans recompiler. Regarde flatpak-override(1). Par exemple,
flatpak override --filesystem=/data org.tonapp.# titre inadapté et course à la dernière version.
Posté par Psychofox (Mastodon) . Évalué à 7.
Je ne suis pas sûr que "dérive sécuritaire" soit le bon mot. C'est une expression utilisée en général pour dénoncer des infractions aux droits de l'homme sous couvert de sécurité.
Là on est juste dans un cas où le compromis/l'intersection entre les besoins/désirs de sécurisation et ceux de l'ergonomie et de la flexibilité est difficile à trouver et jamais idéale pour tous les utilisateurs.
Et au final des solutions ont été évoquées aux problèmes mentionnés.
Par ailleurs j'ajouterai que faire la course à la dernière version d'un programme, mais pourquoi? Es-tu capable de formuler quelles fonctionnalitées aurais-tu perdu où quels bugs tu aurais rencontrés et t'aurais limité dans ton activité en utilisant la version fournie par ubuntu sous forme de paquet deb? Si la réponse est non, peut-être que le plus simple aurait été de te contenter de cette version.
[^] # Re: titre inadapté et course à la dernière version.
Posté par totof2000 . Évalué à 5.
C'est bien pour ça que je l'ai mise entre guillementlemets : j'i un peu grossi le trait certes mais en fait on n'en est pas si loin. On a des éditeurs de logiciels (pour beaucoup privateurs) qui utilisent les mêmes méthodes pour prendre le contrôle des terminaux des utilisateurs sous couvert de sécurité, et empechent ceux-ci de désactiver des trucs style tracking, gestion de DRM, etc … Les SNAP et Flatpack ne ont pas là pour ça, mais ils posent le même problème : perte de contrôle par l'tilisateur sous pretexte de sécurité.
Justement : l'outil devrait permettre un paramétrage par défaut, mais ne pas empêcher les utilisateurs de l'adapter à leur configuration. Comme ça, ilm n'y a pas à se prendre la tête sur les besoins/désirs, et l'utilisateur paramètre en fonction de ce qui est idéal pour lui.
Comme je l'ai dit, j'ai utilisé cet outil dans une version LTS d'Ubuntu (20.04 ou 22.04, je ne me rappelle plus) qui était assez en retard sur la dernière version. La version fournie dans Ubuntu me causait quelques problèmes dont je ne me rappelle plus (ergonomie, modèles par défaut moins intéressant, quelques fonctionnalités manquantes dans la création des noeuds ou l'édition de liens - je ne sais plus exactement). Depuis je n'étais plus revenu dessus. Et c'est juste parce que j'ai ajouté (enfin récupéré) le SSD en question (qui contenait déjà des données) sur mon portable, et que j'ai eu besoin de sauvegarder dessus, que j'ai rencontré le problème (il me semble l'avoir déjà rencontré une fois - je crois pour sauvegarder sur un point de montage réseau - ou un support externe - mais a l'époque j'avais contourné en faisant la manip en deux étapes).
Je ne suis absolument pas du genre à courir après la dernière version d'un soft. Si je le fais, c'est que la version packagée par une distrib est buggée, ou qu'elle manque d'une fonctionnalité dont j'ai besoin. Encore un truc qui devient fatiguant : "dis-moi de quoi tu as besoin, je te dirai comment t'en passer"
Ben en regardant d'un peu plus près, j'ai l'impression justement qu'il n'y a pas de solution.
[^] # Re: titre inadapté et course à la dernière version.
Posté par Psychofox (Mastodon) . Évalué à 3.
J'ai cru que quelqu'un t'avais enseigné une solution
snap connectionsmais apparemment ça ne fait pas ce que faitflatsealsi j'en crois ton commentaire.Je crois qu'on comprends vite pourquoi toutes les distribs proposent du flatpak et personne à part ubuntu et ses dérivés ne proposent le snap.
[^] # Re: titre inadapté et course à la dernière version.
Posté par flagos . Évalué à 2. Dernière modification le 21 août 2023 à 14:51.
Snap est sur Arch: https://wiki.archlinux.org/title/Snap
Et sur Manjaro, tu as meme un plugin pour installer facilement les snaps avec pamac (comme pour les flatpak), la surcouche de Manjaro a pacman: https://wiki.manjaro.org/index.php?title=Snap
[^] # Re: titre inadapté et course à la dernière version.
Posté par Psychofox (Mastodon) . Évalué à 3.
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.
[^] # Re: titre inadapté et course à la dernière version.
Posté par gnumdk (site web personnel) . Évalué à 5.
snap est un logiciel à moitié libre, aucun libriste ne devrait l'utiliser. Donc c'est normal que les distribs ne le propose pas vu que le repo n'est pas libre.
Et les développements autour des portails se fait pour Flatpak, Canonical ne fait que courir derrière.
[^] # Re: titre inadapté et course à la dernière version.
Posté par Psychofox (Mastodon) . Évalué à 4.
Nous sommes d'accord.
# Dériveur
Posté par saltimbanque (site web personnel) . Évalué à 0.
Le temps que flatpak devienne la norme, et tout s'adaptera. Si des outils comme flatseal sont nécessaires, cela deviendra habituel pour tout le monde, mais si des choses peuvent être améliorées pour une appli en particulier plutôt que de nécessiter un outil en plus, ce sera fait. Cette adaptation aura d'autant plus de sens pour les "packager" (flatpakeurs) voire pour les dév upstream qu'elle bénéficiera ) à plusieurs distributions donc à un public suffisamment vaste - de plus en plus vaste.
Il n'y a pas de raison d'être inquiet pour les utilisateurs finaux - leur expérience tendra à être de plus en plus proche peu importe la distribution voire la version de la distribution utilisée. La documentation en sera facilitée.
En attendant retournons travailler!
[^] # Re: Dériveur
Posté par devnewton 🍺 (site web personnel) . É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: Dériveur
Posté par Psychofox (Mastodon) . Évalué à 5.
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
[^] # Re: Dériveur
Posté par barmic 🦦 . É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: Dériveur
Posté par gUI (Mastodon) . Évalué à 10.
Vraie question : peut-on créer un produit stable et performant avant de le mettre en prod ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Dériveur
Posté par Micromy (site web personnel) . Évalué à 10.
Oui, en réalisant un cahier des charges aux petits oignons se basant sur une expression de besoins claire effectuée par des utilisateurs clairvoyants, visionnaires et réalistes à la fois. Puis en développant avec des personnes extrêmement compétentes encadrées par des responsables projet hors pair, avec à disposition les ressources adaptées. Bien entendu en impliquant les utilisateurs sus-nommés régulièrement pour des pré-tests sur des maquettes et des versions intermédiaires. Enfin en appliquant les méthodes de suivi de la qualité et de mesure des performance adaptées avec sérieux et souplesse.
Pour résumer mon propos, non, ce n'est pas possible.
[^] # Re: Dériveur
Posté par totof2000 . Évalué à 2.
Euh … pas besoin de tout ça.
Sans aller sur une solution parfaitement stable, un peu plus de travail en amont sur la définition des use-case, et en mettant en place suffisamment de tests, on peut arriver a des choses un peu plus stables que ce que l'on trouve parfois.
Certains projets y arrivent, mais ça nécessite des moyens, et de faire des choix, trouver un équilibre entre la courses aux fonctionnalités et la stabilisation de l'existant.
Pour revenir au sujet initial, ce qui me dérange avec snap/flatpack, c'est qu'on essaie de répondre à deux besoins distincts, mais qui ne devraient pas être gérés par l'outil (ou la méthode pour le gérer n'est pas la bonne) :
- faciliter la vie du dév/packager
- sécuriser l'appli.
De ce fait le développeur prend en charge quelque chose qui n'est pas de son ressort (dans la sécurisation de l'appli, il ne doit s'assurer que de la sécurité du code). Et s'il prend en charge, il devient responsable. Du coup s'il devient responsable, pour éviter de se faire taper dessus il va verrouiller au max …. ce qui n'est pas forcément dans l'intéret de l'utilisateur.
[^] # Re: Dériveur
Posté par greendev . Évalué à -7.
C’est pas une question de compétences. Z’êtes tous formatés. À commencer par les informaticiens qui ont pris l’habitude de pondre du bloat, parce que le matos arrivait à suivre derrière…
[^] # Re: Dériveur
Posté par totof2000 . Évalué à 2.
Pourquoi le moinssage ? Ce n'est pas forcément la seule raison, mais que c'en est une.
[^] # Re: Dériveur
Posté par Xanatos . Évalué à 8.
Ptet parce que la forme du message n'enrichit pas le débat.
[^] # Re: Dériveur
Posté par greendev . Évalué à -10.
Oui et quand la forme du message c’est du 42ºC dans ta gueule ça t’arrache tellement qui tu préfères t’enfermer dans le déni.
[^] # Re: Dériveur
Posté par barmic 🦦 . É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 saltimbanque (site web personnel) . Évalué à 0.
Enfin un commentaire intéressant.
Avec quelques points
[^] # Re: Dériveur
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 21 août 2023 à 18:23.
À 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.
[^] # Re: Dériveur
Posté par Christophe "CHiPs" PETIT (site web personnel) . Évalué à 2.
Au début du mois, sur une vieille machine, je me suis battu avec Pipewire n'a pas été capable de sortir du son en HDMI avec une Ubuntu 23.04, alors que le PulseAudio de la 22.04 le fait par défaut.
Donc non ça passe pas crème…
[^] # Re: Dériveur
Posté par gnumdk (site web personnel) . Évalué à 1.
J'utilise Wayland et Flatpak, sur ma machine et les 400 ordis du parc au boulot, pas de problèmes, ça juste marche, contrairement à Xorg par exemple.
[^] # Re: Dériveur
Posté par zurvan . Évalué à 6.
facile de se vanter de la fonctionnalité d'une solution sur un parc de 400 machines, qui sont probablement toutes les mêmes, c'est le principe des services informatiques des grosses entreprises qui uniformisent tout.
Chez moi je n'ai réussi à faire fonctionner Wayland nulle part… et Xorg fonctionne parfaitement.
Et quand wayland démarre quand même, c'est cool d'indiquer aux utilisateurs de devoir parfois redémarrer sous Xorg parce que certains logiciels (libres) ne fonctionne pas correctement avec.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Dériveur
Posté par gnumdk (site web personnel) . Évalué à 3.
Euh, qui sont toutes les mêmes, certainement pas, c'est le désavantage des Universités qui n'ont plus de thunes…
[^] # Re: Dériveur
Posté par gnumdk (site web personnel) . Évalué à 2.
Genre?
[^] # Re: Dériveur
Posté par flagos . Évalué à 4.
La première version date de 2007, la première version considérée comme stable est de 2018. Je pense qu'on est bons sur ce critère, on est sur une timeline Waylandesque.
[^] # Cool ! J’ai hâte
Posté par greendev . Évalué à -2.
Vivement que GNU/Linux devienne un système aussi privateur et fermé qu’un Windows ou un Mac.
Là il sera prêt pour le Desktop !
…
Avec 0.5% de part de marché.
[^] # Re: Cool ! J’ai hâte
Posté par Yth (Mastodon) . Évalué à 4.
Et je serais toujours sous Slackware, qui n'aura toujours pas ces problèmes, et aura toujours 0,5% des parts de marché Linux, et était déjà prête pour le Desktop en 1999 (en tout cas plus que les windows de l'époque).
Bises :)
[^] # Re: Cool ! J’ai hâte
Posté par totof2000 . Évalué à 5.
Slackware : le premier Linux que j'ai installé …. j'y suis resté un moment. Puis je suis passé par d'autres, puis déçu à un moment ou Linux a perdu en stabilité, je suis passé sur NetBSD, puis FreeBSD (car certains softs dont j'avais besoin n'étaient pas portés sous NetBSD), avec en parallèle un retour à Linux (Ubuntu, du temps ou elle était un peu plus proche de Debian). Aujourd'hui je n'aime pas trop la direction prise par les distributions dites "majeures" … et j'envisage sérieusement de revenir à Slackware. Et si FreeBSD pouvait gérer la mise en veille de mon portable, j'y serais depuis longtemps.
[^] # Re: Dériveur
Posté par totof2000 . Évalué à 3. Dernière modification le 22 août 2023 à 15:39.
Perso je ne suis pas convaincu que Flatpack deviendra la norme, ou alors un flatpack v2 ….
Je vois plus snap/flatpack aujourd'hui comme un essai, et lorsque les devs auront suffisamment de maturité sur la tentative de résolution des problèmes que ces solutions sont censées régler (ou lorsque quelqu'un qui a une autre vision s'y mettra), on développera quelque chose de mieux. Mais encore faudra-t-il que de chaque côté les gens abandonnent un peu leur égo pour admettre que la solution qu'ils pronent n'est pas parfaite.
[^] # Re: Dériveur
Posté par greendev . Évalué à -3.
Ou alors on fait un poil attention à la rétrocompatibilité, à la stabilité des interfaces, on fait en sorte, de l’autre côté de moins donner de crédit au time-to-market (autre formatage purement capitalistique) pour ne pas chercher la lib dans sa dernière version bien trop hypée. Et ainsi on laisse les intégrateurs faire leur boulot sans leur compliquer la tâche.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.