raphj a écrit 1745 commentaires

Je lance rsync du serveur vers un sous-volume btrfs, et j'en fait un instantané lecture seule avec la date dans son nom.

Ça fait une sauvegarde incrementale et complète. J'ai l'état complet du stockage pour chaque jour, mais ça ne prend pas la place de la somme des états de chaque jour grâce au fonctionnement des instantanés btrfs. Si seuls quelques mégas on changé sur le serveur depuis la dernière sauvegarde, l'instantané ne prend effectivement que quelques mégas sur le disque de sauvegarde. Mais, à l'utilisation, c'est aussi pratique qu'une sauvegarde complète. Ça permet de faire de très nombreuses sauvegardes pas chères et ultra rapidement.

Seul un FS avec ce genre de fonctionnalités permet ça. C'est un de leurs intérêts. Il y a aussi la compression pour gagner encore de la place, et les vérifications de sommes de contrôle pour l'intégrité des données.

J'utilise beaucoup Btrfs, notamment pour la fonctionnalité de sous-volumes (et donc de Copy-on-Write) pour faire des sauvegardes incrémentales utilisables comme des sauvegardes complète.

Je m'attendais à ce que Btrfs soit plus lent qu'ext4 et autres FS sans CoW, mais pas autant. Je vois bien que l'objectif était de comparer l'état des FS sans ajustements, mais ce serait intéressant de savoir ce qu'il en est quand on active la compression et qu'on utilise noatime, c'est comme ça que je l'utilise, et j'utilise aussi noatime sur ext4. Je n'ai jamais eu besoin du dernier temps d'accès, et ça a l'air de faire beaucoup d'écritures inutiles, ça fait même peur pour la longévité des SSD (mais ce n'est peut-être plus un problème aujourd'hui ?).

Cela dit, mes serveurs sont sous ext4, seule la partie sauvegarde est en Btrfs. Donc les perfs ne sont pas critiques, par contre ext4 ne répondrait pas à mon besoin. Sur l'ordinateur portable, j'utilise Btrfs (pour la compression, et la possibilité de faire des sous volumes pour expérimenter et jeter), donc là, plus de perf serait sympathique :-)

Pour mes utilisations, ZFS serait une alternative sérieuse, donc une comparaison avec lui serait aussi intéressante. Cela dit, il faudrait vraiment un avantage écrasant que je pour m'embête avec ça, vu que ce n'est pas installé de base. On pourrait penser à la fiabilité, mais en pratique je n'ai pas eu trop de soucis avec Btrfs jusqu'à présent et je ne sais pas ce qu'il en est de la fiabilité de ZFS on Linux non plus.

En tout cas faut que je suive BcacheFS un peu sérieusement, ça a l'air intéressant, y compris comme alternative à Btrfs.

Debianeux dans l’âme, j’avais jusqu’à il y a peu opté pour Mobian sur le PinePhone. Je me disais qu’avec Debian, j’étais certain d’avoir tout ce qu’il faut dans les dépôts. J’avais aussi peur de l’aspect différente libc (PostmarketOS, basée sur Alpine, utilise Musl, et pas la glibc).

Mais Plasma Mobile n’est pas dans un état très utilisable sur Mobian, et je voulais l’utiliser, surtout dans sa version 6.

J’ai fini par essayer PostmarketOS. J’ai donc découvert Alpine par la même occasion.

C’est top :

