the recording button here.
OK.
Thank you again for the great talk,
even though I haven't been able to catch most of it
because I've been running around behind the scenes.
But very much interested in DBUS and Emacs.
I'm very much looking forward to watching it
after the conference.
But for folks who were able to and did catch the talk,
please, now it's time to send in your questions.
You can either ask away on IRC or put them on the pad.
And we'll also open up this PBB room in a little bit
if you'd like to join here directly on asking questions.
So, Ian, please take it away.
Hey, thanks.
Yeah, going to wait for some questions to come in.
But there's a couple of points I wanted to make.
So I'm going to share my screen here for a minute.
If you're interested in exploring more about DBUS,
there is a graphical client called dfeat.
That's d-feat.
I guess puns are strong when it comes to DBUS software.
And this just gives you a graphical overview
of what's going on with your bus.
So in the case that I was looking at in Emacs,
you can look.
Here's the hostname1 service.
And here's you can change the chassis of it or read.
I'm on a desktop here.
So I think this is a really great tool
for just understanding what is available and what DBUS can do.
I think I didn't do a great job of setting out a vision.
So I want to try to reiterate that here.
Ever since I started using X1 several years ago,
and before that even, once I was learning about LISP machines,
one of the things that I really want out of my computing
experience is a full LISP environment,
like a modern LISP machine.
And I think Emacs and X1 are the closest thing to that
that you can get on a modern machine.
But if you're thinking about what
are the gaps between that and a full blown desktop environment,
there is many of them that make it inconvenient
in a variety of different ways.
And my vision is really to have an Emacs desktop environment.
And I think DBUS is really key to making that work.
And I would love, on the one to two year horizon,
I would really like to see common system tasks be
able to get done seamlessly from inside of Emacs.
And what I mean by that is things
like pairing with a Bluetooth device,
connecting to a Wi-Fi network, rebooting your computer
or putting it into suspend, or any of those things
that you might think of doing in a full blown desktop
environment, whether it's Mac OS, or Windows, or GNOME, or KDE,
or whatever, you should be able to do all that from Emacs.
You should be able to manage everything
without having to leave that environment.
Because I really prefer the Emacs environment.
I would like to do all of that from inside Emacs.
And when it comes to integrating with all
those different things, DBUS is really key to making it work.
But I do think that offering the ability of integrating Emacs
into the desktop for people who don't
want to go that route of having a full blown Emacs desktop
environment, I think that's also a path to some really
interesting feature opportunity that
has been difficult to explore in Emacs in years past.
So I really think it's just a great space to be exploring.
And I'm really excited to see what kind of stuff
I can build in there, and what things other people
start building in there.
Sounds great.
Yeah, and I think DBUS is kind of, I guess,
one of those essential key pieces of software
on GNU Linux where, I mean, if it's working,
and when it's working, it's pretty much,
I mean, you don't even notice it.
It's behind the scenes.
Everything seems to be working hand in hand.
So yeah, I remember, for example,
when I first switched to using a custom window manager,
you pretty much lose all of that sort
of integration and togetherness right away
if there is no DBUS.
And yeah, a lot of beginners, like myself at the time
at least, don't even know what they're missing out on.
So kudos for taking this on and having this vision of essentially
moving towards that direction of being able to use Emacs
as a potentially fully featured desktop environment.
I think that's awesome.
Yeah, thank you.
Looks like I have some questions in the pad,
so I will cover some of those.
No, it's not Web3.
Not funny.
I'm sorry, the question was, so is this a Web3 approach?
No, it isn't.
I have another question.
This is such a great overview of DBUS.
I haven't been paying attention to this space
because it seems to be in flux 10 or 15 years ago.
How long has DBUS been around, and what
was in place before that?
So I covered this real briefly in the beginning of the talk,
but DBUS dates from 2002-ish.
And I would say since 2010, 2012, that time frame,
it has been pretty stable and has seen wide adoption
in multiple desktop environments.
Before DBUS, there wasn't anything like it.
It didn't replace a similar feature.
And if you wanted to do the sorts of things
that DBUS does, you were pretty limited.
Those of you who have been around for a while
might remember that a lot of GUI software for Linux
in the 90s was some variant of a shell,
like a graphical shell program that just called out
to an existing binary on the system.
Like you might have a disk formatter,
and it lets you has a dropdown for the file
and lists your devices and whatever.
But it was doing all the work.
All it was was the interface.
All the work was happening by delegating it to a program.
And essentially, what that's doing
is that's turning the text user interface, the command line
user interface, into an API because you're using a program
to talk to it, but it's not really meant for that.
And there's a lot of details in that interface that
are not stable.
Like anyone who's used a Mac after using a Linux machine
has probably been surprised that the find command didn't
work how they expected.
And there's a lot of that.
In order to make that stuff really reliable,
you end up having to build a lot of special cases into it,
but you're doing it at the wrong layer.
And what DBUS does is it really lets
you have a separate architecture where the service is what
encapsulates all of the differences between kernels,
distributions, flavors of tooling,
and just abstracts all of that and gives you a proper API
that you can use.
And I think that's great because that
lets you build these high-level interactive components
at an abstract level where you don't necessarily
need to care about the implementation details.
I think that's really great.
So that's really what was happening there.
And when it comes to two-way stuff,
it was like a fancy version of Unix pipes.
You would run your program, and maybe if you were lucky,
it had some sort of machine-readable output
switch you could turn on so that you
could have a progress bar or something like that.
That was the sort of thing.
But there wasn't really anything exactly like DBUS.
I have another question.
Forgive me if this question is silly.
Why is everything DBUS prefixed with org dot?
Not everything is, but most things are.
Those identifiers are reverse FQDN.
So if you think about the Java namespaces,
that's what they're ripping off there.
And it's org because most of it is written by nonprofits.
So in particular, Free Desktop is
what it sponsors development of DBUS.
And so there is an inordinate number
of org dot Free Desktop dot whatever services on DBUS
just because they build so many of them.
In your investigations, do most OS desktop environment window
manager interop well over DBUS?
Which ones have proven more challenging, if any?
I'm not sure I quite understand this question.
DBUS is fairly abstract, and those graphical programs
can choose to use it or not.
But you're not interacting with the desktop environment
too much.
You're interacting with a service.
So what you're doing is you're taking any program
and you're breaking it into a client server model.
The DBUS service does all of the work,
and then there's a graphical environment on top of it.
So they're communicating back and forth.
And if you want to do those same things,
you want to communicate with the service,
you don't need to communicate with the actual GUI program
unless you want to control the program.
If you want to do the same thing the program is doing,
you can use a DBUS service.
I guess in the case of something like a word processor,
you might want to have a DBUS API that
lets you add a heading or something like that.
That's not an area I've explored too much.
So I'm not sure how that works.
Work done.
Regarding using XWIM as a desktop environment,
does XWIM provide a session manager daemon?
Whoever wrote that, if you could add some more context,
I would appreciate it.
I'm not sure I can answer that as it is written.
No, I don't know.
Next question.
There is a lot of criticism against DBUS out there.
Why do you think that might be?
Well, it's because it's not very good.
I mean, I love what it unlocks feature wise,
but I do think it is not the best implementation
for doing what it does.
But when in Rome, you want to do those things,
I want to do those things, I don't
want to rewrite everything in the way
I think it should have been to get it done because I'll never
get it done.
The whole point is you just shove it in a corner,
you don't have to care about it, and you
use high level bindings.
I would say the specific criticisms I've seen
are using XML is something that is not popular these days.
And if I had to criticize a thing about it,
I would say it doesn't have strong guidelines
for how to make a good API.
And so the quality of one service to another
can be extremely variable.
And different services have different ways
of doing very similar tasks.
So I would love to see, if anything, a little more
uniformity in those APIs.
I generally could care less that it's sending XML around
or whatever.
I think people who are offended that XML is being used
don't have their hearts in the right place, basically.
Which system services come to mind
when thinking about applications,
be it at the OS desktop environment, window manager
level?
So the stuff that I am interested in using this for
is, like I was saying, connecting to wireless networks,
pairing with Bluetooth devices, that kind of stuff.
Things that don't have a streamlined way of accomplishing
it without using D-Bus and some graphical client.
And I would just like to not have
to deal with the client end of it.
I would like the UI to be in Emacs.
When it comes to managing devices,
how are D-Bus and U-Dev related?
U-Dev is a D-Bus service.
So it is a daemon that is running at some point
in the background.
If it's not running, D-Bus will start it
when you send it a message.
And I'm sorry, I'm mistaking U-Dev for U-Disks.
U-Dev is unrelated to D-Bus.
U-Dev is a way of dynamically populating your devices
and having triggers that run when they are plugged in
or unplugged.
They're orthogonal.
D-Bus and U-Dev don't interact.
But D-Bus, I suspect some of the D-Bus services, like U-Disks,
too, probably need to talk to U-Dev in order
to do their job.
But this is a service by service thing,
rather than D-Bus is integrated with U-Dev sort of thing.
Skip one of these.
If you want to do the kinds of things that D-Bus does,
you're limited.
What is something D-Bus does that you couldn't do before?
What is a really cool use of D-Bus
in a modern desktop environment?
So again, I think that the hardware and dynamic refresh
is the use case that I keep coming back to.
You walk somewhere where there's a new Wi-Fi network
or there's an open Wi-Fi network to connect to,
and maybe you get a notification somewhere.
You plug in some hardware and it shows up
in some list or some user interface
to make it easy to use.
You unplug it, it goes away.
Those are the things that I think are really interesting
because when you use a full blown desktop environment,
you have come to expect that kind of interactivity
and that kind of integration from the low level
of the hardware up to whatever graphical layer you're using.
And Emacs doesn't have that, and I want it to have that.
So I think that's the thing that D-Bus really gives me.
I would say in particular, you plug in hardware
and it shows up in a list, that's pretty damn cool.
That's a thing that I don't remember seeing done
without D-Bus, or the way it was done
was not portable and very complicated.
D-Bus allows you to build those types of interfaces
with a lot less work, and I think that's pretty great.
Let's see.
As an average GNU slash Linux user,
I've used signals and methods before but not properties.
You gave an example involving properties,
but it kind of flew by.
Can you explain briefly what clients and services
can do with properties?
Sure, so let me share this screen real quick.
So just looking at hostname1 because this
is a pretty simple and straightforward.
Actually, let me look at U disks.
So here's a whole mess of disks that are connected,
and you can see here's a block device
and it has all of these different properties to it.
So hit system will say, is this a system device?
Is this a fixed device, something
that the system is in control of mounting,
or is this something that a user might want to interact with?
That property is how you're going to know
which one of those things are, and I
think that's really important when you're building a UI.
Maybe you want to hide the system disks
because you can see them, but there's not much you can do.
I can't unmount my root device without turning the computer
off.
So the things you might want to do
at a graphical interactive level are pretty limited,
and that property lets you figure that out.
Here's a crypto vacuum device that read only
what drives it's associated with.
They really bundle up just a lot of metadata about the thing,
and they have a lot of links in between the different objects.
So looking at one thing, you can connect it up
to other parts of it at different levels.
There's the notion of a drive, which contains a block device,
which can have some partition tables, which
can have file systems, or maybe an encryption container that
has more of those things.
So it's really a tree, but it's a strangely modeled tree
where you have to walk the different leaves.
It's not a single tree that encapsulates everything.
It is a tree of links into other bits of the tree,
essentially.
So they're important to use for that sort of thing.
The other thing that properties do
is the signals let you know when a property has been updated.
So if your hostname changes, you can
get a signal that says, hey, my hostname changed,
and maybe give a notice.
Or if your active network connection changes
or disconnects, a signal is going to be what tells you that,
and the change in property is what will drive the signal.
So it's kind of related to that.
Naive question, me not knowing much about D-Bus.
Is there such a thing as a D-Bus reflection browser,
maybe Emacs-based, that lets you discover
all the behavior different D-Bus app participants provide?
And actually, wait, I think you're showing it.
Defeat is that.
Definitely a to-do item is to build an Emacs Lisp interface
that is akin to Defeat, but I have not done that.
So pull requests, welcome.
Next question, D-Bus seems great for extensibility,
but then Emacs has no such mechanism
and is fantastically more extensible.
Why do you think this is so?
I don't think I agree with the premise.
D-Bus is not really that extensible in the way
that you might think in the same context as Emacs.
You can add new functionality by adding a new service,
but you can't add new functionality
to an existing service without changing it.
So I'm not sure I would say that's
extensible in the same way, whereas Emacs is very malleable
and you can change how it works even while it's running.
So I think it's a different kind of extensibility, really.
And Emacs can participate on D-Bus,
so Emacs has a superset of what D-Bus can do, really.
Do you have any other cool D-Bus ideas?
I think I have dropped them all.
Definitely remote org capture is a thing
that I have wanted a couple of times
because if I'm browsing around somewhere,
I'd really love to have a simple flow that
allows me to turn a web page into an org capture.
And I think D-Bus could be a good way of accomplishing that,
although I haven't messed with the browser integration
end of it.
Are there buses besides system and session?
Is there anything more to a bus besides a way
to group objects?
There are always at least a system bus and a session bus.
And actually, that's maybe not completely true.
There's always at least a system bus, session bus
as long as there is at least one logged in session.
And there's really more than one session bus.
There's one bus per session so that you're not leaking stuff
across sessions on the same computer
because despite this being 2022, Unix
is still a multi-user operating system
and you have to think about that stuff.
There are an unlimited number of D-Bus buses.
You can create ones that have limited sets of services.
You can connect to ones over a TCP socket.
There are always generally at least system and session.
There can additionally be other ones.
But it is uncommon to have any other bus.
Generally, well-behaved D-Bus services
will attach to one or the other of those two buses.
And in fact, PulseAudio is, it has D-Bus support
but it is not a good D-Bus citizen
because it does not use the session bus.
It has, it's very weird actually.
It has a D-Bus plug-in that hooks into the session bus
but all it has is a method that returns the path to the Unix
socket of the real D-Bus which you then
have to connect to separately which strikes me
as not the best way of doing that.
Cool.
All right, I think that is all of the questions.
Cool, I think we still have about like six and a half
or seven more minutes of Q&A on the stream.
So if there are any more questions, folks,
please feel free to post them on the pad
or come up here, join us on BBB.
Yeah, we can hang out here for a little bit longer.
The stream will move on at some point
but Ian, of course, and anyone else who is interested
is welcome to hang out if Ian is around.
Yeah.
I will be around for a bit.
I am on IRC all the time but I'm not always
paying attention to it.
You're welcome to reach out to me there.
This is with almost all of my Emacs packages and stuff.
This is in my Emacs Weirdware project on Codeburg.
So codeburg.org slash Emacs dash weirdware
has everything that I demoed and some other wonderful goodies
that maybe you already know about and maybe you don't.
I saw one other question from the chat, which
is what do you use this for?
Well, I mean, the main thing I use it for
is discomfort for managing external devices.
But this has been a really great research project
just to understand D-Bus better, see what it can offer,
and write some interesting code because what I really like
is writing code that unlocks new possibilities
to where people can look at it and say,
oh, that gives me a great idea.
I want to do this with it.
And I see D-Base and this talk as really just pushing
mindshare on this stuff.
And really, the best result of this talk
is for people to come out of it and say, wow, that was awesome.
I can't wait to build something with it and go build new stuff.
And just kind of building those platforms
that other people can use and find helpful
in whatever their programming journey is.
That's the thing that I really like.
That means a lot to me.
So I hope that someone watches this
and comes away with a good idea and goes and hacks on it.
Looks like there's one more question.
I'm not sure if we have time.
I'll follow up in the pad if we end up over time on that.
Yeah, we still have a couple more minutes,
so it should be good.
OK, so the last question is, it looks
like D-Bus is mostly useful for Emacs to do IPC.
If I understand correctly, this is
how SIGTEX works when working with LaTeX docs.
How does it compare with other ways of doing IPC,
for example, communicating over a socket with MPD?
So the main way that it's different
is that MPD has its own protocol that you
have to build support for in whatever your client is.
D-Bus gives you a single, uniform way
of talking to any service.
So instead of having to reinvent that socket code
and write the protocol support for MPD or whatever else,
where you're taking the concrete, what
are the bytes over the wire, and building
an abstract programming interface that wraps that
and drives those things, D-Bus already provides all of that.
So you can say, here's a description of everything
that I already do, and you can code gen stuff
to do all of it.
So I think that's the main difference between them.
But it is over a socket.
It's over a Unix socket for local stuff, TCP for remote.
It is very similar.
The main difference is that it is
a framework for multiple applications
rather than an application-specific mechanism,
which makes it very easy to reuse
in a variety of different contexts.
And I think that's been key to its popularity
over the last 10 years or so is the fact
that it provides just enough opinion about how stuff should
work that you don't have to think too hard about what
should the protocol be.
Should it be binary?
Should it be text?
Should it be S expressions?
Should it be JSON?
It's already done for you, and you can just think about,
how do I connect it up?
And I think that provides a lot of value.
Yeah, and I can second that.
It's been adopted by all sorts of different software
projects, one of which I worked on.
Jammy, people might know, GNU package
for basically universal communication.
It's basically a text messaging and also audio video calling
and conferencing application.
And it's Daemon, which runs in the background.
It also supports D-Bus, so you can do all sorts of things,
write little Python scripts or whatever,
talk with it through D-Bus, give it commands
to take calls from a particular point
or just hang up calls or just do all sorts of things
over D-Bus.
And it is all, like you said, sort of application agnostic.
It's not specific to, oh, how would I
do this in a different way for each individual application?
Yeah, exactly.
It's the de facto way of doing that sort of stuff
on Linux machines these days.
And you can look back to some of the other message passing
stuff in Windows and see it's drawn some inspiration
from a variety of different places and different ways
of doing that kind of interactivity.
But it is, I mean, I don't think there was ever
really a serious competitor to it,
but it is the de facto standard if you
want to do any kind of graphical program that
manipulates your system or a batch program that
drives an otherwise purely interactive graphical program.
That's the tool.
And there is not really any competitive landscape or reason
to go reinventing it at this time.
Sounds good.
And I think that's all the time that we
have on the live stream.
Folks, you are welcome to stick around on IRC
or come here on BBB and continue talking to Ian.
Thank you, Ian.
Wonderful.
Thank you so much.
Cheers.
All right.
I think the stream has moved on.
Yeah, you're welcome to stay here, Ian, if you like,
or just continue catching up with folks in IRC.
Great.
I will hang out here for a little bit
in case someone wants to jump in and just write
some stuff in the pad.
Sounds good.
Thank you.
And I do see people are still writing or posting on the pad,
so that's awesome.
Yeah, sure thing.
Awesome.
Thank you so much.
All right.
Cheers.
Welcome.
And yeah, see you around on IRC.
All right.