path: root/2022/captions/emacsconf-2022-dbus--the-wheels-on-dbus--ian-eure--answers.vtt

WEBVTT

00:00.000 --> 00:02.600
the recording button here.

00:02.600 --> 00:03.600
OK.

00:03.600 --> 00:05.180
Thank you again for the great talk,

00:05.180 --> 00:06.680
even though I haven't been able to catch most of it

00:06.680 --> 00:08.560
because I've been running around behind the scenes.

00:08.560 --> 00:11.360
But very much interested in DBUS and Emacs.

00:11.360 --> 00:13.240
I'm very much looking forward to watching it

00:13.240 --> 00:14.080
after the conference.

00:14.080 --> 00:18.360
But for folks who were able to and did catch the talk,

00:18.360 --> 00:21.680
please, now it's time to send in your questions.

00:21.680 --> 00:24.820
You can either ask away on IRC or put them on the pad.

00:24.820 --> 00:28.300
And we'll also open up this PBB room in a little bit

00:28.300 --> 00:31.960
if you'd like to join here directly on asking questions.

00:31.960 --> 00:34.520
So, Ian, please take it away.

00:34.520 --> 00:35.280
Hey, thanks.

00:35.280 --> 00:38.580
Yeah, going to wait for some questions to come in.

00:38.580 --> 00:41.320
But there's a couple of points I wanted to make.

00:41.320 --> 00:46.840
So I'm going to share my screen here for a minute.

00:46.840 --> 00:50.880
If you're interested in exploring more about DBUS,

00:50.880 --> 00:54.080
there is a graphical client called dfeat.

00:54.080 --> 00:56.200
That's d-feat.

00:56.200 --> 00:59.960
I guess puns are strong when it comes to DBUS software.

00:59.960 --> 01:03.400
And this just gives you a graphical overview

01:03.400 --> 01:06.160
of what's going on with your bus.

01:06.160 --> 01:09.920
So in the case that I was looking at in Emacs,

01:09.920 --> 01:11.600
you can look.

01:11.600 --> 01:13.280
Here's the hostname1 service.

01:13.280 --> 01:18.360
And here's you can change the chassis of it or read.

01:18.360 --> 01:20.240
I'm on a desktop here.

01:20.240 --> 01:23.940
So I think this is a really great tool

01:23.940 --> 01:30.720
for just understanding what is available and what DBUS can do.

01:30.720 --> 01:33.720
I think I didn't do a great job of setting out a vision.

01:33.720 --> 01:37.000
So I want to try to reiterate that here.

01:37.000 --> 01:41.320
Ever since I started using X1 several years ago,

01:41.320 --> 01:46.480
and before that even, once I was learning about LISP machines,

01:46.480 --> 01:48.920
one of the things that I really want out of my computing

01:48.920 --> 01:52.720
experience is a full LISP environment,

01:52.720 --> 01:54.400
like a modern LISP machine.

01:54.400 --> 01:59.440
And I think Emacs and X1 are the closest thing to that

01:59.440 --> 02:01.800
that you can get on a modern machine.

02:01.800 --> 02:03.760
But if you're thinking about what

02:03.760 --> 02:07.680
are the gaps between that and a full blown desktop environment,

02:07.680 --> 02:10.800
there is many of them that make it inconvenient

02:10.800 --> 02:12.760
in a variety of different ways.

02:12.760 --> 02:17.600
And my vision is really to have an Emacs desktop environment.

02:17.600 --> 02:21.080
And I think DBUS is really key to making that work.

02:21.080 --> 02:24.760
And I would love, on the one to two year horizon,

02:24.760 --> 02:29.080
I would really like to see common system tasks be

02:29.080 --> 02:32.680
able to get done seamlessly from inside of Emacs.

02:32.680 --> 02:34.640
And what I mean by that is things

02:34.640 --> 02:37.440
like pairing with a Bluetooth device,

02:37.440 --> 02:41.440
connecting to a Wi-Fi network, rebooting your computer

02:41.440 --> 02:44.440
or putting it into suspend, or any of those things

02:44.440 --> 02:47.800
that you might think of doing in a full blown desktop

02:47.800 --> 02:51.320
environment, whether it's Mac OS, or Windows, or GNOME, or KDE,

02:51.320 --> 02:53.920
or whatever, you should be able to do all that from Emacs.

02:53.920 --> 02:56.840
You should be able to manage everything

02:56.840 --> 02:59.200
without having to leave that environment.

02:59.200 --> 03:02.160
Because I really prefer the Emacs environment.

03:02.160 --> 03:05.520
I would like to do all of that from inside Emacs.

03:05.520 --> 03:07.380
And when it comes to integrating with all

03:07.380 --> 03:11.960
those different things, DBUS is really key to making it work.

03:11.960 --> 03:20.560
But I do think that offering the ability of integrating Emacs

03:20.560 --> 03:23.160
into the desktop for people who don't

03:23.160 --> 03:26.720
want to go that route of having a full blown Emacs desktop

03:26.720 --> 03:30.880
environment, I think that's also a path to some really

