Gentoo Archives: gentoo-dev

From: Francesco Riosa <vivo75@×××××.com>
To: gentoo development <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] Changing order of default virtual/udev provider
Date: Tue, 09 Feb 2016 13:13:51
Message-Id: CAD6zcDxmokWgr7BeQzx7t+LfUGzJu3Xqg_Wtb48B2bVepKe3pA@mail.gmail.com
In Reply to: Re: [gentoo-dev] Changing order of default virtual/udev provider by Rich Freeman
1 2016-02-09 13:17 GMT+01:00 Rich Freeman <rich0@g.o>:
2
3 > On Tue, Feb 9, 2016 at 3:43 AM, Kent Fredric <kentfredric@×××××.com>
4 > wrote:
5 > >
6 > > A pure udev system is in comparison, much simpler than a systemd system.
7 >
8 > I don't buy that at all. In systemd you have a unified object model
9 > across device nodes, mountpoints, services, and cron jobs. In the
10 > alternate model you have completely different implementations of all
11 > of those, each with their own configurations and behaviors.
12 >
13 > >
14 > > And that's much of the beauty of OpenRC. Its simple, it achieves the
15 > > same goals as Systemd and Upstart, etc, but does so with a lot less
16 > > mechanics under the hood, and doesn't clutter up systems with features
17 > > you don't need prematurely.
18 >
19 > OpenRC doesn't achieve MANY of the goals of systemd. Maybe you don't
20 > personally care about some of them, but you really can't compare the
21 > feature sets at this point.
22 >
23 > > And there are great benefits from simplicity over complexity.
24 >
25 > Absolutely. It is great to create a text file and symlink it in a
26 > directory named after a service to make that service auto-restart, or
27 > have a memory limit, or set an IO priority for that service. It is
28 > great to not have to think about anything to have just about all your
29 > processes organized into a sensible cgroup hierarchy. It is great to
30 > be able to tweak one config file to ensure that users who log out of a
31 > system can't leave any processes behind.
32 >
33 > It is great to be able to tweak something in policykit and change
34 > things like who can shut down the system, or who can restart a
35 > service.
36 >
37 > The simplicity of systemd comes from the fact that it has brought what
38 > used to be a collection of many independent tools under one roof, and
39 > created a converging set of interfaces for all of them.
40 >
41 > > And a lot of Gentoo is surprisingly simple: Like our use of bash
42 > > scripts for recipies to build things, like using rsync to deploy/relay
43 > > not just those recipies, but security notices and news items, which
44 > > are themselves reasonably simple formats.
45 >
46 > Well, one thing about Gentoo that certainly isn't simple is our init.d
47 > scripts.
48 >
49 > Compare this:
50 > http://pastebin.com/sSDtpF4t
51 >
52 > With this:
53 > http://pastebin.com/Lfn8r7qP
54 >
55 > Systemd does the job in 10% of the code (and half of it is a comment),
56 >
57
58 Actually that's incorrect, it does not implement "configdump" and
59 "fullstatus" is it possible for systemd to implement those?
60 Anyway we are hijaking another discussion to OpenRC versus Systemd or it's
61 only my impression?
62
63
64 > and doesn't implement its own service polling and killer script during
65 > shutdown independently for every service (not that every init.d script
66 > even does this - most of them will just leave orphans behind, and
67 > systemd will catch orphans that even the lengthy init.d script for
68 > apache misses).
69 >
70 > >
71 > > The only preference I see here is the preference to not have and
72 > > install things your system has no use for, which I find an odd
73 > > preference to be complaining about, and depending on your system
74 > > requirements, that may also be not so much "preference".
75 > >
76 >
77 > And hence my suggestion that we simply get this stuff out of the
78 > stage3s in the first place. Then everybody can just pick the
79 > implementation that best suits their requirements.
80 >
81 > If you want to talk about default providers, the most straightforward
82 > one to use is systemd. It is what people are going to be used to
83 > coming from other distros, it is what every upstream package expects
84 > to be running anyway, and it is the simpler tool that does everything
85 > that most people want.
86 >
87 > For people who want a more exotic configuration, there are
88 > alternatives, and Gentoo should certainly support using them as long
89 > as people care to maintain them.
90 >
91 > --
92 > Rich
93 >
94 >