Simon a écrit 11 commentaires

github.com/boltdb-go/bolt est le nom du package. Bien que ça puisse prêter à confusion, ça ne me semble pas être du phishing. Le lien aurait pu également pointer sur https://pkg.go.dev/github.com/boltdb/bolt.

Merci pour ce message !

Le souci avec un système de lien symbolique / webdav / whatever, exploité par plusieurs instances FreeTube, c'est le modèle de fonctionnement de FreeTube.
Au démarrage, FreeTube charge en mémoire les données issues des fichiers puis les rewrite depuis les données en mémoire. À aucun moment il ne recharge ces fichiers pendant qu'il est en fonctionnement. Du coup, si 2 FreeTubes utilisent les mêmes fichiers, le dernier qui fait une mise à jour écrasera les données du premier.

Top merci !

Oops, j'ai partagé un lien vers un commentaire et je ne sais pas comment on peut corriger. Le bon lien est https://www.deblan.io/post/667/gestionnaire-de-fonds-decran-pour-i3

J'aime beaucoup les générateurs de sites statique, surtout pour les documentations que je suis amené à écrire.

J'aime également les outils non statiques qui permettent, pour les personnes moins à l'aise, de faire des modifications via des interfaces web pensées pour ça. Cela permet également d'intégrer des traitements comme la compression des images, la génération de miniature et autres.
Quand les outils sont bien réalisés, tu peux aussi faire les choses bien sans passer par un processus qui peut prendre plus de temps par ailleurs.

Bonjour Bux,

De mon points de vue, tu as plusieurs cas d'usages qui sont intéressants.

1er cas : tu développes un paquet non public qui est une dépendance d'un projet à toi. Tu peux utiliser ton Gitea pour l'héberger et le rendre accessible via ton gestionnaire de paquets. Personnellement, je suis développeur PHP et via le fichier de dépendances de composer, je peux ajouter des registres qui seront consultés en priorité pour récupérer des paquets.

2ème cas : tu as une CI/CD dans une infra proche de ton Gitea et tu utilises des images dockers qui peuvent rapidement être obèses. Pour réduire le coût de bande passante (en temps et en ressources), tu peux héberger ces images docker sur ton Gitea plutôt qu'aux USA chez Amazon. C'est mon cas et ça permet de grappiller du temps de téléchargement non négligeable (je suis auto-hébergé).

3ème cas : tu veux centraliser tous tes paquets chez toi, en complément ou pas des registres officiels. Typiquement, j'ai réalisé des paquets/projets PHP, NPM et docker, ils sont maintenant tous accessibles depuis ma forge et liés à leur dépôt respectif. Même si je n'utiliserai pas systématiquement cette forge comme source de paquets principale, je serai en mesure de le faire le jour où un registre est HS.

Merci pour cette belle source d'information qu'est LinuxFR :)

Avec un peu d'huile de coude, tu peux déjà tendre à le faire avec Matrix.

C'est que ça semble vraiment génial à utiliser…

~if(10>1,
     <![bloc1[
        Voici le premier bloc nommé "bloc1"
        ~if(empty(foo),
             foo=10,
             <![foo[ Un autre bloc nommé "foo" ]foo]>
           )
     ]bloc1]>,
 <![foo[ Encore un autre bloc nommé "foo" ]foo]>
)

Projet intéressant.

Je vois cependant plusieurs limites :
- pour lancer une application graphique, tu dois passer par l'ouverture d'un xterm
- tu es vite limité par la création d'une seule liste de "tâches". Imaginons que tu veuilles préparer des environnements de travail par bureau virtuel, comment fais-tu ?

Sans parler de difficulté de configuration, je me suis déjà penché sur cette dernière question et j'ai trouvé une solution avec xdotool (exemple). Cependant, Je suis conscience que ce n'est pas tout à fait ce que tu proposes :)

Une application ~= une tache

Firefox n'est pas là pour lire mes mails !