 Okay, so I think we're gonna go ahead and start. This is the Debian installer skills exchange. Joey Hess is, I guess, moderating it. And if you have questions or suggestions or whatever, raise your hand, I'll try to run a microphone to you. All right, thank you. Yeah, I really only put this on the schedule because a couple of people came to me and said, we're starting to work on DI and we would need detailed help on various areas and if people here are interested in just getting started, we can start at the very beginning or we can dive into whatever particular details people want to learn about. So it's really up to y'all. I don't have any particular demos prepared or anything like that. I just wanted to, you know, simple school exchange. And I would also like to invite people in the back to move up front if you wanna participate because it's a small room that you can get up here under the front and we can all talk together easier. Serena? Ha ha ha, or not. Yeah. If no one else is gonna state any preferences, I'd be happy to hear something sort of more starting towards the beginning. I'm not even sure how I would begin working with DI. It doesn't seem to follow the same packaging workflow that I'm used to for modifying other Debian packages, but maybe I just am missing this step. It basically does because you have source packages that build new Debs, which are, you know, like Debs and they're all in Git and basically your workflow is the same. You don't have patches going on because they're all native packages. Most of them are all native, except for things like Busybox. So I mean, you can start, I think probably the place that most people would get started would be to take a checkout of DI, which is a bit of a complicated process because we have, you know, several hundred packages in Git and there is this one simple command line here which actually will pull down everything. Well, you might have to escape this guy here. Does that show up? No. Okay. I don't know if I can make that show up. Anyway, there's a command line which you now can't see and if you cut and paste that, it will start checking things out like it's doing here and you'll get a DI tree eventually. DI tree is fairly simple. You have your packages directory, which has the line share of packages that are in DI. You have this other directory installer, which is the, can you see this? Okay, which is the Debian installer source package, which actually builds the installation images and basically working on DI as a matter of finding the right UDEP and modifying it, you know. So I've been trying to build the installer recently and one thing you have to know is that when you try to build the installer, it has some funky detection mechanism to either take UDEPs from testing or unstable even if you build to unstable and it has been discussed last year by the release team in Otavio about how it should be done in an ideal world. Nowadays, if you build for unstable, you're taking UDEPs from testing, which can be quite confusing. But all in all, the building process is quite easy and hacking on this, even this installer part is just a matter of various make files and other things. I mean, I just changed the images for the syslinux boots splash screens and I mean, it's just a matter of finding the correct files, commenting into git, trying to build in some clean street and then you have images and then you can just boot them using Kimew or whatever and it just works. Yeah. Or not. Well, it just works. This isn't my normal development machine. It's just a random machine that I have available since my laptop's dead. But yeah, wow, that's a fun error. The only tricky thing about building DI yourself is you do have to put in the modified UDEPs that you want to use. If you haven't released them and you're in a development rebuild test cycle, you have to put them in the right place in here. It's all documented or we can show how to do it but you do have to learn a few tricks to get it going. Wookie. So I guess the thing I found when I tried hacking on this is if you just check out the DI stuff, it's just this kind of tree of metadata rather than any actual program and you kind of look at it going, what do I change where to actually change something? You know, I could copy another one but I have no clue what I'm doing. So a little bit of that might be helpful. If you, for example, you go into a random package, maybe that's not a good one, maybe you were thinking about something like, oh, I don't know. What? No, a random package that's not insane. So yeah, I mean, you might go into a package and see, oh, there's one whole file in the source package and then the important stuff tends to be tucked away in here. We have a templates file, you know, standard DEBConf templates. We have, you know, a post-inst, which is what gets run when the UDEB is selected in the main menu or when it's automatically selected at run time and all this does is calls another piece of DI. So that's helpful. Yeah, I mean, DI, probably 90% of the interesting stuff does live in the packages control metadata. Do we have an easy way to run some sort of DI-ish route? Besides just launching a QMU, going to console stuff? There's a way to do that, but you can't use it to do very much. If you go in here to where I failed to build a minute ago, you can run, I think it's demo underscore image names, so demo underscore net boot, and it'll start up the DI menu, but you probably don't want to run very much in it because you'll eventually nuke your drive or it'll just fail to work. So everybody tests it in QMU or in VirtualBox. It's like for me, that demo would be awesome if I can connect a loopback hard drives or like hard drives as a files to quickly automatically test stuff for part-man. Yeah, yeah, I can, trying to get to where you want to test is one of the annoying things about DI for sure. And I'll tell you personally, my dirty little secret is when I'm working on DI, I'll build something that I think might work, boot up the image, find out it doesn't work, and then I'll go in and edit the post-ins manually until it works. And there's the third console which has the debug log so you can pretty much see how it's failing. Get a post-ins that kind of works and then I'll pull it back out and massage that into something I can commit. I mean in theory it's possible to use SieveDepcon from your system and just run a random UDEP from it. But like with NetCon, it might just screw your system if you aren't careful. Yeah. And I think one thing that we could do better along those lines is to use the live installer stuff which actually can run DI in a CH route and actually do useful things because it's what's used on the live CDs. We could use that maybe better but nobody's really used it that way. Also something else that might be useful is you can run the VIN installer in LXC as well now. In what? In LXC. Oh, in a container? Yeah, in a container. Oh, okay. My flatmate does a lot of the VIN installer work and he does it all in LXC and it just works fine. That would be a good thing to document how to do. Yeah, apart from he said he doesn't do anything with disks such that it doesn't complete the installation. Yeah, well, it doesn't have to run all the way through. But if I wanna work on part and I do wanna partition the hard disk, so yeah, that's me. One option for you if you want to work on part man is to just have a pre-seed file that goes until part man starts. Another option, yeah. Speedy part. Yeah, another option that I sometimes use if I'm using virtual box, it has checkpointing features so you can checkpoint the virtual machine right when part man starts up and then you resume it, it runs through it, does its thing, it doesn't work. So you resume it again, edit part man a little bit and let it run through, et cetera. And then you have a fairly tight loop there. You can even say W get a file down so you can have a file that you're pulling in every time that's the one that you're editing. Something like that can be a little bit more sane. So a slightly different subject. I often find if I do actual testing on real machines like you get stuck a part way through and something doesn't work, you're stuck in the, this didn't work so you can't go on and do the rest of it. And you drop into, so you're in the shell and you haven't got all your normal stuff. You haven't got proper apt or proper d-package. You've got all the crazy things. And I've never found anywhere written down to tell me what I could actually do there. So you go, I'm sure I could get myself out of here if I knew what to type. And it seems to be quite hard to discover. And maybe it's well documented now because this was a while back. Yeah, this file, which you have to know where it is that it's in Debian Installer Utils Source Package and it's the readme file. And that's all the, that's a lot of the interesting little bits and pieces that you can use to do good things in DI such as install new UDebs or install Debs into the target system or, you know. So what was that called again? Where was it? That's a useful fact. It is in the Debian Installer Utils Source Package which you can just deb check out if you don't want the whole tree. Yeah. We also have some other documentation. Yeah. Unfortunately, this is all old and, you know, not really user level, but can be really helpful if you're developing the environment. You just have to kind of learn, you know, it is a different environment, clearly. Because I suspect people in the real world get stuck there quite often and we probably ought to make, I don't know if there's a wiki page saying, here's some stuff you can type which might get you out of a stuck install. Yeah. Because it's usually some little piece that, you know, if you could just tell it to ignore that and carry on or whatever. Somebody wanted to know about preceding, if nobody else has an immediate thing. Who was that? Somebody here? I'm trying to do it. Oh, okay. Okay. So. Maybe one thing that is not widely known is where you can just find the standard preceding file because it's quite hard to just find which exact string you have to write. Well, you've seen the manual, right? Microphone, please. One thing that would be useful is if you install a system manually and then somewhere on that is the preceded file that would recreate it? It is. It's on your laptop right now. Sweet. Where on my laptop? Yeah, I don't actually know if it's on this machine because this wasn't installed with Debian installer because it's in a colo. But yeah, you have a very long Debian installer and it has the debconf templates. You can actually use that to dump out a precede file that has everything that you did during the installation even. Okay, so something that needs post-processing. This is, well, a little bit, but not much. It's actually documented in the manual how to dump this out and use it as your precede file if you want to, although you tend to have to edit it to remove garbage. Cool, yeah. Sorry, whereabouts is it again? It should be in slash var slash log slash Debian installer over here. Var, log, installer, CDAP controller. Oh, installer, yeah. Questions dot DAT and templates dot DAT. Yeah, I wish you wanted to ditch that. Under there, here I'll put it over here. I wonder if somebody put it, Garrett, why don't you put it on the gobby? Put it on the gobby if you can. Joey. Yeah, hello. But one thing is, you know, you have to enter, at the beginning of the I, the user configuration that loads all the packages and installs the system. You think we could have an easy way to run Debian installer on an installed system so you can configure the user, keyboards and all these parameters. That's like an OEM configuration. Yeah, kind of. Right, and I think you have an answer next to you. Well, there's a second question. Well, let him answer. I'm not gonna answer. Okay, we just have to go to the camera. Well, in Ubuntu, there is package OAM config shipped which does that such that on first boot it allows you to configure the system. But it's part of Ubiquity, so you have to bring a lot of dependencies in. It's, no? It is Ubiquity. It's Ubiquity, it's quite, it's quite... The answer is yes. And then... Sorry, yes, OEM config is Ubiquity, so that's what he's talking about. And then there is the question, you know, we had to drop support for the slab because there was no enough RAM. Should we start thinking on adding UCLibC support or is it not worth it? Maybe you don't have an answer, but maybe the audience or how do you feel about that? I think it would make it a lot harder to build DI just because of all the fairly complicated libraries all the way up to GKK that we use. Trying to build all that against UCLibC seems difficult. I'm always trying to find ways to make DI smaller though. And we have, I think, looked at UCLibC or something like that before we just didn't get it to work. And of course we already do reduce libc down with makelibs, but it does, the kernel is really the biggest problem we have as far as size and we can't really do anything about it. It just keeps getting bigger. Every module is just 10 times what it was when we started DI. And it's sort of building our own size-optimized kernel. I don't know what to do about that. I suspect that the kernel is gonna get larger, the kernel will get larger as well as the signed modules they're starting to add. And that adds a big chunk for each module. About the OEM, I've been discussing this in private with other Dev-in developers. The idea we had is what about creating a Dev-in sort of image that you just put on the first partition with a preceding file that leaves out most of the questions and that would even eventually protect itself by, I don't know, preceding part-man to avoid the user dropping this partition and that could then stay as the rescue partition or something, what amount of work would that mean? My feeling is that almost everything we need is there. Just put it smartly. I mean, you could start with Dev-in and start a launcher. Again, it seems like the right thing to do because it can go directly from X into DI already and run things and jump back into X even if you want. I think there's a lot of stuff in Dev-in Live that we could use that way. I think they even already do a few OEM-type configurations on boot in Dev-in Live, but I don't really know the details. I've just been using it this week, so I'm kind of getting a feel of it. Although I know there were some people who had specific detail, but I think you had some detailed thing and I'd be happy to go into it if nobody else has any. I think one thing we had been struggling in the last weeks is how do others have good tips how to debug DIC code? Hmm. Not my area, except for Anna and Main Menu, which I could help you with, but not live DI. But yeah, nobody has already put GDB into a DI image or whatever, run something on their wall grind or... I think people have actually colonized on it. Yeah. I don't know if there's a GDB UDub. I think you can actually just put it in... There's a way to pull in individual binaries as long as you have all the libraries available. So... Eh, that's rather a lot. Python. Okay. Well. Python extension to GDB is optional, so check GDB minimal. Ah. Yeah. Um... Well, you can do it from the live session because then you can install anything you like and then wrap around that somehow. Yeah, you could do that. Definitely. But that's not running the Debian install and the way you're gonna end up running it. So if you can't reproduce it in live session, then you are stuck. This is actually a... It might be an amusing thing to... It's a live image, I don't care. I don't know what it did there. It's obviously booting up DI. There we go. Yeah. I think this could be a usable development environment because you have this console and you have a full Debian in it. So... Oh, you can't see this console, but I'm at call BT number one. And I've got a full Debian system. I have DI right here so you could GDB very easily that way. Yeah, it seems reasonable. Probably for our specific case, this does not run the Net Config at all. Because network is already available. Oh, yeah, definitely. Yeah. Got to let this before out. Oh, that's easy. Maybe a question is what are the low-hanging fruits that are pending in Debian and the installer that could be tackled by someone in the audience? I mean, it's somehow hard also to see what work is really needed. I mean, well, now we're in free so the question is somehow unrelated. But I mean, there are probably things that could be sold in Debian and the installer that just aren't because no one is doing their work but that aren't necessarily hard. Yeah, and unfortunately, I'm a little out of touch. So somebody also have to... Did the Flash support that was going into Partman ever get in and therefore give us the ability to install to Flash which is something we've been missing forever? You're talking about, yeah. I don't think it did. I think Martin Mikkelmeyer was working on it. Maybe. It was originally BlindVT, I've forgotten his name. A Swedish guy. My GSOc student ages ago and he did some work but it didn't quite get into Partman and then I think it just kind of fell on the floor really and we asked three years later and still doesn't work. Yeah, yeah, that would be a good... Definitely. Yeah, that excludes a whole class of devices. I mean, actually it's less true than it was because people tend to have SD cards now so we care less. But embedded devices still really can use it. I was kind of wondering where would you get started for like porting a new kernel or a new piece of hardware? Like getting, what are the baby steps for getting a new port for DI? Okay, is it an ARM port? Yeah. Okay, just random guess. Of course. There's a, okay, LibDI has like a table of ARM boards like sub-architecture names and you have to get into there and at that point UD package dash dash sub-architecture or something can tell the rest of DI what your board is and from that point it's mostly just a matter of hacking whatever bits of DI need to be specific to that board and then making actual boot images which of course is always fun for ARM. But it's generally, you know, you go into the Divina installer build system and find one that's sort of close and copy it and hack on it type thing. That's the general, I mean, it's all like you're copying the image, you're copying the build system. Hello. We just added a new ARM platform which is the dream block device. And you just have to hack this Divina installer file and then within installer configs ARM just add what flavor you want to build and it's just, that's it, you just build the image and try to boot it. But of course you need to use the Debian, you have to use the Debian kernel because you pull from the network, all the packages and then you have to install the Debian kernel. So first you have to work with mainline and get your platform supported in mainline. Once you got all these bits, then you can get it. Thank you. When I was doing stuff with new kernels, there's not a variable in build complex for a unit and so you can start listing all the new UDebs. Absolutely, yeah. You can put any UDebs that you like. There's a local UDebs directory. But I mean, fascinating included. Right, there's also a package list slash local file that you can add UDeb names into and then they go into your image. Yeah. So was the outcome of that that there is an easy method to stick in a kernel of your choice? Because often it isn't upstreamed yet but you'd quite like to get, at least get DI working with this magic kernel you've got and then you could worry about the upstream part later. I wouldn't say easy. I mean, if it doesn't have any modules and it's just a monolithic kernel that happens to work with your hardware, then it's pretty easy because you just build a DI and you maybe leave out the kernel modules to save some space and you boot it with the kernel and it works. So we can't just kind of have arbitrary packages. So if we've made a package with some, or a set of arbitrary files, we can have a pile of lib modules blur and we can just dump that part in. Yeah, you just, well, you have to make a UDeb out of it but that's easy, you know. Like make a Debian package with your arbitrary files. Okay, so we can do that and that's written down somewhere, it's not, right? Yeah. Yeah. I think if you want to use a completely different kernel because you need some patches to actually boot or everything, you need to first package this as a Debian package and then to split out the UDebs and potentially modify the lists kernel batch uses. Yeah, I've not done this since kernel batch somehow got merged into the kernel package. So I don't know the details. And there's this final list where you can say for this architect to use this on this kernel, you have eventually to modify that in the build system so the right packages get included into. So it's kind of complicated. I mean, it could probably be easier and I think that's what something would also be acceptable to have like developer kernel option in the build system that you could use in that case. One other thing we, that could be added to the build system that is normally not very interesting is having firmware built in because we tend to test net boot images because it's the easiest way to build. But usually if you don't net boot over wireless where you need firmware or if you need firmware you probably can't net boot that card. So it's mostly not needed in normal circumstances. I usually just hack the build system to do that but then I forget to have a proper patch to do it cleanly. There is an easy way to pull in firmware just by listing it in a file but I forget where that is. There's like an environment variable. It's easy to add the firmware to the init rd but you have to add it before building the mini iso if you then want to use the mini iso. Yeah, but you can just make it be pulled into the init rd directly from libfirmware at build time. That's already in the build system? Yeah, there's an environment variable which unfortunately I'm forgetting the name of but it's basically list of files to just pull off your disk and shove into the dir init rd in the same place. So if you say libfirmware foo, there it is. Didn't know about that. Yeah, I unfortunately forget where it is but it is documented somewhere. Well, I'm sat here with this. A kind of slightly off to an angle is whether we should look at, I mean effectively, DI is a way to make a little mini debian for a specific purpose and I wonder whether for the embedded debian stuff we should be considering what, how is it craziness to try and use this mechanism for slightly other purposes? To what degree have we added all this machinery around it so it only makes installed images not really suitable for making anything else? I don't really know whether this is a sensible route to ponder or look at or not really. So it seems to me like we have a bunch of other architectures for making other stuff. We have debian live, there's the deburf setup which is for making full debian systems that run in the initial word MFS that you can customize, it's got its clonkiness but you can get anything from a rescue CD in the initial MFS. The init ramp stuff is that pretty much a list of binaries to copy out, is that how it works? The init ramp MFS is actually a, it's a GZIP CPIO archive, that's all it is. And you can modify any init ramp MFS in the same way that you would modify another GZIP CPIO archive. Just on GZIP it, feed it through CPIO as a super user or under fake route, modify the files, stop it back through CPIO, GZIP it again and it'll work. But aren't there a lot of hooks so that it knows packages that need to know and put files in the init ramps do the right thing? For init ramp MFS tools there are a set of hooks but in terms of what is in an init ramp MFS what are we working with? It's a very standard form. And it doesn't need to be tiny, it's only needs to be as tiny as your memory is. Apart from ARM where there are limits on how big your init ramp MFS is and it's something like three bank and then you're stuck. If you're pulling your init ramp MFS off of the onboard storage. You know what I'm just saying, there's other ways of getting an init ramp MFS onto a machine. So in fact grub net boot is now functional for relatively large size init remotes. Yeah, I sometimes wonder how long does it make sense to have a separate DI from Debian Live that has a completely different system that you have to learn all the quirks of and everything. But unfortunately it does still soon to make sense because we have all the ARM systems, we have all the weird things like that that DI can support that you can't really support just running pieces of DI inside Debian Live type thing. We have a colon I've even talked about trying to use DI as the init ramp MFS for Debian. Because then you could say pull down SSH or something and have an SSH server in your init ramp MFS when you boot up a fit the can't mount the refile system, never quite got there to try to make it work. So given that we are slowly approaching to the end of the session, there's a question I see by Keebee who will be the next DI release manager. Who will be? Okay, yeah. If there are people interested in I guess forming a team or doing work, et cetera. Right, I think we need to find a way to get the DI team re-energize more than we are now but it's obviously difficult because we're a mature project. What do you think? Well, one thing to maybe add is that it was certainly mega difficult in the past to hack on this because most of the bits were not done and from nowadays doing incremental patches to solve and to just scratch your itch is reasonably easy. I think if you know how to package, I mean UDEPs are just different type of packages so I mean, yeah. And then understanding the installer build process is not necessary as long as you just run the build and it just works. So I mean, yeah, don't be afraid. Yeah, I'm interested but maybe after that come to 13. So do we need a DI release manager? Is it, I mean the release team? I mean why is DI special? I guess is what I'm gonna say. Right, the things that the DI release manager does comes down to coordinating not only the DI team as far as getting a coherent release out which is basically what their release team does for Debian but also chasing down everything in Debian that breaks, then breaks DI coordinating all of those things, it's a lot of work still. So basically that given that Kiwi took it over so Cyril took it over from Otavio more or less because Otavio was too busy, you can sort of considered that release team picked it up. I mean, he even said it on IFC now so that's not the ideal situation. You would want to have somebody really know the internals of DI and working on it specifically and on its goal specifically than just the overall picture release team view. So I think now might be a good time to actually get into, I forget your name, your difficult question so we can scare the rest of the room a little bit if you wanna. So part man LVM does not currently live if you use guided partitioning or manual as far as I understand. It cannot leave free disk space in the physical, well in the volume group, such that you can't have any snapshots or resize or move your LVM partitions after you run the installer. And the other thing, well side question which is I think has less usage, if you use guided LVM it cannot leave any free disk space at all on the actual your hard disk such that you can't have something else left after it for dual booting or whatever and all. So the sort of maybe brain dead workaround for that is to include in your precede a demand for a large volume named delete me. And then when you're done you just delete the. And that's what Edu Debian is doing right now. And there is a back report saying we would like to drop this. Please do something. So you wanna work on this side, take it. Well yeah, or at least poke around the part man to show what needs to be changing. Cause as far as I understand it's the part man who doesn't support the leave this space free even though I have created it somehow or whatever. Right. Whereabouts would that be? It'll be in part man auto. Unfortunately part man auto is not part of part man that I know very well. And I don't know that I know part man that well. Have a try. Yeah. I mean you have all these recipes, right? They're some complicated thing. You have to add, it's basically a little language. You have to find some way to add your feature in. Yeah. I mean, where is it? So this is the little weird, completely weird and unspecified language which needs to be replaced with something else really. That makes sense. Well it made sense 20 years ago. Basically the way this works as I understand it which isn't very well is that part man, you can think of it as an object oriented system but it's not really of course. So these are all, all the object properties are little files on disk in this directory and this is tweaking attributes of the objects to make part man behave the way it wants it to. I think that's the correct title view of how this works right now. And so it's going through, just setting up different objects for different file systems with various attributes like how they're formatted, if they're a swap partition. So you need a way to have some kind of reserved, I don't know, either a reserved object that's never actually created might be one way to do it or something. Or go in and actually modify the core logic that lays these out would be the other way, I guess. It's like what you want is the VG should take the whole space yet from your multi-scheme you don't want your root partition or the biggest one to take the biggest amount you want it to be something else. Yeah, yeah. And yeah, these numbers are how it figures out the space right now. So I think one way would just be to add like, something like that. Yeah. No idea, it's just something along those lines but this is the part of part man I'd say the least people understand well. Is that the part that also gives you the default sizes we get at the moment? Yes. Because they're looking a bit old too. We know how to tweak those and we do tweak them from time to time but as far as tweaking much more of this it gets a little hairy. Yeah. Yeah, I have exactly the same problem as this that you always want to make with a blank space that's kind of the whole point and it doesn't work. The other question about this magical variables which they're not very nice considering that we have really large disks right now because the way you could do it you have some magical factors involved because if you say 80% on a 10 terabyte disk you really want it to leave for example 200 gig remaining. If you have a tiny small disk and SD card of eight gig you really want to leave just 200 meg or whatever 20% is. Yeah, you really want some conditionals in this little micro language so you can. Yeah, well one ideal solution I saw is that you dynamically adjust what 80% means depending on how large your disk is using a formula and a magical factor. It's actually called magic factor such that you even it out as your disk grows to make it smaller such that it becomes non-linear but that's what you want. In cases where you have fairly small and very large systems. That's a mathematical idealistic answer but whether practically it's implementable. You have to be able to do it in expert, in bash, in busy box shell. Of course, of course, of course. I thought you would argue to write in Haskell and ship to binary. I'm not gonna go there. Maybe another thing to add is as UDEPs are exactly like Debin packages for most of the aspects, one can perfectly upload them to experimental during the freeze if there are new things that I don't know that you went to would like to test in Debin first. I mean, we have this experimental that still works that still builds on all our architectures and then you can even even give a small trickery build Debin insular images from UDEPs from experimental. Although I don't think that's implemented yet. It should work. Yeah, absolutely. And it's, I mean, being able to take UDEPs partly from experimental is also in the ground picture of what would be ideal for Debin insular. So if you implement that, it would be welcome. I guess. I think you can actually do it just by going in here to sources.list.udev and putting an experimental line in and then it should, I don't know about pinning and how that's gonna work but you might better pin it. Yeah. Yeah. Probably have to adjust the pinning so it works. Yeah. And there was this question about what kind of areas that need work or where the cool new features could be added. One problem I see that is, I don't know a good solution is that many missing features I know of currently are things that need quite a complicated setup so you can test them. Like if we want to have enterprise WPA supported in the installer, you need a test environment that actually has radius and everything to test it or a little bit less complicated thing. If you want VLANs configured in network, you need at least a VLAN capable switch or some OPPWT device that can do VLAN tagging or IPv6 is similar. Yeah, disk things may be similar. I think I recently saw a new report of this group install installs to the actual installation USB stick instead of the real hard disk. That's something that apparently still happens but nobody knows why or because it just happens on that certain device. That's really hard to develop. But again, don't forget that the tab installer, despite the fact that you see it only once in the life of one computer supposedly, is still a piece of software that is very much tab in specific and has, well it's an area in which you can have a huge impact in terms of translations, in terms of whatever else, tiny functionality that just allows you to install tab in from a campaign or whatever. Sir, you were talking about mysterious failures on somebody's machine. Presumably we have some kind of logging we get from it. Is it looking by default? It's just that bar log, whatever it is. Right, it depends on whether the user sends an installation report. We don't do automatic reporting back type logging. So they have to actually do that and then they have to actually select the logs because unfortunately the BTS kind of dislikes and numerous logs. So it's a problem. So is there a report bug DIY feature that helps with that, right? Yeah, there's a report bug installation report that does everything, yeah. And I think we're pretty much out of time. This was pretty productive. I hope that it's gotten a few people interested in working on DIY. It'd be great if you did. So thank you for coming. Thank you.