benoar a écrit 4238 commentaires

Petite question au passage, pourquoi trouve‑t‑on si peu de mémoires de masters français (dans la sélection on peut trouver deux masters tunisiens et aucun français par exemple) ?

Parce que ça ne fait pas « sérieux » de citer un site d'amateurs qui font du libre, c'est-à-dire des logiciels donnés gratuitement en plus ? Je fais un peu d'ironie, mais on a beau être une source d'actualité, je pense que ça ne fait pas méga-crédible quand même, même si c'est dommage. Pour les tunisiens, disons qu'ils sont peut-être moins apeurés par le côté artisanal ?

Pourquoi poster un commentaire énervé à 1h du mat' ? (si tu es dans la tz de Paris)

Parce que c'est énervé mais pas méchant ; j'avoue réfléchir à deux fois si c'est méchant, mais si c'est juste du HS je poste.

C'est une I/O ça peut planter tenter de ne gérer que les cas que tu imagine c'est généralement en oublier un énorme paquet. Et en terme de complexité ça n'est pas forcément si incroyable que ça. Du moins ça peut l'être si ton design a était prévu pour.

Il faut gérer tous les cas d'erreur, bien sûr, mais là on parle de latence dans la réponse ; et sur la complexité, j'ai l'impression que vous avez tous des ressentis sur la théorie que devrait être cette gestion, mais vous oubliez que « Worse is better ». En fait, il y a incompréhension sur l'objectif : bien sûr que j'aimerais une GUI qui soit tip-top et ne laggue pas, mais posez-vous la question de pourquoi c'est toujours difficile de résoudre un problème qui a 20 ou 30 ans et n'en finit pas ?

Si non tu pourrais lui expliquer ce que tu es entrain de faire, ce qui plante, lui donner des billes pour savoir si c'est transitoire ou non…

Je sais pas qui sont tes utilisateurs… si c'est transitoire, il faut… attendre, il n'y a rien d'autre à faire (comment pourrais-tu indiquer « ça va arriver dans 1 minute » ? Tu n'es pas devin !), et si c'est permanent, c'est que le feedback est bloqué pour une raison à la con (perte d'état intermédiaire que j'expliquais plus haut), et il faut corriger ça, parce qu'il n'existe pas de super heuristique sur « j'ai pas de feedback depuis X temps donc il faut abandonner » (pour info, dans TCP c'est 30 jours environ et c'est très bien comme ça).

Donc au lieu de faire en sorte que les UI restent réactives donnent des info à leur utilisateurs, il faut qu'ils investiguent eux-même d'où vient ton freeze, qu'ils regardent toutes les I/O de leur machine et potentiellement de leur réseau et corrigent le problème.

Mais si ton appli est capable d'avoir des infos, pourquoi elle freeze ? Quand l'appli freeze, c'est qu'elle est en attente sans en savoir plus. Que veux-tu dire à l'utilisateur qui permettra à lui de changer la situation, quand tu es en attente d'une machine à l'autre bout du réseau ? Mon point de vue c'est de vous demander de pousser la réflexion plus loin que la première étape qui est le feedback visuel, en se demandant ce que ça va changer à l'issue de la tâche qu'est en train d'effectuer l'utilisateur.

Tant pis si tu es sur un wifi publique ou si ta connexion est mauvaise (réseau mobile hors jolies 4 ou 5G ou alors ligne physique mais en défaut sur le moment) ?

Si ta connexion est lente, c'est quoi ton issue ? Attendre ou te barrer. J'ai jamais été contre « se barrer » dans mes commentaires plus haut, si c'est pour définitivement abandonner. Ce qui est un constat d'échec. Et dans l'autre cas, il faut… attendre.

