raphj a écrit 1339 commentaires

Merci pour la coquille :-)

Je vois plusieurs possibilités :

• tout le monde n'implémente pas ça strictement. Dans mon université, pas de spf, dkim, dmarc et ils refusent de l'implémenter. On peut se faire passer pour n'importe qui ayant une adresse électronique de cette université y compris le président. Je pense que c'est vrai dans beaucoup d'universités.

• ces mécanismes servent surtout à empêcher l'usurpation d'identité et la modification des messages. On peut faire du spam qui respectent ces mécanismes même si ce n'est régulièrement pas le cas.

Merci, échec de copier-coller !

Merci à vous deux :-)

L'intérêt immédiat pour moi est que j'utilise déjà letsencrypt pour les sites que j'héberge donc un certificat de plus c'est facile à mettre en place.

Je serais intéressé de savoir s'il y a d'autres intérêts :-)

Le processus de vérification est manuel : je vérifie périodiquement que les fichiers sont là. Je m’en sers aussi de temps en temps, parce que j’ai envie de consulter ou restaurer une version précédente d’un fichier. Mais effectivement, rien de très rigoureux.

Pour ce qui est de la restauration, si jamais mon serveur tombe en rade ça sera une réinstallation manuelle. Mettre en place un système de restauration un peu automatique serait certainement trop lourd à mon niveau pour le moment. De toute façon je ne pourrais pas trop restaurer automatiquement les choses depuis la maison, la connexion montante est trop faible pour ça, et le faire périodiquement voudrait certainement dire d’avoir un serveur virtuel additionnel.

Pour ce qui est du chiffrement, il faudrait voir quelle attaque elle préviendrait : mon serveur virtuel doit de toute façon pouvoir accéder aux données, donc la clé serait quelque part dessus. La seule manière pour le moment d’accéder aux données est de rentrer dans le serveur, mais à ce moment il est possible d’accéder à la clé.

Idem pour l’ordinateur de la maison. Je pourrais chiffrer le disque dur externe au cas où il serait volé et l’ordi non, mais ça ne facilite pas une restauration des données en cas de problème avec le système de fichiers.

L’ordinateur portable sera chiffré à un moment donné, c’est probablement ce que je suis le plus susceptible de me faire voler.

Merci pour le commentaire ! Ce sont des éléments importants et si je pouvais modifier mon journal je rajouterais tout ça.

et pourquoi SSH ? OK, j'ai pas cherché à savoir, mais si je veux du SSH, j'utilise ssh, pas Git. Chacun son taff.

Et moi, quand je veux faire mes sauvegardes avec rsync, je n'utilise pas SSH, chacun son… ah, merde :-D
Plus sérieusement, git peut aussi cloner à travers ssh, et c'est assez répandu ;-)
Réutiliser ssh dans ces cas permet de ne pas avoir à reconstruire tout un système d'identification et de transport sécurisé. On laisse ça a des gens sont c'est le domaine d'expertise et ça permet de réutiliser les infrastructures déjà en places. Ça me paraît plutôt bien :-)

Ou alors, ils auraient du proposer le choix, avec ou sans systemd. C’est chiant à gérer ? Oui, peut-être. Mais rien que pour le mail, combien de MTA existent ? Tu gardes exim ? Sendmail ? Postfix ? Un autre ? C’est chiant à gérer cette quantité de choix dans les repos, aller, on en garde qu’un seul !

Postfix, bien sûr. Mais vivement que Lennard nous écrive un bon vieux remplaçant pour retrouver le Simple de SMTP. (ah ah :-D)

Avant git, svn marchait du tonnerre aussi.
Et avant svn, cvs marchait du tonnerre également.

Et avant systemd, les scripts bash tous dégueulâsses dans tous les sens pour démarrer les services marchaient aussi relativement bien. (voilà, on fait comme ça)

Il me semble que la compilation chez Signal est reproductible et que l'application du Play Store est fournie telle qu'envoyée par les dev.

Ainsi, il y a normalement moyen de vérifier si le code source correspond au binaire.

