Guillawme a écrit 235 commentaires

Merci, j’aurais dû chercher avant de poster un doublon. 😌

On dirait que ces services ne sont pas accessibles aux particuliers, mais tous les composants sont libres et auto-hébergeables : https://github.com/suitenumerique (bon, par contre l'état héberge le code de ces outils sur Microsoft GitHub, au lieu de montrer un meilleur exemple).

La plupart des messageries permettent de désactiver les accusés de lecture.

On dirait que Decibels sert simplement à lire un fichier audio, sans aucune fonctionnalité de bibliothèque musicale. Donc je vois ça comme un petit utilitaire complémentaire pour écouter un fichier sans devoir ouvrir toute la bibliothèque, qui elle reste dans Rythmbox.

Dire que les pilotes open source pour GPUs Nvidia fonctionnent très bien, c'est techniquement correct depuis que le pilote Nvidia est devenu open source : https://linuxfr.org/users/guillawme/liens/nvidia-transitions-fully-towards-open-source-gpu-kernel-modules

On pourrait même dire que le meilleur support des GPUs Nvidia est fourni par un pilote open source. 😇

Extrait de l'article vers lequel pointe ce lien (sur le blog de Nvidia, donc la source officielle) :

For cutting-edge platforms such as NVIDIA Grace Hopper or NVIDIA Blackwell, you must use the open-source GPU kernel modules. The proprietary drivers are unsupported on these platforms.

Distribuer des « pertinent » et « inutile » ne change pas ton karma, ça change celui des personnes à qui tu les distribue. Et c’est ceux que tes messages reçoivent qui changent ton karma à toi. Et le karma détermine combien de « pertinent » et « inutile » tu peux distribuer chaque jour. Enfin en gros. Je n’ai pas lu la doc ni le code, donc je ne peux pas donner une explication quantitative.

Et personne ne semble intéressé pour faire un début de simplification.

Ce n'est pas vraiment une simplification en termes techniques, mais Guix pousse à l'extrême l'approche des environnements isolés en la généralisant à tous les paquets du système. Et au final, du point de vue de l'utilisateur, c'est effectivement une simplification : un seul outil à apprendre pour mettre de l'ordre dans ce bazar.

Ce fonctionnement permet de garantir plein de propriétés intéressantes, par exemple (parmi bien d'autres) : installer des paquets ne nécessite plus les droits d'administrateur, plusieurs versions d'un paquet peuvent cohabiter sur le même système sans causer de conflits, les mises à jour sont "tout ou rien" (soit elle réussit, soit on reste avec la version qu'on avait, mais on ne se retrouve jamais avec un système partiellement modifié et inutilisable, même si on annule brutalement une commande de mise à jour), on peut revenir aux "générations" précédentes de son profil utilisateur ou même de tout l'OS si une mise à jour apporte des changements indésirables, etc.

