Merci, c'est très intéressant. Je vais t'embêter encore un peu si ça ne te dérange pas (je comprendrais que tu n'aies pas le temps de répondre) : penses-tu qu'apprendre à git-am à traiter ce genre de message serait la bonne solution ? Enfin, ça ressemble plus à un hack qu'autre chose, mais d'un côté de ce que j'ai lu de la RFC 1847 on ne peut pas toucher à la structure multipart/signed donc on est obligé de « l'encapsuler » dans un multipart/mixed si on veut rajouter quelque-chose après.
Bien sûr, la « bonne » solution serait de corriger les softs de gestion de ML pour qu'ils ne touchent pas les messages signés, mais je pense que c'est une bataille déjà perdue d'avance. Es-tu d'accord ?
Merci pour ta réponse. Sur les qualités de l'e-mail hors confidentialité (persistante ou non), intégrité, signature/attestation, non-répudiation je les connais bien, mais ma question était plus orientée sur qu'est-ce qui te fait croire en la sécurisation possible de l'e-mail, au sens des qualités que je viens de citer ? Ta réponse est peut-être uniquement « gnupg le fait bien », mais c'était pour savoir si tu savais argumenter plus précisément dans ce sens, quand d'autres répliquent que « ça ne marchera jamais ».
Tu soulignes bien en tous cas que les qualités que tu voies à l'e-mail sont effectivement décrites comme étant des défauts par d'autres, mais j'ai effectivement la même approche « libre » des technologies : apprendre à l'utilisateur à lire et à écrire, qu'on désignait entre autre comme faisant partie de « l'instruction » des élèves, est essentiel pour en faire des citoyens libres (enfin, leur équivalent numérique).
Par contre, sur l'e-mail killer dont j'en ai effectivement vu passer un paquet, j'ai un peu moins d'espoir que toi : Facebook a bouffé une bonne partie des communications inter-personnelles, et pour une très grande partie de la population (c'est ce qui manquait aux précédents, l'étendue générationnelle). Il reste la communication « entreprise », mais c'est en train d'être attaqué par d'autres. Je tiens toujours à mon e-mail, j'aime le low-tech, mais j'ai un peu peur de l'avenir.
(Mais c’était une mauvaise idée en fin de compte.)
T'es fort pour nous laisser en suspend sur des problèmes intéressants… pourquoi, si c'est pas indiscret ? (ça n'est pas mentionné sur la page de fmail, ça pourrait être intéressant de l'expliquer pour l'histoire)
Un des gros problèmes de cette solution est qu’elle interdit pratiquement toute utilisation de PGP/MIME, sauf pour les fous furieux qui aiment construire et parser des structures MIME « à la main ».
Je suis tombé il n'y a pas longtemps sur mime-construct qui est un script perl qui peut permettre de faire ça ; cf. le man qui indique à la fin explicitement une utilisation de GPG avec un document MIME.
D’une part parce que sécuriser l’e-mail est un problème difficile (tellement difficile que beaucoup de cryptologues ont purement abandonné cette idée et disent aujourd’hui « utilisez Signal »), mais aussi et surtout parce qu’un des intérêts d’OpenPGP en général et de GnuPG en particulier est de donner le contrôle aux utilisateurs (empowering the users, comme on dit en anglais), ce que les approches à la Signal ne font pas.
Par curiosité, pourrais-tu présenter les arguments qui t'incitent à continuer dans la voie d'essayer de sécuriser l'e-mail ? Je suis personnellement pour, même si je ne pratique pas, parce qu'un système de messagerie historique, ouvert, simple et a-centré comme l'email est pour moi indispensable à une vraie informatique libre, même s'il est très imparfait, mais je cherche d'autres arguments si possible :-)
Augeas https://augeas.net/ n'a pas type mais a des sortes de schémas qui sont des « lentilles », basées sur des regexp, qui ont en plus une base théorique solide si c'est ton genre de truc. Ça permet de faire de la modification de fichier de configuration avec toute une base de schémas déjà existant pour plein de logiciels qu'on trouve dans /etc. C'est complètement bidirectionnel ce qui est assez génial, et offre une API accessible dans plein de langages pour de la modification programmatique de fichier de configuration.
Bon, c'est assez différent en fait, car ça n'est pas un truc « générique » comme a l'air d'être le tiens, mais pour gérer de la conf ça semble quand même vachement plus sympa (mon avis).
La migration des clés est un processus prévu dans la norme ! Après, c'était l'époque du TPM 1.2, mais c'était bien un des exemple d'utilisation nécessaire pour certains besoins.
Bravo en passant pour ton journal/dépêche, ça fait du bien de toujours retrouver du contenu très technique encore aujourd'hui.
Ça ressemble vachement à Oracle avec sa base de données ce que vous racontez : utilisé partout par des gens qui le maîtrisent mal et n'ont pas besoin d'un logiciel aussi pléthorique, mais niveau commercial ça turbine à fond.
C'est une manière de voir, mais beaucoup arguent que continuer à construire des centrales très puissantes nous engagent sur un moyen terme ou il sera possible de continuer à consommer comme on le fait aujourd'hui, sans devoir changer en profondeur.
Je suis convaincu de la nécessité de décroître, mais sur les arguments que avoir beaucoup d'énergie nucléaire nous « ferait croire » qu'on peut continuer comme avant ce sont des ressorts psychologiques qui ne sont pas du tout avérés et restent de la spéculation sociologique. J'ai lu François Roddier, si c'est le genre de personne dont tu parles, et même s'il est plutôt convainquant, reste qu'imaginer faire la transition dans une société sans énergie nucléaire suffisante est quelque-chose qui me fait peur.
J'estime que transmettre le savoir et informer sur le changement climatique est une part essentielle de mon boulot de météorologue.
Tout à fait. Mais il y a tellement d'autres choses à faire avant imaginer que fabriquer d'autres centrales nucléaires soit un problème sérieux, surtout si tu crois pouvoir arriver à faire vivre une société comme la nôtre avec si peu d'énergie dans un laps de temps si court ! Comment veux-tu faire réaliser aux gens les concessions nécessaires pour un scénario Négawatt (par exemple) qui est pourtant présenté par les autorités comme plutôt sérieux, alors qu'il faudra qu'ils abandonnent en grande partie en à peine 30 ans transport individuel, chauffage et viande ? Bien sûr qu'il faut s'y préparer, mais commençons par prioriser ses combats !
OK donc pour reformuler en français, le « propriétaire » de la machine (je mets entre guillemets parce que pour les logiciels qui tournent dessus c'est un mensonge, il n'en est pas propriétaire du tout ; juste du matériel) peut demander gentiment à HPE de faire valider (signer) sa clé intermédiaire qui lui permettra de faire tourner le(s) firmeware(s) de son choix, pour certaines machines désignées seulement. C'est mieux que rien, mais perso c'est une telle entrave à la liberté de faire tourner ses logiciels que j'ai beaucoup de peine à appeler ça une « liberté de choix », mais bon. Encore moins de décrire la volonté de « protection » comme légitime, mais c'est mon avis perso.
Le fait que tu décrives le mécanisme en détail sans évoquer de grand système de gestion connu me fait penser que c'est une solution ad-hoc, imaginée par vous dans un coin, et ça ne me rassure pas du tout sur la maturité du truc : ça ressemble à un proto qui a de grands risques de ne jamais voir le jour. Vous basez-vous sur un dérivé de ce qui a été fait pour le Secure Boot sur UEFI (pas que ça soit un système qui ait ma sympathie, mais il a le mérite d'exister), ou alors c'est du BootGuard avec implémentation custom ? Sans parler des questions de gestion, qui sont malheureusement souvent oubliées des concepteurs de ce genre de solution parce que c'est la partie selon moi la plus importante, puisqu'elle concerne les garanties que les utilisateurs peuvent attendre d'un tel système, mais qu'en général c'est la dernière préoccupation des constructeurs. Bref, ça ressemble plus à de la poudre aux yeux qu'à un réel système qui mettrait vaguement en avant l'intérêt de l'utilisateur.
Ca peut sembler etre une usine a gaz, mais a court terme, cela permet deja d'avancer et ne compromet pas le mode de fonctionnement deja etablit.
Le principe technique ne me paraît pas tant usine à gaz : les chaînes de confiance à niveaux multiples sont un classique — même si ici tu ajoutes une propriété comme l'ID de la machine —, et je comprends la volonté de rétro-compatibilité avec l'existant. Mais cette volonté de faire du spécifique est pour moi vouée à l'échec. Enfin, toutes les solutions de protection de ce genre sont pour moi pourries, donc d'un côté je suis content qu'elle échoue.
On etudie d'autres options avec moins de dependances vis a vis d'HPE
Est-ce une réelle volonté ou un affichage pour faire sembler de ce préoccuper de ce point ?
et/ou sans tier de confiance en utilisant une approche blockchain
OK je suis désolé mais quand tu en arrives à sortir ça, pour moi tu es 100% dans le bullshit sans avoir compris réellement le problème. Tu es comme un certain nombre de personne à t'amuser avec de la crypto parce que c'est marrant, mais tu n'as pas compris l'essentiel des problématiques de liberté d'utilisation des machines. C'est un dilemme classique : on met des personne qui croient honnêtement œuvrer à faire des choses bien, mais qui abordent un problème sans les connaissances adéquates. Je sais que tu vas me trouver méprisant, mais je pense que tu devrais réellement te poser la question de ce que tu fais avec les techniques que tu es en train de mettre en place.
Merci en tous cas pour ces explications des mécanismes sur lesquels tu travailles.
Après, pour une note de contexte finale sur mon point de vue : perso, je trouve que la libération des firmwares a peu d'intérêt en dehors de la vérification de l'absence de fonction déloyale à l'utilisateur, et je ne cherche pas absolument à les « libérer » : en effet, ce sont des logiciels plutôt fixés et utilisés uniquement au démarrage de la machine, dont l'OS prend vite le relais. Bref, ça n'a pas un intérêt gigantesque en terme de liberté logicielle pour l'utilisateur. Et l'absence de fonction déloyale serait plutôt à chercher dans la publication de code source ou la certification par des organisme spécifique que dans la possibilité de faire tourner un firmware choisit par l'utilisateur, qui sera de toutes façons toujours une solution minoritaire et ne règle pas le problème de manière globale.
Pour le contexte, bépoète depuis plus de 10 ans, avec Typematrix.
Pourquoi on continue à s'évertuer à décaler les rangées de touches à chaque ligne du clavier ?
Parce qu'il n'existe pas de manière standard de rendre un 105 touches orthogonal ? Je veux dire, personne ne s'est encore mis d'accord sur quelle était la bonne manière de faire : Typematrix en a fait une qui vaut ce qu'elle vaut, mais il y a toujours un compromis à faire sur des touches qui vont être décalées en bas, en haut, voire à l'autre bout du clavier si on veut pouvoir rendre des colonnes inclinées partiellement droites dans une forme rectangulaire, parce que ça ferait vraiment bizarre d'avoir des trous si on redressait strictement un 105 touches classique sans réfléchir.
L'intérêt de garder toutes les touches peut sembler débile aux communautés de keyboard hackers, mais pour la plupart des gens c'est essentiel de ne pas se retrouver avec une touche manquante sur le mapping par défaut : c'est le problème des standards, il faut qu'il y ait toutes les touches présentes comme sur un 105 incliné, sinon ça ne fonctionnera pas. Regarde tous les orthogonaux alternatifs : ce sont des trucs pour spécialistes, avec chacun sa customisation, ça ne pourra jamais fonctionner comme standard global.
C'est pour moi un des grands avantages et une des grande victoire du bépo : avoir réussi a imposer un standard, qui ne plaît pas à tout le monde mais est quand même vachement bien pour la plupart des gens. Perso, j'ai arrêté la customisation à outrance pour mes softs et cherche toujours un entre deux : des customisation essentielles, tout en essayant de me dire que je pourrais me débrouiller sans, sur une config par défaut disponible chez tout le monde, même si ça n'est pas idéal.
Pourquoi le clavier à une main n'a pas été plus loin que ça ?
J'avais un mapping xkb à une main sur typematrix à une époque, il faudrait que je retrouve ça (juste pour les lettres) ; ça n'était qu'un test mais c'était « marrant ».
La difficulté technique repose principalement sur la mise en oeuvre des mécanismes de protection (légitime) des microcodes depuis quelques années (Silicon Root of Trust, et Intel Bootguard en sont quelques exemples). Comment concilier liberté de choix et mécanisme de protection ?
Heu, perso ça m'intéresse, parce que ça fait longtemps que j'étudie le sujet et que je ne vois absolument pas comment c'est possible… Déjà rien qu'au vocabulaire que tu utilises (« protection »), ça n'augure rien de bon. Mais je suppose que tes compromis sont différents de ceux que je pense acceptables. Aurais-tu plus de détails stp ?
OK, donc ça semble plutôt une source pas encore établie et en cours de recherche. C'est très intéressant ce que tu dis ici, mais il ne faudrait pas non plus vendre ça comme un consensus établi ; je pense que la volonté de mahikeulbody était d'être clair sur ce point.
Parce que quand même, dire qu'on ne peut plus faire de nucléaire à cause du réchauffement climatique, qui arrive parce qu'on n'a pas fait assez de nucléaire, c'est un peu fort de café à la base. Et ton 40 à 48° à l'ombre, si en plus tu veux baisser la clim pour que la conso énergétique baisse, ça ne va pas vraiment passer… Perso je suis absolument contre la clim, hein, pour que la boucle de rétro-action soit bien fermée sur la gueule des êtres humains, mais si on en rajoute encore plus en disant qu'il faut zéro nucléaire, tu auras autre chose à craindre que juste le réchauffement climatique.
LinuxFr a probablement parmi le meilleur comité de relecture du paysage informationnel français, tous sujets confondu.
Elle est bonne celle-là ! Je ne l'aurais pas imaginé de cette manière, mais c'est pas complètement faux :-) Oui, ça défouraille grave des fois, et c'est pour ça qu'on s'aime bien, mais je n'aurais jamais osé parlé de « comité de relecture » même si ça s'y prête bien !
Ceux qui écrivent sur Linuxfr sont pour la plupart des spécialistes de haut niveau qui savent parler avec passion de leurs domaines de prédilection.
Je sais bien, j'ai la prétention d'en faire partie /o\ Mais c'est vrai qu'il y a ce mélange de site « maison », de ton relâché, qui fait que même s'il y a effectivement de très bons contributeurs (c'est pour ça que je viens ici aussi !) ça ne fait pas très « officiel » ou « sérieux ». Mais c'est très drôle d'avoir ce mélange !
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 !
[^] # Re: E-mail sans support du client
Posté par benoar . En réponse au journal Bien démarrer avec GnuPG. Évalué à 3.
Merci, c'est très intéressant. Je vais t'embêter encore un peu si ça ne te dérange pas (je comprendrais que tu n'aies pas le temps de répondre) : penses-tu qu'apprendre à git-am à traiter ce genre de message serait la bonne solution ? Enfin, ça ressemble plus à un hack qu'autre chose, mais d'un côté de ce que j'ai lu de la RFC 1847 on ne peut pas toucher à la structure multipart/signed donc on est obligé de « l'encapsuler » dans un multipart/mixed si on veut rajouter quelque-chose après.
Bien sûr, la « bonne » solution serait de corriger les softs de gestion de ML pour qu'ils ne touchent pas les messages signés, mais je pense que c'est une bataille déjà perdue d'avance. Es-tu d'accord ?
[^] # Re: Ouh là lààààà
Posté par benoar . En réponse à la dépêche Bien démarrer avec GnuPG. Évalué à 2.
Merci pour ta réponse. Sur les qualités de l'e-mail hors confidentialité (persistante ou non), intégrité, signature/attestation, non-répudiation je les connais bien, mais ma question était plus orientée sur qu'est-ce qui te fait croire en la sécurisation possible de l'e-mail, au sens des qualités que je viens de citer ? Ta réponse est peut-être uniquement « gnupg le fait bien », mais c'était pour savoir si tu savais argumenter plus précisément dans ce sens, quand d'autres répliquent que « ça ne marchera jamais ».
Tu soulignes bien en tous cas que les qualités que tu voies à l'e-mail sont effectivement décrites comme étant des défauts par d'autres, mais j'ai effectivement la même approche « libre » des technologies : apprendre à l'utilisateur à lire et à écrire, qu'on désignait entre autre comme faisant partie de « l'instruction » des élèves, est essentiel pour en faire des citoyens libres (enfin, leur équivalent numérique).
Par contre, sur l'e-mail killer dont j'en ai effectivement vu passer un paquet, j'ai un peu moins d'espoir que toi : Facebook a bouffé une bonne partie des communications inter-personnelles, et pour une très grande partie de la population (c'est ce qui manquait aux précédents, l'étendue générationnelle). Il reste la communication « entreprise », mais c'est en train d'être attaqué par d'autres. Je tiens toujours à mon e-mail, j'aime le low-tech, mais j'ai un peu peur de l'avenir.
[^] # Re: E-mail sans support du client
Posté par benoar . En réponse au journal Bien démarrer avec GnuPG. Évalué à 3.
T'es fort pour nous laisser en suspend sur des problèmes intéressants… pourquoi, si c'est pas indiscret ? (ça n'est pas mentionné sur la page de fmail, ça pourrait être intéressant de l'expliquer pour l'histoire)
[^] # Re: E-mail sans support du client
Posté par benoar . En réponse au journal Bien démarrer avec GnuPG. Évalué à 4.
Je suis tombé il n'y a pas longtemps sur mime-construct qui est un script perl qui peut permettre de faire ça ; cf. le man qui indique à la fin explicitement une utilisation de GPG avec un document MIME.
[^] # Re: Ouh là lààààà
Posté par benoar . En réponse à la dépêche Bien démarrer avec GnuPG. Évalué à 5.
Par curiosité, pourrais-tu présenter les arguments qui t'incitent à continuer dans la voie d'essayer de sécuriser l'e-mail ? Je suis personnellement pour, même si je ne pratique pas, parce qu'un système de messagerie historique, ouvert, simple et a-centré comme l'email est pour moi indispensable à une vraie informatique libre, même s'il est très imparfait, mais je cherche d'autres arguments si possible :-)
# Ça me fait un peu penser à Augeas
Posté par benoar . En réponse au journal Dhall, une réponse au problème de configuration. Évalué à 3. Dernière modification le 27 mai 2020 à 00:09.
Augeas https://augeas.net/ n'a pas type mais a des sortes de schémas qui sont des « lentilles », basées sur des regexp, qui ont en plus une base théorique solide si c'est ton genre de truc. Ça permet de faire de la modification de fichier de configuration avec toute une base de schémas déjà existant pour plein de logiciels qu'on trouve dans /etc. C'est complètement bidirectionnel ce qui est assez génial, et offre une API accessible dans plein de langages pour de la modification programmatique de fichier de configuration.
Bon, c'est assez différent en fait, car ça n'est pas un truc « générique » comme a l'air d'être le tiens, mais pour gérer de la conf ça semble quand même vachement plus sympa (mon avis).
[^] # Re: sauvegarde de clé ?
Posté par benoar . En réponse à la dépêche Utilisation d’un TPM pour l’authentification SSH. Évalué à 4.
Je vais te ressortir un vieux commentaire de khane< d'une discussion qu'on avait eu il y a… 14 ans là-dessus :
https://linuxfr.org/news/tcpatpm-la-deferlante-silencieuse#comment-740971
La migration des clés est un processus prévu dans la norme ! Après, c'était l'époque du TPM 1.2, mais c'était bien un des exemple d'utilisation nécessaire pour certains besoins.
Bravo en passant pour ton journal/dépêche, ça fait du bien de toujours retrouver du contenu très technique encore aujourd'hui.
[^] # Re: PetiteMerveille
Posté par benoar . En réponse à la dépêche Proxmox VE 6.2 est disponible. Évalué à 5.
Ça ressemble vachement à Oracle avec sa base de données ce que vous racontez : utilisé partout par des gens qui le maîtrisent mal et n'ont pas besoin d'un logiciel aussi pléthorique, mais niveau commercial ça turbine à fond.
[^] # Re: diff, git, delta
Posté par benoar . En réponse à la dépêche Trois utilitaires : Delta, Dust et Watchexec. Évalué à 2.
Un éditeur bien fait le fait normalement très bien aussi, cf. vimdiff par exemple.
[^] # Re: Warning!
Posté par benoar . En réponse au journal Choisir un ordinateur portable en 2020. Évalué à 1.
Je suis convaincu de la nécessité de décroître, mais sur les arguments que avoir beaucoup d'énergie nucléaire nous « ferait croire » qu'on peut continuer comme avant ce sont des ressorts psychologiques qui ne sont pas du tout avérés et restent de la spéculation sociologique. J'ai lu François Roddier, si c'est le genre de personne dont tu parles, et même s'il est plutôt convainquant, reste qu'imaginer faire la transition dans une société sans énergie nucléaire suffisante est quelque-chose qui me fait peur.
Tout à fait. Mais il y a tellement d'autres choses à faire avant imaginer que fabriquer d'autres centrales nucléaires soit un problème sérieux, surtout si tu crois pouvoir arriver à faire vivre une société comme la nôtre avec si peu d'énergie dans un laps de temps si court ! Comment veux-tu faire réaliser aux gens les concessions nécessaires pour un scénario Négawatt (par exemple) qui est pourtant présenté par les autorités comme plutôt sérieux, alors qu'il faudra qu'ils abandonnent en grande partie en à peine 30 ans transport individuel, chauffage et viande ? Bien sûr qu'il faut s'y préparer, mais commençons par prioriser ses combats !
[^] # Re: Mécanismes de protection ?
Posté par benoar . En réponse au journal Microcode ouvert sur materiel HPE ?. Évalué à 2.
OK donc pour reformuler en français, le « propriétaire » de la machine (je mets entre guillemets parce que pour les logiciels qui tournent dessus c'est un mensonge, il n'en est pas propriétaire du tout ; juste du matériel) peut demander gentiment à HPE de faire valider (signer) sa clé intermédiaire qui lui permettra de faire tourner le(s) firmeware(s) de son choix, pour certaines machines désignées seulement. C'est mieux que rien, mais perso c'est une telle entrave à la liberté de faire tourner ses logiciels que j'ai beaucoup de peine à appeler ça une « liberté de choix », mais bon. Encore moins de décrire la volonté de « protection » comme légitime, mais c'est mon avis perso.
Le fait que tu décrives le mécanisme en détail sans évoquer de grand système de gestion connu me fait penser que c'est une solution ad-hoc, imaginée par vous dans un coin, et ça ne me rassure pas du tout sur la maturité du truc : ça ressemble à un proto qui a de grands risques de ne jamais voir le jour. Vous basez-vous sur un dérivé de ce qui a été fait pour le Secure Boot sur UEFI (pas que ça soit un système qui ait ma sympathie, mais il a le mérite d'exister), ou alors c'est du BootGuard avec implémentation custom ? Sans parler des questions de gestion, qui sont malheureusement souvent oubliées des concepteurs de ce genre de solution parce que c'est la partie selon moi la plus importante, puisqu'elle concerne les garanties que les utilisateurs peuvent attendre d'un tel système, mais qu'en général c'est la dernière préoccupation des constructeurs. Bref, ça ressemble plus à de la poudre aux yeux qu'à un réel système qui mettrait vaguement en avant l'intérêt de l'utilisateur.
Le principe technique ne me paraît pas tant usine à gaz : les chaînes de confiance à niveaux multiples sont un classique — même si ici tu ajoutes une propriété comme l'ID de la machine —, et je comprends la volonté de rétro-compatibilité avec l'existant. Mais cette volonté de faire du spécifique est pour moi vouée à l'échec. Enfin, toutes les solutions de protection de ce genre sont pour moi pourries, donc d'un côté je suis content qu'elle échoue.
Est-ce une réelle volonté ou un affichage pour faire sembler de ce préoccuper de ce point ?
OK je suis désolé mais quand tu en arrives à sortir ça, pour moi tu es 100% dans le bullshit sans avoir compris réellement le problème. Tu es comme un certain nombre de personne à t'amuser avec de la crypto parce que c'est marrant, mais tu n'as pas compris l'essentiel des problématiques de liberté d'utilisation des machines. C'est un dilemme classique : on met des personne qui croient honnêtement œuvrer à faire des choses bien, mais qui abordent un problème sans les connaissances adéquates. Je sais que tu vas me trouver méprisant, mais je pense que tu devrais réellement te poser la question de ce que tu fais avec les techniques que tu es en train de mettre en place.
Merci en tous cas pour ces explications des mécanismes sur lesquels tu travailles.
Après, pour une note de contexte finale sur mon point de vue : perso, je trouve que la libération des firmwares a peu d'intérêt en dehors de la vérification de l'absence de fonction déloyale à l'utilisateur, et je ne cherche pas absolument à les « libérer » : en effet, ce sont des logiciels plutôt fixés et utilisés uniquement au démarrage de la machine, dont l'OS prend vite le relais. Bref, ça n'a pas un intérêt gigantesque en terme de liberté logicielle pour l'utilisateur. Et l'absence de fonction déloyale serait plutôt à chercher dans la publication de code source ou la certification par des organisme spécifique que dans la possibilité de faire tourner un firmware choisit par l'utilisateur, qui sera de toutes façons toujours une solution minoritaire et ne règle pas le problème de manière globale.
# Parce qu'il n'y a pas d'orthogonalisation standard du 105 touches ?
Posté par benoar . En réponse au journal Clavier orthogonal, clavier à une main, etc pourquoi rien ne change ?. Évalué à 2.
Pour le contexte, bépoète depuis plus de 10 ans, avec Typematrix.
Parce qu'il n'existe pas de manière standard de rendre un 105 touches orthogonal ? Je veux dire, personne ne s'est encore mis d'accord sur quelle était la bonne manière de faire : Typematrix en a fait une qui vaut ce qu'elle vaut, mais il y a toujours un compromis à faire sur des touches qui vont être décalées en bas, en haut, voire à l'autre bout du clavier si on veut pouvoir rendre des colonnes inclinées partiellement droites dans une forme rectangulaire, parce que ça ferait vraiment bizarre d'avoir des trous si on redressait strictement un 105 touches classique sans réfléchir.
L'intérêt de garder toutes les touches peut sembler débile aux communautés de keyboard hackers, mais pour la plupart des gens c'est essentiel de ne pas se retrouver avec une touche manquante sur le mapping par défaut : c'est le problème des standards, il faut qu'il y ait toutes les touches présentes comme sur un 105 incliné, sinon ça ne fonctionnera pas. Regarde tous les orthogonaux alternatifs : ce sont des trucs pour spécialistes, avec chacun sa customisation, ça ne pourra jamais fonctionner comme standard global.
C'est pour moi un des grands avantages et une des grande victoire du bépo : avoir réussi a imposer un standard, qui ne plaît pas à tout le monde mais est quand même vachement bien pour la plupart des gens. Perso, j'ai arrêté la customisation à outrance pour mes softs et cherche toujours un entre deux : des customisation essentielles, tout en essayant de me dire que je pourrais me débrouiller sans, sur une config par défaut disponible chez tout le monde, même si ça n'est pas idéal.
J'avais un mapping xkb à une main sur typematrix à une époque, il faudrait que je retrouve ça (juste pour les lettres) ; ça n'était qu'un test mais c'était « marrant ».
# Mécanismes de protection ?
Posté par benoar . En réponse au journal Microcode ouvert sur materiel HPE ?. Évalué à 3.
Heu, perso ça m'intéresse, parce que ça fait longtemps que j'étudie le sujet et que je ne vois absolument pas comment c'est possible… Déjà rien qu'au vocabulaire que tu utilises (« protection »), ça n'augure rien de bon. Mais je suppose que tes compromis sont différents de ceux que je pense acceptables. Aurais-tu plus de détails stp ?
[^] # Re: Warning!
Posté par benoar . En réponse au journal Choisir un ordinateur portable en 2020. Évalué à 4.
OK, donc ça semble plutôt une source pas encore établie et en cours de recherche. C'est très intéressant ce que tu dis ici, mais il ne faudrait pas non plus vendre ça comme un consensus établi ; je pense que la volonté de mahikeulbody était d'être clair sur ce point.
Parce que quand même, dire qu'on ne peut plus faire de nucléaire à cause du réchauffement climatique, qui arrive parce qu'on n'a pas fait assez de nucléaire, c'est un peu fort de café à la base. Et ton 40 à 48° à l'ombre, si en plus tu veux baisser la clim pour que la conso énergétique baisse, ça ne va pas vraiment passer… Perso je suis absolument contre la clim, hein, pour que la boucle de rétro-action soit bien fermée sur la gueule des êtres humains, mais si on en rajoute encore plus en disant qu'il faut zéro nucléaire, tu auras autre chose à craindre que juste le réchauffement climatique.
[^] # Re: Manque de citations françaises de linuxfr ?
Posté par benoar . En réponse à la dépêche Ces articles, papiers et autres publications qui mentionnent LinuxFr.org. Évalué à 2.
Elle est bonne celle-là ! Je ne l'aurais pas imaginé de cette manière, mais c'est pas complètement faux :-) Oui, ça défouraille grave des fois, et c'est pour ça qu'on s'aime bien, mais je n'aurais jamais osé parlé de « comité de relecture » même si ça s'y prête bien !
[^] # Re: Manque de citations françaises de linuxfr ?
Posté par benoar . En réponse à la dépêche Ces articles, papiers et autres publications qui mentionnent LinuxFr.org. Évalué à 1.
Je sais bien, j'ai la prétention d'en faire partie /o\ Mais c'est vrai qu'il y a ce mélange de site « maison », de ton relâché, qui fait que même s'il y a effectivement de très bons contributeurs (c'est pour ça que je viens ici aussi !) ça ne fait pas très « officiel » ou « sérieux ». Mais c'est très drôle d'avoir ce mélange !
# Manque de citations françaises de linuxfr ?
Posté par benoar . En réponse à la dépêche Ces articles, papiers et autres publications qui mentionnent LinuxFr.org. Évalué à 6.
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 ?
[^] # Re: Aucun I/O dans le fil d'exécution principal est irréaliste
Posté par benoar . En réponse au journal GNOME avec un scheduler temps réel. Évalué à 2.
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.
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 ?
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).
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.
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.
[^] # Re: Aucun I/O dans le fil d'exécution principal est irréaliste
Posté par benoar . En réponse au journal GNOME avec un scheduler temps réel. Évalué à 0.
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.
# Aucun I/O dans le fil d'exécution principal est irréaliste
Posté par benoar . En réponse au journal GNOME avec un scheduler temps réel. Évalué à 5.
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.
[^] # Re: Le journal n'a qu'un jour mais déjà dépassé.
Posté par benoar . En réponse au journal A propos des protocoles de traçage pour le Covid-19 : Google/Apple vs. INRIA/Fraunhofer. Évalué à 2.
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…
[^] # Re: azerty
Posté par benoar . En réponse au journal systemd, de pire en pire. Évalué à 4.
Ç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.
# Couper la parole peut se faire avec une latence basse
Posté par benoar . En réponse au journal Organiser des visioconférences de haute qualité (avec le logiciel libre Jitsi Meet). Évalué à 2. Dernière modification le 23 avril 2020 à 00:14.
Ç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…)
[^] # Re: L’ambiguïté persiste
Posté par benoar . En réponse au journal Logiciel libre et vie privée. Évalué à 0.
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 !
[^] # Re: et sinon via le hardware ?
Posté par benoar . En réponse au journal Réglage du contraste sur ordinateur portable. Évalué à 0.
Super intéressant, je ne connaissais pas, merci !