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 !
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.
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.
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.
Posté par benoar .
En réponse au journal Le retour de l'esclavage.
Évalué à 2.
Dernière modification le 26 mars 2020 à 23:04.
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.
[^] # 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 !
[^] # Re: L’ambiguïté persiste
Posté par benoar . En réponse au journal Logiciel libre et vie privée. Évalué à 9.
Définis « 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.
[^] # Re: Logs?
Posté par benoar . En réponse au message Le serveur ssh plante après 20 minutes (debian). Évalué à 2.
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.
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.
[^] # Re: ca dénonce grave
Posté par benoar . En réponse au journal Marre des pages web qui chargent les images au fur et à mesure que tu scrolles....... Évalué à 2.
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…
[^] # Re: Expérience utilisateur
Posté par benoar . En réponse au journal Cloudflare abandonne le reCAPTCHA de Google. Évalué à 8.
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.
[^] # Re: Avec le Device Mapper ?
Posté par benoar . En réponse à la dépêche Sauver un disque dur mécanique. Évalué à 2.
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.
[^] # Re: Solutionnisme technologique ?
Posté par benoar . En réponse au journal Covid 19 - un traçage organisé par le monde du libre ?. Évalué à 7.
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.
# Device mapper
Posté par benoar . En réponse au message Comment avoir plus de 256 partitions?. Évalué à 3.
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é ?
[^] # Re: DoH : « le diable est dans les détails »
Posté par benoar . En réponse au journal Mozilla Firefox 74 est maintenant disponible en téléchargement. Évalué à 7.
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 !
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.
[^] # Re: surcharge hospitalière
Posté par benoar . En réponse au journal Le retour de l'esclavage. Évalué à 2. Dernière modification le 26 mars 2020 à 23:04.
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…
Cette phrase est contradictoire : la résorption du déficit oblige à augmenter le budget de la sécu. Pas « malgré ».
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.
[^] # Re: surcharge hospitalière
Posté par benoar . En réponse au journal Le retour de l'esclavage. Évalué à 1.
Alors là, balèze : va relire mon commentaire, et voit comment tu fais exactement ce que tu dénonces.