Gentoo Archives: gentoo-user

From: "Canek Peláez Valdés" <caneko@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
Date: Tue, 18 Feb 2014 19:34:57
Message-Id: CADPrc81dHATj8jX_o7QHBs-QGJ5BnYBdqrLLcwLCkVFOGAzS5g@mail.gmail.com
In Reply to: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie by Tanstaafl
1 On Tue, Feb 18, 2014 at 1:09 PM, Tanstaafl <tanstaafl@×××××××××××.org> wrote:
2 > On 2014-02-18 1:54 PM, Canek Peláez Valdés <caneko@×××××.com> wrote:> On
3 > Tue, Feb 18, 2014 at 12:31 PM, Tanstaafl <tanstaafl@×××××××××××.org> wrote:
4 >>> I'm curious as to the extent of these programs, and to what extent
5 >>> they *truly* require systemd.
6 >
7 >> I don't understand what you mean by "the extent of these programs".
8 >
9 > Sorry, worded that badly... I meant, basically, how many programs now
10 > require systemd...
11
12 The packages requiring loingd.
13
14 >>> I can't for the life of me think of any reason that server daemons
15 >>> like postfix, dovecot, apache, etc would or could ever *require*
16 >>> systemd.
17 >
18 >> Neither of those packages would ever require systemd (nor any init
19 >> system). If they do, I would call that a bug.
20 >
21 > Then why should XFCE requiring it also not be a bug?
22
23 If XFCE requires systemd the *init system*, I agree it's a bug.
24
25 > I totally get XFCE *supporting* the use of logind, but why should it ever
26 > support *only* logind? That would seem insane to me.
27
28 If someone writes the support for non-logind systems (like the *BSDs),
29 everything is dandy and you and I are happy as clams.
30
31 >> All of those programs can use features provided by systemd (like
32 >> socket activation,
33 >
34 > OpenRC will supposedly soon support the use of sockets...
35
36 I suppose it will be different; but probably it can be made to work
37 for both. Again, if *someone* writes the support for each.
38
39 >> using the more advances features of the journal, etc.), but they can
40 >> be made optional.
41 >
42 > Exactly... it is the question of *requiring* it, or *only* supporting it,
43 > that doesn't make sense to me.
44
45 If the project supports both no one will complain. The thing is that
46 there will be projects that will only actively support logind, because
47 it works so much better than ConsoleKit. That's the case with GNOME.
48
49 If someone writes the famous logind replacement, again, everybody is
50 happy as a clam.
51
52 >>> Also, for those that do require it, what feature of systemd (that
53 >>> doesn't have an alternative available) is it that the program
54 >>> uses?
55 >
56 >> Again, basically logind. And there *is* ConsoleKit available as an
57 >> alternative.
58 >
59 > Ok, so the numerous times you and others have made comments about the 'many
60 > new features' of systemd, you only really meant logind?
61
62 No, we meant logind, the journal, hostnamed, timedated, the socket
63 activation, the new networking tool that will arrive with 209, and all
64 the features to handle and monitor services.
65
66 By the way, both GNOME and KDE (and I'm sure Xfce, eventually) are
67 planning on using systemd --user to handle the desktop session.
68
69 The normal session handling will keep working in both desktops, but
70 (and this is just an educated guess from my part) I think it will
71 happen the same as with logind: the new way to do things will work so
72 much better, and the other way will bitrot. Unless *someone* gives
73 time and code to maintain it.
74
75 >> But basically all the GNOME developers are using systemd, so the CK
76 >> support is getting bitrotten. That's why the Gentoo GNOME team decided
77 >> to depend on systemd, although the requirement is really logind.
78 >>
79 >> If *someone* creates a logind compatible replacement (it uses a simple
80 >> dbus API[1]), then even the GNOME suit in Gentoo could drop the
81 >> requirement for systemd. Ubuntu has been working on something like
82 >> this, and Mark Shuttleworth said that they will continue to work on
83 >> it, even with Ubuntu choosing systemd[2], so if/when that's available,
84 >> there will be no program that *requires* systemd, AFAIK.
85 >>
86 >> (Well, gnome-logs depends on the journal, but it's a GUI for a systemd
87 >> specific feature).
88 >>
89 >> Like I've been saying; no one is forcing nothing on no one. But
90 >> someone has to write/support/maintain the alternative.
91 >
92 > Excellent... so apparently, the only real new features that have any kind of
93 > dependency are logind and maybe journald,
94
95 systemd --user will be used at lest by GNOME and KDE.
96
97 > so all that would be needed are compatible replacements,
98
99 Exactly. If someone is willing and able to write and support those
100 replacements, your non-systemd world doesn't needs to change.
101
102 > and all of the noise about systemd consuming the world has been just that... noise?
103
104 That's been my *whole* point. Nobody is forcing nothing on no one.
105
106 Now, from the point of view of a distribution, they can decide that
107 the supported init system is only systemd. That's their choice. That's
108 what Fedora, OpenSUSE and Arch did. Debian will set systemd as
109 *default* init, but it will keep (I suppose) supporting multiple init
110 systems. They need to, since the non-Linux ports will never get
111 systemd support. I'm pretty sure Ubuntu will switch at some point to
112 only support systemd.
113
114 I think Gentoo will be like Debian; we will support multiple init
115 systems basically forever (and Gentoo also works in FreeBSD). It's
116 possible the council will decide to make systemd the default init
117 system... in twenty or forty years.
118
119 So no, the sky isn't falling, and the systemd virus is not spreading
120 to touch everything you know.
121
122 However, if someone doesn't step up and provide the functionality
123 provided for systemd, and some projects want to use said
124 functionality, there will be packages that will require systemd.
125
126 You want to use those packages and not use systemd? Step in and contribute.
127
128 Regards.
129 --
130 Canek Peláez Valdés
131 Posgrado en Ciencia e Ingeniería de la Computación
132 Universidad Nacional Autónoma de México