Alors pour le partage réseau, déjà, est-ce que c'est un partage abstrait par le VFS ou alors une API spécifique à Nautilus (ou une lib qu'il utilise spécifiquement) qui lui permet de savoir que c'est un partage réseau ? Dans le premier cas, ça obligerait à complexifier le cas pour tous les accès même locaux, et ça causerait sûrement plein de problèmes de consommation et complexification supplémentaire pour uniquement ce problème particulier. Dans le second, il y a effectivement peut-être des choses à faire, mais il faut essayer de comprendre le besoin : le réseau ajoute intrinsèquement des latences, alors combien de temps il faut attendre avant de dire qu'il est « en carafe » ? Est-ce une erreur transitoire ou permanante (et on démonde le partage) ?

Certes, pouvoir fermer la fenêtre devrait être une option accessible, mais si je peux me permettre le tirage de cheveu, la question de l'informatique a toujours été de cacher les modalités, et là donc la modalité du « je suis dans un dossier du partage réseau », que tu la recrées en fermant la fenêtre et en allant en rouvrir une autre pour aller au même endroit et te reprendre la même erreur… quel intérêt ? « Attendre que ça revienne » peut être une solution également valable ! Ça me fait penser à ceux qui rechargent leurs pages pour régler leur problèmes : TCP a été inventé (dans les années 70 !) pour réessayer à votre place, sans que vous ayez besoin de le faire vous-même ! (vous n'êtes pas des machines ! Bien que les devs prennent souvent leurs utilisateurs pour des automates débiles)

