wismerhill a écrit 2608 commentaires

Tu mélange les acronymes.
FAT (File Allocation Table) est bien un système de fichiers, qui est donc (généralement) stocké dans une partition.

Tente un ping, tu ne devrais pas avoir de réponses du host

Pas forcément, il me semble que le message d'erreur est le même quand le port 22 est bloqué.

Ça devrait être effectivement le cas quand tu produit le document en une fois.
L'exemple donné ressemble à un cas où chaque page aurait été produite séparément, puis le tout combiné dans un PDF unique sans retravailler le contenu.

Mauvais exemple, c'est le shell qui va résoudre le glob (si le fichier existe), et sudo verra /sbin/shutdown

Pas besoin de copier la commande, il suffit de faire sudo /sbin/./shutdown et ça passera ;-)

Le con est vraiment con, il croit que c'est nous le con alors qu'en fait c'est lui…

Référence obligatoire à l'Effet Dunning-Kruger (où on parle d'incompétence, plutôt que de stupidité)

Attention, là tu risque d'avoir les fans de starwars souffrant de dysorthographie sur le dos.

Ça se fait avec l'option Ciphers de ssh (voir man ssh_config).
Dans le fichier de configuration de ssh, tu peux combiner ça avec l'option Host pour définir des options à appliquer quand tu te connecte à un serveur en particulier.

Alors tu peux préparer les commandes dans un fichier, une par ligne, ça fait techniquement un script que tu peux lance avec bash, comme ça un fois lancé il va enchainer les fichiers et tu peux le laisser tourner pendant la nuit.
À coup de copier/coller, ça peut aller assez vite.

Je recommande de mettre un "set -e" au début du fichier, pour qu'il s'arrête si une des commandes échoue (sinon ça risque de passer inaperçu).

Alors ce qu'il te faut, c'est faire une boucle, pour appliquer la même commande à plusieurs fichiers.
Supposons que tes vidéos sont (éventuellement via des liens symboliques) dans le répertoire orig, et que tu veux les résultats dans le répertoire dest, ça donnerait:

for f in orig/*.mp4 ;do
  ffmpeg -i "$f" {options ici} dest/"${f##*/}"
done

Ça te donnera les fichiers recodés, avec le même nom, dans le répertoire dest.

ça peut vite être galère en Bash si tu veux contrôler que le fichier existe

Mauvais exemple, c'est une des choses les plus faciles à faire avec bash:

[[ -e $fichier ]] && exit 1

(et non, ce n'est pas une erreur qu'il n'y ait pas de guillemets autours de la variable)

Ajouter un message d'erreur est laissé comme exercice au lecteur ;-)

Ça n'a rien de nouveau, ça existait déjà dans KDE 4 (peut-être même 3, je ne me souviens plus), je l'utilise depuis des années.
Peut-être que c'est maintenant activé par défaut?

Un rideau de plomb aurait été plus efficace.

Il y a 2nd quadrant (2ndquadrant.com), qui est un gros contributeur à PG, et a des bureaux en Europe.

Un tmpfs ne consomme que l'espace effectivement pris par les fichiers qu'il contient (c'est à dire la colonne "used").
Ce qui est indiqué dans la colonne "size" est seulement la taille maximum qu'il acceptera de stocker (par défaut c'est 50% de la RAM).
Donc, dans l'exemple que tu donne il y a à peine 107 MiO utilisés dans /run, le reste est négligeable.

C'est probablement possible de re-configurer le système pour s'en passer, ça veut dire que les données correspondantes seront stockées sur la partition racine, s'il s'agit d'un disque dur ça aura un impact sur les performances, s'il s'agit d'un SSD ça aura un impact sur sa longévité. Et il faudra que tu mette en place un script pour vider ces répertoires à l'extinction, pour ne pas avoir des fichiers qui y trainent, qui pourraient faire des choses bizarres au prochain démarrage.

Donc, à moins que tu aie absolument besoin de chaque MiO de RAM, c'est beaucoup de complications pour un résultat inférieur.
Dit autrement, si ton serveur n'est pas déjà à 100% de RAM utilisée par les vrai programmes (pas les caches), ne perd pas ton temps à ça.

sympa le script qui fait le dump pour l'effacer ensuite…

Note qu'il ne l'efface que si le dump a réussi ;-)

Xephyr est une alternative plus moderne à Xnest, ça peut faire une différence pour certains logiciels s'ils ont besoin de certaines fonctionnalités récentes (comme xrandr).

Dans mageia, il est dans le paquet bind-utils.

il n’y a pas vraiment de raison d’utiliser 0 * * * * plutôt que @hourly.

Certes, mais par contre si on a plusieurs scripts à lancer toutes les heures (jours, semaines, mois), c'est intéressant de mettre autre chose que 0 pour qu'ils ne se lancent pas tous au même moment.

Ça me fait penser au plugin fsview pour konqueror (l'«ancien» programme à tout faire de KDE, qui est toujours maintenu):
https://docs.kde.org/stable5/en/konqueror/konqueror/view-extensions.html

J'en ai trouvé une capture d'écran là
https://www.coagul.org/drupal/publication/outils-pour-analyser-l%E2%80%99espace-disque-et-visualiser-loccupation-dun-disque
(c'est vieux, mais il n'a guère évolué depuis)

C'est parce que ce n'est pas une fonction propre de nautilus, c'est une fonction de base du composant arborescence (qu'on retrouve d'ailleurs de façon semblable dans la plupart des toolkits graphiques "classiques").

Donc, comme déjà écrit par d'autres, le problème n'est pas l'écran mais la carte graphique.

Avec un ordinateur suffisamment puissant, on peut tout à fait avoir un débit en USB2 de 45Mo/s soutenu.
Mais là on parle d'un vieil eeePc …

Certes, mais l'écran en question sera toujours connecté (donc probablement détecté, s'il n'est pas complètement mort). Et puis, si tu branche un écran externe, il y a un écran de connecté ;-)

Quand on en est à faire autant de modifications sur une machine aussi ancienne, autant racheter d'occasion une machine moins vieille, ça ne coutera probablement pas plus cher (si on trouve une bonne ocaz) et sera probablement plus performant.