Par contre, la compilation de Signal dépend des Google Play Services qui ne sont pas libres (toutes lignes com.google.android.gms:play-services du fichier https://github.com/signalapp/Signal-Android/blob/master/build.gradle).

Donc on n'a en fait pas accès à tout le code source du binaire… même si on compile Signal soit même.
Exécuter Signal veut dire exécuter du code non libre.

Et finalement, les hash des numéros sont relativement faciles à renverser, d'après Moxie lui-même, c'est un problème qui n'est pas résolu : https://en.wikipedia.org/wiki/Signal_(software)#

J'ai déjà utilisé Signal mais avec ces deux éléments et le fait :
- qu'on dépende d'un numéro de téléphone
- qu'on dépende d'Android (ou iOS) et de lancer au moins une fois l'application mobile Signal
- que les dev ne veulent pas d'application alternative sur leur réseau (ce qui a tué un fork entièrement libre de l'application Signal)
- que ça reste centralisé (mais bon, j'étais prêt à faire un compromis là dessus)

je suis maintenant assez réticent à l'utiliser et le promouvoir.

Exactement, les effets activés par défaut dans Plasma sont les mêmes que ceux d'OS X, de Gnome, de Windows et de Cinnamon, à quelque chose près. C'est à dire :

• les ombres sous les fenêtres;
• un fondu / zoom discret lorsqu'un menu de la barre ou une fenêtre est affichée ou masquée;
• un effet de glissement lors du changement d'espace de travail.

Tous ces effets sont des éléments d'utilisabilité qui conviennent à la plupart des gens. Et si on préfère ne pas les avoir, il est très simple et probablement plus simple que dans beaucoup d'autres environnements de les désactiver. L'environnement est également tout à fait utilisable sans le compositeur, à un niveau assez surprenant d'ailleurs. KDE sans accélération graphique sous X11 ? Facile.

Et si on veut plus, on peut activer tout un tas d'effets bling bling à la Compiz. C'est ce que j'aime chez KDE : des paramètres par défaut qui me paraissent censés, et une grande flexibilité dans les possibilités de configuration. Et le panneau de configuration un peu fouillis s'améliore sensiblement de version en version, il est déjà très bon.

Si on arrive à retrouver la partition btrfs (peut-être avec testdisk), probablement plutôt bien : https://linuxfr.org/users/raphj/journaux/btrfs-restore-a-la-rescousse

Oui, et je suis d'accord. Surtout que sway, ce n'est pas exactement le genre de projet utilisé par des gens qui ne sont pas au courant à priori.

Deuxième paragraphe : pourquoi ?

Je ne pense pas qu'il s'agisse d'être sectaire, je pense surtout que Drew en a ras le bol que des gens viennent râler auprès de lui contre un truc qu'il ne contrôle pas.

Même si c'est différent, il doit ressentir une frustration similaire à celle des développeurs web envers les utilisateurs d'IE il y a 10 ans.

En voyant ce journal, je me suis demandé ce qui a bien pu pousser les dev de ReactOS à prendre en charge Btrfs.

Si j'ai bien compris l'article source, il s'agirait de tester et renforcer la pile qui gère les pilotes de systèmes de fichiers NT dans ReactOS. Le pilote WinBtrfs est réutilisé.

Cela permet peut-être aussi de faire cohabiter ReactOS et Linux sur une même partition ? Mais attention quand même, winBtrfs est plus ou moins expérimental.

En ayant choisi KDE il y a 15 ans, tu aurais subit la transition KDE 3 / KDE 4 pas du tout évidente à négocier à cause de l'instabilité de KDE 4 à ses débuts. Plasma 5 n'était pas tip top au tout début non plus. J'ai longtemps décidé de rester sur KDE 4 quand il était très stable.

J'ai commencé avec KDE 3 (Mandrake 9/10 puis Mandriva 2006), puis Gnome 2 (Ubuntu), puis j'ai essayé KDE 4 (quand ce n'était pas stable), je suis revenu à Gnome 2 (je considérais qu'il n'y avait pas mieux), le tout avec quelques passage occasionnels à Xfce et e17 sur des ordis un peu légers, puis KDE 4 (les dernières versions étaient vraiment très stables) et Plasma 5 pour de bon (actuellement au moins aussi stable que les dernières version de KDE 4, et beaucoup plus joli, aussi. Breeze remplace avantageusement ce thème Oxygen grisâtre de KDE 4).

Ça peut être difficile de changer d'environnement. Aujourd'hui je suis plus ou moins coincé sur KDE depuis des années. Je ne trouve aucun autre environnent aussi pratique, que ce soit Gnome 3, Cinnamon, MATE ou ceux que j'ai mentionnés ci-avant. Et pourtant, beaucoup de gens qui ont essayé Plasma 5 préfèrent Cinnamon ou Gnome, y compris pour des raisons esthétiques.

Si tu as les mêmes repères avec Gnome que moi avec KDE, il faudra peut-être s'accrocher un peu.

Cinnamon le fait aussi.

Il semblerait que {a, b} = {a: 1, b: 2} sans let ou var et sans les parenthèses fonctionne avec nodejs mais que ça ne devrait pas d'après https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment#Object_destructuring

Et ça ne fonctionne (effectivement) pas dans Firefox.

Ah ah, oui, cette image m'amuse beaucoup.

En C++, tu as aussi intérêt à te limiter à un sous-ensemble assez restreint du langage.

J'aime bien ton article, il est bien documenté et soulève des points valides de manière respectueuse et agréable à lire.
Il se trouve que je ne suis quasiment pas affecté par les points négatifs que tu soulèves : je n'utilise pas (beaucoup) npm ni de bibliothèques externes, ni les webworkers. Je n'ai pour l'instant pas trop adopté la syntaxe des déconstructions pour des raisons de compatibilité des navigateurs mais je vais certainement bientôt m'y mettre, et pour null et undefined je me suis fait un modèle qui fonctionne pour moi (undefined = la fonction ne retourne rien de particulier, null est explicitement renvoyé quand l'élément n'existe pas mais effectivement ce n'est pas forcément idéal).

Pour ton { a, b } = o, ça s'explique certainement par le fait que { a, b } est interprété comme un bloc de code qui contient une instruction pas terminée par un point virgule (ce qui est autorisé en JS, et je ne suis pas fan de ça), et cette instruction a, b est composée de deux sous-instructions (qui sont des expressions…) séparées avec l'opérateur virgule. L'analyse syntaxique échoue au niveau du = parce = après un bloc de code n'a pas de sens. Les parenthèses interdisent l'analyseur de considérer les accolades comme un bloc de code. Je sais, c'est dommage. Ce n'est pas incompréhensible, mais je reconnais que c'est pénible.

Pour le ===, C'est pénible et c'est la même chose en PHP : j'ai décidé de considérer que == ne devait pas être utilisé.

Ben voyons.

Je n'ai pas affirmé qu'on peut écrire du beau code dans n'importe quel langage.

Le ruban de Turing est un modèle pour raisonner sur la calculabilité, raisonnements qui seraient lourds à faire avec un langage de programmation quelconque. Il n'est pas question d'écrire des programmes avec dans la vie de tous les jours. Le brainfuck n'est pas pensé pour écrire du code maintenable.

Un tas d'application à succès de taille respectable qui continuent à évoluer et à fonctionner ont été écrites avec du JS, c'est qu'elles doivent être un minimum maintenables (Firefox, Thunderbird, PDF.js, Signal, Wire, Wordpress, un tas de gros sites web, …).

On peut dire la même chose de PHP (malgré ses nombreuses incohérences - Nextcloud, WordPress…), de Java (malgré ses lourdeurs), de C (malgré le nombre de pièges dans lesquels on peut tomber), de C++ (malgré sa complexité)… et bien sûr, il est possible d'écrire du code médiocre dans ces langages.

Si un code n'est pas maintenable dans n'importe lequel de ces langages, c'est que les personnes qui l'ont écrit ont mal fait leur boulot, étaient inexpérimentées dans les langages utilisés, que le processus de développement a eu des loupés ou que le langage choisi n'est pas adapté au cas d'utilisation. Après, il y a des pièges dans tous les langages. Il est nécessaire de connaître profondément la sémantique des outils qu'on utilise et d'apprendre à éviter ces pièges (vous avez déjà utilisé une liste vide comme valeur par défaut d'un paramètre de fonction en Python ?). Si vous utilisez une scie sans avoir appris à l'utiliser, vous allez peut-être couper ce que vous vouliez couper, mais vous risquez aussi de vous couper un doigt. Et si vous savez vous en servir, vous risquez quand même de vous blesser, donc la vigilance reste de la partie.

En C aussi, on peut avoir du code qui compile et qui tourne, mais qui se vautre à l'exécution à cause d'un dépassement (quand on a la chance que ça crash !).

Et puis si quelqu'un ne se sent pas capable d'écrire du code propre en $LANGAGE parce cette personne n'accroche pas avec son fonctionnement, ce n'est pas grave, il y a d'autres langages qui pourront mieux lui convenir.

On peut écrire des immondices dans n'importe quel langage. Si les choses sont faites avec un peu de discipline, on peut arriver à un résultat correct.

Il suffit de ne pas faire n'importe quoi, d'utiliser un sous-ensemble correct du langage et de suivre les bonnes pratiques qu'on a choisies et de s'y tenir. Il y a des très bons linters si on veut avoir un peu de rigueur "garantie". Je ne les utilise plus actuellement mais j'en étais fan il y a quelques années et j'ai beaucoup appris grâce à eux.

Ne pas écrire du code trop intelligent, éviter les constructions bizarres, nommer ses variables correctement, et en fait appliquer les conseils qui s'appliquent à tous les langages font déjà beaucoup de bien.

Je préfère aussi avoir du typage statique mais ce n'est pas le seul aspect du langage et en l'occurrence, TypeScript offre un système de type meilleur que beaucoup de langages typés (mais il y a mieux aussi).

hey les gens, la "transpilation" C'EST DE LA COMPILATION, compiler ce n'est que transformer un langage dans un autre…

Pas la peine d'être désagréable comme ça.

Est-ce que le terme "transpiler" a été inventé par les gens du milieu Javascript ? Non.

Est-il est mal utilisé ? Pas à ma connaissance.

Est-il ambigu ou vague ? Non.

Quel est le problème d'utiliser "transpiler" à la place de "compiler" ?

On peut ne pas aimer le terme transpiler, et considérer que c'est une forme spécifique de compilation, et préférer juste dire compilation. On peut ne pas aimer les néologismes. Mais ça n'a rien à voir avec "ils ne connaissent tout simplement ce qui se fait en dehors de leur propre écosystème". C'est hors sujet.
Il y a une différence entre ignorance et choix.

Je ne changerai pas mon avis plus ou moins neutre sur le mot "transpiler" avec des remarques en majuscules et continuerai à l'utiliser tant que personne ne me donnera un argument solide.

Commenter c'est aussi écrire. Devrait-on dire "écrire" plutôt que "commenter" ? Non, "commenter" a un sens plus précis.

Je dis ça en ayant écrit un compilateur jouet (vers assembleur) et un transpileur (vers Javascript). Il y a plein de problèmes que je n'ai pas touchés dans le second cas, notamment l'allocation de registre (mais effectivement, il y a des problèmes de renommage dans les deux cas). Il y a aussi un problème que j'ai traité dans le second cas et pas dans le premier cas : la lisibilité du code produit, et calquer le formatage du code source. Pour moi ce n'est pas complètement aberrant de vouloir appeler ces deux trucs différemment et chaque camps devrait respecter les avis de l'autre camp.

Sur le fond du problème : Javascript a clairement ses travers et son écosystème est étouffant mais ce n'est clairement pas un mauvais langage. Après, il y a des questions de goût et des expressions comme "ad nauseam" n'ont rien à faire dans un argumentaire solide.

On peut ne pas aimer et ça ne se discute peut-être pas trop, mais on peut faire du Javascript correct sans utiliser la lourdeur de l'écosystème (perso j'écris systématiquement du Javascript standard ou du TypeScript occasionnellement).

Je ne comprends pas toute cette haine pour ce langage. Il faut juste passer un peu de temps à accepter ses défauts (il y en a beaucoup - mais j'en connais dans les autres langages que j'utilise), à comprendre son fonctionnement et à apprécier ses richesses. Et des langages comme TypeScript retirent une partie des problèmes si on veut plus de garanties sur les types.

Importe ton interpréteur Lua, je ne désactiverai pas mon bloqueur de scripts pour ton projet (ça me gonfle de voir mon navigateur devoir interpréter du code pour afficher un article), ma bande passante et mon processeur ont d'autres trucs à faire et les ressources énergétiques de la planète aussi. Après on parle de bibliothèques légères, faudrait voir à être cohérent. Grrr. Désolé pour le petit coup de gueule.

J'ai eu l'idée il y a quelques années de faire exactement ça.

Me rendant compte que ça voulait dire d'implémenter un moteur de rendu HTML/CSS, avec les difficultés du style traitement des textes bi-directionnels, j'ai abandonné.

J'ai essayé sur un document que j'ai écrit dans une syntaxe maison, le résultat est très bon.

J'ai toujours été frustré par la gestion des passages à la page suivante avec les impressions des moteurs de rendu classiques (au mauvais endroit, lignes coupées en deux) et autre problème (marges, taille de la police, WebKit qui ne prenait pas en charge les césure correctement).

Un « petit » manque : si MathJax est utilisé, les formules ne s'afficheront pas (j'imagine que prendre en charge Javascript n'est pas trivial). Pour ce cas particulier, KaTeX est une piste à explorer.

Peut-être qu'un jour on pourra écrire des articles pour des conférences comme ça ?

système de gestion de raccourcis clavier super sous Plasma mais bogué, ce qui veut dire que c'est soit impossible, soit incroyablement compliqué d'avoir à la fois ALT+< pour passer au morceau précédent et ALT+> au morceau suivant sur mon clavier AZERTY (https://bugs.kde.org/show_bug.cgi?id=397984)

Par un hasard assez fou, ce bogue vient d'être corrigé apparemment.

https://bugs.kde.org/show_bug.cgi?id=350816

Je ne vois pas pourquoi ça serait là pour faire chier. Je peux comprendre que monter la partition du téléphone sur l'ordinateur alors qu'elle est en cours d'utilisation sur le téléphone est un peu délicat. MTP est une solution à ce problème et je ne vois pas de raison particulière sur pourquoi ça ne devrait pas fonctionner correctement sous GNU/Linux.

Pour ma part j'utilise adb pull/push, scp ou rsync.

copier-coller avec la molette sous Wayland. Tant qu'on n'aura pas ça, pas de Wayland pour moi.

Sous GNOME avec Wayland ça marche.

Je crois qu'il s'agit d'une extension à Wayland, pas encore standard. Du coup, ça ne marche pas sous tous les environnements, ou selon les bibliothèques graphiques. J'ai bon espoir que ça se standardise.

Encore une fois, le développeur principal de Kwin était réticent sur ce sujet à un moment, je crois. On peut lire des trucs là dessus ici : https://blog.martin-graesslin.com/blog/2016/07/synchronizing-the-x11-and-wayland-clipboard/

Ça fait plusieurs années que le HiDPI existe, pourquoi on a encore ces problèmes ?

Car c'est un exercice plutôt compliqué.

Oui, j'ai cru comprendre. Ça oblige à ne pas simplement faire un ×1,5, mais plutôt un × 3 / 2 ou des choses comme ça. Et on se retrouve avec des fractions de pixels. Dans tous les cas, le compositeur ne peut pas donner une image complètement net. Un jour, je me suis retrouvé devant un Mac Retina, et l'affichage ne m'avait pas paru complètement net. C'était peut-être pour ça. Ou alors un mauvais réglage. À vrai dire je ne sais plus bien.

Mais si j'ai pris un écran HiDPI, c'est justement pour que tout soit net.

Ce qui serait sympa, ce serait d'avoir un truc qui ressemble au zoom des navigateur. Aussi, Android semble bien s'en sortir sur ces questions là. Il doit y avoir une solution élégante à ce problème, au moins pour les applications libres maintenues aujourd'hui.