[quote=“vv222”]Je ne vois pas le rapport avec ce vote.[/quote]Pourquoi, j’ai migré directement vers *BSD en connaissance de cause (Gnome 3.xx + système d’initialisation par défaut) puis Debian est toujours libre avec quelques nuances.
Je conserve l’autre (en desktop) sous gnome3-lite-3.14.2 au cas où, or je préfère la facilité d’utilisation Linux en général et Debian en particulier d’où mon intérêt pour cette alternative.
C’est fait.
[quote=“Cluxter”]Lorsque je vois le bordel que c’est que d’utiliser Debian sans ‘systemd’, je me dis qu’ils se sont bien foutus de notre gueule lorsqu’ils nous rabâchaient que “non non promis, vous pourrez toujours utiliser Debian sans ‘systemd’, ça changera rien de le mettre par défaut”.
Perso je suis en train de migrer vers d’autres distrib, je suis en train d’en tester quelques unes, et dès que j’aurai trouvé la bonne, j’abandonne Debian une fois pour toutes, car je me suis vraiment senti trahi. Qu’une distribution comme Arch adopte ‘systemd’ par défaut ne me pose pas le moindre problème, car c’est un choix assumé depuis la naissance de la distrib. Pour Debian, le contrat social affirmait qu’il fallait rester à l’écoute des utilisateurs. Vu le nombre de personnes qui ont gueulées contre l’adoption de ‘systemd’ par défaut (et qui continuent de le faire), je considère que ce contrat n’a pas été respecté.
Donc Debian et moi c’est terminé, après pourtant 8 ans d’utilisation et d’administration quotidienne.[/quote]
Je pense que ce que tu dis reflète bien l’avis et le ressenti des utilisateurs de Debian qui, comme nous, n’ont pas digéré cette rupture de contrat.
Pour Arch, ce n’est pas si évident que ça, même si moi aussi leur utilisation de systemd ne me dérange en aucune façon. Mais ce n’a jamais été ma distribution.
Arch a été créée en s’inspirant de Crux, elle se veut “kiss” et était dotée à l’origine d’un système d’init de type BSD, donc …
Pour les distros no-systemd, et bien il ne reste que Slackware, Gentoo/Funtoo en distros “mère”, et PcLinuxOs + quelques petites distributions pas très connues.
Sinon c’est du *BSD.
[quote]
Lorsque je vois le bordel que c’est que d’utiliser Debian sans ‘systemd’[/quote]
Tu te fout pas un peu du monde, non ?
J’ai plus d’une centaine de machine sous Debian Jessie, sous tout les cas d’utilisations possibles, aucune n’a systemd, et pour aucune ce n’est “le bordel à utiliser”.
Je ne demande pas mieux que me tromper au sujet de ce fork, mais je digère toujours très mal cette décision de lancer un nouveau projet alors que le projet Debian n’a absolument rien fait pour refuser leurs contributions.
Il serait intéressant à ce sujet de voir comment étaient traités les bugs spécifiques à systemd/upstart/etc. lorsque SysV était encore le système par défaut. Ça nous donnerait probablement un aperçu du niveau de priorité qui sera donné à SysV pour les deux années à venir.
À mon avis SysV tiendra bon jusqu’à ce qu’une alternative à systemd séduisant les sceptiques débarque s’il y a suffisamment d’administrateurs/développeurs à continuer à s’en servir.
[quote=“vv222”]
Il serait intéressant à ce sujet de voir comment étaient traités les bugs spécifiques à systemd/upstart/etc. lorsque SysV était encore le système par défaut. Ça nous donnerait probablement un aperçu du niveau de priorité qui sera donné à SysV pour les deux années à venir.
À mon avis SysV tiendra bon jusqu’à ce qu’une alternative à systemd séduisant les sceptiques débarque s’il y a suffisamment d’administrateurs/développeurs à continuer à s’en servir.[/quote]
Il n’y avait pas de souci car tous utilisaient les mes services (syslog, udev, pam, etc). Le problème n’est pas le remplacement de sysv par systemd, le problème est le remplacement de udev, pam, cron, at, login, syslog, dbus, … par les plugins systemd correspondant avec les incompatibilités existantes et à venir. Si tu fais un système qui utilises udev, je te fiche mon billet que ça va coincé avec systemd t ou tard, il suffit de voir le passage de hotplug à udev. L’amusant est d’ailleurs qu’à l’époque l’argument était de faire passer udev dans l’espace utilisateur et dans faire un truc indépendant. Là soudain on regroupe tout. Si systemd s’était contenté de faire le démarrage et de lancer init, il n’y aurait jamais eu cette levée de boucliers.
Je suis tout à fait d’accord. Il est en effet évident que SysV commence à vieillir et qu’un coup de jeune ne lui ferait pas de mal. Seulement, je parle bien de l’init et des rc, pas de tous les outils de base. cron et rsyslog fonctionnent parfaitement bien, par exemple.
Je suis tout à fait d’accord. Il est en effet évident que SysV commence à vieillir et qu’un coup de jeune ne lui ferait pas de mal. Seulement, je parle bien de l’init et des rc, pas de tous les outils de base. cron et rsyslog fonctionnent parfaitement bien, par exemple.[/quote]
Ben tu vois, c’est un argument auquel je n’adhère pas, mais pas du tout.
J’utilise tout les jours pleins de machin qui ont plus de 30ans : vi, ls, grep. Il n’est pas nécessaire ni bon de les changer.
Avec le temps, certain projet arrivent à maturité, il n’est plus nécessaire d’y rajouter des fonctionnalités, ils sont parfaits (ou presque).
Le remplacement d’un truc des années 80 devrait demander une quantité non négligeable de bénéfices, pour compenser l’échange de qualité entre un truc fonctionnel, fiable et démentiellement robuste, et un nouveau machin (qui, comme tout ce qui est nouveau, est défectueux).
Bref, sysvinit fonctionne, qu’apporte systemd qui vaut ce changement ? Aux dernières nouvelles, rien.
Je n’ai pas dit que sysvinit ne fonctionnait pas, ni que systemd amenait de bonne choses.
Je dis juste que, par exemple, le fait que les runlevels ne soient pas les mêmes pour toutes les distribs ou que les scripts ne soient pas toujours très clair pourraient être des choses à améliorer.
Effectivement, systemd améliore ça, mais apporte bien plus d’inconvénients. Ce n’est donc pas le bon remplaçant.
Et oui, j’utilise aussi les coreutils et autres trucs qui n’ont pas besoin d’être changés et j’en suis très satisfait.
C’est vrai que systemd ne permet aucune souplesse de configuration ?
Merci pour ton avis en tout cas !
Non, c’est bien évidemment faux.
Ce qui est vrai est qu’il se base sur un paradigme différent de celui de SysV, n’utilisant par exemple pas de runlevels.
Interessant, notamment par la défensive et la faiblesse de certains arguments:
[quote] systemd est un cauchemar de fonctionnalités
Eh bien, systemd couvre certainement plus de terrain que par le passé. Ce n’est plus uniquement un système d’initialisation, mais le bloc de base de l’espace utilisateur à partir duquel construire un système d’exploitation ; mais nous faisons attention de garder optionnelles la plupart des fonctionnalités. Vous pouvez en désactiver beaucoup lors de la compilation, et encore plus lors de l’exécution. Ainsi pouvez-vous choisir librement combien de fonctionnalités injecter.
systemd vous force à faire quelque chose
systemd n’est pas la mafia. C’est un logiciel libre, vous pouvez en faire ce que vous voulez, ce qui inclut ne pas l’utiliser. C’est plutôt l’opposé de « forcer ».
[/quote]systemd est donc bien conçu comme une surcouche complète par dessus le noyau. On quitte bien le système existant avec des taches dédiées et il est nécessaire de recompiler pour désactiver les fonctionnalités sans qu’on sache si on peut mettre les anciens utilitaires. Comme c’est libre il suffit de le patcher. Belle avancée donc.[quote]
systemd rend impossible l’utilisation de syslog
C’est faux, nous avons fait attention lors de l’introduction du journal à ce que les informations soient transmises au serveur syslog. En fait, s’il y a bien une chose qui a changé, c’est surtout le fait que syslog reçoit maintenant plus d’informations, car nous nous occupons du début du démarrage système ainsi que des flux STDOUT/STDERR de tous les services du système. [/quote]
Le problème des logs binaires n’est pas abordé. Nul ne conteste qu’il y a des logs, mais leur lecture simple n’est plus possible.
[quote]systemd est incompatible
Nous faisons de notre mieux pour garantir la meilleure compatibilité possible avec sysvinit. En fait, la grande majorité des scripts d’initialisation fonctionne telle quelle sous systemd, sans modifications. Toutefois, il y a effectivement quelques incompatibilités, mais nous essayons de les documenter et d’expliquer comment y réagir. En fin de compte, tout système qui n’est pas systemd aura une certaine dose d’incompatibilité avec lui vu qu’il n’aura pas exactement la même structure d’exécution.
Notre but est que les différences entre les multiples distributions restent à un niveau minimum. Cela implique que les fichiers unité fonctionnent généralement bien sur une distribution différente de celle où ils ont été conçus, ce qui est un énorme progrès sur les scripts classiques d’initialisation qui sont très difficiles à écrire d’une façon portable à d’autres distributions Linux, compte tenu des nombreuses incompatibilités entre elles.[/quote]En clair c’est incompatible.
Enfin aucune des objections majeures n’est abordée
Pas moi. La lecture d’un texte qui dit tant de fois « c’est faux » ne me tente pas plus que ça.
Ils auraient pu soigner leur titre, aussi. « Mise aux poings sur systemd », franchement ! Ou alors c’était dans l’optique d’une baston à venir. 
Pas moi. La lecture d’un texte qui dit tant de fois « c’est faux » ne me tente pas plus que ça.
Ils auraient pu soigner leur titre, aussi. « Mise aux poings sur systemd », franchement ! Ou alors c’était dans l’optique d’une baston à venir. [/quote]
Même avis, mais le texte est riche des objections non évoquées dans ce plaidoyer…
Retesté nouvelle iso Refracta/exe/Gnu Linux XFCE “Jessie nosystemd” avec eudev de Gentoo.
Installé en dur, cette fois ci tout est fonctionnel, tout marche nickel.
Iso en date du 30/05.
Une chose est sure c’est que jessie sur mon vieux pc portable a crashé au deuxieme demarrage, outre la lenteur le fonctionnement global constaté au premier est loin d’atteindre le confort de wheezy. Ah c’est sûr l’interface est sympatoche avec l’horloge qui se met au verrouillage de l’écran, l’ergonomie bcbg mais bon… un os qui crashe au deuxieme boot n’est pas fait pour moi
Et bien justement: cette Jessie nosystemd+eudev est 686-pae, ils n’ont pas produit d’iso 64 bits.
Et bien la consommation de ressources ram est bluffante: 186 mo en idle sur le bureau (avec Htop). Moitié moins que ma Jessie 64 bits.
Une jessie sans systemd, sans sans sans est elle une jessie?
J’ai l’impression que jessie va tuer debian
Cette distro est identifiée comme Devuan 1 et non comme Debian 8.
D’autre part, il y a un gros article aujourd’hui sur Distrowatch concernant les distributions non systemd.
distrowatch.com/weekly.php?issue=20150601
Le rédacteur, lui, a opté pour la Manjaro OpenRC, donc c’est cette dernière qui a les honneurs.