Mass bug filing: use and misuse of dbus-launch (dbus-x11)

[Jonathan de Boyne Pollard]

This can already work. If you put XDG_RUNTIME_DIR in user programs'
environment, and arrange for your favourite service manager to make a
dbus-daemon (or something else that speaks the same protocol) listen
on $XDG_RUNTIME_DIR/bus before any user process would try to connect
to it, then modern versions of at least libdbus, GDBus and sd-bus will
connect to it by default with no additional effort on your part. This
client-side code path does not depend on systemd, does not depend on
libsystemd (except obviously sd-bus which is part of libsystemd), and
is compiled in for all supported Unix platforms.

That's the problem. No the whole unix:runtime=yes mechanism is not. As
I said, this is something that you and Joe Marcus Clarke and whomever
else have to sort out with each other. I'm unfortunately stuck in the
middle, here. Please do whatever it is that you need to do with each
other to make your program understand address=systemd: and
address=unix:runtime=yes on FreeBSD/TrueOS/OpenBSD. It does not do so.

Meanwhile, if you want the relevant integration files (your favourite
service manager's equivalent of systemd units) to be part of dbus (the
reference implementation of D-Bus), please propose tested patches; if
they follow the "user session" model[1], they could eventually go in
dbus-user-session.deb, with its dependencies changed from the current
systemd-sysv to "systemd-sysv | your-service-manager".

Kudos for being the first project to offer integration, ever. (-: Yes,
down the road it would be marvellous if people included service bundles
in their own projects. Yes, I'd like to see the day when the number of
service bundles in the nosh-bundles package actually starts going down,
because people are taking on shipping their own service bundles for
their own services, instead of going up. So yes, eventually you'll be
taken up on that offer I hope. But one step at a time.

As for what I would like, I'd like you (where that's plural,
including Joe Marcus Clarke or whomever else) to please make either
address=systemd: or address=unix:runtime=yes work in your program on
FreeBSD/PC-BSD/OpenBSD.

To the best of my knowledge, the listenable address "unix:runtime=yes"
(as in "dbus-daemon --address=unix:runtime=yes") does work on generic
Unix, and should interoperate fine with the XDG_RUNTIME_DIR/bus
fallback used by clients with no DBUS_SESSION_BUS_ADDRESS. It is
compiled and tested whenever DBUS_UNIX is defined (i.e. everything
except Windows), and I haven't seen bug reports about that test failing.