03:30.880 --> 03:35.200
interesting feature opportunity that

03:35.200 --> 03:39.760
has been difficult to explore in Emacs in years past.

03:39.760 --> 03:44.160
So I really think it's just a great space to be exploring.

03:44.160 --> 03:46.280
And I'm really excited to see what kind of stuff

03:46.280 --> 03:48.520
I can build in there, and what things other people

03:48.520 --> 03:49.600
start building in there.

03:53.400 --> 03:54.160
Sounds great.

03:54.160 --> 03:57.640
Yeah, and I think DBUS is kind of, I guess,

03:57.640 --> 04:00.680
one of those essential key pieces of software

04:00.680 --> 04:03.120
on GNU Linux where, I mean, if it's working,

04:03.120 --> 04:05.240
and when it's working, it's pretty much,

04:05.240 --> 04:06.800
I mean, you don't even notice it.

04:06.800 --> 04:07.760
It's behind the scenes.

04:07.760 --> 04:09.600
Everything seems to be working hand in hand.

04:09.600 --> 04:11.880
So yeah, I remember, for example,

04:11.880 --> 04:14.600
when I first switched to using a custom window manager,

04:14.600 --> 04:16.760
you pretty much lose all of that sort

04:16.760 --> 04:20.200
of integration and togetherness right away

04:20.200 --> 04:22.440
if there is no DBUS.

04:22.440 --> 04:24.560
And yeah, a lot of beginners, like myself at the time

04:24.560 --> 04:27.480
at least, don't even know what they're missing out on.

04:27.480 --> 04:33.200
So kudos for taking this on and having this vision of essentially

04:33.200 --> 04:35.840
moving towards that direction of being able to use Emacs

04:35.840 --> 04:38.840
as a potentially fully featured desktop environment.

04:38.840 --> 04:40.680
I think that's awesome.

04:40.680 --> 04:42.560
Yeah, thank you.

04:42.560 --> 04:44.880
Looks like I have some questions in the pad,

04:44.880 --> 04:47.160
so I will cover some of those.

04:47.160 --> 04:48.720
No, it's not Web3.

04:48.720 --> 04:49.320
Not funny.

04:52.440 --> 04:54.840
I'm sorry, the question was, so is this a Web3 approach?

04:54.840 --> 04:56.840
No, it isn't.

04:56.840 --> 04:58.160
I have another question.

04:58.160 --> 04:59.960
This is such a great overview of DBUS.

04:59.960 --> 05:01.800
I haven't been paying attention to this space

05:01.800 --> 05:05.120
because it seems to be in flux 10 or 15 years ago.

05:05.120 --> 05:07.040
How long has DBUS been around, and what

05:07.040 --> 05:09.160
was in place before that?

05:09.160 --> 05:11.960
So I covered this real briefly in the beginning of the talk,

05:11.960 --> 05:15.400
but DBUS dates from 2002-ish.

05:15.400 --> 05:21.760
And I would say since 2010, 2012, that time frame,

05:21.760 --> 05:26.080
it has been pretty stable and has seen wide adoption

05:26.080 --> 05:28.600
in multiple desktop environments.

05:28.600 --> 05:30.800
Before DBUS, there wasn't anything like it.

05:30.800 --> 05:33.120
It didn't replace a similar feature.

05:33.120 --> 05:35.320
And if you wanted to do the sorts of things

05:35.320 --> 05:40.160
that DBUS does, you were pretty limited.

05:40.160 --> 05:42.600
Those of you who have been around for a while

05:42.600 --> 05:45.600
might remember that a lot of GUI software for Linux

05:45.600 --> 05:49.840
in the 90s was some variant of a shell,

05:49.840 --> 05:53.720
like a graphical shell program that just called out

05:53.720 --> 05:57.160
to an existing binary on the system.

05:57.160 --> 05:59.200
Like you might have a disk formatter,

05:59.200 --> 06:01.320
and it lets you has a dropdown for the file

06:01.320 --> 06:03.400
and lists your devices and whatever.

06:03.400 --> 06:04.960
But it was doing all the work.

06:04.960 --> 06:06.200
All it was was the interface.

06:06.200 --> 06:09.480
All the work was happening by delegating it to a program.

06:09.480 --> 06:12.000
And essentially, what that's doing

06:12.000 --> 06:16.480
is that's turning the text user interface, the command line

06:16.480 --> 06:19.880
user interface, into an API because you're using a program

06:19.880 --> 06:22.680
to talk to it, but it's not really meant for that.

06:22.680 --> 06:27.400
And there's a lot of details in that interface that

06:27.400 --> 06:29.240
are not stable.

06:29.240 --> 06:33.480
Like anyone who's used a Mac after using a Linux machine

06:33.480 --> 06:37.240
has probably been surprised that the find command didn't

06:37.240 --> 06:38.960
work how they expected.

06:38.960 --> 06:40.480
And there's a lot of that.

06:40.480 --> 06:43.000
In order to make that stuff really reliable,

06:43.000 --> 06:47.600
you end up having to build a lot of special cases into it,

06:47.600 --> 06:49.680
but you're doing it at the wrong layer.

