<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 23, 2014 at 1:07 PM, Mike O'Dell <span dir="ltr"><<a href="mailto:mo@ccr.org" target="_blank">mo@ccr.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">re: systemd vs procd vs etcd...<br>
<br>
If other distros have largely converged to systemd,<br>
is it worthwhile for CeroWrt to do something different?<br>
This assumes that the daemons in question have already or<br>
are in process of becoming systemd-compatible. If that is<br>
indeed the case, is it really worthwhile to spend time<br>
supporting something different?<br>
<br>
not trying to re-open old wounds, just wondering how many<br>
different approaches are actually "better" in some material<br>
way and how many are just "different".<br>
<br>
I've watched Apple go through the pains of moving all the<br>
lifetime control of services to launchd. It took a long time to<br>
justify it being different, but now that it's done, the fact<br>
there is only ONE place to look is really a feature. One thing,<br>
for instance, is that the Xserver and its helpers all start<br>
automagically when an X11 binary is run. Likewise, making<br>
a daemon periodic instead of continuous is changed in just<br>
one place - not moved from one to another.<br>
<br>
My point is that making is truly better, as opposed to "just<br>
different, yet again" requires doing the whole job, not just<br>
a different subset of it. So if there is a base of systemd-capable<br>
versions of the daemons in question, just use those to avoid<br>
the work. or do the whole job an import launchd. (which i'm<br>
*not* lobbying for!)<br>
<br>
-mo<br></blockquote><div><br></div><div class="gmail_default">Mike,</div><div class="gmail_default"><br></div><div class="gmail_default">CeroWrt is an upstream development version of OpenWrt.</div><div class="gmail_default">
<br></div><div class="gmail_default">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).</div><div class="gmail_default">
<br></div><div class="gmail_default">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.</div>
<div class="gmail_default"><br></div><div class="gmail_default">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.</div>
<div class="gmail_default"><br></div><div class="gmail_default">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...</div>
<div class="gmail_default"><br></div><div class="gmail_default"> - Jim</div><div class="gmail_default"><br></div><div class="gmail_default" style="font-size:small"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
_______________________________________________<br>
Cerowrt-devel mailing list<br>
<a href="mailto:Cerowrt-devel@lists.bufferbloat.net">Cerowrt-devel@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/cerowrt-devel" target="_blank">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a><br>
</blockquote></div><br></div></div>