1 |
On Sunday 16 Feb 2014 16:50:26 Canek Peláez Valdés wrote: |
2 |
> On Sun, Feb 16, 2014 at 9:46 AM, Tanstaafl <tanstaafl@×××××××××××.org> |
3 |
wrote: |
4 |
> > On 2014-02-15 3:32 PM, Canek Peláez Valdés <caneko@×××××.com> wrote: |
5 |
> >> For Slackware, I have no idea. For Debian, no the only options were[1]: |
6 |
> >> |
7 |
> >> 1. sysvinit (status quo) |
8 |
> >> 2. systemd |
9 |
> >> 3. upstart |
10 |
> >> 4. openrc (experimental) |
11 |
> >> 5. One system on Linux, something else on non-linux |
12 |
> >> 6. multiple |
13 |
> >> |
14 |
> >> It should also be noted that no one in the TC voted OpenRC above |
15 |
> >> systemd AND upstart, and that while a couple voted systemd below |
16 |
> >> everything else, it can be argued that it was a tactical vote. |
17 |
> >> |
18 |
> >> Regards. |
19 |
> >> |
20 |
> >> [1]https://wiki.debian.org/Debate/initsystem/ |
21 |
> > |
22 |
> > I would really, really, REALLY like to see a thorough, civil debate |
23 |
> > involving those far more knowledgeable than I on the pros and cons of |
24 |
> > systemd vs OpenRC... |
25 |
> |
26 |
> Well, that's the pickle, isn't it? We have the usual stuff: |
27 |
> |
28 |
> • OpenRC wasn't able (until very recently) to properly do parallel |
29 |
> execution of daemons. There will be someone who will say "that isn't |
30 |
> important". |
31 |
> |
32 |
> • Then there is the inability of OpenRC to properly stop/monitor |
33 |
> daemons (everybody here had to use "/etc/init.d/daemon zap" at some |
34 |
> point, I suppose). Someone will say that there is experimental cgroups |
35 |
> support for OpenRC... "experimental" being the important word, and |
36 |
> there is also the little matter of that not being integrated into the |
37 |
> official package (AFAIU). Also, with that OpenRC loses the "advantage" |
38 |
> of being portable to FreeBSD and/or Hurd. |
39 |
> |
40 |
> • And of course, OpenRC is slow as hell compared to systemd (although |
41 |
> there are reports of being really fast using reentrant busybox... I |
42 |
> never used that way, so I don't know). Which again, someone will say |
43 |
> that "that doesn't matter because I never reboot my machine". Great. |
44 |
> |
45 |
> But then we have the whole load of features that systemd provides that |
46 |
> no other init system does (OpenRC included). That is an advantage if |
47 |
> you believe that having an standardized plumbing in all "mainstream" |
48 |
> Linux distributions has technical merit and is a good design. If you |
49 |
> believe so (like I and many others do), then systemd is several orders |
50 |
> of magnitude better than OpenRC. If you don't believe so (like many... |
51 |
> although apparently they are less and less as time goes by), then |
52 |
> systemd is the spawn of the devil and it should be killed with fire. |
53 |
> |
54 |
> For General Purpose Linux distributions, systemd is a godsend since it |
55 |
> solves and centralizes a lot of stuff that matters to a lot of people. |
56 |
> It's fast and small (if you remove the optional dependencies), so the |
57 |
> embedded guys like it. It offers (for the first time ever) proper |
58 |
> daemon control and management and O(log n) access logs, so the server |
59 |
> guys like it. And if offers proper session monitoring and seat |
60 |
> control, so the desktop guys like it too. |
61 |
> |
62 |
> But all those advantages only will be so, if you agree with having a |
63 |
> tightly integrated plumbing interface directly above the kernel and |
64 |
> below PAM and/or X (soon Wayland) sessions. It gets kind of |
65 |
> philosophical, which is why a lot of people taunts the fuzzy term |
66 |
> "UNIX philosophy" so much when they rave against systemd. |
67 |
> |
68 |
> > As it seems to me, the Debian OpenRC page says that the cons are not |
69 |
> > nearly as large as the systemd proponents would have us believe. |
70 |
> > |
71 |
> > https://wiki.debian.org/Debate/initsystem/openrc |
72 |
> |
73 |
> It's because they are cons only if you agree with systemd's view of the |
74 |
> world. |
75 |
> |
76 |
> I do. |
77 |
|
78 |
I think what people primarily object to is not the parts that systemd does |
79 |
well or does better than other init process start up systems. The main |
80 |
objection from what I understand is the removal of choice that systemd |
81 |
developers have forced upon users, by making certain architectural decisions. |
82 |
These are decisions which may look optimal for RHL, but appear to be less so |
83 |
for the rest of the *nix ecosystem given the objections to systemd across the |
84 |
populace. |
85 |
|
86 |
For some Gentoo users in particular, removing the choice of running /usr on a |
87 |
separate partition (without *forcing* the use of initramfs) created the first |
88 |
pain point, or wakeup call. Many complaints were posted on this M/L, |
89 |
centering on this removal of choice. Unlike binary distros Gentoo is all |
90 |
about choice, so the complaints were perhaps louder than elsewhere. |
91 |
|
92 |
People speaking of *nix design philosophy are not necessarily having a rant, |
93 |
but can be legitimately concerned that architectural decisions to hardwire |
94 |
systemd into Linux will remove choice from its wider user base. I am |
95 |
similarly concerned that a monoculture has less success of survival. The fact |
96 |
that Debian decided to embrace the systemd option will no doubt have an impact |
97 |
on what Gentoo follows. |
98 |
|
99 |
I am not educated in init start up systems to know why other options were not |
100 |
considered as part of the Debian debate. Is it that runit, or epoch or what- |
101 |
else are not even close in terms of functionality, versatility and choice? |
102 |
Framing a question can narrow the answers. |
103 |
|
104 |
I hope that whatever the Gentoo decision may be one day, it will not |
105 |
irreversibly remove choice from us Gentoo-ers. |
106 |
|
107 |
-- |
108 |
Regards, |
109 |
Mick |