• 6xpipe_@lemmy.world
    link
    fedilink
    arrow-up
    137
    arrow-down
    4
    ·
    edit-2
    1 year ago

    XDG gang, rise up!

    Also, I know that this community and dot-files in general are Unix based, but this holds true for Windows development as well. You should be putting app files in the users’ %APPDATA% directory, not their user folder. It’s probably even more important since Windows doesn’t autohide dot files.

  • gnutrino@programming.dev
    link
    fedilink
    arrow-up
    107
    arrow-down
    2
    ·
    1 year ago

    I just write my config files directly to random unused blocks on /dev/sda, filesystems are overrated.

  • AKADAP@lemmy.ml
    link
    fedilink
    arrow-up
    89
    arrow-down
    2
    ·
    1 year ago

    I absolutely despise the following directories: Documents, Music, Pictures, Public, Templates, Videos. Why? Because applications randomly dump stuff into these directories and fill them with junk files. I don’t want any application putting anything into directories I actually use, unless I explicitly tell them to. It is not possible to keep your files organized if applications randomly dump trash files into them.

    • herr@lemmy.world
      link
      fedilink
      arrow-up
      52
      arrow-down
      1
      ·
      1 year ago

      Same shit happens on Windows. Games will just install their shit literally all over OS with no rhyme or reason to it.

      Why can’t the save game and config.ini just be in the main god damn game directory? Nobody knows.

      • lloram239@feddit.de
        link
        fedilink
        arrow-up
        23
        arrow-down
        1
        ·
        1 year ago

        Why can’t the save game and config.ini just be in the main god damn game directory?

        You’d lose all save games every time you uninstall the game. We already had that in DOS/Win9x days and I am very happy that we moved away from this. Static program data and generated data should be clearly separated.

        In Linux we have the XDG Base Directory spec for that, that gives you directories for cache, config, state and data, so everything is nicely separated. The only problem is that not every app follows it, bug reports can help.

        I find Android handles this by far the worst. They have the core right idea with permissions that makes it impossible for games to write outside of their assigned directories, but the way they handle it your savegames go into an area that will be deleted when you uninstall the app. So the risk of losing savegames is extremely high. The alternative is that games require SD card permissions and than just write wherever they want. It’s basically all just a dark pattern to force games into using the Google Play service for cloud saves. Games that lose state and restart when you switch apps are also great.

        • Gyoza Power@discuss.tchncs.de
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          I mean, in Windows they literally have a “saved games” folder and almost no games use it. I too hate that most fucking games have to save their shit to the Documents directory. That’s the directory FOR MY FUCKING DOCUMENTS, NOT GAME SAVEDATA

      • AdmiralShat@programming.dev
        link
        fedilink
        English
        arrow-up
        19
        ·
        1 year ago

        Microsoft OWNS not just gaming companies, but one of the largest gaming hardware companies and many of the largest game developers.

        You’d think by now we’d get a dedicated Saves folder to organize this shit after this long.

      • jasondj@ttrpg.network
        link
        fedilink
        arrow-up
        18
        ·
        1 year ago

        Actual reason is system permissions.

        Most the default installation path is Program Files. That needs elevation to write to. Fine when you’re installing something, but not something you want to need just to run the game.

        Writing to %APPDATA% or really anywhere in %USERHOME% is guaranteed to have the right permissions for this user.

        Granted, a lot of home PCs and gaming PCs are single-user environments. The “personal” computer. In that case there’s no reason games and applications can’t be installed in %LOCALAPPADATA%, and in fact, I think windows has an environment variable or registry setting for that.

        It’s no different in Linux. You don’t want users writing to /etc. And you may expect multiple users. So all of that stuff goes to dot files in $HOME.

        • Trainguyrom@reddthat.com
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          Granted, a lot of home PCs and gaming PCs are single-user environments. The “personal” computer. In that case there’s no reason games and applications can’t be installed in %LOCALAPPADATA%, and in fact, I think windows has an environment variable or registry setting for that.

          I tried setting up my main windows gaming machine with a separate admin and user accounts, and tried to set it up to be multi-user. It didn’t work well. Most games worked but some random games had all sorts of bizarre issues, from only being able to run as admin, to requiring messing with directory permissions to just plain strange behavior but working sometimes. Steam also really didn’t like if I tried to run games as a different user and got very confused at times by the multiple user accounts

          • jasondj@ttrpg.network
            link
            fedilink
            arrow-up
            2
            ·
            1 year ago

            See, that’s dumb. Just because games aren’t enterprise software, there’s no reason basic security practice like least-privilege shouldn’t apply in development.

      • PixxlMan@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        I have my own directories on windows. I never use system provided directories for my own stuff, it always sucks. And if I want to move directories between drives or just change permissions, all hell breaks loose because everything depends on the default locations… So I just leave them be if I can.

      • nayminlwin@lemmy.ml
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        They’re probably trying to handle per user config. But nowadays, there’s mostly only one user using a machine.

      • Chewy@discuss.tchncs.de
        link
        fedilink
        arrow-up
        15
        ·
        1 year ago

        The apps dumping files into foldes like Documents usually don’t care about the XDG_user_directories spec, iirc.

    • akash_rawal@lemmy.world
      link
      fedilink
      arrow-up
      5
      arrow-down
      1
      ·
      1 year ago

      I just keep my stuff far away from $HOME and not bother about the junk. Not even a subdirectory under $HOME.

      Same goes for ’ My documents’ on windows.

    • BeeMe@beehaw.org
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      This is why I’ve made a “Filing Cabinet” directory. My stuff goes in there nice and organized, while I ignore the rest.

    • Tiger Jerusalem@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      These places are a cesspool of junk in every system, it’s incredible. MacOS has this kind of shit too, just like Windows, with apps dumping crap there without a care.

  • nyan@lemmy.cafe
    link
    fedilink
    English
    arrow-up
    73
    ·
    1 year ago

    Y’know what’s worse? When there’s no dot. Worse than that, it’s an undotted directory used to store a single config file. Ugh, unpleasant memories. 😒

      • unalivejoy@lemm.ee
        link
        fedilink
        English
        arrow-up
        21
        arrow-down
        1
        ·
        1 year ago

        That’s not the only folder go creates. There’s also ~/sdks/go1.xy

        • pivot_root@lemmy.world
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          Oh god, what? Is that new? Aside from the plethora of shit that are dotfiles living in ~ instead of under ~/.config, the only outlier I have at the moment is ~/go.

      • andrew@lemmy.stuart.fun
        link
        fedilink
        English
        arrow-up
        8
        arrow-down
        1
        ·
        1 year ago

        That’s just the default location for what it’s worth. You can move GOPATH wherever you want.

    • Chobbes@lemmy.world
      link
      fedilink
      arrow-up
      6
      ·
      1 year ago

      There’s a version control system called darcs that stores its configuration files in a _darcs/ directory in your project and it wounds my soul.

  • ouch@lemmy.world
    link
    fedilink
    arrow-up
    74
    arrow-down
    3
    ·
    1 year ago

    If you care, please take time to upvote or file bugs on packages that don’t follow XDG. Or even better, make PRs.

    • Kogasa@programming.dev
      link
      fedilink
      arrow-up
      22
      arrow-down
      15
      ·
      1 year ago

      Those bugs and PRs would just get closed without comment. Nobody is going to move a dotfile as a breaking change in any established software. You either get it right the first time or probably never.

      • nous@programming.dev
        link
        fedilink
        English
        arrow-up
        30
        arrow-down
        1
        ·
        1 year ago

        The software can read from both locations in a backwards compatible way. Many tools already do this.

        • CosmicTurtle@lemmy.world
          link
          fedilink
          English
          arrow-up
          7
          arrow-down
          4
          ·
          1 year ago

          The best way to handle this is to have the next version move the old directory (if it exists) and then start reading from there.

          That way it’s in compliance from then forward.

          A UI notice is nice but will probably be ignored.

          • donnachaidh@lemmy.dcmrobertson.com
            link
            fedilink
            arrow-up
            11
            ·
            1 year ago

            That could break some peoples’ dotfile management, e.g. symlinks or git repos. I’d say deprecation notice and reading from both, at least for a while, is better.

      • duncesplayed@lemmy.one
        link
        fedilink
        English
        arrow-up
        21
        arrow-down
        1
        ·
        edit-2
        1 year ago

        Nobody is going to move a dotfile as a breaking change in any established software

        We have oodles of counterexamples to this. GIMP did it, Blender did it, DOSBox did it, Libreoffice did it, Skype did it, Wireshark did it, ad nauseum. It’s not really as big a deal as you make it to be (or a big deal at all). You have a transitional period where you look for config files in both locations, and mark the old location as obsolete.

        • Kogasa@programming.dev
          link
          fedilink
          arrow-up
          9
          arrow-down
          2
          ·
          1 year ago

          It’s not really as big a deal as you make it to be (or a big deal at all).

          It’s a big deal to developers who were inconsiderate enough to do it in the first place. To do it in a non-breaking, non-confusing way requires slightly more care than doing it correctly to begin with. Hence why your $HOME is still a giant mess.

        • Neshura@bookwormstory.social
          link
          fedilink
          English
          arrow-up
          2
          ·
          1 year ago

          I mean if the code is well written it shouldn’t be hard in the first place. You likely have a sinlge code var for the config path already so instead of hardcoding it to be in $HOME make it check if the file is in XDG_Config, if not check if it’s in $HOME. If the file is in neither of these it does not exist -> create a new one in XDG_Config. If it does exist in $HOME -> Move it to XDG_Config.

      • gerdesj@lemmy.ml
        link
        fedilink
        English
        arrow-up
        8
        ·
        1 year ago

        They will if enough people whine about it.

        In the old days (I’m 50+) tumbleweed drifted through ~/ apart from my drivel and I’d have a folder for that so /home/gerdesj/docs was the root of my stuff. I also had ~/tmp/ for not important stuff. I don’t have too much imagination and ~/ was pretty clean. I was aware of dot files and there were a shit load of them but I didn’t see them unless I wanted to.

        This really isn’t the most important issue ever but it would be nice if apps dumped their shit in a consistently logical way. XDG is the standard.

      • Imnebuddy@lemmy.ml
        link
        fedilink
        English
        arrow-up
        7
        ·
        edit-2
        1 year ago

        I know developers are busy, and I don’t mean to berate them for their choices or work. I only have a two year Computer Information Systems degree and haven’t programmed a lot for a while, but supporting the XDG specification and remaining backwards compatible doesn’t seem to be very difficult or would cause so much breakage (of course, the amount of work would depend on the software and how the hardcoded path is implemented). I look up git repository issues for the software and tend to find ubiquitous examples like vim to be resistant to such change: https://github.com/vim/vim/issues/2034

        This is really frustrating and leads me to find alternative software, such as neovim/doom emacs instead of vim, nushell instead of bash, etc., just to be able to clear up my home directory. I don’t mind if I have to wait for XDG to be supported, but many important projects just label the issue as “won’t fix”. I totally understand where you are coming from.

        List of software with hardcoded paths at this time: https://wiki.archlinux.org/title/XDG_Base_Directory#Hardcoded

        • Kogasa@programming.dev
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          If you install config files to the new location and prefer the new config file location over the old, you risk accidental misconfiguration when a system has both config files (e.g. in a build pipeline that installs the software and then copies the config to the old location). It is not impossible to solve, but there are questions that require some care if you have a large userbase and solidified codebase. More care than it takes to do it right the first time.

    • aulin@lemmy.world
      link
      fedilink
      arrow-up
      4
      ·
      1 year ago

      A (very well used) program I use places files in $HOME. Someone argued for changing to $XDG_CONFIG or at least add that as an option. The dev, being used to the old school way, gave the exact opposite reason: that .config was just an extra level of organization when dotfiles are what the home dir is for. So I’m not sure how successful you would be with that approach.

      To be clear, I am clearly on the side of XDG, myself.

    • cbarrick@lemmy.world
      link
      fedilink
      English
      arrow-up
      6
      arrow-down
      3
      ·
      1 year ago

      XDG is a Red Hat thing.

      Stuff outside of their influence is unlikely to change, like OpenSSH or ZSH.

  • Gleddified@lemmy.ca
    link
    fedilink
    arrow-up
    59
    ·
    1 year ago

    One of my greatest pet peeves is random folders appearing in my home folder. Thanks for this

    • unalivejoy@lemm.ee
      link
      fedilink
      English
      arrow-up
      68
      arrow-down
      1
      ·
      edit-2
      1 year ago

      Let’s count them. (not including legacy or standard locations like .local, .config, or .cache, .ssh, and shell configuration files

      • .aws
      • .azure
      • .bun
      • .byobu
      • .cargo
      • .dbus
      • .docker
      • .dokku
      • .keychain
      • .kube
      • .minikube
      • .motd_shown
      • .node_repl_history
      • .npm
      • .nuxt
      • .nuxtrc
      • .nvm
      • .oh-my-zsh
      • .pack
      • .psql_history
      • .pyenv
      • .python_history
      • .redhat
      • .ruff_cache
      • .rustup
      • .selected_editor
      • .sqlite_history
      • .sudo_as_admin_successful
      • .tmux.conf
      • .tox
      • .ts_node_repl_history
      • .vim
      • .viminfo
      • .vimrc
      • .vscode-server
      • .wget-hsts
      • .yarn

      And a couple more, non-hidden files for Go.

      • go
      • sdk/go1.20
      • WasPentalive@beehaw.org
        link
        fedilink
        arrow-up
        17
        arrow-down
        1
        ·
        edit-2
        1 year ago

        Why aren’t all of these just normal directories under either .local (for data files) or .config (for configuration)???

        Actually, I think the XDG directories should be under a single XDG directory either dotted or not (a better name would be OK with me) ~/xdg/Documents, ~/xdg/Music, ~/xdg/Pictures etc.

        • unalivejoy@lemm.ee
          link
          fedilink
          English
          arrow-up
          5
          ·
          1 year ago

          Documents, Music, etc actually are configurable. Just edit ~/.config/user-dirs.dirs

          • WasPentalive@beehaw.org
            link
            fedilink
            arrow-up
            3
            ·
            1 year ago

            I also had to (under KDE)

            • Edit the settings for each of the folders in Dolphin (The file manager)

            • Edit the location of the desktop folder in the settings found by right-clicking the desktop and going into “Configure Desktop and Wallpaper” Location.

            • Edit the show item by choosing Custom Location, and adding the XDG directory for the desktop. This setting may not stick.

        • flying_sheep@lemmy.ml
          link
          fedilink
          arrow-up
          5
          ·
          1 year ago

          That’s the beauty: XDG compliant applications are entirely configurable using standardized environment variables.

  • tal@kbin.social
    link
    fedilink
    arrow-up
    50
    arrow-down
    7
    ·
    edit-2
    1 year ago

    They may not want their configuration stored in $HOME, for example:

    they’re on a machine that isn’t under their physical control and ~/.config is mounted over the network from their personal machine;

    That sounds like it’s a bad way to handle configuration, since among many other problems, it won’t work with the many programs that do have dotfiles in home directory, but even if that happened, you could just symlink it.

    they prefer to version control their configuration files using git, with a configuration directory managed over different branches;

    I do that. I symlink that config into a git-controlled directory. If OP plans to put his entire ~/.config in git, he is doing things wrong, because some of that needs to be machine-local.

    the user simply wants to have a clean and consistent $HOME directory and filesystem

    If whatever program you are using to view your home directory cannot hide those files, it is broken, as it does not work with a whole lot of existing software.

    less secure,

    If your home directory is “not secure”, you’re probably in trouble already.

    Like, there are reasons you may not want to put dotfiles in a homedir, but none of the arguments in the article are them.

    EDIT: I will ask developers to stop dumping directories and files that don’t start with a dot in people’s home directories, though. I gave up over twenty years ago and put my actual stuff under ~/m just to keep it from being polluted with all the other things that dump non-dotfiles/-dotdirs in a home directory. Looking at my current system, I have:

    • A number of directories containing video game saves and configuration. I am pretty sure that these are mostly bad Windows ports or possibly Windows programs under WINE that just dump stuff into a user’s home directory there (not even good on Windows). Some are Windows Steam games.

    • WINE apparently has decided that it’s a good idea to default to sticking the Windows home directory and all of its directories in there.

    • Apparently some webcam software that I used at one point.

    • A few logfiles

    • PlexSheep@feddit.de
      link
      fedilink
      arrow-up
      21
      ·
      1 year ago

      I agree with most of your points, but I still think putting configs in the xdg dir instead of putting tons of dotfiles in $HOME is good practice.

      I find dotfiles to be that stuff that I want to edit easily, and xdg stuff to be that stuff that I don’t edit frequently (manually at least)

    • rockstarmode@lemmy.world
      link
      fedilink
      arrow-up
      14
      ·
      1 year ago

      I agree with most of your points. Just wanted to add that I use Git + GNU Stow to manage this exact situation and it works flawlessly.

      • tal@kbin.social
        link
        fedilink
        arrow-up
        3
        ·
        edit-2
        1 year ago

        Yeah, I think I tried it and it didn’t do something I wanted and so used a homebrew script for the same thing, but it or a similar package or script is definitely what I’d recommend.

        That should work with dotfiles in .config, in the home directory, any other config you want to be portable across machines, etc.

    • PixxlMan@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      Somehow I’ve never considered using git for version controlling/version synchronizing anything other than exclusively code… Brb gonna git all my files.

  • herr@lemmy.world
    link
    fedilink
    arrow-up
    24
    arrow-down
    2
    ·
    edit-2
    1 year ago

    And wtf is with anaconda3 just permanently changing your “user@machine” terminal prompt?? Who thought that was a good idea?

    • SteveTech@programming.dev
      link
      fedilink
      English
      arrow-up
      6
      ·
      1 year ago

      As someone who uses anaconda, it’s quite useful to know what environment I’m in, but I definitely don’t have it enabled by default.

      • sickday@kbin.social
        link
        fedilink
        arrow-up
        4
        ·
        1 year ago

        You can manage symlinks pretty easy with home-manager. I’d personally setup symlinks for these app configuration directories if I don’t want them storing files directly on the disk I use for $HOME. It’s also done in a delcarative way that can persist across multiple computers.

        • onlinepersona@programming.dev
          link
          fedilink
          English
          arrow-up
          3
          ·
          1 year ago

          I’m not sure I understand. So you create a symlink from $HOME/.program.ini to something in the nix store? If so, how does that solve the problem of clutter in $HOME ?

          • sickday@kbin.social
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            If so, how does that solve the problem of clutter in $HOME ?

            If it wasn’t clear from my message, the problem(s) these tools are solving for me would be 1. not having to keep track of my dotfiles and their directories, and 2. not storing configuration files directly on the disk I use for the $HOME dir. I’m not claiming these tools would solve clutter in the $HOME dir. Further, I think it should be alright for me to share tools for managing configuration files in your home directory in a discussion that directly relates to that subject.

            So you create a symlink from $HOME/.program.ini to something in the nix store?

            Normally it’s the other way around. When you use nix and home-manager, you’re technically generating files that will live in the nix-store and nix/home-manager will take care of symlinking those files to locations in your $HOME dir.

            In this scenario though, I would use the https://nix-community.github.io/home-manager/options.html#opt-home.file option from home-manager to create a symlinks to a location that’s outside of my $HOME dir so those files don’t have to live on my home disk.

            My particular use-case is that I want persistent configuration files that are shared throughout a handful of devices on my network. To this end, I use some home-manager symlinks that lead to a network folder where all these various directories and configuration files actually live. I edit those configurations in a single place and their changes propagate across the network to all the devices that would use them.

          • Byter@lemmy.one
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            You’re right, it doesn’t. That does give me an idea though.

            You could use overlayfs with an opaque upper directory to hide the files littering your $HOME and still access them by bind-mounting them into the appropriate xdg dirs.

            Way more effort than it’s worth, of course.

    • pivot_root@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      Is there an easy way to learn this for just the package manager? Most of the tutorials I find are tailored to NixOS, which I’m not using and don’t plan on using.

      • Chobbes@lemmy.world
        link
        fedilink
        arrow-up
        3
        ·
        1 year ago

        You can absolutely use nix and home-manager without NixOS, you can even use it on a Mac!

        Most of the tutorials I find are tailored to NixOS

        I think that’s less true than you think. There’s definitely a lot of tutorials from people who do use NixOS… But this mostly doesn’t matter, using nix is more or less the same regardless of operating system. There is some stuff specific to NixOS, but that’s mostly just using nix to configure system services.

        Is there an easy way to learn this for just the package manager?

        That said… There’s not a super easy gateway to learning nix, unfortunately. The easiest way to learn is probably to try to package one of your personal projects, or by learning home-manager and trying to fully declare your home environment. Packaging programs in certain languages can involve having to learn more about the nix ecosystem than others (e.g., python is a little more complicated than what you’d need to package a simple C program, because python has it’s own ecosystem that you have to integrate with).

        Probably the best introduction is the nix pills if you want to learn how nix works (not necessarily how to use it, but it will give you a really solid foundation):

        https://nixos.org/guides/nix-pills/

        Though, it’s really common for people to bounce off of the nix pills because they start kind of slow. If you can follow through them, though, you’ll have a good understanding of the nix language and how it’s used to construct derivations for building packages.

        The nix language is much maligned, but it’s actually not as bad as you think going in (error messages can be ATROCIOUS, however). It looks a bit weird, but I think if you go in with the understanding that it’s “Turing Complete JSON” you’ll have a better time. Almost everything you’re doing in nix is building up attribute sets (which are basically just JSON dictionaries) which specify the dependencies and build stages of a project… But it’s not a static representation like JSON, you can call functions to do arbitrary computations to build up fields (e.g., I have some functions to automatically set up wireguard configurations from a description of the network layout of my machines, so it’s useful to be able to do this stuff).

      • sickday@kbin.social
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        For what it’s worth, I don’t understand the nix language or all the package manager functions in their entirety. I generally use what I need and that’s it. Most information I’ve required that is nixpkgs-specific I was able to find in the manual. home-manager has one as well and it’s been the best reference for me.

  • Urist@lemmy.ml
    link
    fedilink
    English
    arrow-up
    17
    ·
    edit-2
    1 year ago

    Tangentially related: I recently learned that there are tools for handling dotfiles such as chezmoi and yadm. I would suppose that after spending some time on backing up the dotfiles that matter one can purge the remainders without much issue. I also remember some tool that was made for the purpose of cleaning $HOME, but can not recall its name (if anyone knows please let me know).