Si l'ouverture d'un document PDF verrouillé par mot de passe ne fonctionnement pas sous votre Debian Buster, c'est potentiellement à cause du bug ci-lié. Semble (je n'ai pas trop cherché) affecter poppler 0.66 et le commit de fix semble être dans la 0.73.
En tous cas sur une mint 19.3 (que j'avais sous la main pour tester) en 0.62 ça fonctionne.

EDIT: comme alternative, le PDF.js de Firefox ESR actuel (78) fonctionne.

Un graph 3D représentant les idéologies et organisations s'y rattachant telles que vues par tzitzimitl.
Ce graph est vraiment sympa à mon sens de relatif béotien dans ce domaine car il permet de sortir d'un schéma "droite/gauche" pour fixer 3 axes arbitraires et définir les idéologies que l'on souhaite selon ces critères-ci. La version pré-remplie ici est déjà bien, mais on peut tout modifier directement puis publier sa version. On peut aussi se placer soi-même là-dedans.

Exemple d'usage : en 3D on voit bien que ce n'est pas forcément faire le grand écart que d'être à la fois intéressé par des idées anarchistes et libérales par exemple qui ne sont finalement pas si éloignées, toujours selon ces 3 critères. Alors que le communisme (tel qu'il a été implémenté) est, lui, franchement loin.

Ah oui il y a tout simplement un link application/rss+xml sur les pages youtube… alors que tellement galère de trouver le channel_id sinon… donc encore plus simple pour ajouter une chaine à son agréagateur habituel :)

Alors pour les gens qui utilisent encore POP et qui ont un Thunderbird qui se met à jour tout seul comme souvent sur les Windows, si subitement sans rien remarquer de différent et sans message d'erreur çamarcheplus™, la raison pourrait être que Thunderbird 78 désactive par défaut TLS < 1.2 et que certains fournisseurs comme ici Free n'ont pas mieux que TLS 1.1 sur POP !

Trois "solutions" toutes crades :

• le plus logique, passer en IMAP sauf que Thunderbird ne sait pas faire, il faut créer un nouveau compte et buter l'ancien et copier les mails entretemps car en POP tout est viré du serveur au fur et à mesure par défaut (c'est pas moi qui suis boulet a priori, c'est officiel : https://support.mozilla.org/en-US/kb/switch-pop-imap-account)
• réactiver les vieux TLS… sauf qu'il faut aller dans le about:config etc. et au téléphone j'ai pas eu le courage
• désactiver la sécurité… au final ça passe des serveurs free sur une ligne free et ça n'en sort pas donc ils ont déjà accès à tout de toutes façons…

J'ai choisis la dernière solution, bien crade mais moins relou à distance… et entre un TLS troué ou pas de TLS sur une ligne FAI vers un service FAI… dans tous les cas c'est pas ouf.

Si seulement TB pouvait au minimum afficher un message d'erreur, même incompréhensible… on aurait au moins un point de départ…

