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.
