 Today, I wanted to talk to you guys a little bit about the XDG base directory specification. And for those of you that are not familiar with what that is, the XDG base directory specification is essentially a set of guidelines that tell people that are writing programs exactly where they should place certain files on the Linux file system. For example, where should a config file go? Well according to XDG, a config file should go in the user's home slash dot config directory. Where should cache files go? It should go in your home directory slash dot cache. Where should user specific data go? It should go in the home directory slash dot local slash share. Those are the three big directories that most people associate with the XDG base specification. Now is the XDG base specifications, are they hard and fast rules that you must follow if you're a software developer? No, of course not. This is free and open source software. You don't have to obey any rules, you're free to do whatever the hell you want. And this is one of the things I love about Linux and it's really why, unlike a lot of people that you see discussing Linux on YouTube, I never get hung up on things like whether something is POSIX compliant or not, or whether it's compliant with the Linux standards base or the free desktop specifications, the XDG base specifications. I don't care, right, because at the end of the day, everyone has the freedom to do whatever the hell they want. These guidelines that people set out, hey, we think everybody should do this. That's great. People can put out there what they think everybody should do, but guess what? Everybody's not going to do that. In some ways I find it odd that so many Linux users, because we're non-conformist, right? It's all against the crowd. You wouldn't be on Linux if you were just one of these people that went along with everything, right? You're a rebel, right? So you're using Linux and you're this non-conformist, you go your own way. But when you get here, all of a sudden, you start telling everybody that everything has to be POSIX compliant and XDG compliant and things like that, and it's, I find that odd. If you're one of these Linux users that's spout that, I really think you should re-evaluate exactly what you think Linux and free and open source software actually is. And the reason I'm making this video today is because I actually had a merge request over on my .files repository, over on my GitLab, and I knew when I saw this merge request it was going to potentially cost me hours of work if I accepted this merge request because it was going to move around some of my existing .files to more XDG compliant places. And because I build so much stuff off of my .files such as the packages and the DTOS core repository and the DTOS installation script also expects certain things to be in certain directories, I knew if I had accepted this merge request it was going to cost me a lot of work. In the end I ended up doing it though because the person that made the merge request, I know he put a lot of work in moving a lot of stuff around making the merge request. So let me actually show you the merge request, let me go to my desktop here. So this is my .files repo on my GitLab. And you can see this merge request here, XDG compliant Xmonad. So he didn't like the fact that my Xmonad files and all my Xmonad scripts and color schemes and all of that were all in the home directory slash .xmonad. Xmonad is a very old window manager and because it kind of predates the XDG base directory specifications, many programs on Linux are older than the XDG base specifications. That's why so many of them just don't adhere to it. Things like Emacs for example, which has existed way before XDG was a thing, same thing with Mozilla Firefox, you know, and that's why you have that .mozilla folders because Firefox predates the XDG base specification. And I've had many people complain to me over the years that they didn't like that Xmonad had that .xmonad folder in their home directory because they claim it's polluting their home directory, right? It's cluttering up my home directory. They should actually put that in .config and oh, that's weird, like I don't understand why that's a big deal, especially if it's going to involve a ton of work to move things around. But this person, you know, he made a pretty significant merger request. You can see 29 changes here. Some of it was just renaming some files, moving some files around. But then he had to actually get into the code of some of the files and actually change some of the file paths, obviously, all the file paths for everything are changing. He also had to get into all of my shell configs, the bashrc, the zshrc, and my config.fish, because now he had to specify exactly where these Xmonad config directories are going to be located because now you have to export these environment variables for where Xmonad config dir is and data dir and cache dir. So I do love it when people, you know, want to contribute to some of my get lab stuff and they do these merge requests. This guy obviously put in some work, but I had to consider this and I spent about 10 or 15 minutes thinking about this before I went ahead and accepted the merge because I knew that if I accepted this merge request, not only, you know, all the work that he put in, but I would have to do a ton of additional work because he's just looking at my dot files. But again, all of the DTOS stuff depends on a lot of my Xmonad configs and, you know, pulling from various repositories, including the dot files repository. I also have to consider people that use my dot files and my config files, you know, is this going to cause anybody else problems if I start moving things around, you know, I got to take a lot of stuff into consideration before I just accept such a massive change that at the end of the day really doesn't do anything. All it does is move files to a different location. So is it worth it to put all that work in just to move files to a different place? In my personal opinion, no, it's not worth it. I would have never done this myself. The only reason I accepted this, again, is because I recognize this guy put in a lot of work and he really thought he was doing something important, something that was actually helping me out by moving all of this stuff around because he probably genuinely believes that the XDG-based specifications are like hard, fast rules that must be followed. And I was actually like breaking some commandment by having my Xmonad config in the home directory, right? No, no, no DT. It's got to be in the dot config file. Let me help you with that. And I appreciate that because obviously he was genuinely trying to help me out. That's why I accepted the merge request and it ended up costing me several hours of work yesterday because I had to redo a lot of DTOS stuff, rebuild a whole lot of packages, make sure all the file paths for everything have changed. I had to do a test run of the DTOS installation to make sure Xmonad actually works with the new configs and the new file paths and everything. And as of right now, everything works with DTOS, so no issues there. Now just because I say I don't care about the XDG-based specifications, again, I know I'm going to get a ton of people in the comments, probably I'm going to get flooded in the comments with people that actually think it matters. If you're one of those people that think it actually matters, you know, one of the great resources on the ArchWiki is this page, the XDG-based directory page. Because I know a lot of people out there, they do want to clean up their home directory, they want to try to stuff as much stuff into .config as they can to get it out of their user's home. And this excellent ArchWiki page, it has three very large tables of supported applications, so these are programs that actually allow you to move from the legacy config file, which is typically in the home directory, over to .config. So you've got the supported table here, and then after this you have partial, so these are applications that partially support the XDG specification. And then at the bottom, you also have a table of hard-coded, so these are applications that you really can't do anything with. So these are programs that are written in such a way they expect this config file to be in this exact location it should never change, so you're just stuck with these programs. So this is an excellent resource, I definitely think if you're trying to clean up your home directory, check out this page on the ArchWiki, and the other thing you should probably do is check out this program here, I've got the GitHub page for XDGNinja. And what XDGNinja is, it's a command line program, it's actually written in Haskell. And all you do is you run XDGNinja at the command line, and it tells you everything in your home directory as far as config files that could be moved, and it'll tell you exactly how to do that. And if you want to see an example of XDGNinja in action, let me zoom in here. Let's do XDGNinja, now I'm going to have a ton of stuff because again, I don't care about the XDG base specifications, so I'm not going out of my way to move a ton of stuff. And as you can see, it was a very lengthy list, I'm here at the end with some stuff about ZSH, ZSH, I could move to .config slash ZSH, I'd have to export some environment variables to accomplish that. And let me scroll up to see some other stuff, a lot of the Xorg stuff, you know, like in your home directory, you have things like .xresources and .xauthority. Honestly, I wouldn't touch any of the standard Xorg stuff, Xorg well predates the XDG standards, and there's so much stuff that's kind of hard-coded to expect those files to be there. Yeah, a lot of, you're asking for trouble moving a lot of this stuff around, I just wouldn't do it. But that's just me, I'm in a little bit of a unique position because so many people use my files, my .files, and you know, I don't want to do things that are really off the wall and non-standard, like, I would never have my VMRC, not be home slash .vmrc, right, it wouldn't make any sense, matter of fact, VM is so old, I don't even know if VM even allows for XDG-based specification. I know Emacs allows you to move from using home slash .emacs over to .config slash Emacs, I've never personally done it because just for legacy reasons, kind of everybody expects you to use the .emacs folder in your home directory, so that's just what I do. But again, I know people are going to disagree with my thoughts on all of this stuff, just like many people disagree with my thoughts on POSIX compliance, you guys know I love the fish shill, I don't care about POSIX, right, and then people trash me all the time, oh you're doing it wrong, DT, hey, let me know in the comments down below. Now before I go, I need to thank a few special people, I need to thank the producers of this episode. I'm talking about Dustin Gabe, James Matt, Max and Michael Mitchell, Paul Westwine, Jibald, Homie Allen, Armoredrager, Chuck, Commander, Henry, Diokai, Dylan, Greg, Marstrum, Erion, Alexander, Paul, Peace, Archonford, Dwarf, Politech, Riala, Teeth, for Lesser, Red Prophet, Steven, Tools, Devler, and Willie, these guys, they're my highest tiered patrons, over on Patreon, without these guys, this episode would not have been possible. The show's also brought to you by each and every one of these fine ladies and gentlemen. All these names you're seeing on the screen right now, these are all my supporters, over on Patreon because I don't have any corporate sponsors, I'm sponsored by you guys, the community, if you like my work, I want to see more videos about Linux and free and open source software. Subscribe to Distro Tube over on Patreon, peace. So all your home directory has in it is .config.local and temp. What do you want, a gold star?