Depuis un certain temps (voire toujours), il m'a été compliqué d'utiliser OMEMO pour XMPP. C'est vrai que c'est compliqué, que les serveurs et les clients ne suivent pas forcément les specs etc. mais ça marchottait quand même.
Depuis quelques jours c'était plutôt pire, et avec un contact, systématiquement, s'il commençait la conversation, je ne recevais rien (ou si par hasard je regardais au même moment, j'avais la signalisation qu'il était en train d'écrire mais jamais le contenu).
On a tenté de creuser ensemble le problème, mais quoi que je fasse, il n'avait d'active par défaut au tout début qu'une clef précise ne correspondant à aucun des clients que j'utilisais !
Nous avons tous tenté de tout purger de chaque côté concernant OMEMO mais rien à faire. Même en purgeant la clef du client et en en obtenant donc une nouvelle, cette (mauvaise) clef-là était toujours la seule présentée au début.
J'ai fini par déplacer directement sur mon serveur ejabberd tout ce qui était donnée pubsub eeeeet… depuis ça marche.
Les clefs (publiques) sont stockées côté serveur et présentées lorsqu'on est déconnecté, de tel sorte qu'un contact va pouvoir écrire des messages chiffrés qui seront stockés et lisibles par n'importe lequel des client que j'utiliserai en premier pour me connecter (s'il était déjà connu du serveur bien sûr). Et apparemment ce stockage était corrompu…
Forcément tout contenu pubsub stocké par tous les utilisateurs de mon serveur a sauté… je ne sais pas trop quel impact cela a mais il devrait être léger.

Qu'est-ce qui fait réagir un système avec systemd aux événements ACPI (poweroff etc.) ? logind !
Du coup la doc qui dit qu'il faut acpid n'est plus utile : quand acpid fonctionne, il appelle un script qui vérifie juste que logind tourne et qu'un appel dbus précis est possible (voir /usr/share/acpi-support/policy-funcs).

J'ai creusé tout ça parce que une seule VM parmi une grosse dizaine ne répondait pas aux injonctions d'extinction "propre" de son hyperviseur…
Il se trouve que cette VM était à la base un conteneur LXC non-privilégié (oui j'ai testé ça un moment pour voir). Et dans ce conteneur, le service systemd-udevd était masqué…

J'ai appris plein de choses sur udev, acpi, logind.
J'ai découvert les modules noyal "button" et "evdev".
Par hasard je suis tombé sur lsinitramfs.
Pas si mal :)

Pour lancer acpid en mode debug + log : acpid -d -l -f

Pour faire un gros transfert (plusieurs centaines de To), j'ai tenté d'après cette réponse le coup de tar + mbuffer. Avec de gros buffers côté mbuffer, c'est vraiment pas mal. Et mbuffer gère lui-même la partie réseau (avec -I et -O). On pourrait peut-être imaginer compresser en plus ou éviter les header de tar mais c'est déjà pas si mal je trouve.
Sur réseau 10 Gbps, on arrive à monter à du 250 Mo/s avec le vent dans le dos : c'est probablement un des systèmes de fichiers distribué qui traine, le transfert tourne alors que tout est en prod, etc. En tous cas c'est beaucoup plus rapide qu'un simple rsync (encore heureux). Mais forcément on ne peut pas reprendre s'il y a un crash…

Un pine64 dans un coin et envie de monter vite-fait une sonde de température avec un DS18B20 sous la main ?
C'est devenu facile…

• il y a une image armbian basée sur Debian Buster toute prête
• le pine64 est "mainline" depuis un moment donc on peut utiliser un Linux standard
• il y a même ce qu'il faut pour activer le w1 (one-wire) facilement, aussi facilement que sous raspbian, à coup d'overlay dans le DT

Doc utile :

le branchement des connecteurs
http://files.pine64.org/doc/Pine%20A64%20Schematic/Pine%20A64%20Pin%20Assignment%20160119.pdf

Des thread de forum (pointus en tous cas pour moi à propos de DTD) :
https://forum.pine64.org/archive/index.php?thread-1004-1.html
https://forum.pine64.org/archive/index.php?thread-6987.html

et ci-lié comment activer les overlays et utiliser leurs paramètres.

Dans mon cas j'utilise le GPIO 18 du connecteur Pi-2-like. Donc pin PC8.

Il m'a suffit d'ajouter ces deux lignes dans /boot/armbianEnv.txt et pouf le thermomètre est reconnu et fonctionne :
overlays=w1-gpio
param_w1_pin=PC8

Le plus long a été de trouver les infos, essayer de la comprendre, découvrir que tout est déjà prêt et pré-mâché…

Pas si mal sur le fond, même si j'ai du mal avec le style. Bref en tous cas, il semble que ce soit reparti pour un tour d'interdiction de l'IEF (instruction en famille). Devons-nous nous bouger une énième fois ?

Source de l'edit : expérience. Après si t'es bien avec ta banque tu peux toujours demander l'extourne de ces frais… par exemple dans le cas d'une assurance-vie qui traine dans un coin (lire : pas dans ta banque principale pour raison historique) mais que leur SI lie forcément à un compte courant pour leur simplifier la gestion (ce que je comprends)… et que donc ce compte sera toujours inactif par définition et n'est en réalité pas du fait du client.

Ça serait une clause du contrat avec la banque, limite ça serait moins pire qu'une sorte d'arnaque légale… même si ce sont peut-être les lobbys banquiers qui l'ont institutionnalisée. Et oui j'ai lu l'argumentaire de la loi eckert, mais je suis pas pour autant convaincu, surtout en 2020.

Alors comme ça on nous prépare des files sur la route réservées à certaines personnes ayant le droit de dépasser les autres sur des critères complètement subjectifs… si ça c'est pas de la discrimination, je sais pas ce qu'il vous faut :) Déjà que les files réservées aux bus c'est à mon sens très limite… là c'est vraiment pire.
Et le pompon c'est qu'on développe en même temps de quoi surveiller cela, comme si une machine automatique pouvait vraiment détecter à la volée combien de personnes sont dans une voiture avec une fiabilité suffisante. Entre les bébés dans leur siège, les pare-soleil à l'arrière, les vitres teintées etc. je vois juste pas comment c'est possible. Et ça devrait même détecter les mannequins… hé beh. :)
Donc au lieu de débloquer les bouchons, on va continuer d'en créer artificiellement (bah oui la voiture c'estmal™) tout en dé-pénalisant lesgensbiens™. Et en se basant sur des choses totalement abstraites comme "crit'air 0" qui pour le coup va vraiment avantager les méchant riches car pour l'instant la voiture électrique c'est pas vraiment le plus facile niveau budget.
Je trouve toujours autant magnifique le niveau de bullshit qu'on peut faire passer sous couvert de… euh… ce qu'ils appellent "écologie" mais qui n'a rien à voir avec la nature ou la gestion des ressources ? Parce que désolé mais les voitures électriques, c'est rigolo, c'est classe, c'est pro-nucléaire donc potentiellement plus pérenne, mais la partie "écologique" je cherche toujours (indices : masse, batteries, source de l'énergie).

ffmpeg utilisé comme ici et couplé à un serveur rstp (comme spydroid, disponible sur f-droid) sur le téléphone permet d'avoir une webcam via android sur son linux. v4l2loopback est packagé dans Debian. C'est donc assez simple à tester.

Je n'ai cependant pas réussi à avoir mieux que 320×240 de définition depuis spydroid et il faut passer un paramètre au module v4l2loopback (https://github.com/umlaeute/v4l2loopback/issues/78) pour le rendre compatible avec les applis "relou" comme Chromium. Sinon ça va. Et non je ne vais pas montrer ma tronche en visio conf mais j'ai quand même tout testé comme si… histoire de savoir.

J'ai voulu tester un hébergement web + PHP + MariaDB rapidement et j'avais vu passer adminer sans vraiment prêter attention. J'ai donc testé… et oui ça juste marche. Un simple fichier PHP et c'est parti on peut a priori faire ce qu'on veut avec ses bases de données (il y a plein de SGBD reconnus) sans se prendre la tête avec les commandes SQL reloues. Ça permet de mettre son nez "graphiquement" et tester toute la chaine, tester des sauvegardes, etc.

En tous cas beaucoup plus simple que phpMyAdmin…

J'ai quelques sites web qui tournent chez moi depuis un moment (2010…), et au fur et à mesure j'ai appris des choses, mis d'autres choses en vrac, changé des configurations, etc.

Je suis en train de migrer une partie de mes services dans des VM sur d'autres machines. C'était donc le moment de revoir de fond en comble mon setup web.

J'ai beaucoup cherché s'il n'y aurait pas moyen de tout mettre dans un système magique qui s'occupe un peu de tout, calcule des infos en plus (graph), permet de filer un coin de web rapidemement à quelqu'un sans se prendre la tête etc. et forcément il y a plein d'outils qui existent et qui prétendent faire le café.

Grosso modo j'ai vu soit des gros trucs pour revendeurs à la cpanel/vesta/ispconfig/… soit des scripts maison mais qui du coup ne fonctionnent que sur par exemple Ubuntu (LEMPer) ou CentOS (VPSSIM). Or toute mon infra est en Debian, et je n'ai pas besoin d'intégration mail/DNS/TLS/… car tout cela est déjà géré par d'autres briques. Sortent un peu du lot, froxlor et tinycp…

J'ai hésité pour froxlor mais beaucoup de doc date de Debian wheezy, il y a tout de même cette notion de revendeur, DNS, mail, … qui ne m'intéresse pas (mais il suffit de ne pas les utiliser, on est d'accord… alors que ça rajoute quand même de la complexité et des risques de failles). Et au final ça ne semblait pas me rajouter beaucoup de facilité. Il aurait aussi fallu gérer les mise à jour et mises à niveau (comme pour tout outil quoi).

Tinycp avait l'air vraiment sympa mais actuellement les dev sont en train de se demander comment ils vont fournir leur bidule et dans tous les cas le code n'est pas libre. Donc compliqué dans le temps si on a pas envie de se prendre le chou et pas propre éthiquement.

J'ai donc perdu beaucoup de temps pour au final écrire le script qui fait juste ce que je veux et voilà. J'espère que je ne suis pas passé à côté de certaines notions élémentaires que les panel sus-cités ont déjà pris dans la tronche et corrigé : le web c'est compliqué et pas vraiment passionnant.

De nos jours sur un système avec systemd (comme une Debian "à jour" sans bidouille pour l'enlever), logrotate est lancé par un timer systemd, et enregistré en tant qu'unit systemd. Pour faire un run de test, il suffit de le start comme un service normal du coup… trop simple.

Pour tester une configuration logrotate, on peut aussi feinter la date de dernière exécution dans /var/lib/logrotate/status et donc après un start, bien vérifier que tout se passe bien… trop simple aussi, mais j'ai dû chercher pour tout ça, je me dis que ça peut servir souvent plutôt que "flemme".

Suite à une discussion sur le chan IRC de proxmox, il semblerait que désactiver ce pointeur absolu lorsqu'on a par exemple une machine virtuelle sans interface graphique (un serveur par exemple) diminue la charge à vide d'environ 2% à autour de 0.7, parfois 0.0 même.
Je reproduis ce comportement chez moi… pourquoi pas du coup. Ça se fait en live, et côté kernel de la VM ça se voit comme une déconnection de périphérique USB.
Celui qui en parlait avait dans les 8% en permanence, et retombe aux même valeurs sans.
À noter que la même option est gérée par libvirt, et que là j'ai déjà remarqué que c'est plutôt utile d'avoir un pointeur absolu lorqu'on utilise une interface graphique via Spice par exemple. Sinon on retombe dans le "vieux" mode où le pointeur se fait "coincer" sur l'affichage et il faut explicitement sortir via une combinaison de touches.

Notes de mon approche pour passer sur une fibre Orange du vieux PPPoE à DHCP. Le principal problème étant que dans ma zone il est nécessaire de taguer les paquets DHCP avec la bonne priorité VLAN… j'ai donc patché busybox et odhcpc6.

À noter qu'au passage, j'ai de l'IPv6 native, un débit qui passe de 100/100 à 400/400 et je ne remonte plus forcément à Paris (donc meilleur routage vers Francfort par exemple et géoloc au bon endroit). Et aussi, plus de changement d'IP systématique toutes les semaines, même si l'IP risque de changer quand même en cas de coupure prolongée.

Toi aussi passe 2h à comprendre pourquoi ton scanner (HP, bien géré par hplip normalement) marche plus depuis mise à jour en Debian Buster…
Verdict : il faut recompiler hplip avec le patch ci-lié…

Problème : tout marche avec hp-scan mais au moment de lire des données
error: No data read.

Éléments notables :
3.18.12 buster = pas marche
3.17.10 VM mint = marche

Très utile :
SANE_DEBUG_DLL=128
hp-scan -g

S'il y a du rouge ou des erreurs à la construction du paquet, je suppose que c'est normal en tous cas ça gène pas…

On ne doit plus voir la ou les lignes d'appel à l'option après patch :
[dll] sane_control_option(handle=0x134a1d0,option=9,action=1,value=0x7ffdf74d0b60,info=0x7ffdf74d0b54)

Le patch modifie une lib cpython, distribuée par le paquet hplip, donc il faut soit l'installer lui (et pas la partie libsane comme je faisais un moment) soit juste copier la lib comme un bourrin.

Rapport de bug d'où le patch semble venir (Debian a "juste" importé 34 (!) patches de Fedora… entre autres) : https://bugzilla.redhat.com/show_bug.cgi?id=1684434

Proxmox est passé (il y a longtemps) d'un simple tar disque virtuel + conf à un format perso (mais ouvert) pour contenir les backup. Pourquoi pas, et il y a des raisons apparemment compréhensibles.

Cependant, on peut être amené à vouloir vérifier un backup ailleurs, sur une machine non-Proxmox (son desktop par exemple). Il existe un outil pour gérer ces sauvegardes mais apparemment pas trop dissocié ni dissociable… il vaut mieux être prévenu du coup, ce que je fais là.

Au pire du pire on peut faire comme moi et juste copier l'exécutable et les libs à la main, si on est sur une distro pas trop différente ça se passera bien (moi du coup de Debian 10 à Debian 10 ça a été crème :)).

Si on s'est trompé de nom (ou a oublié une parie) à l'installation d'une machine Proxmox, renommer n'est pas trop compliqué, suivre la doc officielle. Par contre (comme dit ici : https://memo-linux.com/proxmox-renommer-un-noeud/) il peut être nécessaire de faire un bon vieux reboot au bout, en tous cas on n'a pas réussi sans, même à relancer la plupart des services.