Je me doutais un peu de ta réaction, mais c'est un choix réfléchi :)
Il me semble que, sous Debian, cron (et son copain anacron) sont installés par défaut,
Ça dépends.
Ils le sont si tu sélectionnes les outils de bases lors de l'installation du système, mais il se trouve que c'est quelque chose que je ne fais plus depuis bien longtemps (cela dis, il semble que j'ai installé anacron sur ma machine, je sais pas pourquoi. J'imagine que je voulais jouer avec et que j'ai omis de le supprimer :) ).
Il semble que leur principal usage soit de compresser les journaux trop vieux, et je dois admettre que vu le peu d'usage que je fais des journaux (je les lis jamais: je sais c'est mal) je me moque un peu de leur présence.
Les logs de cron et d' anacron devraient être lisibles avec :
En gros, j'ai 3 lignes le 26 avril, et pleins le 1er mai. Rien d'autre, et pourtant ce système est bien plus vieux. Aucune info sur ce qui est fait exactement.
Ce lancement de tâches selon des contraintes temporelles, nécessaire au bon fonctionnement du système d'exploitation, peut être fait avec cron, ou avec systemd.
Ces tâches sont loin d'être nécessaires. Cron (et consort) sont des dépendances de logrotate, lui-même n'étant qu'une dépendance recommandée du système (de rsyslog en fait), rien de plus.
De même qu'aptitude recommande apt-xapian-index (dont je ne vois absolument pas l'intérêt et que je n'installe donc jamais), qui ensuite dépend du paquet python-apt n'implique pas que python-apt est un outil nécessaire au bon fonctionnement du système.
Il y a exactement 19 paquets qui dépendent directement d'anacron (flemme de regarder pour cron, mais si ils ont été bien fait, ça devrait être pareil) dont 10 pour lesquels il s'agit d'une dépendance, 4 qui le recommandent, et 5 qui le suggèrent.
Les 10:
checksecurity
fiaif
gnome-schedule
gnumed-server 16
gnumed-server 17 (je précise les versions ici pour montrer qu'en fait, c'est même pas vraiment 10…)
kde-config-cron 4.8
kde-config-cron 4.10 (idem)
logrotate 3.8.3-3
logrotate 3.8.3-4 (encore)
task-laptot 3.14
Les 4:
email-reminder
task-desktop 3.14+nmu2
update-notifier 0.99.3debian11
update-notifier-kde 1.2.4
Les 5:
backup-manager
bcron-run
cron (mouarf)
cronie (hum)
popularity-contest
Dis-moi qu'est-ce qui, dans ces logiciels, est réellement vital au système? Pour moi, rien… D'ailleurs, comme je l'ai dis, je fonctionne habituellement sans (et vais d'ailleurs re-supprimer cet outil dont je n'ai que faire).
J'ai compris ton propos, et je disais juste que la surconsommation de RAM causée par systemd me semble raisonnable, vu le matériel moderne.
Dans l'ensemble, je suis d'accord.
Mais pas sur du matériel bas de gamme, même moderne, comme l'est mon eeepc (par moderne, j'entends pas "tout neuf", mais avec des générations de matos ayant encore cours, comme les proc x64 bi-coeur multi-thread par exemple. La quantité de RAM ne me semble pas avoir grand chose à voir avec la modernité par contre. Mais sa techno, si: la DDR3, ça va encore non? Il semble que la DDR4 soit prévue à la vente grand public pour 2015 après tout…).
Ce problème ne peut-il pas être réglé avec nice et son copain ionice ?
Probablement, mais je suis encore un débutant sous linux (ça fait que 3 ans que j'ai switché mon OS principal, et j'ai encore pas mal a apprendre pour qu'il fasse de plus en plus uniquement ce que je lui demande, de façon optimale).
Enfin bon, plutôt que de jouer avec les priorités des processus, le plus simple et le plus efficace reste de sélectionner des logiciels qui font ce qu'on leur demande, tout en étant moins gourmands.
Dans le cas de la compilation, clang++ à juste banni g++ de mes habitudes.
Dans le cas des processus d'init, je trouve encore un intérêt et un rôle utile à sysVinit, bien que je ne serais pas contre une solution de remplacement qui soit capable de lire les fichiers utilisés par systemd, mais qui n'apporte pas de dépendances dont je n'ai que faire. Et dont je ne suis manifestement pas le seul à n'avoir que faire: quand le sujet est abordé sur la ml de debian, je constate que je ne suis pas le seul a éprouver des réticences à installer dbus et autres truckit.
Le principe est le suivant : un service est lancé uniquement lorsqu'on fait appel à lui, pas avant. L'opération est transparente pour l'utilisateur.
J'ai effectivement entendu parler de ça, et c'est d'ailleurs pourquoi mon avis sur systemd est très mitigé:
* d'un côté il crée des dépendances dont je n'ai pas l'usage et à un coût réel d'exécution
* d'un autre côté, il permets d'améliorer pas mal de choses: facilité de maintenance des scripts d'init, parallélisation du démarrage des services, montage des partitions à la demande, arrêt/démarrage des services pour qu'ils ne fonctionnent que si on en a besoin.
La plupart de ces avantages sont très très utiles pour un serveur, je pense (y compris le temps de démarrage réduit: quand un serveur doit redémarrer, autant que ça soit le plus bref possible), mais pour une machine d'utilisateur final, à part quelques services à lancer à la demande comme cups, samba, ou les outils des DEs (sur-?)évolués comme KDE/Gnome, l'intérêt est restreint. Et ces mêmes outils ne sont pas forcément utiles à toutes les machines.
D'ailleurs, je me demande si cups+samba+sysVinit consomment autant que systemd seul? C'est une vraie question hein, vu que je n'utilise pas les 2 démons cités, je n'ai absolument aucune idée de leur consommation.
Reste ssh, que je démarre généralement quand j'en ai besoin (c'est à dire uniquement quand je suis chez moi et que je me sers du PC portable comme d'une télécommande pour la tour). Selon top, au repos, il consomme 1Mo, à peu près…
dans les cas où c'est possible, cela permet d'économiser de la RAM. ;-)
Je suis conscient de cet avantage (comme dit plus haut) mais je me demande si la RAM ainsi économisée compense réellement la surcharge induite par l'usage de systemd sur un poste d'**utilisateur final et normal** genre bureautique (la moyenne des utilisateurs utilisent quoi, à part quelques jeux, un navigateur web, et un logiciel de traitement de texte?).
Sur un serveur, je n'en ai aucune idée. De prime abord je dirais que oui, vue la quantité de services lancés, mais à bien y réfléchir, de nos jours la tendance semble plutôt être a 1 service par serveur virtuel, avec N machines virtuelles installées par serveur physique (voire par grappe de serveur physiques) histoire de réguler la charge. Après, je ne connais pas trop ce domaine donc… je dis sûrement de la merde :D
Sur un poste de développeur web, ça me semble évident que systemd soit intéressant, vu que j'imagine qu'il faut utiliser des serveurs de diverses sortes régulièrement pour tester. Pour un poste de dev "classique" par contre, je ne vois pas l'intérêt.
[^] # Re: Re: Quelles distributions utilisent systemd par défaut ?
Posté par freem . En réponse au journal SystemD et Arch autosuggestion. Évalué à 2.
Je me doutais un peu de ta réaction, mais c'est un choix réfléchi :)
Ça dépends.
Ils le sont si tu sélectionnes les outils de bases lors de l'installation du système, mais il se trouve que c'est quelque chose que je ne fais plus depuis bien longtemps (cela dis, il semble que j'ai installé anacron sur ma machine, je sais pas pourquoi. J'imagine que je voulais jouer avec et que j'ai omis de le supprimer :) ).
Il semble que leur principal usage soit de compresser les journaux trop vieux, et je dois admettre que vu le peu d'usage que je fais des journaux (je les lis jamais: je sais c'est mal) je me moque un peu de leur présence.
En gros, j'ai 3 lignes le 26 avril, et pleins le 1er mai. Rien d'autre, et pourtant ce système est bien plus vieux. Aucune info sur ce qui est fait exactement.
Ces tâches sont loin d'être nécessaires. Cron (et consort) sont des dépendances de logrotate, lui-même n'étant qu'une dépendance recommandée du système (de rsyslog en fait), rien de plus.
De même qu'aptitude recommande apt-xapian-index (dont je ne vois absolument pas l'intérêt et que je n'installe donc jamais), qui ensuite dépend du paquet python-apt n'implique pas que python-apt est un outil nécessaire au bon fonctionnement du système.
Il y a exactement 19 paquets qui dépendent directement d'anacron (flemme de regarder pour cron, mais si ils ont été bien fait, ça devrait être pareil) dont 10 pour lesquels il s'agit d'une dépendance, 4 qui le recommandent, et 5 qui le suggèrent.
Les 10:
Les 4:
Les 5:
Dis-moi qu'est-ce qui, dans ces logiciels, est réellement vital au système? Pour moi, rien… D'ailleurs, comme je l'ai dis, je fonctionne habituellement sans (et vais d'ailleurs re-supprimer cet outil dont je n'ai que faire).
Dans l'ensemble, je suis d'accord.
Mais pas sur du matériel bas de gamme, même moderne, comme l'est mon eeepc (par moderne, j'entends pas "tout neuf", mais avec des générations de matos ayant encore cours, comme les proc x64 bi-coeur multi-thread par exemple. La quantité de RAM ne me semble pas avoir grand chose à voir avec la modernité par contre. Mais sa techno, si: la DDR3, ça va encore non? Il semble que la DDR4 soit prévue à la vente grand public pour 2015 après tout…).
Probablement, mais je suis encore un débutant sous linux (ça fait que 3 ans que j'ai switché mon OS principal, et j'ai encore pas mal a apprendre pour qu'il fasse de plus en plus uniquement ce que je lui demande, de façon optimale).
Enfin bon, plutôt que de jouer avec les priorités des processus, le plus simple et le plus efficace reste de sélectionner des logiciels qui font ce qu'on leur demande, tout en étant moins gourmands.
Dans le cas de la compilation, clang++ à juste banni g++ de mes habitudes.
Dans le cas des processus d'init, je trouve encore un intérêt et un rôle utile à sysVinit, bien que je ne serais pas contre une solution de remplacement qui soit capable de lire les fichiers utilisés par systemd, mais qui n'apporte pas de dépendances dont je n'ai que faire. Et dont je ne suis manifestement pas le seul à n'avoir que faire: quand le sujet est abordé sur la ml de debian, je constate que je ne suis pas le seul a éprouver des réticences à installer dbus et autres truckit.
J'ai effectivement entendu parler de ça, et c'est d'ailleurs pourquoi mon avis sur systemd est très mitigé:
* d'un côté il crée des dépendances dont je n'ai pas l'usage et à un coût réel d'exécution
* d'un autre côté, il permets d'améliorer pas mal de choses: facilité de maintenance des scripts d'init, parallélisation du démarrage des services, montage des partitions à la demande, arrêt/démarrage des services pour qu'ils ne fonctionnent que si on en a besoin.
La plupart de ces avantages sont très très utiles pour un serveur, je pense (y compris le temps de démarrage réduit: quand un serveur doit redémarrer, autant que ça soit le plus bref possible), mais pour une machine d'utilisateur final, à part quelques services à lancer à la demande comme cups, samba, ou les outils des DEs (sur-?)évolués comme KDE/Gnome, l'intérêt est restreint. Et ces mêmes outils ne sont pas forcément utiles à toutes les machines.
D'ailleurs, je me demande si cups+samba+sysVinit consomment autant que systemd seul? C'est une vraie question hein, vu que je n'utilise pas les 2 démons cités, je n'ai absolument aucune idée de leur consommation.
Reste ssh, que je démarre généralement quand j'en ai besoin (c'est à dire uniquement quand je suis chez moi et que je me sers du PC portable comme d'une télécommande pour la tour). Selon top, au repos, il consomme 1Mo, à peu près…
Je suis conscient de cet avantage (comme dit plus haut) mais je me demande si la RAM ainsi économisée compense réellement la surcharge induite par l'usage de systemd sur un poste d'**utilisateur final et normal** genre bureautique (la moyenne des utilisateurs utilisent quoi, à part quelques jeux, un navigateur web, et un logiciel de traitement de texte?).
Sur un serveur, je n'en ai aucune idée. De prime abord je dirais que oui, vue la quantité de services lancés, mais à bien y réfléchir, de nos jours la tendance semble plutôt être a 1 service par serveur virtuel, avec N machines virtuelles installées par serveur physique (voire par grappe de serveur physiques) histoire de réguler la charge. Après, je ne connais pas trop ce domaine donc… je dis sûrement de la merde :D
Sur un poste de développeur web, ça me semble évident que systemd soit intéressant, vu que j'imagine qu'il faut utiliser des serveurs de diverses sortes régulièrement pour tester. Pour un poste de dev "classique" par contre, je ne vois pas l'intérêt.