Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] Changing order of default virtual/udev provider
Date: Tue, 09 Feb 2016 15:04:31
Message-Id: CAGfcS_kAAo-G0YHA9D+N582mWi8kvG1HhvLHMJivj+et2sF0-Q@mail.gmail.com
In Reply to: Re: [gentoo-dev] Changing order of default virtual/udev provider by Daniel Campbell
1 On Tue, Feb 9, 2016 at 9:44 AM, Daniel Campbell <zlg@g.o> wrote:
2 >
3 > On 02/09/2016 05:44 AM, Rich Freeman wrote:
4 >
5 > If you go with systemd, you have to like or agree with
6 > every change they make or every design decision on everything.
7
8 There is a bit of irony in suggesting this in a discussion that
9 started with eudev, which is proof that you don't have to agree with
10 every decision they make on everything.
11
12 > I see where you're coming from, but there are situations where you
13 > really *do* want that server to stay down.
14
15 Of course, and auto-restarting a daemon is completely optional systemd behavior.
16
17 >>
18 >> Sure, systemd has more lines of code internally, but the difference
19 >> is that instead of having a bazillion independent bash scripts
20 >> maintained by different people at different levels of QA, you have
21 >> a single codebase that almost all distros share that is maintained
22 >> to a higher level of QA. Features are implemented once there
23 >> instead of a million times in various shell scripts.
24 >
25 > And that's where something like eclasses (but for rc scripts) could be
26 > used to consolidate all the redundancy. As far as I can tell we
27 > already implement something similar with the built-in functions that
28 > rc scripts are expected to have. The thing is, do we want to go in the
29 > direction of declarative files and the limitations that come with
30 > that? The complexity would then have to be migrated to the daemon
31 > manager itself instead of the scripts.
32
33 No need to go down that road. Somebody already wrote it for you. :)
34
35 > No matter how you look at it,
36 > managing daemons is non-trivial and rather complex. Most people aren't
37 > going to touch unit files *or* rc scripts unless they're developers,
38 > and most developers will read documentation. If anything, a developer
39 > will have more control over how their daemon is handled in the rc
40 > script. They would have to read systemd's C code or its plethora of
41 > unit options to set it up 'just right' to achieve the same.
42
43 That sounds like suggesting that in order to edit my postfix
44 configuration I need to reverse engineer the software.
45
46 You just grep the manpage for whatever you're looking for. I'll give
47 you two guesses as to what this option does:
48
49 IOSchedulingClass=
50 Sets the IO scheduling class for executed processes. Takes
51 an integer between 0 and 3 or one of
52 the strings none, realtime, best-effort or idle. See
53 ioprio_set(2) for details.
54
55 >>
56 >> The only reason we had OpenRC is that EVERYBODY was rolling their
57 >> own service managers, and OpenRC was better than the alternatives.
58 >> I think that was great, but everybody else has moved on.
59 >
60 > Do you consider OpenRC a project that's not useful anymore?
61
62 I don't personally think it is useful, but I have no objections to
63 people who do find it useful maintaining it.
64
65 I think we're better off getting back onto common ground, which is choice.
66
67
68 --
69 Rich