1 |
On Fri, Feb 21, 2014 at 1:42 AM, Andrew Savchenko <bircoph@×××××.com> wrote: |
2 |
> On Thu, 20 Feb 2014 18:08:43 -0600 Daniel Campbell wrote: |
3 |
>> It's marginally clever, but so clearly obvious at the same time. It's |
4 |
>> sad (to me) that the community didn't see it coming. Those who did have |
5 |
>> been written off as conspiracy theorists or FUDders. Time will reveal all. |
6 |
> |
7 |
> Indeed time reveals everything and part of this foiled plot |
8 |
> revealed itself two days ago. It was said earlier in the list by |
9 |
> systemd supporters, that this project is modular, fine split to |
10 |
> binaries and thus critical issues in the pid 1 are not that likely. |
11 |
> And just look at systemd-209 release notes: |
12 |
> |
13 |
> http://lists.freedesktop.org/archives/systemd-devel/2014-February/017146.html |
14 |
> [quote] We merged libsystemd-journal.so, libsystemd-id128.so, |
15 |
> libsystemd-login and libsystemd-daemon into a a single libsystemd.so |
16 |
> to reduce code duplication and avoid cyclic dependencies (see below). |
17 |
> [/quote] |
18 |
> |
19 |
> So all talks about systemd being modular are nothing more than |
20 |
> nonsense. Guess what will happen on segfault in libsystemd.so? |
21 |
> Segfaults in pid 1 are so nice to bear... |
22 |
|
23 |
You have no idea what are you talking about, do you? |
24 |
|
25 |
The systemd binary (you know, PID 1) *DOESN'T LINK AGAINST libsystemd.so!* |
26 |
|
27 |
It's for consumers of systemd's APIs. |
28 |
|
29 |
> And Canek please talk no more about how "talented" systemd |
30 |
> programmers are or even about how "professional" they are, because |
31 |
> they're no longer. They failed a trivial textbook example: what should |
32 |
> one do when libraries A and B have some common code and cyclic deps? |
33 |
> Push common code to library C. That's the Unix way and secure way. |
34 |
> Creating single bloated library will help in neither fencing nor |
35 |
> debugging, nor code audit. |
36 |
|
37 |
This actually I'm even willing to discuss. They give the rationale in |
38 |
the notes you linked: "he reason for this is cyclic dependencies, as |
39 |
these libraries tend to use each other's symbols." |
40 |
|
41 |
It's true, they could have splitted even more the libraries, but they |
42 |
instead coalesced them. If the libraries used each other symbols, then |
43 |
they basically are functioning as a single module, and then it can be |
44 |
argued that coalescing them is a good move. |
45 |
|
46 |
I'm not saying I agree; I think I also would have preferred for them |
47 |
to split the cycles into another library. But I give the benefit of |
48 |
the doubt to the maintainers, and certainly would still think they are |
49 |
talented enough. |
50 |
|
51 |
(And again, it's a "normal" library, for third-party consumers, not PID 1). |
52 |
|
53 |
> It looks like to me that ultimate goal of systemd is to consume as |
54 |
> much system and user tools and interfaces as possible. |
55 |
|
56 |
Yeah, that's the idea. They have been pretty clear and honest about |
57 |
it. They want systemd to be the standard basic plumbing of Linux. |
58 |
|
59 |
> Perhaps, in the |
60 |
> ideal systemd world there will be nothing but linux-systemd kernel and |
61 |
> systemd-stuff userspace. |
62 |
|
63 |
I would call it "systemd-aware" userspace, but yeah, again, that's the idea. |
64 |
|
65 |
> Shell communication will extinct, all major |
66 |
> application and daemons will be converted to systemd "modules". |
67 |
|
68 |
Why would you disallow shell communication? It's pretty useful. But it |
69 |
will be complemented with dbus IPC and systemd controlled processes. |
70 |
It works pretty much like this with GNOME right now. |
71 |
|
72 |
If you don't want this, just keep using OpenRC. Nobody is forcing |
73 |
systemd on you. |
74 |
|
75 |
> Of |
76 |
> course this goal will be never achieved as-is, but one may consider |
77 |
> it as an asymptote of their actions. |
78 |
|
79 |
They want systemd to be the basic plumbing of Linux, yes. |
80 |
|
81 |
Regards. |
82 |
-- |
83 |
Canek Peláez Valdés |
84 |
Posgrado en Ciencia e Ingeniería de la Computación |
85 |
Universidad Nacional Autónoma de México |