1 |
Rich Freeman posted on Sun, 18 Nov 2012 07:26:17 -0500 as excerpted: |
2 |
|
3 |
> I'm sure all of the options will be offered as options for as long as |
4 |
> people care to take care of them. With the number of anti-systemd posts |
5 |
> on -dev I don't see openrc going away anytime soon. |
6 |
> |
7 |
> I'm sure the default will stay as it is unless a substantial majority |
8 |
> want it otherwise - we can't go flipping that every time the latest |
9 |
> whatever comes along. |
10 |
|
11 |
[For close followers of the discussion, this is a repeat. But it's worth |
12 |
repeating in the hope that the message gets out to gentoo users who don't |
13 |
follow so closely.] |
14 |
|
15 |
Based on previous posts from other gentoo users, this point seems to have |
16 |
been lost on some, but it's absolutely true. As I've pointed out before |
17 |
as well, even if by some miracle all of gentoo turned on a dime and |
18 |
became a virulently pro-systemd distro today, in practice it'd take time |
19 |
for that to work into the implementation. We're looking at probably a |
20 |
year minimum, more practically closer to two, before end-users could |
21 |
really be "forced" over, and that's if somehow the policy changed on a |
22 |
dime, today, which isn't going to happen. So even if gentoo ultimately |
23 |
heads that direction, and I think the default _may_ _eventually_ be |
24 |
systemd but with *SERIOUS* stress on BOTH _MAY_ and _EVENTUALLY_, in |
25 |
reality we're looking at 3-5 years. |
26 |
|
27 |
And in the free software world, a _LOT_ happens in 3-5 years! So much so |
28 |
that five years really is at the horizon in any case -- there will be |
29 |
enough currently unforeseen changes between now and then that it's really |
30 |
hard to predict anything out that far anyway, and MOST people attempting |
31 |
to do so in anything but trivial ways will get MAJOR parts of their |
32 |
prediction wrong, simply because events will overtake them. |
33 |
|
34 |
> And frankly, I could care less what it is since I can change it. If I |
35 |
> wanted to be rigidly bound by defaults there are a lot of distros easier |
36 |
> to maintain than Gentoo. iOS comes to mind. :) |
37 |
|
38 |
That's a point that should be near and dear to any serious gentooer's |
39 |
heart! =:^) |
40 |
|
41 |
> I run OpenRC on my main box, and systemd on a VM hosted within it. I |
42 |
> wouldn't be surprised if I move to systemd some day as my experience |
43 |
> with it has been a good one, but I'll use the tools I think are best for |
44 |
> the problem at hand, and not what somebody else chooses for me, and I'll |
45 |
> be the last to force a choice on anybody else. |
46 |
|
47 |
With the previous caveats about trying to predict anything in the FLOSS |
48 |
world too far out, in 2-3 years, I expect I'll be on systemd myself. But |
49 |
there's no rush, and I intend to wait until it stabilizes somewhat, |
50 |
first. At present it's simply evolving too fast for my tastes, for |
51 |
something so system-basic. I enjoy running alphas and betas as much as |
52 |
the next guy and it's a rare time indeed that I don't have /something/ |
53 |
not-absolutely stable running on my systems, but that doesn't mean I |
54 |
want /all/ of my system unstable and shifting out from under me, and |
55 |
system init is an area where I'm just not ready to make a change as big |
56 |
as systemd, when it's still actively growing and changing at the rate it |
57 |
seems to be doing so today. |
58 |
|
59 |
That said, I _do_ run openrc-9999, mainly because I found the changes of |
60 |
~arch openrc too coarse-grained and hard to troubleshoot when things go |
61 |
wrong. By running the live-git version and examining git-whatchanged |
62 |
every time I update, often looking at the diffs for individual commits, I |
63 |
get the incremental changes as they come in, and can much faster pinpoint |
64 |
where a particular problem is when I see it, making the necessary changes |
65 |
locally and of course bug-filing upstream as I need to, to get it fixed. |
66 |
|
67 |
But running a live-git version of something I'm already on, in ordered to |
68 |
more closely follow individual commits and pinpoint and resolve bugs |
69 |
faster, is quite different from deciding I'm going to switch to something |
70 |
with as much churn as systemd seems to still have, engulfing and |
71 |
extinguishing entire projects like some ravenous black hole or gray goo. |
72 |
Yes, I expect at some point I'll be assimilated myself, but there's no |
73 |
reason that point needs to be now, and the future where I expect it to |
74 |
happen remains to be written, with a good chance the plot line will |
75 |
change significantly between now and then, such that I may never be |
76 |
assimilated after all. For all I know, the whole worldview will change |
77 |
between now and then, and other events might well overtake this gray goo |
78 |
that now seems to be engulfing everything that it touches, such that it |
79 |
never does in fact engulf me and my systems. |
80 |
|
81 |
> That said, Gentoo can |
82 |
> only offer the options that devs step up and maintain, so if you care |
83 |
> greatly about something start writing patches. |
84 |
|
85 |
This too is a point that's often lost on people. Take kde as an |
86 |
example. Yes, kde3 was relegated to the kde-sunset overlay, where it's |
87 |
being maintained in some state by users (see the gentoo-desktop list for |
88 |
the discussion on that, if interested). But that was simply because no |
89 |
current gentoo devs were interested in maintaining it in-tree. All the |
90 |
gentoo/kde folks were on kde4. If there had been active devs interested |
91 |
in keeping a working kde3 in-tree, it would have stayed in-tree. Only |
92 |
when the active gentoo dev interest fell below a sustainable level was it |
93 |
removed, and even then, it's still in kde-sunset, because there's |
94 |
sustainable interest at /that/ level. |
95 |
|
96 |
The same of course applies to trinity, the still active fork from kde3. |
97 |
I think it'd be great to have it in the gentoo tree again. But it's not |
98 |
going to happen unless/until there's enough active gentoo devs interested |
99 |
in making it happen to have it as a project. |
100 |
|
101 |
And the same applies to systemd/udev. The choices available to gentoo |
102 |
users are a direct reflection of the interest of gentoo devs. As it |
103 |
happens, there's a couple gentoo devs with the interest and motivation to |
104 |
have the systemd OPTION in gentoo, but that's exactly where it stands |
105 |
ATM, a non-default OPTION. And that's exactly where it's likely to |
106 |
remain for at least a few years, because the primary gentoo dev interest |
107 |
still seems to be focused on openrc and a udev-alike that remains |
108 |
sufficiently unentangled from systemd that it's still buildable (to some |
109 |
degree) and runnable (to a much larger degree) on its own. |
110 |
|
111 |
The only way that's going to change is if the critical level of interest |
112 |
amongst gentoo devs changes. Thus, the way to either keep a gentoo |
113 |
systemd default from happening, or increase the speed at which it |
114 |
happens, and to maintain choice regardless of the default depending on |
115 |
your own interest, is to do your part to ensure the critical level of |
116 |
gentoo interest in your preferred outcome remains strong. |
117 |
|
118 |
If current wider-Linux-and-FLOSS-universe trends continue, then at some |
119 |
point, probably most gentoo devs will be interested in systemd, as it's |
120 |
what they're familiar with from their previous and continuing outside-of- |
121 |
gentoo experience. However, as I pointed out above, that's not a |
122 |
particularly safe prediction to make, because gentoo as it is today is |
123 |
rather far from that, and by the time it could reasonably get to that |
124 |
point thru normal gentoo dev attrition and recruitment, the whole Linux/ |
125 |
FLOSS worldview may well have changed, and systemd/udev may well be as |
126 |
much yesterday's news as the old kernel's even/odd stable/dev kernel |
127 |
cycle, or the xfree86/xorg split before that, or the gcc/egcs split |
128 |
before that, or... |
129 |
|
130 |
> That is my biggest concern over a lot of this mess - and Greg KH did a |
131 |
> good job putting it into words in the six-month old thread that was just |
132 |
> resurrected. Lennart et al only have the power you give to them - |
133 |
> anybody can fork at any time or keep an old project going. If you don't |
134 |
> like Gnome 3 then start writing code for Gnome 2. This is all FREE |
135 |
> software, and it only exists when people take the time to write it. If |
136 |
> nobody bothers to maintain the alternatives, then I guess collectively |
137 |
> we're going to be stuck with whatever people take the time to write. |
138 |
|
139 |
This is simply reinforcing and underlining the above, only now we're |
140 |
looking at the upstream level, not the gentoo/distro level. |
141 |
|
142 |
> So, feel free to offer advice/comments/etc. However, let's keep the |
143 |
> tone civil. Unless you're their employer, the guys writing the software |
144 |
> you don't like owe you precisely nothing. |
145 |
|
146 |
++ on keeping it civil! =:^) |
147 |
|
148 |
-- |
149 |
Duncan - List replies preferred. No HTML msgs. |
150 |
"Every nonfree program has a lord, a master -- |
151 |
and if you use the program, he is your master." Richard Stallman |