1 |
On Mon, 17 Feb 2014 18:49:47 -0600 Canek Peláez Valdés wrote: |
2 |
> > The whole deep integration approach and lack of |
3 |
> > inter-module boundaries doesn't allow one to write replaceable blocks |
4 |
> > without crazy hacking. |
5 |
> |
6 |
> Well, then go and show them how it's done. And please don't say that |
7 |
> "it's already done", because if that were the case, no distro would |
8 |
> have adopted systemd. |
9 |
> |
10 |
> They adopted it because of the features it offers. |
11 |
|
12 |
What features? As far as I can see if we compare to openrc, the only |
13 |
missed feature is logind for which it is declared to be better than |
14 |
consolekit. I can't argue here because I never used either one. |
15 |
|
16 |
At this moment I have about 50 Gentoo boxes (in hardware) at my |
17 |
control including both personal and work hardware including laptops, |
18 |
desktops, production servers and two HPC setups (not to count |
19 |
hundreds of LXC containers). And I see neither reason nor need for |
20 |
systemd here. |
21 |
|
22 |
From what I can see, all this systemd boom started from Gnome's GDM |
23 |
dropping support for anything aside from systemd. Afterwards |
24 |
distributions started to switch to systemd one after another in order |
25 |
to fully support Gnome-3 setups. And now we have a little fact here: |
26 |
Lennart Poettering is a long time Gnome contributor. Which leads me to |
27 |
only one conclusion: situation we have now is a deliberate sabotage |
28 |
in order to acquire as much influence by RH as possible. Influence |
29 |
leads to a sales market expansion, which leads to a profit. So we |
30 |
have money here as a root cause of all this boom — a root of all evil |
31 |
and a root of systemd. All "features and benefits" are nothing more |
32 |
than just an excuse for the aim for market domination and more profit. |
33 |
|
34 |
> > Just imagine that one have PCI-E bus and this bug is being replaced |
35 |
> > with some other PC-systemd bus, where one have to interface each |
36 |
> > component differently. And if one removes e.g. audio card some other |
37 |
> > seemingly independent component e.g. network controller becomes |
38 |
> > broken. That is the nature of systemd and that is many people dislike |
39 |
> > this technology. |
40 |
> |
41 |
> That is a broken analogy; if logind has a bug, that doesn't affect |
42 |
> timedated, nor udev. |
43 |
|
44 |
No, it is not. You can not remove systemd-udevd and replace it |
45 |
with mdev or static dev without broking most of other systemd |
46 |
components. The same way in my analogy you can not remove audio card |
47 |
without broking network controller. |
48 |
|
49 |
> >> > That said, it seems to me that, for now at least, it isn't that big a deal |
50 |
> >> > to switch back and forth between systemd and, for example, OpenRC. |
51 |
> >> |
52 |
> >> It depends; right now you can't switch back and forth between OpenRC |
53 |
> >> and systemd without reemerging some stuff. Some of those packages |
54 |
> >> *could* be made to switch functionality at run time instead of compile |
55 |
> >> time, but SOMEONE has to write that support, and it's probably that |
56 |
> >> the upstream for the package will not accept those changes, since for |
57 |
> >> binary distributions it makes no sense to have the complexity on the |
58 |
> >> code of switching behavior at runtime when doing at compile time is |
59 |
> >> easier and the distribution generates one binary per architecture for |
60 |
> >> all its users. |
61 |
> > |
62 |
> > The most sane and fair solution was already proposed: create a |
63 |
> > systemd profile for those who need it. I personally highly dislike |
64 |
> > systemd technology, but I respect the right of other to shoot them in |
65 |
> > the leg (or head) as much as they want to. This is Gentoo: a universal |
66 |
> > constructor providing people means to build any system in any shape |
67 |
> > they need. |
68 |
> |
69 |
> If someone willing and able provides any choice, that choice will be available. |
70 |
|
71 |
What choice? For features neither used nor needed before? Before |
72 |
systemd we had our choice: sysvinit, openrc, runit, epoch... By |
73 |
enforcing unwanted features to us systemd takes our freedom and our |
74 |
choice. |
75 |
|
76 |
> > Unfortunately chances are that in future some software may become |
77 |
> > unusable or unsupported outside of systemd profile. But patches may |
78 |
> > be created and other profiles will continue to live the same way |
79 |
> > hardened exists now and will continue to exist later. |
80 |
> |
81 |
> Yeah, and that's my whole point: if you want that the world outside of |
82 |
> systemd keeps working, you need to step in. Complaining about systemd |
83 |
> will get no one nowhere. |
84 |
|
85 |
That's the point of systemd adepts: we'll break things the way we |
86 |
want, fix them yourself if you dare. Behind the curtain you're just |
87 |
offloading your work to others or, more precisely, your time efforts |
88 |
to others. I don't like that. Do whatever you want to do, but please |
89 |
do not be intrusive into other domains and respect the freedom of |
90 |
choice of others. |
91 |
|
92 |
> > BTW it was shown at the recent LVEE Winter 2014 conference that GDM |
93 |
> > can be easily freed from systemd and OpenBSD guys have an interesting |
94 |
> > idea for faking systemd presence for applications requesting one |
95 |
> > mandatory. Though IMO any end-user application strictly dependable on |
96 |
> > any init system is broken by design: for a daemon there should be no |
97 |
> > difference by which tool it was started. |
98 |
> |
99 |
> GNOME depends on logind, not systemd. And no one has been willing and |
100 |
> able to produce a compatible replacement: logind works with a dbus |
101 |
> API, so it's (in theory) *easy* to duplicate its functionality. Ubuntu |
102 |
> has been working in a replacement, but (AFAIU) is not finished. |
103 |
|
104 |
And logind hardly depends on systemd . That's why Gnome depends on |
105 |
systemd. |
106 |
|
107 |
> > The real reason is money: systemd is a Red |
108 |
> > Hat project (despite being formally open for everyone) and is their |
109 |
> > tool^Wweapon to fight with Canonical for a sales market. It the last |
110 |
> > years RH was pushed near even in a server market and now they are |
111 |
> > fighting back. |
112 |
> |
113 |
> Nice conspiracy theory you have going on. |
114 |
|
115 |
You may call facts as like as you want to. This will not change them. |
116 |
|
117 |
> > They were lucky enough to acquire Poettiring guy and |
118 |
> > create from a simple and sound sysvinit (which is an important but |
119 |
> > not dictating peace of software) a key component where they can |
120 |
> > dictate their own line, where they can lead all Linux community in |
121 |
> > a way they need. |
122 |
> |
123 |
> And it gets better. Citation needed? Any hard proof? |
124 |
|
125 |
Citation for what? You're free to analyze fact and trends yourself. |
126 |
|
127 |
> > That the real reason I despise systemd: in replaces the freedom of |
128 |
> > choice by a dictatorship of a small bunch of managers of a single |
129 |
> > corporation (yes, managers, not developers). And all this is under the |
130 |
> > veil of GPL and technical merits. This is the poison in the well of |
131 |
> > FOSS. |
132 |
> |
133 |
> I don't work for RedHat; I teach in a University. Nobody pays me for |
134 |
> using systemd; I just choose to because I think is a technical sound |
135 |
> solution for the chaos that was the plumbing layer in Linux. |
136 |
|
137 |
This chaos is called freedom, freedom of choice, which leads to |
138 |
diversity, evolution and security. With every system unified in |
139 |
its core component we'll have a nice single and easily targeted point |
140 |
of failure. With systemd on most Linux distributions viruses (in |
141 |
terms of self-spreading windows malware) are just a matter of time. |
142 |
If this folly will not be stopped before it's spread you may recall my |
143 |
words in about five years. |
144 |
|
145 |
> The technical merits and advantages of systemd are there in the open |
146 |
> for anyone willing to study a little about it. *After* you carefully |
147 |
> read the code, the documentation, and test the software in real life, |
148 |
> you *may* still think you don't like the software or its design. |
149 |
|
150 |
Believe me or not, but I tested it, I read its docs and I studied its |
151 |
code. I vomited. |
152 |
|
153 |
There are two major types of failures: design failure and |
154 |
implementation failure. I'm tolerant to implementation issues, anyone |
155 |
have them after all. But monolithic deeply integrated approach is |
156 |
flawed by design. Even this issue can be tolerated as long as project |
157 |
is supposed to be compatible and replaceable with other solutions |
158 |
(remember, everyone has right to shoot oneself in the leg). But if |
159 |
project is being aggressively enforced, this is no way to go. |
160 |
|
161 |
Best regards, |
162 |
Andrew Savchenko |