Lots of comments in the thread from February 2023: <a href="https://news.ycombinator.com/item?id=34730520">https://news.ycombinator.com/item?id=34730520</a>
FYI. There is a XDG checker called "xdg-ninja"[1]<p>> A shell script that checks your $HOME for unwanted files and directories.<p>> When xdg-ninja encounters a file or directory it knows about, it will tell you whether it's possible to move it to the appropriate location, and how to do it.<p>1. <a href="https://github.com/b3nj5m1n/xdg-ninja">https://github.com/b3nj5m1n/xdg-ninja</a>
Oh this is my project! I haven’t had energy to work through pending issues for a while due to health reasons; I do still have interest in maintaining it but my health makes it a struggle.
From the README:<p><pre><code> It wants to put its config in ~/.tmux.conf. With boxxy, you can put its config in ~/.config/tmux/tmux.conf
</code></pre>
From tmux(1):<p><pre><code> By default, tmux loads the system configuration file from /etc/tmux.conf, if present, then looks for a user configuration file at ~/.tmux.conf $XDG_CONFIG_HOME/tmux/tmux.conf or ~/.tmux.conf.
</code></pre>
XDG_CONFIG_USER defaults to "$HOME/.config".<p>Very poor choice for an example.
On a tangent: it bugs me that the default XDG directory structure doesn't fully match the standard Linux directory structure. What's with these inconsistent defaults?<p><pre><code> XDG_DATA_HOME="$HOME/.local/share" # okay, reasonable
XDG_CONFIG_HOME="$HOME/.config" # ...uh, pardon?
XDG_STATE_HOME="$HOME/.local/state" # well at least it's in ~/.local
XDG_CACHE_HOME="$HOME/.cache" # ...but this one ain't; what in tarnation?
</code></pre>
It'd make more sense to be consistent with how system-wide applications use /usr or /usr/local, like so:<p><pre><code> XDG_DATA_HOME="$HOME/.local/share"
XDG_CONFIG_HOME="$HOME/.local/etc"
XDG_STATE_HOME="$HOME/.local/var/lib"
XDG_CACHE_HOME="$HOME/.local/var/cache"
</code></pre>
This would make $XDG_(CONFIG|STATE|CACHE)_HOME consistent with $XDG_DATA_HOME, and also consistent with existing conventions around ~/.local/bin and ~/.local/lib.<p>The XDG spec ain't the only naughty naughty boy here, either. Flatpak puts all of its application data in ~/.var/app, whereas it'd make a lot more sense in ~/.local/var/lib/flatpak/app. And of course, the subject of Boxxy (and, as others mentioned, xdg-ninja) is the countless apps contributing further to the chaos.<p>Of course, all this would stop being an issue entirely if Linux would just embrace union mounts like Plan 9 did and overlay everything onto /bin, /lib, /share, /etc, and so on. Hell, if I were the not-so-benevolent dictator for life of the Linux ecosystem I'd take the opportunity to rename all those weird UNIX™ vestiges, too, like /etc→/conf and /var→/data - but if we're gonna hang on to those vestiges, the least XDG could do is encourage consistency with them.<p>Maybe I just need to make my own distro and finally say goodbye to what little remains of my sanity.
> boxxy is a part of the amyware discord server.<p>Can we reverse this trend? I've recently started to see an FAQ, on GitHub, hide the answer with a deeplink into Discord channels where you needed to find the guild to join first. I've never gotten disinterested in a project that fast. This needs to stop.
I don't know if the reference was on purpose, but I now have this 13 years-old remix on repeat : <a href="https://www.youtube.com/watch?v=LHNZVAjadqY" rel="nofollow">https://www.youtube.com/watch?v=LHNZVAjadqY</a>
Related question: Which software do you recommend to sandbox a locally running AI agent, so that it can only access parts of the filesystem (e.g. one folder) and an allow-list of URLs?
> alias aws="boxxy aws"<p>That's rather inconvenient to alias ever app, is there a more ergonomic way to rewrite the file access calls?
Is this like a better version of toolbx? Because I love toolbx and use it daily, but I wish it allowed for more granular configuration.<p>For example I'd want to create more containers for more specific use cases where they only have access to specific dirs in my HOME.