Grub2 est devenu pénible à configurer, d'où mon passage à LILO
Arf ! 😄
Je me doutais un peu de ta réaction, mais c'est un choix réfléchi :)
N'y vois pas de malice de ma part, c'est juste que nos avis sont différents (et que j'adore utiliser les smileys en UTF-8 😞😐😊😄). Lorsque je l'utilisais, Lilo me semblait pénible à paramétrer car, pour modifier sa configuration, il fallait lancer un exécutable (le binaire lilo) après avoir modifié le fichier de conf. Je trouve Grub2 plus simple à paramétrer : on modifie le fichier de conf, on enregistre, point. La mauvaise réputation de Grub2 me paraît injustifiée.
Enfin, chacun ses besoins. Si Lilo te convient, tant mieux. 😊
Il me semble que, sous Debian, cron (et son copain anacron) sont installés par défaut,
Ça dépend.
Ils le sont si tu sélectionnes les outils de base lors de l'installation du système, mais il se trouve que c'est quelque chose que je ne fais plus depuis bien longtemps
C'est noté.
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…).
Ça va m'être difficile de répondre, je suis un fossile, resté à la DDR2. 😊
Et effectivement, je voulais dire : la surconsommation de RAM causée par systemd me semble raisonnable, vu la quantité de RAM utilisée dans le matériel moderne.
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.
Combien de temps passé à chercher les bons logiciels, à les tester, à les configurer ? Mais je reconnais que ta démarche permet d'apprendre, c'est plus instructif que de jouer avec la priorité des processus.
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.
Je l'ignore. C'est vrai que, si systemd consomme 50 pour économiser 30, mon argument tombe à l'eau. 😊
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.
Lorsqu'il a conçu systemd, Lennart Poettering a choisi d'utiliser des briques déjà existantes : dbus, les truckit, etc. Conséquence de ce choix : systemd a de nombreuses dépendances. Si Lennart avait cloné toutes les briques nécessaires, et intégré ces clones dans le code de systemd directement, systemd n'aurait aucune dépendance aujourd'hui (ou très peu). Le package d'installation de systemd serait plus gros, mais systemd aurait exactement les mêmes fonctionnalités. Et aucune dépendance (ou très peu).
L'argument « systemd a trop de dépendances » n'existe qu'à cause des choix de conception de systemd : s'appuyer sur des logiciels existants, plutôt que de ré-inventer la roue.
Dans ta conception des choses, tu pourrais remplacer « systemd a trop de dépendances » par « Pour plus de lisibilité, le code de systemd est réparti entre plusieurs paquets à installer ».
[^] # Re: Re: Quelles distributions utilisent systemd par défaut ?
Posté par Sylvain Blandel . En réponse au journal SystemD et Arch autosuggestion. Évalué à 2.
N'y vois pas de malice de ma part, c'est juste que nos avis sont différents (et que j'adore utiliser les smileys en UTF-8 😞😐😊😄). Lorsque je l'utilisais, Lilo me semblait pénible à paramétrer car, pour modifier sa configuration, il fallait lancer un exécutable (le binaire
lilo) après avoir modifié le fichier de conf. Je trouve Grub2 plus simple à paramétrer : on modifie le fichier de conf, on enregistre, point. La mauvaise réputation de Grub2 me paraît injustifiée.Enfin, chacun ses besoins. Si Lilo te convient, tant mieux. 😊
C'est noté.
Ça va m'être difficile de répondre, je suis un fossile, resté à la DDR2. 😊
Et effectivement, je voulais dire : la surconsommation de RAM causée par systemd me semble raisonnable, vu la quantité de RAM utilisée dans le matériel moderne.
Combien de temps passé à chercher les bons logiciels, à les tester, à les configurer ? Mais je reconnais que ta démarche permet d'apprendre, c'est plus instructif que de jouer avec la priorité des processus.
Je l'ignore. C'est vrai que, si systemd consomme 50 pour économiser 30, mon argument tombe à l'eau. 😊
Lorsqu'il a conçu systemd, Lennart Poettering a choisi d'utiliser des briques déjà existantes : dbus, les truckit, etc. Conséquence de ce choix : systemd a de nombreuses dépendances. Si Lennart avait cloné toutes les briques nécessaires, et intégré ces clones dans le code de systemd directement, systemd n'aurait aucune dépendance aujourd'hui (ou très peu). Le package d'installation de systemd serait plus gros, mais systemd aurait exactement les mêmes fonctionnalités. Et aucune dépendance (ou très peu).
L'argument « systemd a trop de dépendances » n'existe qu'à cause des choix de conception de systemd : s'appuyer sur des logiciels existants, plutôt que de ré-inventer la roue.
Dans ta conception des choses, tu pourrais remplacer « systemd a trop de dépendances » par « Pour plus de lisibilité, le code de systemd est réparti entre plusieurs paquets à installer ».
D'ailleurs, une anecdote : systemd n'est plus dépendant de consolekit ! Dans la liste des dépendances de la version 202 de systemd, on ne trouve aucun truckit. Les fonctionnalités de consolekit ont été intégrées à systemd, dans un composant nommé systemd-logind. D'ailleurs, l'abandon de consolekit est confirmé sur la distribution qu'il ne faut pas nommer ☠