• pmbootstrap, pour construire des paquets ou des images installable avec les paramètres que l’on souhaite, est un superbe outil. Il peut être utilisé sur la machine sous PostmarketOS, ou sur n’importe quel ordinateur faisant tourner n’importe quelle distribution Linux répandue, permet de cross-compiler, et aussi de faire du développement en lançant des choses dans qemu.
• tout semble léger : j’ai l’impression qu’on peut installer un tas de chose et ça prend moins de place / c’est plus léger
• on a des paquets très à jour, y compris pour Plasma 6 pour lequel il y a un mainteneur qui fournit des quasi nightlies
• il y a une prise en charge plus ou moins poussée de beaucoup d’environnement de bureaux
• leur récapitulatif par appareil (tablette, téléphone) donne une bonne vue sur le bon fonctionnement du matériel avec PostmarketOS, et, presque par extension, une prédiction raisonnable pour les autres distributions (peut-être dans le futur)
• il y a une forte volonté de garder une base libre aussi pure que possible, point que j’aime bien aussi chez Debian
• tout semble marcher mieux : vidéos plus fluides, son par Bluetooth plus stable, Plasma Mobile est effectivement utilisable alors que ça n’arrête pas de crasher sur Mobian, etc
• il y a un écran d’accueil lors du premier démarrage sur Plasma 6, et ça donne l’impression qu’il y a un peu de peaufinage. Mais peut-être que c’est un truc Plasma Mobile plus que PostmarketOS. Cela dit, j’ai bien l’impression qu’il y a une belle intersection ici : les gens qui travaillent sur Plasma Mobile sont probablement beaucoup sous PostmarketOS.
• j’ai été étonné à quel point Musl n’est pas une source d’ennui. J’avais supposé que comme tout est développé et testé sous glibc, il y aurait des petits soucis à droite à gauche, mais non, apparemment pas. J’imagine qu’il y a déjà eu beaucoup de correctifs partout pour ça et que maintenant, ça marche tout simplement bien.

Dans les défauts, je noterais que :

• il peut manquer certaines petites choses par défaut. Par exemple, je n’avais pas de connectivité internet par Bluetooth (PAN), ce qui ne m’était jamais arrivé jusqu’à maintenant. En fait, c’est juste que le module Bluetooth de Network Manager n’était pas installé. c’est quelques Kio, ça pourrait venir par défaut quand on installe network-manager ou Plasma 6. J’ai mis un certain temps à comprendre parce que la documentation prétendait que ça pouvait marcher, mais que ce n’était pas activé par défaut dans la stack Bluetooth de la distribution. En fait, ça l’était, donc j’ai creusé une mauvaise piste pendant un petit moment. J’ai bien sûr corrigé la doc.
• vu que c’est basé sur Alpine, le système de boot est OpenRC, et perso, je préfère largement systemd. Ça démarre plus vite, c’est robuste, et je sais l’utiliser. Je ne vois pas d’avantage clair à OpenRC, que des inconvénients, sinon ce dernier point serait moins pertinent, je n’ai pas trop de soucis à apprendre à utiliser un nouvel outil s’il est mieux. Mais ce problème va disparaitre, parce que l’équipe de PostmarketOS semble d’accord avec moi. Ils sont en train de passer à systemd, déviant plus fortement d’Alpine, alors qu’en général, ils préfèrent être le plus proche d’Alpine et remonter le plus de choses possible.

J’ai aussi découvert qu’Alpine fonctionne aussi très bien comme distribution de bureau. Je l’ai essayée sur une vieille tablette Intel (sur laquelle il vaut mieux installer une distribution x86 32 bits, donc ça limite les choix – en particulier pas de postmarketOS pour cette raison), ça marchait bien, sauf un bug d’affichage très bloquant. J’ai donc basculé sur openSUSE Tumbleweed. Même bug bloquant finalement, probablement lié à une mauvaise interaction avec le pilote graphique et QML, mais donc ce n’était pas un bug d’Alpine finalement.

Ça donne envie de pouvoir utiliser PostmarketOS sur bureau, étant une Alpine bientôt basée sur systemd avec un pmbootstrap super pratique, permettant de faire du développement sur les paquets de la distribution très facilement. Et même si le but n’est pas de packager, pour travailler n’importe quel logiciel un peu répandu, il y a probablement un paquet qui permet de télécharger les sources, les dépendances, et de compiler les modifications ultra-facilement, et sinon le format des paquets est méga simple. Les paquets Alpine semblent aussi très « vanilla », il n’y a pas l’air d’avoir beaucoup de patchs appliqués par la distribution. Non pas que je trouve que ce soit une mauvaise chose, c’est cool que la distribution fasse de l’intégration, mais ça peut simplifier le développement et le débogage.

Bon, pour finir, le PinePhone, ça reste lent, et le PinePhone Pro n'a pas encore une très bonne gestion de la batterie. Globalement, les deux appareils avec les distributions actuelles ne me paraissent pas encore assez fiables et autonomes (niveau batterie) pour être utilisés au quotidien et pour qu'on puisse compter dessus en cas d'urgence. Côté téléphonie, le son était catastrophique surtout côté correspondant quand j'avais testé. J'attends un peu avec impatience un matériel fiable pour faire tourner du Linux mobile dessus, sans blobs propriétaires devant tourner sur le CPU principal.

