Eh ben, c'est hyper intéressant de lire ces deux billets :-)
Ils ont eu de très bon commentaires sur leurs choix techniques avant même de les implémenter !
Je pense que ça a été très bénéfique pour eux cette transparence des choix techniques avant même leur mise en place: ils ont en tout cas évités des frais inutiles.
Tiens, il y a aussi un autre usage: le tir sportif.
J'y pense parce que je vais devoir bientôt voter pour durcir la loi sur les armes à feu en Suisse.
Et justement, un des arguments du comité contre cette mise à jour de la loi est que les tireurs sportifs ne pourraient plus utiliser d'arme (mais il me semble que leur argumentation est douteuse).
J'avais aussi l'habitude de "plus petit multiple commun" à l'école obligatoire, puis à l'uni on a parlé de "plus petit commun multiple". Comme en français les adjectifs peuvent être placés n'importe où (à peu près), tous les deux sont justes et expriment la même idée :)
Merci Kantien, ça me semble plus clairement posé que mon résumé :)
Quand tu écris ceci:
type patch
type state
val commit : patch -> state -> state
val merge : state -> state -> state
J'ai juste un doute sur les deux dernières lignes: commit et merge sont bien des fonctions prenant les 2 premiers éléments en paramètre et faisant un résultat du type du dernier élément ?
Pour essayer d'exprimer avec les conventions mathématiques dont j'ai un peu plus l'habitude (style f(x,y) = z avec les préfixes des arguments leur type):
commit(patch: x, state: A) = state: B
merge(state: A, state: B) = state: C
L'idée d'illustrer avec des opérations simples (multiplication et ppcm) sur les nombres est très bonne aussi.
Pour la phrase suivante:
La solution est de prendre un type plus riche que les liste pour les sommets du graphe : à savoir des graphes de lignes (dont les listes sont un cas particuliers).
Je trouve qu'elle explique mieux l'astuce de l'utilisation des graphes et elle n'utilise même pas le terme de graggle, bravo :) (quand je parlais de simplification de la représentation du fichier, c'est exactement ça, mais plus clairement exprimé en partant de la richesse du graphe au lieu de la "simplification/relaxation" de la liste).
Ok, j'ai lu les articles du blog de Joe Neeman et de ce que j'ai compris: non, il n'y a pas de magie dans pijul, les conflits de fusion sont encore à être traité par l'utilisateur pour avoir un fichier final cohérent.
Par contre, si je comprends bien, pijul devrait résoudre plus souvent les conflits automatiquement, grâce à la théorie des patchs mathématiques (au contrario de git qui fait de l'heuristique).
Dans son blog, Joe Neeman définit un patch mathématique comme ce ci:
Le patch dépend d'un fichier source
Le patch travaille ligne par ligne (et non pas mot par mot)
Un patch peut ajouter des lignes, mais ne pas les modifier
Pour le dernier point, ça paraît bizarre, mais c'est résolu dans pijul avec l'ajout d'un attribut "fantôme" à une ligne pour la marquer comme supprimée bien qu'elle reste dans la représentation de pijul.
Ensuite, il explique que ce framework mathématiques a besoin de simplifier la définition d'un fichier: un fichier n'est plus une simple liste ordrée de lignes, mais devient un graphe ordré de lignes. Cette simplification de la représentation d'un fichier permet à deux lignes différentes d'avoir la même ligne parente.
Cette représentation de fichier sous forme de graphe de lignes est appelée graggle (mot valise entre graphe et ligne) pour simplifier. Bien sûr, un graggle est inutilisable par un compilateur / un éditeur de texte si deux lignes ont le même parent.
Ce qui est intéressant, c'est que maintenant, pijul a beaucoup plus d'informations pour résoudre les conflits, car il ne va plus traiter les fichiers lignes par lignes, mais il va comparer des graphes mathématiques qui contiennent plus d'information, car chaque ligne a un parent et un enfant (alors qu'avec la liste on ne considérait que la position de la ligne dans la liste).
Enfin, la procédure de fusion est finalement celle-ci: en partant d'un fichier O (pour original), nous avons deux patchs p et q qui créent les versions A et B du fichier. Pour créer les patch r et s qui fusionnent respectivement depuis A et depuis B dans une nouvelle version commune du fichier nommée M (pour merged):
Ecrire les graggles de A et B l'un à côté de l'autre
Quand une ligne de A et de B partagent le même parent, fusionnez les parents en une seule ligne.
A la fin de cette procédure, pijul se retrouve avec un nouveau graggle M qui est cohérent dans sa représentation interne des fichiers. Par contre, cette version est impossible à utiliser pour nos outils qui s'attendent à avoir un fichier représenté sous une série ordrée de ligne (et non pas un graphe).
Il y a donc un conflit que l'utilisateur devra gérer en créant un nous patch t qui va transformer le graggle M en graggle F (pour flattened) qui aplatit à nouveau le graphe en une liste de ligne.
Le premier article amène très bien ces idées avec de bonnes illustrations, je vous conseille de les lire si vous voulez avoir une meilleure vision de ce qui se passe.
J'ai le sentiment que grâce à cette théorie pijul pourra résoudre plus souvent automatiquement les conflits, car il enregistre plus d'informations dans ses patchs (il travaille avec des graggles comme fichier source pour les patch).
En plus, dans les articles suivant, Joe Neeman montre la puissance de pijul avec un exemple assez simple: essayer de faire un patch qui annule un ancien patch, mais ceci après un merge dans l'historique. Dans ce cas, git perd les pédales et va demander à l'utilisateur de résoudre à nouveau un conflit. Alors que pijul saura bien se tirer d'affaire car, dans sa représentation interne, il n'y a jamais eu de conflit, il n'a eu qu'une simple série de patch (bien qu'en pratique l'utilisateur à du faire un patch supplémentaire pour aplatir le graphe).
Comme il a une série cohérente de patch et avec beaucoup d'informations (les graggles au lieu des fichiers), pijul peut s'en sortir très facilement de cette situation.
Un autre exemple qui est donné est la fonction cherry-pick de git: avec git, quand on veut récupérer un commit d'une branche à une autre, on se retrouve toujours avec des commits différents (leur hash est différent, et comme git ne travaille pas avec le contenu des commits, il ne sait pas que le contenu est identique). Le jour où on veut fusionner une branche qui a fait du cherry-pick sur une autre, git demande à nouveau de fusionner les fichiers (car il ne voit pas que c'était le même commit). Pijul s'en sort très bien dans ce cas, simplement parce qu'il travaille avec le contenu des graggles qui ont bien plus d'informations que des fichiers plats.
Finalement, j'espère qu'à terme pijul trouvera sa voie et fera beaucoup d'adepte comme git à l'époque où le marché était dominé par CVS et SVN. Il y a encore beaucoup de boulot, mais je pense sincèrement que Pierre-Étienne Meunier est sur la bonne voie avec cette innovation technologique (et ce surtout quand on se lance sur de nouveaux projets qui vont nécessiter du maintient de code à long terme).
… mais quand même tous les algos qui marchent, pour la première fois !
Et si j'ai bien compris, c'est la fête, parce que l'implémentation a réussi et la théorie tient la route :)
Bravo !
Il y a maintenant besoin de former une communauté qui se mette à travailler sur des articles de vulgarisation, des exemples, d'intégrer pijul a des forges logicielles…
PS: tous ces propos ne sont que mon point de vue formé sur les explications de Joe Neeman, un mathématicien externe au projet pijul qui analyse ces idées.
Ah pardon, c'est moi qui avait mal installé le système, il faut bien sûr installer le paquet ruby-rack pour faire fonctionner correctement board-linuxfr. Il faut que je mette à jour mon fichier d'installation :)
Merci pour la confirmation, je me doutais que la page de rédaction n'était pas complète à cause du manque des événements :)
Je suis un peu bloqué, je n'arrive pas à lancer board-linuxfr avec Ruby 2.3.
J'ai vu que Goliath a besoin de Ruby 1.9.2, j'ai donc suivi leur tutoriel d'installation, mais je n'arrive pas à l'installer. Il semble qu'il y ait un problème de versions nécessaire de ruby entre rack et goliath (j'ai dû même changer la version de rubygems pour réussir à lancer l'installation, c'est pas évident :/).
Du coup, je suis un peu bloqué pour continuer le travail sur l'espace de rédaction. Tu aurais une piste pour me sortir de ce sac de nœud de versions des différents composants ?
Je suis en train d'essayer de faire du dev sur l'espace de rédaction et je vois que mon navigateur essaie de joindre la route "/b/un_identifiant_a_rallonge". Cette route n'est pas enregistrée dans rails et du coup je reçois un 404.
Dans ton ansible, j'ai vu que tu demandais à Nginx de rediriger "/b/" vers un socket unix "board.sock". Est-ce que tu te souviens de ce que c'est ? J'ai l'impression d'avoir raté quelque chose.
Edit:
Ah ben je viens de voir le lien the board-daemon dans le Readme :)
Par rapport à HTML, les syntaxes comme Markdown / BBCode sont utiles pour empêcher l'injection de code malicieux dans ton site.
Pour les sites, c'est donc bien plus simple de valider le texte reçu de l'utilisateur:
il vire tout le code HTML qui pourrait y être présent
il lit le reste avec la syntaxe qu'il a choisi
il fait un rendu pour l'utilisateur et demande la confirmation à l'utilisateur.
Il serait également possible de définir un sous-ensemble des tags et attributs HTML et faire le même travail en théorie. Mais ça demande plus d'investissement: il faut utiliser une représentation XML et l'utiliser pour enlever tout ce qui n'est pas dans ta liste blanche de balises et attributs HTML.
Ok et avais-tu déjà choisi de les stocker en base de donnée ou sur le système de fichier ? Je ne sais pas trop ce qui est envisageable comme je ne connais pas l'architecture système actuelle…
Pour cette série, je me pose des plusieurs questions:
Si on commence à faire intégrer une image par article, est-ce qu'il faut commencer à proposer le stockage des images directement sur le serveur de LinuxFr ? L'idée, c'est qu'avec ce nouveau design, l'image fait vraiment partie de l'article, du coup, faudrait-il un stockage pérenne ou on continue d'accepter des liens qui peuvent casser ?
Pour la citation de l'auteur de l'image en Markdown, il ne semble pas y avoir de manière standard. Est-ce que l'on ajoute une nouvelle notation spécifique à LinuxFr ? Ou est-ce que l'on met toujours la citation dans le texte alternatif de l'image ? J'ai vu aussi sur Stack Overflow une solution proposant d'utiliser le tag HTML <cite> pour les bloques de citation.
Pour l'instant, je vais faire des tests où on continue de ne pas stocker d'images sur LinuxFr. Dans ce cas, j'ai juste besoin d'ajouter un champ aux articles qui contient le lien Markdown avec la citation.
Merci pour la mise à jour de la maquette, j'aime bien cette proposition qui permet de retrouver la source sans avoir à toujours afficher le bouton pour le Markdown.
Si je me souviens bien, la fonctionnalité de télécharger le fichier "Epub" est arrivée il y a 4-5 ans dans la vie du site. En fait, c'est vraiment plus pratique pour la plupart des lecteurs et je trouve que c'est une bonne idée de mettre en avant uniquement ce média hors-ligne.
Le bouton "Afficher la source" est aussi pratique pour pouvoir exporter son article vers d'autres plateformes qui comprennent le Markdown (comme des blogs personnels, par exemple).
Pour l'instant, je propose de laisser le pied de page tel qu'il est actuellement et de reprendre les modifications selon le plan que Bruno a mis dans les commentaires ci-dessus. Ça vous convient ?
Il y a peut-etre une solution plus simple: garder le fonctionnement actuel, mais désactiver le float en mobilité. Cette solution permettrait de rester compatible avec IE.
Le résultat en mobile donne sur Firefox Desktop avec gabarit pour Galaxy S9/S9+:
J'ai testé sous Interne Explorer 10 et cette solution casse un peu l'affichage du lien "Lire la suite" (les boutons de téléchargements débordent un peu par dessus).
PS: J'ai ré-ouvert l'entrée de suivi pour ce fil de commentaire.
En effet, j'ai remarqué que sur mobile les liens Markdown et Epub apparaissent bizarrement. J'ai vérifié et c'était déjà le cas avant d'ajouter ces images.
Pour améliorer ça, il faudrait repenser la CSS du site pour éviter d'utiliser des float et préférer les CSS Grids. Apparemment, beaucoup de navigateurs supportent les CSS Grid maintenant, je vais voir ce que je peux faire.
Merci pour la fusion, la réactivité est appréciée :)
C'est très intéressant la liste proposée par Matthieu, je vais la découper et faire une entrée de suivi par partie. Ça permettra de montrer à tout le monde où on en est et ce qu'il y a encore à faire.
Pour ma part cette demande est très étrange : habitué à lire toutes mes nouvelles du jour sur mon propre lecteur RSS, je peste d'habitude contre les sites qui m'imposent des résumés d'articles pour me forcer à visiter leur site.
Du coup, je suis vraiment surpris par cette demande et je serai bien intéressé à comprendre un peu mieux comment tu utilises tiny rss ? Est-ce que tu l'utilises comme point centrale de notification ? Est-ce que tu consultes uniquement des sites web qui ont un design qui s'adapte à la taille de ton écran ?
Si on essaie d'imaginer cette fonctionnalité, quelle taille de texte voudrais-tu retrouver dans ton lecteur RSS ? Uniquement les titres ? Ou le titre avec les 20 premiers mots ? Ou au moins 150 caractères ?
Par rapport au journal précédent, j'ai trouvé cette information supplémentaire:
Parfois, cela coûte même cher aux développeurs qui doivent payer pour leur serveur ou d’autres services.
Le moment est peut-être venu d'allier travail et plaisir : et si la blockchain permettait aux développeurs open source, dans le cadre d'un système économique parallèle, d'échanger ou d'acheter des services, des outils, des produits ?
Cette nouvelle crypto-monnaie veut se concentrer sur cette idée.
En admettant que demain mes quelques développements open-source requièrent une infrastructure importante et coûteuse, je comprends avec ce paragraphe que je devrais me "tourner" vers l'Elphyrecoin.
Qu'est-ce que je dois faire alors pour commencer à bénéficier de cette blockchain ?
Utiliser la confiance de mes éventuels donateurs/utilisateurs pour leur demander de recevoir des dons via cette monnaie ?
Quelles garanties puis-je avoir que je vais pouvoir "échanger ou acheter des services, des outils, des produits" ?
Si aujourd'hui, je vais sur votre page web, je vois des logos de Bitcoin à la place de votre logo sur des images et j'ai donc déjà mon alarme "attention phising" qui s'allume. Un deuxième indice est l'image avec un graphe qui "monte", mais qui ne représente rien, si ce n'est une "rassurante" courbe montante (enfin, pas tout à fait rien, il y a le texte "bitcoin" à côté du graphique…).
Ensuite, je trouve le livre blanc dans le pied de page qui me donne à peu près les mêmes informations que dans ces 2 journaux (il contient aussi les choix techniques pour la configuration de la cryptomonnaie).
Enfin, les autres liens pointent vers des réseaux sociaux disponibles uniquement sur inscription (Telegram, discord) ou avec peu d'informations rapidement compréhensible (Github, Twitter).
Ces informations sont pour moi vraiment trop maigre pour prendre une décision aussi importante que d'influencer d'autres personnes et prendre le risque de leur faire perdre de l'argent.
Surtout que j'imagine que la première remarque des mes donateurs sera une phrase du style: "Je voudrais te faire un don, mais je n'utilise que les Bitcoin (Cash ou non) et ils te permettent déjà d'échanger, acheter des services, des outils, des produits. Si tu ne proposes qu'Elphyrecoin, je ne pourrais pas te faire de don.".
Il me semble que le paramètre que tu cherches est ici:
Ouvrir Gnome Settings
Dans le panneau latéral de gauche (GNOME 3.30), choisir "Recherche"
Faire défiler le panneau principal jusqu'au fond de la liste
A la fin de la liste, il y a une boîte à outil, il faut cliquer sur le bouton avec la roue dentelée
Un popup s'ouvre avec plusieurs onglets, choisir l'onglet "Autre"
Ajouter les dossiers supplémentaires à chercher
Dans les autres onglets, désactiver les dossiers proposés par défaut (je pense au moins à "Dossier Personnel")
Je n'ai jamais essayé, parce que j'aime bien la recherche, mais ça devrait le faire, parce que tu passes à un fonctionnement en "Whitelist".
Si tu veux fonctionner en blacklist, tu peux soit ajouter des fichiers vides ".trackerignore" dans tes dossiers à ne pas indexé, soit directement modifier la configuration de tracker avec dconf-editor (org.freedesktop.tracker.miner.files ; tu peux aussi y configurer le nom du fichier à ajouter).
J'avais rapidement essayé de reprendre le déploiement docker qui était présent un temps, mais c'était compliqué de le mettre à jour avec mes maigres connaissances et en plus ça demandait pas mal d'actions manuelles.
Avec Debian Stretch et ses backports, l'installation est devenue bien plus simple qu'avant, quand on devait récupérer Ruby depuis le site du projet :-)
[^] # Re: previously, in "gitlab migrations"
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au lien Gitlab migre de Azure vers GCP et explique pourquoi (spoil : azure sucks). Évalué à 4.
Eh ben, c'est hyper intéressant de lire ces deux billets :-)
Ils ont eu de très bon commentaires sur leurs choix techniques avant même de les implémenter !
Je pense que ça a été très bénéfique pour eux cette transparence des choix techniques avant même leur mise en place: ils ont en tout cas évités des frais inutiles.
# Il vaut mieux attendre encore un peu...
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Mise à jour logo Red Hat. Évalué à 3 (+0/-0).
… on pourra directement intégré le futur logo ;-)
[^] # Re: le web dans sa fange
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal Firefox ne peut plus utiliser d'extension. Évalué à 3. Dernière modification le 07 mai 2019 à 06:54.
Tiens, il y a aussi un autre usage: le tir sportif.
J'y pense parce que je vais devoir bientôt voter pour durcir la loi sur les armes à feu en Suisse.
Et justement, un des arguments du comité contre cette mise à jour de la loi est que les tireurs sportifs ne pourraient plus utiliser d'arme (mais il me semble que leur argumentation est douteuse).
[^] # Re: Exemples concrets?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 2.
J'avais aussi l'habitude de "plus petit multiple commun" à l'école obligatoire, puis à l'uni on a parlé de "plus petit commun multiple". Comme en français les adjectifs peuvent être placés n'importe où (à peu près), tous les deux sont justes et expriment la même idée :)
[^] # Re: Exemples concrets?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 2.
Merci Kantien, ça me semble plus clairement posé que mon résumé :)
Quand tu écris ceci:
J'ai juste un doute sur les deux dernières lignes:
commitetmergesont bien des fonctions prenant les 2 premiers éléments en paramètre et faisant un résultat du type du dernier élément ?Pour essayer d'exprimer avec les conventions mathématiques dont j'ai un peu plus l'habitude (style
f(x,y) = zavec les préfixes des arguments leur type):L'idée d'illustrer avec des opérations simples (multiplication et ppcm) sur les nombres est très bonne aussi.
Pour la phrase suivante:
Je trouve qu'elle explique mieux l'astuce de l'utilisation des graphes et elle n'utilise même pas le terme de
graggle, bravo :) (quand je parlais de simplification de la représentation du fichier, c'est exactement ça, mais plus clairement exprimé en partant de la richesse du graphe au lieu de la "simplification/relaxation" de la liste).[^] # Re: Exemples concrets?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 10.
Ok, j'ai lu les articles du blog de Joe Neeman et de ce que j'ai compris: non, il n'y a pas de magie dans pijul, les conflits de fusion sont encore à être traité par l'utilisateur pour avoir un fichier final cohérent.
Par contre, si je comprends bien, pijul devrait résoudre plus souvent les conflits automatiquement, grâce à la théorie des patchs mathématiques (au contrario de git qui fait de l'heuristique).
Dans son blog, Joe Neeman définit un patch mathématique comme ce ci:
Pour le dernier point, ça paraît bizarre, mais c'est résolu dans pijul avec l'ajout d'un attribut "fantôme" à une ligne pour la marquer comme supprimée bien qu'elle reste dans la représentation de pijul.
Ensuite, il explique que ce framework mathématiques a besoin de simplifier la définition d'un fichier: un fichier n'est plus une simple liste ordrée de lignes, mais devient un graphe ordré de lignes. Cette simplification de la représentation d'un fichier permet à deux lignes différentes d'avoir la même ligne parente.
Cette représentation de fichier sous forme de graphe de lignes est appelée graggle (mot valise entre graphe et ligne) pour simplifier. Bien sûr, un graggle est inutilisable par un compilateur / un éditeur de texte si deux lignes ont le même parent.
Ce qui est intéressant, c'est que maintenant, pijul a beaucoup plus d'informations pour résoudre les conflits, car il ne va plus traiter les fichiers lignes par lignes, mais il va comparer des graphes mathématiques qui contiennent plus d'information, car chaque ligne a un parent et un enfant (alors qu'avec la liste on ne considérait que la position de la ligne dans la liste).
Enfin, la procédure de fusion est finalement celle-ci: en partant d'un fichier O (pour original), nous avons deux patchs p et q qui créent les versions A et B du fichier. Pour créer les patch r et s qui fusionnent respectivement depuis A et depuis B dans une nouvelle version commune du fichier nommée M (pour merged):
A la fin de cette procédure, pijul se retrouve avec un nouveau graggle M qui est cohérent dans sa représentation interne des fichiers. Par contre, cette version est impossible à utiliser pour nos outils qui s'attendent à avoir un fichier représenté sous une série ordrée de ligne (et non pas un graphe).
Il y a donc un conflit que l'utilisateur devra gérer en créant un nous patch t qui va transformer le graggle M en graggle F (pour flattened) qui aplatit à nouveau le graphe en une liste de ligne.
Le premier article amène très bien ces idées avec de bonnes illustrations, je vous conseille de les lire si vous voulez avoir une meilleure vision de ce qui se passe.
J'ai le sentiment que grâce à cette théorie pijul pourra résoudre plus souvent automatiquement les conflits, car il enregistre plus d'informations dans ses patchs (il travaille avec des graggles comme fichier source pour les patch).
En plus, dans les articles suivant, Joe Neeman montre la puissance de pijul avec un exemple assez simple: essayer de faire un patch qui annule un ancien patch, mais ceci après un merge dans l'historique. Dans ce cas, git perd les pédales et va demander à l'utilisateur de résoudre à nouveau un conflit. Alors que pijul saura bien se tirer d'affaire car, dans sa représentation interne, il n'y a jamais eu de conflit, il n'a eu qu'une simple série de patch (bien qu'en pratique l'utilisateur à du faire un patch supplémentaire pour aplatir le graphe).
Comme il a une série cohérente de patch et avec beaucoup d'informations (les graggles au lieu des fichiers), pijul peut s'en sortir très facilement de cette situation.
Un autre exemple qui est donné est la fonction cherry-pick de git: avec git, quand on veut récupérer un commit d'une branche à une autre, on se retrouve toujours avec des commits différents (leur hash est différent, et comme git ne travaille pas avec le contenu des commits, il ne sait pas que le contenu est identique). Le jour où on veut fusionner une branche qui a fait du cherry-pick sur une autre, git demande à nouveau de fusionner les fichiers (car il ne voit pas que c'était le même commit). Pijul s'en sort très bien dans ce cas, simplement parce qu'il travaille avec le contenu des graggles qui ont bien plus d'informations que des fichiers plats.
Finalement, j'espère qu'à terme pijul trouvera sa voie et fera beaucoup d'adepte comme git à l'époque où le marché était dominé par CVS et SVN. Il y a encore beaucoup de boulot, mais je pense sincèrement que Pierre-Étienne Meunier est sur la bonne voie avec cette innovation technologique (et ce surtout quand on se lance sur de nouveaux projets qui vont nécessiter du maintient de code à long terme).
Il a écrit dans un commentaire plus bas:
Et si j'ai bien compris, c'est la fête, parce que l'implémentation a réussi et la théorie tient la route :)
Bravo !
Il y a maintenant besoin de former une communauté qui se mette à travailler sur des articles de vulgarisation, des exemples, d'intégrer pijul a des forges logicielles…
PS: tous ces propos ne sont que mon point de vue formé sur les explications de Joe Neeman, un mathématicien externe au projet pijul qui analyse ces idées.
[^] # Re: Exemples concrets?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 7.
J'ai regardé les anciens contenus linuxfr tagués pijul, je suis tombé sur Hacker News, puis sur ce lien: https://jneem.github.io/archive/
Il y a quatre postes de blog assez long, mais qui m'ont l'air mieux formaté et plus concret :)
[^] # Re: Version ansible
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Fichier INSTALL.md détaillé pour guider les nouveaux contributeurs. Évalué à 2 (+0/-0).
Ah pardon, c'est moi qui avait mal installé le système, il faut bien sûr installer le paquet
ruby-rackpour faire fonctionner correctementboard-linuxfr. Il faut que je mette à jour mon fichier d'installation :)[^] # Re: Version ansible
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Fichier INSTALL.md détaillé pour guider les nouveaux contributeurs. Évalué à 2 (+0/-0).
Merci pour la confirmation, je me doutais que la page de rédaction n'était pas complète à cause du manque des événements :)
Je suis un peu bloqué, je n'arrive pas à lancer board-linuxfr avec Ruby 2.3.
J'ai vu que Goliath a besoin de Ruby 1.9.2, j'ai donc suivi leur tutoriel d'installation, mais je n'arrive pas à l'installer. Il semble qu'il y ait un problème de versions nécessaire de ruby entre rack et goliath (j'ai dû même changer la version de rubygems pour réussir à lancer l'installation, c'est pas évident :/).
Du coup, je suis un peu bloqué pour continuer le travail sur l'espace de rédaction. Tu aurais une piste pour me sortir de ce sac de nœud de versions des différents composants ?
[^] # Re: Version ansible
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Fichier INSTALL.md détaillé pour guider les nouveaux contributeurs. Évalué à 2 (+0/-0). Dernière modification le 20 avril 2019 à 22:09.
Je suis en train d'essayer de faire du dev sur l'espace de rédaction et je vois que mon navigateur essaie de joindre la route "/b/un_identifiant_a_rallonge". Cette route n'est pas enregistrée dans rails et du coup je reçois un 404.
Dans ton ansible, j'ai vu que tu demandais à Nginx de rediriger "/b/" vers un socket unix "board.sock". Est-ce que tu te souviens de ce que c'est ? J'ai l'impression d'avoir raté quelque chose.
Edit:
Ah ben je viens de voir le lien the board-daemon dans le Readme :)
[^] # Re: Intérêt réel du Markdown ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal Saletés de codes différents et tutoriel wiki. Évalué à 6.
Par rapport à HTML, les syntaxes comme Markdown / BBCode sont utiles pour empêcher l'injection de code malicieux dans ton site.
Pour les sites, c'est donc bien plus simple de valider le texte reçu de l'utilisateur:
Il serait également possible de définir un sous-ensemble des tags et attributs HTML et faire le même travail en théorie. Mais ça demande plus d'investissement: il faut utiliser une représentation XML et l'utiliser pour enlever tout ce qui n'est pas dans ta liste blanche de balises et attributs HTML.
[^] # Re: 1ère série - préparer le terrain dans l'espace de rédaction
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Implémenter le nouveau design de LinuxFR. Évalué à 2 (+0/-0).
Ok et avais-tu déjà choisi de les stocker en base de donnée ou sur le système de fichier ? Je ne sais pas trop ce qui est envisageable comme je ne connais pas l'architecture système actuelle…
# 1ère série - préparer le terrain dans l'espace de rédaction
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Implémenter le nouveau design de LinuxFR. Évalué à 3 (+0/-0). Dernière modification le 15 avril 2019 à 09:50.
Pour cette série, je me pose des plusieurs questions:
Si on commence à faire intégrer une image par article, est-ce qu'il faut commencer à proposer le stockage des images directement sur le serveur de LinuxFr ? L'idée, c'est qu'avec ce nouveau design, l'image fait vraiment partie de l'article, du coup, faudrait-il un stockage pérenne ou on continue d'accepter des liens qui peuvent casser ?
Pour la citation de l'auteur de l'image en Markdown, il ne semble pas y avoir de manière standard. Est-ce que l'on ajoute une nouvelle notation spécifique à LinuxFr ? Ou est-ce que l'on met toujours la citation dans le texte alternatif de l'image ? J'ai vu aussi sur Stack Overflow une solution proposant d'utiliser le tag HTML
<cite>pour les bloques de citation.Ah ben, je vois qu'il y avait déjà une proposition ici pour la citation: https://linuxfr.org/suivi/ajouter-le-texte-alternatif-en-bas-des-images Cette proposition utilise en plus les nouveaux tags HTML5, c'est le bon moment pour commencer à les utiliser :)
Pour l'instant, je vais faire des tests où on continue de ne pas stocker d'images sur LinuxFr. Dans ce cas, j'ai juste besoin d'ajouter un champ aux articles qui contient le lien Markdown avec la citation.
[^] # Re: Cas d'usage pour le téléchargement en markdown ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Design: ajouter une icône de téléchargement à côté des liens Markdown et Epub. Évalué à 2 (+0/-0).
Salut Matthieu,
Merci pour la mise à jour de la maquette, j'aime bien cette proposition qui permet de retrouver la source sans avoir à toujours afficher le bouton pour le Markdown.
Si je me souviens bien, la fonctionnalité de télécharger le fichier "Epub" est arrivée il y a 4-5 ans dans la vie du site. En fait, c'est vraiment plus pratique pour la plupart des lecteurs et je trouve que c'est une bonne idée de mettre en avant uniquement ce média hors-ligne.
Le bouton "Afficher la source" est aussi pratique pour pouvoir exporter son article vers d'autres plateformes qui comprennent le Markdown (comme des blogs personnels, par exemple).
Pour l'instant, je propose de laisser le pied de page tel qu'il est actuellement et de reprendre les modifications selon le plan que Bruno a mis dans les commentaires ci-dessus. Ça vous convient ?
[^] # Re: CSS à ajuster ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Design: ajouter une icône de téléchargement à côté des liens Markdown et Epub. Évalué à 2 (+0/-0).
Chouette, merci pour la fusion :)
[^] # Re: CSS à ajuster ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Design: ajouter une icône de téléchargement à côté des liens Markdown et Epub. Évalué à 2 (+0/-0).
Il y a peut-etre une solution plus simple: garder le fonctionnement actuel, mais désactiver le float en mobilité. Cette solution permettrait de rester compatible avec IE.
Il faut que je teste d'abord.
[^] # Re: CSS à ajuster ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Design: ajouter une icône de téléchargement à côté des liens Markdown et Epub. Évalué à 2 (+0/-0). Dernière modification le 08 avril 2019 à 22:13.
Re,
J'ai regardé cette piste et en effet les CSS Grids fonctionnent mieux que
floatpour faire du responsive design.J'ai posté l'évolution ici: https://github.com/linuxfrorg/linuxfr.org/pull/234
Le résultat en mobile donne sur Firefox Desktop avec gabarit pour Galaxy S9/S9+:
J'ai testé sous Interne Explorer 10 et cette solution casse un peu l'affichage du lien "Lire la suite" (les boutons de téléchargements débordent un peu par dessus).
PS: J'ai ré-ouvert l'entrée de suivi pour ce fil de commentaire.
[^] # Re: CSS à ajuster ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Design: ajouter une icône de téléchargement à côté des liens Markdown et Epub. Évalué à 2 (+0/-0).
En effet, j'ai remarqué que sur mobile les liens Markdown et Epub apparaissent bizarrement. J'ai vérifié et c'était déjà le cas avant d'ajouter ces images.
Pour améliorer ça, il faudrait repenser la CSS du site pour éviter d'utiliser des float et préférer les CSS Grids. Apparemment, beaucoup de navigateurs supportent les CSS Grid maintenant, je vais voir ce que je peux faire.
[^] # Re: Merci pour le patch
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Design: ajouter une icône de téléchargement à côté des liens Markdown et Epub. Évalué à 3 (+0/-0).
Hello,
Merci pour la fusion, la réactivité est appréciée :)
C'est très intéressant la liste proposée par Matthieu, je vais la découper et faire une entrée de suivi par partie. Ça permettra de montrer à tout le monde où on en est et ce qu'il y a encore à faire.
# Comment utilises-tu les RSS ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Limiter la taille des articles dans les flux RSS. Évalué à 6 (+0/-0).
Hello,
Pour ma part cette demande est très étrange : habitué à lire toutes mes nouvelles du jour sur mon propre lecteur RSS, je peste d'habitude contre les sites qui m'imposent des résumés d'articles pour me forcer à visiter leur site.
Du coup, je suis vraiment surpris par cette demande et je serai bien intéressé à comprendre un peu mieux comment tu utilises tiny rss ? Est-ce que tu l'utilises comme point centrale de notification ? Est-ce que tu consultes uniquement des sites web qui ont un design qui s'adapte à la taille de ton écran ?
Si on essaie d'imaginer cette fonctionnalité, quelle taille de texte voudrais-tu retrouver dans ton lecteur RSS ? Uniquement les titres ? Ou le titre avec les 20 premiers mots ? Ou au moins 150 caractères ?
[^] # Re: commentaire bookmark
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au lien Suse is once again an independent company - OSnews. Évalué à 6. Dernière modification le 25 mars 2019 à 17:14.
Et autant donner directement la vrai source ;-)
https://www.suse.com/c/news/suse-completes-move-to-independence-reaffirms-commitment-to-customers-partners-and-open-source-communities-as-industrys-largest-independent-open-source-company/
# Pour qui ? Par qui ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal Elphyrecoin : la cryptomonnaie au service de l'opensource. Évalué à 10. Dernière modification le 19 mars 2019 à 22:22.
Hello,
Par rapport au journal précédent, j'ai trouvé cette information supplémentaire:
En admettant que demain mes quelques développements open-source requièrent une infrastructure importante et coûteuse, je comprends avec ce paragraphe que je devrais me "tourner" vers l'Elphyrecoin.
Qu'est-ce que je dois faire alors pour commencer à bénéficier de cette blockchain ?
Utiliser la confiance de mes éventuels donateurs/utilisateurs pour leur demander de recevoir des dons via cette monnaie ?
Quelles garanties puis-je avoir que je vais pouvoir "échanger ou acheter des services, des outils, des produits" ?
Si aujourd'hui, je vais sur votre page web, je vois des logos de Bitcoin à la place de votre logo sur des images et j'ai donc déjà mon alarme "attention phising" qui s'allume. Un deuxième indice est l'image avec un graphe qui "monte", mais qui ne représente rien, si ce n'est une "rassurante" courbe montante (enfin, pas tout à fait rien, il y a le texte "bitcoin" à côté du graphique…).
Ensuite, je trouve le livre blanc dans le pied de page qui me donne à peu près les mêmes informations que dans ces 2 journaux (il contient aussi les choix techniques pour la configuration de la cryptomonnaie).
Enfin, les autres liens pointent vers des réseaux sociaux disponibles uniquement sur inscription (Telegram, discord) ou avec peu d'informations rapidement compréhensible (Github, Twitter).
Ces informations sont pour moi vraiment trop maigre pour prendre une décision aussi importante que d'influencer d'autres personnes et prendre le risque de leur faire perdre de l'argent.
Surtout que j'imagine que la première remarque des mes donateurs sera une phrase du style: "Je voudrais te faire un don, mais je n'utilise que les Bitcoin (Cash ou non) et ils te permettent déjà d'échanger, acheter des services, des outils, des produits. Si tu ne proposes qu'Elphyrecoin, je ne pourrais pas te faire de don.".
[^] # Re: GNOME et Vie privée
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au lien GNOME 3.32 est disponible - Developpez.com. Évalué à 3. Dernière modification le 17 mars 2019 à 07:45.
Hello,
Il me semble que le paramètre que tu cherches est ici:
Je n'ai jamais essayé, parce que j'aime bien la recherche, mais ça devrait le faire, parce que tu passes à un fonctionnement en "Whitelist".
Si tu veux fonctionner en blacklist, tu peux soit ajouter des fichiers vides ".trackerignore" dans tes dossiers à ne pas indexé, soit directement modifier la configuration de tracker avec dconf-editor (
org.freedesktop.tracker.miner.files; tu peux aussi y configurer le nom du fichier à ajouter).[^] # Re: Retour de bâton
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au lien pour bien s'amuser avec son éditeur de texte favori. Évalué à 5.
Ils n'ont plus qu'à s'échanger les domaines xD
[^] # Re: Version ansible
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Fichier INSTALL.md détaillé pour guider les nouveaux contributeurs. Évalué à 2 (+0/-0).
Super, c'est une bonne nouvelle :-)
J'avais rapidement essayé de reprendre le déploiement docker qui était présent un temps, mais c'était compliqué de le mettre à jour avec mes maigres connaissances et en plus ça demandait pas mal d'actions manuelles.
Avec Debian Stretch et ses backports, l'installation est devenue bien plus simple qu'avant, quand on devait récupérer Ruby depuis le site du projet :-)