tag:linuxfr.org,2005:/users/roc_pierreLinuxFr.org : les contenus de Pierre Roc2014-09-17T20:16:33+02:00/favicon.pngtag:linuxfr.org,2005:Diary/352192014-09-04T01:06:36+02:002014-09-04T01:06:36+02:00Sur systemd, btrfs & coLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<h2 class="sommaire">Sommaire</h2>
<ul class="toc">
<li>
<a href="#de-la-technique">De la technique</a><ul>
<li><a href="#avant-de-commencer">Avant de commencer</a></li>
<li><a href="#btrfs">BTRFS</a></li>
<li><a href="#udev--systemd">Udev + systemd</a></li>
</ul>
</li>
<li>
<a href="#de-la-politique">De la politique</a><ul>
<li><a href="#unix-un-outil-par-t%C3%A2che-vraiment-kiss">UNIX : un outil par tâche, vraiment KISS ?</a></li>
<li><a href="#des-erreurs-de-jeunesse">Des erreurs de jeunesse</a></li>
<li><a href="#et-si-c%C3%A9tait-politique">Et si c’était politique</a></li>
</ul>
</li>
</ul><p>Bien le bonsoir,</p>
<p>Histoire de changer d’air, je vais parler un peu de bidouilles qu’il est possible de réaliser sous GNU/Linux avec des outils modernes. Il ne s’agit pas de tutoriel, ni de manuel au sens classique des termes mais d’un exemple pratique et volontairement simplifié à l’extrême, une manière de partager des astuces, écrit au kilomètre, que chacun pourra adapter & compléter à sa convenance. Parce que c’est ce que j’aime sous GNU/Linux, le côté bidouille, avec une documentation foisonnante pour réaliser facilement des tâches complexes, les automatiser, etc. Je finirai par un peu de politique (vous inquiétez pas, il ne sera pas question de communistes mangeurs d’enfants pour une fois).</p>
<h2 id="de-la-technique">De la technique</h2>
<h3 id="avant-de-commencer">Avant de commencer</h3>
<p>Pré-requis : se débrouiller en shell, savoir deux–trois p’tits truc sur les systèmes GNU/Linux, utiliser btrfs comme système de fichier et systemd (le reste appartenant à la préhistoire de l’informatique).</p>
<p>Documentation : le <a href="https://fr.wikipedia.org/wiki/World%20Wide%20Web" title="Définition Wikipédia">World Wide Web</a>, <a href="https://fr.wikipedia.org/wiki/man_(Unix)" title="Définition Wikipédia">man_(Unix)</a>.</p>
<h3 id="btrfs">BTRFS</h3>
<p><a href="https://fr.wikipedia.org/wiki/btrfs" title="Définition Wikipédia">btrfs</a> est un système de fichiers nouvelle génération, utilisant massivement le <em>copy-on-write</em>. Il gère les sous-volumes (<em>subvolume</em>), les instantanés (<em>snapshot</em>), le raid (en cours d’implémentation si je ne m’abuse), le copie de fichier (essayez donc <code>cp --reflink=auto</code> sur un gros fichier, c’est magique…), et j’en oublie sûrement… ah oui ! la possibilité de faire un <em>copy-on-write</em> d’un système de fichier en lecture seule : utile pour des liveCD par exemple.</p>
<p>Aujourd’hui ce qui me préoccupe, c’est la création d’un script shell/dash (pour les performances optimales et l’occupation mémoire minimale) de sauvegarde utilisant des outils extrêmement simples et exploitant btrfs. (Attention tout de même : btrfs n’est stabilisé que sur des versions récentes du noyau et l’utiliser pour des sauvegardes se fait à vos risques & périls.)</p>
<p>Mettons que nous avons monté un système de fichiers btrfs sur <code>/mnt</code>. La première étape est la création d’un sous-volume <code>backup</code> :</p>
<pre><code class="bash">sudo btrfs subvolume create /mnt/backup</code></pre>
<p>Puis un autre qui se trouvera lui-même dans backup :</p>
<pre><code class="bash">sudo btrfs subvolume create /mnt/backup/latest</code></pre>
<p>Ce sous-volume contiendra toujours la sauvegarde la plus récente de nos données personnelles via un simple :</p>
<pre><code class="bash">rsync -axv --inplace --delete <span class="nv">$HOME</span> /mnt/backup/latest</code></pre>
<p>Tout ceci est bien beau, mais qu’en est-il si je veux retrouver un fichier effacé depuis un mois ? Très simple ! Au moment de créer la sauvegarde, juste après que la commande rsync ait fini, on exécute :</p>
<pre><code class="bash">sudo btrfs subvolume snapshot -r /mnt/backup/latest /mnt/backup/<span class="sb">`</span>date +<span class="s1">'%Y-%m-%d'</span><span class="sb">`</span></code></pre>
<p>Et automagiquement un instantané de <code>latest</code> est créé à la date du jour ! Grâce au <em>copy-on-write</em>, on a une véritable sauvegarde incrémentale : tout <code>rsync</code> dans <code>latest</code> n’enregistrera que les modifications nécessaires, limitant la place mémoire occupée physiquement sur le disque dur, et on conservera les données des instantanés du passé.</p>
<p>On peut raffiner ces quelques commandes et obtenir un script <code>/usr/local/bin/backup</code> du genre :</p>
<pre><code class="bash"><span class="c">#!/bin/dash</span>
mount /mnt/backup <span class="o">||</span> <span class="nb">exit </span>1
<span class="nv">H</span><span class="o">=</span>/home/pierre_roc
<span class="nv">cmd</span><span class="o">=</span><span class="s2">"rsync -axv --inplace --delete"</span>
<span class="nv">$cmd</span> --filter<span class="o">=</span><span class="s2">"merge $H/.rsync.pattern"</span> <span class="nv">$H</span> /mnt/backup/latest<span class="nv">$H</span>
<span class="o">[</span> -d /mnt/backup/<span class="sb">`</span>date +<span class="s1">'%Y'</span><span class="sb">`</span> <span class="o">]||</span>btrfs subvolume snapshot -r /mnt/backup/latest /mnt/backup/<span class="sb">`</span>date +<span class="s1">'%Y '</span><span class="sb">`</span>
<span class="o">[</span> -d /mnt/backup/<span class="sb">`</span>date +<span class="s1">'%Y-%m'</span><span class="sb">`</span> <span class="o">]||</span>btrfs subvolume snapshot -r /mnt/backup/latest /mnt/backup/<span class="sb">`</span>date + <span class="s1">'%Y-%m'</span><span class="sb">`</span>
<span class="o">[</span> -d /mnt/backup/<span class="sb">`</span>date +<span class="s1">'%Y-%m-%d'</span><span class="sb">`</span> <span class="o">]||</span>btrfs subvolume snapshot -r /mnt/backup/latest /mnt/backup/<span class="sb">`</span>dat e +<span class="s1">'%Y-%m-%d'</span><span class="sb">`</span>
<span class="k">for</span> i in <span class="sb">`</span>seq <span class="m">0</span> 99<span class="sb">`</span>
<span class="k">do</span>
<span class="o">[</span> -d /mnt/backup/<span class="sb">`</span>date --date<span class="o">=</span><span class="s2">"year ago $i month ago"</span> +<span class="s1">'%Y-%m'</span><span class="sb">`</span> <span class="o">]&&</span>btrfs subvolume delete /mnt/backup/<span class="sb">`</span>date --date<span class="o">=</span><span class="s2">"year ago $i month ago"</span> +<span class="s1">'%Y-%m'</span><span class="sb">`</span>
<span class="k">done</span>
<span class="k">for</span> i in <span class="sb">`</span>seq <span class="m">0</span> 999<span class="sb">`</span>
<span class="k">do</span>
<span class="o">[</span> -d /mnt/backup/<span class="sb">`</span>date --date<span class="o">=</span><span class="s2">"month ago $i day ago"</span> +<span class="s1">'%Y-%m-%d'</span><span class="sb">`</span> <span class="o">]&&</span>btrfs subvolume delete /mnt/backup/<span class="sb">`</span>date --date<span class="o">=</span><span class="s2">"month ago $i day ago"</span> +<span class="s1">'%Y-%m-%d'</span><span class="sb">`</span>
<span class="k">done</span>
umount /mnt/backup</code></pre>
<p>À condition d’exécuter le script tous les jours, on obtient un instantané par jour, avec un roulement : les instantanés de plus d’un mois sont effacés, sauf celui qui a été réalisé en premier chaque mois ; les instantanés de chaque mois sont conservés, sauf s’ils ont plus d’un an ; enfin le premier instantané de chaque année est quand à lui conservé indéfiniment. On obtient par exemple (j’avoue ne pas être très régulier dans la sauvegarde de mes données) :</p>
<pre><code>ls /mnt/backup
2012/ 2013/ 2013-11/ 2014/ 2014-07/ 2014-08-26/ 2014-08-27/ 2014-09/ 2014-09-03/ latest/
</code></pre>
<p>Là où ce genre de besoins nécessitait des outils complexes, pas toujours très performants, btrfs permet de résoudre avec brio la problématique posée par un système de sauvegarde, avec une simplicité enfantine pour qui sait manier un peu le shell. Et ce sans absolument rien sacrifier en performances.</p>
<p>Passons à <a href="https://fr.wikipedia.org/wiki/systemd" title="Définition Wikipédia">systemd</a> maintenant, car il faut bien automatiser le lancement du script, disons tous les jours à 4h du matin. Par exemple. Avec Cron, c’était imbittable, avec systemd c’est un jeu d’enfant ! Tout d’abord nous allons créer un “timer”, c’est-à-dire une unité qui permet d’activer un service selon un calendrier donné. Pour cela il suffit de créer un fichier <code>/etc/systemd/system/backup.timer</code> :</p>
<pre><code>[Timer]
OnCalendar=*-*-* 04:00:00
[Install]
WantedBy=timers.target
</code></pre>
<p>Puis un autre fichier qui doit impérativement porter le même nom et dont seule l’extension change <code>/etc/systemd/system/backup.service</code> :</p>
<pre><code>[Unit]
After=local-fs.target
[Service]
ExecStart=/usr/local/bin/backup
</code></pre>
<p>Et on active le bazar via :</p>
<pre><code>sudo systemctl start backup.timer
</code></pre>
<p>C’tout. Systemd, plutôt que de vous obliger à réinventer la roue, vous permettra de vérifier très aisément si votre timer a bien exécuté le programme, si le script s’est bien déroulé, etc. grâce aux commandes (entre autres) :</p>
<pre><code>systemctl status backup.service
systemctl status backup.timer
systemctl list-timers
</code></pre>
<p>Cool non ? Ça a tout de même plus de gueule qu’un script init à la syntaxe horrible, et qui change en fonction de la distribution pour ne rien arranger, tout en proposant plus de fonctionnalités sans coût supplémentaires (journal, raffinement dans les modalités d’exécution par systemd, etc.).</p>
<h3 id="udev--systemd">Udev + systemd</h3>
<p>Un autre usage que je propose est l’automatisation du téléchargement des photos depuis un appareil. En gros : je branche mon appareil, j’attends 30s, un “dong” retentit (le détail qui tue), et je n’ai plus qu’à débrancher mon appareil. Tout est fait automatiquement.</p>
<p>On suppose que vous avez déjà un script de téléchargement des photos dans <code>/usr/local/bin/down_photo</code>, on peut utiliser rsync (sans l’option --delete cette fois-ci), ou alors, en guise d’exemple, je présente un script plus raffiné :</p>
<pre><code class="bash"><span class="c">#!/bin/dash</span>
<span class="nv">H</span><span class="o">=</span>/home/pierre_roc
mount /mnt/olympus <span class="o">||</span> <span class="nb">exit </span>1
<span class="o">[</span> -d <span class="nv">$H</span>/photographie/darktable <span class="o">]</span> <span class="o">||</span> <span class="nb">exit </span>1
<span class="k">for</span> i in /mnt/olympus/DCIM/*/*.ORF
<span class="k">do</span>
<span class="nv">j</span><span class="o">=</span><span class="sb">`</span>basename <span class="nv">$i</span><span class="sb">`</span>
<span class="nv">d</span><span class="o">=</span><span class="sb">`</span>exiftool <span class="nv">$i</span> -DateTimeOriginal<span class="p">|</span>sed <span class="s1">'s/^Date\/Time Original\s*: \([0-9]*\):\([0-9]*\):.*$/\1-\2/1'</span><span class="sb">`</span>
<span class="nb">echo</span> -n <span class="s2">"$d/$j"</span>
<span class="k">if</span> <span class="o">[</span> ! -d <span class="nv">$H</span>/photographie/darktable/<span class="nv">$d</span> <span class="o">]</span>
<span class="k">then</span>
<span class="nb">echo</span> -n <span class="s2">" mkdir"</span>
mkdir <span class="nv">$H</span>/photographie/darktable/<span class="nv">$d</span>
chown pierre_roc:pierre_roc <span class="nv">$H</span>/photographie/darktable/<span class="nv">$d</span>
<span class="k">fi</span>
<span class="k">if</span> <span class="o">[</span> -f <span class="nv">$H</span>/photographie/darktable/<span class="nv">$d</span>/<span class="nv">$j</span> <span class="o">]</span>
<span class="k">then</span>
<span class="nb">echo</span> <span class="s2">" pass"</span>
<span class="k">else</span>
<span class="nb">echo</span> <span class="s2">" down"</span>
cp <span class="nv">$i</span> <span class="nv">$H</span>/photographie/darktable/<span class="nv">$d</span>/
chmod a-x <span class="nv">$H</span>/photographie/darktable/<span class="nv">$d</span>/<span class="nv">$j</span>
chown pierre_roc:pierre_roc <span class="nv">$H</span>/photographie/darktable/<span class="nv">$d</span>/<span class="nv">$j</span>
<span class="k">fi</span>
<span class="k">done</span>
umount /mnt/olympus
<span class="nv">count</span><span class="o">=</span>0
mount /mnt/olympus
<span class="k">for</span> i in /mnt/olympus/DCIM/*/*.ORF
<span class="k">do</span>
<span class="nv">j</span><span class="o">=</span><span class="sb">`</span>basename <span class="nv">$i</span><span class="sb">`</span>
<span class="nv">d</span><span class="o">=</span><span class="sb">`</span>exiftool <span class="nv">$i</span> -DateTimeOriginal<span class="p">|</span>sed <span class="s1">'s/^Date\/Time Original\s*: \([0-9]*\):\([0-9]*\):.*$/\1-\2/1'</span><span class="sb">`</span>
<span class="k">if</span> diff <span class="nv">$i</span> <span class="nv">$H</span>/photographie/darktable/<span class="nv">$d</span>/<span class="nv">$j</span>
<span class="k">then</span>
rm <span class="nv">$i</span>
<span class="nv">count</span><span class="o">=</span><span class="k">$((</span>count+1<span class="k">))</span>
<span class="k">else</span>
<span class="nb">echo</span> <span class="s2">"error: $j"</span> ><span class="p">&</span>2
rm <span class="nv">$H</span>/photographie/darktable/<span class="nv">$d</span>/<span class="nv">$j</span>
<span class="k">fi</span>
<span class="k">done</span>
umount /mnt/olympus
<span class="nb">echo</span> <span class="nv">$count</span> pictures downloaded
mpv -quiet <span class="nv">$H</span>/documents/ding.mp3 >/dev/null</code></pre>
<p>Comme vous pouvez le constater, c’est assez complexe car je classe mes photos dans des dossiers, en fonction du mois de la prise de vue, grâce aux méta-données <a href="https://fr.wikipedia.org/wiki/exif" title="Définition Wikipédia">exif</a>.</p>
<p>Pour info. voici la ligne /etc/fstab qui va bien :</p>
<pre><code>/dev/disk/by-id/usb-OLYMPUS_XZ-1_AAN547126-0:0-part1 /mnt/olympus vfat noauto 0 0
</code></pre>
<p>car il est primordial de ne pas être dépendant d’un nom de périphérique du style <code>/dev/sdXN</code>, trop volatile.</p>
<p>Reste plus qu’à lancer automatiquement le script. C’est là où udev entre en jeu. Il y a là deux petits truc à savoir si on ne veut pas galérer. En premier, faites les essais sans photographies importantes sur votre appareil car j’ai constaté des comportements très suspects avec des pertes de données, et écrivez vos règles udev avec votre périphérique débranché pour commencer. En second, on va se servir de systemd : c’est le comportement recommandé pour des versions récentes d’udev qui a été intégré à systemd il y a peu. C’est ce dernier point qui m’a posé problème car il rend caduque certains documents qu’on trouve sur le web.</p>
<p>Tout d’abord on branche l’appareil photo, on repère le périphérique /dev/sdXN qui représente la partition de sa carte mémoire et on exécute :</p>
<pre><code>udevadm info -ap `udevadm info -q path /dev/sdXN`
</code></pre>
<p>Vous obtiendrez une sortie bien bien moche (note : il semblerait que la commande <code>udevadm info</code> soit spécifique à Gentoo, la variante la plus courante devrait être <code>udevinfo</code>).</p>
<p>La sortie commence par le <em>device</em> représentant la partition, et remonte l’arbre des périphériques :</p>
<pre><code>looking at device '[...]sdXN':
[...]
SUBSYSTEM=="block"
ATTR{size}=="15515648"
ATTR{partition}=="1"
looking at parent device [...]:
[...]
looking at parent device [...]:
SUBSYSTEMS=="scsi"
[...]
ATTRS{model}=="XZ-1 "
looking at parent device [...]:
[...]
</code></pre>
<p>Attention, il y a deux écueils à éviter. Il ne faut choisir qu’un, et un seul, <em>parent device</em> et vous y tenir pour ce qu’y suit : en règle général vous choisirez celui qui identifie à coup sûr votre appareil (le XZ-1 en ce qui me concerne, un excellent objectif ceci dit en passant :) ). Ensuite il faut bien différencier la partition sur la carte mémoire (sdXN) de la mémoire entière (sdX), donc bien veiller à sélectionner un attribut qui permettent de distinguer les deux : <code>ATTR{partition}</code> joue ce rôle.</p>
<p>Nous voilà fin prêt pour écrire la règle udev dans <code>/etc/udev/rules.d/10-local.rules</code> (pensez à débrancher votre appareil avant) :</p>
<pre><code>ACTION=="add",SUBSYSTEM=="block",ATTR{size}=="15515648",ATTR{partition}=="1",SUBSYSTEMS=="scsi",ATTRS{model}=="XZ-1",ENV{SYSTEMD_WANTS}="down_photo.service"
</code></pre>
<p>Le tout sur une seule ligne, impérativement. Une règle udev c’est quelque chose d’extrêmement simple : des tests et des assignations, si les tests sont vrais, udev effectuera les assignations. Ici, si le périphérique est branché (<code>ACTION=="add"</code>) et qu’il correspond aux critères permettant d’identifier l’appareil photo et sa carte que je ne change jamais d’où le critère de taille (cf. la sortie de la commande précédente), alors on affecte l’unité systemd <code>down_photo.service</code> à la propriété <code>SYSTEMD_WANTS</code>.</p>
<p>Ce dernier point mérite un commentaire. Avant on pouvait lancer directement un script grâce à RUN+="mon_script". Mais ce comportement n’est pas recommandé car la gestion de l’exécution du script par udev est extrêmement sommaire et pose de plus en plus de problèmes (l’environnement y est extrêmement limité). Passer par systemd permet de profiter de ses fonctionnalités avancées : l’appel non bloquant contrairement à udev et, entre autres, les logs. En effet vous aurez remarqué que j’ai plein de <code>echo</code> dans mon script : ils seront redirigés automatiquement vers le journal de systemd.</p>
<p>Il ne reste plus qu’à créer l’unité systemd <code>/etc/systemd/system/down_photo.service</code>. Très simple là encore :</p>
<pre><code>[Unit]
Description=Download from XZ-1
After=local-fs.target
[Service]
ExecStart=/usr/local/bin/down_photo
</code></pre>
<p>C’tout. Vous avez votre système de téléchargement des photos entièrement automatisé. :)</p>
<h2 id="de-la-politique">De la politique</h2>
<p>Systemd est l’occasion de trolls à profusion, et je voulais apporter ma petite contribution.</p>
<h3 id="unix-un-outil-par-tâche-vraiment-kiss">UNIX : un outil par tâche, vraiment KISS ?</h3>
<p>La théorie veut que le système UNIX utilise des outils simples, réalisant des tâches simple, et qu’on assemble le tout pour réaliser des tâches complexes.</p>
<p>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).</p>
<p>Et c’est là que ça se gâte.</p>
<p>Parce que le shell, dans le genre usine à gaz qui fait plein de choses, et toutes très mal…</p>
<p>Ça se pose là.</p>
<p>Le shell c’est un langage de programmation… Enfin, il paraît ! Syntaxe horrible &co, on écrit pas de gros programmes avec ça, à moins d’être un peu masochiste sur les bords.</p>
<p>Le shell c’est une interface homme–machine… Pourquoi pas ! C’est encore là où il se défend le mieux. Je ne comprends plus l’intérêt d’une interface graphique dans énormément de mes usages, où j’ai l’impression d’être totalement bridé. Mais dès lors qu’on sort du texte, que le travail nécessite beaucoup de manipulations manuelles, y’a plus personne… du coup les opérations à réaliser sont un sous-ensemble relativement restreint de tâches automatiques et donc de tout ce qu’il est possible de faire avec un ordinateur. Pt’êt que chez les dinosaures ça suffit, mais pour une utilisation un poil moderne de l’outil informatique, force est de constater que l’interface en ligne de commande est insuffisante.</p>
<p>Enfin, le shell utilise les tubes pour la glue entre les programmes… Bon ça va bien cinq minutes mais on se retrouve très, mais alors très, très vite limité, même pour du traitement de texte basique (d’où awk,sed&co, même la substitution de texte est une “basherie” !).</p>
<p>Pourquoi parler de tout ça ? Parce que j’ai le sentiment que Systemd loin de trahir la philosophie UNIX, reproduit ce comportement : un outil central (mieux pensé que le shell tout de même) qui permet de gérer un ensemble d’outils très simples (ici mes petits scripts maison) qui communiquent entre eux (ou pas), sans avoir besoin de réinventer la roue (des logs? systemd le fait pour vous).</p>
<h3 id="des-erreurs-de-jeunesse">Des erreurs de jeunesse</h3>
<p>Curieusement les débats autour de systemd sont rarement techniques. Pourtant, il y a quelques petits ratés, et je vais en citer un, très factuel, très terre à terre. Ça change. Pour une fois. Peut-être est-ce lié à ma distribution (Gentoo) auquel cas sentez-vous libres de (me) corriger dans les commentaires.</p>
<p>Les développeurs, s’arrogeant le droit de prendre des décisions à ma place, ont décidé que la taille du journal devait être fonction de l’espace mémoire disponible sur le système (un pourcentage je crois bien).</p>
<p>Cela a tout de la fausse bonne idée.</p>
<p>Premièrement. On ne sait jamais combien d’espace mémoire il nous reste <em>réellement</em>. C’est particulièrement pénible sous certaines conditions d’utilisation où on est amené à faire transiter beaucoup de données en mémoire. Vous croyez qu’il vous reste plus que 10 Go, vous virez 10 Go, et vous vous retrouvez avec 15 Go de libre au lieu de 20, vous remettez 10, mais l’espace libre n’a diminué que de 5. L’arithmétique à la sauce systemd : c’est un concept…</p>
<p>Secondement et beaucoup plus grave. Si plusieurs programmes s’avisent de faire de même, cela pose une grande question métaphysiques du style : qui va vampiriser l’espace disponible, combien occupe chaque programme ? En effet mettons qu’on ait deux programmes A & B qui décident d’occuper 50 % de l’espace libre, avec 20 Go de dispo. Je vous passe le cas d’une <em>race condition</em> où les deux programmes évaluent l’espace disponible à 20 Go, avant d’engager chacun le remplissage à hauteur de 10 Go… <em>A</em> voyant 20 Go libres, remplit à hauteur de 10 Go, <em>B</em> arrive après et remplit à hauteur de 5 Go (50 % de 20-10 Go). <em>A</em> repasse après, voit qu’il n’y a plus que 5 Go de libre + 10 Go qu’il occupe ce qui donne 15 Go, divisé par deux, soit 7,5 Go : <em>A</em> se dit “oulala j’occupe 10 Go c’est beaucoup trop, faut que je libère un peu… À l’itération suivante c’est B qui se dit “cool maintenant y’a plus d’espace vais pouvoir charger un peu la mule”. Et ainsi de suite. Au final, en fonction des itérations, des politiques suivies par chacun des programmes et de l’historique d’utilisation de votre mémoire, vous ne saurez jamais combien chacun occupe. C’est la fiesta sur votre disque dur, chacun n’en fait qu’à sa tête, les ressources sont gaspillées, mal réparties et j’en passe.</p>
<p>C’est un comportement particulièrement irresponsable de la part d’un développeur, d’une distribution, et d’un administrateur que d’amener à avoir des programmes qui s’adaptent d’eux-même en fonction des ressources globales du système et applique une politique d’utilisation dans leur coin. Ça marche pas. Tout le monde sait bien que les politiques d’accès aux ressources <s>économiques</s>informatiques doivent s’établir de manière globale et non pas laissées à la discrétion des <s>individus–entreprises</s>programmes. (Toute ressemblance avec des système économiques tels que libéralisme et socialisme est purement fortuite, et indépendante de ma volonté, car je l’avais promis.)</p>
<p>Un petit passage par <code>/etc/systemd/journald.conf</code> et la page man associée résoud fort heureusement le problème. Mais ça vous fait tout drôle la première fois de voir ce truc occuper des Go.</p>
<h3 id="et-si-cétait-politique">Et si c’était politique</h3>
<p>Ce qui m’a surpris dernièrement (qu’à moitié ceci dit), c’est d’apprendre que l’auteur de systemd avait une vision politique, au sens noble du terme, c’est-à-dire une vision à long terme, je veux dire un <em>projet</em>, de ce que devrait être le système Linux. Il suffit de lire un peu son <a href="http://0pointer.net/blog/">blog</a> pour que ça saute aux yeux. En passant outre les qualités diplomatiques de Lennart Poettering — je suis tout cela de très loin, mais j’ai cru comprendre qu’il a tendance à imposer ses solutions (litote) —, je me demande s’il ne s’agit pas de cela au fond. C’est une ouverture que je propose. Honnêtement je ne compte pas répondre moi-même à cet épineux problème (à savoir l’avenir de Linux). Comme je l’ai dit, ce qui m’intéresse avec ce système, c’est la possibilité de mettre les mains dans le cambouis. Et contrairement à l’avis majoritaire sur systemd, je trouve que ce système d’init offre plus d’opportunité, car il est moins rebutant que ce qui existait avant : franchement, je ne sais pas ce qu’il en est de votre côté, mais un script d’init Gentoo/OpenRC/Bash, ça fait pas envie.</p>
<p>Le fait est que je vois d’un très mauvaise œil une quelconque démocratisation de GNU/Linux, car j’ai le sentiment que c’est de cela qu’il s’agit en toute dernière analyse. Outre les contraintes techniques que cela nécessite, c’est aussi une question d’écosystème. Toujours en terme de bidouillage, il est plus facile de trouver une réponse sur le web à un problème précis lorsque vous avez 90 % de contenus très techniques, plutôt que 90 % de questions posées par des neuneus, sans réponse bien évidemment. Et cet écosystème ne peut pas ménager le chou et la chèvre : à un moment donné il faudra faire un choix, qui nous sera très certainement imposé d’ailleurs.</p>
<p>Restera BSD.</p><div><a href="https://linuxfr.org/users/roc_pierre/journaux/sur-systemd-btrfs-co.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/103187/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/roc_pierre/journaux/sur-systemd-btrfs-co#comments">ouvrir dans le navigateur</a>
</p>
Pierre Rochttps://linuxfr.org/nodes/103187/comments.atomtag:linuxfr.org,2005:Diary/328922012-07-27T17:52:49+02:002012-07-27T17:52:49+02:00Voltaire n’est pas mon ami<p>C’est la journée des journaux aux blagues. :)</p>
<p>
<a href="http://www.youtube.com/watch?v=9MCU7ALAq0Q">http://www.youtube.com/watch?v=9MCU7ALAq0Q</a>
</p>
<p>Bon visionnage.</p><div><a href="https://linuxfr.org/users/roc_pierre/journaux/voltaire-n-est-pas-mon-ami.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/94986/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/roc_pierre/journaux/voltaire-n-est-pas-mon-ami#comments">ouvrir dans le navigateur</a>
</p>
Pierre Rochttps://linuxfr.org/nodes/94986/comments.atom