From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id F070E208AAD for ; Thu, 23 Jan 2014 10:10:24 -0800 (PST) Received: by mail-oa0-f48.google.com with SMTP id l6so2533469oag.21 for ; Thu, 23 Jan 2014 10:10:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=XifvP922r0T6dAAAxKFKCDpLuyZUC1SECI50SkWAmR4=; b=AzKfB8hIR89N/ievaEpv1BUJVQPJKeIuF1HDWQ7wiQtbuE3cCK/KHQF1oBx93PTA4F 0ZDi+BcW1WMax0moB+OSXd12XXEbNInKq92fbSon0fp5Ljuk/KmuPGPwcO6UVbzhsThk mzvsgFnKW6wAETXjqv0KbvFUgV5DM0YhpWnweXIsslnF+AnPUt8TEEkp/3x25d4rFxD5 teE+q8t4hJuz0u01kE1NhsARs/XEGbjG7Ufa03de9z79IQaJyv2EnXTXlMqqVZMYy922 ry2vfsiTY/NLVIyRbHVWiHYGI1s0VZeNokJFvCWoFnriHviZSg1y56kQd9TwTxcm+fhY qXmQ== MIME-Version: 1.0 X-Received: by 10.182.113.195 with SMTP id ja3mr7868905obb.46.1390500623907; Thu, 23 Jan 2014 10:10:23 -0800 (PST) Sender: gettysjim@gmail.com Received: by 10.76.84.162 with HTTP; Thu, 23 Jan 2014 10:10:23 -0800 (PST) In-Reply-To: <88756.1390500464@ccr.org> References: <88756.1390500464@ccr.org> Date: Thu, 23 Jan 2014 13:10:23 -0500 X-Google-Sender-Auth: YPeOp6oM78XP79CI4re5DwMH1Vo Message-ID: From: Jim Gettys To: "Mike O'Dell" Content-Type: multipart/alternative; boundary=089e013d0db0bf7f1704f0a7271b Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Cerowrt-devel Digest, Vol 26, Issue 49 X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 18:10:25 -0000 --089e013d0db0bf7f1704f0a7271b Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 23, 2014 at 1:07 PM, Mike O'Dell wrote: > re: systemd vs procd vs etcd... > > If other distros have largely converged to systemd, > is it worthwhile for CeroWrt to do something different? > This assumes that the daemons in question have already or > are in process of becoming systemd-compatible. If that is > indeed the case, is it really worthwhile to spend time > supporting something different? > > not trying to re-open old wounds, just wondering how many > different approaches are actually "better" in some material > way and how many are just "different". > > I've watched Apple go through the pains of moving all the > lifetime control of services to launchd. It took a long time to > justify it being different, but now that it's done, the fact > there is only ONE place to look is really a feature. One thing, > for instance, is that the Xserver and its helpers all start > automagically when an X11 binary is run. Likewise, making > a daemon periodic instead of continuous is changed in just > one place - not moved from one to another. > > My point is that making is truly better, as opposed to "just > different, yet again" requires doing the whole job, not just > a different subset of it. So if there is a base of systemd-capable > versions of the daemons in question, just use those to avoid > the work. or do the whole job an import launchd. (which i'm > *not* lobbying for!) > > -mo > Mike, CeroWrt is an upstream development version of OpenWrt. One of the current constraints of OpenWrt is that it still (for its own good reasons) targeted at very small flash routers (8mb, and even 4mb flash routers). When I last looked at systemd, it's footprint looked larger than would likely be feasible given those constraints: granted, I did not do a really careful analysis of systemd's footprint, which is probably only knowable by doing a full port. So for the moment, I expect our attention needs to be elsewhere (though I do like systemd from what I've seen of it). But without funding to bear the costs of such a fork from OpenWrt, it can't fly. I expect the flash constraints will eventually ease; the question is when... Funding for these projects (OpenWrt/CeroWrt) would also help, as it would make sense to do a fork as it's clear that the flash constraint is something that should bite the dust someday and sooner would be better than later... - Jim > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > --089e013d0db0bf7f1704f0a7271b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Jan 23, = 2014 at 1:07 PM, Mike O'Dell <mo@ccr.org> wrote:
re: systemd vs procd vs etcd...

If other distros have largely converged to systemd,
is it worthwhile for CeroWrt to do something different?
This assumes that the daemons in question have already or
are in process of becoming systemd-compatible. If that is
indeed the case, is it really worthwhile to spend time
supporting something different?

not trying to re-open old wounds, just wondering how many
different approaches are actually "better" in some material
way and how many are just "different".

I've watched Apple go through the pains of moving all the
lifetime control of services to launchd. It took a long time to
justify it being different, but now that it's done, the fact
there is only ONE place to look is really a feature. One thing,
for instance, is that the Xserver and its helpers all start
automagically when an X11 binary is run. Likewise, making
a daemon periodic instead of continuous is changed in just
one place - not moved from one to another.

My point is that making is truly better, as opposed to "just
different, yet again" requires doing the whole job, not just
a different subset of it. So if there is a base of systemd-capable
versions of the daemons in question, just use those to avoid
the work. or do the whole job an import launchd. (which i'm
*not* lobbying for!)

=A0 =A0 =A0 -mo

Mike,

CeroWrt is an upstream development version of OpenWrt.

One of the current constraints of Op= enWrt is that it still (for its own good reasons) targeted at very small fl= ash routers (8mb, and even 4mb flash routers).

When I last looked at systemd, it= 9;s footprint looked larger than would likely be feasible given those const= raints: granted, I did not do a really careful analysis of systemd's fo= otprint, which is probably only knowable by doing a full port.

So for = the moment, I expect our attention needs to be elsewhere (though I do like = systemd from what I've seen of it). =A0But without funding to bear the = costs of such a fork from OpenWrt, it can't fly.

I expec= t the flash constraints will eventually ease; the question is when... =A0Fu= nding for these projects (OpenWrt/CeroWrt) would also help, as it would mak= e sense to do a fork as it's clear that the flash constraint is somethi= ng that should bite the dust someday and sooner would be better than later.= ..

=A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- Jim

_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.= bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

--089e013d0db0bf7f1704f0a7271b--