[init] initscripts ou initscripts-systemd ? (resolu)

[falke]

Le moins qu'on puisse dire c'est que ces derniers temps les dév font tout pour semer la confusion.


Suite à la dépréciation de rc.conf dans sa forme habituelle pour un "rc.conf" éclaté en plusieurs fichiers de conf (un "sys
temd like" by arch d'après ce que je comprends),
les dév ne sachant pas sur quel pied danser (adopte -t-on la logique systemd ou gardons nous un initscript ressemblant à systemd tout en restant compatible et fonctionnel même si éventuellement il n'est pas modifié par l'utilisateur, d'ailleurs question : pendant combien de temps).

Bref, on choisi me semble-t-il de ne pas choisir, ce qui est la pire option à mon sens.

Donc voici la question que je me pose, tout bon confusé que je suis :

Dois-je "éclater" mon fichier dans les nouveaux fichiers de config tout en gardant le paquet initscript , ou devenir full-systemd avec le paquet init-systemd, ou ne rien faire du tout ? car même les dév semblent partagés sur l'orientation à venir de initscript par rapport à la distro arch.
On voit bien que sa philosophie KISS pose sans cesse question et j'ai pas l'impression qu'on aille vers le plus KISS.
Il me semble que si chacun fait à sa façon ça va devenir très compliqué.

Quel est votre avis ?

falke

[tuxce]

Le moins qu'on puisse dire c'est que ces derniers temps les dév font tout pour semer la confusion.

Au contraire, les dév essaient de faire tout pour que tu ne sois pas confus (malheureusement, quand on lit x messages de critiques, il y a de quoi être confus)
Un ancien utilisateur ne voit rien changer.
Un nouveau est doucement guidé vers les nouveaux fichiers.
Je vois mal comment on peut faire plus simple.

un "systemd like" by arch d'après ce que je comprends

les dév ne sachant pas sur quel pied danser

Tu as mal compris. C'est systemd tout court.
Les développeurs d'Arch comptent adopter systemd mais gardent la compatibilité avec rc.conf pour ne pas avoir de changement brusque.

On voit bien que sa philosophie KISS pose sans cesse question et j'ai pas l'impression qu'on aille vers le plus KISS.

Si tu comprends par KISS, simple pour l'utilisateur, tu as juste mal compris ce que KISS veut dire : http://wiki.archlinux.fr/Kiss

Dois-je "éclater" mon fichier dans les nouveaux fichiers de config tout en gardant le paquet initscript , ou devenir full-systemd avec le paquet init-systemd, ou ne rien faire du tout ?

Justement, c'est toi qui choisis, pour l'instant rien ne change (et pour info, systemd et les fichiers sont là depuis très longtemps)

Il me semble que si chacun fait à sa façon ça va devenir très compliqué.

+1 mais après tout, il était déjà possible d'avoir un init différent, on a des desktop différent, des machines différentes, ça ne changera pas grand chose ... il suffit de dire ce qu'on utilise.

[Aikadil]

J'ai choisis initscripts+systemd et j'ai éclaté mon rc.conf, le temps de bien tester l'ensemble, d'ici quelques mois quand la grande majorité sera passé à systemd, que les tuto, wiki etc... se seront mis à la mode systemd je passerais en full.

On est en Roling, il me semble normal de s'adapter aux nouvelles technologies, en installant Arch, je ne m’attendais pas à moins et l'ensemble reste parfaitement KISS, simple techniquement, on modifie si on le désir, tout ce fait par des fichier de config bien documenté.

[widapit]

+1 avec Aikadil,
ma passerelle et mon serveur sont encore en transition, avec un initscript-systemd mais ma machine test et mon portable sont en full systemd et comme je le dis dans un autre topic, je trouves pas ça moins KISS, c'est juste différent de ce à quoi on est habitué...
Je trouves ça presque plus logique, même si j'aimais beaucoup mon /etc/rc.conf, chaque chose est désormais géré par un fichier qui lui est propre et ne sert que à ça, je vois pas en quoi ce n'est pas KISS

[Aikadil]

C'est même une brique fondamentale UNIX, un logiciel, qui ne fait que une seul chose et le fait bien

[FoolEcho]

Dois-je "éclater" mon fichier dans les nouveaux fichiers de config tout en gardant le paquet initscript , ou devenir full-systemd avec le paquet init-systemd, ou ne rien faire du tout ?

Le fait d'utiliser le rc.conf pour le strict minimum est recommandé... mais pas imposé. Donc tu fais ce que tu veux à ce niveau (ça peut être judicieux de le faire cependant pour une éventuelle transition plus douce ou si tu veux tester systemd et en revenir sans te casser la tête).
Pareil pour systemd/initscripts. Aucun problème à rester sur initscripts seul ou les deux conjointement. Pour un passage complet à systemd, si tu as envie d'essayer fais-le mais si tu n'as pas de machine de test, disons que c'est peut-être plus prudent de ne pas le faire. En tous cas pas d'un coup, le temps de se familiariser avec. Tu peux faire l'essai avec initscripts-systemd, voir comment gérer les services (dans l'absolu on retrouve très vite ces marques avec rc.d, preuve que ce dernier est bien foutu, preuve aussi que systemd n'est pas la fin du monde non plus) et une fois tous les services bien lancés, tu peux tenter le coup du passage complet... ou pas.

[Distag]

Moi qui suis passé en full Systemd depuis quelques mois, je n'ai rien à dire de vraiment négatif déçu.
C'est facile à configurer. Bon il y a encore quelques Deamon qui ne se lance pas comme par MPD. Mais je prends mon mal en patience, cela ne devrait pas tarder à arriver.

[tuxce]

mpd a son .service, il faut peut être voir pourquoi il se lance pas ... mais au cas où, ça fera plutôt l'objet d'un topic à part.

[Distag]

Topic ouvert http://forums.archlinux.fr/topic11572.html

[oktoberfest]

Je trouves ça presque plus logique, même si j'aimais beaucoup mon /etc/rc.conf, chaque chose est désormais géré par un fichier qui lui est propre et ne sert que à ça, je vois pas en quoi ce n'est pas KISS

C'est à mon avis LE point qui justement peut faire débat.
A une époque Archlinux mettait en avant la simplicité de configuration car tout était regroupé dans un seul fichier : /etc/rc.conf.
Maintenant on met en avant la simplicité de configuration en ayant plusieurs fichiers spécialisés.
Il n'y a pas de bonne ou de mauvaise façon de faire, c'est juste le fait de changer le point de vue qui me chiffonne un peu.

Après, c'est le système d'init qui induit cela :
- avec un rc.sysinit monolithique, il est logique d'avoir un seul fichier de configuration
- avec un systemd modulaire, il est logique d'avoir un fichier de configuration par module.

[FoolEcho]

Il n'y a pas de bonne ou de mauvaise façon de faire, c'est juste le fait de changer le point de vue qui me chiffonne un peu.

Après, c'est le système d'init qui induit cela :
- avec un rc.sysinit monolithique, il est logique d'avoir un seul fichier de configuration
- avec un systemd modulaire, il est logique d'avoir un fichier de configuration par module.

+1
Sachant que les deux ne sont pas incompatibles (initscripts-systemd + systemd et rc.conf et rc.local sont toujours lus).

Perso, je trouve que c'est faire beaucoup de foin (c'est l'époque bien sûr) pour pas grand chose. En dehors des services (et encore, disons que c'est la seule chose qui va évoluer post-installation), le reste de la configuration est immuable (locale, timezone)... enfin, je ne sais pas pour vous mais pour moi, oui. Donc, transvaser d'un fichier à plusieurs, ou pas, c'est quand même pas insurmontable.

[mélodie]

C'est le "ou pas" qui m'intéresse. Tant que ça fonctionne comme ça, ça me va. J'ai commencé à lire ce très long billet, mais juste le début (66 pages si j'imprime, ça me décourage un peu):
http://0pointer.de/blog/projects/systemd.html