Surtout que si on essaye de remonter à l'origine de ce problème, ça n'est pas le blocage de ton navigateur de fichier (qui n'est qu'un symptôme), mais de mon expérience personnelle c'est très souvent dû à des sessions effacées inutilement, que ça soit niveau firewall, NAT, ou système d'authentification : encore des modalités qui n'ont parfois aucune raison d'être (le NAT et autre état intermédiaire là pour contourner une difficulté technique plus ou moins involontairement créée par l'homme) et qui doivent être résolues par l'utilisateur, en rechargeant, se reloggant, en fermant/rouvrant, en redémarrant, etc ! C'est débile. Corrigeons d'abord ces conneries afin d'avoir un réseau plus fiable, après on aura moins de problème avec les GUI.

Tu vas me dire « oui mais en attendant on pourrait avoir ces workaround dans la GUI », mais si ça fait 20 ans qu'il y a les même problèmes (car ça fait vingt ans que la complexification des réseaux fout la merde) et qu'ils n'ont toujours pas été résolus dans la GUI, c'est peut-être qu'il faut arrêter de chercher des workaround et corriger les problèmes dans le réseau.

Désolé de la digression, mais t'es tombé pile sur un truc qui m'énerve.

Je rêve d'autre chose aussi, aucun accès IO dans le fil d'exécution principal du rendu du shell,

Je ne pense pas que ça apporte du bien : ça ne fait que repousser le problème. Soit tu n'avais pas réellement besoin de cette I/O, dans ce cas il faut corriger le code, soit tu en avais vraiment besoin et tu vas inventer la roulette à la MacOS ou équivalent. Le truc c'est que tu ne géreras jamais tous les cas possibles où t'as besoin d'I/O, car t'auras toujours des I/O abstraites derrières 3 couches à travers 10 appels de fonction que tu ne connais pas. Donc ça bloquera, buguera, ou autre.

De toutes façons, les systèmes qui veulent ainsi cacher les latences sont « mous » dans le sens où en voulant cacher le feedback, on perd tout lien avec le besoin réel de resource (ici en I/O) derrière : ya le même problème sur le Web avec tout le JS qui attend des resources réseau sur une connexion lente, et c'est tout moisi quand tout est (presque) géré par le JS lui-même avec masse d'artifice pour te faire attendre. C'est même un principe « physique » si on peut dire : c'est la base des circuits en boucle fermés, dans lesquels tu rajouterais de la capacité (pour les électroniciens, mettre de la capa ça « résout » magiquement tout les problèmes ; mais en fait ça en ajoute plein d'autres). C'est pareil en réseau avec l'ajout de buffer, en algorithmique en ajoutant des caches (de la mémoire), etc.

La France est bien seule à continuer dans cette voie si je suis bien, et comme cette voie dépend de Google et Apple qui ne veulent pas vraiment…

Ce qui en dit beaucoup sur l'état de notre démocratie aujourd'hui : on n'a aucune autonomie technologique aujourd'hui, et on veut s'amuser avec ces outils…

Ça ne dépend pas du tout de systemd (comme beaucoup des choses) : sous Debian (même sans systemd) on a une bonne disposition dès l'initrd, même en bépo par exemple. En fait, le problème j'ai l'impression ce sont les préférences par défaut : avoir un bon keymap dans l'initrd, systemd n'y peut rien (quoique j'ai vu récemment qu'ils s'y attaquent) mais ça marche sous Debian sans, et redémarrer sans cesse les process c'est tout pourri pour moi et c'est ce que fait systemd mais pas sysv, même si chacun pourrait faire ce que fait l'autre.

Il est désagréable de se faire couper la parole dans des échanges en présentiel, c'est tout autant désagréable en visioconférence ; mais en plus, en visioconférence la situation devient vraiment inextricable, incompréhensible. Il faut de la discipline, de la patience.

Ça, c'est avec à peu près tous les softs de visios, qui bufferisent pas mal pour différentes raisons, et du coup avec un décalage c'est effectivement ingérable de parler à plusieurs en même temps. Jitsi Meet ne fait pas exception.

Par contre on a essayé il y a quelques semaines notre « apéro du libre » avec Mumble, qui est une solution orientée gamer (et audio seulement) et donc très orienté latence faible (perso je n'avais que la latence de mon ADSL, grosso modo 50 ms), et bien on peut s'empoigner virtuellement exactement comme à l'apéro IRL, ça se passe très bien avec cette faible latence !

Bref, ça n'est pas un problème insoluble dans l'absolu, mais c'est vrai que ça demande du gros travail sur l'infra réseau : moins de NAT pourris qui t'obligent à faire des détours, et moins de buffer-bloat. Dire qu'on pourrait avoir de l'instantané en vidéo avec de la fibre si le réseau était bien fait… (et c'est ironique qu'on se tape cette latence de merde en DSL alors qu'ATM avait été prévu pour la latence à la base…)

T'es chiant, tu fais toujours exprès de pas comprendre, c'est pas comme si on avait pas toujours les même conversations : le libre, c'est être maître de sa machine, avoir le contrôle de son informatique. Ainsi, en contrôlant les programmes, on protège sa vie privée, qui est je le rappelle un droit fondamental défendu par la Déclaration Universelle des Droits de l'Homme. Bien sûr, tout le combat est sur les nuances de ce qui respecte exactement ta vie privée, mais je n'ai pas encore vu de discussion là-dessus ici. Le moyen d'y arriver par les logiciels est de respecter les quatre libertés. Ces quatre libertés sont un moyen d'arriver à un but, putain !

Super intéressant, je ne connaissais pas, merci !

la FSF a une idéologie, pas le libre,

Définis « le libre »…

la FSF utilise le libre pour autre chose que ce pour quoi le libre est connu et utilisé; ne vous étonnez pas que les gens s'éloignent du mot "libre" pour lui préférer le mot "open source" qui dit clairement qu'il est neutre sur tout ce qui ne touche pas le libre

Heu… La FSF a une certaine définition du libre car c'est son fondateur qui l'a formalisé (je ne dis pas « inventé » car Stallman lui-même, comme d'autres, dit que c'était un « esprit » qui était déjà présent avant la création de la GPL et de la FSF), donc c'est assez cavalier (mais habituel chez toi) de dire que ce n'est pas la définition « connu[e] et utilisé[e] ». Mais du coup oui alors, que ceux qui ne défendent pas les valeurs de liberté et de vie privée se mettent à utiliser un mot comme « open source », très bien ! Ça désigne effectivement plutôt bien ce qu'ils défendent.

Mais attention, « défendre » ne veut pas forcément dire intriquer de manière incurable des choses qu'on a du mal à mettre par écrit dans une licence (la « philosophie ») : Stallman a choisit comme outil les quatre libertés, de manière pragmatique, qui ne forcent effectivement pas à être « bon » ; comment pourrais-tu définir ça juridiquement ? C'est très intelligent stratégiquement parlant.

Encore une fois, tu veux enlever au libre ce pour quoi il a été créé. Je ne sais pas pour qui tu te prends en voulant décréter ça.

Tu t'es fait trouer ? La première fois que SSH est lancé, il se lance sans problème et ne dit pas avoir d'option inconnue dans la config. De plus, les clés doivent bien exister à ce moment-là.

avril 15 10:08:31 sshd[4575]: Server listening on 0.0.0.0 port 22.
avril 15 10:08:31 sshd[4575]: Server listening on :: port 22.
Ensuite, un KILL sorti de nulle part, et redémarrage avec une conf différente (ou un binaire différent ne supportant pas PAM), et les clés manquantes ? J'imagine en fait un binaire spécifique compilé par un attaquant, avec des clés statiques dedans où un truc du genre.

avril 15 10:30:32  sshd[4895]: /etc/ssh/sshd_config line 84: Unsupported option UsePAM
avril 15 10:30:32  sshd[4895]: Could not load host key: /etc/ssh/ssh_host_rsa_key
avril 15 10:30:32  sshd[4895]: Could not load host key: /etc/ssh/ssh_host_dsa_key
avril 15 10:30:32  sshd[4895]: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
avril 15 10:30:32  sshd[4895]: Disabling protocol version 2. Could not load host key
avril 15 10:30:32  sshd[4895]: sshd: no hostkeys available -- exiting.

Bref, quelqu'un est en train de faire quelque-chose dans ton dos, ou a (plus probablement) installé un RAT ou autre truc du genre. Vérifie que ta machine n'est pas infectée.

leboncoin.fr est devenu le site le plus lent que j'utilise

Faudrait en faire un journal, car c'est tellement vrai. J'avais cru lire ici qu'en gros c'était depuis leur rachat par une grosse boîte de merde, il y a un an ou deux. Leur site est clairement insupportable, mais tellement utile…

PS : pour Humble Bundle, je n'ai pas eu de captcha (ce n'est pas tout le temps…), tu es considéré plus à risque que moi :).

