Pas plus incohérent que de faire des œuvres artistiques non libres mais en utilisant des logiciels libres
Tu n'enfermes pas des gens en créant une BD non-libre. Avec un logiciel non-libre, tu les manipules comme tu veux.
utiliser les meilleurs outils
Dans une logique libertarienne extrême, sans morale, oui « utiliser les meilleurs outils » sans aucune autre considération, ça doit être normal. Quand on a par contre une certaine sensibilité pour les valeurs humanistes, on fait attention à ne pas enfermer son prochain.
mais bon mon firmware il est non libre cherche pas à comprendre.
Bien sûr qu'il est important d'avoir le maximum de liberté logicielle jusqu'au firmware ; cependant, longtemps les firmware ont été considérés comme si « inchangeables » qu'on pouvait les assimiler à du matériel (Stallman encore). C'est moins vrai aujourd'hui, et il faut donc chercher à les libérer encore plus. Question de priorité, encore une fois.
Oui, je sais que pour certaines personnes une interface graphique avec des élément artistiques ça n'existe pas
Alors tes éléments ont peut-être une valeur utilitaire, comme je disais plus haut, et il est plus important de les « libérer » que d'autres œuvres artistiques. Mais continue de caricaturer sans essayer de voir de nuances…
mais les logiciels non libres ne te privent jamais de rien
Je vais répéter des choses sûrement déjà dites, mais le terme « privateur » est à prendre dans le contexte moral que devraient avoir (selon Stallman et les supporters de ses thèses) des sociétés se disant démocratiques : on ne devrait pas imposer à son prochain d'être dirigé par des logiciels et des machines. Du coup, dans ce contexte, utiliser des logiciels non-libres te prive d'un paquet de libertés qu'une société morale devrait accepter, comme copier le logiciel puisque ce ne sont que des bits, et le modifier comme tu veux puisque les ordinateurs sont des machines reconfigurables à l'infini, etc. D'où le terme « privateur ».
Je vais tenter une analogie périlleuse, mais je suis sûr qu'à l'époque où l'esclavage était ancré dans les mœurs, parler de « travail forcé » pour un esclave ne devait avoir aucun sens : c'est « normal », c'est un esclave ! On ne l'a pas privé de sa liberté de choisir son travail, car c'est normal pour un esclave d'obéir à ses maîtres !
il n'y a alors plus aucun rapport entre ce livre en particulier et LinuxFr…
Nan mais un livre sur les geeks, qui parle d'une planète où un super ordinateur impose des choses à ses habitants, où un certain Linus semble résister… tu vois pas le rapport ?
Toujours le même débat, mais j'enchaîne : pour Stallman et beaucoup de libristes, l'important est que les œuvres « d'usage pratique » (mots de Stallman en français dans le texte) soient libres. Cela concerne la majorité des logiciels, mais peu les œuvres artistiques, à part si elles ont une valeur utilitaire. La question des libertés liées à des œuvres autres que le logiciel est arrivée bien après celui-ci, quand des personnes plus éloignées du code informatique se sont ralliées au mouvement. Les problématiques des œuvres artistiques libres sont intéressantes, mais pour moi beaucoup moins importantes que celles du logiciel, qui contraignent ta vie tous les jours, contrairement à ce genre d'œuvre qu'est une BD.
Ici, on parle d'une œuvre pour se divertir, ou réfléchir. Ça ne me gène pas du tout qu'elle ne soit pas sous une licence libre. Ça me gène beaucoup plus quand je vois des gens promouvoir des œuvres artistiques libres mais en utilisant des logiciels privateurs : c'est complètement incohérent de mon point de vue. Malheureusement, c'est de plus en plus en vogue.
Je voulais dire de règle de changement de fuseau, pardon.
Et depuis les débuts de l'informatique, la règle pour savoir quand on change d'heure a été modifiée.
Ah bon ? Heure_d'été : Effectivement, je n'avais pas vu qu'on avait décalé le passage à l'heure d'hiver, mea culpa. Bon, disons que c'est « relativement ancien », pour me rattraper ;-)
Pour les machines, j'en connais plus qui ne gèrent pas les changements d'heure que l'inverse. Par exemple les digicodes qui permettent de rentrer sans code jusqu'à 19h en été et 20h en hivers.
Tous les téléphones actuels sont réglés sur l'alternance été/hiver, et beaucoup ne sont plus mis à jour.
Tout ce qu'il faut pour gérer les changements dans les règles et gérer les date historiques existe déjà depuis des dizaines d'années !
Entre exister et marcher en pratique, sur les problèmes d'heure et date, il y a malheureusement souvent un pas de géant. Mais j'espère tout comme toi que tout marchera bien quand même, dans le fond.
Peut-être que les pages ne sont réellement « supprimées » de la RAM que quand la mise en swap totale a réellement réussi ? Du coup, oui, pendant le temps de sauvegarde en swap, tes pages sont dupliquées entre la RAM et le swap, mais de toutes façons ton système est freezé pendant cette période donc ça n'est pas dérangeant. Et si l'hibernation échoue, ton système « repart » sans avoir rien à remettre en RAM… Non ?
Déjà, /proc est un répertoire contenant des pseudo-fichiers. Et des pseudo-fichiers, ce sont des fichiers qui n'ont pas d'existence « réelle » tant qu'on n'a pas accédé à leur contenu : du coup, le noyau ne « stocke » rien dans ce système de fichier, il fait « apparaître » du contenu au moment où tu y accèdes.
mais que la liste des actions don't elle a besoin soit suffisamment spécifié pour pouvoir s'assurer qu'elle n'est pas corrompu.
Ah, OK, je pensais que tu parlais d'autre chose : d'interdire des flux déclarés parce que quelqu'un (l'admin, qui n'a pas codé l'appli) estime qu'ils ne sont « pas légitimes » (vu en vrai !).
Par contre, autoriser uniquement des flux spécifiés pour ton application, oui, et comme je disais c'est exactement pareil en IPv6 avec des connexions reçues/émises depuis/vers des IP diverses (que tu trouves « daubé »), et du Docker avec du mapping de port. Je persiste juste à dire que coder des prérequis applicatifs dans des éléments du réseau, c'est scléroser le réseau et perdre tous les avantages d'IPv6 (même si — encore une fois — c'est possible).
Le contrôle du comportement d'un programme, c'est la base de la sécurité (ce que tu as avec les droits unix, avec les lsm, avec les gr security, avec seccomp, etc).
Malheureusement, cette pratique dans le réseau fait qu'on mélange l'adressage — qui concerne la topologie du réseau — avec des besoins applicatifs et de « sécurité » codés dans le réseau plus ou moins en dur, et que cela va forcément entraîner une sclérose du schéma d'adressage qui ne sera plus changeable, et qu'on devra palier « en dessous » en rajoutant une couche de routage sous-jacente, c'est à dire des tunnels ou autre technologie de VPN/overlay/etc. Et on aura perdu les propriétés de malléabilité du réseau que permet IP.
Oui, et les machines les suivent-elles ? Ici en France, on n'a pas changé de fuseau depuis les débuts de l'informatique, donc c'est facile de dire que « tout se passe bien ». Beaucoup de matos ne se met pas à jour vis-à-vis des modifications de fuseau horaire, cf. il y a quelques années où on en a entendu parler aux US quand c'est arrivé. La théorie est belle, mais en pratique ça va être assez moche.
ça simplifiera les choses qu'il n'y ai plus les changements d'heure.
À terme, peut-être, mais gérer la transition va être horrible : il faudra modifier toutes les applications/machines existantes, dont plein qui ne se mettent pas à jour facilement.
Après, je n'aime pas en général l'argument de « changer c'est compliqué », mais si on le fait, faisons-le au moins pour une bonne raison ; mais franchement, la perspective de pas de changement d'heure ne me semble pas si génial que ça.
on peut espérer que la décision de l'UE fasse tâche d'huile
Tu auras toujours des cas à la con ; le « plus personne ne change de fuseau », je n'y crois pas. Et même pour des calculs de date historique, tu auras toujours besoin de gérer les fuseau avec heure été/hiver différente.
J'ajoute que j'ai parfois entendu parmi les informaticiens la croyance que « sans changement d'heure été/hiver, on n'aura plus de problème de calcul d'heure les jours de changement » : c'est faux ! Déjà, ça voudra dire qu'il faudra mettre à jour toutes les machines actuelles au regard du fichier des fuseaux horaires, et ça serait une vrai gageur. Certes, Debian sait bien le faire avec son dépôt « volatile » même pour les anciennes distros, mais c'est tellement la cata partout ailleurs… Et c'est sans parler des tous les autres problèmes qui pourraient arriver avec la transition, et que tout ça ne changera rien aux problèmes de fuseau horaire qui arrivent de toutes façons entre pays.
C'est pas vraiment une « structure » mais au Hackerspace (à l'Élabo) il y a un certain nombre de personnes qui réparent des machines. Et un stock de poubelles^Wmachines à recycler impressionnant (enfin, je pense qu'une bonne partie est allée à la benne lors du dernier nettoyage).
Pareil ici pour ma banque, même pour l'espace client de gestion de son compte. Bon, ça a changé il y a 6 mois avec la refonte, mais c'était le cas pendant plusieurs années. J'ai même reçu un joli courrier papier après ma remarque sur laquelle ils m'indiquent qu'ils ne voyaient pas de problème…
C'est toi qui choisi quels ports sont utilisés (c'est un mapping que tu fais). Tu n'es pas obligé d'autoriser des plages de port
J'aurais bien aimé avoir ton explication sur ce choix… Alors j'enfonce un peu le clou : s'imaginer qu'on maîtrise une application parce qu'on peut « choisir » quels ports elle utilise, c'est un peu comme ceux qui croient maîtriser la consommation CPU ou mémoire d'une appli avec les cgroup. Tu te dis « Je vais interdire à l'application de faire ci ou ça », alors qu'en fait tu la casses parce que si un flux existe, c'est qu'il a une bonne raison d'exister, comme pour la conso CPU ou mémoire. J'ai l'impression que les gens font des analogies à deux francs sur « restreindre » une application comme un être vivant : ça va la « calmer » un peu de limiter son accès réseau / son CPU / sa mémoire… c'est débile !
Oui, ce que tu pointes (qui est un utilitaire) est plutôt défini par les configurations de socket : https://manpages.debian.org/unstable/systemd/systemd.socket.5.en.html
Je précise dans le journal qu'une configuration pour approx est fournie par défaut dans ce format. Cependant, le manuel ne semble pas indiquer la possibilité de spécifier un nom d'hôte dans "ListenStream" (équivalent du premier champ pour inetd), ce qui est pour moi une régression inacceptable (les identifiants sous forme de noms changent en général moins que les IP, et dans mon exemple le nom d'hôte sera spécifié potentiellement pour d'autres services, et la modification serait laborieuse et prompte à erreur si elle se faisait par adresse ; sans parler de la lourdeur avec les IPv6). Encore une réinvention de la roue en moins bien.
Si quelqu'un qui utilise systemd pouvait me contredire, je n'en serais que plus heureux ; mais il faudrait au moins mettre à jour le man.
Je vais faire le commentaire habituel : avec du suspend-to-ram, j'ai mon système up plus rapidement que mes écrans s'allument… (2-3 s, en gros) Et j'ai tout de chargé et connecté, pas besoin de relancer mes n logiciels et leur contexte.
OK, j'ai oublié la troisième voie : ne rien en avoir à foutre et rester comme on est par la force, l'isolement, etc, afin de défendre nos besoins en énergie. Ça « peut » marcher, mais j'ai quelques doutes quand même.
Va falloir discuter un coup avec les gilets jaunes, alors, parce que ça me semble assez incompatibles avec l'injonction permanente à gagner du pouvoir d'achat.
Je ne pense pas que c'est ce qu'ils veulent : ils ne veulent juste pas en perdre. On a détruit les services publics pour les remplacer par plus de consommation et de divertissement, mais ça ne suffit pas à combler ce manque.
Après, bien sûr que dans ma perspective il y a une grosse dimension décroissance qui est assez difficile à faire accepter. Mais il n'y a pas d'autre solution, le seul choix étant de savoir si on veut la choisir (maintenant) ou la subir (plus tard). Généralement, quand on subit, c'est moins beau à voir.
C'est toi qui choisi quels ports sont utilisés (c'est un mapping que tu fais). Tu n'es pas obligé d'autoriser des plages de port parce que peut être que quelqu'un va les utiliser un jour
Alors là tu retombes complètement dans les contorsions inutiles d'IPv4 : en quoi « choisir » les ports de tes applications va t'aider à la maîtriser ? Faire du mapping de port, c'est comme faire du NAT, c'est des modalités locales « hors » de l'appli qui sclérosent le routage et le réseau ; c'est de « l'intelligence dans le réseau ». Les ports ne sont pas faits pour servir de variable d'ajustement du placement de service, à la base, même si c'est la « doctrine Docker » aujourd'hui (les mecs qui ont inventé Docker n'y connaissent rien en réseau).
Je ne comprends pas du tout ce que ça t'apporte de pouvoir bidouiller ça.
OK donc tu veux mettre de l'intelligence au milieu, et ça ne colle pas bien dans le modèle « classique » d'IP.
Par contre, la gestion de surcharge peut très bien s'effectuer côté client, avec des SRV et/ou l'utilisation correcte de getaddrinfo(3), qui permet de base d'itérer sur un nombre d'hôtes renvoyé par le DNS, et trouver un serveur fonctionnel dans le tas (avec des règles précises d'essai et de repli pour les SRV). Tu peux même mettre des règles en « fontal » également si tu le souhaites, sur critère X ou Y, pour renvoyer un ICMP unreachable quand tu veux.
Encore une fois, tu peux toujours utiliser des solutions « intelligentes » dans le réseau pour faire de l'analyse et du re-routage en cas de surcharge ou autre, comme l'exemple que tu as donné, mais tu peux également utiliser les méthodes plus « bout-en-bout ».
Je me demande quel est l'overhead (octets utiles sur octets pour transporter) pour dire "salut" suivi de "salut" suivi de "je t'ai pas vu en ligne hier" (chose qu'on ne fait pas avec des mails) par rapport aux autres protocoles.
Sûrement 100 fois moins que la somme des JS utilisés sur chaque page Web pour visionner le-dit message ;-)
C'est assez intéressant. J'ai déjà eu des idées similaires pour un autre type de projet, et j'avais également déjà voulu faire du chat par e-mail, sans y penser sérieusement… bravo à vous.
En ce qui concerne les groupes, j'avais tenté de voir comment était supporté la gestion de groupe « historique » de l'e-mail (https://tools.ietf.org/html/rfc5322#page-17) et ça marchait dans Outlook, ce qui m'avait motivé pour creuser un peu, celui-ci étant pour moi le plus petit dénominateur commun. Manque de bol, j'ai l'impression que c'est le MUA qui gère le mieux cette feature… Effectivement, tracker les modification d'état du groupe de manière non-stricte est à faire, et le système présenté ici est pas mal.
La ou Internet IPv4 est un réseau de réseaux, avec des passerelles, avec IPv6 il n'y a plus qu'un seul réseau?
« Réseau de réseaux » ne veut pas forcément dire « imbrication » avec NAT ! Internet v6 est autant un réseau de réseau qu'IPv4, c'est juste que l'interconnexion se fait de manière « plate » jusqu'aux extrémités.
Si tu es distribué c'est complexe quelque soit ta version d'IP, c'est le fait d'avoir 2 logiciels qui tournent et qui doivent être synchronisés qui pose problème pas le routage, pas le reverse proxy.
Oui, sauf que si ton application ne nécessite pas d'état partagé, comme approx, tu n'as pas à t'embêter avec ; le frontal en reverse-proxy t'oblige à le faire, même si ton application ne le nécessite pas. Après, si tu gères majoritairement des applications distribuées qui nécessitent du partage d'état, avoir à le faire sur le proxy n'ajoute qu'une contrainte de plus, en effet.
[^] # Re: Sinon il y a systemd
Posté par benoar . En réponse au journal Lancer un programme sans accès au réseau, merci les espaces de noms réseaux. Évalué à 3.
Mmmhhh… tu peux expliquer ton utilisation ? Parce que là, je ne vois pas l'utilité…
[^] # Re: En effet, mais on parle aussi de libre parfois ici
Posté par benoar . En réponse au journal Le Guide du Voyageur Galactique a enfin un successeur : Pixel !. Évalué à 8.
Tu n'enfermes pas des gens en créant une BD non-libre. Avec un logiciel non-libre, tu les manipules comme tu veux.
Dans une logique libertarienne extrême, sans morale, oui « utiliser les meilleurs outils » sans aucune autre considération, ça doit être normal. Quand on a par contre une certaine sensibilité pour les valeurs humanistes, on fait attention à ne pas enfermer son prochain.
Bien sûr qu'il est important d'avoir le maximum de liberté logicielle jusqu'au firmware ; cependant, longtemps les firmware ont été considérés comme si « inchangeables » qu'on pouvait les assimiler à du matériel (Stallman encore). C'est moins vrai aujourd'hui, et il faut donc chercher à les libérer encore plus. Question de priorité, encore une fois.
Alors tes éléments ont peut-être une valeur utilitaire, comme je disais plus haut, et il est plus important de les « libérer » que d'autres œuvres artistiques. Mais continue de caricaturer sans essayer de voir de nuances…
Je vais répéter des choses sûrement déjà dites, mais le terme « privateur » est à prendre dans le contexte moral que devraient avoir (selon Stallman et les supporters de ses thèses) des sociétés se disant démocratiques : on ne devrait pas imposer à son prochain d'être dirigé par des logiciels et des machines. Du coup, dans ce contexte, utiliser des logiciels non-libres te prive d'un paquet de libertés qu'une société morale devrait accepter, comme copier le logiciel puisque ce ne sont que des bits, et le modifier comme tu veux puisque les ordinateurs sont des machines reconfigurables à l'infini, etc. D'où le terme « privateur ».
Je vais tenter une analogie périlleuse, mais je suis sûr qu'à l'époque où l'esclavage était ancré dans les mœurs, parler de « travail forcé » pour un esclave ne devait avoir aucun sens : c'est « normal », c'est un esclave ! On ne l'a pas privé de sa liberté de choisir son travail, car c'est normal pour un esclave d'obéir à ses maîtres !
Nan mais un livre sur les geeks, qui parle d'une planète où un super ordinateur impose des choses à ses habitants, où un certain Linus semble résister… tu vois pas le rapport ?
[^] # Re: En effet, mais on parle aussi de libre parfois ici
Posté par benoar . En réponse au journal Le Guide du Voyageur Galactique a enfin un successeur : Pixel !. Évalué à 5.
Toujours le même débat, mais j'enchaîne : pour Stallman et beaucoup de libristes, l'important est que les œuvres « d'usage pratique » (mots de Stallman en français dans le texte) soient libres. Cela concerne la majorité des logiciels, mais peu les œuvres artistiques, à part si elles ont une valeur utilitaire. La question des libertés liées à des œuvres autres que le logiciel est arrivée bien après celui-ci, quand des personnes plus éloignées du code informatique se sont ralliées au mouvement. Les problématiques des œuvres artistiques libres sont intéressantes, mais pour moi beaucoup moins importantes que celles du logiciel, qui contraignent ta vie tous les jours, contrairement à ce genre d'œuvre qu'est une BD.
Ici, on parle d'une œuvre pour se divertir, ou réfléchir. Ça ne me gène pas du tout qu'elle ne soit pas sous une licence libre. Ça me gène beaucoup plus quand je vois des gens promouvoir des œuvres artistiques libres mais en utilisant des logiciels privateurs : c'est complètement incohérent de mon point de vue. Malheureusement, c'est de plus en plus en vogue.
[^] # Re: Ne pas utiliser l'argument fallacieux de la facilité pour les logiciels
Posté par benoar . En réponse au journal [HS] Etes-vous pour rester à l'heure d'été ou à l'heure d'hiver ?. Évalué à 1.
Je voulais dire de règle de changement de fuseau, pardon.
Ah bon ? Heure_d'été : Effectivement, je n'avais pas vu qu'on avait décalé le passage à l'heure d'hiver, mea culpa. Bon, disons que c'est « relativement ancien », pour me rattraper ;-)
Tous les téléphones actuels sont réglés sur l'alternance été/hiver, et beaucoup ne sont plus mis à jour.
Entre exister et marcher en pratique, sur les problèmes d'heure et date, il y a malheureusement souvent un pas de géant. Mais j'espère tout comme toi que tout marchera bien quand même, dans le fond.
# Tentative
Posté par benoar . En réponse au message Étrange occupation de la mémoire virtuelle. Évalué à 1.
Peut-être que les pages ne sont réellement « supprimées » de la RAM que quand la mise en swap totale a réellement réussi ? Du coup, oui, pendant le temps de sauvegarde en swap, tes pages sont dupliquées entre la RAM et le swap, mais de toutes façons ton système est freezé pendant cette période donc ça n'est pas dérangeant. Et si l'hibernation échoue, ton système « repart » sans avoir rien à remettre en RAM… Non ?
[^] # Re: plusieurs erreur de base
Posté par benoar . En réponse au message probleme if. Évalué à 1.
Peut-être confonds-tu avec les espace avant/après les crochets fermant/ouvrant ? Je me suis déjà bêtement fait avoir avec ça.
# Car il n'a pas d'existence en mémoire
Posté par benoar . En réponse au message question sur le /proc. Évalué à 5.
Déjà, /proc est un répertoire contenant des pseudo-fichiers. Et des pseudo-fichiers, ce sont des fichiers qui n'ont pas d'existence « réelle » tant qu'on n'a pas accédé à leur contenu : du coup, le noyau ne « stocke » rien dans ce système de fichier, il fait « apparaître » du contenu au moment où tu y accèdes.
[^] # Re: L’avenir et le passé
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 1.
Ah, OK, je pensais que tu parlais d'autre chose : d'interdire des flux déclarés parce que quelqu'un (l'admin, qui n'a pas codé l'appli) estime qu'ils ne sont « pas légitimes » (vu en vrai !).
Par contre, autoriser uniquement des flux spécifiés pour ton application, oui, et comme je disais c'est exactement pareil en IPv6 avec des connexions reçues/émises depuis/vers des IP diverses (que tu trouves « daubé »), et du Docker avec du mapping de port. Je persiste juste à dire que coder des prérequis applicatifs dans des éléments du réseau, c'est scléroser le réseau et perdre tous les avantages d'IPv6 (même si — encore une fois — c'est possible).
Malheureusement, cette pratique dans le réseau fait qu'on mélange l'adressage — qui concerne la topologie du réseau — avec des besoins applicatifs et de « sécurité » codés dans le réseau plus ou moins en dur, et que cela va forcément entraîner une sclérose du schéma d'adressage qui ne sera plus changeable, et qu'on devra palier « en dessous » en rajoutant une couche de routage sous-jacente, c'est à dire des tunnels ou autre technologie de VPN/overlay/etc. Et on aura perdu les propriétés de malléabilité du réseau que permet IP.
[^] # Re: Ne pas utiliser l'argument fallacieux de la facilité pour les logiciels
Posté par benoar . En réponse au journal [HS] Etes-vous pour rester à l'heure d'été ou à l'heure d'hiver ?. Évalué à 0.
Oui, et les machines les suivent-elles ? Ici en France, on n'a pas changé de fuseau depuis les débuts de l'informatique, donc c'est facile de dire que « tout se passe bien ». Beaucoup de matos ne se met pas à jour vis-à-vis des modifications de fuseau horaire, cf. il y a quelques années où on en a entendu parler aux US quand c'est arrivé. La théorie est belle, mais en pratique ça va être assez moche.
À terme, peut-être, mais gérer la transition va être horrible : il faudra modifier toutes les applications/machines existantes, dont plein qui ne se mettent pas à jour facilement.
Après, je n'aime pas en général l'argument de « changer c'est compliqué », mais si on le fait, faisons-le au moins pour une bonne raison ; mais franchement, la perspective de pas de changement d'heure ne me semble pas si génial que ça.
Tu auras toujours des cas à la con ; le « plus personne ne change de fuseau », je n'y crois pas. Et même pour des calculs de date historique, tu auras toujours besoin de gérer les fuseau avec heure été/hiver différente.
# Ne pas utiliser l'argument fallacieux de la facilité pour les logiciels
Posté par benoar . En réponse au journal [HS] Etes-vous pour rester à l'heure d'été ou à l'heure d'hiver ?. Évalué à 7.
J'ajoute que j'ai parfois entendu parmi les informaticiens la croyance que « sans changement d'heure été/hiver, on n'aura plus de problème de calcul d'heure les jours de changement » : c'est faux ! Déjà, ça voudra dire qu'il faudra mettre à jour toutes les machines actuelles au regard du fichier des fuseaux horaires, et ça serait une vrai gageur. Certes, Debian sait bien le faire avec son dépôt « volatile » même pour les anciennes distros, mais c'est tellement la cata partout ailleurs… Et c'est sans parler des tous les autres problèmes qui pourraient arriver avec la transition, et que tout ça ne changera rien aux problèmes de fuseau horaire qui arrivent de toutes façons entre pays.
[^] # Re: sur Rennes ?
Posté par benoar . En réponse au journal Refaire fonctionner des portables dans un fablab. Évalué à 3.
C'est pas vraiment une « structure » mais au Hackerspace (à l'Élabo) il y a un certain nombre de personnes qui réparent des machines. Et un stock de poubelles^Wmachines à recycler impressionnant (enfin, je pense qu'une bonne partie est allée à la benne lors du dernier nettoyage).
[^] # Re: Même le milieu médical s'en fout
Posté par benoar . En réponse au journal Sécurité, vie privée... et Google Analytics!. Évalué à 3.
Pareil ici pour ma banque, même pour l'espace client de gestion de son compte. Bon, ça a changé il y a 6 mois avec la refonte, mais c'était le cas pendant plusieurs années. J'ai même reçu un joli courrier papier après ma remarque sur laquelle ils m'indiquent qu'ils ne voyaient pas de problème…
[^] # Re: L’avenir et le passé
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 0.
J'aurais bien aimé avoir ton explication sur ce choix… Alors j'enfonce un peu le clou : s'imaginer qu'on maîtrise une application parce qu'on peut « choisir » quels ports elle utilise, c'est un peu comme ceux qui croient maîtriser la consommation CPU ou mémoire d'une appli avec les cgroup. Tu te dis « Je vais interdire à l'application de faire ci ou ça », alors qu'en fait tu la casses parce que si un flux existe, c'est qu'il a une bonne raison d'exister, comme pour la conso CPU ou mémoire. J'ai l'impression que les gens font des analogies à deux francs sur « restreindre » une application comme un être vivant : ça va la « calmer » un peu de limiter son accès réseau / son CPU / sa mémoire… c'est débile !
[^] # Re: Pour remplacer inetd
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 3.
Oui, ce que tu pointes (qui est un utilitaire) est plutôt défini par les configurations de socket : https://manpages.debian.org/unstable/systemd/systemd.socket.5.en.html
Je précise dans le journal qu'une configuration pour approx est fournie par défaut dans ce format. Cependant, le manuel ne semble pas indiquer la possibilité de spécifier un nom d'hôte dans "ListenStream" (équivalent du premier champ pour inetd), ce qui est pour moi une régression inacceptable (les identifiants sous forme de noms changent en général moins que les IP, et dans mon exemple le nom d'hôte sera spécifié potentiellement pour d'autres services, et la modification serait laborieuse et prompte à erreur si elle se faisait par adresse ; sans parler de la lourdeur avec les IPv6). Encore une réinvention de la roue en moins bien.
Si quelqu'un qui utilise systemd pouvait me contredire, je n'en serais que plus heureux ; mais il faudrait au moins mettre à jour le man.
[^] # Re: userland
Posté par benoar . En réponse au journal Mon retour sous KDE. Évalué à 1.
Je vais faire le commentaire habituel : avec du suspend-to-ram, j'ai mon système up plus rapidement que mes écrans s'allument… (2-3 s, en gros) Et j'ai tout de chargé et connecté, pas besoin de relancer mes n logiciels et leur contexte.
Ah, et ça fait 10 ans que ça fonctionne…
[^] # Re: Proposition n°1: la production doit être durable
Posté par benoar . En réponse au journal Cahier de doléances. Évalué à 1.
OK, j'ai oublié la troisième voie : ne rien en avoir à foutre et rester comme on est par la force, l'isolement, etc, afin de défendre nos besoins en énergie. Ça « peut » marcher, mais j'ai quelques doutes quand même.
[^] # Re: Proposition n°1: la production doit être durable
Posté par benoar . En réponse au journal Cahier de doléances. Évalué à 0.
Je ne pense pas que c'est ce qu'ils veulent : ils ne veulent juste pas en perdre. On a détruit les services publics pour les remplacer par plus de consommation et de divertissement, mais ça ne suffit pas à combler ce manque.
Après, bien sûr que dans ma perspective il y a une grosse dimension décroissance qui est assez difficile à faire accepter. Mais il n'y a pas d'autre solution, le seul choix étant de savoir si on veut la choisir (maintenant) ou la subir (plus tard). Généralement, quand on subit, c'est moins beau à voir.
[^] # Re: L’avenir et le passé
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 4.
Alors là tu retombes complètement dans les contorsions inutiles d'IPv4 : en quoi « choisir » les ports de tes applications va t'aider à la maîtriser ? Faire du mapping de port, c'est comme faire du NAT, c'est des modalités locales « hors » de l'appli qui sclérosent le routage et le réseau ; c'est de « l'intelligence dans le réseau ». Les ports ne sont pas faits pour servir de variable d'ajustement du placement de service, à la base, même si c'est la « doctrine Docker » aujourd'hui (les mecs qui ont inventé Docker n'y connaissent rien en réseau).
Je ne comprends pas du tout ce que ça t'apporte de pouvoir bidouiller ça.
[^] # Re: Merci !
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 1.
OK donc tu veux mettre de l'intelligence au milieu, et ça ne colle pas bien dans le modèle « classique » d'IP.
Par contre, la gestion de surcharge peut très bien s'effectuer côté client, avec des SRV et/ou l'utilisation correcte de getaddrinfo(3), qui permet de base d'itérer sur un nombre d'hôtes renvoyé par le DNS, et trouver un serveur fonctionnel dans le tas (avec des règles précises d'essai et de repli pour les SRV). Tu peux même mettre des règles en « fontal » également si tu le souhaites, sur critère X ou Y, pour renvoyer un ICMP unreachable quand tu veux.
Encore une fois, tu peux toujours utiliser des solutions « intelligentes » dans le réseau pour faire de l'analyse et du re-routage en cas de surcharge ou autre, comme l'exemple que tu as donné, mais tu peux également utiliser les méthodes plus « bout-en-bout ».
[^] # Re: Merci !
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 1.
Si tu fais de l'authentification en frontal, il va bien falloir synchroniser tes tokens de session. C'est un exemple, il y en a peut-être d'autres.
[^] # Re: Consommation de ressources
Posté par benoar . En réponse au journal Delta Chat est prêt pour le bureau. Évalué à 10.
Sûrement 100 fois moins que la somme des JS utilisés sur chaque page Web pour visionner le-dit message ;-)
# Sympa
Posté par benoar . En réponse au journal Delta Chat est prêt pour le bureau. Évalué à 6.
J'ai regardé la spec pour comprendre un peu mieux :
https://github.com/deltachat/spec/blob/master/spec.md
C'est assez intéressant. J'ai déjà eu des idées similaires pour un autre type de projet, et j'avais également déjà voulu faire du chat par e-mail, sans y penser sérieusement… bravo à vous.
En ce qui concerne les groupes, j'avais tenté de voir comment était supporté la gestion de groupe « historique » de l'e-mail (https://tools.ietf.org/html/rfc5322#page-17) et ça marchait dans Outlook, ce qui m'avait motivé pour creuser un peu, celui-ci étant pour moi le plus petit dénominateur commun. Manque de bol, j'ai l'impression que c'est le MUA qui gère le mieux cette feature… Effectivement, tracker les modification d'état du groupe de manière non-stricte est à faire, et le système présenté ici est pas mal.
Bon courage pour la suite !
[^] # Re: My 2 cents
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 4.
« Réseau de réseaux » ne veut pas forcément dire « imbrication » avec NAT ! Internet v6 est autant un réseau de réseau qu'IPv4, c'est juste que l'interconnexion se fait de manière « plate » jusqu'aux extrémités.
[^] # Re: L’avenir et le passé
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 1.
L'article de LWN à propos de cette présentation vient d'être dispo au public aujourd'hui :
https://lwn.net/Articles/777595/
[^] # Re: Merci !
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 1.
Oui, sauf que si ton application ne nécessite pas d'état partagé, comme approx, tu n'as pas à t'embêter avec ; le frontal en reverse-proxy t'oblige à le faire, même si ton application ne le nécessite pas. Après, si tu gères majoritairement des applications distribuées qui nécessitent du partage d'état, avoir à le faire sur le proxy n'ajoute qu'une contrainte de plus, en effet.