wismerhill a écrit 2598 commentaires

Et pour que le test soit vraiment significatif, il faut démarre sur un système live, pour que le SSD ne doit pas sollicité par le système pendant le test.

à l'époque il ne gérait pas le TRIM des SSD

Tu parle d'une époque lointaine, car quand j'ai acheté mon premier SSD il y a cinq ans il le gérait déjà.

Et pour explorer ce qui est disponible dans la distribution, il y a Mageia app db:
https://madb.mageia.org/

Peux-tu te vanter de n'utiliser aucun anglicisme ?

Il y a peut-être moyen de s'en sortir en remarquant que beaucoup de mots de langlais actuel viennent du vieux français (voir du latin) ;-)

En mode texte, oui.
Mais là il parle d'une session graphique, et il donne lui-même le nom du programme dans sa question, c'est gnome-terminal.

Non, l'émulateur de terminal lance un programme (bash (ou un autre shell) par défaut) et te permet d'interagir avec lui, donc quand tu tape une commande c'est à bash que tu demande de l'exécuter, l'émulateur de terminal intercepte ce qui est écrit sur la sortie standard/d'erreur et l'affiche dans sa fenêtre.

Encore personne qui ait proposé emacs ou vi?

Heu, c'est la page de manuel, le lien donné par damaki pointe vers manpages.debian.org

C'est verbeux en effet, mais si le but est de produire un XML structuré différemment (ou du HTML), ce dernier peut être inclus directement mélangé dans les balises XSLT, ce qui est beaucoup plus pratique que dans n'importe quel autre language, avec la garantie de générer un XML syntaxiquement valide.

J'ai tiqué sur cette remarque:

Un peu comme la catastrophe du XSLT pour le XML.

En quoi XSLT est-il une catastrophe?
C'est très pratique pour transformer un document XML en autre chose, ou pour en extraire des données.

Ça ne fonctionne pas avec firefox 60esr :-(

Le disque dur sur lequel est enregistré la base de données n'est pas indestructible, ta définition est trop stricte pour être utilisable, aucun support de stockage n'est infaillible.

Donc dans ton cas, si tu effaces volontairement tes données, ta base de donnée peut toujours être considérée comme durable. Ton expérience ne dit rien de la durabilité de ta base de données.

En quoi est-ce différent avec un ramdisk?
Quand le ramdisk est supprimé, la base de données l'est également, ça ne change pas le fait que, tant que le ramdisk (et donc la base de données qu'il contenait) existe, le fonctionnement de la base de données peut être transactionnel, tu n'aura pas des données à moitié enregistrées.

Donc, d'après ton raisonnement, si je crée une base de données avec PostgreSQL, je fais quelques opérations dedans, puis je supprime la base de données, mes opérations n'étaient pas transactionnelles car ma base de données n'était pas durable?

Wget fait également du téléchargement récursif (en suivant les liens dans les pages HTML), ce qui peut être utile pour faire un miroir d'un site (quoiqu'un outil spécialisé comme httrack donnera un meilleur résultat, surtoout s'il y a des redirections).

Et wget gère aussi le ftp.

Quoique l'exemple qu'il donne, c'est exactement le cas d'utilisation de paste.

Non, justement, systemd ne fait pas de redirection, donc en écrivant ça le script va obtenir en argument les valeurs: ">" "/home/pi/dem.log" "2>&1"
Si tu veux faire des redirections, c'est dans le script lui-même qu'il faut le faire (ou encapsuler dans un script qui ne sert qu'à ça).

Mais dans l'exemple donné, ça ne sert à rien, systemd redirige automatiquement les deux sortie du programme vers le journal, qu'oçn peut ensuite consulter avec journalctl, et les dernière lignes sont directement fournies quand on fait un systemctl status.

Donc, il suffit d'exécuter le script, sans rien d'autre.

C'est parce que tu force l'exécution (dans le ExecStart de ton unité) avec /bin/sh, alors que ton script est écrit pour bash ([[ est un syntaxe spécifique à bash).

Et de toute façon, essayer de faire des redirections dans l'ExecStart de l'unité systemd ne fonctionnera pas, il faut le faire dans le script lui-même.
Je te recommande de lire les pages de manuel systemd.unit et systemd.service

C'est grace aux cgroup.
Systemd crée (par défaut) un cgroup pour chaque service, il sait donc quels sont tous les processus qui ont été lancé par le service. Si ce dernier ne s'arrête pas correctement (typiquement grace à la commande ExecStop), tu peux faire un systemctl kill qui enverra un signal à tous les processus du cgroup associé au service.

Il y a de moins en moins de petits SSD, les fabricants préférant grossir les chiffres en stockant davantage de bits par cellules (un 128 Go en MLC devenant un 256 Go en TLC).

Non, la MLC c'est deux bits par cellule de flash, et la TLC trois, donc si tu veux garder le même nombre de cellules, un 128 GO en MLC deviendrait un 192 GO en TLC.

J'ai aussi un clavier et une souris unifying, ça fonctionne. Il y a depuis peu un outil libre pour configurer ces périphériques (apairage, mises à jour…)

Tant qu'à faire, on peut le citer, il s'agit de solaar.
Et il n'existe pas "depuis peu", au contraire le dernier release date de 2013.

Je pense que ce comportement n'est volontairement pas défini, et il faut s'attendre à des résultats différents selon les version de bash, voir selon la libc à laquelle il est lié.

Modifier un script en cours d'exécution est généralement une mauvaise idée.
Si tu dois absolument faire ta modification avant que l'exécution précédente soit terminée, il vaut mieux faire une copie et travailler sur celle-là pendant que l'exécution précédente se termine.

Ou alors il faut les faire bouillir, ça les ramolli.

500GB = 512 000MB

Seulement s'il s'agit de GiB et MiB ;-)

Et puisque dans awk, la regex est appliquée par défaut à $0:

xrandr --listactivemonitors|awk '/0:/{print $4}'

on aurait donc pu compter en base 12 des le debut plutot qu'en base 10

C'était le cas

Il me semble que le système décimal s'est imposé avec l'arrivée des chiffres indo-arabes.