Hello,
Jonathan de Boyne Pollard, on Thu 01 Sep 2016 08:47:44 +0100, wrote:
> >You have forgotten about the existence of Debian Hurd. (-:
> >
> >* https://jdebp.eu./FGA/hurd-daemons.html#proc
>
> >The Hurd precisely tries to expose things as files.
> >
> Not in this case. I pointed earlier to t
]] Jonathan de Boyne Pollard
> Russ Allbery:
>
> > I think that... says the same thing I said?
> >
> Read again, and let your eye dwell upon Laurent Bercot's name this
> time. (-: The world has changed since 2014 and the Debian systemd
> packaging Hoo-Hah, and I've been keeping tabs.
s6 doesn
[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
[2016-08-30 08:55] Jonathan de Boyne Pollard
>
> part text/plain 198
> Dmitry Bogatov:
>
> > Thanks history, we have pid files, not `libpid' to talk to `pidd'.
> >
> You have forgotten about the existence of Debian Hurd. (-:
I like Hurd idea, but I was talking about Linux
Jonathan de Boyne Pollard, on Tue 30 Aug 2016 08:55:26 +0100, wrote:
> >Thanks history, we have pid files, not `libpid' to talk to `pidd'.
> >
> You have forgotten about the existence of Debian Hurd. (-:
The Hurd precisely tries to expose things as files.
Samuel
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?
> > 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
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
Jonathan de Boyne Pollard
writes:
> Russ Allbery:
>> All other init systems except upstart [...]
> Psst!
> * https://jdebp.eu./FGA/unix-daemon-readiness-protocol-problems.html#Choice
I think that... says the same thing I said? At least the only ones I see
there are systemd and a proposal for
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
[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
❦ 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
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
[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
On Sun, Aug 28, 2016 at 02:21:47PM +0100, Jonathan de Boyne Pollard wrote:
> Simon McVittie:
> >You mean like libsystemd, which looks in /run to see whether systemd is in
> >use, talks to it if it is, and returns some suitable error code (-ENOSYS?)
> >if it isn't? :-)
>
> Here's interesting for yo
❦ 28 août 2016 15:21 CEST, Jonathan de Boyne Pollard
:
>> You mean like libsystemd, which looks in /run to see whether systemd
>> is in use, talks to it if it is, and returns some suitable error
>> code (-ENOSYS?) if it isn't? :-)
>>
> Here's interesting for you. (-:
>
> Here's libsystemd and A
On 2016-08-28 at 09:11, Jonathan de Boyne Pollard wrote:
> The Wanderer:
>
>> IMO this level of integration between things which are not mutually
>> interdependent is a minor bug in itself, but none of the
>> maintainers are going to agree with me on that.
>
> Actually, they might. But this is
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
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 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
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
> 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 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
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
> > > * 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 24/07/14 12:16, Marco d'Itri wrote:
> This package provides a dummy libsystemd-daemon-dev binary package on
> kfreebsd-* and hurd-* systems.
>
> The purpose of this package is to allow other packages to
> unconditionally build-depend depend on libsystemd-daemon-dev, removing the
> need for if
26 matches
Mail list logo
