Je ne sais pas si c'est du à la mise en page, ou tu a sréellement ce prompt, mais perso j'évite, et je le vire de toutes les machines de prod qui passent entre mes mains.
Une fois, au boulot, on s'est retrouvé avec des scripts qui ne fonctionnaient plus. En cherchant un peu, on s'est rendu compte qu'un binaire avait disparu. Pour quoi ? Parce que quelqu'un avait fait un copier/coller malencontreux et avait exécuté
> /chemin/vers/le/binaire
au lieu de
/chemin/vers/le/binaire
La personne avait fait un copier/coller qui prenait un caractère en trop (deux avec l'espace) sans s'en rendre compte … et en voulant aller vite n'a pas pris le temps de vérifier avant de valider sa frappe.
pour ceux qui connaissent la signification : "mais pourquoi se présentent-ils avec leur dénomination dans leur nom? quand j'achète une mercedes, la marque c'est pas VéhiculeMercédès, ni de TéléviseurSamsung ou encore de RégionBretagne ni TrainsSNCF"
Quand tu achètes une mercedes, tu n'achètes pas une mercédes. Tu achètes un modèle de la marque Mercedes, modèle qui a une désignation. D'ailleurs ce peut être une voiture ou un véhicule utilitaire.
De même quand tu achètes un téléphone sous IOS, ou un ordinateur sous MacOS, tu n'achètes pas un "IOS" ou un "macos". Tu achètes un ordinateur de la marque Apple, qui est soit un iMac, soit un MacBook, soit un Mac mini … équipé du système d'exploitation MacOS, également de la marque Apple.
IOS et MacOS ne sont pas des "marques" au même titre que Mercedes, mais des désignations de "modèles".
Ensuite jamais on achète "une SNCF" ou "un SNCF". On va acheter un service à la société SNCF.
Mais pour laisser le choix il faudrait mettre en place des interfaces standardisées permettant de le faire. Seule la législation pourrait permettre de mettre ce genre d'interface en place.
Ensuite, soit le constructeur fournit un truc tout fait en option, soit il laisse les utilisateurs choisir le produit de leur choix (Google, Apple, ou autre).
Pour l'utilisateur ça lui évite d'avoir des équipements redondants (système gps du véhicule + GPs autonome style Tom Tom + téléphone, autoradio du constructeur + radio via téléphone, etc …). Financièrement l'utilisateur pourrait s'y retrouver, et écologiquement je pense qu'on y gagnerait à économiser sur ces ressources.
Si tu veux un autre mot, la possibilité de fork est un moyen de pression pour que l'auteur initial ne fasse pas trop n'importe quoi. A noter que des fois ça ne marche pas du tout cf libav fork échoué de FFmpeg suite à désaccords de dev (mais toujours en libre) et tout le monde est repassé chez FFmpeg mais ça n'a pas été non plus été inutile car FFmpeg a aussi un peu changé suite au fork.
Il me semble d'ailleurs que certains projets ont forké, puis ont de nouveau fusionné après avoir réglé les différends. Mais le fork n'est pas non plus la seule possibilité : par exemple lorsque, dans ledomaine du son, OSS a voulu changer ses licences, le libre a créé ALSA. Ca veut dire que le fork est peut-être le moyen le plus simple pour faire pression sur un projet pour qu'il reste libre, mais il y a d'autres moyens de pression dans le cas ou un développeur ou éditeur voudrait "fermer" son logiciel.
une arme jamais utilisée quand il y a besoin n'est pas une arme.
C'est une vision bien belliqueuse du développement logiciel que tu as là. La possibilité de scission (ou fork) n'est pas forcément une arme. C'est une fonctionnalité, c'est tout.
Pour le reste, je suis assez d'accord avec ce que tu exprimes.
Posté par totof2000 .
En réponse à la dépêche Désolé, j'ai forké.
Évalué à 2.
Dernière modification le 25 août 2023 à 09:45.
Le droit à la scission (je ne sais pas pourquoi le mot anglais fork a été gardé dans la traduction)
Peut-être parce que la majorité de gens ne savent pas l'utiliser ?
on a le droit de scissionner
Tu m'apprends qu'on disait scissionner (je n'aurais jamais pensé que le verbe issu de la même raçine avait cette forme), et je ne suis pas sûr que tout le monde le sache ( j'aurais plutôt tourné ma phrase en disant "on a le droit de faire scission").
Peut-être aussi parce qu'un des synonymes de ce mot est "faire dissidence", et que dans le cadre d'un logiciel, ce terme ne reflète pas forcément la même idée que "fork" (dissidence est souvent employé avec une connotation négative, alors que fork me paraît plus neutre).
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.
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.
Je ne suis pas sûr de comprendre ou tu veux en venir (mais peut-être parce que moi-ùmême je n'ai pas forcément été clair non plus dans ce que je voulais exprimer).
LA stabilité ne signifie pas forcément l'immobilisme. On peut être suffisamment stable en mintenant la rétrocompatibilité au maximum, et ne se limiter qu'aux breaking changes réellements essentiels, tout en continuant à avancer et à fournir des nouvelles fonctionnalités.
Python est un bon exemple : je ne suis pas un fan de python, je ne suis pas non plus convaincu par certains changements apportés par Python3, mais il faut reconaître que la transition entre Python 2 et python 3 s'est faite en douceur. Python 2 et python 3 ont été maintenus suffisamment longtemps pour que les gens puissent apporter les changements à leur code. Python2 fournissait des bibliothèques (future, six) permettant d'écrire du code proche de python 3. Et de ce point de vue, que l'on aime ou pas Python, tout a été fait pour que la transition se fasse dans les meilleures conditions.
A l'opposé il existe des outils et des frameworks (GTK est souvent cité pour ça, mais ça a été aussi le cas de certains frameorks Javascript côté serveur ou côté client) qui ont eu quelques soucis de manque de rétrocompatibilité, pour lesquels les devs (enfin ceux que je connaissais) se sont plaint de devoir passer plus de temps à gérer les changements des couches basses et à réécrire du code qui fonctionnait très bien jusqu'aux changements en question plutôt que de développer leurs fonctionnalités (et manque de bol ils ont eu à ce moment là à gérer des changements sur plusieurs dépendances qui se sont étalées suffisamment longtemps pour que ça pénalise leur travail).
J'ai moi-même bossé dans une équipe qui développait des composants pour un outil de déploiement qui utilisait Ansible en couche basse, et une des contraintes que l'on s'était imposé c'était de n'introduire des breaking changes uniquement quand c'était nécessaire, et de maintenir suffisamment longtemps les versions N-1 (en terme de correction de bugs) pour laisser suffisamment de temps aux utilisateurs pour faire la transition (leur métier n'étant pas de s'adapter aux outils de déploiement, mais d'écrire du code et de le déployer (avec l'infra sous-jacente) de la manière la plus simple qui soit.
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.
# Du danger du prompt ">"
Posté par totof2000 . En réponse au message Un bug dans les shell ?!!!! Mais en fait non (Linux fuck Posix). Évalué à 10. Dernière modification le 27 août 2023 à 19:19.
Je ne sais pas si c'est du à la mise en page, ou tu a sréellement ce prompt, mais perso j'évite, et je le vire de toutes les machines de prod qui passent entre mes mains.
Une fois, au boulot, on s'est retrouvé avec des scripts qui ne fonctionnaient plus. En cherchant un peu, on s'est rendu compte qu'un binaire avait disparu. Pour quoi ? Parce que quelqu'un avait fait un copier/coller malencontreux et avait exécuté
au lieu de
La personne avait fait un copier/coller qui prenait un caractère en trop (deux avec l'espace) sans s'en rendre compte … et en voulant aller vite n'a pas pris le temps de vérifier avant de valider sa frappe.
[^] # Re: 80's OS
Posté par totof2000 . En réponse au journal mais pourquoi s'appellent ils tous "OS"?. Évalué à 2.
Un os tellement chiant qu'à force de l'utiliser tu te fatigues et tu vas dormir.
# faille dans le raisonnement.
Posté par totof2000 . En réponse au journal mais pourquoi s'appellent ils tous "OS"?. Évalué à 3. Dernière modification le 27 août 2023 à 08:24.
Quand tu achètes une mercedes, tu n'achètes pas une mercédes. Tu achètes un modèle de la marque Mercedes, modèle qui a une désignation. D'ailleurs ce peut être une voiture ou un véhicule utilitaire.
De même quand tu achètes un téléphone sous IOS, ou un ordinateur sous MacOS, tu n'achètes pas un "IOS" ou un "macos". Tu achètes un ordinateur de la marque Apple, qui est soit un iMac, soit un MacBook, soit un Mac mini … équipé du système d'exploitation MacOS, également de la marque Apple.
IOS et MacOS ne sont pas des "marques" au même titre que Mercedes, mais des désignations de "modèles".
Ensuite jamais on achète "une SNCF" ou "un SNCF". On va acheter un service à la société SNCF.
# il faudrait laisser le choix à l'utilisateur ...
Posté par totof2000 . En réponse au journal Les tribulations d’un GPS embarqué, encore… Et l'avenir , Android Auto et Carplay ?. Évalué à 5.
Mais pour laisser le choix il faudrait mettre en place des interfaces standardisées permettant de le faire. Seule la législation pourrait permettre de mettre ce genre d'interface en place.
Ensuite, soit le constructeur fournit un truc tout fait en option, soit il laisse les utilisateurs choisir le produit de leur choix (Google, Apple, ou autre).
Pour l'utilisateur ça lui évite d'avoir des équipements redondants (système gps du véhicule + GPs autonome style Tom Tom + téléphone, autoradio du constructeur + radio via téléphone, etc …). Financièrement l'utilisateur pourrait s'y retrouver, et écologiquement je pense qu'on y gagnerait à économiser sur ces ressources.
[^] # Re: encore merci le libre
Posté par totof2000 . En réponse à la dépêche Désolé, j'ai forké. Évalué à 2.
Il me semble d'ailleurs que certains projets ont forké, puis ont de nouveau fusionné après avoir réglé les différends. Mais le fork n'est pas non plus la seule possibilité : par exemple lorsque, dans ledomaine du son, OSS a voulu changer ses licences, le libre a créé ALSA. Ca veut dire que le fork est peut-être le moyen le plus simple pour faire pression sur un projet pour qu'il reste libre, mais il y a d'autres moyens de pression dans le cas ou un développeur ou éditeur voudrait "fermer" son logiciel.
[^] # Re: Oui, on a le droit
Posté par totof2000 . En réponse à la dépêche Désolé, j'ai forké. Évalué à 3.
Si je n'avais été "influencé" par la scission, je pense que c'est auusi le terme qui me serait venu à l'esprit.
[^] # Re: encore merci le libre
Posté par totof2000 . En réponse à la dépêche Désolé, j'ai forké. Évalué à 1.
C'est une vision bien belliqueuse du développement logiciel que tu as là. La possibilité de scission (ou fork) n'est pas forcément une arme. C'est une fonctionnalité, c'est tout.
Pour le reste, je suis assez d'accord avec ce que tu exprimes.
[^] # Re: Oui, on a le droit
Posté par totof2000 . En réponse à la dépêche Désolé, j'ai forké. Évalué à 2. Dernière modification le 25 août 2023 à 09:45.
Peut-être parce que la majorité de gens ne savent pas l'utiliser ?
Tu m'apprends qu'on disait scissionner (je n'aurais jamais pensé que le verbe issu de la même raçine avait cette forme), et je ne suis pas sûr que tout le monde le sache ( j'aurais plutôt tourné ma phrase en disant "on a le droit de faire scission").
Peut-être aussi parce qu'un des synonymes de ce mot est "faire dissidence", et que dans le cadre d'un logiciel, ce terme ne reflète pas forcément la même idée que "fork" (dissidence est souvent employé avec une connotation négative, alors que fork me paraît plus neutre).
[^] # 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.
Pourquoi le moinssage ? Ce n'est pas forcément la seule raison, mais que c'en est une.
[^] # Re: Flatseal
Posté par totof2000 . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. É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 totof2000 . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. É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: 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é à 3.
Je ne suis pas sûr de comprendre ou tu veux en venir (mais peut-être parce que moi-ùmême je n'ai pas forcément été clair non plus dans ce que je voulais exprimer).
LA stabilité ne signifie pas forcément l'immobilisme. On peut être suffisamment stable en mintenant la rétrocompatibilité au maximum, et ne se limiter qu'aux breaking changes réellements essentiels, tout en continuant à avancer et à fournir des nouvelles fonctionnalités.
Python est un bon exemple : je ne suis pas un fan de python, je ne suis pas non plus convaincu par certains changements apportés par Python3, mais il faut reconaître que la transition entre Python 2 et python 3 s'est faite en douceur. Python 2 et python 3 ont été maintenus suffisamment longtemps pour que les gens puissent apporter les changements à leur code. Python2 fournissait des bibliothèques (future, six) permettant d'écrire du code proche de python 3. Et de ce point de vue, que l'on aime ou pas Python, tout a été fait pour que la transition se fasse dans les meilleures conditions.
A l'opposé il existe des outils et des frameworks (GTK est souvent cité pour ça, mais ça a été aussi le cas de certains frameorks Javascript côté serveur ou côté client) qui ont eu quelques soucis de manque de rétrocompatibilité, pour lesquels les devs (enfin ceux que je connaissais) se sont plaint de devoir passer plus de temps à gérer les changements des couches basses et à réécrire du code qui fonctionnait très bien jusqu'aux changements en question plutôt que de développer leurs fonctionnalités (et manque de bol ils ont eu à ce moment là à gérer des changements sur plusieurs dépendances qui se sont étalées suffisamment longtemps pour que ça pénalise leur travail).
J'ai moi-même bossé dans une équipe qui développait des composants pour un outil de déploiement qui utilisait Ansible en couche basse, et une des contraintes que l'on s'était imposé c'était de n'introduire des breaking changes uniquement quand c'était nécessaire, et de maintenir suffisamment longtemps les versions N-1 (en terme de correction de bugs) pour laisser suffisamment de temps aux utilisateurs pour faire la transition (leur métier n'étant pas de s'adapter aux outils de déploiement, mais d'écrire du code et de le déployer (avec l'infra sous-jacente) de la manière la plus simple qui soit.
[^] # 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.