On 26/05/10 04:02, Casey Dahlin wrote:
> On Tue, May 25, 2010 at 05:45:07PM +0200, Lennart Poettering wrote:
>> On Tue, 25.05.10 10:21, Casey Dahlin (cdahlin@xxxxxxxxxx) wrote:
>>
>>>
>>> On Mon, May 24, 2010 at 09:05:31AM -0400, Tom spot Callaway wrote:
>>>> On 05/23/2010 04:19 AM, Kevin Kofler wrote:
>>>>> Lennart Poettering wrote:
>>>>>> So far response from the community has been very positive, but we didn't
>>>>>> have a fedora-devel discussion about this yet, so we'll have to see
>>>>>> whether we can somehow make the broader community as enthusiastic about
>>>>>> the whole idea as I am. ;-)
>>>>>
>>>>> I, for one, think systemd should be the default ASAP.
>>>>
>>>> Perhaps the first time I can recall that we have agreed. ;)
>>>>
>>>> ~spot
>>>
>>> Any particular reason on either of your parts?
>>>
>>> Just about everything in systemd is either set to be in upstart (simpler
>>> dependency syntax, xinetd-style service activation) or was discarded by it
>>> years ago (cgroups are a dead end).
>>
>> Oh, is that so?
>>
>> Have you actually read the blog story I put together?
>>
>
> Yes, but I'm going to go read it again just to be sure.
>
>> Why do you say "cgroups are a dead end"? Sure, Scott claims that, but
>> uh, it's not the only place where he is simply wrong and his claims
>> baseless. In fact it works really well, and is one of the strong points
>> in systemd. I simply see no alternative for it. The points Scott raised
>> kinda showed that he never really played around with them.
>>
>> Please read up on cgroups, before you just dismiss technology like that
>> as "dead end".
>>
>
> I did. When upstart was about to use them. 2 years ago. We chucked them by the
> following LPC.
>
> The problem we've found is that cgroups are too aggressive. They don't have a
> notion of sessions and count too much as being part of your service, so you end
> up with your screen session being counted as part of gdm.
>
> This is why setsid was added to the netlink connector.
>
>>> The assumption that just because its new means its more advanced is in this
>>> case a bit misguided.
>>
>> Well, please read the blog story. I know it's long, but it should be an
>> interesting read. The whole point of the blog story is to make clear the
>> reason systemd exists is purely technical, and that we think our design
>> is simply the better one.
>>
>
> So you have:
>
> 1) Socket activation. Part of Upstart's roadmap. Would happen sooner if you
> cared to submit the patch. We don't think its good enough by itself, hence the
> rest of Upstart, but a socket activation subsystem that could reach as far as
> systemd and even work standalone in settings where systemd can work is
> perfectly within Upstart's scope. I'd be happy to firm up the design details
> with you if you wanted to contribute patches.
>
> 2) Bus activation. Missed opportunity here to actually become the launchpoint
> for activated services. I won't criticize that too much though, as its
> usefulness is largely dependent on kernelspace DBus, which I've been trying to
> bludgeon Marcel Holtmann into turning over to the public for a year now.
>
> 3) Cutting down on the forking by replacing some of the shell scripts... cool
> 3a) With C code... really?
>
Yeah. I think this is odd too.
The blog complains about how many awk spawns there are - but this looks
like a complaint that belongs in the 70's.
It really doesn't take long to launch awk. at all. And most of the
things people are asking awk to do in shell scripts are very trivial,
requiring very little processing.
using a simple for i in {1..1000}; do ... loop I can launch on this
rubbish old laptop a thousand awk processes in 3.35 seconds. By
comparison, it takes 2.24 seconds to launch a thousand C hello world
programs. So C is faster. Just about. But the complaint in the blog
is that awk is called 92 times. By this metric that costs the user 0.3
seconds of CPU time. To get rid of this horrible waste of resources we
are compiling all our startup scripts.... wait. Something is wrong with
that picture ;)
Modern systems just don't take very long to spawn awk. Or sed. Or cut.
Or bash. IMO this sort of tradeoff between speed and ease of use hasn't
been appropriate in 20 years.
It's really not at all uncommon for me to need to modify an init script.
There would be much rage if in order to do this I had to download the
SRPM, extract the init code, figure out what I needed to change, modify
it, recompile then install.
The rest of systemd looks great to me - and the sooner we can switch the
lesser the pain in some respects (as the longer we wait, the more used
people become to upstart, and then we have to switch again, causing user
frustration).
-siXy
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
