Je parlais bien de la vitesse du code généré. J'aurais bien aimé avoir une référence, car il me semblait justement que Go avait les mêmes performances que Rust, voir légèrement mieux, pour le moment.
Je vais voir ce que je peux faire pour corriger automatiquement ce qui peut l'être. Parce que tu as corrigé 2 pages, mais il en reste environ 170 autres. Donc, à la main, ça va être très long ;-)
Si le système de karma reste bien sûr perfectible. Mais il est assez illusoire de croire qu'il va filtrer magiquement tous les lourds et rien d'autres. Il remplit plutôt bien son rôle, mais un pénible qui a beaucoup de temps devant lui finira toujours par trouver comment contourner le système à son avantage.
Là, tu décris une situation particulière qui a été réglée par l'intervention d'un admin. Je ne vois pas trop ce que je pourrais modifier sur le système de karma à partir de ce cas très spécifique. Je ferme donc cette entrée de suivi.
Par exemple, pour les programmes en go sur lesquels je code (quelques milliers de ligne au code tout au plus), je n'utilise que go run. Ça compile à la volée le code puis exécuté le binaire généré dans la foulée, et c'est instantané même sur des PC pas récents.
Et c'est, paraît-il, encore beaucoup plus impressionnant sur des programmes bien plus conséquents.
Rust est plus sûr que go, mais pour la rapidité, je demande à voir. Est-ce que tu as une source pour affirmer ça ? Il me semblait au contraire que le dernier benchmark que j'avais vu montrer que les performances étaient équivalentes entre ces 2 langages.
Ça ne me plaît vraiment pas de faire sauter le cache pour les erreur 4xx et 5xx, car on pourrait alors facilement se servir des images LinuxFr.org pour faire un deni de service d'un autre site. Il faudrait plutôt trouver une autre solution.
Pour les liens, c'est vraiment bizarre, je ne vois pas de quoi ça peut venir et je n'ai même pas réussi à retrouver la requête en question dans les logs de nginx.
Pour la réorganisation, la dépêche est bien longue et la requête prend plus de 30 secondes pour faire ça. Or unicorn est configuré pour tuer toute requête qui prend plus de 30s en production. D'où les erreurs.
J'ai fait quelques optimisations et je pense que l'on peut maintenant réorganiser la dépêche (avec une requête qui prend donc moins de 30 secondes). Dis moi si tu as toujours le problème.
Je viens de vérifier sur Epub validator, les epubs générés par LinuxFr.org sont tout à fait valides. Je pense qu'il faudrait plutôt remonter le problème aux logiciels qui n'acceptent pas ces epubs.
Bon, je me suis battu avec ElasticSearch et il a bien fini par vouloir ré-indexer toutes les dépêches. J'avoue que je n'ai pas tout compris au pourquoi du comment. Mais bon, les dépêches sont là et il y a une autre entrée de suivi pour corriger les problèmes d'indexation plus en profondeur.
# Doublon
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Markdown et espaces insécables. Évalué à 3 (+0/-0).
Cf http://linuxfr.org/suivi/espace-insecable
[^] # Re: Go vs C++ (et Rust ?) : Minimalisme versus sophistication
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Présentation de Rust 0.8. Évalué à 2.
Je parlais bien de la vitesse du code généré. J'aurais bien aimé avoir une référence, car il me semblait justement que Go avait les mêmes performances que Rust, voir légèrement mieux, pour le moment.
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Gestion des pages supprimées du wiki. Évalué à 4 (+0/-0).
Cf https://github.com/nono/linuxfr.org/compare/e76ba3029e09...e98c1fa4fedc
[^] # Re: Parcours des pages du wiki
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Le wiki a été vidé. Évalué à 4 (+0/-0).
J'ai lancé ce script :
Ça m'a l'air d'avoir corrigé la très grande majorité des liens (si ce n'est tous). Je ferme donc l'entrée.
[^] # Re: Parcours des pages du wiki
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Le wiki a été vidé. Évalué à 3 (+0/-0).
Oui, j'ai touché aux slugs. Le cache n'était pas sensible à la casse à cause d'un problème de collation MySQL. Cela pouvait poser quelques soucis, cf http://linuxfr.org/suivi/deux-depeches-ne-peuvent-avoir-le-meme-titre.
Je vais voir ce que je peux faire pour corriger automatiquement ce qui peut l'être. Parce que tu as corrigé 2 pages, mais il en reste environ 170 autres. Donc, à la main, ça va être très long ;-)
[^] # Re: Bof
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Pas de cache images pour les erreurs. Évalué à 3 (+0/-0).
Fait. Cf https://github.com/nono/linuxfr.org/commit/22b7a20e0f5f31b66332fec5a258bb7f0f9d5e59
# Heu...
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Linuxfr fait-il bien la distinction entre nouveaux maladroits, les relous et les spammeurs ?. Évalué à 4 (+0/-0).
Si le système de karma reste bien sûr perfectible. Mais il est assez illusoire de croire qu'il va filtrer magiquement tous les lourds et rien d'autres. Il remplit plutôt bien son rôle, mais un pénible qui a beaucoup de temps devant lui finira toujours par trouver comment contourner le système à son avantage.
Là, tu décris une situation particulière qui a été réglée par l'intervention d'un admin. Je ne vois pas trop ce que je pourrais modifier sur le système de karma à partir de ce cas très spécifique. Je ferme donc cette entrée de suivi.
[^] # Re: Et go ?
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Présentation de Rust 0.8. Évalué à 3.
Je confirme, go compile vraiment très rapidement.
Par exemple, pour les programmes en go sur lesquels je code (quelques milliers de ligne au code tout au plus), je n'utilise que
go run
. Ça compile à la volée le code puis exécuté le binaire généré dans la foulée, et c'est instantané même sur des PC pas récents.Et c'est, paraît-il, encore beaucoup plus impressionnant sur des programmes bien plus conséquents.
[^] # Re: Go vs C++ (et Rust ?) : Minimalisme versus sophistication
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Présentation de Rust 0.8. Évalué à 2.
Rust est plus sûr que go, mais pour la rapidité, je demande à voir. Est-ce que tu as une source pour affirmer ça ? Il me semblait au contraire que le dernier benchmark que j'avais vu montrer que les performances étaient équivalentes entre ces 2 langages.
# Bof
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Pas de cache images pour les erreurs. Évalué à 4 (+0/-0).
Ça ne me plaît vraiment pas de faire sauter le cache pour les erreur 4xx et 5xx, car on pourrait alors facilement se servir des images LinuxFr.org pour faire un deni de service d'un autre site. Il faudrait plutôt trouver une autre solution.
[^] # Re: raccourcis claviers
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Tester d'autres éditeurs de texte que markitup. Évalué à 3 (+0/-0).
Oui, ainsi qu'à http://markitup.jaysalvat.com/home/, l'éditeur actuellement utilisé sur LinuxFr.org.
[^] # Re: Nous
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi WebFinger. Évalué à 3 (+0/-0).
Nous, contributeurs de LinuxFr.org :p
[^] # Re: Idem
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Trop de texte pour le diff, impossible de réorganiser la dépêche?. Évalué à 3 (+0/-0).
Pour les liens, c'est vraiment bizarre, je ne vois pas de quoi ça peut venir et je n'ai même pas réussi à retrouver la requête en question dans les logs de nginx.
Pour la réorganisation, la dépêche est bien longue et la requête prend plus de 30 secondes pour faire ça. Or unicorn est configuré pour tuer toute requête qui prend plus de 30s en production. D'où les erreurs.
J'ai fait quelques optimisations et je pense que l'on peut maintenant réorganiser la dépêche (avec une requête qui prend donc moins de 30 secondes). Dis moi si tu as toujours le problème.
Cf https://github.com/nono/linuxfr.org/commit/71cc672d84b12d8f2be1cec72121c34c9e62d36b
[^] # Re: Note
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Affichage des formules mathématiques. Évalué à 3 (+0/-0).
Et le bug chez redcarpet : https://github.com/vmg/redcarpet/issues/313
# Note
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Affichage des formules mathématiques. Évalué à 3 (+0/-0).
Pour la syntaxe markdown, voir http://kramdown.rubyforge.org/syntax.html#math-blocks
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Bannières actives ou non. Évalué à 3 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/903efb9dae5fe7e0e79fed6368ecca67fee1519b
# Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Deux dépêches ne peuvent avoir le même titre ? . Évalué à 4 (+0/-0).
En fait, la différence entre les 2 dépêches étaient la présence ou non d'un accent sur le 'À'. MySQL avait un comportement assez drôle :
J'ai modifié les collations, cf https://github.com/nono/linuxfr.org/commit/35dca086965e8407b1aeda6fe81694fc3eac421d pour corriger ça.
# Epubs valides
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Epub et Android. Évalué à 4 (+0/-0).
Je viens de vérifier sur Epub validator, les epubs générés par LinuxFr.org sont tout à fait valides. Je pense qu'il faudrait plutôt remonter le problème aux logiciels qui n'acceptent pas ces epubs.
# Vote du public
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Vote: Pertinent/inutile - d'accord/pas d'accord. Évalué à 3 (+0/-0).
L'entrée de suivi a un score de -2 actuellement => je ferme cette entrée.
# Non
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Décocher par défaut la case licence "Creative Commons". Évalué à 3 (+0/-0).
Nous cherchons à promouvoir les contenus sous licences libres, aussi est-il pertinent que la licence proposée par défaut soit CC by-sa.
# Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Impossible de prévisualiser si un utilise mal la syntaxe Markdown pour les images. Évalué à 5 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/c21888c3327cdea1d72c286cbfd8647aab9eb435
# Effectivement
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Les liens vers Wikipédia en https ne sont pas indiqués par un petit W. Évalué à 3 (+0/-0).
Bien vu, c'est corrigé avec https://github.com/nono/linuxfr.org/commit/0fe5b0443cc65a54cdd2475da53d7ae793e41870.
# Bof
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Empêcher les doublons. Évalué à 3 (+0/-0).
On a déjà un système anti-doublon. Il n'est pas parfait et en bidouillant, on peut arriver à le contourner. Mais bon, je pense que ça suffit comme ça.
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Gestion des balises video + source. Évalué à 3 (+0/-0).
Cf https://github.com/nono/html-pipeline-linuxfr/commit/f92c62335db01d3d927961f7f115c1f2d8b25929
# mwais
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Le moteur de recherche ne renvoie plus les dépêches. Évalué à 4 (+0/-0).
Bon, je me suis battu avec ElasticSearch et il a bien fini par vouloir ré-indexer toutes les dépêches. J'avoue que je n'ai pas tout compris au pourquoi du comment. Mais bon, les dépêches sont là et il y a une autre entrée de suivi pour corriger les problèmes d'indexation plus en profondeur.