Si tu utilises grub, il faut rajouter single à la ligne kernel (lien).
LILO :)
Grub2 est devenu pénible à configurer, d'où mon passage à LILO.
Systemd est plus qu'un système d'init
Attention, passage truffé de suppositions ;)
Je crois que c'est justement ce qui bloque pas mal d'opposants.
Quel intérêt de changer pour un composant qui fasse plus de choses si on ne s'en sers que comme d'un système d'init?
Par exemple, tu cites cron. Très bien, mais sur mes machines je n'utilise pas cron, je n'en ai pas l'utilité: j'éteins mes bécanes (oui je sais, je pourrais utiliser l'hibernation. Mais même dans ce cas, on peut utiliser les scripts j'imagine) quand je m'en sers plus, donc si j'ai besoin de faire quelque chose régulièrement je peux facilement le mettre au moment du boot ou de l'extinction. La plupart du code contenu dans les scripts d'init sers à gérer un service: pour une simple "tâche évènementielle" je pense que ce n'est pas nécessaire de s'encombrer de toute la structure "start/restart/stop/status" si le but est juste de lancer une tâche.
A bien y réfléchir, la mécanique des runlevel est plus puissante que je l'imaginais… j'ai encore trop de réflexes de mes années windows et je n'aurai pas imaginé avant ce message utiliser les runlevels pour planifier une action à l'extinction de ma machine :)
selon des contraintes temporelles
Je pense que là, on met le doigt sur un autre problème, justement. Ce que je vais dire rejoins assez ce commentaire d'une autre autre dépêche: quel intérêt pour un ordinateur de bureau utilisé par quelqu'un de normal?
Lancer une tâche toutes les 20 minutes ou à heure fixe? Je ne vois personne dans mon entourage qui le fasse… Bien sûr, pour faire des mises à jour automatiques sur une machine qui est toujours allumée, c'est utile. C'est aussi super sur un serveur qui doit faire des backup réguliers et n'a comme réelle donnée pour savoir quand que le temps.
Mais voila, tout ça, c'est super pour des serveurs (ou même du matériel embarqué), pour un ordinateur de bureau c'est bien plus contestable.
systemd est une avancée mais surtout pour ceux qui administrent des serveurs ou des machines professionnelles, qui ne s'éteignent jamais. Pour les autres utilisateurs qui ne veulent qu'activer/désactiver des services au lancement de la machine, je n'en suis pas sûr: renommer /etc/rc2.d/S02mpd en /etc/rc2.d/K02mpd n'est pas complexe, et je parie qu'il existe des GUI pour le faire (enfin, non, je parie pas, je sais qu'il y en a au moins une, mais impossible de remettre la synapse sur son nom…).
qui consiste à dire qu'on se fiche de l'occupation mémoire des logiciels qu'on écrit parce que le client bah "il a qu'a acheter de la ram".
Nous parlons d'une surconsommation de RAM (de systemd par rapport à sysvinit) de 30 ou 40 Mo.
Sur la citation que tu as faite, je parlais d'une tendance générale dans l'industrie du logiciel, et pour être précis d'une tendance qui tends à m'exaspérer fortement, pas de systemd en particulier.
Pour en revenir à systemd et son augmentation de 30Mo, ou mieux, en prenant ton test Debian/ArchLinux, j'ai toujours préféré les données relatives: 30Mo supplémentaires ne veulent rien dire en soit, je préfère parler de 100% d'augmentation.
Ca parle beaucoup plus ainsi.
Par exemple, si on parle d'une augmentation de la consommation de 30Mo de LibreOffice d'une version X à une version Y, si la version X consommait 1000Mo (j'invente hein) alors ce n'est une augmentation que de 3%. Pas loin d'être négligeable donc. Alors que la version X consommait 30Mo, et la version Y passe à 60Mo, il vaut mieux que le gain en fonctionnalités vaille le coup pour moi. (surtout que dans un cas comme dans l'autre, rien ne dis que j'utiliserai ces nouvelles fonctionnalités)
Dans le cas de systemd, ça semble être le cas… même si suis assez sceptique sur la nécessité de certaines dépendances en dur que je n'utilise pas (je pense ici à dbus). Encore une fois, c'est une simple augmentation de 30Mo de la consommation de ma machine (j'invente, encore) mais si je dois rajouter une consommation moyenne de 60Mo, ça peut vouloir dire que ma machine va beaucoup plus swapper quand je compile, et le disque dur est d'une lenteur impressionnante, et quand j'utilisais GCC pour compiler autorealm, si je voulais utiliser mon CPU à fond (avec 4 thread donc) ma machine devenais complètement hors de contrôle pendant près de 15 minutes (du coup je tournais à mi-régime et ça compilait en +/-4 minutes. J'ai ensuite découvert clang, et je suis passé à +/-2 minutes :) )
Je pourrais acheter de la RAM bien sûr, mais dans ce cas c'est l'autonomie de ma batterie qui va diminuer il me semble.
Enfin, je ne suis pas un expert sur la question… mais je pense que si systemd est bel et bien une avancée sur pas mal de points, il a malgré tout des conséquences négatives qui font qu'il faut qu'un autre système d'init, un qui ne fasse que ça, soit toujours maintenu. Peu m'importe que ce soit sysVinit, openRC ou je ne sais quoi, mais j'adhère assez à la philosophie UNIX qui dit que les programmes efficaces ne font qu'une seule chose mais la font bien (ça ne m'empêche pas de voir qu'il y a plein de contre exemples).
[^] # Re: Re: Quelles distributions utilisent systemd par défaut ?
Posté par freem . En réponse au journal SystemD et Arch autosuggestion. Évalué à 2.
LILO :)
Grub2 est devenu pénible à configurer, d'où mon passage à LILO.
Attention, passage truffé de suppositions ;)
Je crois que c'est justement ce qui bloque pas mal d'opposants.
Quel intérêt de changer pour un composant qui fasse plus de choses si on ne s'en sers que comme d'un système d'init?
Par exemple, tu cites cron. Très bien, mais sur mes machines je n'utilise pas cron, je n'en ai pas l'utilité: j'éteins mes bécanes (oui je sais, je pourrais utiliser l'hibernation. Mais même dans ce cas, on peut utiliser les scripts j'imagine) quand je m'en sers plus, donc si j'ai besoin de faire quelque chose régulièrement je peux facilement le mettre au moment du boot ou de l'extinction. La plupart du code contenu dans les scripts d'init sers à gérer un service: pour une simple "tâche évènementielle" je pense que ce n'est pas nécessaire de s'encombrer de toute la structure "start/restart/stop/status" si le but est juste de lancer une tâche.
A bien y réfléchir, la mécanique des runlevel est plus puissante que je l'imaginais… j'ai encore trop de réflexes de mes années windows et je n'aurai pas imaginé avant ce message utiliser les runlevels pour planifier une action à l'extinction de ma machine :)
Je pense que là, on met le doigt sur un autre problème, justement. Ce que je vais dire rejoins assez ce commentaire d'une autre autre dépêche: quel intérêt pour un ordinateur de bureau utilisé par quelqu'un de normal?
Lancer une tâche toutes les 20 minutes ou à heure fixe? Je ne vois personne dans mon entourage qui le fasse… Bien sûr, pour faire des mises à jour automatiques sur une machine qui est toujours allumée, c'est utile. C'est aussi super sur un serveur qui doit faire des backup réguliers et n'a comme réelle donnée pour savoir quand que le temps.
Mais voila, tout ça, c'est super pour des serveurs (ou même du matériel embarqué), pour un ordinateur de bureau c'est bien plus contestable.
systemd est une avancée mais surtout pour ceux qui administrent des serveurs ou des machines professionnelles, qui ne s'éteignent jamais. Pour les autres utilisateurs qui ne veulent qu'activer/désactiver des services au lancement de la machine, je n'en suis pas sûr: renommer /etc/rc2.d/S02mpd en /etc/rc2.d/K02mpd n'est pas complexe, et je parie qu'il existe des GUI pour le faire (enfin, non, je parie pas, je sais qu'il y en a au moins une, mais impossible de remettre la synapse sur son nom…).
Sur la citation que tu as faite, je parlais d'une tendance générale dans l'industrie du logiciel, et pour être précis d'une tendance qui tends à m'exaspérer fortement, pas de systemd en particulier.
Pour en revenir à systemd et son augmentation de 30Mo, ou mieux, en prenant ton test Debian/ArchLinux, j'ai toujours préféré les données relatives: 30Mo supplémentaires ne veulent rien dire en soit, je préfère parler de 100% d'augmentation.
Ca parle beaucoup plus ainsi.
Par exemple, si on parle d'une augmentation de la consommation de 30Mo de LibreOffice d'une version X à une version Y, si la version X consommait 1000Mo (j'invente hein) alors ce n'est une augmentation que de 3%. Pas loin d'être négligeable donc. Alors que la version X consommait 30Mo, et la version Y passe à 60Mo, il vaut mieux que le gain en fonctionnalités vaille le coup pour moi. (surtout que dans un cas comme dans l'autre, rien ne dis que j'utiliserai ces nouvelles fonctionnalités)
Dans le cas de systemd, ça semble être le cas… même si suis assez sceptique sur la nécessité de certaines dépendances en dur que je n'utilise pas (je pense ici à dbus). Encore une fois, c'est une simple augmentation de 30Mo de la consommation de ma machine (j'invente, encore) mais si je dois rajouter une consommation moyenne de 60Mo, ça peut vouloir dire que ma machine va beaucoup plus swapper quand je compile, et le disque dur est d'une lenteur impressionnante, et quand j'utilisais GCC pour compiler autorealm, si je voulais utiliser mon CPU à fond (avec 4 thread donc) ma machine devenais complètement hors de contrôle pendant près de 15 minutes (du coup je tournais à mi-régime et ça compilait en +/-4 minutes. J'ai ensuite découvert clang, et je suis passé à +/-2 minutes :) )
Je pourrais acheter de la RAM bien sûr, mais dans ce cas c'est l'autonomie de ma batterie qui va diminuer il me semble.
Enfin, je ne suis pas un expert sur la question… mais je pense que si systemd est bel et bien une avancée sur pas mal de points, il a malgré tout des conséquences négatives qui font qu'il faut qu'un autre système d'init, un qui ne fasse que ça, soit toujours maintenu. Peu m'importe que ce soit sysVinit, openRC ou je ne sais quoi, mais j'adhère assez à la philosophie UNIX qui dit que les programmes efficaces ne font qu'une seule chose mais la font bien (ça ne m'empêche pas de voir qu'il y a plein de contre exemples).