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.