06:49.680 --> 06:51.440
And what DBUS does is it really lets

06:51.440 --> 06:55.320
you have a separate architecture where the service is what

06:55.320 --> 06:59.200
encapsulates all of the differences between kernels,

06:59.200 --> 07:02.280
distributions, flavors of tooling,

07:02.280 --> 07:05.440
and just abstracts all of that and gives you a proper API

07:05.440 --> 07:06.400
that you can use.

07:06.400 --> 07:07.860
And I think that's great because that

07:07.860 --> 07:12.600
lets you build these high-level interactive components

07:12.600 --> 07:15.320
at an abstract level where you don't necessarily

07:15.320 --> 07:17.280
need to care about the implementation details.

07:17.280 --> 07:19.480
I think that's really great.

07:19.480 --> 07:21.400
So that's really what was happening there.

07:21.400 --> 07:23.680
And when it comes to two-way stuff,

07:23.680 --> 07:26.480
it was like a fancy version of Unix pipes.

07:26.480 --> 07:29.760
You would run your program, and maybe if you were lucky,

07:29.760 --> 07:32.360
it had some sort of machine-readable output

07:32.360 --> 07:33.960
switch you could turn on so that you

07:33.960 --> 07:37.480
could have a progress bar or something like that.

07:37.480 --> 07:38.600
That was the sort of thing.

07:38.600 --> 07:40.720
But there wasn't really anything exactly like DBUS.

07:45.240 --> 07:46.480
I have another question.

07:46.480 --> 07:48.360
Forgive me if this question is silly.

07:48.360 --> 07:53.320
Why is everything DBUS prefixed with org dot?

07:53.320 --> 07:57.800
Not everything is, but most things are.

07:57.800 --> 08:00.800
Those identifiers are reverse FQDN.

08:00.800 --> 08:03.560
So if you think about the Java namespaces,

08:03.560 --> 08:05.960
that's what they're ripping off there.

08:05.960 --> 08:09.680
And it's org because most of it is written by nonprofits.

08:09.680 --> 08:12.320
So in particular, Free Desktop is

08:12.320 --> 08:15.040
what it sponsors development of DBUS.

08:15.040 --> 08:17.320
And so there is an inordinate number

08:17.320 --> 08:22.480
of org dot Free Desktop dot whatever services on DBUS

08:22.480 --> 08:28.480
just because they build so many of them.

08:28.480 --> 08:32.680
In your investigations, do most OS desktop environment window

08:32.680 --> 08:35.360
manager interop well over DBUS?

08:35.360 --> 08:38.160
Which ones have proven more challenging, if any?

08:40.960 --> 08:45.280
I'm not sure I quite understand this question.

08:45.280 --> 08:49.720
DBUS is fairly abstract, and those graphical programs

08:49.720 --> 08:53.360
can choose to use it or not.

08:53.360 --> 08:58.440
But you're not interacting with the desktop environment

08:58.440 --> 08:59.040
too much.

08:59.040 --> 09:01.200
You're interacting with a service.

09:01.200 --> 09:03.720
So what you're doing is you're taking any program

09:03.720 --> 09:06.520
and you're breaking it into a client server model.

09:06.520 --> 09:09.680
The DBUS service does all of the work,

09:09.680 --> 09:12.360
and then there's a graphical environment on top of it.

09:12.360 --> 09:14.640
So they're communicating back and forth.

09:14.640 --> 09:16.320
And if you want to do those same things,

09:16.320 --> 09:18.080
you want to communicate with the service,

09:18.080 --> 09:22.400
you don't need to communicate with the actual GUI program

09:22.400 --> 09:25.000
unless you want to control the program.

09:25.000 --> 09:27.240
If you want to do the same thing the program is doing,

09:27.240 --> 09:28.680
you can use a DBUS service.

09:28.680 --> 09:30.960
I guess in the case of something like a word processor,

09:30.960 --> 09:32.720
you might want to have a DBUS API that

09:32.720 --> 09:35.720
lets you add a heading or something like that.

09:35.720 --> 09:39.160
That's not an area I've explored too much.

09:39.160 --> 09:40.760
So I'm not sure how that works.

09:40.760 --> 09:42.760
Work done.

09:46.120 --> 09:49.080
Regarding using XWIM as a desktop environment,

09:49.080 --> 09:55.040
does XWIM provide a session manager daemon?

09:55.040 --> 09:57.200
Whoever wrote that, if you could add some more context,

09:57.200 --> 09:58.080
I would appreciate it.

09:58.080 --> 10:01.000
I'm not sure I can answer that as it is written.

10:04.120 --> 10:07.560
No, I don't know.

10:07.560 --> 10:08.720
Next question.

10:08.720 --> 10:11.600
There is a lot of criticism against DBUS out there.

10:11.600 --> 10:13.280
Why do you think that might be?

10:13.280 --> 10:15.200
Well, it's because it's not very good.

10:18.600 --> 10:21.960
I mean, I love what it unlocks feature wise,

10:21.960 --> 10:25.240
but I do think it is not the best implementation

