Bah on va te dire que c'est de ta faute, qu'il faut patcher tes systèmes toutes les semaines pour gérer la dette technique au fil de l'eau …
sauf que … il faut comprendre un truc: les devs n'ont pas forcément le temps d'adapter leur code à toutes les versions des frameworks sous-jacents : leur job c'est de développer de nouvelles fonctionnalités. Ca ne veut pas dire qu'il faut rester dans l'immobilisme par rapport aux couches basses, mais que plus les couches sont basses, olus il faut qu'elles soient stables dans le temps (je ne suis pas sûr que les devs gnome seraient content si la libc cassait la rétropcompatibilité et changeait tous les 4 matins).
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.
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.
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.
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.
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.
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.
totof@superbipbip:/usr/local/bin$ wmaker
wmaker: error while loading shared libraries: libWINGs.so.3: cannot open shared object file: No such file or directory
Je regarde ce qui se passe (mais j'ai ma petite idée).
Je suis vraiment curieux de savoir si c'est bien ça le problème. Ca confirme un problème au niveau de ldconfig qui n'arrive pas à localiser la lib, non pas parce qu'il est mal configuré, mais parce qu'il attend un pattern au niveau des liens qui ne serait pas respecté.
Utiliser LD_LIBRARY_PATH aurait permis je pense de trouver la lib en question et de lancer le binaire, mais je pense que c'est plus propre d'utiliser les liens comme attendu par ldconfig (pas de paramétrage de variables d'environnement dans les scripts de lancement).
Je viens de voir un truc dans la man page de ldconfig :
Note that ldconfig will only look at files that are named lib*.so* (for
regular shared objects) or ld-.so (for the dynamic loader itself).
Other files will be ignored. Also, ldconfig expects a certain pattern
to how the symlinks are set up, like this example, where the middle
file (libfoo.so.1 here) is the SONAME for the library:
libfoo.so -> libfoo.so.1 -> libfoo.so.1.12
Or, quand je regarde le contenu de /usr/local/lib:
Le problème, c'est qu'ubuntu fournit de plus en plus de softs uniquement en snap. Redhat semble partir sur la même voie avec flatpack. Perso ce qui me dérange, c'est le fait que ces solutions retirent, sous pretexte de sécurité, un certain contrôle à l'utilisateur (voir un de mes journaux sur le sujet), sans donner de moyen à l'utilisateur de configurer le truc our qu'il adapte la solution à ses besoins.
Aujourd'hui sur mon portable je suis aussi en ubuntu 22.04, mais je pense que je ne passerai pas sur la prochaine LTS. J'envisage de changer completement de distribution ( retour aux sources avec une slackware ? ou tester un FreeBSD - et le garder s'il gère la mise en hibernation lorsque je ferme l'écran de mon portable ? ou, comme j'utilise Enlightenment comme environnement de bureau, pourquoi pas une bodhi linux).
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.
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é.
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é.
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.
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.
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?
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).
Si la réponse est non, peut-être que le plus simple aurait été de te contenter de cette version.
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"
Et au final des solutions ont été évoquées aux problèmes mentionnés.
Ben en regardant d'un peu plus près, j'ai l'impression justement qu'il n'y a pas de solution.
L'upgrade ne changera rien si tu as compilé window maker par tes propres moyens.
il faudrait faire un ldd sur le binaire window maker, ppour savoir ou il va chercher la lib.
Si il ne la trouve pas, tu fais un export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib et tu relances ldd sur le binaire. Si ça fonctionne c'est que la configuration du linker dynamique n'inclut pas le chemin d'installation de ta lib, et qu'il faut le parametrer (dans /etc/ld.so.conf et/ou /etc/ld.so.conf.d, man ldconfig)
Ca me rappelle de souvenirs de compilation sous slackware … ou quand je travaillais à la R&D EDF sur la compilation des logiciels libres pour les systèmes proprios (Solaris, HP-UX, SGI Irix, IBM AIX …).
Il est à priori possible de laisser le préfixe par défaut (si tu ne veux pas mélanger ton installation avec le reste) mais d'aller chercher les librairies ailleurs avec les options --with-libs-from="-L/usr/lib" et --with-incs-from="-I/usr/include -I/usr/include/tiff" par exemple.
Sauf erreur de ma part, il me semble que l'option -L (ou with_lib) est une option utilisée à la compilation (corrigez-moi si je me trompe), tandis que le problème mentionné se trouve à l'exécution.
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.
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.
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.
Posté par totof2000 .
En réponse au message Popularité de la 5G ?.
Évalué à 3.
Dernière modification le 20 août 2023 à 17:48.
l'idée reste d'avoir la techno la plus efficace partout (la fibre) et pas la moins chère à déployer, pour les organisations concernées
C'est une vision bien naïve de ce qui se passe dans le monde.
Un fournisseur de bien ou de service favorisera le produit qui lui permettra de dégager le plus de marge, quel que soit l domaine (assurance, finance, FAI, services, …) quitte à ignorer certains besoins (parce au'il ne dégagera pas assez de marge pour le mettre en oeuvre). Ne considérez jamais votre "conseiller financier" comme un conseiller : ne le voyez que pour ce qu'il n'est : un commercial qui cherche à se faire de l'argent.
voyez le caractère illogique et déraisonné du "tout par la cinqgé" qui commence à tuer à petit feu les lignes fixes…
vu sur un article du figaro, un commentateur rouspetant des dérives du déploiement de la fibre, qui recommandait de "mettre toute la france sous 5G uniquement probleme résolu"
Ben oui, pour le fournisseur ça coute moins cher … Et d'ailleurs le déploiement de la fibre est un exemple de ce qui se passe aujourd'hui en général et d'une mentalité que je qualifierai "de merde" un peu partout : on fait viter, mal sans se poser de question sur les conséquences à long terme : du coup on déploie des trucs dégueulasses (il suffit de voir certains points de concentration mis en place par les opérateur) … on fait faire ça pas cher par des sous-traitants de sous-traitants, on laisse la merde s'étaler … jusqu'au momant ou ça ne tient plus. Sauf que l'on considère ça comme un "point de non retour" (qui n'en est pas un, juste que ça coute un bras à pouvoir remettre les choses en ordre), alors qu'en faisant les choses correctement dès le début, et en traîtant les problèmes au fur et à mesure plutôt que de les laisser se développer jusqu'à ce que ça devienne ingérable, certes ça prend un peu de temps dans l'immédiat, mais sur le moyen/long terme ça coute moins cher.
On fait les mêmes erreurs que dans le développement des SI.
Ah juste une question : mis à part wikipedia, je n'ai aucune référence qui indique que ce standard a été généré et validé par d'autres instances que la Linux Foundation.Il me semble donc que ce soit une spécificité linux (celà dit si vous avez des sources autres que wikipedia, je suis preneur). Et quand tu bosses dans un monde ou tu as des unix divers et variés, tu t'arranges pour garder une certaine cohérence dans ton parc. Et le fait que d'autres systèmes Unix, qui sont arrivés avant, avec d'autres pratiques pèse dans la balance quand tu dois décider ou non de suivre une norme.
C'est effectivement différent quand tu pars de zero, mais quand il y a de l'existant, c'est autre chose.
Certains systèmes mettent les configurations système par defaut dans /etc:default (exemple freebsd). Je ne suis pas allé voir si la logique était respectée pour les configuration dans /usr/local/etc (là ou la conf des paquets est censée se trouver) par contre. Mais j'avais aussi vu des trucs dans /usr/share pour certains softs (mais je ne me rappelais plus de ça avant que tu poste ton message).
/srv est une recommandation qui est arrivée bien tard : les systèmes Unix classique montent tout ça dans /var. /var/db (ou variante) pour les bases de données, et dans certaines socété, c'est totalement autre chose (/data, ou un point de montage avec des règles à la con - dont certaines s'inspirent des mainframes IBM) …
FSH est une recommandation qui est arrivée bien tard, qui n'est pas toujours respectée pour des raisons historiques. Sinon si j'en crois la page wikipedia /var/www et /var/db sont conformes à FSH.
[^] # Re: L'histoire se répète
Posté par totof2000 . 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.
Bah on va te dire que c'est de ta faute, qu'il faut patcher tes systèmes toutes les semaines pour gérer la dette technique au fil de l'eau …
sauf que … il faut comprendre un truc: les devs n'ont pas forcément le temps d'adapter leur code à toutes les versions des frameworks sous-jacents : leur job c'est de développer de nouvelles fonctionnalités. Ca ne veut pas dire qu'il faut rester dans l'immobilisme par rapport aux couches basses, mais que plus les couches sont basses, olus il faut qu'elles soient stables dans le temps (je ne suis pas sûr que les devs gnome seraient content si la libc cassait la rétropcompatibilité et changeait tous les 4 matins).
[^] # Re: Flatseal
Posté par totof2000 . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. É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: Cool ! J’ai hâte
Posté par totof2000 . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. É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: Flatseal
Posté par totof2000 . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. É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: Dériveur
Posté par totof2000 . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. É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 totof2000 . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. É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: Etrange
Posté par totof2000 . En réponse au message Échec au démarrage de windowmaker 0.96 (libwraster). Évalué à 3.
J'ai exécuté un ldconfig pour rafraichir le cache du chargeur dynamique, et à priori ça fonctionne. JHe n'ai plus de lib not found.
Merci au posteur initial pour cette demande, ça m'a redonné envie de faire certaines choses.
[^] # Re: trouvé...
Posté par totof2000 . En réponse au message Échec au démarrage de windowmaker 0.96 (libwraster). Évalué à 5.
Ah … je vois.
Merci pour le retour.
[^] # Re: Etrange
Posté par totof2000 . En réponse au message Échec au démarrage de windowmaker 0.96 (libwraster). Évalué à 2.
J'ai réussi à reproduire le problème :
Je regarde ce qui se passe (mais j'ai ma petite idée).
[^] # Re: Etrange
Posté par totof2000 . En réponse au message Échec au démarrage de windowmaker 0.96 (libwraster). Évalué à 3.
Je suis vraiment curieux de savoir si c'est bien ça le problème. Ca confirme un problème au niveau de ldconfig qui n'arrive pas à localiser la lib, non pas parce qu'il est mal configuré, mais parce qu'il attend un pattern au niveau des liens qui ne serait pas respecté.
Utiliser LD_LIBRARY_PATH aurait permis je pense de trouver la lib en question et de lancer le binaire, mais je pense que c'est plus propre d'utiliser les liens comme attendu par ldconfig (pas de paramétrage de variables d'environnement dans les scripts de lancement).
[^] # Re: Etrange
Posté par totof2000 . En réponse au message Échec au démarrage de windowmaker 0.96 (libwraster). Évalué à 3.
Je viens de voir un truc dans la man page de ldconfig :
Or, quand je regarde le contenu de /usr/local/lib:
sauf si mes yeux me trompent tu devrais plutot avoir :
/usr/local/lib/libwraster.so => /usr/local/lib/libwraster.so.6
et
/usr/local/lib/libwraster.so.6 => libwraster.so.6.1.0
En essayant de construire les liens comme demandé par ldconfig, peut-être que ça marchera mieux ?
[^] # Re: apt purge snapd
Posté par totof2000 . En réponse au message F..k snap ! , passer à Mint ou LMDE ?. Évalué à 6.
Le problème, c'est qu'ubuntu fournit de plus en plus de softs uniquement en snap. Redhat semble partir sur la même voie avec flatpack. Perso ce qui me dérange, c'est le fait que ces solutions retirent, sous pretexte de sécurité, un certain contrôle à l'utilisateur (voir un de mes journaux sur le sujet), sans donner de moyen à l'utilisateur de configurer le truc our qu'il adapte la solution à ses besoins.
Aujourd'hui sur mon portable je suis aussi en ubuntu 22.04, mais je pense que je ne passerai pas sur la prochaine LTS. J'envisage de changer completement de distribution ( retour aux sources avec une slackware ? ou tester un FreeBSD - et le garder s'il gère la mise en hibernation lorsque je ferme l'écran de mon portable ? ou, comme j'utilise Enlightenment comme environnement de bureau, pourquoi pas une bodhi linux).
[^] # Re: dossiers xdg-user-dirs
Posté par totof2000 . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. É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: titre inadapté et course à la dernière version.
Posté par totof2000 . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. É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: Etrange
Posté par totof2000 . En réponse au message Échec au démarrage de windowmaker 0.96 (libwraster). Évalué à 4. Dernière modification le 21 août 2023 à 11:21.
Bon finalement en relisant les messages, je me dis que ça ne changera pas grand chose : je n'avais pas bien compris la nature du problème.
Du coup je suis allé voir ce que Google en pensait et j'ai trouvé ça :
https://bugs.launchpad.net/ubuntu/+source/wmaker/+bug/2023942
Une piste ?
J'en ai trouvé un autre :
https://www.linuxquestions.org/questions/linux-software-2/window-maker-install-error-175305/
Ca confirme pour moi une mauvaise config au niveau du linker dynamique.
[^] # Re: Etrange
Posté par totof2000 . En réponse au message Échec au démarrage de windowmaker 0.96 (libwraster). Évalué à 4. Dernière modification le 21 août 2023 à 11:13.
L'upgrade ne changera rien si tu as compilé window maker par tes propres moyens.
il faudrait faire un ldd sur le binaire window maker, ppour savoir ou il va chercher la lib.
Si il ne la trouve pas, tu fais un export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib et tu relances ldd sur le binaire. Si ça fonctionne c'est que la configuration du linker dynamique n'inclut pas le chemin d'installation de ta lib, et qu'il faut le parametrer (dans /etc/ld.so.conf et/ou /etc/ld.so.conf.d, man ldconfig)
Ca me rappelle de souvenirs de compilation sous slackware … ou quand je travaillais à la R&D EDF sur la compilation des logiciels libres pour les systèmes proprios (Solaris, HP-UX, SGI Irix, IBM AIX …).
[^] # Re: Problème de préfixe
Posté par totof2000 . En réponse au message Échec au démarrage de windowmaker 0.96 (libwraster). Évalué à 3.
Sauf erreur de ma part, il me semble que l'option -L (ou with_lib) est une option utilisée à la compilation (corrigez-moi si je me trompe), tandis que le problème mentionné se trouve à l'exécution.
[^] # Re: Flatseal
Posté par totof2000 . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. É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 totof2000 . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. É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: dossiers xdg-user-dirs
Posté par totof2000 . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. É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: C'est un pas à passer qui prendra du temps, mais qui a mon avis a beaucoup d'intéret.
Posté par totof2000 . En réponse au message Popularité de la 5G ?. Évalué à 3. Dernière modification le 20 août 2023 à 17:48.
C'est une vision bien naïve de ce qui se passe dans le monde.
Un fournisseur de bien ou de service favorisera le produit qui lui permettra de dégager le plus de marge, quel que soit l domaine (assurance, finance, FAI, services, …) quitte à ignorer certains besoins (parce au'il ne dégagera pas assez de marge pour le mettre en oeuvre). Ne considérez jamais votre "conseiller financier" comme un conseiller : ne le voyez que pour ce qu'il n'est : un commercial qui cherche à se faire de l'argent.
Ben oui, pour le fournisseur ça coute moins cher … Et d'ailleurs le déploiement de la fibre est un exemple de ce qui se passe aujourd'hui en général et d'une mentalité que je qualifierai "de merde" un peu partout : on fait viter, mal sans se poser de question sur les conséquences à long terme : du coup on déploie des trucs dégueulasses (il suffit de voir certains points de concentration mis en place par les opérateur) … on fait faire ça pas cher par des sous-traitants de sous-traitants, on laisse la merde s'étaler … jusqu'au momant ou ça ne tient plus. Sauf que l'on considère ça comme un "point de non retour" (qui n'en est pas un, juste que ça coute un bras à pouvoir remettre les choses en ordre), alors qu'en faisant les choses correctement dès le début, et en traîtant les problèmes au fur et à mesure plutôt que de les laisser se développer jusqu'à ce que ça devienne ingérable, certes ça prend un peu de temps dans l'immédiat, mais sur le moyen/long terme ça coute moins cher.
On fait les mêmes erreurs que dans le développement des SI.
[^] # Re: Ce troll de compèt c’est pour vendredi ?
Posté par totof2000 . En réponse au lien $HOME, Not So Sweet $HOME. Évalué à 2.
Ah juste une question : mis à part wikipedia, je n'ai aucune référence qui indique que ce standard a été généré et validé par d'autres instances que la Linux Foundation.Il me semble donc que ce soit une spécificité linux (celà dit si vous avez des sources autres que wikipedia, je suis preneur). Et quand tu bosses dans un monde ou tu as des unix divers et variés, tu t'arranges pour garder une certaine cohérence dans ton parc. Et le fait que d'autres systèmes Unix, qui sont arrivés avant, avec d'autres pratiques pèse dans la balance quand tu dois décider ou non de suivre une norme.
C'est effectivement différent quand tu pars de zero, mais quand il y a de l'existant, c'est autre chose.
[^] # Re: Ce troll de compèt c’est pour vendredi ?
Posté par totof2000 . En réponse au lien $HOME, Not So Sweet $HOME. Évalué à 2.
Euh … 2004 alors que des entreprises ou des éditeurs avaient déjà des pratiques en terme de nommage de dossiers depuis les années 90. OPui c'est tard.
[^] # Re: Ce troll de compèt c’est pour vendredi ?
Posté par totof2000 . En réponse au lien $HOME, Not So Sweet $HOME. Évalué à 2.
Certains systèmes mettent les configurations système par defaut dans /etc:default (exemple freebsd). Je ne suis pas allé voir si la logique était respectée pour les configuration dans /usr/local/etc (là ou la conf des paquets est censée se trouver) par contre. Mais j'avais aussi vu des trucs dans /usr/share pour certains softs (mais je ne me rappelais plus de ça avant que tu poste ton message).
[^] # Re: Ce troll de compèt c’est pour vendredi ?
Posté par totof2000 . En réponse au lien $HOME, Not So Sweet $HOME. Évalué à 2.
/srv est une recommandation qui est arrivée bien tard : les systèmes Unix classique montent tout ça dans /var. /var/db (ou variante) pour les bases de données, et dans certaines socété, c'est totalement autre chose (/data, ou un point de montage avec des règles à la con - dont certaines s'inspirent des mainframes IBM) …
FSH est une recommandation qui est arrivée bien tard, qui n'est pas toujours respectée pour des raisons historiques. Sinon si j'en crois la page wikipedia /var/www et /var/db sont conformes à FSH.