Il faudrait configurer le serveur web de www.gimp.org pour servir l'image avec le bon content-type. Pour le moment, ça dit que c'est de l'audio/unknown, et LinuxFr.org n'accepte que des images sur le sous-domain img.
Donc ta position, c'est qu'il ne se passe rien d'intéressant côté Open Hardware qui mérite un journal ou une dépêche sur LinuxFr.org. C'est bien ça que tu veux dire ?
Pour ma part, je me refuse à ne pas aborder le sujet sur LinuxFr.org. Et je ne crois pas qu'un jour un projet magique va arriver et changer complètement la donne.
Je ne vois que trop rarement des initiatives sur le sujet, alors quand j'en vois une passer, j'en envie d'en parler même si ce n'est qu'un tout petit pas dans la bonne direction. Oui, c'est probablement assez creux, plus de marketing que de réalisations concrètes, mais ça reste mieux que le status quo. Et si tu as mieux à proposer, je t'encourage à en parler (même si c'est pour montrer les limites). Ce n'est pas en enterrant le sujet et en évitant d'en parler complètement que les choses vont avancer.
J'ai corrigé le soucis de copier/coller. Pour la fin, ça ne passe pas, il y a une limite de longueur pour les titres et elle est atteinte entre « fabriqué » et « en ».
Toujours est-il qu'en fin de compte on se retrouve avec une version communautaire qui n'est pas très appréciée par la communauté, voir complètement rejetée, et une version non communautaire très largement plébiscité par la communauté !
C'est une affirmation très arbitraire. dep a plus de 10 000 étoiles sur github, ce qui ne correspond pas vraiment à une version complètement rejetée par la communauté. Je pense que la plupart des développeurs Go s'en fiche du choix de l'un ou l'autre, l'important pour eux est qu'il y est enfin un outil officiel pour faire ça.
Oui, la bibliothèque des regexp est particulièrement bien optimisée en Rust et c'est une partie de la réponse. Mais il y a d'autres éléments. Par exemple, l'algorithme de recherche utilisé (ce sont des variantes de Boyer-Moore qui sont utilisés par tous les greps) est un peu plus poussé dans le cas de ripgrep : il fait une analyse rapide de la fréquence des caractères pour choisir un caractère peu fréquent à utiliser avec memchr.
Russ Cox a dit qu'il avait présenté un premier brouillon de ses travaux fin 2017 au "package management group" et ce groupe a voté pour que dep intègre ses travaux (ou disparaisse). L'équipe derrière dep était en désaccord avec cette décision prise par un petit groupe (et c'est cette décision que je qualifie de prise par Google). Et c'est cette étape qui a clairement marqué la fin de dep.
Alors, oui, derrière, on peut dire qu'il y a une proposition officielle des go modules et qu'il n'y a jamais eu de proposition officielle pour dep (l'équipe de dep n'aurait pas demandé mieux, mais Russ Cox n'a jamais pris la peine de leur dire comment dep aurait pu s'intégrer aux go tools, qui était une étape obligatoire pour faire cette proposition). Et une fois que Russ Cox a publié ces papiers en février et que l'équipe de Dep était devenue complètement démotivée, ça n'a plus été très compliqué de faire approuver la proposition officielle.
Je ne critique pas le résultat. C'est possible que les modules Go (la suite de vgo) soient très bien, je ne les ai pas encore utilisés. Par contre, je ne me fais guère d'illusions sur le processus de décision : c'est Google qui décide, un point c'est tout.
Je note que ton commentaire laisse entendre que la réflexion autour de Dep s'est faite lors de discussions privées, alors que les réflexions autour de vgo se sont faites dans les issues github. Pourtant, c'est bien le contraire qui s'est passé. Le dépôt dep a toujours été accessible, avec une licence libre. Il y a eu des discussions dans les issues et sur un slack (OK, ce n'est pas forcément le meilleur outil). Les principaux contributeurs ont même tenu des réunions ouvertes à tout le monde. Les seules réunions privées étaient celles organisées par Russ Cox (Google) qui devait faire le suivi de l'expérimentation et rapporter les avancements à un comité de Google.
À l'inverse, Russ Cox (Google) a travaillé sur vgo seul dans son coin. Puis, il a présenté vgo à un petit comité (Google) et leur a demandé de trancher entre dep et vgo. Ce comité a tranché pour vgo (la proposition interne de Google). Et c'est seulement plus tard que la proposition a été rendue publique et que la communauté a pu faire des retours dessus.
Non, il n'y a rien de prévu dans ce style pour le moment.
Ceci dit, il y a du Go en production sur LinuxFr.org depuis quelques années, avec epub et img. Et ça ne me déplairait pas de faire un autre daemon dans ce style en Rust si le besoin se présente.
Dans ma dépêche Des alternatives à grep, ls et find, on m'a fait remarqué que certains outils en ligne de commande écrits en Go ont un certain succès :
Ha, je m'étais aussi noté d'essayer neoformat, un autre greffon qui sert à remettre en forme le code à chaque sauvegarde. Par exemple, en utilisant gofmt pour du Go ou Prettier pour du JS ou de la CSS.
J'utilise depuis un bout de temps Neomake (avec Neovim). Ce greffon avait justement été initié pour corriger le côté synchrone bloquant de syntastic. Je suis content de neomake, même si je n'ai pas comparé avec ALE.
Humm, je me demande si le problème ne vient pas d'une incompréhension. Il est possible pour l'auteur d'une dépêche d'ajouter des tags à sa dépêche quand celle-ci est dans l'espace de rédaction. Mais, quand la dépêche est soumise à modération, elle n'est plus accessible qu'à l'équipe de modération et personne d'autres ne peut alors y ajouter de tags.
Ce n'est pas vraiment que le code puisse être mutable en Elixir, c'est juste que le langage permette de réaffecter une valeur à une variable déjà assignée. Par exemple :
# Une histoire de content-type
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Linuxfr n'a pas réussi à mettre en cache une image webp. Évalué à 4 (+0/-0).
Il faudrait configurer le serveur web de www.gimp.org pour servir l'image avec le bon content-type. Pour le moment, ça dit que c'est de l'
audio/unknown
, et LinuxFr.org n'accepte que des images sur le sous-domain img.[^] # Re: open-washing
Posté par Bruno Michel (site web personnel) . En réponse au journal Thelio Io, de l'Open-Hardware par System76. Évalué à 8.
Donc ta position, c'est qu'il ne se passe rien d'intéressant côté Open Hardware qui mérite un journal ou une dépêche sur LinuxFr.org. C'est bien ça que tu veux dire ?
Pour ma part, je me refuse à ne pas aborder le sujet sur LinuxFr.org. Et je ne crois pas qu'un jour un projet magique va arriver et changer complètement la donne.
Je ne vois que trop rarement des initiatives sur le sujet, alors quand j'en vois une passer, j'en envie d'en parler même si ce n'est qu'un tout petit pas dans la bonne direction. Oui, c'est probablement assez creux, plus de marketing que de réalisations concrètes, mais ça reste mieux que le status quo. Et si tu as mieux à proposer, je t'encourage à en parler (même si c'est pour montrer les limites). Ce n'est pas en enterrant le sujet et en évitant d'en parler complètement que les choses vont avancer.
# Merci
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Saut lorsque les pages sont défilées sur un téléphone . Évalué à 3 (+0/-0). Dernière modification le 03 novembre 2018 à 16:08.
Merci pour le correctif, c'est déployé en prod.
[^] # Re: Titre
Posté par Bruno Michel (site web personnel) . En réponse au lien L'état chinois suspecté d'avoir introduit des puces espionnes dans le design de matériel. Évalué à 5.
J'ai corrigé le soucis de copier/coller. Pour la fin, ça ne passe pas, il y a une limite de longueur pour les titres et elle est atteinte entre « fabriqué » et « en ».
[^] # Re: Pb de lien
Posté par Bruno Michel (site web personnel) . En réponse au journal LinuxFr.org : seconde quinzaine de septembre 2018. Évalué à 3. Dernière modification le 03 octobre 2018 à 13:29.
C'est corrigé. Merci pour le signalement.
[^] # Re: Coquille
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche GHC 8.4 et 8.6. Évalué à 4.
C'est corrigé.
[^] # Re: Go -> Rust
Posté par Bruno Michel (site web personnel) . En réponse au journal Go et Rust, lequel est le remplaçant du C ?. Évalué à 3.
C'est une affirmation très arbitraire. dep a plus de 10 000 étoiles sur github, ce qui ne correspond pas vraiment à une version complètement rejetée par la communauté. Je pense que la plupart des développeurs Go s'en fiche du choix de l'un ou l'autre, l'important pour eux est qu'il y est enfin un outil officiel pour faire ça.
[^] # Re: performances RipGrep
Posté par Bruno Michel (site web personnel) . En réponse au journal softs dev en Rust empaqueté pour Ubuntu & cie. Évalué à 7.
Oui, la bibliothèque des regexp est particulièrement bien optimisée en Rust et c'est une partie de la réponse. Mais il y a d'autres éléments. Par exemple, l'algorithme de recherche utilisé (ce sont des variantes de Boyer-Moore qui sont utilisés par tous les greps) est un peu plus poussé dans le cas de ripgrep : il fait une analyse rapide de la fréquence des caractères pour choisir un caractère peu fréquent à utiliser avec
memchr
.https://blog.burntsushi.net/ripgrep/ donne pas mal d'informations pour ceux qui veulent creuser le sujet.
[^] # Re: Go -> Rust
Posté par Bruno Michel (site web personnel) . En réponse au journal Go et Rust, lequel est le remplaçant du C ?. Évalué à 5.
Russ Cox a dit qu'il avait présenté un premier brouillon de ses travaux fin 2017 au "package management group" et ce groupe a voté pour que dep intègre ses travaux (ou disparaisse). L'équipe derrière dep était en désaccord avec cette décision prise par un petit groupe (et c'est cette décision que je qualifie de prise par Google). Et c'est cette étape qui a clairement marqué la fin de dep.
Alors, oui, derrière, on peut dire qu'il y a une proposition officielle des go modules et qu'il n'y a jamais eu de proposition officielle pour dep (l'équipe de dep n'aurait pas demandé mieux, mais Russ Cox n'a jamais pris la peine de leur dire comment dep aurait pu s'intégrer aux go tools, qui était une étape obligatoire pour faire cette proposition). Et une fois que Russ Cox a publié ces papiers en février et que l'équipe de Dep était devenue complètement démotivée, ça n'a plus été très compliqué de faire approuver la proposition officielle.
[^] # Re: Go -> Rust
Posté par Bruno Michel (site web personnel) . En réponse au journal Go et Rust, lequel est le remplaçant du C ?. Évalué à 6.
Je ne critique pas le résultat. C'est possible que les modules Go (la suite de vgo) soient très bien, je ne les ai pas encore utilisés. Par contre, je ne me fais guère d'illusions sur le processus de décision : c'est Google qui décide, un point c'est tout.
Je note que ton commentaire laisse entendre que la réflexion autour de Dep s'est faite lors de discussions privées, alors que les réflexions autour de vgo se sont faites dans les issues github. Pourtant, c'est bien le contraire qui s'est passé. Le dépôt dep a toujours été accessible, avec une licence libre. Il y a eu des discussions dans les issues et sur un slack (OK, ce n'est pas forcément le meilleur outil). Les principaux contributeurs ont même tenu des réunions ouvertes à tout le monde. Les seules réunions privées étaient celles organisées par Russ Cox (Google) qui devait faire le suivi de l'expérimentation et rapporter les avancements à un comité de Google.
À l'inverse, Russ Cox (Google) a travaillé sur vgo seul dans son coin. Puis, il a présenté vgo à un petit comité (Google) et leur a demandé de trancher entre dep et vgo. Ce comité a tranché pour vgo (la proposition interne de Google). Et c'est seulement plus tard que la proposition a été rendue publique et que la communauté a pu faire des retours dessus.
[^] # Re: Machine virtuelle ?
Posté par Bruno Michel (site web personnel) . En réponse au journal Go et Rust, lequel est le remplaçant du C ?. Évalué à 6. Dernière modification le 10 septembre 2018 à 17:28.
Non, Rust n'a pas de Garbage Collector.
[^] # Re: Go → Rust
Posté par Bruno Michel (site web personnel) . En réponse au journal Go et Rust, lequel est le remplaçant du C ?. Évalué à 10.
On peut quand même citer PDF.js, asm.js (et donc web assembly) et emscripten comme projets nés chez Mozilla et qui ont eu une vie ailleurs.
[^] # Re: Lequel est le remplaçant de Ruby?
Posté par Bruno Michel (site web personnel) . En réponse au journal Go et Rust, lequel est le remplaçant du C ?. Évalué à 8.
Non, il n'y a rien de prévu dans ce style pour le moment.
Ceci dit, il y a du Go en production sur LinuxFr.org depuis quelques années, avec epub et img. Et ça ne me déplairait pas de faire un autre daemon dans ce style en Rust si le besoin se présente.
[^] # Re: Go -> Rust
Posté par Bruno Michel (site web personnel) . En réponse au journal Go et Rust, lequel est le remplaçant du C ?. Évalué à 6.
Oui, et la manière dont dep a été écarté au profit de vgo l'a très clairement montré. Cf https://peter.bourgon.org/blog/2018/07/27/a-response-about-dep-and-vgo.html entre autres.
[^] # Re: Domaines différents
Posté par Bruno Michel (site web personnel) . En réponse au journal Go et Rust, lequel est le remplaçant du C ?. Évalué à 6.
Dans ma dépêche Des alternatives à grep, ls et find, on m'a fait remarqué que certains outils en ligne de commande écrits en Go ont un certain succès :
[^] # Re: Je crois qu'il manque un morceau de phrase
Posté par Bruno Michel (site web personnel) . En réponse au journal Go et Rust, lequel est le remplaçant du C ?. Évalué à 5.
Effectivement, j'ai eu un raté. J'ai corrigé la phrase en :
[^] # Re: Une autre alternative
Posté par Bruno Michel (site web personnel) . En réponse au journal vim: Au revoir syntastic, bonjour ALE. Évalué à 4.
Ha, je m'étais aussi noté d'essayer neoformat, un autre greffon qui sert à remettre en forme le code à chaque sauvegarde. Par exemple, en utilisant gofmt pour du Go ou Prettier pour du JS ou de la CSS.
# Une autre alternative
Posté par Bruno Michel (site web personnel) . En réponse au journal vim: Au revoir syntastic, bonjour ALE. Évalué à 5.
J'utilise depuis un bout de temps Neomake (avec Neovim). Ce greffon avait justement été initié pour corriger le côté synchrone bloquant de syntastic. Je suis content de neomake, même si je n'ai pas comparé avec ALE.
# Bug d'akregator ?
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi erreur d'encodage dans le flux atom.. Évalué à 3 (+0/-0).
A priori, tout a l'air bon côté LinuxFr.org, je me demande si ce n'est pas un bug d'akregator.
[^] # Re: Déjà le cas
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Ajout de tags sur les dépêches. Évalué à 3 (+0/-0). Dernière modification le 20 août 2018 à 20:09.
Bon, tu as bien fait d'insister. Ça ne marchait effectivement pas. Ça devrait aller mieux maintenant avec https://github.com/linuxfrorg/linuxfr.org/commit/e4419351211fdbc3ac7efae40ff1fd44f86c6eed
[^] # Re: Déjà le cas
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Ajout de tags sur les dépêches. Évalué à 3 (+0/-0).
Humm, je me demande si le problème ne vient pas d'une incompréhension. Il est possible pour l'auteur d'une dépêche d'ajouter des tags à sa dépêche quand celle-ci est dans l'espace de rédaction. Mais, quand la dépêche est soumise à modération, elle n'est plus accessible qu'à l'équipe de modération et personne d'autres ne peut alors y ajouter de tags.
[^] # Re: pour ma part je n'aime pas trop elixir
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Elixir, Phoenix et Membrane. Évalué à 4.
Ce n'est pas vraiment que le code puisse être mutable en Elixir, c'est juste que le langage permette de réaffecter une valeur à une variable déjà assignée. Par exemple :
http://blog.plataformatec.com.br/2016/01/comparing-elixir-and-erlang-variables/ explique pourquoi ce comportement a été choisi.
[^] # Re: Chrome-like, Firefox : les blocs de code sont 1,1x trop gros
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Quelques petits changements sur le site. Évalué à 5.
Merci, c'est corrigé. Cf https://github.com/linuxfrorg/linuxfr.org/commit/d5cc3ba84febdb11807abe42c308dad9f2d0dbda
[^] # Re: les raccourcis clavier
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Quelques petits changements sur le site. Évalué à 6.
La tribune dans la colonne de gauche n'a plus le focus par défaut maintenant. Cf https://github.com/linuxfrorg/linuxfr.org/commit/2f73fb881248e9bb32f71198ae981ce8c62d3730
# Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi [firefox mobile] le score cache le texte. Évalué à 4 (+0/-0). Dernière modification le 18 août 2018 à 23:07.
Cf https://github.com/linuxfrorg/linuxfr.org/commit/d5cc3ba84febdb11807abe42c308dad9f2d0dbda