Adrien Dorsaz a écrit 952 commentaires

J'ai oublié d'avertir, que la modification a été fusionnée avec cet autre PR.

E.T. peut enfin téléphoner maison

Ce suivi est donc à clore :)

L'introduction de cette dépêche semble faire la même erreur que dans sa sœur ce serait la huitième edition du Kernel Recipes et pas la neuvième :-)

D'ailleurs, je pense que l'introduction est un peu malheureuse, parce qu'elle ne nomme pas l'Embedded Recipes qui semble être le sujet ici ;-)

Ce n'est pas toujours facile de persévérer pour contribuer à un projet. Le temps disponible n'est pas infini.

Un point important pour moi est donc que je puisse monter facilement un environnement de développement pour pouvoir bidouiller.

C'est ce qui m'a plu avec le code en C d'HomeBank: le langage est assez simple ce qui permet de monter facilement mon environnement et de modifier le code rapidement.

Avec LinuxFr, j'ai eu pas mal de peine à réussir à monter correctement mon poste de développement (j'ai essayé plusieurs fois ces dernières années et c'est avec Debian Stretch que j'ai eu la meilleur expérience). Par contre, quand j'ai réussi à le monter, j'ai eu accès à toutes les facilités offertes par Ruby on Rails: un serveur web local, un outil de gestion des mises à jour debase de donnée, de configuration des routes…

En plus, Ruby on Rails est une communauté avec une bonne documentation de ce que j'ai vu, c'est un second point important :-)

Pour la partie web, je dois dire aussi que Mozilla fait un très bon travaille de documentation d'HTML, de CSS et de JavaScript. C'est un point dont on ne parle pas souvent, mais je tombe souvent sur la documentation de Mozilla et jamais sur celle de Chrome (alors que je cherche via Google ;)).

Enfin, j'ai la chance de pouvoir travailler à 80% (donc environ 33h/semaines sur 4 jours, en Suisse) ce qui me laisse plus de temps pour m'amuser à bidouiller :-)

De rien :)

Ah pour le ratio de l'image, je vois maintenant que c'est du 3:1 qui a été prévu avec un affichage à 900x300 pour les grands écrans. Du coup, je vais faire les formats 300x100, 600x200 et 900x300.

Si jamais, j'ai réussi à avancer sur ce sujet: j'ai enfin réussi sur mon poste de dev d'ajouter des images dans le template de rédaction et de permettre leur modification (sans verrou).

Je vais préparer une branche propre avec cette proposition:

1. Je ne traite que les images sur les dépêches
2. L'image et sa référence seront enregistrés dans la table news (et news_version) avec une colonne chacun
3. L'image sera transformée pour avoir un ratio de 3.5:1 (avec les rendus à 350x100 pixels, 700x200, 1050x300 et 1300x400 pixels)
4. Le rendu ne sera pas fait en MarkDown, mais directement en HTML5 depuis les informations de la base de donnée

Tout commentaire est bienvenu sur ces décisions :)

Ouh la la, je suis bien content dene pas travailler dans ce genre de milieu :-)

Franchement, refuser même les mises à jour de sécurité de Debian, c'est quand même de la folie…

Debian Jessie à Firefox ESR 60 de disponible: je te conseille de faire les mises à jour, c'est risqué de butiner avec un vieux navigateur ;-)

Hello,

Grâce à ce commentaire à propos des boutons de download, je me rend compte qu'avant de se lancer dans l'implémentation du nouveau design, il faut d'abord choisir quels navigateurs on souhaite supporter.

Pour Chrome, c'est difficile de retrouver les anciennes versions, Google force les mises à jour et ne supporte que la dernière version. Je propose de supporter la version Chromium de Debian oldstable (soit la version 57): https://packages.debian.org/search?keywords=chromium

Pour Firefox, je propose de faire la même chose puisque Debian utilise déjà les version ESR, on peut utiliser la version ESR de Debian oldstable (soit la version 60): https://packages.debian.org/search?suite=default&section=all&arch=any&searchon=names&keywords=firefox-esr

Pour Android c'est beaucoup plus compliqué, car le navigateur par défaut dépend des mises à jour des constructeurs (jusqu'à la version Lolipop). Si les utilisateurs ont la version L et le Google Play Store, alors leur webview suit les mises à jour de Chrome. Pour les autres, il faudrait soit installer "Chrome pour Android", soit "Firefox".

Pour iOS, je ne pourrais même pas tester et du coup, je ne sais même pas ce que je pourrais imaginer comme "version minimale" :/

J'avais déjà prévu une correction pour IE, il devrait aussi corriger l'affichage de ces anciens navigateurs: à la place d'utiliser les grid de CSS, je joue simplement avec la désactivation du float que l'on utilisait avant.

Le pull request est disponible ici: https://github.com/linuxfrorg/linuxfr.org/pull/235

Non c'est le navigateur de base.

Pour Android, le "navigateur par défaut/de base" n'existe pas par exemple sur les smartphones Samsung, c'est un navigateur spécial fait par Samsung (qui est sûrement crée au-dessus du WebView d'Android, mais ça ne change pas grand chose à mon problème: je ne peux pas tester, je n'ai pas le matériel).

En plus, ce genre de navigateur pose des problèmes de sécurité à cause de certains algorithmes indisponibles (par exemple, certains algorithmes de TLS) ou des failles de sécurité jamais corrigées. D'ailleurs, Google a décidé de ne plus lier le "navigateur par défaut" à Android, mais de livrer "Chrome pour Android" pour que les mises à jours du navigateurs ne doivent plus attendre les mises à jours Android des constructeurs (qui sont quasiment inexistantes).

Est ce que les version ESR de Firefox fonctionnent toutes ? voilà ce qu'il faut trouver le temps de tester.

Qu'est-ce que tu entends par "les versions ESR de Firefox fonctionnent toutes" ?

Il n'y en a qu'une seule (voire 2 pendant quelques semaines de chevauchement): https://wiki.mozilla.org/Release_Management/Calendar.

Par exemple, pour Firefox ESR 45, cette version est sortie en 2016 et n'est plus supportée par Mozilla depuis la version ESR 52.2 sortie en juin 2017. Cette version est elle-même remplacée par le support de la version ESR 60.2 sortie en septembre 2018. Cette version actuelle ESR perd son support cet automne.

Si tu veux vraiment les supporter "toutes", la première version ESR est sortie en janvier 2012 ;-)

PS: tu peux cliquer aussi sur le tritre des éléments pour lire la suite.

pas compris

Pour lire les articles au complet, je voulais dire que le titre des dépĉhes/journaux/liens/entrées de forum est aussi un lien cliquable pour voir l'article complet.

Pour Android, je n'ai pas de version 4 ou 5 sous la main et il dépend du constructeur si je me souviens bien.

Pour Debian Jessie, je veux bien regarder, mais bon, Stretch est disponible depuis 2 ans et Buster sera bientôt dispo…

PS: tu peux cliquer aussi sur le tritre des éléments pour lire la suite.

Oui, il est chouette :)

J'avais besoin d'un DE léger pour une machine virtuelle et il fonctionne vraiment bien !

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.

… on pourra directement intégré le futur logo ;-)

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).

Il a écrit dans un commentaire plus bas:

… 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.

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 :)

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:

1. il vire tout le code HTML qui pourrait y être présent
2. il lit le reste avec la syntaxe qu'il a choisi
3. 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…