wismerhill a écrit 2598 commentaires

Si tu veux que la barre de défilement ne disparaisse plus, c'est l'option widget.gtk.overlay-scrollbars.enabled à mettre à false.

Il y a aussi l'option widget.non-native-theme.scrollbar.size.override qui permet de définir la largeur (en pixels) sans changer le style.

En fait, il y a une série d'options widget.non-native-theme.scrollbar.* qui permettent d'ajuster l'affichage de cette barre de défilement.

Avec LUKS, il est possible de faire une sauvegarde de l'en-tête (avec la commande cryptsetup luksHeaderBackup).
Cette sauvegarde doit bien entendu être conservée dans un endroit bien sécurisé, sinon c'est elle le maillon faible.

Aussi, LUKS prévoit plusieurs slots de clés dans son en-tête (je ne sais plus si c'est 4 ou 8). Chaque slot contient la clé de chiffrement du périphérique, mais elle-même chiffrée avec un mot de passe (éventuellement) différent.
L'usage de base est de permettre à plusieurs personnes de partager un même périphérique sans devoir partager le mot de passe, mais ça peut aussi servir à se prémunir d'une corruption d'un slot en utilisant d'emblée plusieurs (éventuellement avec le même mot de passe).

Note que pour être tout à fait équivalent à la version avec grep, il faudrait plutôt utiliser -name '*org?gnome?Evince?desktop*', puisque le grep recherche le pattern n'importe où dans la ligne, et que le . correspond à n'importe quel caractère.
Mais c'était probablement un bug dans la version original ;-)

Gsmartcontrol est une interface graphique au-dessus de smartctl, qui est plus accessible aux non spécialistes.

La commande xwininfo (qui n'est probablement pas installée par défaut) permet d'avoir des informations sur une fenêtre en particulier.
(je ne sais pas quel est l'équivalent pour wayland, si c'est ça qui est utilisé)

Malheureusement, ce n'est pas tout à fait équivalent, car si, par exemple, le echo "a" échoue, tu va exécuter l'alternative, ce que ne fait pas un if else.

$ a=1
$ if [ $a -eq 1 ] ;then ls --bad; else echo oups; fi
ls: unrecognized option '--bad'
Try 'ls --help' for more information.
$ { [ $a -eq 1 ] && ls --bad ; } || echo oups
ls: unrecognized option '--bad'
Try 'ls --help' for more information.
oups

Pour exécuter une commande à intervalle régulier, le bon outil est cron.

S'il est important de pouvoir limiter le nombre d'exécution, tout en se prémunissant des déconnexions, alors il faut lancer la commande dans une session screen ou tmux.

man flock pour une solution plus robuste (en particulier la section d'exemples avec le boilerplate pour qu'un script se lock lui-même).

Je constate que mon compte a été créé en juin 2001, j'avais alors la moitié de mon age actuel…

Juste pour information (car quand on travail seul en local, on utilise les outils qu'on préfère), c'est tout à fait faisable avec subversion, sans mettre en place un serveur.
Il suffit d'initialiser un dépôt dans un répertoire quelconque, puis d'en faire un checkout avec une URL de type file:///

Avec plasma, le successeur s'appelle kscreen, s'il est installé il devrait être disponible (mais peut-être désactivé par défaut) dans les entrées de la boite de miniatures, mais peut également être lancé manuellement.

Pourquoi tu fais écouter ton serveur SSH sur le port 80?
C'est prendre le risque qu'il y ait de l'inspection de paquets…

Avec le port 443, c'est prendre moins de risques.

Non, quel que soit le port utilisé, ssh parle le ssh, et donc sera forcément crypté, le choix du port n'a pas d'incidence sur le risque (mis à part que le port standard est une cible plus évidente).

Le seul problème potentiel (qui me vienne à l'esprit) à détourner un port bien établi, tout particulièrement celui de http(s), c'est qu'il pourrait y avoir dans le chemin quelque chose qui décide que si ce qui passe sur le port 80 ne ressemble pas à du trafic http, alors il le bloque (possible aussi pour le port 443, à l'établissement de la connexion).

Il y a aussi le fait que, OK, sur un serveur, c'est douteux, mais pour une machine portative, nettement moins, et j'imagine que la même méthode s'applique.

Sauf que la situation est très différente.

Dans les serveurs, les disques ou SSD sont généralement accessibles en façade, sans ouvrir le capot. Donc voler un disque en vitesse est effectivement beaucoup plus crédible qu'emporter le serveur complet.

Alors que pour un ordinateur portable, c'est plus simple d'emporter le tout, plutôt que l'ouvrir à la volée.
Donc s'il suffit de l'allumer pour déverrouiller les partitions cryptées, autant considérer qu'il n'est pas protégé contre le vol de données.
Pour ce cas de figure, il vaut mieux avoir un support physique quelconque, qui contient la clé de déchiffrement, mais qu'on garde sur sois.

Si tu parle de l'image qui illustre cet article, comme le dit son libellé, c'est un "dessin de la NASA".
Les seules "images réelles" de trous noir (où celui-ci n'est pas beaucoup plus petit qu'un pixel de l'image) sont celles produites par l'Event Horizon Telescope.

Si tu veux voir l'image réelle qui a permit de déduire l'existence de ce trou noir, voir par exemple l'article d'ars technica:
https://arstechnica.com/science/2023/04/black-hole-is-soaring-between-galaxies-leaving-stars-in-its-wake/
(ne pas s'arrêter à la même vue d'artiste qui introduit l'article)
où on apprend qui plus est que l'affaire est loin d'être entendue.

La probabilité qu’un truc pareil arrive.

… n'est pas si faible.

Il y a des centaines de milliards de galaxies dans l'univers observable (estimation par extrapolation), qui sont généralement groupées en amas et super-amas, dans lesquels les distances entre galaxies sont assez faibles (relativement à leurs tailles).
Donc les collisions de galaxies sont fréquentes, c'est même le scénario principal pour expliquer la formation de grandes galaxies.

Et couple de trous noirs super-massifs, suite à une collision, doit avoir initialement une orbite assez large, qui peut mettre plusieurs milliards d'années avant de conduire à une fusion, ec qui laisse largement le temps à une troisième galaxie d'arriver, et de former un système triple.

Donc, un trou noir super-massif éjecté de sa galaxie n'est probablement pas un cas unique.

Ce qui est exceptionnel, c'est de réussir à le détecter, car sans matière (fournie par sa galaxie hôte) pour l'alimenter, il est vraiment noir.
Ici, justement, il a été détecté parce qu'il rencontre des nuages de gaz inter-galactiques qui le rendent visible.

J'imagine que c'est détecté comme une souris, et ça fonctionne comme une souris.

Pas tout à fait.

Une souris est un dispositif de pointage relatif.
Donc, l'information qu'elle envoi à l'ordinateur, c'est une distance et une direction (probablement codés sous forme d'offsets des coordonnées X/Y)

Un écran tactile est un dispositif de pointage absolu.
Lui, il envoi à l'ordinateur la position où on a touché (ou plusieurs positions, s'il est multi-touch).
Du coup, pour que a fonctionne correctement, il faut que l'ordinateur sache à quelle partie de la zone d'affichage correspond l'écran tactile.
(voir mon autre réponse concernant xinput)

Si tu utilise Xorg, l'option --map-to-output de la commande xinput permet d'indiquer à Xorg par rapport à quel sous-ensemble (identifié par la sortie vidéo qui lui correspond) de l'écran virtuel le périphérique de pointage absolu doit être calibré.
Par contre, je n'ai pas trouvé de moyen d'en faire une configuration permanente, et il faut le ré-exécuter chaque fois que la configuration de l'affichage change (donc même avec un script de démarrage, c'est difficile).

Du coup, le plus "pratique" est de mettre ça dans un script associé à une combinaison de touches.

À combiner avec les options --enable/--disable (et faire un --disable au démarrage) si on veut éviter d'"avoir le curseur qui clique n'importe où si on touche l'écran par erreur.
(certaines personnes ont une fâcheuse tendance à tapoter sur l'écran pour indiquer de quoi ils parlent)

La commande parallel a aussi une option -0/--null (mais par défaut, c'est les retours à la ligne, pas les espaces)

Voir cet article de pour la science d'il y a deux mois qui explique justement le fonctionnement des caloducs.

Certes, mais il y a souvent différents modes de mise en veille, et les plus efficaces nécessitent peut-être un pilote sur mesure pour pouvoir être activé. Par exemple pour désactiver certains périphériques inutiles.

Probablement un pilote de gestion d'énergie sur mesure, pré-installé par le constructeur sous windows, et qui n'a pas d'équivalent pour linux (ou autre).
Ou alors ça existe, mais il faut l'installer manuellement.
Ou encore il faut un paramétrage sur mesure, et il faut chercher dans les recoins d'internet si quelqu'un a déjà trouvé les paramètres qui fonctionnent.

Moi aussi je parle des cycles d'écriture, et les spécifications, ce sont des moyennes.
Ce n'est pas parce qu'un SSD est prévu pour 600 ré-écritures qu'il va tomber en panne à la 601, dans certains cas ce sera avant, dans d'autres ça tiendra plus longtemps (si on est prêt à prendre le risque).

À moins qu'il soit question des SSD maudits de chez intel qui se suicidaient au moment où ils atteignaient leur limite de garantie, la limite (effectivement bien réelle) du nombre d'écriture des cellules de mémoire flash est une moyenne.

Les constructeurs garantissent un certain nombre de téra-octets écrits (TBW), ça veut dire que si ton SSD tombe en panne avant d'avoir atteint cette limite ils te le rembourseront (ou remplaceront). Mais le SSD peut tout à fait être encore pleinement fonctionnel après avoir dépassé cette limite. C'est même probable, car les constructeur calculent leur limite de garantie pour ne pas devoir en remplacer trop.

D'ailleurs, différents constructeurs avaient revu récemment à la baisse leur garantie (trop optimistes), à cause d'une cryptomonnaie qui faisait des écritures intensives, et trop de SSD tombaient en panne avant d'avoir dépassé le nombre d'années de garantie.

Ah, je n'avais pas fait attention que tu essaie de regarder dans le fichier maps, je pensais que tu regardais directement la ligne de commande.
Alors ça ne fonctionnera probablement jamais.
Ce ne sont pas des bibliothèques au sens du format elf, ce sont des classes java qui sont chargées (typiquement) depuis des fichiers jar, qui sont de simples archives zip, et je pense que la JVM ne garde pas les fichiers ouverts en permanence (et ne sont peut-être pas du tout mappés en mémoire).