10:25.240 --> 10:28.240
for doing what it does.

10:28.240 --> 10:31.640
But when in Rome, you want to do those things,

10:31.640 --> 10:32.760
I want to do those things, I don't

10:32.760 --> 10:34.480
want to rewrite everything in the way

10:34.480 --> 10:36.960
I think it should have been to get it done because I'll never

10:36.960 --> 10:37.760
get it done.

10:37.760 --> 10:39.880
The whole point is you just shove it in a corner,

10:39.880 --> 10:41.600
you don't have to care about it, and you

10:41.600 --> 10:43.440
use high level bindings.

10:43.440 --> 10:46.040
I would say the specific criticisms I've seen

10:46.040 --> 10:54.720
are using XML is something that is not popular these days.

10:54.720 --> 10:58.260
And if I had to criticize a thing about it,

10:58.260 --> 11:02.240
I would say it doesn't have strong guidelines

11:02.240 --> 11:03.680
for how to make a good API.

11:03.680 --> 11:06.120
And so the quality of one service to another

11:06.120 --> 11:09.120
can be extremely variable.

11:09.120 --> 11:12.360
And different services have different ways

11:12.360 --> 11:14.440
of doing very similar tasks.

11:14.440 --> 11:16.960
So I would love to see, if anything, a little more

11:16.960 --> 11:19.960
uniformity in those APIs.

11:19.960 --> 11:22.840
I generally could care less that it's sending XML around

11:22.840 --> 11:23.760
or whatever.

11:23.760 --> 11:30.920
I think people who are offended that XML is being used

11:30.920 --> 11:37.560
don't have their hearts in the right place, basically.

11:37.560 --> 11:45.320
Which system services come to mind

11:45.320 --> 11:47.000
when thinking about applications,

11:47.000 --> 11:49.760
be it at the OS desktop environment, window manager

11:49.760 --> 11:50.440
level?

11:50.440 --> 11:53.520
So the stuff that I am interested in using this for

11:53.520 --> 11:56.600
is, like I was saying, connecting to wireless networks,

11:56.600 --> 11:59.360
pairing with Bluetooth devices, that kind of stuff.

11:59.360 --> 12:04.520
Things that don't have a streamlined way of accomplishing

12:04.520 --> 12:07.960
it without using D-Bus and some graphical client.

12:07.960 --> 12:09.360
And I would just like to not have

12:09.360 --> 12:11.360
to deal with the client end of it.

12:11.360 --> 12:14.160
I would like the UI to be in Emacs.

12:19.720 --> 12:21.160
When it comes to managing devices,

12:21.160 --> 12:23.760
how are D-Bus and U-Dev related?

12:23.760 --> 12:25.760
U-Dev is a D-Bus service.

12:25.760 --> 12:30.520
So it is a daemon that is running at some point

12:30.520 --> 12:31.760
in the background.

12:31.760 --> 12:33.520
If it's not running, D-Bus will start it

12:33.520 --> 12:35.040
when you send it a message.

12:35.040 --> 12:42.120
And I'm sorry, I'm mistaking U-Dev for U-Disks.

12:42.120 --> 12:46.640
U-Dev is unrelated to D-Bus.

12:46.640 --> 12:53.400
U-Dev is a way of dynamically populating your devices

12:53.400 --> 12:56.520
and having triggers that run when they are plugged in

12:56.520 --> 12:57.600
or unplugged.

12:57.600 --> 12:59.840
They're orthogonal.

12:59.840 --> 13:02.120
D-Bus and U-Dev don't interact.

13:02.120 --> 13:08.520
But D-Bus, I suspect some of the D-Bus services, like U-Disks,

13:08.520 --> 13:11.720
too, probably need to talk to U-Dev in order

13:11.720 --> 13:13.080
to do their job.

13:13.080 --> 13:16.200
But this is a service by service thing,

13:16.200 --> 13:27.400
rather than D-Bus is integrated with U-Dev sort of thing.

13:27.400 --> 13:29.320
Skip one of these.

13:29.320 --> 13:32.200
If you want to do the kinds of things that D-Bus does,

13:32.200 --> 13:33.280
you're limited.

13:33.280 --> 13:35.880
What is something D-Bus does that you couldn't do before?

13:35.880 --> 13:37.520
What is a really cool use of D-Bus

13:37.520 --> 13:39.880
in a modern desktop environment?

13:39.880 --> 13:43.680
So again, I think that the hardware and dynamic refresh

13:43.680 --> 13:47.520
is the use case that I keep coming back to.

13:47.520 --> 13:50.760
You walk somewhere where there's a new Wi-Fi network

13:50.760 --> 13:52.960
or there's an open Wi-Fi network to connect to,

13:52.960 --> 13:55.240
and maybe you get a notification somewhere.

13:55.240 --> 13:57.360
You plug in some hardware and it shows up

13:57.360 --> 13:59.880
in some list or some user interface

13:59.880 --> 14:01.880
to make it easy to use.

14:01.880 --> 14:03.600
You unplug it, it goes away.

14:03.600 --> 14:05.960
Those are the things that I think are really interesting

