Voir dans systemd un complot de Red Hat dans le but de controler nos machines puis le monde me parait pour le coup délirant.
La dessus je suis d’accord, ou on tombe dans la paranoïa pure et dure.
Il n’empêche que dans le monde GNU/Linux, il y aura un avant, et un après systemd. Avant, et bien on connait, enfin on a connu. Après, qu’est ce que ça va devenir ?
Qui vivra verra …
Ah non je n’en arrive pas là. Mais je pense que c’est un très bon moyen pour eux d’enfermer peu à peu leurs utilisateurs dans un écosystème qui leur permettra d’avoir plus de contrôle et donc de monétiser davantage leurs services.
[quote=“fran.b”]Non, il ne faut pas dire n’importe quoi non plus:
Un complot, je ne pense pas. On est encore libre de compiler tous nos logiciels sans le support de systemd (ce que je fais). Par contre c’est clairement une stratégie.
[quote=“SwordArMor”]Par contre c’est clairement une stratégie.[/quote]C’est un choix, un (très) mauvais choix, mais un choix de Debian, choix que je ne comprends pas.
Voyons comment va évoluer la situation, c’est toujours possible de faire marche arrière. Pour ma part, je n’upgraderais pas ma stable, ensuite je réagirais suivant l’évolution du projet…
Je suis dans le même état d’esprit, sauf que pour mes nouvelles machines je suis passé sur du gentoo où je compile sans le le support de systemd.
Et sur hurd, systemd y serait aussi ? 
Mise à part l’ironie, le projet GNU a lancé dmd “Daemon managing Daemons” (ou “Daemons-managing Daemon”?) pour gérer les services quelque soit l’OS. Toute aide est la bienvenue.
Mise à part l’ironie, le projet GNU a lancé dmd “Daemon managing Daemons” (ou “Daemons-managing Daemon”?) pour gérer les services quelque soit l’OS. Toute aide est la bienvenue.
réf : https://www.gnu.org/software/dmd/[/quote]
Merci beaucoup pour ce lien ! C’est exactement à ça que je pensais qu’il fallait travailler plutôt que de développer ‘systemd’. C’est très prometteur ! Espérons que ça finisse dans Debian le plus vite possible…
C’est pour moi la plus grosse réussite de systemd : avoir attiré l’attention sur tous ces obscurs projets de systèmes d’init, et d’avoir poussé à la création de nouveaux systèmes.
On n’a jamais eu autant d’alternatives à SysV que depuis le prétendu monopole de systemd 
[quote=“vv222”]C’est pour moi la plus grosse réussite de systemd : avoir attiré l’attention sur tous ces obscurs projets de systèmes d’init, et d’avoir poussé à la création de nouveaux systèmes.
On n’a jamais eu autant d’alternatives à SysV que depuis le prétendu monopole de systemd [/quote]
Euh… Les quels ? Parce que si tu parle d’OpenRC, il n’est pas nouveau c’est un projet plus vieux qui a repris de l’intérêt en réaction à systemd. upstart (qui est mort) est antérieur à systemd.
Il apporte quoi par rapport à OpenRC ?
Avant de vous dire ce qu’il faut faire pour les autres unix, vous vous êtes demandé de ce que eux ils veulent ? Les BSD n’ont pas vraiment envie de changer leur système d’init[^1], pour tous les autres unix importants ils ont leur propre système d’init qui ont inspiré celui de systemd.
[^1]: En fait il y a une discussion au sein de FreeBSD, mais il s’agira d’utiliser des choses comme capsicum ou les jail donc du spécifique BSD.
[quote=“MisterFreez”][quote=“vv222”]C’est pour moi la plus grosse réussite de systemd : avoir attiré l’attention sur tous ces obscurs projets de systèmes d’init, et d’avoir poussé à la création de nouveaux systèmes.
On n’a jamais eu autant d’alternatives à SysV que depuis le prétendu monopole de systemd [/quote]
Euh… Les quels ? Parce que si tu parle d’OpenRC, il n’est pas nouveau c’est un projet plus vieux qui a repris de l’intérêt en réaction à systemd. upstart (qui est mort) est antérieur à systemd.[/quote]
Mon pluriel est malvenu, je ne peux en effet citer que dmd comme nouveau projet (pour l’instant). Il y a bien quelques autres projets qui me viennent en tête, comme uselessd, mais ceux-ci sont essentiellement des forks de systemd.
Mais OpenRC est un bon exemple de système dont je n’avais jamais entendu parler avant « l’affaire systemd », et qui à mon avis mérite qu’on s’y intéresse, ne serait-ce que par curiosité technique.
[quote=“vv222”]
Mais OpenRC est un bon exemple de système dont je n’avais jamais entendu parler avant « l’affaire systemd », et qui à mon avis mérite qu’on s’y intéresse, ne serait-ce que par curiosité technique.[/quote]
Attention, OpenRC est un remplaçant de sysv-rc et non de sysvinit. C’est à dire qu’il se charge des dépendances entre les services, mais il lui faut un init (généralement sysvinit) pour les lancer/arrêter/recharger/whatever.
Ce n’est donc pas une alternative à sysvinit. Par contre systemd a son propre programme de gestion des RC. Ainsi, il est considéré comme une alternative à systemd.
Depuis hier en fin de matinée, Devuan a “ouvert” ses dépôts.
Il est maintenant possible de basculer son sources.list sur Devuan.
Merci 
Je viens de tester une Machine virtuelle sur LMDE (linux mint debian edition) et une machine virtuelle MX linux) et je me suis amusé a comparé le fichier sources.list a un debian 12 stable.
Sur LMDE le fichier sources.list a un dépot Linux Mint qui doit être pour certaines mises a jour comme Cinnamon par exemple, ce qui permet d’installer certains paquet Mint de ce fork, mais je remarque que le dépôt backport est activé par defaut et que dans leur centre logiciel on peut soit installé des .deb ou flatpak mais rien n’indique que les .deb installé sont des backport (a part si on jette un coup d’œil en ligne de commande), du coup on peut se retrouver avec des paquets backport installé depuis leur centre logiciel sans le savoir, je trouve qu’on perd le contrôle de ce qu’on fait, alors certes ce fork est friendly et facile d’accès mais sans aucun contrôle de ce que l’on installe. Quand pensez vous ?
Sur MX-Linux le fichier sources.list a un dépot MX qui installe certains paquet pour ce fork, par contre les dépôts backport sont désactivé par défaut et ils sont accessible dans leur centre logiciels avec une demande d’activation dans le sources.list ce qui permet un certains contrôle. Par contre elle est moyennement firendly cette distribution sur certains points, logiciels de mises a jour, configuration et on perd le contrôle sur certains points, et il reste certains point en franglais, obligé de rajouter l’installation de certains paquet en french. Quand pensez vous ?
Plus le temps passe et plus je n’arrive a pas a voir la plus-value de ces forks de Debian en 2024 pour un poste de travail comparé a une Debian stable qui permet de garder le contrôle de ce qu’on fait. 
Quand pensez vous ?
Je viens aussi d’essayer une machine virtuelle sur Q4os, c’est le pire des forks a mon avis et quel est le votre ?
D’accord.C’est pour ça qu’on est sur debian.
Ça a le mérite d’être clair. 