Hi!

I read this great Devuan ML whenever I have time, and am still so
excited to be using Devuan some day, but am slow to learn things (am
almost 60 and started less then 20 ys ago, before that I was not a
computer user at all... and I work slow like a turtle.)

The original that I was able to find:

[ same title as this Steve Litt's message I'm replying to ]
https://lists.debian.org/debian-devel/2016/09/msg00056.html
(and a backup for future reference, just in case:
http://osdir.com/ml/debian-devel/2016-09/msg00056.html )

I'd need more time to understand the full details of this message
(reported in its entirety below, I believe):
On 160905-12:47-0400, Steve Litt wrote:
> On Sun, 4 Sep 2016 17:30:43 +0100
> Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@???>
> wrote:
>
> > Simon McVittie:
> >
> > > 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.
> >
> > Simon McVittie:
> >
> > > 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. (-:
>
> 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.
I like the statement above so much. That's what I felt it was pretty
soon, really more like felt than understood, and I was so right... Well:
I vaguely but impressively understood, as user.

>
> Do not cooperate with systemd. The systemd proponents don't cooperate
> with anyone else.
So right! And the other Steve's remarks below...
>
>
> > 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).
>
> > 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.
>
> >
> > Simon McVittie:
> >
> > >> 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.
>
>
> > 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]
> >
> > Simon McVittie:
> >
> > > 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.
>
> > 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.
>
> >
> > 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.
>
> >
> > 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.

"dbus is" (probably was part of the plan, and not just become all of a
sudden) "now just a pretty entry point to systemd."

That's what I was, of course not so explicitely and not in such learned
words ;-) but that's what I was saying back when I wrote:

Uninstalling dbus and *kits (to Unfacilitate Remote Seats)
https://forums.gentoo.org/viewtopic-t-992146.html

and Isaac Dunham put it more clearly than I would know:

https://lists.dyne.org/lurker/message/20150724.032546.cdebd81f.en.html

"The OP" (me, Miroslav Rovis) "has repeatedly stated that systemd,
pulse, and dbus are all backdoors for remote exploits, and provided
notes on removing them with the aid of Thorsten's repositories and
hardening a system with grsec; these notes have been useful to some,
despite the OP not being fluent in English."

See the thread:
https://lists.dyne.org/lurker/thread/20150727.104841.34107d9e.en.html#20150727.104841.34107d9e
Steve wrote there too...

So, just let's make people aware that:

=====================================================================
"systemd, pulse, and dbus are all backdoors for remote exploits"
            ( in my strong opinion )
=====================================================================

Of course, as soon as I'm able to (I only install in Air-Gapped, no way
would I install straight from the Internet and trust that the system is
clean... )

[Of course, as soon as I'm able to], I surely will go for (or from):

https://git.devuan.org/dev1fanboy/Upgrade-Install-Devuan/wikis/Upgrade-to-Devuan-and-minimalism

because there's "Removing dbus" there ;-)
)

And maybe one note allow me to add:

The great OpenRC which Gentoo folks offer to the world boasts no
dependency on Dbus:

https://wiki.gentoo.org/wiki/Comparison_of_init_systems

and I see the plan is to go the OpenRC way in Devuan...

I hope you guys won't all grow gray long beards before I finally install
Devuan ;-)

--
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr