There's a lot of info on the web, but I never can find a complete canonical way of doing this when I need it, so here's mine:

On the source machine, dpkg --get-selections > my-selections (here, everybody agrees though)

On the target machine:

# apt update
# apt-cache dumpavail | dpkg --merge-avail
# dpkg --clear-selections  # that's dangerous if you don't set reasonable selections afterwards!
# dpkg --set-selections < my-selections
# apt-get -u dselect-upgrade

And voila.

‒ Je l’avoue : 99 % de ma haine pour l’AI vient du fait que TOUS les services ont réussi à intégrer ça dans leur roadmap en moins de 6 mois ; mais ça fait 15 ans que « l’accessibilité c’est compliqué, on a pas le temps » 😫
‒ L'accessibilité ne rapporte pas d'argent. La bulle qu'est les nouvelles technos est bien plus lucrative.

So true, et tellement souvent pour le buzz plutôt que comme technologie pour résoudre un problème…

If you're fed up by websites installing absurd shortcuts like e.g. ctrl+k (yes, I'm looking at you, GitHub).

Just set permissions.default.shortcuts to 2 (3 doesn't seem to work for me) in about:config, and you're finally free.

Disclaimer: I just tested that moments ago, so maybe there's downsides to this, but for now it just felt amazing stopping worrying whether ctrl+k will do what I want or a random useless action.

Got a stubborn capslock, e.g. in a VM?

xdotool key Caps_Lock

or the more convoluted, but that likely doesn't require installing additional software:

python3 -c 'from ctypes import *; X11 = cdll.LoadLibrary("libX11.so.6"); display = X11.XOpenDisplay(None); X11.XkbLockModifiers(display, c_uint(0x0100), c_uint(2), c_uint(0)); X11.XCloseDisplay(display)'

Quoting the Bash manual page:

If a compound command or shell function executes in a context where -e is being ignored, none of the commands executed within the compound command or function body will be affected by the -e setting, even if -e is set and a command returns a failure status. If a compound command or shell function sets -e while executing in a context where -e is ignored, that setting will not have any effect until the compound command or the command containing the function call completes.

All this isn't so clear, but it actually means that if a simple command (or a pipeline, etc.) exits with an error code inside a function which the caller checks, that command will not be subject to set -e.

In practice, it pretty much means that using functions renders set -e moot:

set -e

foo() {
  false  # this command returns 1
  true
}

foo  # that one would fail
foo && echo "No errors!"  # would print "No errors!", and pass fine

All this basically means set -e is untrustworthy when using shell functions to factorize the code. Worse, it gives an impression of safety, where there isn't any.

See also SO answer 37191242 and the bash-bug thread linked there for a "rationale" (can't say I understand why they don't introduce a custom shell option for this, though).

[edit] I was confused about set -E, so scrapped it. But it's basically unrelated, only affects ERR traps.

When someone states "if you have nothing to hide, you have nothing to fear," this is a pretty good answer:
"I need privacy, not because my actions are questionable, but because your judgement and intentions are."

Source: https://libreddit.mha.fi/r/privacy/comments/fvocq2/i_need_privacy_not_because_my_actions_are/

To import the environment of another process, one can use while read -d '' -r ev; do export "$ev"; done <"/proc/$(pgrep -u "$USER" -x PROCNAME)/environ" (when using bash).

This is particularly handy e.g. when connecting to a machine through SSH while a graphical session is running and wanting to interact with it (X, DBus, etc.).

This leverages some Bash specifics, like read -d '' to use NUL as the line separator. There are solutions only using POSIX constructs, but the only I know involves a temporary file, which is not as handy. Before discovering read -d '' I was using another Bashism: process substitution, in the form of <(tr '\0' '\n' </proc/$(pgrep -u "$USER" -x PROCNAME). It isn't as good as it would not properly handle newlines in the environment, though, but it could easily be converted to a POSIX-compliant construct using a temporary file. Note that the naive alternative of piping the same thing to the while loop (and thus to read) will not work as it would run the loop in a subshell, not affecting the environment of the current shell. Another alternative would be to evaluate the output of such a subshell that would echo it, but that would require escaping the values, to which I don't know a robust POSIX solution (there are plenty of handmade ones around, but most fail in odd corner cases -- and no, printf %q is not in POSIX).

Imaginons une base de donnée qui contient des données dans un encodage différent de celui de stockage… c'est le bordel.

Dans mon cas, j'avais une colonne (enfin, plus d'une…) en utf8, qui contenait la représentation latin1 d'une donnée utf8. #brainfuck.
À priori, je me suis retrouvé avec ça en forçant une communication utf8 à une BDD latin1 qui avait des colonnes utf8. J'imagine donc que naturellement mes données étaient interprétées en latin1 à l'arrivée, et converties en utf8 pour remplir la colonne. Je me retrouve donc avec ce bousin de double encodage.

Bref, je m'en sors avec une version alambiquée des idées de cette page :
UPDATE mytable SET mycolumn = CONVERT(CAST(CONVERT(mycolumn USING latin1) as BINARY) USING utf8);
La partie magique est bien sûr le CONVERT(CAST(CONVERT(mycolumn USING latin1) as BINARY) USING utf8) : on demande une conversion de la valeur en latin1, puis on force une interprétation binaire pour oublier toute notion d'encodage, et on convertit le binaire en utf8. Le résultat est la suppression du "surencodage" latin1 au milieu. Mais évidemment ça ne marche qu'avec des données représentables en latin1 j'imagine, mais je ne sais même pas si avec mon setup j'aurais pu enregistrer des données incompatibles… je préfère ne pas y penser.

[edit]
Si on souhaite voir les lignes qui seraient affectées, ont peut utiliser SELECT mycolumn FROM mytable WHERE mycolumn <> CONVERT(CAST(CONVERT(mycolumn USING latin1) as BINARY) USING utf8); : on sélectionne les lignes pour lesquelles la conversion a un effet.

PS : je suis une quiche en SQL (preuve en est la situation dans laquelle je me suis mis…), donc il y a peut-être d'autres solutions meilleures, une solution pour ne pas avoir à répéter le nom de colonne 2 à 3 fois (ce qui augmente fortement le risque de typo quand on fait ça à la main), etc.

:D

Morts du Covid-19 en France: L'équivalent d'un avion de ligne qui s'écrase PAR JOUR.

Ce n'est pas lui qui a inventé cette comparaison à sensation, mais elle reste toujours aussi pourrie. Cette piqûre de rappel me donne envie de m'énerver ici.
Bref, quel est le rapport entre le nombre de morts d'un virus et le nombre de morts d'un crash aérien ? Aucun, mais le crash aérien fait sensation. Même si au final la majorité des avions de ligne transportent au maximum quelques 200 passagers (pour quelques 300 morts du COVID à priori¹).

Au passage, si j'en crois les stats de l'INSEE, on a quelques 2000 morts par jour, un peu moins de 100 de plus qu'en 2019 sur la même période. Les quelques 300 morts du COVID représentent donc ~15% des morts. Au passage, on notera qu'en 2020, l'INSEE donne une moyenne inférieure à 2019 de quelques 150 morts, juste pour rire un peu (encore ici, le diable est probablement dans les détails de ce que cachent ces chiffres bruts de décoffrage par un avion de ligne).

Bref, on fait toujours dire aux données ce qu'on veut, et quand ça suffit pas on rajoute du sensationnel. Rien de nouveau, mais ça reste à gerber.

D'autant plus que je ne vois pas ce que ça rajoute : les chiffres eux-mêmes me parlent plus que le crash d'un hypothétique avion rempli de chatons arc-en-ciel, et ce sans me donner envie de trucider l'auteur de l'article.

--
¹ Non, je n'ai pas cherché plus loin, et je n'ai pas spécialement envie de le faire pour cet article. Ça correspond à la louche mouillée à la jauge d'un avion de ligne moyen (et même plus), donc ça ne jure pas avec le propos que j'assassine. Et mon propos n'est pas axé sur les nombres, ce qui est justement ce qui m'emmerde.

Si votre compte PayPal est inactif pendant au moins 12 mois consécutifs, nous pouvons facturer des frais d'inactivité annuels. "Inactif" signifie que vous ne vous êtes pas connecté à votre compte PayPal ou que vous n'avez pas utilisé votre compte PayPal pour envoyer, recevoir ou virer de l'argent.

[…]

A3.13 Compte PayPal inactif

Les frais d'inactivité seront inférieurs au montant indiqué ci-dessous ou au solde restant sur votre compte.
Euro :12,00 EUR

Rien que ça. Bon, ça ne semble que s'appliquer pour les utilisateurs ayant un solde sur leur compte PayPal, mais quand-même. Des frais par ce que tu ne fais rien – et que tu ne coûte rien du coup, me faites pas rire à prétendre que quelques entrées dans une BDD a une incidence sur leur commerce.

Et même si c'est bien mentionné sur leur récapitulatif de mise à jour des conditions envoyé par mail, ça l'est de façon… très pudique :

Autres modalités juridiques – Nos droits – Frais d'inactivité

Nous introduisons des frais d'inactivité pour les comptes qui restent inactifs pendant au moins 12 mois consécutifs.

Via https://sebsauvage.net/links/?5goOXg

Edit : johndescs m'apprend qu'en France la loi autorise les banques à facturer des frais jusqu'à 30€ pour les comptes hors épargne réglementée (comme par exemple un simple compte courant)… youpi.

Un billet (de mon « Directeur ») contre la proposition présidentielle contre l'IEF, feat vous-voyez-qui (je ne le savais pas, il m'en a fait part ce matin) :]

Sinon, le contexte et pourri : PPL anti-IEF, #3 (?). Enfin je ne sais pas encore où ça en est, c'est peut-être encore des propos en l'air pour faire du buzz présidentiel, mais ça reste pourri, ineffectif (à priori les chiffres seraient maintenant de 8% de suspicions de raisons religieuses dans les enfants IEF en 2020), réducteur et oublieux même des situations où l'école républicaine est juste absente (écoles qui ferment par ce que villages trop petits, etc.). V3. Pour rappel, on a eu la même en 2014 et 2016… mais là ça a pour lui le buzz présidentiel en plus.

Ma réparation/galère de la semaine.

Même si les explications liées ici sont un peu approximatives à priori, ça n'en reste pas moins mon problème et la solution : active le memory remapping.

Donc j'ai récemment upgradé un ordi avec une ASUS P5B d'occasion car la CM précédente n'avait que 2 solts DDR2 plus un problème (de contrôleur mémoire ?) si plus de 3Go étaient installés (OS instable + erreurs memtest). À y repenser en écrivant ça, peut-être aurais-je dû jouer avec les voltages si jamais l'option existe ? Je n'y connais pas des masses.
Mais bref, j'ai donc une P5B, tout marche bien, sauf que j'installe 5Go de RAM (2×2 + 1×1) mais le BIOS et Linux n'en voient que 4Go. Oui, 4, y'en a un qui a disparu. Je sais que mes barrettes sont bonnes, je les ai toutes testées séparément. On notera ici que j'ai bien 4Go, pas seulement les 3 l'adressage en dessous des 3Go. Et si j'en met 6 (je n'avais juste pas la barrette sous la main au premier montage, maintenant je suis à 2×2 + 2×1), je n'en vois que 5.
Bref, il semble que sans le memory remapping, le BIOS cache le 4ème Go. Si je comprends bien, c'est normal pour éviter des conflits d'adresse avec les périphériques PCI, même si pour le moment je ne me suis pas documenté plus avant et ça reste donc un peu vague dans mon esprit.