14:05.960 --> 14:10.600
because when you use a full blown desktop environment,

14:10.600 --> 14:14.240
you have come to expect that kind of interactivity

14:14.240 --> 14:17.760
and that kind of integration from the low level

14:17.760 --> 14:21.760
of the hardware up to whatever graphical layer you're using.

14:21.760 --> 14:26.440
And Emacs doesn't have that, and I want it to have that.

14:26.440 --> 14:32.000
So I think that's the thing that D-Bus really gives me.

14:32.000 --> 14:34.240
I would say in particular, you plug in hardware

14:34.240 --> 14:37.240
and it shows up in a list, that's pretty damn cool.

14:37.240 --> 14:40.640
That's a thing that I don't remember seeing done

14:40.640 --> 14:43.400
without D-Bus, or the way it was done

14:43.400 --> 14:47.240
was not portable and very complicated.

14:47.240 --> 14:50.320
D-Bus allows you to build those types of interfaces

14:50.320 --> 14:53.280
with a lot less work, and I think that's pretty great.

14:58.640 --> 14:59.680
Let's see.

14:59.680 --> 15:02.040
As an average GNU slash Linux user,

15:02.040 --> 15:05.320
I've used signals and methods before but not properties.

15:05.320 --> 15:07.600
You gave an example involving properties,

15:07.600 --> 15:08.880
but it kind of flew by.

15:08.880 --> 15:11.640
Can you explain briefly what clients and services

15:11.640 --> 15:13.960
can do with properties?

15:13.960 --> 15:20.880
Sure, so let me share this screen real quick.

15:20.880 --> 15:26.000
So just looking at hostname1 because this

15:26.000 --> 15:28.480
is a pretty simple and straightforward.

15:28.480 --> 15:32.920
Actually, let me look at U disks.

15:32.920 --> 15:36.720
So here's a whole mess of disks that are connected,

15:36.720 --> 15:39.360
and you can see here's a block device

15:39.360 --> 15:41.960
and it has all of these different properties to it.

15:41.960 --> 15:46.600
So hit system will say, is this a system device?

15:46.600 --> 15:48.680
Is this a fixed device, something

15:48.680 --> 15:50.400
that the system is in control of mounting,

15:50.400 --> 15:53.000
or is this something that a user might want to interact with?

15:53.000 --> 15:55.160
That property is how you're going to know

15:55.160 --> 15:56.600
which one of those things are, and I

15:56.600 --> 15:58.880
think that's really important when you're building a UI.

15:58.880 --> 16:00.480
Maybe you want to hide the system disks

16:00.480 --> 16:04.280
because you can see them, but there's not much you can do.

16:04.280 --> 16:07.440
I can't unmount my root device without turning the computer

16:07.440 --> 16:07.960
off.

16:07.960 --> 16:11.760
So the things you might want to do

16:11.760 --> 16:15.800
at a graphical interactive level are pretty limited,

16:15.800 --> 16:19.440
and that property lets you figure that out.

16:19.440 --> 16:22.400
Here's a crypto vacuum device that read only

16:22.400 --> 16:24.240
what drives it's associated with.

16:24.240 --> 16:28.280
They really bundle up just a lot of metadata about the thing,

16:28.280 --> 16:31.400
and they have a lot of links in between the different objects.

16:31.400 --> 16:36.480
So looking at one thing, you can connect it up

16:36.480 --> 16:39.560
to other parts of it at different levels.

16:39.560 --> 16:43.440
There's the notion of a drive, which contains a block device,

16:43.440 --> 16:45.560
which can have some partition tables, which

16:45.560 --> 16:49.200
can have file systems, or maybe an encryption container that

16:49.200 --> 16:50.800
has more of those things.

16:50.800 --> 16:57.160
So it's really a tree, but it's a strangely modeled tree

16:57.160 --> 17:00.880
where you have to walk the different leaves.

17:00.880 --> 17:03.200
It's not a single tree that encapsulates everything.

17:03.200 --> 17:07.360
It is a tree of links into other bits of the tree,

17:07.360 --> 17:07.960
essentially.

17:07.960 --> 17:11.920
So they're important to use for that sort of thing.

17:16.320 --> 17:17.680
The other thing that properties do

17:17.680 --> 17:24.440
is the signals let you know when a property has been updated.

17:24.440 --> 17:28.640
So if your hostname changes, you can

17:28.640 --> 17:30.600
get a signal that says, hey, my hostname changed,

17:30.600 --> 17:32.840
and maybe give a notice.

17:32.840 --> 17:35.440
Or if your active network connection changes

17:35.440 --> 17:39.320
or disconnects, a signal is going to be what tells you that,

17:39.320 --> 17:43.200
and the change in property is what will drive the signal.

17:43.200 --> 17:44.840
So it's kind of related to that.

17:49.920 --> 17:53.120
Naive question, me not knowing much about D-Bus.

17:53.120 --> 17:56.400
Is there such a thing as a D-Bus reflection browser,

17:56.400 --> 17:58.280
maybe Emacs-based, that lets you discover

17:58.280 --> 18:02.160
all the behavior different D-Bus app participants provide?

