Pour l'avis sur le second intérêt, je ne pense pas que ça soit inefficace, ça rend la chose plus explicite, donc ça peut-permettre de critiquer plus facilement par exemple. Si on hésite entre deux applications pour faire une chose, avoir cette info peut aider à choisir. Mais je suis d'accords ça ne va pas corriger seul les problèmes de façon magique.
Il me semble que ce n'est pas de permissions bidons, mais de données bidons (fake) dont il est question.
La mise en place ne me semble pas évidente, enfin dans le sens où si on veut avoir des applications qui accèdent aux données valides, et d'autres à des données bidons, il faut que ça soit géré au niveau du système d'accès.
Mais par contre je suis à 100% avec l'idée, j'avais déjà essayé ce genre de chose pour la position gps sur smartphone.
Ça me fait penser une critique que j'ai envers les restrictions d'accès aux fichiers sous Android, et avec les portails Flatpak.
Aujourd'hui, on peut ne pas autoriser une application à avoir accès aux fichiers de l'utilisateur (par exemple), mais dans ce cas on ne peut pas ouvrir un fichier spécifique avec cette application.
J'aimerais pouvoir interdire l'accès d'une application à tous les fichiers, mais que si je fais "ouvrir avec" à partir de l'explorateur (par exemple), l'application puisse dans ce cas ouvrir le fichier.
Après bien sur ça ouvre des questions qui font que ce n'est pas aussi simple que ça pourrait paraître :
- en lecture seulement ou aussi en écriture, si c'est au choix de l'utilisateur, ça veut dire qu'il faut que ça soit proposé dans l'interface.
- juste pour cette fois, où jusqu'à ce que l'autorisation soit (éventuellement) retirée.
J'ai vu passé des échanges qui pourrais concerner des travaux dans ce sens dans le système de "portails freedesktop", mais je n'ai pas creusé, je ne suis pas certain.
Oui, même si ce n'est pas très mis en avant, il y a aussi moyen en Rust de faire des librairies partagées dynamique ou statique.
Rust utilise l'ABI C pour ça (et pour l’interaction avec d'autres langages)
Plus d'info dans la doc : Linkage
Si il y a plusieurs processus qui utilisent un même programme Rust, la mémoire est-elle totalement privée et donc, consommée 2 fois ?
La gestion des processus, ça se joue au niveau du système d'exploitation, pas du langage.
Je ne suis pas expert, mais dirais que le code est chargé une seule fois en mémoire, mais que chaque processus à sa propre mémoire pour le fonctionnement. Et bien sûr, ils peuvent aussi avoir de la mémoire partagée.
Pour ceux qui ont la toolchain Rust d'installé c'est facile à compiler et installer avec l'outil cargo. Ça ne sera pas un avantage pour tout le monde, mais pour moi ça l'est.
Du coup, qu'elle est la taille du binaire "écrit en Rust". Parce que faire des binaires compilés statiquement, tu peux le faire en C.
Si la personne ne fournit pas le binaire et que tu veux compiler toi-même, généralement en C la gestion des dépendances est plus compliqué.
Un des plus (ou le plus) gros problèmes de performance est lié à la taille des binaires (pour cela qu'O2 donne bien souvent de meilleurs résultats qu'O3).
Je crois que le point sur les performances c'était entre programme écrit en langage interprété et ceux écrits en langage compilé, donc la question de la taille des binaires n'a pas de sens dans le propos de @steph1978.
Le problème ne se trouve pas dans le code mais dans le packaging.
Pourquoi il y aurait "un seul et unique problème" ?
Je ne parlais pas de la problématique d'avoir un programme non maintenu qui fonctionne tel quel encore 12 ans après.
Mais de la problématique que le fait qu'il est packagé dans une distribution sans que le fait qu'il ne fonctionne visiblement plus n'ait pas été détecté (a priori). Et donc que le package n'ait pas été soit corrigé (comme l'a fait débian a priori) soit retiré.
La compilation est pour moi une forme de test que le développeur n’a pas besoin d’écrire.
Fuir une application parce qu’elle est écrite en Python me semble peu efficace. Tu vas potentiellement éviter une application correctement testée pour utiliser une application compilée mais non testée ?
Du coup une application compilée et forcément un minimum testé :)
Bien sur ce n'est pas un boycott (j'utilise par exemple synapse et borg), le langage d'une application n'est pas la seule chose que je vais regarder, mais si j'ai le choix d'une alternative ok, je vais privilégier des applications en langage compilé.
Prendre l’exemple d’une application non-maintenue depuis 12 ans, pour laquelle un patch existe, ne me semble pas pertinent pour statuer sur une question si complexe ou déduire une généralité comme tu sembles le faire.
Je n'utilise pas l'exemple pour statuer, je profite de cet exemple pour partager mon ressenti/ma vision au sujet de l'absence d'étape de validation de code (ça pourrait être autre chose qu'une compilation).
Et je m’interroge aussi sur l'impact que ça a dans le fait qu'une application non-maintenue depuis 12 ans puisse rester dans les dépôts d'une distribution alors qu'elle est visiblement "cassée" (d'après le journal).
J'ai le sentiment qu'avec des langages compilés, ça réduirait un peu les risques, mais c'est pas magique, et ça dépens aussi des outils de validation des paquets mis en place.
Peut-être avec des linters Python comme cité plus bas, il y aurait moyen de détecter plus de problèmes à ce moment-là.
Le débat langage statiquement typé vs dynamiquement typé existe depuis très longtemps.
Je parle de validation du code à l’exécution du code au moment de l’exécution ou en amont, pas de typage statique ou dynamique.
Tu penses qu’il pourrait être utilisé par les distributions linux pour vérifier, contrôler, améliorer la qualité des programmes Python qu’ils distribuent ?
Par exemple en remontant des problèmes upstream. Ou pour détecter les programmes qui ne fonctionne plus et ne sont plus maintenu ? Comme ça semble être le cas de l’exemple du journal.
Ou il risquerait d’y avoir trop de "faux positif", trop de variété de pratiques pour que ça soit un angle intéressant ?
La compilation n’empêche pas tous les bugs effectivement, mais ça réduit les bugs potentiels. Donc ça permet d’avoir plus d’espace mental pour se concentrer sur les catégories qui ne sont pas éliminés.
La solution la plus efficace c’est quand même les tests, non ?
La plus efficace pour quoi ? Pourquoi les deux serais opposable ?
Les tests il faut les écrire, donc c’est du travail et c’est optionnel.
Les tests ne vont valider seulement le code qui va être exécuté, dans les conditions testées. Comment tu détermines que ça couvre tout le code ? Toutes les possibilités (exemple que ça gère des données d’entrées avec des erreurs) ?
Alors que la compilation couvre tout le code pour valider qu’il est ok, … sur ce que le compilateur peut vérifier, mais c’est déjà plus que rien.
Ensuite les tests servent pour ce qui ne peut pas être validé par le compilateur.
Du coup je pense que les deux sont complémentaires.
Oui bien sur la compilation n'empêche pas tous les problèmes, mais c'est un outil qui aide, et je pense qu'en programmation, toute aide est bonne à prendre.
D'ailleurs il existe peut-être en Python des outils type analyseur static qui peuvent aider, mais je n'en pas entendu parler.
Est-ce que le fait que l’erreur arrive à l’exécution n’est pas une illustration que Python n’est pas idéal pour le développement d’application ?
De ce que j’ai compris, ici @totof2000 a installé l’outil venant de la distribution.
Pourquoi l’outil n’a pas été retiré de la distribution ou corrigé ?
Pour moi, ce genre de code devrait être empêché et donc obliger à mieux écrire son programme.
C’est une chose qu’apportent les langages compilés, avoir une étape obligatoire de validation du programme. Qui permet d’attraper beaucoup plus d’erreurs avant l’exécution du programme, y compris à l’intégration continue. Est-ce qu'il existe des outils pour Python qui permettrait d'attraper des problèmes de programmation hors exécution ?
Les compilateurs, en plus de rapporter les erreurs peuvent, comme avec Rust, se montrer accompagnant en proposant, dans de nombreux cas, une solution au problème détecté.
Donc si je trouve que le journal manquait de justification, je partage plutôt l’idée "arrêtez d’utiliser python pour vos logiciels" (pour le scripting j’aurais moins de griefs). Chacun fait comme il veut, mais personnellement je vais plutôt fuir le python, aussi bien en tant qu'utilisateur que développeur.
Je pense que les commentaires aux dessus ne disent pas qu'il n'y a pas de "problèmes" avec la demande d'aide et qu'on a toujours une réponse qui nous aide. Mais plus que la comparaison n'est pas pertinente et maladroite.
Et je suis plutôt d'accords, dans la BD est comparé la demande de conseils à une demande d'assistance technique.
Et ses situations sont dans le même temps mise en place dans un contexte IRL d'un côté, et sur le web de l'autre.
Ma première impression à été un ressenti d'un dessin stigmatisant vis-à-vis des "geek informatique".
Context: je n'ai pas lu l'article, et je suis programmeur historiquement surtout C++ et aujourd'hui Rust
Mon expérience de Python en "production" c'est l'hébergement de Yunohost et Synapse (server matrix de référence).
Après une mise à jour de Synapse, l'envoie de photos ne fonctionnait plus. Après petite enquête dans les logs, il s'avère qu'une dépendance pour la gestion d'image avait été mise à jour, et que cette mise supprimait une fonction qui était marqué comme déprécié depuis un moment, et que le code de Synapse n'avait pas été mis à jour.
Que ce genre de problème puisse arriver jusqu'en production sans qu'au minimum un check de CI n'est levé une alerte me parais quand même problématique.
Peut-être qu'il y a des outils type analyseur static qui aurait pu/dû être utilisé en CI pour prévenir le problème. Mais rien que le fait que ce soit optionnel est un malus pour moi dans la confiance que je peux apporter à du code Python par rapport à du Go/Rust.
Si je dois héberger un service, je vais avoir tendance à chercher plutôt des outils écris dans des langages compilés plutôt qu'interprété comme premier filtre. Et si seulement je ne trouve rien qui correspond, je vais élargir la recherche.
Donc je suis plutôt d'accords avec l'idée "Difficile de recommander Python en production".
J'ai trouvé la vidéo intéressante, ça ne va pas dans les détails techniques, mais ça présente assez bien quand HTMX est intéressant et quand ça l'est moins, ses limites.
Contrairement à ce que le titre de l'article pourrait laisser penser, AppImage n'est pas du tout en cause ici ; le problème est surtout causé par un manque d'attention (ou de compréhension) de l'utilisateur.
Ce n'est pas le lancement de l'application qui a cassé le système, mais l'utilisateur qui a voulu faire en sorte de pouvoir lancer une application non compatible avec son système.
Il semblerait que cette variable d'environnement ne soit pas définie dans l'image Docker Ubuntu 24.04, ce qui a donné des surprises sur la CI. Bon ben dans ce cas je repasse sur /tmp en secours, tant pis.
Merci pour le (début de) tips, ça m'a justement servi pour un projet en court.
J'avais le même problème d'absence de variable TMPDIR sous Fedora, et après une recherche, j'ai lu que la variable d'environnement à utiliser était plutôt XDG_RUNTIME_DIR pour moi en tout cas.
Je partage l'idée que le "secret des affaires" est toxique et que le "secret des sources" et nécessaire, mais je pense qu'il serait intéressant de développer le "pourquoi".
Quelqu'un pourrait dire le contraire et avoir "raison", mais dans ce cas soit au moins un se trompe, soit c'est que cette personne aspire à une société complètement différente.
Pour compléter (je suis également utilisateur de Sailfish OS depuis début 2014 avec le Jolla 1, puis aujourd'hui un Xperia 10).
Si j’apprécie beaucoup de point de Sailfish Os, il y a aussi des problèmes qui font que j'ai du mal à en recommander l'usage.
Le plus gros point noir pour moi, est la sauvegarde des mms qui ne fonctionne pas. Les infos du message sont bien sauvegardés, mais pas son contenu (qui est stoqué de façon indépendante pour les mms).
Lors du passage du Jolla au xperia, j'ai dû me faire mon propre outil pour sauvegarder et restaurer les fichiers et mettre à jour la base de donnée des messages.
Et quand j'ai ouvert un ticket pour rapporter le problème (possibilité officielle suite à l'achat d'une licence), on m'a juste proposé de demander sur le forum communautaire, sans aucune info particulière, genre : est-ce que le code source de la sauvegarde est ouvert ou pas ? est-ce que c'est un problème connu ? …
Et il s'avère que le code de sauvegarde n'est pas opensource, du coup il n'est même pas possible de proposer une amélioration (je suis programmeur, j'aurais pu).
Donc, j'ai aussi été déçu que des points aussi basiques que la sauvegarde restauration de mms ne fonctionne pas correctement et qu'il ne soit pas possible de contribuer.
[^] # Re: permissions -> données
Posté par GwenLg . En réponse au journal De l'importance d'implémenter des permissions bidons. Évalué à 4 (+3/-0).
Oui c'est ça.
Par contre l'usage n'est pas encore très répandue il me semble. Vivement que ça se démocratise.
# permissions -> données
Posté par GwenLg . En réponse au journal De l'importance d'implémenter des permissions bidons. Évalué à 3 (+2/-0).
Pour l'avis sur le second intérêt, je ne pense pas que ça soit inefficace, ça rend la chose plus explicite, donc ça peut-permettre de critiquer plus facilement par exemple. Si on hésite entre deux applications pour faire une chose, avoir cette info peut aider à choisir. Mais je suis d'accords ça ne va pas corriger seul les problèmes de façon magique.
Il me semble que ce n'est pas de permissions bidons, mais de données bidons (fake) dont il est question.
La mise en place ne me semble pas évidente, enfin dans le sens où si on veut avoir des applications qui accèdent aux données valides, et d'autres à des données bidons, il faut que ça soit géré au niveau du système d'accès.
Mais par contre je suis à 100% avec l'idée, j'avais déjà essayé ce genre de chose pour la position gps sur smartphone.
Ça me fait penser une critique que j'ai envers les restrictions d'accès aux fichiers sous Android, et avec les
portailsFlatpak.Aujourd'hui, on peut ne pas autoriser une application à avoir accès aux fichiers de l'utilisateur (par exemple), mais dans ce cas on ne peut pas ouvrir un fichier spécifique avec cette application.
J'aimerais pouvoir interdire l'accès d'une application à tous les fichiers, mais que si je fais "ouvrir avec" à partir de l'explorateur (par exemple), l'application puisse dans ce cas ouvrir le fichier.
Après bien sur ça ouvre des questions qui font que ce n'est pas aussi simple que ça pourrait paraître :
- en lecture seulement ou aussi en écriture, si c'est au choix de l'utilisateur, ça veut dire qu'il faut que ça soit proposé dans l'interface.
- juste pour cette fois, où jusqu'à ce que l'autorisation soit (éventuellement) retirée.
J'ai vu passé des échanges qui pourrais concerner des travaux dans ce sens dans le système de "portails freedesktop", mais je n'ai pas creusé, je ne suis pas certain.
[^] # Re: On s’en fiche que ça soit « écrit en Rust »
Posté par GwenLg . En réponse au lien Outil de renommage en masse de fichiers écrit en Rust. Évalué à 1 (+0/-0).
Oui, même si ce n'est pas très mis en avant, il y a aussi moyen en Rust de faire des librairies partagées dynamique ou statique.
Rust utilise l'ABI C pour ça (et pour l’interaction avec d'autres langages)
Plus d'info dans la doc : Linkage
La gestion des processus, ça se joue au niveau du système d'exploitation, pas du langage.
Je ne suis pas expert, mais dirais que le code est chargé une seule fois en mémoire, mais que chaque processus à sa propre mémoire pour le fonctionnement. Et bien sûr, ils peuvent aussi avoir de la mémoire partagée.
[^] # Re: On s’en fiche que ça soit « écrit en Rust »
Posté par GwenLg . En réponse au lien Outil de renommage en masse de fichiers écrit en Rust. Évalué à 1 (+0/-0).
Pour ceux qui ont la toolchain Rust d'installé c'est facile à compiler et installer avec l'outil
cargo. Ça ne sera pas un avantage pour tout le monde, mais pour moi ça l'est.Si la personne ne fournit pas le binaire et que tu veux compiler toi-même, généralement en C la gestion des dépendances est plus compliqué.
Je crois que le point sur les performances c'était entre programme écrit en langage interprété et ceux écrits en langage compilé, donc la question de la taille des binaires n'a pas de sens dans le propos de @steph1978.
[^] # Re: Le problème n'est pas GTK non plus
Posté par GwenLg . En réponse au journal SVP arrêtez d'utiliser Python pour vos logiciels en GUI.. Évalué à 1 (+0/-0).
Je ne parlais pas de la problématique d'avoir un programme non maintenu qui fonctionne tel quel encore 12 ans après.
Mais de la problématique que le fait qu'il est packagé dans une distribution sans que le fait qu'il ne fonctionne visiblement plus n'ait pas été détecté (a priori). Et donc que le package n'ait pas été soit corrigé (comme l'a fait débian a priori) soit retiré.
[^] # Re: Le problème n'est pas GTK non plus
Posté par GwenLg . En réponse au journal SVP arrêtez d'utiliser Python pour vos logiciels en GUI.. Évalué à 0 (+0/-1).
Du coup une application compilée et forcément un minimum testé :)
Bien sur ce n'est pas un boycott (j'utilise par exemple synapse et borg), le langage d'une application n'est pas la seule chose que je vais regarder, mais si j'ai le choix d'une alternative
ok, je vais privilégier des applications en langage compilé.[^] # Re: Le problème n'est pas GTK non plus
Posté par GwenLg . En réponse au journal SVP arrêtez d'utiliser Python pour vos logiciels en GUI.. Évalué à 0 (+1/-2). Dernière modification le 30 mars 2025 à 22:35.
Je n'utilise pas l'exemple pour statuer, je profite de cet exemple pour partager mon ressenti/ma vision au sujet de l'absence d'étape de validation de code (ça pourrait être autre chose qu'une compilation).
Et je m’interroge aussi sur l'impact que ça a dans le fait qu'une application non-maintenue depuis 12 ans puisse rester dans les dépôts d'une distribution alors qu'elle est visiblement "cassée" (d'après le journal).
J'ai le sentiment qu'avec des langages compilés, ça réduirait un peu les risques, mais c'est pas magique, et ça dépens aussi des outils de validation des paquets mis en place.
Peut-être avec des linters Python comme cité plus bas, il y aurait moyen de détecter plus de problèmes à ce moment-là.
Je parle de validation du code à l’exécution du code au moment de l’exécution ou en amont, pas de typage statique ou dynamique.
[^] # Re: Le problème n'est pas GTK non plus
Posté par GwenLg . En réponse au journal SVP arrêtez d'utiliser Python pour vos logiciels en GUI.. Évalué à 0 (+0/-1).
Ok, merci pour l’info sur les linters.
Tu penses qu’il pourrait être utilisé par les distributions linux pour vérifier, contrôler, améliorer la qualité des programmes Python qu’ils distribuent ?
Par exemple en remontant des problèmes upstream. Ou pour détecter les programmes qui ne fonctionne plus et ne sont plus maintenu ? Comme ça semble être le cas de l’exemple du journal.
Ou il risquerait d’y avoir trop de "faux positif", trop de variété de pratiques pour que ça soit un angle intéressant ?
[^] # Re: Le problème n'est pas GTK non plus
Posté par GwenLg . En réponse au journal SVP arrêtez d'utiliser Python pour vos logiciels en GUI.. Évalué à 3 (+4/-2).
La compilation n’empêche pas tous les bugs effectivement, mais ça réduit les bugs potentiels. Donc ça permet d’avoir plus d’espace mental pour se concentrer sur les catégories qui ne sont pas éliminés.
Les tests il faut les écrire, donc c’est du travail et c’est optionnel.
Les tests ne vont valider seulement le code qui va être exécuté, dans les conditions testées. Comment tu détermines que ça couvre tout le code ? Toutes les possibilités (exemple que ça gère des données d’entrées avec des erreurs) ?
Alors que la compilation couvre tout le code pour valider qu’il est ok, … sur ce que le compilateur peut vérifier, mais c’est déjà plus que rien.
Ensuite les tests servent pour ce qui ne peut pas être validé par le compilateur.
Du coup je pense que les deux sont complémentaires.
[^] # Re: Le problème n'est pas GTK non plus
Posté par GwenLg . En réponse au journal SVP arrêtez d'utiliser Python pour vos logiciels en GUI.. Évalué à 1 (+2/-2).
Oui bien sur la compilation n'empêche pas tous les problèmes, mais c'est un outil qui aide, et je pense qu'en programmation, toute aide est bonne à prendre.
D'ailleurs il existe peut-être en Python des outils type
analyseur staticqui peuvent aider, mais je n'en pas entendu parler.[^] # Re: Le problème n'est pas GTK non plus
Posté par GwenLg . En réponse au journal SVP arrêtez d'utiliser Python pour vos logiciels en GUI.. Évalué à -2 (+6/-9).
Est-ce que le fait que l’erreur arrive à l’exécution n’est pas une illustration que Python n’est pas idéal pour le développement d’application ?
De ce que j’ai compris, ici @totof2000 a installé l’outil venant de la distribution.
Pourquoi l’outil n’a pas été retiré de la distribution ou corrigé ?
Pour moi, ce genre de code devrait être empêché et donc obliger à mieux écrire son programme.
C’est une chose qu’apportent les langages compilés, avoir une étape obligatoire de validation du programme. Qui permet d’attraper beaucoup plus d’erreurs avant l’exécution du programme, y compris à l’intégration continue. Est-ce qu'il existe des outils pour Python qui permettrait d'attraper des problèmes de programmation hors exécution ?
Les compilateurs, en plus de rapporter les erreurs peuvent, comme avec Rust, se montrer accompagnant en proposant, dans de nombreux cas, une solution au problème détecté.
Donc si je trouve que le journal manquait de justification, je partage plutôt l’idée "arrêtez d’utiliser python pour vos logiciels" (pour le scripting j’aurais moins de griefs). Chacun fait comme il veut, mais personnellement je vais plutôt fuir le python, aussi bien en tant qu'utilisateur que développeur.
[^] # Re: Problème très courant
Posté par GwenLg . En réponse au lien Un dessin humoristique de Boulet sur l'entraide technique [date de 2023]. Évalué à 4 (+4/-1).
Je pense que les commentaires aux dessus ne disent pas qu'il n'y a pas de "problèmes" avec la demande d'aide et qu'on a toujours une réponse qui nous aide. Mais plus que la comparaison n'est pas pertinente et maladroite.
Et je suis plutôt d'accords, dans la BD est comparé la demande de conseils à une demande d'assistance technique.
Et ses situations sont dans le même temps mise en place dans un contexte IRL d'un côté, et sur le web de l'autre.
Ma première impression à été un ressenti d'un dessin stigmatisant vis-à-vis des "geek informatique".
[^] # Re: Huhu
Posté par GwenLg . En réponse au lien Difficile de recommander Python en production . Évalué à 9 (+8/-0). Dernière modification le 08 mars 2025 à 12:52.
Context: je n'ai pas lu l'article, et je suis programmeur historiquement surtout C++ et aujourd'hui Rust
Mon expérience de Python en "production" c'est l'hébergement de Yunohost et Synapse (server matrix de référence).
Après une mise à jour de Synapse, l'envoie de photos ne fonctionnait plus. Après petite enquête dans les logs, il s'avère qu'une dépendance pour la gestion d'image avait été mise à jour, et que cette mise supprimait une fonction qui était marqué comme déprécié depuis un moment, et que le code de Synapse n'avait pas été mis à jour.
Que ce genre de problème puisse arriver jusqu'en production sans qu'au minimum un check de CI n'est levé une alerte me parais quand même problématique.
Peut-être qu'il y a des outils type
analyseur staticqui aurait pu/dû être utilisé en CI pour prévenir le problème. Mais rien que le fait que ce soit optionnel est un malus pour moi dans la confiance que je peux apporter à du code Python par rapport à du Go/Rust.Si je dois héberger un service, je vais avoir tendance à chercher plutôt des outils écris dans des langages compilés plutôt qu'interprété comme premier filtre. Et si seulement je ne trouve rien qui correspond, je vais élargir la recherche.
Donc je suis plutôt d'accords avec l'idée "Difficile de recommander Python en production".
[^] # Re: article en Français
Posté par GwenLg . En réponse au lien Bronsonisation de Viktor Antonov, directeur artistique de "Half Life 2" . Évalué à 1 (+0/-0).
Et pour ceux qui seraient curieux, il apparaît par exemple dans une des vidéos promotionnelle de Dishonored :
Les coulisses de Dishonored #2 - Immersion
# article en Français
Posté par GwenLg . En réponse au lien Bronsonisation de Viktor Antonov, directeur artistique de "Half Life 2" . Évalué à 3 (+2/-0).
https://www.factornews.com/actualites/deces-de-viktor-antonov-50857.html
# tutoriels
Posté par GwenLg . En réponse au journal La métropole de Lyon arrête son instance CozyCloud. Et Ecolyo ?. Évalué à 9.
Next a publié récemment deux tutoriels pour récupérer directement les données des compteurs Linky.
Le premier avec des modules sans fils est maintenant disponible pour tous : #Nextpresso : module TIC Linky et clé Zigbee pour suivre en direct sa consommation électrique.
Le second n'est pour le moment réservé aux abonnées : #Nextpresso LiXee TIC-DIN : récupérer en USB les données de Linky sur Raspberry Pi
@Glandos: ça t'aide pour ta question de fin ?
# l'appel du STJV
Posté par GwenLg . En réponse au lien Chez Ubisoft, les salariés appelés à trois jours de grève. Évalué à 4.
directement sur leur site : https://www.stjv.fr/2024/09/appel-a-la-greve-pour-les-entites-francaises-dubisoft-les-15-16-et-17-octobre-2024/
[^] # Re: Merci
Posté par GwenLg . En réponse au journal Nouvelle version de FlowG - De HTMX à React, pour une meilleure expérience utilisateur ?. Évalué à 3.
En français il y a aussi cette vidéo :
HTMX - Un retour aux templates ou le futur du front-end ? (conf BreizhCamp de cette année)
J'ai trouvé la vidéo intéressante, ça ne va pas dans les détails techniques, mais ça présente assez bien quand HTMX est intéressant et quand ça l'est moins, ses limites.
[^] # Re: Titre trompeur
Posté par GwenLg . En réponse au lien Ubuntu tout cassé après avoir lancé une application .AppImage ?. Évalué à 4.
Et ce titre ?
ça me semble mieux refléter la réalité, tout en étant à peine plus long.
# Titre trompeur
Posté par GwenLg . En réponse au lien Ubuntu tout cassé après avoir lancé une application .AppImage ?. Évalué à 4. Dernière modification le 23 septembre 2024 à 14:40.
Je cite l'article lui-même :
Ce n'est pas le lancement de l'application qui a cassé le système, mais l'utilisateur qui a voulu faire en sorte de pouvoir lancer une application non compatible avec son système.
# de l'influence du rôle des développeur sur leur perspective
Posté par GwenLg . En réponse au lien Un mainteneur de Rust sur le Kernel jette l'éponge.. Évalué à 1. Dernière modification le 30 août 2024 à 16:44.
pour compléter, voici un post de David Airlied qui aborde les difficultés de cohabitation entre développeur en fonction de leur "rôle" : https://airlied.blogspot.com/2024/08/on-rust-linux-developers-maintainers.html
# bonne variable d’environnement pour le dossier temporaire
Posté par GwenLg . En réponse au journal Un environnement de dev dans son téléphone.. Évalué à 2.
J'avais le même problème d'absence de variable
TMPDIRsous Fedora, et après une recherche, j'ai lu que la variable d'environnement à utiliser était plutôtXDG_RUNTIME_DIRpour moi en tout cas.[^] # Re: Annotations sur github/gitlab ?
Posté par GwenLg . En réponse au journal Comment se tenir informé ?. Évalué à 5.
Sur github tu as aussi des flux atom (caché ?) sous la forme :
https://github.com/[organisation]/[depot]/commits/[branche].atom
Exemple : https://github.com/arx/ArxLibertatis/commits/master.atom
Il semblerait qu'il y ai aussi moyen d'avoir un flux pour les tags :
https://github.com/arx/ArxLibertatis/tags.atom
[^] # Re: La bonne blague
Posté par GwenLg . En réponse au lien Droits voisins : Mediapart lance la bataille de la transparence contre Google. Évalué à 2. Dernière modification le 30 avril 2024 à 00:14.
Je partage l'idée que le "secret des affaires" est toxique et que le "secret des sources" et nécessaire, mais je pense qu'il serait intéressant de développer le "pourquoi".
Quelqu'un pourrait dire le contraire et avoir "raison", mais dans ce cas soit au moins un se trompe, soit c'est que cette personne aspire à une société complètement différente.
[^] # Re: Sailfish OS
Posté par GwenLg . En réponse au journal Téléphone sous Linux ?. Évalué à 5.
Oui il y a aussi Sailfish OS.
Pour compléter (je suis également utilisateur de Sailfish OS depuis début 2014 avec le Jolla 1, puis aujourd'hui un Xperia 10).
Si j’apprécie beaucoup de point de Sailfish Os, il y a aussi des problèmes qui font que j'ai du mal à en recommander l'usage.
Le plus gros point noir pour moi, est la sauvegarde des mms qui ne fonctionne pas. Les infos du message sont bien sauvegardés, mais pas son contenu (qui est stoqué de façon indépendante pour les mms).
Lors du passage du Jolla au xperia, j'ai dû me faire mon propre outil pour sauvegarder et restaurer les fichiers et mettre à jour la base de donnée des messages.
Et quand j'ai ouvert un ticket pour rapporter le problème (possibilité officielle suite à l'achat d'une licence), on m'a juste proposé de demander sur le forum communautaire, sans aucune info particulière, genre : est-ce que le code source de la sauvegarde est ouvert ou pas ? est-ce que c'est un problème connu ? …
Et il s'avère que le code de sauvegarde n'est pas opensource, du coup il n'est même pas possible de proposer une amélioration (je suis programmeur, j'aurais pu).
Donc, j'ai aussi été déçu que des points aussi basiques que la sauvegarde restauration de mms ne fonctionne pas correctement et qu'il ne soit pas possible de contribuer.