Mais bref, en résumé, activer le remapping découvre la plage du 4ème Go, quelle que soit la quantité de RAM effectivement installée.

If using the SP Flash Tool on your favorite desktop GNU/Linux distro you're experiencing upload failures, like if the communication was broken a few seconds after it started, it's probably ModemManager's fault.
SP Flash Tool is communicating with the smartphones using a USB-modem-like technique (involving cdc_acm), and doing so leads to ModemManager to think it has to do its thing, actually interfering with the communication, leading to errors like that:

cdc_acm 1-1.2:1.1: failed to set dtr/rts

Fixing this is trivial: just disable ModemManager while using SP Flash Tool, and you should be good to go.

Cet abus des caractères Unicodes « esthétiques » est une très mauvaise chose, car toute sémantique disparaît de ce genre de « textes », ce qui a (entre autres) pour conséquence de rendre ces « textes » inaccessibles (illisibles par les utilisateurs de synthèses vocales, par exemple).

Avant toute chose, il faut que les données soient sémantiques, sinon elles ne veulent plus rien dire ; si les utilisateurs souhaitent réellement ce genre d'apparence (qui est discutable à mon avis, mais soit), il faut que la plate-forme propose ça de façon sémantique (dans ce cas, permettre de choisir la police).

Comme le dit Unicode lui-même : « To be used for mathematical variables where style variations are important semantically. For general text, use standard Latin and Greek letters with markup. »

