1 |
On Wed, 19 Feb 2014 10:19:43 +0000 thegeezer wrote: |
2 |
[...] |
3 |
> >> For all this talk about technical details, |
4 |
> >> nobody seems to notice the marketing |
5 |
> > A few people including myself have noted it earlier. |
6 |
> > |
7 |
> >> that's going on and frankly it disgusts me. |
8 |
> > And me too. |
9 |
> > |
10 |
> > |
11 |
> I have to confess that it does feel very evangelistic the approach from |
12 |
> folks pushing systemd. perhaps it is just because for some it has been |
13 |
> four years of looking at new ways of doing things, whilst others are |
14 |
> just realising now how different it is. |
15 |
> I saw an interesting blog post [1] that basically tried to convince |
16 |
> directly gentoo devs. |
17 |
> it was interesting because of this comment: |
18 |
> |
19 |
> <snip> |
20 |
> " |
21 |
> *Simon* |
22 |
> September 26, 2013 at 2:58 am |
23 |
> <https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/comment-page-1/#comment-756> |
24 |
> |
25 |
> |
26 |
> Yes, I think you’re dead on, there. It’s not that Gnome depends on |
27 |
> systemd – but it’s increasingly dependent on features that are only |
28 |
> provided by systemd. The example of OpenRC not behaving according to |
29 |
> GDM’s assumptions is a perfect illustration of that. It’s dependent not |
30 |
> on systemd, but on something that for practical purposes is |
31 |
> indistinguishable from systemd |
32 |
> " |
33 |
> </snip> |
34 |
|
35 |
It looks like systemd PR agents put it quite simple: my way or the |
36 |
highway. And it looks like Gentoo is the last major shelter for |
37 |
freedom we have. |
38 |
|
39 |
> the difficulty is that without knowing what features are required but |
40 |
> assumed to be there it becomes very difficult to build something the has |
41 |
> the API that logind or others might be requiring. an update of gnome |
42 |
> might require a new feature that is hot off the presses, and until it |
43 |
> breaks an openrc-logind system no one is aware of that requirement. the |
44 |
> API does seem to be online [2], albeit updated 30days ago; i can't |
45 |
> comment if this is up to date enough or not. |
46 |
> |
47 |
> I think the argument on the blog page is a bit disingenuous too - |
48 |
> essentially implying that if you want gnome then you must have logind, |
49 |
> and if you want logind you must supply the features supplied by systemd: |
50 |
> but to get a list of the features required is _your_ problem: go through |
51 |
> the gnome source code to find out. |
52 |
> these kinds of things are what folks are taking umbrage against. |
53 |
> |
54 |
> I'm also a little confused over the socket matrix feature. I think it's |
55 |
> very clever to be negotiating and buffering socket and mounts to |
56 |
> services that need them, but I haven't seen a good technical argument as |
57 |
> to why this is required. From my perspective i see it as xinet.d for |
58 |
> unix sockets and well, is anyone using xinet.d on a production server? |
59 |
> Hopefuly someone can enlighten me? also what happens if the socket |
60 |
> arbitrator dies ? |
61 |
|
62 |
1. We never use xinetd on either production systems or |
63 |
desktops/laptops. The only legitimate setup with xinetd I can recall |
64 |
is CVS server. Though the very CVS technology is obsolete this days |
65 |
(yes, I know portage tree is still using it and I'm looking forward |
66 |
for git migration). |
67 |
|
68 |
Socket activation feature is dubious at least. It looks like nobody |
69 |
from its developers cared to assume that services may start not as |
70 |
fast as they expect (e.g. network issues with cisco switches being |
71 |
too slow to answer dhcp which may take up to several minutes). That's |
72 |
why socket activation is extremely dangerous: it may cause services |
73 |
to fail _on_ start. Some may just crash and will be restarted (though |
74 |
not all services may be restarted after crash without manual |
75 |
interaction, e.g. some DB setups may fail badly), while other may |
76 |
loose some functionality and continue to work. |
77 |
|
78 |
Best regards, |
79 |
Andrew Savchenko |