Si ton but c’est le minimalisme, tu peux déjà commencer avec systemd, car il est possible de désactiver les services mis en place par défaut (à la main faut créer un lien symbolique vers /dev/null, mais il doit y’avoir une commande qui fait ça). De plus toutes les distros, avec leur propre système d’init, viennent avec une configuration par défaut qui active/lance un certain nombre de service sans rien demander à personne.
C’est pas systemd contre les autres. C’est une philosophie de distro.
Techniquement udevd peut te lancer n’importe quel script/programme en fonction des événements matériel. Historiquement un inetd écoute les ports et démarre les serveurs à la demande (y’a plus récent et plus safe). Un cron ou atd vont gérer les tâches périodiques. Pour le bluetooth y’a un daemon pour ça, idem probablement pour gérer le wifi (quoiqu’une petite collection de scripts bien sentie devrait faire le job...).
Mais tu perds beaucoup d’automatisme et de trucs qui marchent out-of-the-box. En vrai des gens très sympas qui ont écrit les scripts et les programmes pour que toi tu n’ais rien à faire. Autant je fais dans le minimalisme pour mon fixe, autant sur un portable qui bouge pas mal, j’éviterai et à la lecture de ton journal je vois que tu as bien cerné le problème qui risque de se poser.
Donc il faut avoir du temps, mais c’est gratifiant d’acquérir les compétences. Grosso modo tu fais une part du boulot qui revient habituellement aux mainteneurs de la distro. L’avantage c’est que tu connais ton matériel et ton usage, du coup t’es pas obligé de monter une usine à gaz pour prévoir tous les cas imaginables. L’inconvénient c’est qu’il faudra mettre la main à la patte. C’est du boulot qu’il n’est envisageable de faire que sur un système très minimaliste, sinon ce serait chronophage.
Petit exemple (mon dernier en date).
Pour la gestion de l’horloge un linux traditionnel fonctionne ainsi :
1. au démarrage je récupère l’heure système depuis le quartz sur la machine ;
2. durant le fonctionnement je suppose qu’un client ntp va tourner pour mettre à jour l’heure système ;
3. à l’arrêt je mets à jour le petit quartz de la machine grâce à l’heure système.
J’avais désactivé le script à l’arrêt. Au bout de quelques mois j’arrivais à quelques 10min de décalage.
Au final ma solution minimaliste : toutes les semaines environ j’ai programmé une tâche qui fait la synchro ntp puis met à jour dans la foulée le quartz. Car synchroniser un quartz une fois par semaine, c’est amplement suffisant, et je n’ai pas un programme qui tourne pour rien à chaque séquence démarrage/arrêt.
Note que cet exemple montre la futilité de la démarche. C’est juste le plaisir de maîtriser sa machine, de la configurer selon son goût et de mieux comprendre comment elle fonctionne.
Le débat n’est pas technique (systemd ou pas systemd), il est politique : à la base une distro distribue des programmes (merci Mr Obvious), mais avec le temps les tâches admin ont été de plus en plus prises en charge par la distribution (rigoureusement une distribution ne devrait même pas toucher à /etc). Ceci en faveur d’une réorientation plus destinée à l’utilisateur-final où l’intermédiaire qu’est l’admin-sys a sauté.
Je n’utilise pas non plus de bureau user-friendly (dwm). Faudra rester cohérent je pense sur tout le système, parce que je suppose que des gnome ou kde doivent bien plus s’attendre à avoir systemd.
# Gentoo avec openrc (mais j’aimerai dév mon propre init)
Posté par PR . En réponse au journal Les problèmes d’un desktop sans systemd ?. Évalué à 7.
Si ton but c’est le minimalisme, tu peux déjà commencer avec systemd, car il est possible de désactiver les services mis en place par défaut (à la main faut créer un lien symbolique vers /dev/null, mais il doit y’avoir une commande qui fait ça). De plus toutes les distros, avec leur propre système d’init, viennent avec une configuration par défaut qui active/lance un certain nombre de service sans rien demander à personne.
C’est pas systemd contre les autres. C’est une philosophie de distro.
Techniquement udevd peut te lancer n’importe quel script/programme en fonction des événements matériel. Historiquement un inetd écoute les ports et démarre les serveurs à la demande (y’a plus récent et plus safe). Un cron ou atd vont gérer les tâches périodiques. Pour le bluetooth y’a un daemon pour ça, idem probablement pour gérer le wifi (quoiqu’une petite collection de scripts bien sentie devrait faire le job...).
Mais tu perds beaucoup d’automatisme et de trucs qui marchent out-of-the-box. En vrai des gens très sympas qui ont écrit les scripts et les programmes pour que toi tu n’ais rien à faire. Autant je fais dans le minimalisme pour mon fixe, autant sur un portable qui bouge pas mal, j’éviterai et à la lecture de ton journal je vois que tu as bien cerné le problème qui risque de se poser.
Donc il faut avoir du temps, mais c’est gratifiant d’acquérir les compétences. Grosso modo tu fais une part du boulot qui revient habituellement aux mainteneurs de la distro. L’avantage c’est que tu connais ton matériel et ton usage, du coup t’es pas obligé de monter une usine à gaz pour prévoir tous les cas imaginables. L’inconvénient c’est qu’il faudra mettre la main à la patte. C’est du boulot qu’il n’est envisageable de faire que sur un système très minimaliste, sinon ce serait chronophage.
Petit exemple (mon dernier en date).
Pour la gestion de l’horloge un linux traditionnel fonctionne ainsi :
1. au démarrage je récupère l’heure système depuis le quartz sur la machine ;
2. durant le fonctionnement je suppose qu’un client ntp va tourner pour mettre à jour l’heure système ;
3. à l’arrêt je mets à jour le petit quartz de la machine grâce à l’heure système.
J’avais désactivé le script à l’arrêt. Au bout de quelques mois j’arrivais à quelques 10min de décalage.
Au final ma solution minimaliste : toutes les semaines environ j’ai programmé une tâche qui fait la synchro ntp puis met à jour dans la foulée le quartz. Car synchroniser un quartz une fois par semaine, c’est amplement suffisant, et je n’ai pas un programme qui tourne pour rien à chaque séquence démarrage/arrêt.
Note que cet exemple montre la futilité de la démarche. C’est juste le plaisir de maîtriser sa machine, de la configurer selon son goût et de mieux comprendre comment elle fonctionne.
Le débat n’est pas technique (systemd ou pas systemd), il est politique : à la base une distro distribue des programmes (merci Mr Obvious), mais avec le temps les tâches admin ont été de plus en plus prises en charge par la distribution (rigoureusement une distribution ne devrait même pas toucher à /etc). Ceci en faveur d’une réorientation plus destinée à l’utilisateur-final où l’intermédiaire qu’est l’admin-sys a sauté.
Je n’utilise pas non plus de bureau user-friendly (dwm). Faudra rester cohérent je pense sur tout le système, parce que je suppose que des gnome ou kde doivent bien plus s’attendre à avoir systemd.
Mort aux cons !