Bah, c'est le principe de reCAPTCHA et justement le problème, selon moi : c'est un système global de gestion de réputation où tu n'as absolument aucun contrôle. Alors tu peux dire que la plupart du temps, c'est quelques images à reconnaître, voire c'est plutôt facile, mais il se trouve que certains utilisateurs, sur décision de Google, sont plus ou moins emmerdés ou empêchés de participer au net grâce à ses systèmes. Bien sûr, tu vas dires que c'est légitime pour un paquet de cas, mais il y en a toujours pour lequel ça le sera beaucoup moins, et on ne saura pas dire si c'est volontaire ou non…

Perso, je me fais prendre tellement pour un bot que je laisse tomber dès que je tombe dessus. Oui, j'ai un setup pas standard, avec du blocage de pub/cookie/JS partout. Est-ce que c'est ça qui me fait viser ? Peut-être, ou peut-être pas et il faudrait que j'enlève mon chapeau en alu. Mais je n'ai pas moyen de savoir.

Merci pour ton retour, content que ça fonctionne. Par contre, je t'indique que les bricolages de ce genre (j'ai déjà bidouillé des trucs alambiqués avec) sont en général peu pérennes. Mais au moins c'est instructif et amusant.

Et pour ceux qui veulent lire sur le sujet, je conseille les écrits d’Evgeny Morozov qui m’a fait connaître le principe de « solutionnisme technologique » ; il vient d’ailleurs d’écrire un article sur le Covid-19 pour le Diplo : https://blog.mondediplo.net/covid-19-le-solutionnisme-n-est-pas-la-solution

Également lié, Éric Sadin dont j’ai acheté le dernier livre « L’Intelligence artificielle ou l’enjeu du siècle : Anatomie d’un antihumanisme radical », et qui avait fait une interview très intéressante chez Thinkerview : https://www.thinkerview.com/eric-sadin-lasservissement-par-lintelligence-artificielle/

