diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-October/009217.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-October/009217.html | 216 |
1 files changed, 216 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-October/009217.html b/zarb-ml/mageia-dev/2011-October/009217.html new file mode 100644 index 000000000..1d849e0a5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-October/009217.html @@ -0,0 +1,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> |