Jean-Philippe Garcia Ballester a écrit 1099 commentaires

je me suis souvenu que tu m'avais déjà parlé d'inotify et que tes commentaires proposait même d'utiliser systemd pour automatiser le lancement de services suite aux changements de fichier

Sauf erreur, je crois que tu fais référence à mon commentaire dans le journal inotify. Ca me fait un peu rire, parce que à la base je l'avais surtout écrit pour troller les anti-systemd :)

Une vieille installation manuelle de phpBB qui trainait, complètement troué. Quelqu'un en profité pour lancer un script qui envoyait des tas de paquets UDP sur une IP donnée, un DDOS sauf erreur.

Je pense que Menton faisait référence à la ville, donc son exemple est pertinent.

C'est aussi que tu ne fais pas de distinction entre une surveillance généralisée par un gouvernement et une surveillance au cas par cas sur décision de justice.

Tout pareil. Tes journaux sont très intéressants, surtout continue !

?

Rien ne t'empêche d'écrire une bibliothèque avec juste les fonctions utilisées par systemd et de patcher systemd pour se lier à ta bibliothèque.

Je rajoute aussi que systemd n'est pas un système d'init. C'est un ensemble de logiciels bas niveau (tout comme kde est un ensemble de logiciels graphiques). Du coup, oui, il est moins complexe à comprendre que ce qu'il remplace.

Dit moi, tu comprends mieux comment fonctionne un système d'init (si on peut encore appeller cela comme ça) aujourd'hui (systemd upstart), ou avant, à l'époque de SysvInit/runit/etc.. ? Moi c'était avant.

Si tu parles du fonctionnement interne du système d'init (le code), alors ça ne change rien, je ne le connais pas plus maintenant qu'avant.

Si tu parles de comment utiliser le système d'init, alors je trouve ça plus facile maintenant. Un tas de scripts d'init étaient imbitables, différent d'une distribution à une autre, non-documentés…

C'est vachement plus facile pour moi aujourd'hui d'écrire un script d'init que ça ne l'était avant, et je peux le faire avec plus de fonctionalités.

Moi je me souviens très bien de l'arrivée de pulseaudio, qui a foutu en l'air plein de truc qui marchaient; perso j'étais sous arts (artsd) à l'époque, j'avais tout qui marchait, (dont l'usage à travers de réseau), et lorsque pulseaudio a été imposé par la distrib, ça a tout cassé.

Sauf erreur de ma part, aRts a cessé d'être développé en 2004 (due to a variety of fundamental development and technical issues, cf wikipedia), et pulseaudio a été installé par défaut sur Ubuntu (une des premières distribs à l'avoir installé par défaut) à partir de 2008.

Et puis faire marcher l'ensemble des applis Linux à l'époque de aRts, il fallait quand même drôlement s'accrocher, avec des couches de compatibilité dans tous les sens, parce qu'entre oss, alsa, aRts, et esd, c'était pas folichon.

Et pulseaudio fait bien plus que ce que faisait aRts (une gestion simple du multi carte-son, ce qui est loin d'être un cas particulier aujourd'hui).

A titre personnel je ne suis pas nostalgique de l'avant PA en tout cas …

Je me rappelle encore de l'époque où il fallait écrire un fichier de config pour dmix à la main… Et même avec ça on avait pas le quart des fonctionnalités de PA.

C'est de plus en plus difficile de savoir ce que fait sa machine, mais c'est aussi de plus en plus facile de l'utiliser.

C'est une supposition, mais je pense que PA utilise seulement l'API bas-niveau de Alsa pour pouvoir faire ce qu'il veut faire.

Non, c'est incron et inotify-cxx. inotify tout court, c'est une API du noyau (des appels systèmes) qui n'est pas développée par la personne qui tient le site dont il est question.