La liste des avantages est longue, et il faut vraiment essayer ce système pour y croire (juste en lisant on se dit que c'est trop beau pour être vrai). Installer Guix et me familiariser avec était mon passe-temps pendant ces vacances, et cet essai m'a vraiment donné envie de persévérer pour finalement y migrer complètement quand j'y serai à l'aise.

Peut-être micro ?
https://micro-editor.github.io

Je ne sais pas si c’est encore possible, mais pendant longtemps on pouvait faire git push sur l’adresse HTTPS du dépôt, et ça demandait systématiquement le mot de passe du compte. Couplé à un gestionnaire de mots de passe qui fournit le mot de passe à git automatiquement, l’expérience utilisateur est identique à celle d’une clé SSH.

Une merveille de design des années 90.
https://bf-enterprise-solutions.github.io/

Bonne idée, et avec des extensions différentes entre les différents services publics bien sûr.

Justement, le module propriétaire était la principale source de complications à l’installation, donc c’est une très bonne nouvelle.
Je ne sais pas si Nvidia prévoit de l’inclure dans le noyau ou de continuer à le développer en dehors, mais c’est un détail.

Il y a seulement quelques années, ce titre aurait fait un poisson d’avril à peine plausible.

Pour ma part, j’espère trouver un cas d’utilisation pour fossil. Sûrement pour un projet privé, vu que pour tout ce qui a besoin de visibilité, GitHub est de fait le meilleur choix…

Ça fait un moment que j’étais tombé sur cet utilitaire, j’ai enfin pris le temps de lire la documentation et de l’installer. Eh bien c’est super utile !

Le principe est simple : une base de données (SQLite je crois) pour stocker l’historique du shell (mais le fichier texte est toujours alimenté, donc on ne perd aucune entrée d’historique récent si l’on décide de ne plus utiliser atuin).
Ça permet entre autres d’avoir un historique virtuellement illimité, et synchronisé entre différentes machines. Ne vous affolez pas : la synchronisation est opt-in, chiffrée de bout en bout, et il est possible d’auto-héberger son propre serveur de synchronisation. Il est aussi possible de régler des filtres pour que certaines commandes ne soient pas stockées dans la base de données (ou toutes les commandes lancées à partir de certains répertoires).
Bien sûr on peut importer l’historique qu’on a déjà, donc c’est utile directement. L’interface est bien faite et configurable. J’ai configuré pour que la flèche haut rappelle l’historique de la machine sur laquelle je suis, et Ctrl+R rappelle l’historique combiné (par la synchronisation) de toutes les machines sur lesquelles j’ai installé atuin. C’est super pratique avec le fuzzy search. Par exemple, j’ai parfois besoin de commandes rsync assez complexes : maintenant je peux les retrouver bien plus facilement, plutôt que de devoir relire le manuel à chaque fois.

J’ai fait une recherche rapide sur le site avant de poster ce lien et j’ai quand même réussi à rater ce journal. Merci, très intéressant en effet.

J’espère vraiment que l’UE ira jusqu’au bout et forcera les apps de messagerie à être complètement interopérables. La plupart utilisent déjà le protocole Signal, c’est donc techniquement possible de les faire communiquer sans compromettre le chiffrement.

Peut-être qu’un jour on pourra enfin communiquer avec tout notre carnet d’adresse sans nécessiter une demi douzaine d’apps qui font toutes la même chose.

HAL et Arxiv sont des serveurs de « preprints » et il est toujours gratuit d’y poster des articles comme de les lire (si votre serveur de preprints vous demande de payer, c’est une arnaque, changez de serveur de preprints).
On appelle preprint la version d’un article de recherche prête à être soumise à un journal et rendue publique par ses auteurs, mais pas encore évaluée par des experts sollicités par le journal (et choisis pour être le plus indépendants possible, en particulier le journal tâche de ne pas envoyer un article à des gens qui ont publié avec les auteurs de l’article en question dans les quelques années précédentes, ni à des compétiteurs directs qui pourraient ne pas être totalement impartiaux). La plupart des journaux n’ont aucun problème à ce que les auteurs postent un preprint avant ou en même temps qu’ils soumettent leur article au journal. Si le journal auquel vous voulez soumettre un article vous interdit de poster un preprint, changez de journal.

Springer, plus précisément le groupe Springer Nature (pas de page Wikipedia en français, désolé), est un éditeur qui publie des journaux scientifiques. Leur modèle économique est de faire payer des sommes déraisonnables en abonnements aux lecteurs (modèle traditionnel) ou en frais de publication aux auteurs (nouveau modèle), selon les journaux, tout en faisant travailler gratuitement les experts qui évaluent les articles et en minimisant leurs dépenses de fonctionnement (la plupart des journaux sont maintenant uniquement en ligne, très peu sont encore imprimés).

Le lien que nous sommes en train de commenter explique que la bibliothèque de l’université de Lille a mis fin aux abonnements qu’elle avait aux journaux du groupe Springer Nature, probablement parce qu’elle a réalisé que cet argent était mieux employé autrement et/ou suite à la dernière augmentation des tarifs pratiquée régulièrement par ces éditeurs (je n’ai pas lu l’article, mais ce genre de nouvelle est courant ces dernières années dans le monde académique dans lequel je travaille).

Courage ! Je sais que mes mots ne pèsent sûrement pas grand chose, mais je compatis.

Aussi je tiens à préciser que j’utilise ici le terme « oisiveté » comme traduction de « idleness » au sens de l’article, qui n’est pas le même que le sens macronien. L’auteur explique qu’une certaine proportion d’oisiveté est nécessaire pour une vie heureuse à l’échelle individuelle, et pour une société saine à l’échelle collective. Il entend par oisiveté le fait de pouvoir poursuivre ce qui nous intéresse indépendamment de l’aspect financièrement viable ou pas. Je le comprends comme la réponse à « qu’est-ce que tu ferais s’il y avait un revenu de base suffisant pour payer le loyer ? ». Bah dans mon cas je passerais le boulot à mi-temps et je ferais plus de musique (sans chercher à en tirer un revenu, juste parce que j’aime ça).

Je partage car c’était une excellente lecture. Il y a 92 ans, cet article recommandait explicitement une semaine de travail de 20 heures avec d’excellents arguments.

Je trouve très pertinente la partie qui explique que nos sociétés ont choisi de forcer certains à l’oisiveté excessive (= le chômage de masse) et les autres au travail excessif (= le surmenage) et que les deux nous rendent misérables alors qu’un meilleur équilibre entre les deux nous rendrait tous plus heureux.

Alors voilà, meilleurs vœux pour 2024, et je vous souhaite de trouver votre équilibre entre travail et oisiveté.

Mon utilisation typique est très simple.

Je ne programme presque pas en général, et encore moins avec Python, que j'essaye d'éviter précisément parce qu'il y a trop d'outils différents pour installer des paquets et gérer des versions, et je n'ai ni l'envie ni le temps de m'y intéresser.

Mais j'utilise pour mon travail plusieurs programmes écrits en Python, et comme je l'écrivais dans un message précédent, j'ai presque toujours besoin de faire cohabiter plusieurs versions d'un même programme (au moins le temps de terminer des projets démarrés plus tôt avec une version plus ancienne). Certains de ces programmes sont distribués dans les dépôts conda, d'autres dans PyPI, certains dans les deux, d'autres encore sont seulement un dépôt git à cloner mais contenant du code qui a besoin de certaines versions précises de Python et de quelques paquets. Bref, c'est le bazar, et moi ce que je veux c'est utiliser ces programmes, pas apprendre un nouvel outil pour installer chaque nouveau programme dont j'ai besoin.

Peut-être que pip+venv marche aussi pour ça, je ne sais pas. De mon expérience, conda répond à toutes ces situations en ayant besoin d'apprendre un seul outil, donc c'est ce que j'utilise. Apprendre des outils spécifiques à Python ça ne m'intéresse pas, je le fais seulement parce que c'est nécessaire pour utiliser des programmes Python mais je m'en passerais bien si c'était possible.

Ah je vois. C'est une situation que je ne rencontre jamais : quand j'ai besoin d'une nouvelle version d'un programme, je l'installe dans un nouvel environnement vide, parce que la plupart du temps j'ai aussi besoin de conserver la version précédente un certain temps. Mais en effet je vois tout à fait comment essayer de mettre à jour pourrait mettre le bazar.

Malheureusement, la réponse de Conda à « Comment installer dans un environnement Conda un paquet PyPI qui n’est pas disponible au format Conda ? » est « Utilisez pip, mais à vos risques et périls, ce n’est pas supporté », ce qui n’est pas fantastique lorsque l’on a besoin d’un tel paquet (cela arrive très vite).

Est-ce que cela cause beaucoup de problèmes en pratique ?

J'utilise uniquement conda car c'est pour moi la façon la plus simple d'éviter certains problèmes, mais ce que j'installe dans un environnement conda n'est pas toujours dans les dépôts conda alors j'installe avec pip quand c'est nécessaire. Je n'ai pas beaucoup d'exemples parce que j'utilise seulement une poignée de programmes python pour un domaine spécifique, mais en tout cas je n'ai absolument jamais eu de problème en utilisant pip dans des environnements conda.

D’après tes critères, Fedora semble un bon compromis :

❌ une distribution dans la famille dérivée de Debian
✅ qui repose sur une communauté un minimum fourni
✅ avec KDE comme bureau idéalement dans une version assez peu modifiée
✅ avec un suivi assez rapide des évolutions de KDE
✅ hors de questions d'avoir des SNAPS
❌ a priori favoriser les deb
✅ pas d'objection à avoir un peu de dépôts autres que Debian et d'avoir l'option de recourir à des flatpacks (sans que cela ne soit l'option privilégiée d'installation)

https://fedoraproject.org/spins/kde/

J’ai écrit ça un peu vite, je voulais surtout évoquer la généralisation forcée du télétravail à cause des confinements. Mais ce n’est pas moi qui le dit, cherche ces mots-clés et tu trouveras plein d’articles de presse à ce sujet. Un exemple pris au hasard.