“It's going to be nearly undetectable and nearly unpatchable.” Only opening a computer's case, physically connecting directly to a certain portion of its memory chips with a hardware-based programming tool known as SPI Flash programmer and meticulously scouring the memory would allow the malware to be removed, Okupski says.

C'est difficile à détecter, d'accord, mais est-ce qu'il ne suffit pas de reflasher la SPI complètement ne suffirait pas à s'en débarrasser ?

Bien sûr, il faut déjà pouvoir flasher la SPI, ce qui n'est malheureusement pas viable dans beaucoup de situations (ça demande souvent des outils spécifiques, souvent d'ouvrir l'ordinateur, etc - et le faire depuis l'OS, si c'est possible, ne serait pas fiable puisqu'un bootkit suffisamment élaboré pourrait faire mentir le processus de flashing si je comprends bien - et si on n'est pas spécialiste qui a les bons outils, il faut déjà avoir entendu parler de la faille et en avoir assez quelque chose à faire pour aller trouver et payer quelqu'un pour le faire - si tant est qu'on a le bon binaire à flasher à disposition).

Tout ça laisse penser que tous ces mécanismes qui permettent de flasher des choses dans le matériel sont des portes ouvertes à ce genre de vulnérabilité - y compris des mécanismes comme Secure Boot, qui par construction demandent de pouvoir enregistrer des données, et qui donc sont susceptibles d'apporter des vulnérabilités alors qu'ils sont là pour le contraire…

For systems with certain faulty configurations in how a computer maker implemented AMD's security feature known as Platform Secure Boot—which the researchers warn encompasses the large majority of the systems they tested—a malware infection installed via Sinkclose could be harder yet to detect or remediate, they say, surviving even a reinstallation of the operating system

C'est quand même con, une fonctionnalité là pour la sécurité qui réduit la sécurité. Je comprends bien que le problème se situe lors de l'intégration de cette fonctionnalité, mais quand-même.

devnewton, jamais décevant ! :-)

"Tu sais où tu peux te la mettre, ton application de merde ‽" prend tout son sens.

Mais ça ne posera problème que pour les gens qui ont acheté à un endroit non officiel, ou qui ont vendu leur ticket, donc finalement ça m'a tout l'air de marcher comme prévu finalement.

Il n'y aura jamais de problème pour quelqu'un qui a acheté son billet normalement.

Même le cas où quelqu'un se fait voler discrètement son ticket peut être géré : la personne pourrait montrer la transaction d'achat avec le site officiel.

Tu devrais savoir qu'il ne faut pas acheter un premier billet n'importe où. Après oui, il y a toujours le phishing, mais de toute façon l'achat se fait sans l'application d'après le journal, donc l'application ne gère même pas ça sauf si j'ai loupé quelque chose.

Une application n'est pas nécessaire pour ça. Par exemple, les billets de la SNCF sont nominatifs, impossible donc de les revendre, et pourtant il n'y a pas d'application nécessaire.

L'article met sur le même plan OSM, OSMAnd et OrganicMaps, alors que ces deux dernières sont des applications mobiles basées sur la première (qui n'est pas une application, mais une base de données cartographiques).

L'article affirme qu'on privilégiera OSMAnd pour la navigation sans expliquer qui est "on" ni pourquoi, et affirme qu'on peut utiliser les données de Wikipedia, mais c'est aussi vrai pour Organic Maps.

De même, l'article affirme qu'il y a les sentiers de randonnée sur OrganicMaps, mais c'est vrai aussi sur OSMAnd, et les deux souffrent du même problème en France de l'absence des GR sur OSM, parce que la Fédération française de randonnée pédestre interdit leur réutilisation, c'est pourtant un point important à soulever (et qui mériterait probablement plus de publicité, ce qui permettrait peut-être de résoudre le problème un jour).