18:02.160 --> 18:04.160
And actually, wait, I think you're showing it.

18:04.160 --> 18:06.320
Defeat is that.

18:06.320 --> 18:11.440
Definitely a to-do item is to build an Emacs Lisp interface

18:11.440 --> 18:16.520
that is akin to Defeat, but I have not done that.

18:16.520 --> 18:17.760
So pull requests, welcome.

18:17.760 --> 18:25.920
Next question, D-Bus seems great for extensibility,

18:25.920 --> 18:28.240
but then Emacs has no such mechanism

18:28.240 --> 18:30.680
and is fantastically more extensible.

18:30.680 --> 18:31.960
Why do you think this is so?

18:34.680 --> 18:37.840
I don't think I agree with the premise.

18:37.840 --> 18:42.400
D-Bus is not really that extensible in the way

18:42.400 --> 18:46.560
that you might think in the same context as Emacs.

18:46.560 --> 18:49.360
You can add new functionality by adding a new service,

18:49.360 --> 18:51.080
but you can't add new functionality

18:51.080 --> 18:54.000
to an existing service without changing it.

18:54.000 --> 18:57.120
So I'm not sure I would say that's

18:57.120 --> 19:01.080
extensible in the same way, whereas Emacs is very malleable

19:01.080 --> 19:06.120
and you can change how it works even while it's running.

19:06.120 --> 19:12.120
So I think it's a different kind of extensibility, really.

19:12.120 --> 19:15.840
And Emacs can participate on D-Bus,

19:15.840 --> 19:21.080
so Emacs has a superset of what D-Bus can do, really.

19:25.200 --> 19:27.120
Do you have any other cool D-Bus ideas?

19:27.120 --> 19:29.480
I think I have dropped them all.

19:29.480 --> 19:32.600
Definitely remote org capture is a thing

19:32.600 --> 19:34.840
that I have wanted a couple of times

19:34.840 --> 19:38.160
because if I'm browsing around somewhere,

19:38.160 --> 19:40.520
I'd really love to have a simple flow that

19:40.520 --> 19:44.720
allows me to turn a web page into an org capture.

19:44.720 --> 19:47.640
And I think D-Bus could be a good way of accomplishing that,

19:47.640 --> 19:49.920
although I haven't messed with the browser integration

19:49.920 --> 19:50.400
end of it.

19:54.640 --> 19:57.920
Are there buses besides system and session?

19:57.920 --> 19:59.920
Is there anything more to a bus besides a way

19:59.920 --> 20:03.920
to group objects?

20:03.920 --> 20:09.920
There are always at least a system bus and a session bus.

20:09.920 --> 20:12.760
And actually, that's maybe not completely true.

20:12.760 --> 20:15.640
There's always at least a system bus, session bus

20:15.640 --> 20:19.800
as long as there is at least one logged in session.

20:19.800 --> 20:22.720
And there's really more than one session bus.

20:22.720 --> 20:26.800
There's one bus per session so that you're not leaking stuff

20:26.800 --> 20:28.880
across sessions on the same computer

20:28.880 --> 20:32.960
because despite this being 2022, Unix

20:32.960 --> 20:34.840
is still a multi-user operating system

20:34.840 --> 20:38.280
and you have to think about that stuff.

20:38.280 --> 20:43.640
There are an unlimited number of D-Bus buses.

20:43.640 --> 20:47.040
You can create ones that have limited sets of services.

20:47.040 --> 20:51.760
You can connect to ones over a TCP socket.

20:51.760 --> 20:55.320
There are always generally at least system and session.

20:55.320 --> 20:58.360
There can additionally be other ones.

20:58.360 --> 21:02.800
But it is uncommon to have any other bus.

21:02.800 --> 21:06.080
Generally, well-behaved D-Bus services

21:06.080 --> 21:10.000
will attach to one or the other of those two buses.

21:10.000 --> 21:13.760
And in fact, PulseAudio is, it has D-Bus support

21:13.760 --> 21:16.440
but it is not a good D-Bus citizen

21:16.440 --> 21:18.960
because it does not use the session bus.

21:18.960 --> 21:22.000
It has, it's very weird actually.

21:22.000 --> 21:25.240
It has a D-Bus plug-in that hooks into the session bus

21:25.240 --> 21:28.640
but all it has is a method that returns the path to the Unix

21:28.640 --> 21:31.560
socket of the real D-Bus which you then

21:31.560 --> 21:34.640
have to connect to separately which strikes me

21:34.640 --> 21:37.840
as not the best way of doing that.

21:41.800 --> 21:43.680
Cool.

21:43.680 --> 21:46.840
All right, I think that is all of the questions.

21:50.000 --> 21:52.520
Cool, I think we still have about like six and a half

21:52.520 --> 21:55.160
or seven more minutes of Q&A on the stream.

21:55.160 --> 21:57.920
So if there are any more questions, folks,

21:57.920 --> 21:59.480
please feel free to post them on the pad

21:59.480 --> 22:03.120
or come up here, join us on BBB.