et un autre contenant un tableau comparatif montrant les avantages du systemd (26 pages A4):
http://0pointer.de/blog/projects/why.html

[tuxce]

Les pages sont longues mais c'est parce qu'il y a des commentaires Les billets ne sont pas si long que ça.

[oktoberfest]

Je trouve le premier billet très intéressant. Il explique les concepts sous-jacents et les raisons qui ont poussé à développer le produit. Après on aime ou on aime pas le produit mais au moins il est détaillé.
Par contre le tableau comparatif je trouve que c'est un peu n'importe quoi.

[mélodie]

> Par contre le tableau comparatif je trouve que c'est un peu n'importe quoi.

As-tu un exemple pour dire pourquoi tu trouves que c'est n'importe quoi ?

[oktoberfest]

L'auteur liste l'ensemble des possibilités de systemd et forcément sysVinit ou Upstart ne les ont pas implémenté.
Comme c'est l'auteur de systemd qui a défini les lignes du tableau, il n'a mis que ce qui est favorable à systemd. C'est ce que note un des posteurs :

Posted by iMil at Fri Apr 29 10:23:50 2011
How convenient are those spreadsheets hu ? How about adding the following lines:

. Portability
. Proper coding standards
. Need to modify FHS
. Consistent configuration files
. Huge dependency list

