C'est assez intéressant de prendre les choses avec recul. Comme par exemple systemd. Vous avez tenté de passer de CentOS 6 à CentOS 7 ? Voilà un changement majeur du boot, et même du fonctionnement global des services qui s'opére au sein de Linux. En fait c'est bien simple : en utilisation serveur on a l'impression d'avoir changé de distribution. Or les distributions, voilà un sujet de guerre de religion pour le vendredi ; et quand on sait que dans un passé que je n'ai pas connu, on a déjà eu droit à de long trolls BSD vs System V… Ajoutez à cela la résistance au changement, et le fait que le développeur de systemd se vante d'avoir cassé le son sous Linux dans son précédant projet (Pulse Audio), et s'est fait détesté cela (à juste titre, même si les distributions ne sont pas innocentes). Ça y est nous avons une planche savonneuse pour systemd.
Techniquement, on ne va pas nier qu'il y a des apports. Est-ce le problème ? En fait, systemd n'est pas « que » un simple remplacement de sysvinit que nous connaissions. C'est un changement de philosophie.
Alors qu'anciennement sous Linux les différents briques d'une distribution étaient assez indépendants, dans un philosophie KISS, systemd viens englober de plus en plus de fonctionnalités : login, pam, getty, syslog, udev, cryptsetup, cron, at, dbus, acpi, cgroups, gnome-session, autofs, tcpwrappers, audit, chroot, mount… Certaines de ces fonctionnalités pas nécessairement utiles pour un boot (D-BUS au boot ? pour quoi faire ?). Toutes les distributions systemd sont en train de converger pour se ressembler, et bientôt, tout comme freedesktop a tenté d'unifier le desktop, systemd unifiera les distributions entre elles.
Est-ce un mal ? Freedesktop a fait converger KDE et Gnome, mais pour ce qui est du code commun, très peu. En outre rien n'interdit de continuer à utiliser window maker ou enlightment. Au contraire de systemd, qui est en train de bouffer l'univers Linux : dépendance de KDE à systemd, dépendance de Gnome à systemd. Les distributions majeures sont toutes en train de sauter le pas. Se passer de systemd deviends difficile, alors même que le rôle important du logiciel (PID 1) en fait une partie importante, et même essentielle du système. Dans l'univers libre, on s'est toujours vanté de la diversité des approches et des logiciels et des manières de faire (KDE / Gnome, vim/emacs, Linux/BSD, gcc/LLVM, libc/musl, etc…), avec systemd que désire unifier le boot, c'est aussi la perte de la diversité. En conséquence, nous avons une centralisation du développement de toutes les distributions Linux chez Red Hat. Certains paranos ne voient pas cela d'un bon oeil.
Pourrons-nous encore nous passer de systemd ? Car en fait, aussi bien ceux qui rêvent que systemd vienne unifier le joyeux bordel que peut être le libre et les distributions que ceux qui en ont peur oublient une chose : la diversité du libre. Au début des années 90 étaient 386BSD, qui a alors forké en Net/Open/Free BSD d'un côté, et GNU/Linux de l'autre. On a pu penser vers 2005 que NetBSD et sa portabilité était mort, que FreeBSD 5 en retard sur Linux 2.6, et OpenBSD se portait bien, mais essentiellement en utilisation sur un système qui a besoin de haute sécurité / un routeur… Et pourtant, NetBSD est aujourd'hui plus actif que jamais, des forks ont eu lieu notamment de FreeBSD (Dragonfly, TrueOS, etc), et ZFS y est supporté nativement, ce qui n'est pas le cas de Linux. Et je ne parle même des distributions Linux de plus en plus nombreuses avec des philosophies différentes qui se sont créés. Et voila où je veux en venir : si par le passé on a pu opposer des distributions KDE à des distributions Gnome (aujourd'hui on peut rajouter XFCE, Mate, LXDE, etc..), bientôt on parlera de deux familles de distributions différentes : les distributions systemd, et les distributions non systemd/openRC. Vous vouliez unifier ? Nous allons forker !
En réalité, le fork a déjà eu lieu lors de l'inclusion d'udev dans systemd : gentoo a déjà forké udev et travaille sur un système de démarrage moderne restant dans la philosophie traditionnelle : openRC.
Alors allons-y, pour les membres importants de chaque famille :
Famille systemd : RedHat, Centos, Fedora, OpenSüse, Ubuntu et ses dérivés (abandon d'upstart), Mint, Debian (systemd est débrayable, non sans poser des problèmes de dépendance).
Famille non systemd : Gentoo (bien que systemd soit disponible optionnellement, OpenRC est un projet issu de Gentoo), Devuan (fork de debian sans systemd dont on pourrait bien entendre parler dans les prochains mois), Slackware (on voit mal Patrick Volkerding changer le système d'init particulier de la distribution), PCLinuxOS, Alpine Linux, Puppy Linux (distribution musl), à laquelle on pourra rajouter toute la famille des BSD.
Famille non décidée : Manjaro, Arch Linux. Systemd est un troll très récurrent chez Arch Linux, le choix par défaut est systemd, mais le fonctionnement sans systemd est possible.
Voilà, je suis prêt à parier que dans les mois qui vont venir, certains seront tentés de migrer de distribution, si ce n'est déjà fait.
# Ah le désespoir
Posté par pasBill pasGates . Évalué à 10.
Bref, 95% du monde Linux sur systemd, 5% sur le reste (et encore je suis gentil).
Amusant que vous croyiez encore qu'il y a une bataille ici. Systemd a gagné la guerre, c'est fini.
[^] # Re: Ah le désespoir
Posté par abriotde (site web personnel, Mastodon) . Évalué à -7. Dernière modification le 25 juillet 2017 à 21:45.
Oui et non. Il faut attendre que SystemD murisse… ou pourisse. On a déjà vu des retours arrière spectaculaire même s'il est assez peu probable. Tant que des distributions assez importantes (Gentoo) ne s'y mettent pas tout reste possible tant que les compétences SystemV existent encore chez les Linuxiens.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Ah le désespoir
Posté par pasBill pasGates . Évalué à 10.
Tout à fait. Le problème est que Gentoo n'est pas importante. C'est un nain comparé à l'autre camp.
[^] # Re: Ah le désespoir
Posté par David Demelier (site web personnel) . Évalué à 6.
systemd, pas SystemD. sinon on a pas fini avec HttpD, NgircD, DhcpcD,
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Ah le désespoir
Posté par zurvan . Évalué à -10.
c'est toujours très intéressant lorsqu'un non-utilisateur de Linux donne son avis sur la question.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Ah le désespoir
Posté par pasBill pasGates . Évalué à 8.
C'est toujours amusant quand quelqu'un ne sait pas de quoi il parle.
[^] # Re: Ah le désespoir
Posté par Philip Marlowe . Évalué à -3. Dernière modification le 26 juillet 2017 à 10:51.
Tu ne t'adresses pas au rédacteur du journal, sinon tu utiliserais la deuxième personne du singulier au lieu de celle du pluriel. L'adverbe ici ne se rapporte pas à systemd, tu aurais écrit à ce sujet sinon. Donc, ça voudrait dire que sur DLFP les gens en général (cette formule est en elle-même un peu vague, j'essaie de traduire) pensent encore qu'il y a une bataille à propos de systemd. Ça me semble totalement faux. Ou alors tu voulais dire autre chose et il faudrait que tu l'exprimes mieux.
[^] # Re: Ah le désespoir
Posté par Philip Marlowe . Évalué à -2.
Pour ceux qui ont la compréhension lente ou difficile ou qui ont du mal à dégager le sens d'une phrase quand ils trouvent qu'elle comporte trop de mots, le commentaire précédent ne dit rien contre systemd.
Ceci fait partie de la série comment se faire des amis.
[^] # Re: Ah le désespoir
Posté par claudex . Évalué à 10.
Elle ne dit rien contre systemd mais tout le monde avait compris que le « vous » s'adressait aux gens qui critiquent systemd à tout va.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Ah le désespoir
Posté par Albert_ . Évalué à 2.
Ben critiquer systemd et donc regarder ce qui se passe chez la concurrence c'est un peu logique … vu les merdes que systemd a eu recemment niveau securite. Alors moi je suis qu'un trolleur mais bon quand meme Linus commence a peter un cable je pense qu'il peut y avoir des questions a se poser mais bon sinon on peut encore utiliser des OS merdiques si on refuse de poser les questions.
Par exemple:
https://usn.ubuntu.com/usn/usn-3341-1/
Systemd veut tout faire et en fait clairement trop aujourd'hui. C'est ce que l'on appele a "single point of failure".
[^] # Re: Ah le désespoir
Posté par freem . Évalué à -4. Dernière modification le 26 juillet 2017 à 15:08.
Yep. C'est un peu ce que les détracteurs se sont tués à expliquer. Moi, j'ai envie de dire: "Et SPOF dans vos faces les pro-sysd!".
(pas pu m'empêcher pour la vanne merdique)
[^] # Re: Ah le désespoir
Posté par claudex . Évalué à 9.
Ça n'affecte que les gens qui utilisent systemd-resolved. Il n'est pas obligatoire.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Ah le désespoir
Posté par FredBezies . Évalué à 0.
Encore cette histoire du systemd-resolved qui n'est presque jamais activé ?
Un libriste qui en a sa claque des puristes.
[^] # Re: Ah le désespoir
Posté par Yth (Mastodon) . Évalué à -5.
Bah Slackware a l'air de représenter entre 9% et 10% des Linux, et n'est pas la seule distribution sans systemd.
Donc le 95% est bien ce qu'il semble être : trollesque.
Maintenant si tu avais dit 80%, l'idée était la même, et déjà bien plus difficile à réfuter.
Mais bon, quand on trolle, on ne compte pas :)
Yth.
[^] # Re: Ah le désespoir
Posté par freem . Évalué à 7.
source?
[^] # Re: Ah le désespoir
Posté par Yth (Mastodon) . Évalué à -2.
J'ai peut-être mal cherché, mais la seule source que j'ai trouvé c'est celle-là :
https://www.linuxcounter.net/statistics/distributions
Sur distrowatch on a juste la popularité des pages des distribs, ce qui n'indique pas grand chose sur leur utilisation.
Et ailleurs, rien trouvé de spécialement pertinent…
Ça m'embête de n'avoir qu'une seule source, généralement j'aime bien recouper et me faire une meilleure idée, mais c'est une question difficile.
Yth.
[^] # Re: Ah le désespoir
Posté par Renault (site web personnel) . Évalué à 7.
Site qui a un biais assez fort lié au niveau technique et à la date de première installation (ce site était populaire il y a longtemps, bien moins aujourd'hui).
Honnêtement, je n'ai jamais croisé plus qu'un couple de Slackware en utilisation dans n'importe qu'elle convention du LL que j'ai assisté. 5-10% de Slackware cela me semble bien trop élevé par rapport à la réalité du terrain.
De toute façon sur la question, c'est difficile d'avoir des chiffres absolus, et cela dépend si tu prends en compte ou non les serveurs et machines virtuelles.
[^] # Re: Ah le désespoir
Posté par freem . Évalué à 5.
Si on suppose que les gens qui vendent des journaux le font en espérant toucher le public le plus large possible, alors je dirais que je n'ai juste jamais rien vu qui parle de slackware, a mettre en parallèle avec le fait que j'ai déjà vu des journaux parler de la famille BSD.
Le sentiment (ben oui, ce ne sont pas des chiffres, tout comme les chiffres de distrowatch ne concernent pas l'utilisation) qui s'en dégage, c'est que slack est ultra minoritaire en normandie et région parisienne (les lieux ou j'ai acheté ce type de magazines ces 4 dernières années).
Comme 10% ne me semble pas du tout ultra minoritaire, l'impression que j'ai est que ce chiffre est totalement faux.
Bon après, ma base de raisonnement est limitée dans le temps et l'espace, et je ne connais moi-même personne qui utilise linux au quotidien. Au niveau taf, les seules distrib que j'ai croisées sont Debian et CentOS, ainsi que Red Hat Linux en recherche d'emploi (pas croisée donc, mais a été mentionnée).
Si je m'en tenais a mon vécu "physique", slack n'existerait tout bonnement pas du tout, ce qui est évidemment faux. Par contre, même sur le net, on en parle quand même très peu, il y a peu de références à elle (comparé aux autres distrib linux et aux *BSD, hein).
Impossible, même. C'est impossible de chiffrer le taux d'utilisation d'une distrib gratuite au niveau mondial.
[^] # Re: Ah le désespoir
Posté par gouttegd . Évalué à 10.
En même temps, pourquoi parlerait-on d’une distribution dont le (quasi-)seul développeur n’est pas une grande gueule, n’a pas d’opinion tranchée sur Systemd, Wayland, Flatpak ou tous les autres sujets qui animent les forums des autres distributions, et globalement fait son job dans son coin sans faire d’histoires ? (À ma connaissance, la seule opinion tranchée bien connue de Patrick Volkerding est sa préférence marquée pour KDE par rapport à GNOME, et même là-dessus on ne peut pas dire qu’il soit très véhément.)
Slackware n’est pas non plus une distribution qui se fixe des objectifs grandiloquents (genre faire tomber Windows de son piédestal sur le marché du desktop, cf. un certain « bug numéro 1 »), et ne se précipite pas pour intégrer les dernières nouveautés.
Franchement, pourquoi parlerait-on de Slackware ? Les seules fois où il y a quelque chose à dire sur cette distribution, c’est pour annoncer une nouvelle version. Et à chaque fois, ça semble d’ailleurs surprendre du monde de constater que, ah tiens, Slackware est encore là.
Ben oui, Slackware est encore là. Ce n’est pas parce ce qu’elle est médiatiquement inexistante qu’elle a cessé d’être.
[^] # Re: Ah le désespoir
Posté par freem . Évalué à 2.
Mais du coup, comment une distribution quasi inexistante médiatiquement pourrait avoir 10% des utilisateurs de distrib linux, même en se limitant au monde serveurs et machines de bureau (parce que si on inclue android, c'est juste évident qu'on est loin des 10%)?
Je ne dis pas que son auteur devrait l'ouvrir plus, je réagissais juste à l'affirmation que slack représente 10% de PdM dans le monde linux sus-cité.
[^] # Re: Ah le désespoir
Posté par pasBill pasGates . Évalué à 8.
Site qui ne couvre que les hobbyistes, et qui compte probablement encore ma Mandrake d'il y a presque 20 ans.
Ayant connaissance des chiffres sur AWS je peux te dire que linuxcounter est à la ramasse.
[^] # Re: Ah le désespoir
Posté par Yth (Mastodon) . Évalué à 0.
Si tu as mieux comme chiffres, je t'en prie, fais-toi (et nous) plaisir et donne-les !
J'ai du mal à croire que Slackware et Gentoo, ainsi que leurs dérivés, ne fassent pas 5% des machines sous Linux.
Pas au vu du dynamisme des communautés, des retours, du nombre de mainteneurs (non, non, la Slackware au sens large, officiellement reconnue, n'est pas réduite à Patrick et à AlienBob).
Mais d'un autre côté, le nombre d'utilisateurs de Linux a beaucoup augmenté avec Ubuntu.
Après, les disparités locales sont une évidence. Il y a 15 ans en France c'était Mandrakiva la favorite, et le biais français la mettait clairement au dessus de son niveau international. Il y a peu de chance que les anciens utilisateurs de cette distribution soient 1) tous passés à Mageia, et 2) beaucoup passés à la Slackware. Essentiellement du fait de la différence de façon d'administrer qui sépare quand même beaucoup les Debianidés et les Redhatidés, des autres.
Ya-t-il un biais en Normandie ? Oui, comme partout.
Est-ce que 95% des installations Linux utilisent systemd ? J'en doute très fortement…
Ça ne change pas grand chose au propos initial, 95% c'est du trollage, mais dire probablement plus de 80% c'était crédible, difficilement réfutable sans une bonne dose de mauvaise foi, et servait tout aussi clairement ton propos.
Propos dont au final on se fout pas mal, parce que bon, Linux sur le desktop ça reste moins de 5%, complètement écrasé par Windows et MacOS, et ce n'est certainement pas une raison de le laisser tomber, pas plus que les BSD d'ailleurs, et d'accepter qu'il n'y a plus de lutte, et que tout est joué.
Ça n'a pas de sens, et en plus il n'y a pas d'opposition.
Qu'est-ce que ça pourrait faire que 95% des installation Linux utilisent systemd si j'ai envie de faire partie du 5% ?
Je n'ai pas conscience d'une guerre, pas conscience qu'on m'ait enlevé mon choix non plus.
Je ne me sens pas plus concerné que par l'existence de Windows ou MacOS, pas mon problème.
Yth.
[^] # Re: Ah le désespoir
Posté par pasBill pasGates . Évalué à 7.
Je ne peux évidemment pas donner de chiffres, pas le droit.
Faut que tu reviennes sur terre, ce qu'ils font est une goutte d'eau comparé à ce qui se passe chez Ubuntu & Redhat par exemple.
Tout à fait, mon propos était de souligner que l'idée d'aller tourner le marché Linux loin de systemd était une cause perdue, ensuite ce que les individus font, ou certaines distrib spécialisées font, c'est évidemment purement de leur ressort.
Notes bien que je dis tout cela en n'ayant personnellement pas de préférence pour ou contre systemd. C'est juste que voila, faut arrèter de réver à un moment… les faits sont là, systemd a pris sur toutes les grosses distribs, il ne disparaitra pas à moins qu'un autre système, nouveau lui-aussi, le remplace dans quelque années.
[^] # Re: Ah le désespoir
Posté par Mimoza . Évalué à 1.
Remet toi 10 ans en arrière (ou pas), remplace Systemd par Windows et on reparle de guerre définitivement gagné …
Pour rappel tu utilise un OS qui a une part de marché inférieur à 5% selon certains sondages.
[^] # Re: Ah le désespoir
Posté par pasBill pasGates . Évalué à 2.
Ben appelles moi le jour ou une boite énorme se met derrière Gentoo, et on en reparlera.
Note : aucun sondage réaliste ne donne Windows à 5%. Il y a plus d'un milliard de Windows en circulation, il n'y a certainement pas 20 milliard de smartphones et tablettes en circulation.
# Gentoo décidée ?
Posté par Damien Thébault . Évalué à 10.
Je dirais que gentoo est dans la catégorie "non décidée". J'ai un laptop en systemd et un serveur en openrc et les deux fonctionnent très bien, c'est au choix. Encore plus que Archlinux je dirais.
# Portnawak
Posté par patrick_g (site web personnel) . Évalué à 10.
Ouch ! Va dire ça à RMS et Linus et tu vas te prendre un coup de pelle.
Pour le reste je trouve ton trollo-journal assez médiocre et convenu. Non systemd n'est pas "en train de bouffer l'univers Linux" comme si c'était un prédateur venu de l'extérieur. Ce sont les développeurs de l'écosystème Linux qui ont décidé de créer et de passer à systemd. Ce sont eux, les faiseurs, et pas les commentateurs qui sont les créateurs de l'univers Linux.
[^] # Re: Portnawak
Posté par GG (site web personnel) . Évalué à -4.
Redhat à créé systemd.
Des développeurs des autres distributions Linux se sont résignés à ne maintenir de compatibilité qu'avec systemd et non plus avec les autres systèmes d'inits. Simplement parce que ça nécessite beaucoup de travail de prendre en charge plusieurs systèmes d'init.
Le passage vers systemd chez Debian ne s'est pas fait dans la joie.
Je n'en dis pas plus, je ne souhaite pas alimenter un éventuel troll.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Portnawak
Posté par Spyhawk . Évalué à 10.
En l'occurrence, des développeurs d'autres distributions Linux se sont décidés à passer à systemd simplement parce que ça nécessite moins de travail que de maintenir leur bousin system-v dans leur coin.
[^] # Re: Portnawak
Posté par xcomcmdr . Évalué à 9.
LOL, réécriture de l'histoire much ?!
Pour Arch par exemple, les développeurs étaient super motivés de passer à systemd, et depuis ils ne s'en portent que mieux.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Portnawak
Posté par WhiteCat . Évalué à 10.
Non.
Source : FAQ de systemd
Date : 2010
[^] # Re: Portnawak
Posté par Albert_ . Évalué à -6.
Petite question: c'est qui qui paie le salaire de LP?
[^] # Re: Portnawak
Posté par ff9097 . Évalué à 4.
Et qui paie le tien ?
[^] # Re: Portnawak
Posté par Sufflope (site web personnel) . Évalué à 7.
Quel rapport avec la génèse du projet s'il a démarré sur son temps libre ?
[^] # Re: Portnawak
Posté par WhiteCat . Évalué à 10. Dernière modification le 26 juillet 2017 à 17:00.
C'est Red Hat en effet.
Et Novell pour le co-auteur de systemd.
Alors dire que Red Hat a créé systemd est faux. Pourquoi ne pas prendre en compte Novell aussi ?
Déjà je ne sais pas si systemd a été créé au départ sur leurs temps de travail.
Ensuite je ne sais pas non plus si ce sont des dirigeants de chez Red Hat et Novell qui se sont dit un jour "tiens on va demander à 2 gars de chez nous de bosser sur un nouveau système d'init et bien plus encore".
Dans des grosses sociétés de ce genre, chez Google par exemple, des employés peuvent travailler quelques heures par semaine/mois sur des projet "perso". J'imagine que chez Red Hat ils doivent avoir la possibilité de faire cela. Par exemple David Airlie (Red Hat) qui bosse sur la pile graphique et pilote AMD depuis très longtemps, a créé il y a quelques années Virgil3D pour la virtualisation. C'est un "pet-project", Red Hat ne lui a jamais demandé de créer cela expressément à ce que je sache. La même chose a du se produire pour systemd.
LP a créé des logiciels (avahi puis pulseaudio) parce qu'il avait envie de bosser là dessus (pour des raisons qu'il explique parfois sur ses billets de blog). Faut pas y chercher un complot de Red Hat.
# Arch non-décidée ?
Posté par Nibel . Évalué à 10.
Chez Arch, Systemd est par défaut depuis Octobre 2012.
Donc c'est plutôt bien décidé…
Et pour avoir essayé d'utiliser OpenRC il y a de ça quelques mois, ça reste assez casse-gueule avec toutes les dépendances… La maintenance était tellement pénible que j'ai préféré retourner sous Systemd parce que ça "juste marche".
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Arch non-décidée ?
Posté par ianux (site web personnel, Mastodon) . Évalué à 8.
Oui, Arch a été une des première distributions à basculer sur systemd et à déprécier officiellement son propre système d'init.
De plus, certains mainteneurs de la distribution ont intégré l'équipe de développement de systemd.
Essayez de vous plaindre sur la mailing-list que votre système ne fonctionne pas bien parce vous refusez d'utiliser systemd et vous vous ferez jeter comme un malpropre, à juste titre.
[^] # Re: Arch non-décidée ?
Posté par Narmer . Évalué à 2.
Sur #archlinux-fr tu peux parler de ton problème d'openrc sans aucun soucis.. On continue de faire de l'informatique, les utilisateurs ont encore la liberté de faire leur choix techniques et être soutenus, à juste titre.
# Clarifications requises
Posté par potate . Évalué à 10.
GNU/Linux, un fork de BSD386 ? Si tu as des informations pour étayer je suis preneur, puisque je ne trouve pas grand chose là-dessus, mis à part Linus qui dit (en 1992) qu'il n'aurait pas commencé Linux si BSD386 avait été prêt plus tôt (ce qui me fait penser à Git vs Mercurial, mais c'est un autre sujet).
La phrase a un air de reproche, hors si ZFS n'a pas son module noyau intégré à toute les bonnes distros aujourd'hui c'est parce que la licence utilisée par ZFS (CDDL) est incompatible avec la GPL (merci Sun !). Donc côté Linux on n'y peut rien. Cela dit, si l'inclusion en binaire est proscrite, la compilation depuis les sources reste possible.
Là aussi la tournure est trompeuse : quand je lis ça, j'ai l'impression que OpenRC serait un fork de Systemd, mais en fait non.
Sortie d'OpenRC : 5 avril 20071
Sortie de Systemd : 30 mars 20102
Pour rappel : "Un fork, en français fourche ou encore embranchement, est un nouveau logiciel créé à partir du code source d'un logiciel existant."3
On en a entendu parler il y a plus ou moins longtemps.
Pour quelle raison on entendrait parler davantage bientôt ?
Et dans les mois qui vont venir il se passe quoi ? Systemd, c'était le sujet chaud fut un temps, mais maintenant plus trop.
https://en.wikipedia.org/wiki/OpenRC ↩
https://en.wikipedia.org/wiki/Systemd ↩
https://fr.wikipedia.org/wiki/Fork_(d%C3%A9veloppement_logiciel) (oui, ma source c'est Wikipédia pour tout, mais prout) ↩
[^] # Re: Clarifications requises
Posté par Maxime Ritter (site web personnel) . Évalué à -1.
GNU/Linux, un fork de BSD386 ?
Non, pas du tout, la phrase peut porter à confusion, c'est bien (386BSD->Net/Open/FreeBSD) d'un côté, et Linux de l'autre, les 2 projets n'ont vraiment rien à voir l'un avec l'autre. Tu dois probablement déjà connaître la cathédrale et le bazar, je n'ai malheureusement rien de mieux à te conseiller pour l'histoire de Linux.
(ZFS) La phrase a un air de reproche
Pas du tout, ou alors caché. Le sujet est systemd, pas le problème de la licence ZFS dont j'étais bien au courant.
Pour quelle raison on entendrait parler davantage bientôt ?
La version 1.0 est maintenant sortie (certes basée sur Jessie ou moment où Stretch sort), le site n'a plus l'air d'une vieillerie. Le projet me donne l'impression d'être de plus en plus actif.
Quand à systemd, il ne semble pas digéré par tout le monde. En tout cas, tant mieux si tu ne trouves pas le sujet chaud (pas mon cas, mais j'évite justement de suivre l'actualité de trop près) ; c'est que les gens vraiment fâchés auront migré de distrib.
[^] # Re: Clarifications requises
Posté par freem . Évalué à 0.
Le sujet est clairement clos.
Ce qu'il reste aujourd'hui, c'est des fanboys systemd qui tapent sur Devuan quand on leur annonce que, finalement, si, c'est possible de faire une grosse distrib sans systemd.
Bon, il faut reconnaître que ce serait pas mal si ils (devuan) pensaient à sortir de sysVinit quand même.
Les anti-systemd connaissent les distrib alternatives (Devuan pour le truc périodique, voidlinux pour la rolling release… et d'autres, y compris certaines dont je ne connais pas le nom) et soit les utilisent, soit restent sur leur distrib pro-systemd en changeant l'init.
Dans le cas de Debian, c'est relativement aisé, et perso je n'ai aucun des "problèmes de dépendance" suggéré par le… "journal".
[^] # Re: Clarifications requises
Posté par kna . Évalué à 6.
Il ne l'a pas précisé, mais ce journal a été posté il y a un an via IPoT
# Pas le problème mais la raison !
Posté par GnunuX (site web personnel) . Évalué à 9.
Encore la semaine dernière … un serveur dédié qui ne redémarre pas après une mise à jour. Évidement sur un serveur pas sous systemd … Franchement j'ai bien regretté systemd/journald.
On peut toujours discuter du sexe des anges mais les avancées de systemd sont suffisamment important pour justifier son inclusion dans les distributions majeurs.
Tous tes arguments … ce n'est que la rhétorique.
[^] # Re: Pas le problème mais la raison !
Posté par Le Gab . Évalué à 3.
En quoi systemd t'aurais permis de faire ce que tu n'a pas pu faire avec l'init classique ? Pas de troll, j'utilise et apprécie systemd, c'est donc une vraie question. À quel niveau ça a planté dans le boot?
[^] # Re: Pas le problème mais la raison !
Posté par GnunuX (site web personnel) . Évalué à 4.
La différence c'est qu'avec systemd/journald tu as les logs de tout, chronologique et facilement accessible. Là je n'avais strictement aucun log.
Le problème que j'avais ? Je n'en suis pas bien sûr (pas de log et pas d'accès à l'écran). Ca semble être liée à des règles de firewall qui ne s'appliqueraient pas.
[^] # Re: Pas le problème mais la raison !
Posté par freem . Évalué à -2.
Si je comprend bien, tu t'es formé à systemd, et pas au mécanisme de journalisation de la distrib en question, et tu râles de ne pas avoir les compétences?
Ah… oups, ça ressemble fort à un des argument que les pro-systemd utilisaient tant: t'es juste dans tes habitudes, faut penser a se former au reste.
M'enfin, pour le coup de dire que le trollnal n'a que des arguments de réthoriques, je suis bien d'accord, je n'ai rien vu de pragmatique et même pas un des réels arguments contre systemd. Mon avis: l'auteur se fait chier au taf parce qu'il a rien à faire en cette période de vacance, donc il lance un troll pour s'occuper ;)
[^] # Re: Pas le problème mais la raison !
Posté par Sufflope (site web personnel) . Évalué à 10.
Non, il y a un vrai apport avec systemd/journald, les logs sont capturés bien plus tôt qu'avec syslog dans la séquence de boot, et sont donc accessibles même après un reboot, là où traditionnellement si tu n'avais pas d'écran/console/… branché (pas gagné sur un serveur distant pas trop cher) ils auraient été perdus. Ce n'est pas qu'une question d'habitude des outils.
[^] # Re: Pas le problème mais la raison !
Posté par GG (site web personnel) . Évalué à 1.
Et comment on fait quand on relance un service (avec systemctl restart nginx, par exemple), pour avoir le retour d'erreur directement dans la console comme avant dans system-v?
Actuellement, avec systemd, je suis obligé d'avoir une autre console ouverte pour afficher les logs. Ou bien je peux utiliser journalctl et chercher le message d'erreur (et qui ne s'affichera pas au complet).
Je n'ai rien trouvé à ce sujet dans le man de sytemctl.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Pas le problème mais la raison !
Posté par claudex . Évalué à 6.
Et tu peux ajouter un
-upour limiter à ta unit.« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas le problème mais la raison !
Posté par Marotte ⛧ . Évalué à 4.
J’ajoute que systemctl a la bonne idée de t’indiquer cette commande lorsqu’une unit ne veut pas démarrer. Difficile de faire mieux.
[^] # Re: Pas le problème mais la raison !
Posté par Sufflope (site web personnel) . Évalué à 4.
Je ne sais pas, pour moi le principe d'afficher les erreurs via la commande journalctl que t'indique systemctl lors d'une erreur au démarrage d'un service n'est pas suffisamment laborieux pour que je cherche autre chose. Et désolé mais "pour avoir le retour d'erreur directement dans la console comme avant dans system-v" je vois pas en quoi c'était garanti. Suivant comment le script d'init était fait on pouvait très bien se fader une erreur dans les logs de l'appli et pas dans le retour du script, donc obligé là aussi d'aller lire un fichier de log.
[^] # Re: Pas le problème mais la raison !
Posté par claudex . Évalué à 6.
Je suis d'accord, mais justement les bons scripts d'init affichaient directement une belle erreur. Alors qu'avec systemd, même avec une unit bien écrite, on n'a rien.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas le problème mais la raison !
Posté par GnunuX (site web personnel) . Évalué à 4.
Personnellement ça ne me gène pas parce que le "status" donne explicitement les erreurs en cas d'erreur de démarrage. Ca reste rapide pour trouver les messages d'erreurs. Par contre, il faut effectivement 2 commandes.
Il manque peut être une option pour afficher les erreurs au démarrage/arrêt.
[^] # Re: Pas le problème mais la raison !
Posté par Sufflope (site web personnel) . Évalué à 7.
Je ne vois pas ce que tu veux dire. J'ai arrêté
httpdet fait unnc -l 80dans un screen :Alors oui deux commandes pour avoir l'erreur, mais au moins je sais que je vais l'avoir de manière standard. Et surtout je n'ai pas rien…
[^] # Re: Pas le problème mais la raison !
Posté par freem . Évalué à 2.
Tu veux dire les logs du kernel, ou des services?
Concrètement, qu'est-ce qui empêche les services d'avoir leur stdout/err redirigés par le script d'init (que ce soit sysV ou un autre, on s'en cogne) dans un fichier propre?
[^] # Re: Pas le problème mais la raison !
Posté par GnunuX (site web personnel) . Évalué à 4.
Rien. Sauf qu'a priori ce n'est pas fait (puisque je n'ai pas de log).
Il n'y a pas de mécanisme prévu pour que pour je modifie le script d'init tout en conservant les mises à jour (ben oui si tu modifie un fichier dans /etc sous debian/ubuntu il n'est plus mis à jour). Donc j'évite (surtout avec mes faibles compétences en ma possession).
[^] # Re: Pas le problème mais la raison !
Posté par freem . Évalué à -1.
Voila. Donc c'est bien ce que je disais, l'argument que j'ai souvent lu en provenance d'un pro-systemd vers les autres se retourne bien ici.
Et tu le prouves ici:
Faux pour pas mal d'entre eux. A minima, les conf de vim et de bash, probablement d'autres, je n'ai pas une mémoire d'éléphant.
Le logiciel te demande ce que tu veux faire, typiquement: prendre la version du mainteneur, regarder le diff ou garder ta version. En tout cas, sous Debian. Conclusion, il est très possible de générer un diff avant (voire pendant) la MàJ et de porter le diff après la MàJ en ayant accepté au préalable la version du mainteneur.
[^] # Re: Pas le problème mais la raison !
Posté par GnunuX (site web personnel) . Évalué à 2.
Tu fais référence à quel argument ?
Effectivement, mais je ne fais jamais les mises à jour à la main mais j'utilise des outils comme "unattended-upgrades".
[^] # Re: Pas le problème mais la raison !
Posté par freem . Évalué à 0.
Le coup du "c'est juste que vous ne voulez pas apprendre".
D'ac. Du coup, ça se passe comment si dpkg pose une question à l'utilisateur? Je n'ai jamais utilisé ce type d'outils, j'ai toujours repoussé ça à plus tard, un peu comme le backup de mes données -.-'
[^] # Re: Pas le problème mais la raison !
Posté par GnunuX (site web personnel) . Évalué à 3.
C'est marrant comme remarque :) Ma phrase faisait référence à la phrase que tu as écrite :
Donc tu me reproches à moi de faire référence à tes propres arguments ?
Très marrant.
dpkg prends la valeur par défaut au question posée si je me souviens bien.
[^] # Re: Pas le problème mais la raison !
Posté par freem . Évalué à -1.
Ce n'était pas un reproche, en soi. En fait, j'avoue m'être laissé séduire par la possibilité de retourner cet argument pénible si souvent utilisé par les pro-systemd contre l'un d'entre eux, qui n'y est d'ailleurs probablement pour rien ;)
Merci.
[^] # Re: Pas le problème mais la raison !
Posté par Sufflope (site web personnel) . Évalué à 6.
Vu que je parle explicitement de logs capturés très tôt dans la séquence de boot, il me semblait assez clair que je ne parle pas d'un petit problème du genre httpd qui ne démarre pas, mais bien de problèmes plus grave donc plutôt kernel en effet. Je me souviens qu'il y avait eu des articles sur le fait que systemd de par sa conception permettait une capture des logs à un moment où ça aurait été simplement impossible pour SysV/syslog.
Enfin bon, comme d'habitude avec les anti-systemd primaires, "qu'est-ce qui empêchait qu'on le fasse alors qu'on l'a pas fait pendant 15 ans ? hein ?". Bah, j'en sais rien, c'était à vous de le dire ou de le faire avant, justement…
[^] # Re: Pas le problème mais la raison !
Posté par freem . Évalué à -1.
Anti-systemd primaire? Si ça t'amuse de le croire…
Concrètement, les trucs que je reproche à systemd c'est bien de ne pas avoir de limites fonctionnelles définies, ce qui me paraît dangereux pour un projet, et de ne pas être portable, ce qui est un choix totalement défendable. Juste, moi, je préfère utiliser du code portable, au cas ou un jour je décide que finalement linux ne me conviens pas.
Si jamais tu as un de mes messages dans lequel je dis un truc du style que je préférerai que systemd n'ai jamais existé, ou qu'il devrait mourir, je veux bien un lien.
Des anti primaires, il y en a, certains ont même utilisé l'argument qu'ils n'aiment l'auteur comme argument contre. Si je l'ai fait, prouves-le.
J'ai aussi vu des arguments techniques stupides genre que sysVinit est parfait et moderne. Perso, quand j'ai appris la naissance de systemd et l'idée générale, j'étais enthousiaste. Parce que j'avais déjà essayé de lire le tas de spaghettis qu'étais le système d'init de Debian.
Ma question était honnête, y compris celle sur le kernel.
Maintenant, je vois assez mal comment un système d'init, de manière générale, pourrait accéder aux logs du kernel alors que les autres ne le pourraient pas.
Clairement, systemd peut utiliser l'API spécifique du kernel, c'est très possible. Mais il me semble que le kernel expose énormément de choses via un système de pseudo-fichiers, accessible donc par n'importe quel soft POSIX, et j'imagine que les logs en font partie.
Si j'ai bien compris, tu soupçonnes le pare-feu de faire planter le kernel? Mouai. Et t'as pas les logs? Re-mouai. Je sais pas ce que tu utilises pour configurer ton pare-feu, mais je doute fort que la sortie d'erreur ne soit pas redirigeable vers un fichier.
Et dans ce cas, le coupable du manque de logs, c'est pas l'init hein, non non, c'est l'admin qui n'a pas fait son job. Job peut-être plus simple avec systemd, pourquoi pas, mais vu que tu ne nous donne pas de détails sur les logs qu'il te manque, on ne peux même pas le prouver.
En fait, comme tu te contente de supposer, il n'y a même aucune preuve que systemd aurait fait le taf. Au lieu de ça, tu m'attaques personnellement. La classe.
[^] # Re: Pas le problème mais la raison !
Posté par GnunuX (site web personnel) . Évalué à 7.
Moi je n'ai jamais parlé de Kernel. Ma préoccupation était de remettre en place le plus rapidement le serveur. Donc … ben j'ai regardé les fichiers de log modifiés depuis le dernier reboot. Et ben …, rien d'intéressant. Non je n'avais pas envie de modifier des scripts d'init pour avoir plus de log.
J'ai désactivé le service du firewall (au hasard) et j'ai redémarré. J'ai eu accès au serveur. Je n'en sais pas plus malheureusement (est-ce que le firewall étant en cause ? aucune idée).
Avec systemd/journald j'aurais au moins pu savoir quels services étaient démarrés ou non au dernier reboot ainsi que les logs et les status. C'est tout ce que j'ai dit.
Après mon propos était de dire que, pour moi, les apports techniques sont bien évidement a prendre en compte, parce que, pour moi, systemd me simplifie la vie. Pour ne citer que ce qui me passe par la tête : journalctl, systemctl is-system-running, systemclt status xxx, systemctl --state=failed, systemctl edit xxxx, systemctl set-environment xxxx n'ont pas d'équivalent aussi puissant et simple.
La perte de diversité supposée, la personnalité de Lennart, le changement de philosophie, et le reste du blah blah ne me préoccupe pas le moins du monde.
[^] # Re: Pas le problème mais la raison !
Posté par freem . Évalué à 4. Dernière modification le 27 juillet 2017 à 10:36.
Et sur ce point je suis d'accord. Chacun utilise bien ce qu'il veut.
Possible. Mais j'ai bien l'impression que
systemctl status xxxà une variante pour les sysVinit. Pas sous Debian la (à mon grand regret) mais ça ressemble àservices status xxx?Pour
systemctl --state=failedeffectivement, en général je me fade une commande à rallonge, combo de grep et de redirection de stderr vers /dev/null.Le reste, je ne sais pas, et/ou ne vois pas nécessairement l'utilité (différents usages, différents besoins).
Ca, c'est une connerie: le fait de proposer un autre modèle augmente la diversité. Si d'autres projets meurent parce que plus utilisés et remplacés par systemd, c'est juste qu'ils ne sont pas assez efficaces.
SysVinit ne me manquera pas, et grâce à systemd j'ai découvert runit, qui à son tour m'a fait découvrir voidlinux.
Perso, j'y ai gagné, dans cette affaire. Je n'ai pas l'intention d'utiliser systemd, j'ai mes raisons, mais je sais que sans systemd je n'aurai pas fait ces recherches et je n'aurai pas appris tout ce que j'ai pu apprendre sur l'init.
[^] # Re: Pas le problème mais la raison !
Posté par GnunuX (site web personnel) . Évalué à 4.
systemctl is-system-running : te dis si le système est complètement démarré et sans erreur (c'est quand le minimum qu'on puisse demander)
systemclt status xxx == service xxx status
systemctl edit xxxx : te permet de personnaliser un script d'init
systemctl set-environment xxx : te permet de setter de variable d'environnement
Je pourrais rajouter à la liste :
systemd-cgls pour voir le contenu des cgroups
systemd-cgtop pour l'usage des ressources des cgroups à la top
systemd-analyze plot > plot.svg : pour avoir les graphs de démarrage en svg
Et plein de détail dont je ne pense pas là tout de suite.
[^] # Re: Pas le problème mais la raison !
Posté par Sufflope (site web personnel) . Évalué à 10.
Écoute, tu demandes en quoi systemd/journald changent quelque chose, notamment pour diagnostiquer un problème de démarrage, j'explique une première fois en quoi (il capture les logs beaucoup plus tôt dont certains qui étaient auparavant volatiles).
Tu me réponds "tu parles de logs de services ? avec 45 lignes de bash on aurait pu faire pareil", je ré-explique que je parle de capture de logs très tôt au démarrage de la machine, au passage je demande pourquoi ça n'était pas fait avec SysV/syslog si c'était si simple. Et oui, je fais remarquer que selon moi ça sent le mec qui veut absolument trouver un truc à redire sur systemd.
Maintenant il faut que j'explique je sais pas quoi ? Non, désolé, j'arrête là.
[^] # Re: Pas le problème mais la raison !
Posté par freem . Évalué à 0.
Bah en gros j'essaie de comprendre comment il fait, et donc pourquoi ce serait infaisable par les autres. Tout bêtement. A partir de la, je pourrai ensuite vérifier que les autres ne le font effectivement pas.
Par exemple, si je te demande s'il fait en gros le même travail que klogd (
The klogd program will extract messages from the kernel log buffer) mais dès le début, je me trompe ou pas? Ou est-ce qu'il utilise un truc plus bas niveau, ce qui serai impossible à d'autres qui refuseraient le code spécifique à un OS?[^] # Re: Pas le problème mais la raison !
Posté par xcomcmdr . Évalué à 2.
C'est exactement pourquoi systemd log bien plus que les autres systèmes d'init.
Il n'a pas peur d'utiliser des API spécifiques à Linux.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pas le problème mais la raison !
Posté par freem . Évalué à 2.
Ce qui est à la fois une bonne et une mauvaise chose. C'est une bonne chose parce que ça permets une meilleure intégration, et pour la majorité qui se contrefiche (avec raison) de la portabilité c'est juste positif.
# Slackware ?
Posté par gouttegd . Évalué à 9.
En quoi le système d’init de la Slackware est « particulier » ?
Slackware n’a pas un init qui lui est propre, elle utilise le sysvinit de Miquel van Smoorenburg dont l’historique remonte à 1992 (un an avant la naissance de la Slack). Rien de spécifique à Slackware, Debian et RedHat par exemple utilisaient aussi cet init.
Et moi ce que je vois mal, c’est Patrick Volkerding se farcir la maintenance d’une alternative à Systemd. Le jour où intégrer Systemd représentera moins de travail que de continuer à faire en sorte que tout fonctionne sans Systemd, m’est avis que la décision sera vite prise (comme ça a été le cas pour PulseAudio, quand Pat s’est rendu compte que les dernières versions de Bluez — la pile Bluetooth pour Linux — dépendaient de PulseAudio).
Bof, pas si sûr.
Tiens, puisqu’on parle de Slackware, quelqu’un a prophétisé un « exode massif » des Slackeux vers les BSD si jamais un jour Slackware passe à Systemd. J’avoue n’avoir pas lu les 113 pages (!) de la discussion, mais rien qu’à voir quelques réactions sur la première page, cette prophétie a l’air assez bancale :
Et je m’ajoute volontiers à cette liste : si j’apprécie Slackware, c’est pour la distribution dans son ensemble, pas parce qu’elle est systemd-free.
Ah , et pour donner des sueurs froides à certains : Systemd dans Slackware, ça existe déjà. :D
# S'il te plaît Lennaert, remplace GRUB
Posté par Le Gab . Évalué à 7.
Si il y a bien une pièce du système d'initialisation de GNU/Linux qui me gave, c'est l'amorceur GRUB.
[^] # Re: S'il te plaît Lennaert, remplace GRUB
Posté par Sacha Trémoureux (site web personnel) . Évalué à 6.
systemd-bootd en EFI ça marche bien :)
[^] # Re: S'il te plaît Lennaert, remplace GRUB
Posté par Le Gab . Évalué à 1.
Cool, mais ça a l'air d'être limité à UEFI, non?
Extrait de la page Wikipedia:
C'est fâcheux. :/
Je vais tester. La question toutefois est de savoir comment ça survi à une mise à jour majeure de distribution.
Mais bon, ai-je vraiment envie d'activer UEFI ??? :)
[^] # Re: S'il te plaît Lennaert, remplace GRUB
Posté par Sacha Trémoureux (site web personnel) . Évalué à 3.
J'utilise ça que sous Arch, donc je sais pas trop comment ça marche en dehors.
Sinon activer l'UEFI apporte plus d'avantages que d'inconvénients si la carte mère n'est pas trop vieillotte.
[^] # Re: S'il te plaît Lennaert, remplace GRUB
Posté par David Demelier (site web personnel) . Évalué à 2.
Ça existe depuis un moment et ça s'appelle systemd-boot (voir bootctl).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: S'il te plaît Lennaert, remplace GRUB
Posté par freem . Évalué à 4.
Tu peux utiliser autre chose hein. Lilo est certes pas terrible, mais syslinux marche très bien tout en étant simple à configurer.
# Lancé médiocre
Posté par Maclag . Évalué à 10.
Allons-y dans l'ordre:
1.Les journaux trolls vides de nouveaux arguments au débat, par tradition, c'est le vendredi
2.Le troll systemd contre les autres init, il commence à passer de mode
3.Le troll "systemd est monolitique" n'impressionne plus personne depuis que Trump twitte n'importe quoi tous les jours, mais en plus en réussissant l'exploit de se renouveler constamment, lui!
Sérieusement, vous ne voulez pas prendre un peu de risques et faire original, genre je ne sais pas moi, "Wayland va casser la pile graphique", ou "BTRFS c'est de la merde parce que c'est pas optimal sur ma clé USB"?
[^] # Re: Lancé médiocre
Posté par Moonz . Évalué à 1.
C’est quoi le problème de btrfs sur une clé usb ?
[^] # Re: Lancé médiocre
Posté par Sacha Trémoureux (site web personnel) . Évalué à 10.
Avec alsa ça fonctionnait mieux.
[^] # Re: Lancé médiocre
Posté par modr123 . Évalué à 5.
trump n'a pas dit de mal de systemd si c'est pas la preuve que c'est nul ?
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
# lag
Posté par Psychofox (Mastodon) . Évalué à 10.
On dirait que ce journal a été écrit il y'a 5 ou 6 ans.
[^] # Re: lag
Posté par Spyhawk . Évalué à 10.
Quelque chose me dit qu'il utilise Debian.
[^] # Re: lag
Posté par freem . Évalué à 7.
Perso, a voir les connaissances sur l'histo des distro dont il fait étalage, je dirais qu'il utilise Windows.
# Scripts inits : ça marche toujours sous Debian
Posté par damaki . Évalué à 2.
Tout n'est pas noir au sujet de la migration systemd. systemd-sysv-generator aide pas mal pour la migration des scripts /etc/init.d ; les scripts fonctionnent par défaut. Ce qui n'est pas le cas sous Arch, versions 2017. Et avec la commande "service" et les logs syslog activés par défaut à l'ancienne, la migration s'est vraiment faite sans accroc sous Debian.
Autant, je ne vois pas le bénéfice de ma petite lorgnette, autant, c'est clairement pas pire qu'avant.
# Bof...
Posté par harlock974 . Évalué à -1.
System V, systemd ou openRC ? M'en fiche, je n'utilise aucun de ces programmes (du moins pas de façon consciente).
# OpenRC
Posté par pizaninja . Évalué à 2.
Quelle aurait été ma joie si j'avais pu avoir un peu plus d'infos sur OpenRC en lisant ce journal !
Mais non, je n'ai vu qu'une amorce de troll, suivi de trolls en pagaille.
Tant pis, j'irai m'informer ailleurs…
Sinon, OpenRC, ça a quoi de particulier ?
[^] # Re: OpenRC
Posté par Albert_ . Évalué à -2. Dernière modification le 27 juillet 2017 à 09:55.
system d'init moderne pour Unix contrairement a systemd qui est, a la base, un systeme d'init moderne pour linux only et qui maintenant fait aussi le cafe, creuse des trous et, pour certains, d'objet de jouissance.
[^] # Re: OpenRC
Posté par freem . Évalué à 3.
De ce que j'ai retiré de mes diverses lectures, ça semble offrir nativement le support du parallélisme et la gestion des dépendances.
Ces points sont 2 des points d'accroche initiaux de systemd selon moi, avec en bonus non négligeable la facilité de configuration (aka: possibilité d'éviter les scripts mais plutôt d'utiliser des fichiers de config plus traditionnels).
Je ne sais pas s'il y a d'autres points intéressants dans OpenRC.
Perso, j'ai plus été séduit par runit qu'OpenRC, la configuration est nettement plus triviale. En revanche, pas de gestion des dépendances, il faut le faire manuellement: soit un programme sait qui dépend de lui et créées leurs liens symbolique (ce qui serait une grosse galère à maintenir) soit un programme sait de quels services il dépend et attend gentiment que ceux-ci soient démarrés, par exemple en scrutant la création d'un fichier PID (a priori, simple à faire et à maintenir).
[^] # Re: OpenRC
Posté par Fopossum . Évalué à 2.
Un début de réponse sur DLFP et un peu plus d'infos sue le wiki de Gentoo
cd /pub && more beer
# T'es courageux...
Posté par apkwa . Évalué à -6.
Tu es courageux de faire une telle déclaration sur LinuxFR, là où le moindre commentaire pouvant être perçu comme défiant systemd est qualifié de rageux.
Là où tous les commentateurs ponctuaient leurs phrases de liberté, vie privée, interopérabilité, NSA, … il n'y a personne pour s'insurger que systemd envoie tes requêtes DNS chez google, ou qu'il se foute de POSIX.
Je ne parle pas de la fâcheuse tendance qu'il a de reparser les usernames ou les noms DNS et de faire n'importe quoi au cas où nous aurions eu l'idée d'utiliser un username que systemd. n'estime pas valide.
Donc oui, je pense que tu as tout à fait raison quand tu parles d'un changement de philosophie. Systemd impose sa loi. Là encore la plupart des gens ici étaient heureux de la diversité, et sont finalement ravis de l'uniformité qu'impose systemd. Va comprendre.
[^] # Re: T'es courageux...
Posté par xcomcmdr . Évalué à 1.
Wut ?
Avant, tout le monde utilisait SystemV ou autre chose.
Maintenant, tout le monde utilise systemd ou autre chose, y compris parfois SystemV.
LOL, la "perte" de la diversité…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: T'es courageux...
Posté par Sufflope (site web personnel) . Évalué à 10. Dernière modification le 28 juillet 2017 à 13:38.
Il parle du fait que, par défaut et de manière configurable à la compilation, et si c'est pas non plus surchargé dans la configuration, si tu te retrouves avec du réseau mais, dieu sait pourquoi, sans DNS configuré, alors quand tout ça est réuni, systemd se rabat sur
8.8.8.8pour assurer un fonctionnement normal.Ce qui bien évidemment via la magie de Twitter et des trolls anti-systemd, est devenu Lennart envoie toutes vos requêtes à Google.
[^] # Re: T'es courageux...
Posté par GnunuX (site web personnel) . Évalué à 0.
Même pas ! Il faut aussi que tu utilise systemd-resolved.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.