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.
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.
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.
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.
~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]>
)
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 :)
# Rollback de l'exploit
Posté par Simon (site web personnel) . En réponse au lien [Copy Fail] The same 732-byte Python script roots every Linux distribution shipped since 2017.. Évalué à 8 (+8/-0).
Pour rollback l'exploit sur une machine :
[^] # Re: Piratage des liens
Posté par Simon (site web personnel) . En réponse au lien Go : attaque de la chaîne d'approvisionnement masquée par le cache des librairies. Évalué à 1.
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.
[^] # Re: Nextcloud / Syncthing
Posté par Simon (site web personnel) . En réponse au lien Synchronisation de clients FreeTube. Évalué à 1.
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.
[^] # Re: Correction de lien
Posté par Simon (site web personnel) . En réponse au lien Gestionnaire de fonds d'écrans pour i3. Évalué à 0.
Top merci !
# Correction de lien
Posté par Simon (site web personnel) . En réponse au lien Gestionnaire de fonds d'écrans pour i3. Évalué à 1.
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
[^] # Re: inconvénients
Posté par Simon (site web personnel) . En réponse au lien Un site vite et bien (?) avec Hugo : quitter Instagram et héberger ses propres galeries photo. Évalué à 1.
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.
[^] # Re: Peux-tu détailler ?
Posté par Simon (site web personnel) . En réponse au lien Gitea 1.17 intègre un registre de paquets. Évalué à 0. Dernière modification le 26 juillet 2022 à 11:22.
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
Posté par Simon (site web personnel) . En réponse à la dépêche Vingt-quatre ans de LinuxFr.org. Évalué à 5.
Merci pour cette belle source d'information qu'est LinuxFR :)
[^] # Re: Interopérabilité des messageries
Posté par Simon (site web personnel) . En réponse au lien L’Union européenne va mieux encadrer les géants du numérique. Évalué à 1.
Avec un peu d'huile de coude, tu peux déjà tendre à le faire avec Matrix.
[^] # Re: Templeet ?
Posté par Simon (site web personnel) . En réponse à la dépêche Rendez-vous Les moteurs de Template en PHP le 6 octobre 2015 à Paris. Évalué à 1. Dernière modification le 04 octobre 2015 à 15:39.
C'est que ça semble vraiment génial à utiliser…
# Intéressant mais quelques limites
Posté par Simon (site web personnel) . En réponse à la dépêche OcLaunch, launch automagically. Évalué à 1.
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 :)
[^] # Re: Thunderbird et Firefox dans une seule fenêtre
Posté par Simon (site web personnel) . En réponse au journal Des news de Firefox. Évalué à 1.
Firefox n'est pas là pour lire mes mails !