OSMAnd et OrganicMaps sont deux excellentes applications un peu complémentaires (caricaturalement : OSMAnd est plus complet, OrganicMaps est plus léger et beaucoup plus simple d'utilisation) qui mériterait une description plus approfondit, il suffirait de passer 5 minutes de plus pour avoir des choses plus intéressantes et exactes à dire. 5 autres minutes auraient permis une introduction bien plus utile et complète d'OSM, qui mérite plus qu'un petit paragraphe tout moisi.

Avec un tel niveau de vulgarisation, l'article arrive quand même à utiliser le mot fork sans expliquer ce que c'est, donc il loupe sa cible.

Allez, on va finir sur deux points plus positifs :

• L'article a le mérite de souligner que Waze appartient à Google
• et de faire voir aux gens qu'il y a d'autres choses que Apple et Google en matière de carte, et d'introduire OSM

Beaucoup de gens ne savent pas ces choses.

Ouais, ok, je vais essayer de faire ça ! Merci pour la suggestion. Et ça « règlera » le bug.

Je ne vois pas comment indiquer efficacement les corrections à apporter au commentaire sans devoir reposter entièrement le bon contenu de toute façon. L'espace de rédaction ne permet que d'envoyer des petits messages sur une ligne, ce n'est pas adapté.

J'ai un palliatif en place, à base de cron qui lance des requêtes régulièrement, mais ce n'est pas totalement fiable :

• Dès qu'on redémarre manuellement nginx après un changement de config, c'est niqué. Peut-être qu'on peut déclencher des actions avec systemd après le redémarrage d'un service. À creuser ! Ou pas, si ça disparait bientôt…

• Pour faire proprement, il faudrait certainement garder trace de l'expiration de l'agrafe et faire la requête au bon moment juste après l'expiration et espérer qu'aucune requête ne s'est glissée entre temps. Le problème, c'est que l'agrafe n'est mise à jour que quand elle est expirée, donc tu as beau faire des requêtes souvent, ça va quand même échouer entre l'expiration et la prochaine requête… si elle arrive assez tôt.

• l'alternative imparfaite, c'est de bourriner et lancer des requêtes vraiment très souvent à intervalle très court et quand-même espérer que des requêtes n'arrivent pas au bon moment.

Concernant le bug nginx, si j'ai bien compris, les dev nginx considèrent que la perf est plus importante et que cette requête à faire avant de répondre, c'est pénible, et apparemment ça demande une réarchitecture majeur, ou en tout cas beaucoup de boulot, donc c'est pas sûr qu'on voit le bug corrigé de sitôt. Ça fait déjà des années que les gens se plaignent.

Peut-être que quelqu'un pourrait fournir un patch, mais il faudrait déjà que les devs d'nginx soient convaincus que c'est une bonne idée.

Et au final, si ça disparait bientôt au profit d'une « meilleure » solution, peut-être autant pas trop s'embêter…

Gros bug d'édition, j'ai dupliqué des paragraphes… si l'équipe de modération veut bien corriger ça ce serait le top. Désolé pour le loupé.

Ah, c'est ballot 😅

D'abord, un petit résumé (edit: wou pinaise, pas si petit, déso) pour celles et ceux qui ne seraient pas familier avec le concept dont il est question, perso je n'en aurais jamais entendu parlé si je n'administrais pas moi même des site web donc je pense que ça peut être utile.

Pour sécuriser les connexions avec HTTPS, il faut un certificat qui dit "c'est bon, ce site web est bien servi par serveur vérifié, et la page n'a pas été modifié". Ce certificat est délivré par une autorité dont le navigateur (ou plus généralement le client HTTPS) fait confiance, et Let's Encrypt est l'une d'elle. C'est même la plus grosse aujourd'hui en termes de sites couverts.

Mais les certificats peuvent être révoqués, par exemple parce qu'ils ont été compromis. OCSP permet de vérifier qu'un certificat n'a pas été révoqué. Pour cela, le navigateur peut aller interroger une URL au moment de la première visite d'un site web depuis un certain temps pour aller voir si c'est le cas.

Problèmes :

• Ça demande une infrastructure coûteuse chez l'autorité de confiance, qui doit répondre à beaucoup de requêtes et doit avoir un uptime en béton.
  • que se passe-t-il si cette infra tombe ? On laisse passer ou on casse le site ?
• ça pose des questions de vie privée : l'autorité de confiance sait alors que telle personne a visité tel site. Elle n'a pas besoin de garder de logs (et Let's Encrypt s'efforce de ne pas garder les traces), mais elle est toujours susceptible d'être interrogée par des services de renseignements, et toutes les autorités ne sont pas aussi tatillonnes sur la protection de la vie privée, et même, on ne devrait pas avoir besoin de faire confiance à une autorité pour ça.

C'est pour ces raisons que Let's Encrypt veut se débarrasser d'OCSP.

En plus :

• ça ralentit cette première visite
• En pratique, parmi les navigateurs répandus, seul Firefox fait cette vérification

Il y a des parades :

• l'option Must Staple lors de la demande d'un certificat, qui bloque ce mécanisme de demande à l'infrastructure OCSP au niveau du navigateur. Le serveur web doit alors lui faire la requête, et fournir "l'agrafe" - la preuve que le certificat n'a pas D’abord, un petit résumé pour celles et ceux qui ne seraient pas familiers avec le concept dont il est question, perso je n’en aurais probablement jamais entendu parler si je n’administrais pas moi-même des sites web, donc je pense que ça peut être utile.

Pour sécuriser les connexions avec HTTPS, il faut un certificat qui dit « c’est bon, ce site web est bien servi par serveur vérifié, et la page n’a pas été modifié ». Ce certificat est délivré par une autorité en laquelle le navigateur (ou plus généralement le client HTTPS) fait confiance, et Let's Encrypt est l’une d’elles. C’est même la plus grosse aujourd’hui en termes de sites couverts.

Mais les certificats peuvent être révoqués, par exemple parce qu’ils ont été compromis. OCSP permet de vérifier qu’un certificat n’a pas été révoqué. Pour cela, le navigateur peut aller interroger une URL au moment de la première visite d’un site web depuis un certain temps pour aller voir si c’est le cas.

Problèmes :

• Ça demande une infrastructure coûteuse chez l’autorité de confiance, qui doit répondre à beaucoup de requêtes et doit avoir un uptime en béton.
  • Eh oui, que se passe-t-il si cette infra tombe / que des requêtes OCSP échouent ? On laisse passer ou on casse le site avec un avertissement inquiétant ou obscure à l’utilisateur ?
• ça pose des questions de vie privée : l’autorité de confiance sait alors que telle personne a visité tel site. Elle n’a pas besoin de garder de logs (et Let's Encrypt s’efforce de ne pas garder les traces), mais elle est toujours susceptible d’être interrogée par des services de renseignements, et toutes les autorités ne sont pas aussi tatillonnes sur la protection de la vie privée, et même, on ne devrait pas avoir besoin de faire confiance à une autorité pour ça.

C’est pour ces raisons que Let's Encrypt veut se débarrasser d’OCSP.

En plus :

• ça ralentit cette première visite, puisqu’il faut attendre que cette requête OCSP termine avant d'afficher le site
• En pratique, parmi les navigateurs répandus, seul Firefox fait cette vérification

Il y a des parades :

• l’option Must Staple lors de la demande d’un certificat, qui bloque ce mécanisme de demande à l’infrastructure OCSP au niveau du navigateur. Le serveur web doit alors lui faire la requête, et fournir « l’agrafe » - la preuve que le certificat n’a pas été révoqué très récemment - au navigateur.
  • en pratique, les serveurs répandus n’implémentent pas bien ce mécanisme. Notamment, Nginx ne fait la demande OCSP qu’après la première requête vers un site après son démarrage (ou après l’expiration des données OCSP), et cette requête part alors sans l’agrafe, ce qui fait échouer la vérification. Apache 2 n’est pas meilleur.
• CRL et CRLite, un mécanisme proposé par Mozilla où les navigateurs téléchargent la liste des certificats révoqués à intervalle régulier (4 fois par jour par exemple), avec des techniques de compression et de mises à jour incrémentales de fou pour que ça soit réalisable. Plus besoin alors d’OCSP si le navigateur sait déjà quel certificat est révoqué. Mais ce n’est pas encore en place.
• un temps de renouvellement très court des certificats. Si ton certificat a une durée de validité de 7 jours ou moins, finalement il y a beaucoup moins besoin de le révoquer. Mais ce n’est pas encore très répandu.

Actuellement, la situation n’est pas très rose :

• SSL Labs, qui fournit un diagnostic pour évaluer la qualité de la sécurisation de son site pousse à mettre en place Must Staple pour avoir un score parfait
• En théorie, c’est une bonne chose, parce que ça respecte mieux la vie privée des utilisateurs et c’est mieux au niveau des performances et de l’utilisation des ressources communes (chaque client n’a pas à faire sa requête OCSP, le serveur le fait pour tout le monde)
• En pratique, c’est tout moisi parce que ça ne marche pas bien : sa prise en charge par les serveurs est affreuse, les navigateurs sauf Firefox s’en tapent…

L’article dit que les gens qui hébergent des sites web ne sont pas concernés par ce changement, mais ce n’est pas tout à fait vrai : on ne sait pas encore comment cette option « Must Staple » sera gérée, et les solutions envisagées ont des inconvénients :

1. l’option pourrait être simplement ignorée. Le certificat sera créé, ça va continuer à marcher, juste qu’il n’y aura plus Must Staple ». Ça veut dire que si le système dépendait de ce mécanisme, ça va casser, et ça peut casser silencieusement. Mais au moins, la livraison des certificats va continuer à fonctionner sans changement partout où ça n’importe pas tellement.
2. l’option pourrait causer un échec de certificat. Dans ce cas, ce sera clair ce qu’il se passe, par contre ça va obliger plein de gens à déboguer et mettre à jour une configuration qui vivait toute seule depuis potentiellement longtemps.

De mon côté, je ne sais pas ce que je préférerais. Peut-être que les navigateurs adoptent un truc comme CRL, ou que les certificats aient encore une durée de validité plus courte, pour rendre OCSP et Must-Staple inutiles.

Ce qui est sûr, c’est que ça résoudra mes problèmes de gestion cassée de Must-Staple par Nginx sans devoir me poser la question de si je dois désactiver ça. Peut-être que SSL Labs mettra aussi à jour son diagnostic pour arrêter de pousser cette option. Au moins, si elle ne fonctionne plus, la question ne se pose plus. Donc je suis un peu pressé que ça arrive.
été révoqué très récemment - au navigateur.
- en pratique, les serveurs répandus n'implémentent pas bien ce mécanisme. Notamment, Nginx ne fait la demande OCSP qu'après la première requête vers un site après son démarrage (ou après l'expiration des données OCSP), et cette requête part alors sans l'agrafe, ce qui fait échouer la vérification. Apache 2 n'est pas meilleur.
- CRL et CRLite, un mécanisme proposé par Mozilla où les navigateurs téléchargent la liste des certificats révoqué à intervalle régulier (4 fois par jour par exemple), avec des techniques de compression et de mises à jour incrémentales de fou pour que ça soit réalisable. Plus besoin alors d'OCSP si le navigateur sait déjà quel certificat est révoqué. Mais ce n'est pas encore en place.
- un temps de renouvellement très court des certificats. Si ton certificat a une durée de validité de 7 jours ou moins, finalement il y a beaucoup moins besoin de le révoquer. Mais ce n'est pas encore très répandu.

Actuellement, la situation n'est pas très rose :

• SSL Labs, qui fournit un diagnostic pour évaluer la qualité de la sécurisation de son site pousse à mettre en place Must Staple pour avoir un score parfait
• En théorie, c'est une bonne chose, parce que ça respecte mieux la vie privée des utilisateurs et c'est mieux au niveau des performances et de l'utilisation des ressources communes (chaque client n'a pas à faire sa requête OCSP, le serveur le fait pour tout le monde)
• En pratique, c'est tout moisi parce que ça ne marche pas bien : sa prise en charge par les serveurs est affreuse, les navigateurs sauf Firefox s'en tapent…

L'article dit que les gens qui hébergent des sites web ne sont pas concernés par ce changement, mais ce n'est pas tout à fait vrai : on ne sait pas encore comment cette option "Must Staple" sera gérée, et les solutions envisagées ont des inconvénients :

1. l'option pourrait être simplement ignorée. Le certificat sera créé, ça va continuer à marcher, juste qu'il n'y aura plus Must Staple". Ça veut dire que si le système dépendait de ce mécanisme, ça va casser, et ça peut casser silencieusement. Mais au moins, la livraison des certificats va continuer à fonctionner sans changement partout où ça n'importe pas tellement.
2. l'option pourrait causer un échec de certificat. Dans ce cas, ce sera clair ce qu'il se passe, par contre ça va obliger plein de gens à déboguer et mettre à jour une configuration qui vivait toute seule depuis potentiellement longtemps.

De mon côté, je ne sais pas ce que je préférerais. Peut-être que les navigateurs adoptent un truc comme CRL, ou que les certificats aient encore une durée de validité plus courte, pour rendre OCSP et Must-Staple inutiles.

Ce qui est sûr, c'est que ça résoudra mes problèmes de gestion cassée de Must-Staple par Nginx sans devoir me poser la question de si je dois désactiver ça. Peut-être que SSL Labs mettra aussi à jour son diagnostic pour arrêter de pousser cette option. Au moins, si elle ne fonctionne plus, la question ne se pose plus. Donc je suis un peu pressé que ça arrive.

Si vous avez peut être de bonnes raisons d'imposer l'installation d'une application tierce sur mon appareil personnel

Félicitations pour la formulation humble et prudente.

Je pense moi qu'il n'y a pas de bonnes raisons de supposer que quelqu'un qui va voir des JO a nécessairement un smartphone, Android ou Apple qui plus est, et en tout cas d'obliger l'installation d'une application.

Générer un QR Code contenant les informations de réservation signées à l'aide d'une clé privée qui garantie que le billet n'est pas trafiqué, qu'on peut montrer avec n'importe quel appareil et même imprimer, c'est facile. En tout cas plus simple que de coder une application cliente pour deux OS et tout le backend derrière.

La SNCF génère des PDF avec des QR Code pour les trains, ça marche très bien.

Ensuite, il n'y a pas de bonne raison pour que l'application ne soit pas libre. Ça m'importerait plus que la disponibilité sur tel ou tel magasin d'application. Même si :

• c'est bien de se battre contre le monopole du Play Store.

• c'est bien de passer un magasin d'application avec lequel on peut interagir avec un client libre (je découvre l'existence d'Aptoide, et son caractère client libre - c'est la base d'F-Droid) (à noter quand même l'existence de clients libres pour le Play Store qui permettent de se passer de compte Google, même si ce n'est pas très approuvé par Google)

Petite note de fin :

en utilisant Aptoide - La boutique alternative d'applications Android

Ce "La" me chagrine un peu. Elle n'est pas la seule, et d'ailleurs je ne la connaissais pas, et si l'application était libre, tant qu'à faire ce serait pas mal qu'elle soit sur F-Droid.

La question est là pour savoir sur quelle version de l'application le feedback s'applique. Quand on utilise Lineage, il faut choisir Android sans aucun doute. Il n'y a aucun doute sur le fait que Lineage est une distribution basée sur Android et que pour Lineage, c'est l'application Android qui te concerne. Ensuite, rien n'empêche de préciser plus loin.

Du coup, si tu refais la démarche, si tu peux aussi réclamer la libération de l'application, ça pourrait être cool. D'autres institutions française s'y mettent, comme IGN, ce n'est plus un truc de geek qui plane à 2000.

PipeWire semble fonctionner beaucoup mieux que PulseAudio.

Sur le PinePhone original, la différence, c'est un son en Bluetooth saccadé avec déconnexions en permanence rendant l'ensemble inutilisable. Avec Pipewire, tout fonctionne. Saccades occasionnelles.

Ce n'est pas aussi violant sur ordinateur classique, mais je me dis que ça doit être moins gourmand et plus stable.

Je suppose que PipeWire a été conçu avec la connaissance et l'expérience accumulée avec PulseAudio et, en à l'esprit, le besoin de gérer aussi les flux vidéos. Le remplacement est drop-in ou quasi, les APIs fonctionnent telles quelles et le niveau de compatibilité m'impressionne. Globalement, les trucs dépendant de PulseAudio n'ont rien eu à faire. Le remplacement a l'air plutôt transparent pour l'utilisateur, et a été effectué dans les distributions au moment où ça fonctionnait bien. Ça me parait sain comme démarche. J'ai l'impression que c'est une bonne manière de remplacer une brique technique, pour les bonnes raisons, au bon moment.

Comme tous cela : https://sourceware.org/bugzilla/buglist.cgi?query_format=specific&order=Importance&no_redirect=0&bug_status=__open__&product=glibc&content=

Et donc ?

Parfois c'est (c'était ?) même mensonger : "Garanti sans virus".

C'est sûr qu'ils n'allaient pas formuler "Notre antivirus a été incapable de trouver un virus dans ce courriel", pourtant ça aurait plus techniquement correct.

Dans le genre, il y a aussi les "Envoyé depuis mon [modèle]".

Je déteste ces bouts de pub.

Oui, la plupart en ont, mais est-ce par choix de conception ou alors des lois comme celles-là l'obligeant existaient déjà ?

Et puis, faut voir la complexité d'un limitateur qui doit connaitre la limitation actuelle, ce n'est pas la même qu'un limitateur ou un régulateur que la personne qui conduit règle à la vitesse limite souhaitée. Ceux-là requièrent certainement un ordinateur de bord, mais probablement beaucoup plus rudimentaire, la fonctionnalité est beaucoup plus simple / moins complexe, avec peut-être moins de risque de bugs.

Globalement, ça oblige les voiture à avoir un ordinateur de bord, n'est-ce pas ?

J'ai appris hier que c'était de la propagande pour redorer son image.

… bon, ils auraient eu tort de ne pas essayer, j'imagine…

J'imagine qu'en se passant de viande à long terme, on se désaccoutume du cinquième goût, l'umami.

Nope. Une alimentation végétarienne est facilement riche en umami. Il y en a par exemple dans les chips, la sauce soja, la sauce tomate, l'ognon, le miso, les champignons. J'apprends aussi qu'il y en a aussi dans les petits pois, les fèves, le celeri.

Et globalement les trucs fermentés.

Il n'y a aucun risque de manquer de protéine, au contraire, on en consomme beaucoup trop !

On en mange beaucoup de trop, c'est absolument certain mais en manquer n'est pas bon non plus

Globalement, la protéine, c'est un faux problème. Elle ne manque dans aucun régime varié, même végétalien. Il y a plein d'ingrédients à base de plantes riches en protéines. C'est même difficile d'en manquer, je suppose qu'il faut se limiter aux fruits et légumes ou un truc dans le genre, ou manger toujours la même chose non diversifiée qui fait que tu n'as pas tous les acides aminés qu'il faut. Il faut vraiment avoir un régime tout pété, faut presque faire des efforts conscient pour avoir des soucis avec les protéines. Ou avoir des gros troubles de l'assimilation mais là, ce n'est plus purement une question de régime alimentaire, on entre dans le domaine du médical.

L'industrie de la viande nous a bien lavé le cerveau avec ces questions de protéines. "Mais et les protéines, comment tu fais ?" Ben… ça juste marche.

Les gens ne savent pas ce que sont les protéines en fait, et répètent ce qu'ils entendent. Et comme on l'entend partout, bah ça fonctionne. Et comme ça rassure ("ah oui, si j'arrête la viande, je vais manquer de protéine, donc je ne peux pas arrêter la viande. Ouf."), c'est plutôt plaisant comme théorie, donc on ne se bouscule pas pour la vérifier.

Il y avait pourtant des cibles plus efficaces : le fer (un peu moins bien assimilable en version végétale - mais bon, on s'en sort quand même et l'anémie, ça ne concerne pas que les végétariens en réalité), la B12 (absente dans un régime végétalien), quelques autres vitamines où il faut éventuellement faire un peu attention… en variant.

je ne parles pas du veganisme qui a pour principal "but" de réduire l'impact écologique

C'est un des buts possibles, mais je ne dirais pas que c'est le principal.

Un des motivations les plus importantes (la plus importante ?) dans la cause est la cause animale.

Cela dit, je ne sais pas dans quelle mesure ça impacte ta démonstration, j'ai du mal à comprendre comment cette remarque s'insère dans ta démonstration.

Par ailleurs :

malgré tout manger biologique ne fait pas toujours l'unanimité

Dans le cadre de la santé : par qui, pour quelles raisons ? (ici je ne remets pas en cause, juste que ça m'intéresserait d'avoir plus de détails là dessus)

Même manger des fruits et légumes est contesté

Par qui, quelles raisons ? Je pensais que ça faisait consensus. Faut pas abuser du sucre et ne pas manger que des fruits et légumes, sinon ça se passe mal, mais après ?

avec plus de fibres

et moins de sucres rapides

le pain blanc n'est pas toxique pour autant cela dépend de ce que tu manges à côté

Oui, de la même manières que les bonbons et sucreries ne sont pas toxiques, mais ça ne dit pas grand chose.

(évidemment, il y a un bon fossé entre un bonbon 100% sucré et du pain blanc, mais je ne sais pas ce que tu cherches à démontrer)

https://www.youtube.com/watch?v=NzvsUJiQVKA

(c'est une vidéo courte, 17 secondes)

(difficile de résister à partager le texte)