🚲 Tanguy Ortolo a écrit 12690 commentaires

Et bien ça dépend de ce dont tu as besoin, mais typiquement tu as besoin du nom/de la ligne de commande

name="$(cat "/proc/${pid}/comm")"
command="$(cat "/proc/${pid}/cmdline")"

Sous Debian, ok. Mais je veux dash pour ses performances, et en plus sous Gentoo ce n’est pas conseillé de changé la cible de /bin/sh pour autre chose que bash.

Ça c'est un réglage local, pas un truc qui devrait nécessiter une adaptation des scripts. Mauvaise distribution, changer distribution.

1: essayer de parser la sortie de 'ps' de manière fiable et on en reparle de la soi-disant supériorité du texte comme sérialisation.

C'est peut-être parce que ps n'est pas fait pour ça, encore que ça ne me semble pas bien difficile en précisant qu'on ne veut pas d'en-tête et qu'on veut des colonnes bien précises. Mais bon, si j'ai besoin d'informations sur un processus dans un script, j'irai plutôt chercher dans /proc.

Mettons que nous avons monté un système de fichiers btrfs sur /mnt

Pour info, ce genre d'utilisation de /mnt est caduque depuis, pfiou, au moins cinq ans. Aujourd'hui, /mnt est dédié aux montages temporaires, typiquement : voyons voir ce qu'il y a dans cette image ISO. Les montages permanents doivent se faire soit dans un répertoire logique, dans ton cas probablement /var/local/backup, soit dans un répertoire lié au médium de stockage, lorsqu'il s'agit par exemple d'un point de montage pour le lecteur optique, indépendamment de son contenu qui peut varier /media/cdrom.

#!/bin/dash

En pratique, on fait appel à un outil très particulier pour réaliser la glue : le shell (bash pour respecter la norme de fait, dash pour respecter la norme des pénibles — ou ses perf. —, zsh pour les vrais hommes).

Non ! Dash doit être vu comme une implémentation d'un shell Unix standard, qui fournit peu de chose de plus. Bash est une autre implémentation, qui fournit pas mal de choses en plus. Mais coder pour Dash, c'est une erreur, si ton code tourne sous Dash il tournera sous n'importe quel implémentation de shell standard, y compris Bash, et il est inutile de cibler /bin/dash, est nuisible dans la mesure où cela empêcherait sans raison de le lancer sur un système qui ne fournit pas Dash.

Bref : tu as presque de bonnes habitudes, continue comme ça mais cible /bin/sh.

Et on voit poindre des tas d'améliorations possibles. Là, le "OnCalendar=--* 04:00:00" n'est qu'une des syntaxes possibles, assez proche de celle de la cron, mais bien plus lisible, merci les "-" et les ":" pour enfin distinguer date et heure. Mon principal reproche à ce stade : ça ne gère pas encore les timezones, un point indispensable dans mon activité pro. Mais rajouter demain une clause "TimeZone" ne semble pas insurmontable.

