1 |
On 5/26/13 9:37 AM, Micha³ Górny wrote: |
2 |
> By the way, we should really keep the separation between systemd itself |
3 |
> and the unit files. I agree that systemd is not the best thing we could |
4 |
> have. But the unit file format is, er, good enough -- and has |
5 |
> the advantage of eventually taking a lot of work from our shoulders. |
6 |
|
7 |
Unit files had been considered when I started exploring the idea, sadly |
8 |
Joost shown me their limitation wouldn't make people life exactly happy. |
9 |
|
10 |
> Although some of the ideas (esp. wrt targets) are near to crazy |
11 |
> and awfully hard to understand, that's what we have and trying to do |
12 |
> something else is eventually going to make people's lives harder. |
13 |
|
14 |
Making better mousetraps usually works fine: as long you have generators |
15 |
that are good enough to get something working nobody would complain. |
16 |
|
17 |
> We should *really* work on supporting the unit files within OpenRC |
18 |
> (aside to init.d files). That's a way to at least: |
19 |
> |
20 |
> a) reuse the work that has been done upstream already (when it was |
21 |
> done), |
22 |
> |
23 |
> b) have common service names and startup behavior in all relevant |
24 |
> distros (which is really beneficial to the users). |
25 |
|
26 |
Can be done notwithstanding the rest. |
27 |
|
28 |
> Considering the design of OpenRC itself, it wouldn't be *that hard*. |
29 |
|
30 |
It is sort of simple. |
31 |
|
32 |
> Actually, a method similar to one used in oldnet would simply work. |
33 |
> That is, symlinking init.d files to a common 'systemd-wrapper' |
34 |
> executable which would parse the unit files. |
35 |
|
36 |
A compiler is an option as well, as said unit -> runscript should map fine. |
37 |
|
38 |
> On the completely different topic, I agree that systemd design is far |
39 |
> from the best and the way it's maintained is just bad. I was interested |
40 |
> in the past in creating an improved alternative using compatible file |
41 |
> format and libraries, while choosing a better design, improving |
42 |
> portability and keeping stuff less integrated. |
43 |
> |
44 |
> But the fact is -- I doubt it will make sense, much like the eudev |
45 |
> project. And it will take much more work, and give much less |
46 |
> appreciation. |
47 |
|
48 |
Having stand alone component would probably win you many friends and if |
49 |
the whole thing could work on something |
50 |
non-linux-latest-with-latest-glibc you'd have one less technical concern. |
51 |
|
52 |
> First of all, working on it will require a lot of work. Seeing how |
53 |
> large systemd become and how rapidly it is developing, establishing |
54 |
> a good alternative (even dropping such useless parts as the Journal) |
55 |
> will take at least twice that work. |
56 |
|
57 |
You make clean blueprints, get enough people agreeing with them and |
58 |
implement simple workalike for what you care about. |
59 |
|
60 |
For example logind seems to be the current fad. |
61 |
|
62 |
> The systemd haters will refuse the project because of its resemblance |
63 |
> to systemd. The systemd lovers will refuse it because of its |
64 |
> resemblance to systemd. And the OpenRC lovers will want to design it |
65 |
> to resemble OpenRC which is just pointless. Then the few remaining |
66 |
> people will find systemd 'good enough'. |
67 |
|
68 |
systemd haters, as you name them, could be split in few groups: |
69 |
|
70 |
- those that consider systemd a bad idea because it is a single item |
71 |
with many parts that would break horribly, if your idea is to make it |
72 |
less tightly coupled and with less parts many would consider helping. |
73 |
|
74 |
- those that consider systemd a bad idea because of the force feeding |
75 |
theme started with udev incorporation and continued with logind and |
76 |
such, again if you are creating alternatives the people would help gladly. |
77 |
|
78 |
- those that consider key part of systemd just wrong the limitation in |
79 |
the unit format or path activation as panacea, in that case you have to |
80 |
make clear the scope of your project, you might win few or lose some. |
81 |
|
82 |
> And even if there are a few people who will want to work on it, |
83 |
> and design a 'good systemd', they wouldn't get much appreciation. |
84 |
> Fedora definitely won't care for it. It would have to be really |
85 |
> definitely awesome for most Linux distros to even notice it. |
86 |
> And I doubt *BSD people would be interested in something external. |
87 |
|
88 |
Make it bsd and they would consider helping. |
89 |
|
90 |
> It is possible that systemd upstream will steal a few patches or ideas |
91 |
> from it. Yet they will never apply any of the really important changes, |
92 |
> so the project will have to be maintained indefinitely. The only hope |
93 |
> for it would be to win over systemd users which I doubt will happen. |
94 |
|
95 |
Or just make something useful, winning or losing is for the people using |
96 |
it. If it works and works fine people will use it. |
97 |
|
98 |
> So there's a lot of work, no fame or money in it, and most likely more |
99 |
> work being the only future. Anyone volunteering? |
100 |
|
101 |
Probably would be better sit down, figure out exactly what you want and |
102 |
see who has interest: |
103 |
|
104 |
E.g. |
105 |
|
106 |
Init-project |
107 |
|
108 |
- portable -> must work on non-linux and non-glibc more or less decently |
109 |
- modular -> loose coupling of functionality |
110 |
- robust -> the core functionality must not crash or remain |
111 |
inconsistent because of libdbus or such often occurring problems |
112 |
unrelated to |
113 |
- compatible -> should grok at least a good subset of systemd unit files. |
114 |
|
115 |
|
116 |
On a side note I really want to know in detail why you loathe openrc |
117 |
with this strength but we can discuss on irc. |
118 |
|
119 |
lu |