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.
ne jamais savoir où chercher les configurations etc.
Tu donnes la réponse dans ta phrase :)
Plus sérieusement … personnelleemnt c'est la mode actuelle d'éparpiller dela conf dans /etc, puis dans /usr,lib (je crois que systemd permet d'en mettre ailleurs si ma mémoire est bonne) qui commence à me fatiguer. A une époque on n'avait pas à se prendre la tête : la conf était dans /etc. On peut reprocher que certaines distrib ou certains logiciels y aient misu n peu tout et n'importe quoi, mais tout le monde n'a pas fait de la merde, on a des OS ou es distrib qui ont su garder un dossier /etc plutôt propre (xBSD par exemple).
Maintenant on a des softs qui poussent la conf dans /etc, d'autres qui mettent un bout dans/etc et un autre dans /var/lib (et peut-être ailleurs), ce qui est assez pénible.
Si on avait de l'IPv6 partout cela ne poserait aucun problème. Le fait est qu'il n'y a plus d'IP v4 et que les accès en IPV4 via le réseau mobile ne sont pas de l'Internet (au mieux c'est du partage d'IP au pire du CGNAT). Mais cela n'a rien à voir avec la 5G et cela touche tous les réseaux : filaire et hertzien.
Le mobile est quand même bien plus concerné par cette problématique que le filaire : il a été conçu ainsi à l'origine, et fournir une IP accessible depuis l'extérieur à chaque terminal (même avec l'IP V6) telle qu'il est possible de le faire aujourd'huii avec le filaire nécessiterait de toucher au coeur du fonctionnement du réseau mobile (2/3/4/5G chez les FAI), et ne doit pas être si simple que ça. Mettre à disposition des IP accessible depuis l'extérieur dans le domaine du fixe est quelque chose qui existe depuis le début, et même si on commence à trouver les mêmes contournements que ce que l'on trouve dans le mobile sur le fixe depuis quelque temps, laisser la possibilité à ceux qui en ont besoin d'avoir une IP V4 classique (comme le fait free), reste moins couteux à mettre en oeuvre, vu que ça existe déjà.
En tout cas j'espère qu'avec une bascule généralisée vers IPV6, on pourra bientôt se débarasser de tous les artifices mis en place pour pallier le manque d'IPV4 tant dans le filaire que dans le mobile.
Je partage le point de vue sur le bilan global. Lorsque j'étais chez Orange il était question avant tout de cout de déploiement. Le bilan énergétique et le bilan carbone n'étaient pas forcément pris en compte (pas sûr qu'on était en mesure de réelleemt l'évaluer). Le focus devait probablement être sur le coût de déploiement. L'idée était peut-être également de voir cette techno comme une techno de transition, pour éviter de perdre trop de clients sur le haut débit fixe dans les zones ou les opérateurs n'auraient pas eu le temps de déployer leur réseau, ou pour éviter d'avoir à négocier des prix de mise à dispositon du réseau d'un concurrent. C'est pour ça que j'avais écrit que l'intéret n'était pas forcément chez les utilisateurs (avec leur téléphone mobile) mais chez les FAI, pour fournir du haut débit à tout le monde, avec des couts de déploiement réduits, ce qui explique à mon avis l'engouement des opérateurs sur cette techno. C'était clairement une piste envisagée à l'époque.
Ls récentes augmentations du prix de l'énergie, ainsi que les contraintes sur le bilan carbone ont probablement rebattu les cartes, mais je pense que le bilan global de la 5G dans certaines zones est plus intéressant que la fibre. Mais ce n'est que mon nez qui me fait penser ça : je serais curieux de voir des études, suffisamment récentes pour prendre en compte les évolutions du prix de l'énergie, ou permettant d'estimer facilement le surcoût lié aux évolutions de ceux-ci.
Avant, quand l mode graphique ne fonctionnait pas on pouvait facimement démarrer le système soit en single, avec un mode texte vga standard, ce qui permettait de réparer facilemment les problèmes.
Aujourd'hui j'ai l'impression que démarrer un système en mode texte basique, en démarrant tout sauf la couche graphique, est devenu quasi impossible - sauf à utiliser un recovery media.
[^] # 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.
[^] # Re: Ce troll de compèt c’est pour vendredi ?
Posté par totof2000 . En réponse au lien $HOME, Not So Sweet $HOME. Évalué à 3.
Bof …
Tu donnes la réponse dans ta phrase :)
Plus sérieusement … personnelleemnt c'est la mode actuelle d'éparpiller dela conf dans /etc, puis dans /usr,lib (je crois que systemd permet d'en mettre ailleurs si ma mémoire est bonne) qui commence à me fatiguer. A une époque on n'avait pas à se prendre la tête : la conf était dans /etc. On peut reprocher que certaines distrib ou certains logiciels y aient misu n peu tout et n'importe quoi, mais tout le monde n'a pas fait de la merde, on a des OS ou es distrib qui ont su garder un dossier /etc plutôt propre (xBSD par exemple).
Maintenant on a des softs qui poussent la conf dans /etc, d'autres qui mettent un bout dans/etc et un autre dans /var/lib (et peut-être ailleurs), ce qui est assez pénible.
# Je ne sais pas si ton problème est résolu mais ...
Posté par totof2000 . En réponse au message Plusieurs problèmes depuis l'installation. Évalué à 2.
Il y a peut-être des pistes à explorer sur ce post
[^] # 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é à 2.
Le mobile est quand même bien plus concerné par cette problématique que le filaire : il a été conçu ainsi à l'origine, et fournir une IP accessible depuis l'extérieur à chaque terminal (même avec l'IP V6) telle qu'il est possible de le faire aujourd'huii avec le filaire nécessiterait de toucher au coeur du fonctionnement du réseau mobile (2/3/4/5G chez les FAI), et ne doit pas être si simple que ça. Mettre à disposition des IP accessible depuis l'extérieur dans le domaine du fixe est quelque chose qui existe depuis le début, et même si on commence à trouver les mêmes contournements que ce que l'on trouve dans le mobile sur le fixe depuis quelque temps, laisser la possibilité à ceux qui en ont besoin d'avoir une IP V4 classique (comme le fait free), reste moins couteux à mettre en oeuvre, vu que ça existe déjà.
En tout cas j'espère qu'avec une bascule généralisée vers IPV6, on pourra bientôt se débarasser de tous les artifices mis en place pour pallier le manque d'IPV4 tant dans le filaire que dans le mobile.
[^] # 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é à 2.
Je partage le point de vue sur le bilan global. Lorsque j'étais chez Orange il était question avant tout de cout de déploiement. Le bilan énergétique et le bilan carbone n'étaient pas forcément pris en compte (pas sûr qu'on était en mesure de réelleemt l'évaluer). Le focus devait probablement être sur le coût de déploiement. L'idée était peut-être également de voir cette techno comme une techno de transition, pour éviter de perdre trop de clients sur le haut débit fixe dans les zones ou les opérateurs n'auraient pas eu le temps de déployer leur réseau, ou pour éviter d'avoir à négocier des prix de mise à dispositon du réseau d'un concurrent. C'est pour ça que j'avais écrit que l'intéret n'était pas forcément chez les utilisateurs (avec leur téléphone mobile) mais chez les FAI, pour fournir du haut débit à tout le monde, avec des couts de déploiement réduits, ce qui explique à mon avis l'engouement des opérateurs sur cette techno. C'était clairement une piste envisagée à l'époque.
Ls récentes augmentations du prix de l'énergie, ainsi que les contraintes sur le bilan carbone ont probablement rebattu les cartes, mais je pense que le bilan global de la 5G dans certaines zones est plus intéressant que la fibre. Mais ce n'est que mon nez qui me fait penser ça : je serais curieux de voir des études, suffisamment récentes pour prendre en compte les évolutions du prix de l'énergie, ou permettant d'estimer facilement le surcoût lié aux évolutions de ceux-ci.
# Un démarrage en mode texte classique (sans frame buffer) - c'est plus possible ?
Posté par totof2000 . En réponse au message Écran noir un peu après GRUB.. Évalué à 3.
Avant, quand l mode graphique ne fonctionnait pas on pouvait facimement démarrer le système soit en single, avec un mode texte vga standard, ce qui permettait de réparer facilemment les problèmes.
Aujourd'hui j'ai l'impression que démarrer un système en mode texte basique, en démarrant tout sauf la couche graphique, est devenu quasi impossible - sauf à utiliser un recovery media.
Je trouve que c'est une belle régression.