1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE> [Mageia-dev] Please test: initscripts+systemd in updates_testing
</TITLE>
<LINK REL="Index" HREF="index.html" >
<LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Please%20test%3A%20initscripts%2Bsystemd%20in%20updates_testing&In-Reply-To=%3C4EAD3462.3050503%40colin.guthr.ie%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="009209.html">
<LINK REL="Next" HREF="009222.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Mageia-dev] Please test: initscripts+systemd in updates_testing</H1>
<B>Colin Guthrie</B>
<A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Please%20test%3A%20initscripts%2Bsystemd%20in%20updates_testing&In-Reply-To=%3C4EAD3462.3050503%40colin.guthr.ie%3E"
TITLE="[Mageia-dev] Please test: initscripts+systemd in updates_testing">mageia at colin.guthr.ie
</A><BR>
<I>Sun Oct 30 12:26:26 CET 2011</I>
<P><UL>
<LI>Previous message: <A HREF="009209.html">[Mageia-dev] Please test: initscripts+systemd in updates_testing
</A></li>
<LI>Next message: <A HREF="009222.html">[Mageia-dev] Please test: initscripts+systemd in updates_testing
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#9217">[ date ]</a>
<a href="thread.html#9217">[ thread ]</a>
<a href="subject.html#9217">[ subject ]</a>
<a href="author.html#9217">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>'Twas brillig, and Thomas Backlund at 29/10/11 21:13 did gyre and gimble:
><i> 30.10.2011 01:16, Colin Guthrie skrev:
</I>>><i> 'Twas brillig, and Thomas Backlund at 27/10/11 15:12 did gyre and gimble:
</I>>>><i>
</I>>>><i> Then we need to move those libs to /lib(64)
</I>>><i>
</I>>><i> There is quite serious talk about deprecating /lib, /bin and /sbin and
</I>>><i> basically anything that is not in /usr (with exceptions for /home /root,
</I>>><i> /etc and a few others). Of course there are various flames about this
</I>>><i> idea (earth will collapse into sun etc.) but it's actually surprisingly
</I>>><i> well received thus far IMO.
</I>>><i>
</I>>><i> Also, keep in mind that you're talking about moving a *lot* to / here...
</I>>><i> all the PCI/USB databases, all the udev setup, any application that udev
</I>>><i> might run in it's rules.... I won't reiterate what is written in the
</I>><i>
</I>><i> So?
</I>><i> it's less impact on / than stuffing all of /usr on /
</I>
I don't understand what point you're trying to make here. You'd be
moving a whole bunch of stuff to /... And it becomes very tricky to
administer exactly what to move to / as the dependencies are non-trivial
to work out, the QA burden is very high to test all the various
combinations of setups to ensure all the required bits have been moved to /
After doing all that QA and ensuring all is well, then the whole
separate of /usr and / is totally blurred anyway. As someone campaigning
to keep /usr on a separate partition, I'd have thought this was what you
were trying to protect against in the first place... it seems totally
contradictory to suggest this as a solution.
Keep in mind that one of the key aims in highlighting this issue via
systemd is to actually ALLOW /usr to be a useful and self contained
filesystem. If /usr is properly configured without leaking half of it to
/ it could be shared across multiple machines far more easily or even
mounted as ro by default which could prove handy for security. Again,
this is about highlighting the issues with an aim to making /usr much
more useful. This is a laudable aim but you seem to be shooting it down
due to gut reactions and prejudice. I've not yet seen any technical
arguments from you about the topic.
>><i> link Olav already provided, but suffice to say the problem is neither
</I>>><i> new, not specific to systemd. It's just being highlighted by systemd.
</I>>><i> Please keep this in mind when commenting on this topic.
</I>>><i>
</I>><i>
</I>><i> Interesting on how people think "systemd is the solution to everything",
</I>><i> and cant accept complaints when is screws up working systems....
</I>><i>
</I>><i> It's pretty much like Apple fans and their love for iCrap
</I>
And the statement above is as equally pointless as fanboiism. You're not
giving ANY technical arguments here, just spouting FUD and pointless
rhetoric which is not something I would expect to see from yourself :(
>>>>><i> That's just plain idiotic.
</I>>>>><i> I somewhat agree. But even Fedora is suggesting not to have separate
</I>>>>><i> /usr :(
</I>>>>><i>
</I>>>><i>
</I>>>><i> That does not make it less idiotic. IIRC they employ the systemd creator
</I>>>><i> so...
</I>>><i>
</I>>><i> But that doesn't make the idea any more or less idiotic.
</I>>><i>
</I>>><i> The reasons stated (and this discussion happened many months ago) are
</I>>><i> all well understood and documented in the link provided by Olav.
</I>>><i>
</I>>><i> It is NOT a systemd problem. It's a problem we have RIGHT NOW too, it's
</I>>><i> just that most setups are easy enough to work around by waiting and
</I>>><i> doing this sequentially which slows down the whole boot process. We've
</I>>><i> solved similar problems in the past by moving things to /lib but it's
</I>>><i> just a sticking plaster, not a real fix.
</I>>><i>
</I>><i>
</I>><i> What's the difference of moving stuff to /lib as compared moving all of
</I>><i> /usr into / besides bloating /
</I>
It dilutes the whole point in keeping /usr separate in the first place!!
This is what you are arguing for but yet you are contradicting it at the
same time.
><i> And by chasing seconds in bootup you screw those who want to finetune
</I>><i> their systems. Thats a regression.
</I>
No it's not. By this argument if you were to build a house upon sand, it
would be the fault of the brick manufacturer for building too heavy
bricks, not the planners who thought that sand was an appropriate
foundation. Papering over the cracks is not good for anyone. I want a
robust system by design, not by careful manipulation of the fundamental
problems to avoid the known broken bits.
><i> For those people that are so concerned about bootup times, why dont
</I>><i> they buy new hw, use fast ssd and learn how to suspend to ram/resume ...
</I>
I really don't understand why people keep harping back to "startup
times" as the sole argument for a systemd-based system. It seems to show
a lack of understanding of the project as a whole if this is the only
justification used.
Sure better h/w will help boot times and I certainly want them myself,
but it doesn't mean I don't want systemd. I want proper process
supervision, I want logging all the way from early boot, I want
information about why a service failed and I want to be able to track
when binaries are launched from webservices and run away (either
malicious due to a breach or just bad programming), and I want to
properly unmount / and deactivate LVM on shutdown and reboot. I cannot
do any of this with sysvinit but systemd means I can do all of that and
more.
>><i> If you have constructive criticism as to the reasons why this is now
</I>>><i> warned about specifically in systemd, then this is perfectly valid but
</I>>><i> should be done in context rather than simply calling it "idiotic"
</I>>><i> without any further clarification.
</I>>><i>
</I>><i>
</I>><i> Well, it _is_ idiotic if it breaks working setups / possibilities to
</I>><i> finetune systems.
</I>
It depends on your definition of "working". Sure if you specifically
work around the know limitations of the design then you may get a
bootable system, which you could classify as working, but I wouldn't say
this is a robust base. Just a house of cards waiting for the next
failure. I'd rather try and address the problems properly and be frank
about it in the discussions.
>><i> And systemd is not saying that /usr cannot be on a separate partition.
</I>>><i> It's just saying that it cannot realistically be the job of the init
</I>>><i> system to mount it, it has to be handled at early boot in the initramfs,
</I>>><i> not by init. The reasons why this is the case are documented very
</I>>><i> clearly.
</I>><i>
</I>><i> So by this reasoning we should stuff everything we can into initramfs,
</I>><i> and not care of partitioning / mount points at all.
</I>
No, it means we have to stuff what is needed to mount /usr into initramfs.
Col
--
Colin Guthrie
colin(at)mageia.org
<A HREF="http://colin.guthr.ie/">http://colin.guthr.ie/</A>
Day Job:
Tribalogic Limited <A HREF="http://www.tribalogic.net/">http://www.tribalogic.net/</A>
Open Source:
Mageia Contributor <A HREF="http://www.mageia.org/">http://www.mageia.org/</A>
PulseAudio Hacker <A HREF="http://www.pulseaudio.org/">http://www.pulseaudio.org/</A>
Trac Hacker <A HREF="http://trac.edgewall.org/">http://trac.edgewall.org/</A>
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="009209.html">[Mageia-dev] Please test: initscripts+systemd in updates_testing
</A></li>
<LI>Next message: <A HREF="009222.html">[Mageia-dev] Please test: initscripts+systemd in updates_testing
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#9217">[ date ]</a>
<a href="thread.html#9217">[ thread ]</a>
<a href="subject.html#9217">[ subject ]</a>
<a href="author.html#9217">[ author ]</a>
</LI>
</UL>
<hr>
<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev
mailing list</a><br>
</body></html>
|