22:03.120 --> 22:06.240
Yeah, we can hang out here for a little bit longer.

22:06.240 --> 22:07.960
The stream will move on at some point

22:07.960 --> 22:10.960
but Ian, of course, and anyone else who is interested

22:10.960 --> 22:14.280
is welcome to hang out if Ian is around.

22:14.280 --> 22:15.560
Yeah.

22:15.560 --> 22:16.960
I will be around for a bit.

22:16.960 --> 22:20.280
I am on IRC all the time but I'm not always

22:20.280 --> 22:21.280
paying attention to it.

22:21.280 --> 22:23.080
You're welcome to reach out to me there.

22:26.680 --> 22:32.160
This is with almost all of my Emacs packages and stuff.

22:32.160 --> 22:36.400
This is in my Emacs Weirdware project on Codeburg.

22:36.400 --> 22:40.360
So codeburg.org slash Emacs dash weirdware

22:40.360 --> 22:45.200
has everything that I demoed and some other wonderful goodies

22:45.200 --> 22:49.040
that maybe you already know about and maybe you don't.

22:49.040 --> 22:52.280
I saw one other question from the chat, which

22:52.280 --> 22:56.720
is what do you use this for?

22:56.720 --> 23:01.760
Well, I mean, the main thing I use it for

23:01.760 --> 23:07.600
is discomfort for managing external devices.

23:07.600 --> 23:13.040
But this has been a really great research project

23:13.040 --> 23:20.000
just to understand D-Bus better, see what it can offer,

23:20.000 --> 23:26.240
and write some interesting code because what I really like

23:26.240 --> 23:31.480
is writing code that unlocks new possibilities

23:31.480 --> 23:33.680
to where people can look at it and say,

23:33.680 --> 23:35.200
oh, that gives me a great idea.

23:35.200 --> 23:36.680
I want to do this with it.

23:36.680 --> 23:41.560
And I see D-Base and this talk as really just pushing

23:41.560 --> 23:43.360
mindshare on this stuff.

23:43.360 --> 23:47.160
And really, the best result of this talk

23:47.160 --> 23:50.960
is for people to come out of it and say, wow, that was awesome.

23:50.960 --> 23:55.120
I can't wait to build something with it and go build new stuff.

23:55.120 --> 23:57.120
And just kind of building those platforms

23:57.120 --> 24:00.600
that other people can use and find helpful

24:00.600 --> 24:03.120
in whatever their programming journey is.

24:03.120 --> 24:05.040
That's the thing that I really like.

24:05.040 --> 24:06.040
That means a lot to me.

24:06.040 --> 24:09.000
So I hope that someone watches this

24:09.000 --> 24:32.360
and comes away with a good idea and goes and hacks on it.

24:32.360 --> 24:34.360
Looks like there's one more question.

24:34.360 --> 24:38.520
I'm not sure if we have time.

24:38.520 --> 24:44.160
I'll follow up in the pad if we end up over time on that.

24:44.160 --> 24:45.840
Yeah, we still have a couple more minutes,

24:45.840 --> 25:12.480
so it should be good.

25:12.480 --> 25:15.040
OK, so the last question is, it looks

25:15.040 --> 25:19.400
like D-Bus is mostly useful for Emacs to do IPC.

25:19.400 --> 25:20.880
If I understand correctly, this is

25:20.880 --> 25:24.440
how SIGTEX works when working with LaTeX docs.

25:24.440 --> 25:26.960
How does it compare with other ways of doing IPC,

25:26.960 --> 25:29.360
for example, communicating over a socket with MPD?

25:32.960 --> 25:36.000
So the main way that it's different

25:36.000 --> 25:40.320
is that MPD has its own protocol that you

25:40.320 --> 25:46.280
have to build support for in whatever your client is.

25:46.280 --> 25:49.800
D-Bus gives you a single, uniform way

25:49.800 --> 25:52.520
of talking to any service.

25:52.520 --> 25:55.720
So instead of having to reinvent that socket code

25:55.720 --> 25:59.080
and write the protocol support for MPD or whatever else,

25:59.080 --> 26:02.280
where you're taking the concrete, what

26:02.280 --> 26:04.280
are the bytes over the wire, and building

26:04.280 --> 26:07.840
an abstract programming interface that wraps that

26:07.840 --> 26:12.360
and drives those things, D-Bus already provides all of that.

26:12.360 --> 26:15.240
So you can say, here's a description of everything

26:15.240 --> 26:18.760
that I already do, and you can code gen stuff

26:18.760 --> 26:20.800
to do all of it.

26:20.800 --> 26:24.840
So I think that's the main difference between them.

26:24.840 --> 26:26.840
But it is over a socket.

26:26.840 --> 26:31.040
It's over a Unix socket for local stuff, TCP for remote.

26:31.040 --> 26:33.000
It is very similar.

26:33.000 --> 26:34.480
The main difference is that it is

26:34.480 --> 26:37.080
a framework for multiple applications

26:37.080 --> 26:39.960
rather than an application-specific mechanism,

26:39.960 --> 26:42.200
which makes it very easy to reuse