J’espère que ça en intéressera plus d’un d’entre vous, car j’avoue que parfois l’audience de LinuxFr me fait peur récemment. Je sais bien que tout le monde n’est pas fan de Stallman ici (qui dénonce ce genre de chose depuis belles lurettes), mais c’est tellement triste de voir des « libristes » renier ses idéaux si concrètement aujourd’hui.

Je me répète mais j'avais suggéré le device-mapper dans ta dépêche, qui n'a pas cette limite. As-tu essayé ?

• On pourrait demander aux FAI de bloquer les IP associées à un site

C'est pas fait en général à cause du virtual-hosting généralisé. Mais ça serait une super pression pour passer à IPv6 : le gouvernement bloque par IP, alors si vous hostez plein de monde sur la même, ça va faire mal ! Solution ? Passez à IPv6 !

• Ce n'est pas le protocole (DNS ou DoH) qui change le problème

Arrête avec ça : oui, en pure technique ça ne change pas grand chose, mais en pratique, tu passes d'un protocole avec whatmille impléms différentes, qui existe depuis quarante ans et est virtuellement intégré à tout ce qui se connecte à Internet, vers un truc tout nouveau normalisé principalement par Google (qui truste l'IETF de plus en plus) et présent certes dans les grand browsers récents aujourd'hui, et fournit (pour la résolution) par seulement trois « clampins » contre virtuellement tous les FAI dans le monde pour DNS. Ça, ça fait une différence énorme, même si techniquement et hypothétiquement tout le monde pourrait utiliser et fournir les deux.

La baisse des cotisations sociales a été compensée par une augmentation de la CSG, afin de faire reposer le coût de la Sécurité Sociale à un ensemble plus large de la société et non qu'aux seuls salariés.

Bof, dans l'absolu les revenus autres que du travail que couvre la CSG (retraites, chômage, capital, patrimoine) sont dérivés du travail à la base (je rappelle qu'on est encore en répartition pour les retraites, et que le capital capte une partie de la valeur du travail), donc ça change temporairement la répartition mais ça aura une tendance à changer plus tard. Et surtout, ça a été transféré des employeurs aux salariés dans l'immédiat ! Et la CSG n'est pas progressive, donc ça a plutôt en fait répartit la charge sur les plus pauvres que les plus riches…

Ce qui explique, que malgré la résorption du déficit, le budget de la Sécu n'a cessé d'augmenter ces dernières années.

Cette phrase est contradictoire : la résorption du déficit oblige à augmenter le budget de la sécu. Pas « malgré ».

la crise des gilets jaunes qui a obtenu la baisse de la CSG, on va avoir un vrai défi pour faire comprendre que l’hôpital va devoir être financé, et par tous.

