raphj a écrit 1446 commentaires

Exact, cette parenthèse ne s'applique qu'à l'efficacité, et le principe est traité dans le paragraphe qui suit, c'est vrai que ce n'était pas terriblement claire et merci pour la clarification. Je traite ton premier point explicitement, et ton deuxième point de façon implicite, mais tu les as exprimé bien mieux que moi.

Je ne suis pas d'accord avec le parallèle avec les armes à feu. Les DRM sont une « solution » technique, pas une solution légale. La solution légale est déjà en place d'ailleurs, avec les droits d'auteurs et les droits voisins.

Ici, la loi s'en mêle quand même en interdisant la rétro-ingénierie sur les solutions de protection de contenus couverts par les droits d'auteurs… (parfois, sauf pour des raisons d'interopérabilité). Cf discussions sur la loi DADVSI.

Aussi, pure spéculation, il se peut qu'il y ait un accord de non divulgation [entre Google et le chercheur qui a découvert le problème] tant que Widevine L3 est utilisé, donc pas sûr qu'on voit les détails tant que ce serait utile.

Je pense surtout que Widevine L3 va être remplacé rapidement par un nouveau DRM. Un composant logiciel utilisé dans les navigateurs constamment mis à jour, c'est certainement relativement aisé. Je ne serais pas étonné que Google ou un concurrent soit en train de travailler sur une nouvelle génération de DRM pour remplacer Widevine L3 en ce moment même. Finalement, c'est probablement plus ou moins un non-évènement. Tout au plus, une petite piqûre de rappel sur le fait que dépendre de la sécurité par l'obscurité est risqué.

Cracker Widevine L1 est probablement un processus plus impliqué. Peut-être en extrayant une clef privée dans le matériel des téléphones Android compatibles, ce qui nécessite peut-être de craquer la sécurité de la TrustZone, la fameuse puce "de confiance" embarquée dans la plupart des SoC ARM utilisées dans les téléphones Android, qui sert aussi à gérer la sécurité du chiffrement utilisé pour le stockage des données personnelles.

Ou cracker d'autres matériels prenant en charge Widevine L1.

Et là, ce serait certainement un peu la merde pour les boîtes qui l'utilisent parce qu'un remplacement de Widevine L1 pourrait nécessiter un remplacement des téléphones et du matériel des personnes utilisant leurs services, ou au grand minimum une mise à jour du système (et on sait comment les mises à jour sont gérées sur la plupart des téléphones Android : c'est à dire pas du tout, et ne parlons pas des télés connectées… parce qu'en fait, je n'en sais foutre rien).

(Avertissement : je n'y connais pas grand chose, je dis peut-être des bêtises.)

Merci pour ces suggestions, je vais considérer l'utilisation :-)
Il se trouve que j'étais déjà tombé sur Qobus puisque le lien s'affichait violet, je ne sais pas pourquoi je n'ai pas remarqué la possibilité d'acheter des pistes à l'unité en haute qualité sans DRM.

Une manière de faire pourrait être découverte sur YouTube (NewPipe est une application excellente pour y accéder sur Android, une telle application pour les ordinateurs classiques serait utile), recherche sur Bandcamp puis, sinon, sur Qobuz.

Le drap de la tromperie.

Clairement, si mon disque dur qui contient les instantanés tombe en panne, je perd l'historique. Il me reste, sur la même machine, la sauvegarde du serveur.

Si jamais il y a un problème sur la machine et que je perds tout, j'ai toujours le serveur que je peux re-sauvegarder.

Si, pas de bol, mon serveur virtuel tombe en panne au même moment (ça devient improbable, mais bon, pourquoi pas, une erreur spectaculaire impliquant SSH touchant les deux machines n'est pas impossible), je perds la configuration du serveur et ça sera beaucoup plus long à tout reconstruire. Je perds aussi les courriels qui n'ont pas été stockés par Thunderbird.

À savoir aussi qu'en réalité, mes instantanées sont en lecture seule, donc c'est monté, mais intouchable même par root, sauf à faire du dd sur le périphérique.

Mes données importantes sont encore sur mon ordi et, sur d'autres machines sur lesquelles mon client NextCloud est installé, potentiellement dans une version un peu plus ancienne.

Globalement, je trouve que les risques de perdre mes données actuelles sont très limités.

Ce que je peux améliorer :

• télécharger régulièrement une copie de mes mails / de la conf du serveur sur mon ordinateur. Je vais peut-être le faire d'ailleurs.
• acheter un nouveau disque dur externe sur lequel je sauvegarde aussi le serveur.

Au lieu d'avoir trois copies dont deux sont sur la même machine, ça permettrait d'avoir 4 ou 5 copies dont 2 sur le même ordinateur.

De là à dire qu'il ne s'agit pas d'une sauvegarde, il y a un pas. Le mécanisme fait partie d'un ensemble plus grand, à lui seul il ne suffit pas je suis d'accord. Petit rappel aussi : je suis un particulier, je ne gère pas les sauvegardes d'une entreprise.

J'ai déjà une belle interface pour la restauration d'un fichier spécifique :

cd /mnt/sauvegardes/@date/chemin…/
get fichier

Qu'est-ce que la base de donnée ajouterait ?

En ce qui concerne le fait de ne pas oublier la restauration, oui c'est très important, cf mon commentaire précédent.

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.