[falke]

salut,

je vois que mon post suscite un certain intérêt .

Ceci-dit j'ai réglé mon problème : j'ai éclaté l'ancien rc.conf dans "un certains nombre de fichiers" utilisés par systemd puis installé le paquet iniscripts-systemd en plus du paquet initscript afin de garder la compatibilité avec ce système-hybride-transitoire à la Arch, en attendant de passer en full systemd lorsqu'il y aura plus de tutos etc...

Donc pour mon post je le passe en résolu ?

Edit : euh.. juste une question venue de cette ligne issue du wiki systemd :

Vous pouvez essayer systemd tout en gardant le système d'init actuel, vous pouvez le sélectionner au démarrage en rajoutant init=/bin/systemd à la ligne du noyau (qui peut différer selon votre chargeur d'amorce).

ça j'ai pas fait par contre, est-ce indispensable ? il semble que mon clavier soit reconnu dans la console et les autres applis , l'heure aussi ...

[FoolEcho]

Si tu ne le fais pas, tu ne bascules pas sous systemd.

[falke]

ok , j'ai ajouté l'option à GRUB , résolu ...

[karhu]

Peut être ne pas le fermer tout de suite, STP.
Suite à la lecture de ce topic et comme j'installe un nouveau PC, j'ai décidé de le rendre le plus compatible possible pour les deux systèmes.
J'ai donc créé d'un coté les fichiers de configuration proposés et de l'autre mis en commentaire les paramètres correspondant dans mon rc.conf. Le tout en m'inspirant fortement des différents wiki's. Cette opération n'a aucunement perturbé le démarrage de ma machine ni son fonctionnement (du moins pour l'instant ).
Cependant j'ai quelques petites questions toutes bêtes :
Il me reste des paramètres dans mon rc.conf que je ne sais pas où mettre :

Code : Tout sélectionner

DAEMON_LOCAL
UDEV_TIMEOUT
USEDMRAID
USEBTRFS
interface=eth0
NETWORK_PERSIST

Est ce que ce sera comme pour USELVM remplacé par un service ?
Autre chose (pour l'instant) quelle est la différence entre /etc/localetime et /etc/timezone.
Doit on utiliser l'un ou l'autre ou l'un et l'autre ? Je n'ai créé que /etc/timezone.