Oui c'est ballot, on a commencé par faire plaisir aux patrons pour ensuite compenser sur les vieux et les chômeurs, et ils ont gueulé… mais c'est bien sûr la faute aux seuls seconds ! Dans quelle logique on peut dire « il faut diviser par deux les resources patronales pour la sécu afin de pérenniser les subventions de feu le CICE » ? (argument du gouvernement) À quoi ça rime de passer ça en douce (c'était exactement pendant le début des gilets jaunes) et de se plaindre quand les gens découvrent le pot aux roses ? Refuser de réaugmenter les cotisations sécu parce que la réforme de la CSG n'a pas pu passer entièrement, c'est normal ? Dire que c'est la faute aux gilets jaunes ?

Alors après, oui, les élections (où pas grand monde va voter, c'est effectivement la faute aux abstentionnistes) et les manipulations des journaux (que plus personne ne paye, les citoyens l'ont bien cherché) font qu'on a un résultat selon la norme officielle qu'on ne peut pas contester si on est légaliste (ce que je suis, je pense), et je suis d'accord qu'on ne remet pas en cause Macron avec un « il n'a pas vraiment été élu blah blah ». Mais tout remettre sur le dos des opprimés alors que ceux aux pouvoir ont insisté pour leur faire porter le chapeau, c'est dégueulasse.

Prendre ce qui arrange pour un but, pas question de regarder l'ensemble surtout si il dérange pour son but…
Rien de nouveau.

Alors là, balèze : va relire mon commentaire, et voit comment tu fais exactement ce que tu dénonces.

Penses-tu que tout le monde est prêt à perdre 200€/mois sur son salaire net pour donner des sous à l'hôpital. Pour la plupart des gens se sera non. On a le système qu'on mérite collectivement.

Les 200€/mois, c'est sûrement ce qu'on payait déjà avant, quand le système de santé était plus équilibré. On a « gagné » ces 200€ de richesses sur le dos de la sécu, et c'est ce qui permet d'afficher un niveau de vie soit-disant plus élevé aujourd'hui, où on peut commander n'importe quelle connerie chinoise pour pas cher alors que ça n'était pas possible il y a 30 ans. Il est là (et dans un paquet d'autres trucs) ton écart, et certes aujourd'hui peut-être que certains rechigneraient à aller en arrière, mais c'est un choix très important qui même s'il ne semblerait pas accumuler beaucoup de partisans au début, devrait faire réfléchir plus d'un vu le résultat qu'on a aujourd'hui.

Et pour info, 200€/mois c'est vraiment pas grand chose : il y a deux ans, les cotisations « patronales » de la branche maladie de la sécu c'était 13% de ton brut. Ça doit faire plus que 200€ pour pas mal de gens ici. Ça a été ramené à 7% il y a un an grâce à notre superbe majorité LREM à l'assemblée, la différence doit bien faire tes 200€ pour un certain nombre de gens. Sauf qu'elle est allée dans la poche des patrons, pas dans la tienne… Et après il y a aussi la branche accidents, la branche famille, la branche vieillesse, etc. Cf. mon journal d'il y a quelques mois : https://linuxfr.org/users/benoar/journaux/le-trou-de-la-secu-est-une-volonte-politique