There you go, then. New knowledge. (-: It doesn't work with your
program as ported to FreeBSD/TrueOS/OpenBSD. Joe Marcus Clarke is the
porter for FreeBSD, according to the port information, and Antoine
Jacoutot the porter for OpenBSD. This is why I am saying that it's
something that you (plural, remember) need to sort out amongst
yourselves. We users stuck in the middle cannot use address=systemd:
and address=unix:runtime=yes with your program on these systems. As I
said, it's something that I had to fix in November 2015, to stop trying
to use address=systemd: on FreeBSD/TrueOS because it turned out that it
didn't actually work. I thought that address=unix:runtime=yes might,
but that did not either.

I am *not* going to go looking for patches on display at the bottom of
a locked filing cabinet stuck in a disused lavatory with a sign on the
door saying "beware of the leopard";

Luckily, you didn't need to. The page that I hyperlinked before pointed
directly to Pierre-Yves Ritschard's and Cameron T. Norman's actual code,
even down to positioning the window around the first lines of the
functions. Now if one *did* want to follow the Debian way of having
mention of these things buried down in the depths, in a bug report from
years ago, then this is a truly excellent example of the genre that one
could enjoy. One should begin with Cameron T. Norman's post here,
roughly one thousand eight hundred messages down, in a bug report from 3

To be brutally honest, there is a fairly low limit to how much benefit
I can create by giving new things to PC-BSD users, [...]

That's not the right way to look at it. You yourself have just said
several times that this is stuff that is supposed to be on "supported
Unix platforms". This isn't giving new things to anyone. This is
making existing things, that you yourself think are existing, work.

I shouldn't dismiss PC-BSD so readily, if I were you, either. PC-BSD
(now rebranded as TrueOS Desktop a few days ago -- I just got through
changing a whole load of preset file and -run package names.) is the BSD
that comes in the box with the desktop environments and with all of the
desktop programs that use Desktop Bus. Yes, people can and do run all
of this stuff on FreeBSD and OpenBSD from ports. But PC-BSD^H^H^H^H^H^H
.. Gah! ... TrueOS Desktop is where it comes in the box and is run as
standard in the default install. TrueOS Desktop is where one ends up
choosing from running PCDMd, kdm, lxdm, or gdm; and where one gets lots
of little Desktop Bus brokers all over the place in various ways from
these different systems. TrueOS Desktop is where the people who are
behind the operating system will be strongly motivated towards improving
the desktop subsystems and the Desktop Bus.

You're pushing your new way of per-user Desktop Bus brokers at the
world. I can give the TrueOS Desktop people, and the the UbuntuBSD
people, and the Debian FreeBSD people, a service management system that
I know can run per-user Desktop Bus brokers on a FreeBSD kernel. It
already does. I published it last year. If you, the Desktop Bus people,
can give us these mechanisms in your program actually working on these
operating systems, then the TrueOS people get the opportunity to
simplify some of the scaffolding that they have had to erect
(PCDM-session writing out nonce scripts that invoke dbus-launch, for
example), and you get less of the world still using your old way of
doing things.

[Steve Litt]

On Sun, 4 Sep 2016 17:30:43 +0100

Post by Jonathan de Boyne Pollard

This can already work. If you put XDG_RUNTIME_DIR in user programs'
environment, and arrange for your favourite service manager to make
a dbus-daemon (or something else that speaks the same protocol)
listen on $XDG_RUNTIME_DIR/bus before any user process would try to
connect to it, then modern versions of at least libdbus, GDBus and
sd-bus will connect to it by default with no additional effort on
your part. This client-side code path does not depend on systemd,
does not depend on libsystemd (except obviously sd-bus which is
part of libsystemd), and is compiled in for all supported Unix
platforms.

That's the problem. No the whole unix:runtime=yes mechanism is not.
As I said, this is something that you and Joe Marcus Clarke and
whomever else have to sort out with each other. I'm unfortunately
stuck in the middle, here. Please do whatever it is that you need to
and address=unix:runtime=yes on FreeBSD/TrueOS/OpenBSD. It does not
do so.

Meanwhile, if you want the relevant integration files (your
favourite service manager's equivalent of systemd units) to be part
of dbus (the reference implementation of D-Bus), please propose
tested patches; if they follow the "user session" model[1], they
could eventually go in dbus-user-session.deb, with its dependencies
changed from the current systemd-sysv to "systemd-sysv |
your-service-manager".

Danger Will Robinson.

"Integration" in cases of systemd and its venus fly trap, dbus, is more
Embrace, Extend, Extinguish than integration. The Rube Goldbergesque
system described in the preceding quoted context exquisitely highlights
that fact.

Do not cooperate with systemd. The systemd proponents don't cooperate
with anyone else.

Post by Jonathan de Boyne Pollard
Yes, down the road it would be marvellous if people included service
bundles in their own projects.

What would be marvellous is if people would simply ignore systemd,
opting for a real init system (not a conglomeration of welded krap
trying to supercede what we've had for years).

Post by Jonathan de Boyne Pollard
Yes, I'd like to see the day when the
number of service bundles in the nosh-bundles package actually starts
going down, because people are taking on shipping their own service
bundles for their own services, instead of going up. So yes,
eventually you'll be taken up on that offer I hope. But one step at a
time.

Ooohhhh, "service bundles." My runit run scripts average about 6 lines
long. Any fool can make them. Behold the power of a real init: An init
that knows it's an init, and does only what inits are designed to do. I
highlight runit out of familiarity, but my use of s6 and Epoch indicate
that both are equally as simple, when defining service startup, runit.

Post by Jonathan de Boyne Pollard

As for what I would like, I'd like you (where that's plural,
including Joe Marcus Clarke or whomever else) to please make
either address=systemd: or address=unix:runtime=yes work in your
program on FreeBSD/PC-BSD/OpenBSD.

To the best of my knowledge, the listenable address
"unix:runtime=yes" (as in "dbus-daemon --address=unix:runtime=yes")
does work on generic Unix, and should interoperate fine with the
XDG_RUNTIME_DIR/bus fallback used by clients with no
DBUS_SESSION_BUS_ADDRESS. It is compiled and tested whenever
DBUS_UNIX is defined (i.e. everything except Windows), and I
haven't seen bug reports about that test failing.

There you go, then. New knowledge. (-: It doesn't work with your
program as ported to FreeBSD/TrueOS/OpenBSD. Joe Marcus Clarke is
the porter for FreeBSD, according to the port information, and
Antoine Jacoutot the porter for OpenBSD.

To the *BSD communities: Please do not let the systemd camel get his
nose in your tent. Systemd is a repudiation of everything Unix, created
by a guy who makes no bones of his hate for Posix.

Post by Jonathan de Boyne Pollard
This is why I am saying
that it's something that you (plural, remember) need to sort out
amongst yourselves. We users stuck in the middle cannot use
address=systemd: and address=unix:runtime=yes with your program on
these systems. As I said, it's something that I had to fix in
November 2015, to stop trying to use address=systemd: on
FreeBSD/TrueOS because it turned out that it didn't actually work. I
thought that address=unix:runtime=yes might, but that did not either.

[snip]

Post by Jonathan de Boyne Pollard

To be brutally honest, there is a fairly low limit to how much
benefit I can create by giving new things to PC-BSD users, [...]

That's not the right way to look at it.

This is precisely the right way to look at it, when it pertains to
systemd.

Post by Jonathan de Boyne Pollard
You yourself have just said
several times that this is stuff that is supposed to be on "supported
Unix platforms". This isn't giving new things to anyone. This is
making existing things, that you yourself think are existing, work.

If these existing things can't be made to work without systemd
incorporation, they should be torn out and replaced. Encumbering a good
system with systemd is not the answer.

Post by Jonathan de Boyne Pollard
I shouldn't dismiss PC-BSD so readily, if I were you, either. PC-BSD
(now rebranded as TrueOS Desktop a few days ago -- I just got through
changing a whole load of preset file and -run package names.) is the
BSD that comes in the box with the desktop environments and with all
of the desktop programs that use Desktop Bus. Yes, people can and do
run all of this stuff on FreeBSD and OpenBSD from ports. But
PC-BSD^H^H^H^H^H^H ... Gah! ... TrueOS Desktop is where it comes in
the box and is run as standard in the default install. TrueOS
Desktop is where one ends up choosing from running PCDMd, kdm, lxdm,
or gdm; and where one gets lots of little Desktop Bus brokers all
over the place in various ways from these different systems. TrueOS
Desktop is where the people who are behind the operating system will
be strongly motivated towards improving the desktop subsystems and
the Desktop Bus.

To those who care about simplicity and user-maintainable software, the
preceding paragraph appears to be one possible strategy to continue
eliminating non-systemd choices. Beware.

Post by Jonathan de Boyne Pollard
You're pushing your new way of per-user Desktop Bus brokers at the
world. I can give the TrueOS Desktop people, and the the UbuntuBSD
people, and the Debian FreeBSD people, a service management system
that I know can run per-user Desktop Bus brokers on a FreeBSD
kernel. It already does. I published it last year. If you, the
Desktop Bus people, can give us these mechanisms in your program
actually working on these operating systems, then the TrueOS people
get the opportunity to simplify some of the scaffolding that they
have had to erect (PCDM-session writing out nonce scripts that invoke
dbus-launch, for example), and you get less of the world still using
your old way of doing things.

LOL, per-user desktops.

There must be a zillion different ways to have sterminal hung off a
Linux box each get their own GUI. I'd do it myself, except that's not
my itch. In a world where a COTS desktop is $600 USD, laptop $500 USD,
and used but still perfectly functional computers can be had for
$50-$200, hanging terminals makes little economic sense. I'm sure the
systemd afficianados will find such a use case, and proclaim that use
case must be served, but we all know it's FUD.

The systemd folks shout from the mountaintops that sysvinit is 32 years
old or whatever, and how that alone is enough reason to use systemd,
and yet these same monuments to modern software proclaim their
multiseat, terminal-enabling technology is a reason to switch to
systemd, even though terminals had their heyday in 1984. Talk about
greybeards.

One more thing: They talk about dbus as if it's a good thing. Even
before systemd, I tried to stay away from a bus system that was pretty
much like a traffic circle enabling everything to talk to everything
else, addressing allowing. What could *possibly* go wrong?

The subject of this thread is "Mass bug filing: use and misuse of
dbus-launch (dbus-x11)". If you're a software user, use dbus as little
as possible. If you're a developer, find other communication methods,
and don't incorporate dbus. Because, as evidenced by this thread, dbus
is now just a pretty entry point to systemd.

SteveT

Steve Litt