Merci pour le commentaire (ce n'est pas le seul dans le genre) très révélateur de la manière de (non) penser des anti-systemd.

Les généralisations outrancières, c'est le mal.

Bonsoir,

c'est une affaire de goûts, mais la syntaxe de systemd me semble au contraire plus explicite (dans la configuration incron, les champs de sont pas explicites, il faut connaître la syntaxe du fichier pour le comprendre).

Elle n'est en tous cas pas plus obscure que celle d'incron (puisque les deux sont très bien documentées).

De plus systemd permet un peu plus de choses (démarrage conditionnel, dépendances, cgroups, etc).

Je croyais que c'était Tor Tue.

À noter aussi que les unités systemd de type path utilisent inotify. On peut donc utiliser systemd en lieu et place d'incron. Pour l'exemple donné ici, demander à lancer automatiquement la commande postalias lorsque /etc/aliases est modifié (totalement non testé mais c'est l'idée) :

le fichier /etc/systemd/system/aliases.path

[Path]
PathModified=/etc/aliases
[Install]
WantedBy=multi-user.target

le fichier /etc/systemd/systemd/aliases.service

[Service]
ExecStart=/usr/sbin/postalias

Il est aussi possible d'utiliser ces fonctionnalités sans accès root en mettant les unités dans le dossier $XDG_CONFIG_HOME/systemd/user/*.

Des infos plus récentes que le bugzilla de firefox peuvent être trouvées ici : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718434#239

Tout à fait, c'est beaucoup mieux, merci !

Sauf erreur de ma part, si on ne l'utilise ni ne la transforme, on ne peut l'utiliser que pour chauffer, n'est-ce pas ?

Sauf erreur de ma part, si on l'utilise pour chauffer, on l'utilise. /o\

Je voulais bien sûr dire, si on en la stocke ni ne l'utilise :)

Donc à part la cuisson des aliments qui ne représente pas une consommation d'énergie très élevée, l'énergie propre dont tu parles sert à se chauffer lorsqu'il fait chaud ?

On pourrait chauffer avec l'énergie solaire même lorsqu'il fait froid.

Tu peux en dire plus ? Des exemples ou des sources ?

Tout à fait. D'après man initrd, le chargeur de démarrage charge l'initrd en mémoire dans /dev/initrd, puis lors du démarrage du noyau, celui-ci décompresse et copie le contenu dans /dev/ram0 puis libère le contenu de la mémoire de /dev/initrd.

Pourquoi dois-tu patcher ceci :
[…]
sachant que /var/run est un lien symbolique vers /run ?

Comme l'a supposé Misc au dessus, /var/run n'est un lien symbolique vers /run que plus tard.

Et pourquoi donc supprimer cette ligne ?

La création du dossier /run/plymouth ne fonctionne pas dans le script install, car cela créé un dossier /run/plymouth dans l'initrd, mais un tmpfs est monté sur /run, donc ce qu'il y a dans /run dans l'initrd est caché.

Il faut donc créer le dossier au boot, donc dans l'unité systemd.

Merci pour ton article, ça donne une vue d'ensemble plus précise de ce qu'il est nécessaire de savoir en plus pour mettre en place un initrd

Il faut espérer que les bug reports soient corrigés et qu'utiliser systemd dans l'initrd se fasse en 5 minutes en changeant juste les hooks.

une histoire de la Bretagne durant cette période (en BD… hum… chacun ses armes),

Je veux bien le titre :)

Alors pas tout à fait. Il y en a quand même une qui est parfaitement propre, abondante et gratuite, à condition qu'on l'utilise telle-quelle sans chercher à la stocker ni à la transformer : le soleil bien sûr.

Sauf erreur de ma part, si on ne l'utilise ni ne la transforme, on ne peut l'utiliser que pour chauffer, n'est-ce pas ?

Donc à part la cuisson des aliments qui ne représente pas une consommation d'énergie très élevée, l'énergie propre dont tu parles sert à se chauffer lorsqu'il fait chaud ?

Il y a la géothermie aussi, qui n'est pas pour source le soleil.