Bof, ce serait plus lisible ainsi : OnCalendar=*-*-* 04:00:00+02:00 (pour un décalage horaire fixe) ou OnCalendar=*-*-* 04:00:00/Europe/Paris (pour un fuseau horaire politique avec potentiellement un changement d'heure).

Affiche le styliste (F11). Dérive un style de caractère par défaut, intitule-le d'un nom correspondant au sens de ce que tu veux (genre : important), règle-le pour qu'il utilise le couleur de police de ton choix. Recommence pour chacun des styles que tu veux créer.

Si la notion de style logique ne te dit rien, il va d'abord falloir apprendre de bonnes notions de bureautique. Pour de vrai j'entends, pas comme la merde qu'on apprend à l'école hein.

Déjà, la bonne façon de faire ça est de créer des styles logiques, dans ton cas des styles applicables au caractère (et non au paragraphe), portant non pas des noms de couleurs, mais les noms correspondant à ce que représentent ces couleurs (disons par exemple important, à retenir, ou je ne sais quoi). Ensuite, afficher en permanence le styliste (F11), puis l'utiliser en double-cliquant sur le style pour l'appliquer à la sélection.

À mon avis, uniquement au texte, mais je n'en suis absolument pas sûr : à vérifier.

Ben non.

Ouais, on dit ça maintenant, mais j'attends de voir. Avec Lennart, je me méfie. (Mais si, je vous assure, je ne fait que maintenir udev dans le même dépôt que systemd mais ça restera tout à fait indépendant, je vous jure. Mais bien sûr, et maintenant ?)

git ne propose pas la déduplication des données (enfin je ne pense pas), fonction assez importante ici.

Si, et heureusement : un gestionnaire de versions qui copierait intégralement chaque version gaspillerait pas mal de place. Dans ses concepts de base, Git peut être vu comme gardant chaque version intégralement, mais s'y ajoute une couche de déduplication, même interne aux fichiers.

Qu'est-ce que c'est qu'un séparateur de chiffres ? L'espace ou le point qu'on met en français pour séparer les tranches de milliers à des fins de lisibilité ?

Tiens, il serait sans doute pertinent de suggérer comme amélioration au paquet grub-efi dans Debian d'ajouter une option de configuration initiale permettant d'installer une copie de l'image principale comme boot/bootARCH.efi pour ce genre d'implémentation merdique.

Par contre une toute dernière question, le fichier "grubx64.efi" (ou "bootx64.efi") est-il définitif (aka crée lors de l'installation et ne bouge plus) ou régénéré à chaque mise à jour de GRUB ou du noyau (auquel cas cette manœuvre sera à répéter à chaque mise à jour sous peine de plus pouvoir démarrer) ?

C'est l'image principale de GRUB, donc elle est générée à chaque nouvelle version de GRUB. Elle est en revanche indépendante de la version du noyau et de la configuration de GRUB (dans le sens où on peut changer la configuration de GRUB sans avoir à modifier son image principale).

Une partition système EFI étant en FAT, et FAT étant un système de fichiers déficient, on ne peut malheureusement pas faire de lien symbolique...

EFI ayant été défini... par Intel, c'est du joli, qu'ils fassent de la merde avec leur propre spec...

Pas bête comme comparaison. La limite, c'est que le bricolage, c'est assez largement pour soi-même ou essentiellement les gens très proches, évidemment.

Tiens, je n'y avais jamais pensé mais c'est évident, maintenant que tu le fais remarquer. Pour en revenir à la contribution au logiciel libre, c'est dans ce cas un véritable sacrifice pour quelqu'un qui serait adepte du kopimisme.

Ça doit être du même style que pour le zonage des DVD : VLC, enfin la libdvdcss, sait très bien craquer les clefs et déchiffrer les DVD de toutes les zones, mais si ton lecteur optique refuse de lire un disque, il n'y a rien à faire...

Beuh, pourquoi ça ? OpenTTD tourne très bien sous Debian, quel que soit l'âge de l'ordinateur.

Channel, à ma connaissance, ça désigne un canal, une chaîne, un salon de discussion ou une voie de communication. Jamais vu d'autre traduction.

Un dispositif de pointage qui permette de rester longtemps sur un point précis, par exemple. Pour faire un truc pareil avec le pointeur d'une Wii, bon courage, ça va en faire un jeu de musculation au passage.

Pas de l'éviter s'il s'arrête en passant instantanément de sa vitesse initiale à une vitesse nulle, se transformant ainsi en obstacle fixe, ce cas n'existant pas dans la réalité.

Au temps pour moi, en fait si, mais doit être considéré comme négligeable : c'est le cas où le véhicule situé devant lâche une caisse. Une vraie caisse, j'entends, qui va rebondir un peu mais s'arrêter assez rapidement.

Les problèmes concernant le véhicule situé devant toi, si. Or la distance de sécurité concerne justement le véhicule situé devant.

Pour les autres problèmes, tels que les obstacles fixes, éventuellement cachés par un virage ou je ne sais quoi, la distance de sécurité est hors de propos.

Non, ça ne fait pas partie de la distance de sécurité, en tout cas pas de la définition qu'en donnait mon Code Rousseau. Le rôle de la distance de sécurité est d'éviter de percuter le véhicule situé devant s'il doit freiner en urgence. Pas de l'éviter s'il s'arrête en passant instantanément de sa vitesse initiale à une vitesse nulle, se transformant ainsi en obstacle fixe, ce cas n'existant pas dans la réalité.

Tout le monde connais la règle, sur autoroute c'est 2 bandes blanches ça correspond à 100m.

Non, c'est faux, ça ce n'est qu'un slogan pratique et plus prudent que nécessaire. Je me souviens très bien de m'être fait cette remarque en révisant pour passer l'examen du code de la route :

1. la distance de sécurité est définie celle parcourue en deux secondes, histoire d'avoir le temps de réagir (normalement une seconde) ;
2. à 130 km/h, cela fait 72 mètres ;
3. la longueur des bandes blanches et des intervalles qui les sépare est assez bien définie mais la somme de deux bandes blanches et d'un intervalle donne plus que ces 72 mètres.