La goutte d'eau qui avait fait déborder le vase et à entraîné le fork, c'est l'impossibilité d'avoir un système sans systemd et sans bidouiller, notamment depuis l'installation. Le tout, alors que systemd était réputé pour avoir des problèmes (avec le réseau, notamment). Choisir une techno avec des problèmes pouvant geler le démarrage, installée par défaut, pour Debian, la distrib qui préfère avoir de vieux paquets qui marche au lieu de paquets modernes qui ont de potentiels problèmes?
Bien sûr que ça mérite un fork. Ceux qui utilisent Debian le font parce que ça juste marche, malgré des soft vieillots, et systemd à cassé ça.
De plus, ce fork n'aurait probablement pas eu lieu (ou aurait échoué) si Debian avait accepté de mettre une option en mode expert pour qu'un autre init soit installé par défaut. Tout simplement. Après tout, c'est bien le cas pour le boot loader, non?
De même, systemd ne touche pas que l'init, mais de mémoire, des choses genre udev également. Si je veux bien accepter que l'init n'est pas si important et que les utilisateurs devraient s'en foutre (de la même façon que mes parents se foutent de savoir que la config de leur OS se fait via une DB et non un jeu de fichiers textes propres qu'on peut versionner, en somme) udev me semble avoir un peu plus d'impact.
M'enfin, je peux me tromper.
Toujours est-il qu'a mon avis la raison du fork c'est pas juste le choix de techno, mais la façon dont certains l'ont ressenti, chose que je peux comprendre pour avoir assisté a quelques batailles.
PS: non, ton truc ne "marche pas comme avant". Pour systemd, un certains nombre de changement ont été effectués, invisible pour pas mal de monde, mais moi je suis tombé sur l'un d'eux, et je n'ai pas eu l'impression qu'ils soient documentés (p'tet pas assez cherché à ce moment). D'ailleurs, j'avais posé la question sur la ml, comment faire pour que startx ne démarre pas la session graphique sur le terminal qui la lance. Rien à voir avec systemd certes, mais le changement semble (j'insiste, semble) avoir été introduit pour lisser le comportement de sysV sur celui de systemd. Sur la ml, personne ne semblait savoir comment contourner le problème. Au fait, j'ai trouvé, pour ceux que ça intéresse, il faut juste se passer de startx et lancer utiliser xinit.
[^] # Re: 1 an
Posté par freem . En réponse au journal Devuan Jessie 1.0. Évalué à 7.
La goutte d'eau qui avait fait déborder le vase et à entraîné le fork, c'est l'impossibilité d'avoir un système sans systemd et sans bidouiller, notamment depuis l'installation. Le tout, alors que systemd était réputé pour avoir des problèmes (avec le réseau, notamment). Choisir une techno avec des problèmes pouvant geler le démarrage, installée par défaut, pour Debian, la distrib qui préfère avoir de vieux paquets qui marche au lieu de paquets modernes qui ont de potentiels problèmes?
Bien sûr que ça mérite un fork. Ceux qui utilisent Debian le font parce que ça juste marche, malgré des soft vieillots, et systemd à cassé ça.
De plus, ce fork n'aurait probablement pas eu lieu (ou aurait échoué) si Debian avait accepté de mettre une option en mode expert pour qu'un autre init soit installé par défaut. Tout simplement. Après tout, c'est bien le cas pour le boot loader, non?
De même, systemd ne touche pas que l'init, mais de mémoire, des choses genre udev également. Si je veux bien accepter que l'init n'est pas si important et que les utilisateurs devraient s'en foutre (de la même façon que mes parents se foutent de savoir que la config de leur OS se fait via une DB et non un jeu de fichiers textes propres qu'on peut versionner, en somme) udev me semble avoir un peu plus d'impact.
M'enfin, je peux me tromper.
Toujours est-il qu'a mon avis la raison du fork c'est pas juste le choix de techno, mais la façon dont certains l'ont ressenti, chose que je peux comprendre pour avoir assisté a quelques batailles.
PS: non, ton truc ne "marche pas comme avant". Pour systemd, un certains nombre de changement ont été effectués, invisible pour pas mal de monde, mais moi je suis tombé sur l'un d'eux, et je n'ai pas eu l'impression qu'ils soient documentés (p'tet pas assez cherché à ce moment). D'ailleurs, j'avais posé la question sur la ml, comment faire pour que startx ne démarre pas la session graphique sur le terminal qui la lance. Rien à voir avec systemd certes, mais le changement semble (j'insiste, semble) avoir été introduit pour lisser le comportement de sysV sur celui de systemd. Sur la ml, personne ne semblait savoir comment contourner le problème. Au fait, j'ai trouvé, pour ceux que ça intéresse, il faut juste se passer de startx et lancer utiliser xinit.