En fait en y relechissant je me rend compte que ce n'est peut-être pas la peine de faire plugin, suffit de lancer un conteneur avec un vim dedans, et de partager sa conf via un volume.
Ça ne semble cependant pas trop difficile à implémenter, et visiblement il y a déjà des gens qui ont fait des plugins pour ça -> https://github.com/schnauzers/devcontainer :)
Le monde du libre a clairement un problème avec les noms. Avec certains projets, on a l'impression qu'après des milliers d'heures de travail sur le code, on choisit comme parrain le cousin Gérard après le trentième verre de mauresque au bar du village. “Eh les mecs ! Moi j'vous dis qu'il faut qu'on appelle notre projet de smartphone libre slash euh slash !”
TL;DR : des “problèmes techniques” et le “tracker eulerian c'est pas un tracker publicitaire, c'est pour un usage interne”
Franchement, leur ligne de défense est quand même fourbe.
Jouer la carte de “c'est un tracker pour nous pas un tracker publicitaire” mouai c'est un peu gros.
Ce serait réellement le cas, le Google Analytics qu'ils ont déjà ferait déjà l'affaire.
La force d'Eulerian est justement d'avoir des informations mutualisées entre leurs différents clients…
Premièrement, elle se base sur le concept de la « tragédie des communs » de Garrett Hardin, qui s'avère être bidon (un peu comme toutes les théories économique libérales), cf. https://lejournal.cnrs.fr/billets/la-tragedie-des-communs-etait-un-mythe. Du coup, il faudrait peut-être arrêter de baser nos sociétés, nos fonctionnements, etc. sur des théories qui ont fait la preuve de leur inexactitude et de leurs effets néfastes. Ce qui est paradoxal c'est que l'article enchaîne ensuite avec les travaux de Olstrom qui contredisent ceux de Hardin
Ce qui nous amène au deuxième problème, c'est qu'il fait, en plus d'une interprétation très personnelle, une application sélective des principes de Olstrom au domaine de l'open-source.
Troisièmement, le parallèle entre gestion du logiciel open-source et gestion d'un bien commun limité est tordu, et je me demande s'il tient vraiment… On passe du logiciel lui-même et sa communauté, à ses “clients” étant le bien commun, tout en gardant d'appliquer les principes de gestion de commune au logiciel qui pourtant du coup n'est plus l'objet “bien commun”…
Pour dire plus, c'est même pas un billet de ma part mais une reprise de celui de Thierry, le papa de NuTyX, pour informer et faire de l’écho à une distribution peu connue et fort sympathique.
Cela me fait penser que sous OpenBSD, on a l'option -P à l'outil rm qui écrit de manière aléatoire des données avant l'effacement.
Après le “must”, en cas de don ou de revente, à minima d'un disque, est d'utiliser ‘dd’, tel que :
dd if=/dev/urandom of=/dev/HD bs=1m
Bien-sûr, ‘HD’ est en réalité le nom du périphérique, et dépend de la nomenclature OS.
Sous OpenBSD, ce serait ‘rsd1c’, par exemple, pour le deuxième HD.
Si unbound résoud localement, sur la station, il est possible d'utiliser juste le champ local-data…
Tel que :
local-data: "eulerian.com A 127.0.0.1"
local-data: "eulerian.com AAAA ::1"
Et de faire de même pour les sous-domaines, et autres domaines à cibler ;)
Un restart de unbound, et go… enfin pas très loin parce que localhost seulement !
T’as l’expérience avec Gitlab pour pouvoir comparer ou pas du tout ?
Article intéressant à propos de la contre-attaque de Cloudflare contre Blackbird (chasseur de brevets).
C'est également ce qui est mis en avant sur les calculatrices lycée.
Ça peut être une solution aussi pour un VIM totalement en CLI :)
En fait en y relechissant je me rend compte que ce n'est peut-être pas la peine de faire plugin, suffit de lancer un conteneur avec un vim dedans, et de partager sa conf via un volume.
Ah je connaissais pas, mais ça à l'air sympa :o
Ça ne semble cependant pas trop difficile à implémenter, et visiblement il y a déjà des gens qui ont fait des plugins pour ça -> https://github.com/schnauzers/devcontainer :)
Ça m'a donné envie de retenter de passer à VIM une quatrième fois… (^_^‘)
Mais il faudrait que je me fasse un plugin pour reproduire le.comportement des “devcontainers” de VSCode.
Ça c'est vraiment hyper cool, je vais essayer de m'amuser cette semaine avec l'outil. Merci pour l'info !
Très bon article, coïncidence j'ai fait un article très similaire il y a quelques jours : https://blog.hackera.fr/jouer-sur-linux.html
Le monde du libre a clairement un problème avec les noms. Avec certains projets, on a l'impression qu'après des milliers d'heures de travail sur le code, on choisit comme parrain le cousin Gérard après le trentième verre de mauresque au bar du village. “Eh les mecs ! Moi j'vous dis qu'il faut qu'on appelle notre projet de smartphone libre slash euh slash !”
TL;DR : des “problèmes techniques” et le “tracker eulerian c'est pas un tracker publicitaire, c'est pour un usage interne”
Franchement, leur ligne de défense est quand même fourbe. Jouer la carte de “c'est un tracker pour nous pas un tracker publicitaire” mouai c'est un peu gros. Ce serait réellement le cas, le Google Analytics qu'ils ont déjà ferait déjà l'affaire.
La force d'Eulerian est justement d'avoir des informations mutualisées entre leurs différents clients…
Il faut bien payer le travail des journalistes autrement que par le financement par la publicité.
Dommage que l'article soit payant. Je propose cette source qui cite le même article :
https://www.lemonde.fr/pixels/article/2019/11/13/la-surveillance-des-reseaux-sociaux-contre-la-fraude-fiscale-adoptee-a-l-assemblee_6019063_4408996.html
Bon, trois problèmes à cette analyse.
Premièrement, elle se base sur le concept de la « tragédie des communs » de Garrett Hardin, qui s'avère être bidon (un peu comme toutes les théories économique libérales), cf. https://lejournal.cnrs.fr/billets/la-tragedie-des-communs-etait-un-mythe. Du coup, il faudrait peut-être arrêter de baser nos sociétés, nos fonctionnements, etc. sur des théories qui ont fait la preuve de leur inexactitude et de leurs effets néfastes. Ce qui est paradoxal c'est que l'article enchaîne ensuite avec les travaux de Olstrom qui contredisent ceux de Hardin
Ce qui nous amène au deuxième problème, c'est qu'il fait, en plus d'une interprétation très personnelle, une application sélective des principes de Olstrom au domaine de l'open-source.
Troisièmement, le parallèle entre gestion du logiciel open-source et gestion d'un bien commun limité est tordu, et je me demande s'il tient vraiment… On passe du logiciel lui-même et sa communauté, à ses “clients” étant le bien commun, tout en gardant d'appliquer les principes de gestion de commune au logiciel qui pourtant du coup n'est plus l'objet “bien commun”…
C'est accepté sur le Jdh, tant que c'est dans la ligne éditoriale, pas de honte a avoir ;)
https://usbeketrica.com/article/intelligence-artificielle-art-ou-artifice #autopromo
Oui en effet.
Pour dire plus, c'est même pas un billet de ma part mais une reprise de celui de Thierry, le papa de NuTyX, pour informer et faire de l’écho à une distribution peu connue et fort sympathique.
Cela me fait penser que sous OpenBSD, on a l'option
-Pà l'outilrmqui écrit de manière aléatoire des données avant l'effacement.Après le “must”, en cas de don ou de revente, à minima d'un disque, est d'utiliser ‘dd’, tel que :
Bien-sûr, ‘HD’ est en réalité le nom du périphérique, et dépend de la nomenclature OS. Sous OpenBSD, ce serait ‘rsd1c’, par exemple, pour le deuxième HD.
Si unbound résoud localement, sur la station, il est possible d'utiliser juste le champ local-data…
Tel que :
Et de faire de même pour les sous-domaines, et autres domaines à cibler ;) Un restart de unbound, et go… enfin pas très loin parce que localhost seulement !