26:42.200 --> 26:43.880
in a variety of different contexts.

26:43.880 --> 26:46.520
And I think that's been key to its popularity

26:46.520 --> 26:49.240
over the last 10 years or so is the fact

26:49.240 --> 26:52.880
that it provides just enough opinion about how stuff should

26:52.880 --> 26:56.400
work that you don't have to think too hard about what

26:56.400 --> 26:57.600
should the protocol be.

26:57.600 --> 26:58.640
Should it be binary?

26:58.640 --> 26:59.560
Should it be text?

26:59.560 --> 27:01.520
Should it be S expressions?

27:01.520 --> 27:02.640
Should it be JSON?

27:02.640 --> 27:05.080
It's already done for you, and you can just think about,

27:05.080 --> 27:06.880
how do I connect it up?

27:06.880 --> 27:08.840
And I think that provides a lot of value.

27:12.280 --> 27:14.440
Yeah, and I can second that.

27:14.440 --> 27:16.520
It's been adopted by all sorts of different software

27:16.520 --> 27:19.040
projects, one of which I worked on.

27:19.040 --> 27:21.560
Jammy, people might know, GNU package

27:21.560 --> 27:23.760
for basically universal communication.

27:23.760 --> 27:27.280
It's basically a text messaging and also audio video calling

27:27.280 --> 27:28.680
and conferencing application.

27:28.680 --> 27:31.400
And it's Daemon, which runs in the background.

27:31.400 --> 27:34.800
It also supports D-Bus, so you can do all sorts of things,

27:34.800 --> 27:38.280
write little Python scripts or whatever,

27:38.280 --> 27:40.480
talk with it through D-Bus, give it commands

27:40.480 --> 27:43.560
to take calls from a particular point

27:43.560 --> 27:46.920
or just hang up calls or just do all sorts of things

27:46.920 --> 27:48.080
over D-Bus.

27:48.080 --> 27:51.640
And it is all, like you said, sort of application agnostic.

27:51.640 --> 27:53.920
It's not specific to, oh, how would I

27:53.920 --> 27:58.520
do this in a different way for each individual application?

27:58.520 --> 27:59.200
Yeah, exactly.

27:59.200 --> 28:02.080
It's the de facto way of doing that sort of stuff

28:02.080 --> 28:04.680
on Linux machines these days.

28:04.680 --> 28:09.920
And you can look back to some of the other message passing

28:09.920 --> 28:13.920
stuff in Windows and see it's drawn some inspiration

28:13.920 --> 28:18.480
from a variety of different places and different ways

28:18.480 --> 28:21.560
of doing that kind of interactivity.

28:21.560 --> 28:24.080
But it is, I mean, I don't think there was ever

28:24.080 --> 28:26.240
really a serious competitor to it,

28:26.240 --> 28:28.080
but it is the de facto standard if you

28:28.080 --> 28:31.960
want to do any kind of graphical program that

28:31.960 --> 28:36.960
manipulates your system or a batch program that

28:36.960 --> 28:41.120
drives an otherwise purely interactive graphical program.

28:41.120 --> 28:42.720
That's the tool.

28:42.720 --> 28:47.880
And there is not really any competitive landscape or reason

28:47.880 --> 28:50.720
to go reinventing it at this time.

28:50.720 --> 28:51.480
Sounds good.

28:51.480 --> 28:52.760
And I think that's all the time that we

28:52.760 --> 28:53.720
have on the live stream.

28:53.720 --> 28:55.840
Folks, you are welcome to stick around on IRC

28:55.840 --> 28:58.160
or come here on BBB and continue talking to Ian.

28:58.160 --> 28:59.560
Thank you, Ian.

28:59.560 --> 29:00.080
Wonderful.

29:00.080 --> 29:01.240
Thank you so much.

29:01.240 --> 29:02.240
Cheers.

29:11.560 --> 29:12.040
All right.

29:12.040 --> 29:13.880
I think the stream has moved on.

29:13.880 --> 29:15.960
Yeah, you're welcome to stay here, Ian, if you like,

29:15.960 --> 29:18.080
or just continue catching up with folks in IRC.

29:20.840 --> 29:21.320
Great.

29:21.320 --> 29:22.960
I will hang out here for a little bit

29:22.960 --> 29:28.360
in case someone wants to jump in and just write

29:28.360 --> 29:30.560
some stuff in the pad.

29:30.560 --> 29:31.360
Sounds good.

29:31.360 --> 29:31.880
Thank you.

29:31.880 --> 29:34.680
And I do see people are still writing or posting on the pad,

29:34.680 --> 29:35.600
so that's awesome.

29:35.600 --> 29:36.720
Yeah, sure thing.

29:36.720 --> 29:37.240
Awesome.

29:37.240 --> 29:38.120
Thank you so much.

29:38.120 --> 29:38.600
All right.

29:38.600 --> 29:38.960
Cheers.

29:38.960 --> 29:39.480
Welcome.

29:39.480 --> 29:41.480
And yeah, see you around on IRC.

29:41.480 --> 29:42.880
All right.

29:42.880 --> 30:11.440
All right.