Dmitry Bogatov wrote:
> Arturo Borrero Gonzalez wrote:
> > * conntrackd & systemd are very good integrated (using libsystemd)
>
> I hugely support idea of dynamically loading libsystemd.
Please don't, no. While I do think packages should keep sysvinit
support as long as it continues to work and
> > > * conntrackd & systemd are very good integrated (using libsystemd)
> >
> > I hugely support idea of dynamically loading libsystemd.
>
> Please don't, no. While I do think packages should keep sysvinit
> support as long as it continues to work and doesn't make other paths
> worse, I don't t
On Sat, Aug 27, 2016 at 10:33:36AM +0300, Dmitry Bogatov wrote:
> > > I hugely support idea of dynamically loading libsystemd.
> >
> > Please don't, no. While I do think packages should keep sysvinit
> > support as long as it continues to work and doesn't make other paths
> > worse, I don't think
On Sat, 27 Aug 2016 at 10:33:36 +0300, Dmitry Bogatov wrote:
>
> > > > * conntrackd & systemd are very good integrated (using libsystemd)
> > >
> > > I hugely support idea of dynamically loading libsystemd.
> >
> > Please don't, no. While I do think packages should keep sysvinit
> > support as l
> Once per thread about systemd, I point out that dbus-daemon links to both
> libapparmor and libselinux - which results in at least one useless library
> for literally everyone with dbus installed, since "major" LSMs don't
> stack, so nobody can possibly be using both AppArmor and SELinux at the
On 2016-08-27 at 06:26, Andrew Shadura wrote:
> On 27 August 2016 at 10:33, Dmitry Bogatov wrote:
>
>> Like compat package, which provides libsystemd.a static library
>> and headers, that mirrors interface of libsystemd. This library
>> would forward call to actual libsystemd, if it exists and r
On Sat, Aug 27, 2016 at 07:36:02AM -0400, The Wanderer wrote:
> There is one minor/cosmetic downside of libsystemd as currently
> provided, however: the apt-listchanges changelog.
>
> The only '*systemd*' package which I have installed is libsystemd0.
> However, whenever I dist-upgrade (which is a
Dmitry Bogatov writes:
> You convinced me. If I pursue simplicity, it would be better to just
> recompile packages to get rid of unwanted dependencies.
I strongly suspect the amount of time you have spent participating in this
thread already exceeds all benefit you will ever achieve from recompi
On Sat, Aug 27, 2016 at 10:33:36AM +0300, Dmitry Bogatov wrote:
> > > I hugely support idea of dynamically loading libsystemd.
> >
> > Please don't, no. While I do think packages should keep sysvinit
> > support as long as it continues to work and doesn't make other paths
> > worse, I don't think
[2016-08-28 06:26] Adam Borowski
>
> part text/plain2020
> On Sat, Aug 27, 2016 at 10:33:36AM +0300, Dmitry Bogatov wrote:
> > > > I hugely support idea of dynamically loading libsystemd.
> > >
> > > Please don't, no. While I do think packages should keep sysvinit
> > > sup
Dmitry Bogatov writes:
> Not to start flame or to advertize anything/anyone, but why to integrate
> with 'runit' init system, your program should support foreground
> operation and logging on stdout, and to integrate with systemd, it
> should link with library?
You should *also* support foregrou
❦ 29 août 2016 05:00 CEST, Russ Allbery :
> upstart supports a similar mechanism via the -Z flag, but it's (IMO) a
> little less clean: the process sends itself a SIGSTOP when it's ready, and
> then lets the init system send it a SIGCONT. This does work, but I don't
> like it as much; pausing f
[2016-08-28 20:00] Russ Allbery
>
> part text/plain3207
> Dmitry Bogatov writes:
>
> > Not to start flame or to advertize anything/anyone, but why to integrate
> > with 'runit' init system, your program should support foreground
> > operation and logging on stdout, and to in
Dmitry Bogatov writes:
> I can understand this need, although never needed it myself.
> But implementation makes me sad. Instead of creating UNIX-way solution
> (create /var/run/foo.ready, when you are ready?), it does the worst
> thing I can imagine.
If communicating with another local daemon
Vincent Bernat writes:
> ❦ 29 août 2016 05:00 CEST, Russ Allbery :
>> upstart supports a similar mechanism via the -Z flag, but it's (IMO) a
>> little less clean: the process sends itself a SIGSTOP when it's ready,
>> and then lets the init system send it a SIGCONT. This does work, but I
>> do
> > I can understand this need, although never needed it myself.
>
> > But implementation makes me sad. Instead of creating UNIX-way solution
> > (create /var/run/foo.ready, when you are ready?), it does the worst
> > thing I can imagine.
>
> If communicating with another local daemon via a UNIX d
Dmitry Bogatov writes:
> Socket is not bad thing. Inventing daemon for no reason is complicating
> things for no reason => bad. Thanks history, we have pid files, not
> `libpid' to talk to `pidd'.
Uh, the daemon in question is the init daemon? Which has been there since
the beginning of UNIX?
[2016-08-29 18:30] Russ Allbery
>
> part text/plain1918
> Dmitry Bogatov writes:
>
> > Socket is not bad thing. Inventing daemon for no reason is complicating
> > things for no reason => bad. Thanks history, we have pid files, not
> > `libpid' to talk to `pidd'.
>
> Uh, the
18 matches
Mail list logo