• https://ban.netlib.re/shaarli/?do=rss . IPv6 capricieuse (ne fonctionnait pas en début d'aprem, fonctionne depuis le milieu d'aprem).

Hum, en fait ma v6 était cassée depuis une migration de mon « hébergeur » (wink wink à l'intéressé) et j'avais pas mis à jour ma zone. Maintenant c'est fait, ça devrait marcher. Par contre, je ne comprend pas comment tu pourrais avoir revu ma v6 fonctionner, elle était juste obsolète depuis un moment…

C'est vrai, mais il y a une limite à ce raisonnement : pour qu'un gus prenne sur lui l'étude d'un autre logiciel (libre ou pas, ce n'est pas mon sujet), il faut que celui-ci soit techniquement ou qualitativement supérieur à la norme. Or, winwin versus nux ou MS Office versus LibreOffice, y'a pas de différence quand t'es une secrétaire. Les deux vont faire chier (si, nux peut faire chier), les deux permettent de saisir le courrier demandé par le boss, sur les fonctions de base, GIMP apporte rien par rapport à Photoshop (et inversement), etc. C'est juste une guéguerre de chapelles (genre en vrai winwin, quand t'as compris la logique, que tu t'es formé, que t'as les bons outils d'administration et les bonnes pratiques, ça juste fonctionne aussi bien que nux, faut arrêter de mentir). Donc quand tu vois l'ordi comme un simple outil pour faire le taff demandé afin de toucher ton salaire, t'en a rien à faire d'une alternative tant que ça t'apporte rien, que ça ne te simplifie pas la vie, que ça ne te permet pas d'aller plus vite (et même, si le boss s'en rend compte et qu'il te file plus de taff, t'as rien gagné, donc, parfois, faut pas chercher à optimiser son temps), etc.

On est d'accord, l'ordinateur, le logiciel, ce sont des outils, et tant qu'ils font ce qu'on leur demande, pourquoi en changer ? Et même si j'ai pris le chapeau melon du libriste évangéliste pour rebondir sur ta remarque, ce n'est (plus) mon cas, et je n'ai plus l'énergie à mettre dans ce débat avec des gens désintéressés, que je ferais d'ailleurs probablement plus chier qu'autre chose.

Je voulais juste souligner que l'homme est une créature aux habitudes tenaces. Même une solution "techniquement ou qualitativement supérieur" sera souvent ignorée car demandera une réadaptation ; il faut donc que cette solution apporte vraiment quelque chose de tangible à l'utilisateur, et que l'utilisateur s'en rende compte pour qu'il décide de faire l'effort de s'adapter.
Et même si c'est un trait humain des fois déplorable, il a de très bonnes raisons d'être également, et je le vois (parfois à regret) sur moi aussi : je n'apprend pas à utiliser certains outils qui je sais me simplifierait certaines tâches, car je pense que le facteur "temps perdu avec ma technique actuelle"/"temps d'apprentissage de la solution" est trop bas pour moi -- souvent par ce que ce sont des tâches relativement rares. En résumé, des fois le pragmatisme de "juste arriver au résultat" gagne sur "choisir l'outil techniquement et qualitativement supérieur".

En gros, si je devais faire plus court : je ne blâme pas le salarié lambda, il a raison de ne pas se poser de questions, car, dans l'écrasante majorité des cas, ça lui apportera aucun avantage. C'est mon point de divergence avec toi.

En fait on ne diverge pas vraiment, moi non-plus je ne blâme pas cette personne. Je ne blâme pas grand monde en fait, les outils qu'ils choisissent restent leur problème. Ça me gène un peu plus quand on impose un outil privateur, voir pire, qu'on oblige à signer des CDG douteuses, ce qui arrive de plus en plus (et même moi j'en signe plus que de raison, soyons réaliste), mais je m'éloigne pas mal du sujet.

• "Faire du graphisme / de la retouche avec GIMP ?! Vous êtes sérieux ?! Vous avez déjà essayé, au moins ?! Faites pas chier, je veux mon Mac, mon Illustrator et mon Photoshop. Laissez-moi exercer mon métier !".

Bref, arrêtons d'utiliser nos arguments d'informaticiens (libre = pas sûr, pas pro, gnagna), le débat avec les utilisateurs n'est pas du tout sur ce terrain. On est sur de l'affect (comme la deuxième personne sus-citée qui se sentait clairement dévalorisée de ne pas avoir de MS Office : pour elle, le prix qu'on met dans son environnement de travail est un indicateur de l'attention qu'on lui prête, et quand t'es payée que dalle sans possibilité d'évolution, je comprend qu'on se rattache à ce genre de choses), sur un effet de réseau / marketing (premier point), et sur un manque d'alternatives crédibles sur certains métiers couplé à un melon des libristes qui sont convaincus que leur solution fait le taff sans connaître celui de la personne à laquelle ils proposent une alternative trop-trop meilleure.

Je vais faire mon libriste au melon démesuré, mais pour ce dernier point je pense que tu ne couvre pas l'ensemble du problème qui est aussi en grande partie que les "alternatives" libres ne sont pas le même logiciel, et ne s'uitlisent pas pareil. Au final la qualité de l'outil n'a que peu de rapport avec la question, la question est beaucoup que la personne est là pour faire son taf, pas pour prendre en main quelque chose de nouveau.

J'ai envie d'inventer un exemple : va proposer à un gars d'un studio d'animation qui utilise un autre outil de passer au logiciel 3D Blender, pourtant reconnu par de nombreux "pros" comme excellent (pour certaines tâches à minima) voir meilleur que les alternatives non-libres. Il n'aura très probablement ni le temps ni l'énergie d'apprendre ce nouvel outil, sauf s'il est lui-même intéressé et prend sur son temps perso.
Au final, c'est presque l'histoire du gars qui essaie d'attraper des poissons avec ses mains et qui n'a pas le temps d'apprendre à utiliser un filet par ce qu'il doit attraper des poissons (oui, c'est une caricature, et elle biaise mon propos :)

Il y a des choses intéressantes, mais il manque ce qui me semble le plus important pour toute idée de défensivité en (Ba)SH : le quoting. Il faut grosso modo quoter toutes les variables, sauf cas particuliers. Par exemple, le snippet tout simple utilisé pour obtenir PROGNAME a un comportement probablement inattendu si $0 contient des espaces :

# avec un script "/tmp/foo bar.bash" :
$ bash foo\ bar.bash 
foo
# avec un script "/tmp/a b c d.bash" :
$ bash a\ b\ c\ d.bash 
basename: extra operand ‘c’
Try 'basename --help' for more information.
# ouch.

Tout ça est dû au fait que sans quoting, l'expansion des variables est sujette au découpage de mots et l'expansion des chemins (pour le fun, essayer avec un script nommé *), ce qui est en général (très) dangereux. La solution est simple : quoter toutes les subsitutions (ce qui inclus $()), et par exemple le PROGNAME devient readonly PROGNAME=$(basename "$0"). On note ici la seule exception : l'assignation à une variable, qu'il n'est pas nécessaire de quoter, mais je recommanderais de toujours quoter, même ça, par ce que ça protège par exemple d'une erreur de refactoring.

Aussi comme le mentionne Sky dans son commentaire (au milieu du reste), utiliser set -e (avorter le script si une commande dont le retour n'est pas vérifié échoue) est une excellente pratique qui évite une cascade de problèmes lorsque une commande échoue de façon inattendue, que je recommande fortement pour tout nouveau script.
À noter cependant que ça ne marche pas dans tous les cas qu'on pourrait attendre, par exemple foo=$(false) ne terminera pas le script (car la commande est considérée comme vérifiée). J'ai l'habitude d'avoir une fonction du style die() { echo "$@">&2 ; exit 1; } et de vérifier également ce type d'assignation en utilisant foo=$(false) || die "failed to do something".

(Via https://sebsauvage.net/links/?u4kZDg)