Tankey est peut-être proche de cette tranche d'âge ?… En tous cas, je constate que les gens même d'âge « moyen » (et donc statistiquement peu susceptibles d'avoir de graves complications) ont vraiment des réactions très différentes : je suis comme toi assez indifférent (pour moi-même) à cette maladie, à part pour mes proches âgés, mais j'ai l'impression qu'on me prend parfois pour un inconscient de ne pas flipper comme le font certains. J'essaye de rassurer comme je peux, même si des fois mon attitude peut avoir l'effet inverse ! Pas facile.

C'est marrant comme quand on baisse la TVA et autres taxes, « magiquement » ça ne crée pas de dette et pas trop de désavantage visible au premier abord.

Moins de TVA ça veut dire moins de ressources financières pour l'État, et donc moins de service public. L'hôpital sera donc encore plus dégradé (mais ça viendra plus tard, on aura tous oublié), alors que le privé aura été sauvé par cette manne, et viendra à la rescousse pour palier les déficiences du public.

Joli plan des néo-libéraux en perspective, encore une fois. La prochaine épidémie sera encore mieux guérie grâce à nos oligarques généreux !

Surtout qu'ici on parle d'une nouveauté qui est optionnelle. Pas tout le monde ne peut et ne doit se servir de ce truc avec systemd. Uniquement si cela répond au cas d'usage identifié.

Perso, vu comment systemd progresse, je pense que ça risque d'être obligé un jour où l'autre. Pour le coup, ça ne sera pas que la faute de Lennart, puisque c'est poussé par un paquet d'autres promoteurs dans les distros.

D'ailleurs je le rappelle que ses fondateurs ont préféré concevoir son successeur à part (Plan 9) plutôt que de faire une évolution incrémentale car le changement à opérer était trop lourd.

Et on voit le résultat. Pour moi, la faillite de Plan 9 est due certes à l'inertie des utilisateurs (migrer à une nouvelle manière de voir est toujours compliqué par tout un tas de facteurs non-techniques), mais également à l'intégration trop poussée avec par exemple l'authentification ou le stockage. Parce que les syscall réduits, ça je pense que c'est une révolution que tout le monde aimerait avoir, mais l'existant aujourd'hui est tellement plus gigantesque qu'à l'époque que ça n'arrivera probablement jamais. Mais question intégration trop poussée, c'est exactement ce qui est reproché à systemd, qui a lui pourtant du succès…

Mais pour revenir à ta critique d'Unix, perso c'est le genre d'argument que j'entends régulièrement et où se sont plantés tellement de monde…

En quoi ce cheminement pourtant commun aujourd'hui est problématique ?

(je comprends que c'est problématique, t'inquiètes pas)

Ce n'est pas normal qu'un utilisateur qui déchiffre la partition déchiffre les données de tout le monde en même temps.

C'est un choix qui est depuis longtemps assumé et n'a pas posé problème, de ce que je constate. Seulement si tu as un modèle de menace parano.

Ce n'est pas réalisable actuellement sans éteindre la machine ou sans se déconnecter totalement.

Ça n'est pas fait, mais ça le serait très bien sans systemd : comme pour le login automatique si on a déchiffré le système au boot, PAM peut avoir des modules pour faire ça. Pourquoi ça n'a pas été fait par ce biais ? Je ne sais pas, mais vu la tendance de Lennart à tout réinventer à sa sauce, ça ne m'étonne pas de lui qu'il ait dû savoir que ça aurait été possible par PAM mais a préféré l'ajouter dans systemd.

Il y a bien sûr la partie interaction avec les évènements liés à la veille, qui sont le cœur originel de systemd et la raison pour laquelle il intègre udev, mais ça aurait pu (et dû !) tellement être fait de manière non-intégrée… Pour info, je suis au courant de ces problématiques bien même avant que Lennart ne s'en soit occupé, car ces interactions étaient déjà réfléchies sur les Mac PPC sous Linux (~ 2005 ou 2006 pour mon cas) puisque la gestion correcte de la veille était l'une des killer-feature de Mac OS X (les PCs étaient à la ramasse à l'époque). C'était avec des démons spécifique (pbbuttonsd ou pommed, après recherche car ma mémoire flanche) et des kernels patchés pour avoir un suspend-to-ram fonctionnel, mais il y avait des réflexions intéressantes sur comment bien intégrer ça, mais qui n'ont pas abouti.

non réalisable sans effectuer ce genre de changements profonds.

C'est faux.

Et cela n'a rien d'obligatoire, si cela ne t'intéresse pas, tu ne l'utilises pas.

C'est l'argument massue avec tout ce qui vient de systemd : t'as qu'à utiliser un système sans systemd, et voir toutes les fonctionnalités se dégrader petit à petit. Oui, les mainteneurs ne peuvent pas doubler leur efforts pour gérer plusieurs systèmes d'init, et donc dire que « c'est pas obligatoire, tu peux faire autrement » est fallacieux ; ça ne sera pas maintenu, ça ne marchera plus. (mais je sais qu'il ne tient qu'à moi d'envoyer des patchs, mais je ne mets pas assez d'effort à cette tâche ; j'ai un exemple typique avec libvirt où les scripts sysv ont été supprimés, y'a plus que des units systemd, mais ils marchent toujours très bien avec la dernière version disponible de libvirt car ils n'ont pas été effacés depuis l'ancienne — killer-feater standard de Debian qui n'efface pas les conffiles si on le souhaite, en passant)

Et forcément pour faire ça, oui il faut du bout de code et de config dans l'initrd car le disque dur est chiffré, oui des données doivent être stockées ailleurs par rapport à nos habitudes, etc. Mais il n'y a pas d'autre choix, en fait.

Si, avec cryptfs (qui est un des choix offert par systemd-homed, en plus), tu ne chiffres que le home de l'utilisateur. Perso, chiffrer le système entier je ne comprends pas l'intérêt (encore une fois, dans des modèles de menace raisonnables). Par contre pour les méta-données utilisateur d'un volume qui bouge de machine, actuellement ça n'est effectivement pas facilement faisable.

Le seul truc auquel je pense c'est la double authentification. Je trouve que c'est très adapté à plein de situations qui concernent à peu près tout le monde.

Pour remplacer les anciens token smartcard/SIM/USB avec PIN code ? Ça oblige en plus à avoir un téléphone et faire de l'entrée manuelle, mais les deux facteurs sont la dans les deux cas.

D'autres exemples de technos modernes de sécurité ?

Pour le cas de systemd-homed, avoir un home encryptée avec une clé séparée de celle de la machine… je m'en fous. Voire je m'en fous de chiffrer tout court.

Je pense aussi à l'authentification forcée d'application sur des systèmes liés à des magasins, ou mécanismes similaires (j'ai fait une conf sur Firefox OS à l'époque où il vivait encore où Mozilla se targuait de faire du libre et de protéger les utilisateurs en n'autorisant que ses apps validées, sans contournement possible bien sûr). C'est anti-liberté.

Ou encore la manie de passer par des gestionnaires de mot de passe, voire en ligne (qui finissent troués), alors qu'à une époque on se profilait à l'utilisation bien meilleure de clé. La gestion était pour des cas d'utilisations différents d'aujourd'hui où Google avec son WebAuth imagine une grande menace de la part des fournisseurs (mais pas lui-même, bien sûr) alors que c'était l'inverse à l'époque de PKCS. Où ils foutent de la biométrie obligatoire alors que c'est éthiquement répréhensible (pour moi).

Il y a aussi les solutions de sandbox (de syscall, ou autre), qui servent à des utilisateurs qui font tourner n'importe quoi sur leur machines en mode YOLO. Je n'utilise que des logiciels libres, de confiance.

Tout ce qui est secure boot, qui essaye de résoudre un problème insoluble : un soft ne pourra jamais être sûr de ce sur quoi il tourne, il pourra toujours être manipulé.

Beaucoup de solutions de firewall (bon, j'y vais peut-être un peu dur, là), qui pour mon cas d'utilisateur de logiciels maîtrisés et modifiables n'a aucun intérêt. Un firewall c'est pour des softs que tu ne maîtrise pas, où des machines que tu ne maîtrise pas.

La plupart des solutions de CDN ou de « protection » de sites contre les DDoS, qui sont des rackets de protection : je fais du petit et décentralisé, j'ai jamais d'emmerdes (oui, j'ai bien dit que c'était pour mes cas, et ça n'ira bien sûr pas à d'autres).

Mettre sur TLS partout : plutôt de se dire qu'on va protéger ses données parce qu'on passe tout le temps aux US et qu'on ne veut pas être espionné par la NSA, on devrait plutôt chercher à faire du local, court, voire sans accès à Internet pour plein de choses qui n'en ont pas besoin. Ça n'est pas forcément mal dans certains cas, mais la manière dont est réfléchi le modèle du « tout est observé par les US » oblige à un modèle de menace délirant, qui occulte plein d'autres problématiques.

C'est tout ce à quoi je pense pour l'instant.

que quand ça revient à la normale tu puisses avoir tes loisirs habituels avec ton niveau de vie habituel plutôt que de devoir tout reconstruire.

Mais quand est-ce que ça reviendra à la normale ? C'est ça (je pense) qui fait peur à ceux qui crient à l'esclavage. Avec le ralentissement de la propagation par le confinement, afin de s'adapter au « rythme » de la disponibilité des hôpitaux, il faudra facile une année voire plus avant d'arriver à avoir une immunité de groupe (je sais pu comment ça s'appelle) ou un vaccin (qu'on paiera la peau des fesses) ou autre chose. C'est quoi le plan du gouvernement à long terme avant de proposer ces mesures ?

J'ai l'impression que le mois reconductible a été un compromis trouvé pour ne pas dire « pendant très longtemps », mais aussi longtemps c'est intenable, je ne comprends pas quel est leur plan. D'où les inquiétudes.