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.
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.
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).
À 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) :
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.
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 ?
Je trouve dommage d'opposer GPG et OTR, car la différence va au-delà de l'échange de clé.
Je ne pense pas que OTR soit plus sûr que GPG, en fait comme le dit ton lien, ils offrent des fonctionnalités différentes et sont destinés à des usages différents.
Extrait de la page wikipedia :
The primary motivation behind the protocol was providing deniability for the conversation participants while keeping conversations confidential, like a private conversation in real life, or off the record in journalism sourcing. This is in contrast with other cryptography tools that produce output which can be later used as a verifiable record of the communication event and the identities of the participants.
Oui. Il y a des gens qui cherchent à volontairement limiter leur salaire (et donc leur consommation), pour avoir un mode de vie soutenable et essayer de tendre vers une société égalitaire.
En même temps, la définition de KISS, c'est un peu flou, non ? En quoi c'est KISS de lancer un interpréteur d'un langage turing-complet à chaque fois que tu veux démarrer un nouveau service ?
[^] # Re: Mwai
Posté par Jean-Philippe Garcia Ballester (site web personnel) . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 2.
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.
[^] # Re: Mwai
Posté par Jean-Philippe Garcia Ballester (site web personnel) . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 5.
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).
[^] # Re: Mwai
Posté par Jean-Philippe Garcia Ballester (site web personnel) . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 5.
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.
[^] # Re: Mwai
Posté par Jean-Philippe Garcia Ballester (site web personnel) . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 5.
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.
[^] # Re: Incron
Posté par Jean-Philippe Garcia Ballester (site web personnel) . En réponse à la dépêche Exploiter inotify, c’est simple. Évalué à 5.
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.
[^] # Re: Mwai
Posté par Jean-Philippe Garcia Ballester (site web personnel) . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 10.
Les généralisations outrancières, c'est le mal.
[^] # Re: Et systemd ?
Posté par Jean-Philippe Garcia Ballester (site web personnel) . En réponse à la dépêche Exploiter inotify, c’est simple. Évalué à 4.
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).
[^] # Re: Fausse impression de sécurité ?
Posté par Jean-Philippe Garcia Ballester (site web personnel) . En réponse au journal Un si joli nom. Évalué à 5.
Je croyais que c'était Tor Tue.
# Et systemd ?
Posté par Jean-Philippe Garcia Ballester (site web personnel) . En réponse à la dépêche Exploiter inotify, c’est simple. Évalué à 10.
À 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
le fichier /etc/systemd/systemd/aliases.service
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/*.
[^] # Re: CA-CERT ?
Posté par Jean-Philippe Garcia Ballester (site web personnel) . En réponse à la dépêche Firefox : dites 33, comme chez le docteur. Évalué à 5.
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
[^] # Re: /var/run -> /run
Posté par Jean-Philippe Garcia Ballester (site web personnel) . En réponse à la dépêche Aujourd’hui c’est déjà demain : systemd dans l’initrd sous Arch Linux. Évalué à 2.
Tout à fait, c'est beaucoup mieux, merci !
[^] # Re: La seule énergie propre : celle que l'on ne consomme pas
Posté par Jean-Philippe Garcia Ballester (site web personnel) . En réponse au journal Douche froide pour la fusion. Évalué à 2.
Je voulais bien sûr dire, si on en la stocke ni ne l'utilise :)
Tu peux en dire plus ? Des exemples ou des sources ?
[^] # Re: Chargement de l'initrd
Posté par Jean-Philippe Garcia Ballester (site web personnel) . En réponse à la dépêche Aujourd’hui c’est déjà demain : systemd dans l’initrd sous Arch Linux. Évalué à 2.
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
.[^] # Re: /var/run -> /run
Posté par Jean-Philippe Garcia Ballester (site web personnel) . En réponse à la dépêche Aujourd’hui c’est déjà demain : systemd dans l’initrd sous Arch Linux. Évalué à 4.
Comme l'a supposé Misc au dessus, /var/run n'est un lien symbolique vers /run que plus tard.
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.
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.
[^] # Re: Ah ouais, quand même...
Posté par Jean-Philippe Garcia Ballester (site web personnel) . En réponse au journal Enfin une ministre de la Qulture qui comprend l'internet !. Évalué à 2.
Je veux bien le titre :)
[^] # Re: La seule énergie propre : celle que l'on ne consomme pas
Posté par Jean-Philippe Garcia Ballester (site web personnel) . En réponse au journal Douche froide pour la fusion. Évalué à 1.
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 ?
[^] # Re: La seule énergie propre : celle que l'on ne consomme pas
Posté par Jean-Philippe Garcia Ballester (site web personnel) . En réponse au journal Douche froide pour la fusion. Évalué à 5.
Il y a la géothermie aussi, qui n'est pas pour source le soleil.
# La seule énergie propre : celle que l'on ne consomme pas
Posté par Jean-Philippe Garcia Ballester (site web personnel) . En réponse au journal Douche froide pour la fusion. Évalué à 10.
Tout est dans le titre :)
[^] # Re: Et BSD ?!
Posté par Jean-Philippe Garcia Ballester (site web personnel) . En réponse au journal Aujourd'hui c'est déjà demain : systemd dans l'initrd sous Arch Linux. Évalué à 10.
Expliciter une blague, c'est vraiment moche !
[^] # Re: Gajim et PGP
Posté par Jean-Philippe Garcia Ballester (site web personnel) . En réponse à la dépêche Gajim 0.16 sort de terre. Évalué à 4.
Je trouve dommage d'opposer GPG et OTR, car la différence va au-delà de l'échange de clé.
Je ne pense pas que OTR soit plus sûr que GPG, en fait comme le dit ton lien, ils offrent des fonctionnalités différentes et sont destinés à des usages différents.
Extrait de la page wikipedia :
[^] # Re: Sponsoring
Posté par Jean-Philippe Garcia Ballester (site web personnel) . En réponse au journal La publicité "propre" ça existe ?. Évalué à 1.
Oui. Il y a des gens qui cherchent à volontairement limiter leur salaire (et donc leur consommation), pour avoir un mode de vie soutenable et essayer de tendre vers une société égalitaire.
# plymouth et kdm
Posté par Jean-Philippe Garcia Ballester (site web personnel) . En réponse au journal Aujourd'hui c'est déjà demain : systemd dans l'initrd sous Arch Linux. Évalué à 4.
Et si vous utilisez plymouth et kdm sur Arch Linux, n'oubliez pas d'installer le AUR
kdebase-workspace-plymouth
.[^] # Re: un message de lennart
Posté par Jean-Philippe Garcia Ballester (site web personnel) . En réponse à la dépêche systemd versions 212 à 215. Évalué à 2.
En même temps, la définition de KISS, c'est un peu flou, non ? En quoi c'est KISS de lancer un interpréteur d'un langage turing-complet à chaque fois que tu veux démarrer un nouveau service ?
[^] # Re: un message de lennart
Posté par Jean-Philippe Garcia Ballester (site web personnel) . En réponse à la dépêche systemd versions 212 à 215. Évalué à 6.
Ce ne sont pas les responsables de la distribution qu'il critique, mais la communauté en général.
[^] # Re: le livreur
Posté par Jean-Philippe Garcia Ballester (site web personnel) . En réponse au journal OVH et le DPI, ou comment se faire débrancher son serveur mail parce qu’on reçoit du spam. Évalué à 5.
Tout savoir, c'est omniscient. Omnipotent, c'est pouvoir tout faire.