Show HN: boxxy – Control where Linux programs put files, without symlinks | Hacker News Reader

Show HN: boxxy – Control where Linux programs put files, without symlinks

github.com

384 pointsnotamy239 comments

If anyone would like to actually force the non-compliant applications to do the thing correctly, then xdg-ninja is your friend [0]. The script looks at all the dotfiles in the home folder and tells you what environment variables you have to set to make them follow XDG base directory specifications, in the cases where that's not possible it will show you the related GitHub issue or similar bug tracking option with the problem.

My current dotfiles [1] already have a lot of these and they mostly just work. Once in a while an application won't respect it completely, and so instead of having a mess with xdg + whatever the dev though was cooler I just let the application do it's thing so at least is somewhat predictable.

[0]: https://github.com/b3nj5m1n/xdg-ninja

[1]: https://github.com/DoodlesEpic/Dotfiles/blob/main/.profile

This is fantastic! Thanks for the share. Reminds me of lostfiles for Arch. https://man.archlinux.org/man/community/lostfiles/lostfiles....

Was thinking this would be a useful tool, same as a tool that would show you where environment variables are being set, and which ones override what.

It also has a table of applications docunented https://wiki.archlinux.org/title/XDG_Base_Directory

I have a similar list in my bashrc [0]. I didn't know about xdg-ninja though, thank you!

[0]: https://github.com/evanpurkhiser/dots-personal/blob/main/bas...

Does it use a centralized database of all known software?

The information comes from Arch Wiki's list of everything known [0].

[0] https://wiki.archlinux.org/title/XDG_Base_Directory

Hah I was literally just complaining about applications not following the XDG directory spec today.

there's a non-exhaustive list of applications on the archwiki [0] that put their config/data in dotfiles in the home directory. surprisingly, there's also lots of pushback from maintainers of projects who don't want to change this, for whatever excuse they can produce. a Reddit thread has some list of issues where the change is brought up [1].

Anyway, I'll look forward to testing this out.

[0] https://wiki.archlinux.org/title/XDG_Base_Directory

[1] https://www.reddit.com/r/linux/comments/971m0z/im_tired_of_f...

Yep, this does my head in. I really feel like there's no excuse for it in 2023.

Can I also soapbox about the XDG_CONFIG_HOME (~/.config) folder having gigs of temp data in it?

(I'm looking at you, Slack!)

How awesome would it be to be able to back up my custom app configs just by copying around one tiny folder? Or throwing it in a git repo and knowing what config changed when? :\

    $ du -sch ~/.config/Slack
    846M $HOME/.config/Slack
    846M total

... this is on a two day old machine. WTF, Slack? Junk cached data belongs in ~/.local/share ($XDG_DATA_HOME), not ~/.config.

I think you mean `~/.cache`.

a bunch of windows stuff does this too putting config in appdata/local and huge cache assets in appdata/roaming. anything that depends on good behaviour is doomed imo like Google wave circles

What’s really frustrating are the number of first-party Microsoft products which do this.

Yeah. It annoys me to no end that the new powershell didn't take the opportunity to move the config out of My Documents and into roaming app data which in theory is where that sort of file should be.

It's things like that which have made me give up on %USERPROFILE% (and to a lesser extent $HOME), and I now put my files that I care about into a completely separate folder outside of the normal hierarchy.

Could you elaborate on that? I too am quite unhappy with the mess my %USERPROFILE% has become.

Oh, it's really not anything impressive. I've just decided to treat %USERPROFILE% as for machine generated files only. I then have a new directory on C: where I put my documents/projects/etc (all in appropriate sub folders).

My config files are a bit more interesting, and are stored in a chezmoi[^1] repo. If I tinker with a program enough, I generally move its config into there so I can keep track of it and the changes (to make this easier I have a bat file in shell:sendto to add files/folders to chezmoi).

Thinking about this, I should probably move the chezmoi repo into my personal directory, and symlink it back to it's normal location.

[1]: https://www.chezmoi.io/

Should've kept Slack in a containered in a browser tab where it belongs so it can't go messing with your system or prevent you from blocking their tracking.

And then I've seen websites hoggi g gigs of local storage after you visit them once a blue moon. The trend is blatantly towards no optimization whatsoever. Apart from profits and squeezing the last drop off your customers by any means necessary

The fault lies with Electron [0]. Open issue since 2016 to fix this behavior only for it to devolve into a morass of, “What is cache?”

[0] https://github.com/electron/electron/issues/8124

Some of these programs also spam the home folder on Windows instead of using the path specified in the %APPDATA% environment variable.

Some also put it in %HOMEPATH%/.name because they are bad ports from Unix. I'd argue that it's better than in My Documents though.

The dotfiles and dotfolders directly in the home folder is "the way it was always done", and now some "new kids" came and want changes done to software which has existed before they were even born. People have muscle memory for those folders, some have hardcoded those paths in other scripts, others just don't care, and things stay as they always were.

On one hand, it's great to have all the stuff in the same place, on the other hand, we used to have this, before the ~/.config folder too.

Also, it's not just in one place anymore, but in many places -- so to completely remove a programX, it's not enough to just remove ~/.programX, but you need to remove a folder from ~/.config/, and another one from ~/.local/something, and another form ~/.cache,...

So yeah, i understand 'the old guys' too... maybe because i'm not 20-something anymore.

The XDG base directory specification[0] was initially introduced in 2003; 20 years ago now. Yes there's plenty of software that existed before 2003 which didn't respect XDG, but most all of the Linux software dumping dotfiles in my homedir where written not just after 2003, but many years after 2003. For example, the following pieces of software all have dumped garbage in my homedir, and all are much less than 20 years (or even 15 years) old:

    vault
    flyctl
    yarn
    npm
    vscode
    terraform
    rustup
    kubernetes
    fzf
    eclipse
    docker
    cargo
    aws (cli)

There's no excuses for these programs not respecting standards that are 1. Well established by the time the software was written and 2. short (seriously, the standard's contents fit entirely on three A4 pieces of paper)

[0] - https://specifications.freedesktop.org/basedir-spec/basedir-...

But why should developers conform to that specific standard, if (for them, and many of their users) it makes more sense to use a "~/.wine" (or whatever other) folder?

If i want to completely remove wine from my profile, how many folders do I have to delete doing it the old way? One - ~/.wine. How many using the new? One in .config, then .local/share, probably one in .cache... oh wait, .local/state too.. Probably.. well, maybe, I'd have to check manually. Same for other software. One folder to remove, one folder to backup, one folder to restore.

Following the standard does not require you don't have a single folder, it can all be changed with 4 simple environment variables. If you want to have everything dumped horrendously in your home folder nothing is saying you can't, it just wouldn't be the default, because it's simply not an orderly way to organize the files.

The biggest problem is programs that don't even let you change where they store the stuff, so even if you're okay with the default not being XDG you dont even have the option to make it respect XDG base directory specification.

Whenever I install directly instead of using e.g. apt (typically because I want a more current version than the distro has), I use GNU stow [0], for precisely this reason. It works at the system level, at the user level, within projects, wherever. A simple "stow -D" is all it takes to clean out all the directories.

[0] https://www.gnu.org/software/stow/

If, as you say

> most all of the Linux software dumping dotfiles in my homedir

then is it really true, that the standard is in fact "well established"?

Right now I have in my home folder 4 undesirable dot something which should be somewhere else and I can't change it. Meanwhile, I have 63 folders in my .config which means most of the applications I'm using do respect the XDG base directory specification, only a few entitled or extremely legacy ones don't.

Out of curiosity, what are the misbehaving ones?

.mozilla - Firefox
.npm - NPM
.pki - Chromium-based software
.SpaceVim.d - My fault, I should write my own vimrc but I'm lazy
.steam and .steampath and .steampid - Steam
.vscode-oss - VS Codium

.w3m - w3m cli browser

These are the ones I couldn't change the behavior of, in my dotfiles I've managed to fix at least a dozen of programs that were previously misbehaving but offered environment variables to change their behaviors.

The thing that bothers me most about these is that most of these folders are simply cache and logs, I can always delete them and the application will keep working, but of course the folders will be recreated. It's truly mind-numbing.

Firefox

  # Save shell wrapper as '~/.local/bin/firefox'

  { while kill -0 $$ 2> /dev/null; do rm -rf $HOME/.mozilla; done; } &
  /bin/firefox --profile $XDG_DATA_HOME/firefox $@

NPM

  # set env variable
  export NPM_CONFIG_USERCONFIG=$XDG_CONFIG_HOME/npm/npmrc

  # and in npmrc:
  prefix=${XDG_DATA_HOME}/npm
  cache=${XDG_CACHE_HOME}/npm
  tmp=${XDG_RUNTIME_DIR}/npm
  init-module=${XDG_CONFIG_HOME}/npm/config/npm-init.js

Steam

  Steam actually creates only symlinks for backward
  compatibility as some games (may) expect them in $HOME.
  You can safely launch it with modified HOME variable:
    $ HOME="$XDG_DATA_HOME/Steam" steam
  (and/or put it into a wrapper script like with Firefox)

Vim

  I don't know how it's with SpaceVim,
  but with regular vimrc you can make it follow the spec:
    https://blog.joren.ga/vim-xdg

w3m

  export W3M_DIR="$XDG_DATA_HOME/w3m"

What the hell you may have just changed my life. The NPM one I was aware of through xdg-ninja but last time I tried it didn't work because I also use nvm which doesn't support that, honestly not an issue with NPM, I should've noted in the comment. The Steam one however is a total life-changer, if I ever find you in the street someday remember me I owe you a beer (or some non-alcoholic beverage of your preference).

If only.

There is a single base directory relative to which user-specific data files should be written. This directory is defined by the environment variable $XDG_DATA_HOME.

There is a single base directory relative to which user-specific configuration files should be written. This directory is defined by the environment variable $XDG_CONFIG_HOME.

Neither of those environment variables is defined on a stock Ubuntu 22.04.1 LTS.

$XDG_DATA_HOME defines the base directory relative to which user-specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used.
$XDG_CONFIG_HOME defines the base directory relative to which user-specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.

$XDG_STATE_HOME defines the base directory relative to which user-specific state files should be stored. If $XDG_STATE_HOME is either not set or empty, a default equal to $HOME/.local/state should be used.

https://specifications.freedesktop.org/basedir-spec/basedir-...

I like this system overall, but this particular aspect seems like a mistake [0] to me. Instead of a simple rule like "use these envars", it has this more complicated logic that must be replicated in all apps supported by all developers. Users would have more agency if they could inform apps of their preferences by simply setting some envars. [1] If this simpler, more user-friendly regime had been in the spec, we would have seen better adoption initially and also two decades later.

[0] of course one shouldn't assume that a totalitarian decision is a mistake, because it's just as likely that the decision-maker has priorities other than "support users"

[1] yes of course users have agency with respect to where XDG is implemented, but the simpler rule would also have given them agency with respect to whether it is implemented

And the variables should not be set if the user/distro wants the default (probably to force developers to handle the default case which is needed for compatibility anyway).

Sure, XDG was introduced in 2003, but why would you expect developers to start to follow its rules instantly? At best, it started to gain some traction 4 or 5 years after that, but still today, it is far from universally accepted.

But take a step further back: why should anyone care about what the XDG says in first place? This isn't a dictatorship, and things were doing just fine long before a handful of people who wrote the XDG thought their ideas were the best approach.

It's been my observation that good standards can be adopted broadly and quickly with little controversy or need for advocacy. The fact that the XDG file layout still isn't universally used suggests it doesn't have as much value as its proponents think.

> But take a step further back: why should anyone care about what the XDG says in first place?

Because their users are asking them to not pollute the home directory? This isn't bikeshedding config locations without reason, there is a clear motivation for letting users a) specify where data should go and b) separate different types of data.

> It's been my observation that good standards can be adopted broadly and quickly with little controversy or need for advocacy.

The XDG basedir spec has been adopted broadly amongs many organizations and individual devlopers including all major desktop environments. It is not adopted universally yet, but few things are.

> There's no excuses for these programs not respecting standards that are 1. Well established by the time the software was written and 2. short

This isn't a standard, it's a convention at best. A freedesktop.org specification. Basically a scheme Red Hat people thought up and implemented widely in the open source software projects they control. It may be a useful abstraction but there's absolutely no obligation to conform to it. There doesn't have to be an "excuse" or any form of justification at all. "I just don't like it" is enough. I don't like those unsightly XDG variables either and it's entirely within my power as a software developer to trash the entire concept of XDG and do things in any way I see fit.

https://www.freedesktop.org/wiki/Specifications/

> freedesktop.org produces specifications for interoperability, but we are not an official standards body.

> There is no requirement for projects to implement all of these specifications, nor certification.

This is the world of Unix, there's very little obligation to do anything other than convention. That's technically true, just like you can write your software to ignore all signals, or write your software such that it assumes it's always run as root for your convenience. That may be more convenient for you the developer, it's true.

But those are all generally poor ways to write software, and a great way to get your users to complain. So it is with ignoring XDG.

To put configs in ~/.program is the convention I learned, not ~/.config/. That came later, and I see 0 reason to pick it up. It's an annoying new hierarchy which I don't even like as a user, so I certainly wouldn't follow it as a developer.

If the programs in question implement the XDG base directory spec properly, then putting `export XDG_CONFIG_HOME=$HOME/.program` in your .profile will make them put config files in .program, not .config.

Charming idea :) I'm not actually that annoyed that I will set XDG_CONFIG_HOME to $HOME, but I'll keep it in mind.

> This isn't a standard, it's a convention at best.

So is, like, basically all of userland in a UNIX system. Maybe we need to start looking at that as a problem instead of an excuse.

It is within your power as a developer to delete the user's home directory if you want to as well, that doesn't mean you should do it!

The really fun part is when you have a program that has ~/.programX, but also ~/.programXy, ~/.programX_cache, ~/.programxrc, ~/.programx_init, ~/.programx/a_whole_directory, ~/.otherthing, ~/.maybe_a_database_for_good_measure.sqlite, ~/.and_the_kitchen_sink_too. And that's not even getting into questions like "can I nuke ~/.programX_db to clear the program's cache without losing my configurations?". I agree that the XDG spec isn't an improvement for programs that have _precisely_ one config file, but it's a _major_ improvement for programs that need multiple config files, config directories, separate configs and caches, and more, and it's not a _regression_ from single-file configs.

That's why that kind of software uses a .programX directory, where everything like that can be put in.

Look at ~/.wine for example... config files, whole C drive, everything in one simple folder. Want to upgrade to an alpha version to test something, but don't want to break anything that's now working? Just backup that one single folder. Restore or migrate configuration to another computer? One single folder. Remove any trace of that app? Again, one simple folder.

Want to do the same with google chrome? .config/google-chrome... oh wait, what if there's something in .local too? Still doesn't work? Oh wait, you forgot the .cache directory, and have been loading an old version of something.

If you have a mass of cached data that shouldn't be backed up would you rather just exclude .cache or investigate what files/directories every individual app uses.

> Look at ~/.wine for example... config files, whole C drive, everything in one simple folder

Except it isn't really. Just a few days ago I tried to purge Wine from my system. Uninstalled through pacman, cleaned up orphaned dependencies. Killed the ./wine folder and various other leftovers too, because depite your claim, there they were, though I didn't commit to memory exactly where and what. Removed some autostart shortcuts, cleared a few icons from desktop, and manually edited the Plasma menu to remove some stubborn links.

And yet ... I still get suggestions to open my jpg's and png's with something called Wine Internet Explorer. Which i don't really believe is distro specific, since I've seen the same thing happen in both Debian and RedHat derivatives.

This is probably because Wine created a .desktop file in the directory for registering default applications. I don't remember what the directory path is but your package manager is responsible for it, not Wine. They can't put it in .wine because it's a standardised location.

Just FYI, in case it is useful for you: Here's the information that you would want for cleaning that up.

https://wiki.winehq.org/FAQ#How_do_I_clean_the_Open_With_Lis...

If you ever want to prevent this integration from happening in the first place, you can do it by editing the registry in a given wine prefix. You can run regedit with the usual command, `wine regedit`, then locate the key:

HKLM\Software\Microsoft\Windows\CurrentVersion\RunServices\winemenubuilder

Set it to empty to disable the integration entirely. Or, just remove the `-a` switch and you will still get desktop icons, just not file associations.

It is unfortunate that it has to be outside of the WINEPREFIX, but there's no way around it, since those various files need to be in their respective locations to reasonably be picked up. (Maybe it could use symlinks instead, but even if it did, they'd need to get cleaned up by something when the target gets deleted.)

> It is unfortunate that it has to be outside of the WINEPREFIX, but there's no way around it

There is a way around unwanted and unexpected associations though: make the integration opt-in instead of opt-out and/or filter associations that the user is unlikely to ever want (like standard file types that will almost certainly already be handled outside Wine). Wine's Internet Explorer is there for compatibilty with Windows programs that expect IE, exposing it outside the Wine environment does not make any sense.

Since I use multiple prefixes, including temporary ones, editing registry in each one of them is not an option so I have my package manager set not to install winemenubuilder at all.

I believe another approach is to edit the default registry settings in /usr/share/wine/wine.inf so that new prefixes have the desired setting. Of course, then when updating the package it has to be reconciled. But it does have the advantage of being able to allow e.g. the settings that would only produce launcher icons and not file associations. There's another method using environment variables too, though I think that one basically works the same as removing the package entirely and can't be used to customize the behavior.

I kind of agree with you that the defaults are not great, or at least if things haven't changed. We could always see if maybe they'll accept patches to filter out more stuff by default.

IMO, Wine desktop integration should be off by default.

Like with privacy issues, once you realize you want to opt out the mess has already been made.

> Just backup that one single folder.

Backups are the main reason why I want programs to follow the XDG Base Directory Specification. I don't want my backups to includes gigabytes of files that should be in ~/.cache, which is a directory I never back up. The shell script that I wrote to back up my PC includes dozens of rsync exclusions for files in ~/.mozilla, etc. that should be in ~/.cache.

> That's why that kind of software uses a .programX directory, where everything like that can be put in.

You mean, this is why that kind of software should use a .programX directory. Evidently many don't. And of you think about doing it, just move it into .config for good measure...

Crap like wget just keeps shoving files directly into my home instead. When they added hsts support they had the chance to finally create a directory, ideally in .config, so if they need to add even more files in the future they wouldn't have to clutter $HOME even more. But no, that would be too forward-thinking. Just put the hsts file in home and be done.

> some have hardcoded those paths in other scripts

My sympathy is lacking, as is my respect for those running projects that hardcode paths. Stop hardcoding paths and the world will be a better place.

eg. ~./bashrc has existed there for 30+ years, changing stuff just because someone doesn't like seeing a file in a folder is imho stupid.

A hidden file, even. Stop using "ls -A" and you'll be fine.

To be pedantic, if we're going to cite Unix history, then technically there is no such thing as a "hidden" file. As I understand, the original implementation of tools like ls would not show the current directory "." in the listing. The quickest way of doing this in C was checking whether dentry.name[0] == '.'

This also had the side effect of hiding entries that had names beginning with ".", and over time an implementation bug/quirk became accepted behaviour, and was post-hoc rationalised as "hidden" files.

Who cares how the feature of hidden files came to be, when it has been what it is now for so many years?

As a defence of hardcoded paths might go, I could've done better myself. What else from your OS 30 years ago might you keep just because it's 30+ years old?

I keep it because it's worked for 30 years without issues and it's still working. Must you always replace something, just because a newer thing is "out there"? On the other hand, this is hackernews, and rewriting everything, from a text editor to a file browser, into a <language of the week> (ruby, go, rust,...) is a thing.

Try moving all of those directories and files somewhere else that you would prefer and then see which programs break, which apps and libraries won't install, and then wonder why hardcoding is something the devs for these projects cling to.

Or perhaps Bash for 30 years was using a sub-optimal solution and now when a better approach has emerged it just stubbornly refuses to adapt?

I'd say bashrc and profile and friends are one of the few examples in which using hardcoded paths is OK. Same with SSH, GPG, and PAM.

But when people are talking about compliance, and hardcoding very few people are talking about those applications - there are hundreds of other applications do the wrong thing, and some scripts hardcode things as a result.

No, but don't keep doing it that way for new software, or even new files. You existing config file is in ~ because it's 30 years old. Fine.

If you get to the point where you need another file for something, put it in a directory under .config so whenever you need to add even more, you don't keep cluttering my home.

Home is where the .bashrc is <3

> Also, it's not just in one place anymore, but in many places -- so to completely remove a programX, it's not enough to just remove ~/.programX, but you need to remove a folder from ~/.config/, and another one from ~/.local/something, and another form ~/.cache,...

OTOH if you want to completely remove your cache, or completely backup your config...

I don't see the problem. There's no reason to choose one or the other when we can have both. Many programs try several options. Git for example tries ~/.gitconfig and ~/.config/git/config.

Do people seriously resist such non-destructive improvements just because they think it's offensive when younger programmers have opinions on legacy software?

Personally I see a lot of young people use emacs and BSD licences, but because I'm an older engineer and have the wisdom and experience of time, I use vim and GPL.

I honestly can't imagine not using vim. It fits like a glove. Sometimes I find myself typing <Esc>;wq to try and send messages.

Another man with the wisdom of ages, irrespective of the date of your birth. Your choice of text editor reveals that you must also be quite good looking.

Exactly, except for a minor typo. :s/vim/nvim.

What age are those who use nano?

/hides

hi!

I'm also a Vim user; in my Vim wisdom and experience I made it follow the damn XDG spec; if hidden files are a feature, I want it to be a feature for my use-cases, not program clutter.

I use nvim like the user (backers.md baby!) so I get to use `master` with `~/.config/nvim/init.vim`. Of course, I also donated to Bram's Ugandas or wherever, so I think you are a wise and attractive person. Your choice of actions reveals that your soul is deep and beautiful.

> now some "new kids" came and want changes

I realize that you wrote "new kids" in quotes, but these "new kids" might have grandchildren at this point given that the initial draft of the XDG Base Directory Specification was published in 2002.

If we want to flex gray hairs, the idea that an application should put it's configuration files in dotfiles cluttering the home directory is regarded as a mistake by the people who are responsible for it.

https://web.archive.org/web/20180827160401/https://plus.goog...

Obviously, we are now stuck with dotfiles as a "feature", but that doesn't mean we need to have more of them than necessary. Cluttering the home folder with a disorganized mess of files with different modalities next to eachother is ridiculous, pointless, and a collective waste of time.

Almost all of the apps people are complaining about not following XDG were created long after the XDG base directory specification existed. It's time to move on.

P.S.: it'd be preferable also if it wasn't simply implied that everyone who's been around Linux/UNIX for a couple decades hates change. Churn for the sake of churn is bad, but churn is not all wasted. Standardizing once-disorganized directory hierarchy is certainly not a waste of time.

Considering the spec is 20 years old, having "muscle memory" is a bit of a weak excuse at this point.

Having a couple of directories to clean up is a bit annoying, but they used to stick the config file in your home and then make an application directory so we were already having to deal with multiple locations.

That's usually not a problem though.

The software can look at $XDG_WHATEVER/tool/config first and ~/.toolrc second. Everyone who wants the clutter can keep using that.

I mean, from the perspective of a person that hasn't heard about it before, this is just another standard[0].

I opened your links. There's no easy way to judge the traction or popularity of this. Why do you think maintainers should just apply another standard that's thrown at them?

I don't mean to be dismissive nor criticize the standard itself. I'm trying to give you a glimpse of what a person that hasn't heard about XDG before sees, when they open your links.

[0]: https://xkcd.com/927/

What are the competing standards to XDG? Stick everything in $HOME? Stick everything in $HOME/.config?

Those 2 aren't standards and aren't helpful.

Yes, sticking everything into `$HOME/.toolname` is what most cross-platform software is doing, and I imagine that's just fine for the vast majority of users.

Short, memorable passwords like one's birthday or favourite pet's name are "just fine for the vast majority of users". It's a meaningless metric of quality - or more to the point - it isn't a metric of quality.

Weak passwords have securities downside.

I struggle to see what the issue is with ~/.programName ?

Your lack of imagination is not a compelling argument.

First and foremost, that I don't get to decide where things go on my own machine, and that if I do regardless, because developers didn't follow a simple standard and instead decided to hardcode things that shouldn't be hardcoded - which is just about the first thing every dev is taught not to do - things will break.

You may not find it important but is it an issue or not?

1. It doesn't separate program's config, data, and cache; so it is impossible to backup excluding cache, impossible to reset your config without data-loss.

2. It assumes home is infinite, if you are running out of space in home you can't move program files to other partitions. E.G. Flatpack hardcodes its apps data in `~/.var` so if you have a small/almost-full home partition you simply can't install certain Flatpacks.

Except it isn't most cross-plaform software doing that. It might be most of the cross-platform software you use but IME it's mostly it's corporate software plus a few holdouts too stubborn to add two lines to the code reading their config file.

One of the best things about no longer using macOS is not having to fight 'but Application Support/Resources/Nonsense/Foobar.app/Resources/config is the standard location on this platform!' ... The XDG base dir spec makes a lot more sense even on macOS for developer tools, but I'm glad not to have to worry about that any more.

On Linux that excuse is gone, so it's just either 'oops yes will fix' or 'agh, sorry, legacy'. Nobody (that I've ever seen) tries to claim something else is fine or better.

> surprisingly, there's also lots of pushback from maintainers of projects who don't want to change this, for whatever excuse they can produce.

There doesn't need to be an "excuse" though. "I don't like it" or "I don't want to do it" is more than enough. They're the ones maintaining the damn things, the least we can do is respect them. They don't really need to justify anything, acting as if they had to is how you get pushback. They probably deny you just to prove that you have no power over them, because you insinuated otherwise with words like "excuse".

> They're the ones maintaining the damn things, the least we can do is respect them.

we don't respect maintainers who leave in buffer overruns or x-site scripting, why should we respect maintainers who don't respect users? yes, they're writing and maintaining, but undoubtedly also using tons of respectful opensource that other maintainers take care of.

it's like driving a car ("everybody faster than me is a maniac, everybody slower than me is a moron") and cursing cyclists, then jumping on your bike and running red lights, stop signs, crosswalks, sidewalks, you name it. To have a civilized society we all have to go out of our way a little bit for other people, throw away some trash that's not yours.

like forum/reddit moderator phenomenon, there is something about the power (and most definitely the nagging they get from impolite users) that makes the developers act like douches when they probably aren't the rest of the time.

but that's not an excuse for crapping all over my dotfiles and home directory tree.

> why should we respect maintainers who don't respect users?

Saying that using dotfiles instead of ~/.config means they "don't respect users" is a little dramatic, don't you think? Like it or not, unix has historically treated dotfiles as "hidden" and nobody expects you to get upset that they created a hidden file in your home directory without your consent. It's not really about respect, it's just convention you apparently don't like.

I currently have 60 dotfiles in my home directory and probably deliberately created less than 10 of those. The fact that anyone would be upset by this is news to me and most likely is news to a lot of the developers that created these things: cargo, dbus, docker, gem, gnome, gnupg, gphoto, java, kde, maven, mozilla, osquery, rpm, rustup, ssh, vagrant, vim, vscode, wget, yarn, zoom. Not that "this bad behavior is widespread" is a good excuse, but the point is that I don't think the world is at all in agreement that this is "bad behavior."

Just to clarify, it is not just about "hidden" files looking good. There are many reasons one may want to move config/data/cache files to other locations, E.G. in my case I have a computer with home on a small partition that simply can't fit all the crap those misbehaving programs try to put there. I simply can't install Flatpacks on that machine because they obviously won't fit in a small home and can't be moved because of a maintainer who is very disrespectful to users (the bugs full with messages of users pleading for him to allow them to move apps to other partitions is disheartening).

> Saying that using dotfiles instead of ~/.config means they "don't respect users" is a little dramatic, don't you think?

No I don't think so. For many applications (i.e. only config, no cache) it's literally an additional getenv and minimal logic when opening your config files. No additional dependencies needed. The amount of effort required is tiny compared to the benefit multiplied by the number of users that don't want dotfiles in their $HOME.

> we don't respect maintainers who leave in buffer overruns or x-site scripting, why should we respect maintainers who don't respect users?

Because they're the ones putting in the work. I could patch all the programs to use whatever paths I liked best if I really cared but the truth is I don't want to put in that much effort. So I just work with what I'm given instead.

Besides, dotfiles conventions are not even in the same category of technical decision as literal vulnerabilities. One puts people at actual risk, the other is just opinion on file system taxonomy.

I mean, I have opinions on proper file system organization too and they certainly don't match Unix "tradition" but I don't go to other people's issue trackers and shame other developers when they make "excuses" for not following whatever scheme I thought up. I have reasons and I can certainly try to convince others that I'm right but it's simply offensive to show up out of nowhere with an indignant tone demanding that others make changes of a subjective and frankly trivial nature and then criticizing them in other forums when they refuse.

I hate when applications ignore the XDG spec, but you know what I hate more? the XDG spec!

I don't want all my pictures to go in Pictures, all my documents in Documents, etc. I want everything from each project to go in the directory for that project. I don't need it to read my mind, but when I save a document to a new directory and then I want to save a spreadsheet too... I want that new directory to be a top-line choice, but I want the old directory there too.

Doesn't everybody work like me? (asking seriously)

and hey, call me a freak, but I still get the odd sort of picture that I don't want showing up on the lock screen screensaver

hypothetical, but, could easily make a script that, upon cd, checks all above directories for `.xdg-root`, and while inside, has envvars set to use said folder as a root for Documents/Pictures/Etc folders

not a terrible idea, has some good points, but gui apps don't cd in a way that can be hooked, and usually i get around to popping a terminal window after i'm working on a project rather than before. (also, cd isn't so easy to script, I'd have to use a bash function, but i'd probs have to make a up new name to get used to, cdproj or something, otherwise any "headless" scripts would be do it too

And I frequently jump from desktop to desktop for multiple projects, and my terminal on that desktop is likely to already be where I want to be. Do gui apps reliably reload xdg all the time, or only at startup?

anyway, keeping it in mind, it might just be worth the trouble to click a scripted icon on each desktop :)

You can set the XDG environment variables in Direnv maybe?

The Desktop, Downloads, Pictures, etc. directories are not from the XDG Basedir spec and not set by XDG_ environment variables but instead in the $XDG_CONFIG_HOME/user-dirs.dirs file. I also find these less useful than the more generel data/config/cache dirs.

Also I hate localized XDG directories. Windows and macOS don't localize real directory name but only Linux does. I run LANG=C xdg-user-dirs-update after I install Linux with my lang

Windows does (did at least)

And macOS has Xxx.localized directories

Windows just localizes how it shown on Explorer (and have API to get localized name), so real path is still C:\Users\user\Documents . macOS does the same thing by the way as you wrote. I don't think it's a problem.

Only XDG based systems use real /home/user/ドキュメント (in Japanese) directory . This is annoying. Please localize it well as Win/mac does.

I 100% agree. Localized directories was a stupid mistake. The way Windows does it today is much better and XDG should follow suit.

Now yes, but it didn't used to be that way. No, I can't tell you which version changed that, it might have been 2000. :P

Right, I still remember programs blowing up because they expected C:\Program Files and then encountered C:\Programme - that one at least got better when WoW64 forced the issue for english-speaking devs.

What are you talking about? When people say the "XDG spec", they are usually referring to the XDG Base Directory Specification, but there are other specifications from XDG - are you talking about a different one?

Because the XDG Base Directory Specification does not dictate about how files should be saved - whether in Pictures/, Documents/, or anything else...

https://www.freedesktop.org/wiki/Software/xdg-user-dirs/

I don't think there is a spec dictating that the default location for saving files needs to depend on the file tile - which program is doing this? I think Firefox remembers the last used path per file type, even across restarts.

The Desktop, Downloads, Pictures, etc. directories themselves are not from the XDG Basedir spec and not set by XDG_ environment variables but instead in the $XDG_CONFIG_HOME/user-dirs.dirs file. I also find these less useful than the more generel data/config/cache dirs and have most theme set to my home directory - perhaps that is affecting how Firefox works?

Plug: I made a small set of shell scripts to achieve something similar to this a couple of years ago, but with symlinks:

https://tomwh.uk/blog/posts/2020/03/28/fake-home-prison/

https://tomwh.uk/git/fake-home.git/

It's a simple command that shadows the binary names you want with a wrapper in ~/.local/bin/ that calls the original binary after redefining $HOME to be somewhere else (by default inside ~/.local/share/fake-home/).

So if you have a program foo that dumps stuff in ~/.foo, then running `fakehome-banish foo` will create a symlink "foo" inside ~/.local/bin/evil-software (which is added to $PATH) that points to "fakehome".

"fakehome" is a simple wrapper script that, busybox-style, gets the binary name that it's being called as ("foo"), and then sets $HOME to be ~/.local/share/fakehome and calls the original foo binary.

Is this named after the one and only boxxy?!

No! I just thought it was a cute name ("put things in a box"), and it wasn't a common repo name on GitHub.

You might be surprised how many of us were obsessed with Boxxy lol.

YUP, she was the OG camgirl, sadly got all the worst parts of the gross attention / fame without any of the perks/money that Belle Delphine gets now

At least it seems she's doing okay. Money, fame and attention can ruin lives, especially if obtained at a young age.

Original!? JenniCam would like a word.

https://en.wikipedia.org/wiki/Jennifer_Ringley

I remember it quite well! Just not my particular cup of tea.

Glad someone still remembers the e-drama of yore. I wasn't obsessed with Boxxy, but that's a name that reminds me of the glory days of the internet.

I actually think it was just you obsessing over her unironically

https://www.youtube.com/watch?v=Yavx9yxTrsw

You have no idea how much of a thing this was?

People either loved her or got irrationally angry if she was ever brought up to the point of committing federal crimes

They're not the only one, I've never even heard of her before.

No surprises there, it's basically ancient history at this point at 15 years ago

AWS an interesting example considering it's also a default search path for the SDK so anything using an AWS SDK is going to check for ~/.aws/config; does boxxy apply the rules to anything run in a shell, or only if 'run by boxxy'?

Only in the latter case; I didn't want to assume how people want things done, and implicitly magical tools break more often than not in my experience.

You may also be able to tell I don't have a lot of AWS experience (:

Would be cool if there was a tool that could detect that configured path was attempted to be opened, and redirect the open() syscall to the real path... But that would most likely require kernel support.

Boxxy seems good enough for userspace.

I actually attempted using ptrace to rewrite syscalls first! It was... horribly painful, and didn't work anywhere near as well as the bind-mount version.

In the past I used something like inotab to use an inotify-based trigger to pipe data from SSH to a different system that didn't have any NAS or SAN support, it might also work to detect 'who' is touching any files that boxxy has previously seen rules for.

Perhaps still too tricky to make it do magic things and break programs in the process, but it could be used to audit who's working with what paths and let the user print a report so they know what apps to boxx up and make them behave.

That is an excellent idea! Something like could definitely be worth adding. It's why there's a "remount rootfs as ro" flag; that way anything not specified in rules is ro and misbehaving programs will explode.

Love exploding apps. That's what they get for eating my filesystem.

Fun fact, one layer of App Engine's sandbox from a couple years ago was implemented using ptrace. It will redirect filesystem IO to in-memory files.

Interesting! That makes perfect sense, I just don't think I'm smart enough to use ptrace properly right now :P

Were you mostly going off the ptrace man page? I tried reading it to figure out ptrace and it made me feel not smart enough too.

The man page + Google! There's very few good examples of it, and I've accepted that I'm just not familiar enough with that specific problem space.

Try checking out proot?

For a structured approach to ptrace/syscall rewriting, you could try FB's reverie. I worked on and used it during an internship a few years back; it's pretty amazing at what it does.

https://github.com/facebookexperimental/reverie

Lo and behold

http://ordiluc.net/fs/libetc/

I suppose that is indeed more trouble than it's worth. As for applications that might behave like AWS and their SDK; I think that if someone uses boxxy they would probably also remember to do the same thing for other stuff that uses aws under the hood, so overall a win either way!

If I were to try to do this without symlinks, maybe I'd try mount

This seems like a great idea, thank you for sharing.

Are you aware of any notable caveats to using Boxxy, given the mount-based implementation? E.g., will this continue to work if you sync ~/ with other machines (rsync, FTP, SyncThing)?

> This seems like a great idea, thank you for sharing.

Thanks :D

> Are you aware of any notable caveats to using Boxxy, given the mount-based implementation?

System configuration to allow mount namespaces, tools might have to understand recursive paths, it's tested for my use-cases.

> E.g., will this continue to work if you sync ~/ with other machines (rsync, FTP, SyncThing)?

I haven't tried it! Would love to see what happens as that's unfortunately not a use-case I have.

In my experience doing weird things with mountpoints, there is almost always some bug that happens on reboot of the system. For example, if your mounts aren't in /etc/fstab, they simply won't be restored. And if you have a script that sets them up manually, then make sure that script runs on boot after any mounts it implicitly depends on.

Also note that any scripts with config stored in these mountpoints (which seems to be the point of the tool) will not be able to run until the mountpoints are up. That seems like an obvious observation, but it's easy to fall into a trap where one of your scripts installed with this tool is called in a setup script that runs on boot of your machine.

Yes, absolutely! Good points to be aware of; I should find a way to add some warnings about this to the README.

(earlier less-relevant comment was deleted)

Yep, have an old Java application that wants to put calibration data for a vector network analyzer right in my home directory. This is a perfect tool.

Another solution might be to override the root user directory like:

_JAVA_OPTIONS="-Djava.util.prefs.userRoot=${XDG_CONFIG_HOME}/programName" programName

I remember when the GNUStep people thought their software was important enough to create `~/GNUStep`. Fucking maddening. Especially when one did not actually use GNUStep but some dependency.

There have been some bad ports of Windows games creating ~/My Documents lol. AFAIK there's also ~/snap. You'd think at least such non-hidden hardcoded directories would bother the developers themselves.

Oh, the logic behind the excused for ~/snap made me never want to use that program at all

I wonder if this could be used to move the obnoxious ~/snap directory.

I was wondering the same. So infuriatingly obnoxious!

Question is if those user/mount namespace tricks are composable

As far as I'm aware, yes! You should be able to nest namespaces and mounts.

While reading more about this I found out about the ~/.hidden file which I'm pretty excited about. The following hides the folder from Thunar & Dolphin (and presumably other file managers):

echo snap >> ~/.hidden

But sadly `ls ~` will still show it.

It looks like a useful project.

By the way, as for the original motivation:

> I recently had to use the AWS CLI. It wants to save data in ~/.aws, but I don't want it to just clutter up my $HOME however it wants. boxxy lets me force it to puts its data somewhere nice and proper.

- they could have used AWS_CONFIG_FILE and AWS_SHARED_CREDENTIALS_FILE.

TIL! Thanks :D

But you shouldn't have to — that's the point of the complaint. That's like saying that if your neighbor is dumping toxic waste in your yard, you can always ask them to stop. Sure, but maybe they just shouldn't do that in the first place.

Sure. But there will be many scenarios where you can't use boxxy.

It would be very nice to integrate it with Nix and make the hijacking automatic (perhaps with LD_LIBRARY_PATH).

I'd been meaning to make something like this for ages but never had the patience to figure out the namespace API, great work!

Thanks :D <3

> suggested usage

> alias aws="boxxy aws" (repeat for other tools)

If you could find a way to somehow intercept without requiring aliasing, this would be amazing.

Also, as it is, isn't it problematic that programs might call others (outside of your shell, not respecting its aliasing).

A neat semi-solution (still worse than transparent interception if somehow possible) would be to have a boxxy-run script sym-linkable from ~/whatever/bin/aws (say) that basically just executes `boxxy "$(basename "$0")"`. So you could just symlink the same script with the name of whatever command you wanted to 'boxx'.

I mean, you can just run "boxxy aws" if you don't want to make an alias. That's your solution for "intercept without requiring aliasing"

As the program intercepts file APIs for all processes launched under it, it should handle subprocesses just fine.

No I mean as in if I run foobar, which itself happens to call aws under the hood.

Now I need both boxxy foobar and boxxy aws configured for the same ~/.aws redirection.

Perhaps a better solution would have been not using the Linux namespaces but using LD_PRELOAD to preload a shared library to intercept all the FS-related API and normalize the path. Of course more complex and would only function for dynamically linked executables, but would have not required to launch the executable with a proxy and would also be more stable, not relying on not so stable features such as Linux namespaces.

> If you could find a way to somehow intercept without requiring aliasing, this would be amazing.

I figured out while testing that `boxxy sh` works as expected, so I would imagine you can wrap any shell in it since it’s just a mount namespace.

> Also, as it is, isn't it problematic that programs might call others (outside of your shell, not respecting its aliasing).

Nope! Any spawned processes live inside the same mount namespace and see the same pretend view of the world.

Can you use boxxy on itself if you dont want the config file at ~/.config/boxxy/boxxy.yaml ?

I would assume that it follows the XDG spec and that you can specify XDG_CONFIG_HOME to place the file somewhere else.

Chromium doesn't respect XDG config, it always creates ~/Downloads directory on startup. It was so annoying, I hope this tool helps me fix it.

AFAICS it does respect https://www.freedesktop.org/wiki/Software/xdg-user-dirs/.

I'm not using default settings, I changed XDG downloads setting in ~/.config/user-dirs.dirs.

Maybe change download location in chrome://settings/downloads to where you want?

I did. It still creates an empty ~/Downloads on each startup.

Update: the tool didn't help. It complains about being unable to run some SUID executable that Chromium calls. I'll have to keep removing the Downloads by hand then after each use of Chromium.

Isn't this what your `~/.config` directory is for? Is that where you'd expect it to try first?

Really interesting project for other use cases too btw.

It is, but I find many programs ignore ~/.config 3:

Does this use namespaces or chroot? The readme mentions namespaces (like Flatpak?), but https://github.com/queer/boxxy/blob/mistress/src/enclosure/m... seems to indicate it uses chroot.

It creates a new mount namespace, and bind-mounts your ENTIRE filesystem into it, before chrooting, so that it can optionally remount / as ro to prevent applications from writing outside of the desired directories. The namespace is to allow doing the bind mounts in the first place.

Is there an infinite recursion in /tmp? Do you use a bubblewrap-like pivot_root trick?

> Is there an infinite recursion in /tmp?

No! The directory in /tmp outside of the "box" is completely empty; the remount of / is only seen within the mount namespace.

This is very cool and would massively simplify how I build my dotfiles. Is there any way this could support macOS?

> Is there any way this could support macOS?

I don't use macOS often-enough to know for sure, but a quick search suggests that bind-mounts (or similar) are more complicated on macOS. Not against the idea tho!

Edit:

> and would massively simplify how I build my dotfiles.

I guess I should tell r/unixporn at some point, huh? (:

Can boxxy make use of rules with regex? If not, consider this a feature request.

It sadly can't. Regex paths are hard due to the way it's implemented; if it was intercepting syscalls via ptrace then regex would be a lot more viable, but since this is just a glorified collection of bind mounts in the end, I'm unsure how I'd implement that nicely...

Okay understood. Consider adding a way to query all files written by a boxed application. If it generated a config file based on this info that would be super useful. Thanks for considering!

Absolutely a good idea! I'll have to see what's doable.

Maybe I've misunderstood, but it seems like this would only help for files the program puts in places itself. Thus it wouldn't help with files placed by the installer would it?

It could, you would just have to then run the installer itself under boxxy and write the rules for it.

The package manager already installs the program into the right place.

Omg boxxy???

This is nice. This is why I like to use minimal distros like Alpine or Void, so I know where everything is on my system and have some control over it.

The biggest problem with getting programs to respect the XDG spec isn't getting programs to move their config file from $HOME/.myproj.yaml to $HOME/.config/myproj/config.yaml. It's getting projects not to store configuration and secrets in the same file.

So much for checking all of $HOME/.config into a Git repository.

Whats the difference between this and a chroot?

Instead of chrooting to somewhere else, replicating your filesystem, ..., this switches into a new mount namespace and uses bind mounts to shadow the files/directories that are intended to be redirected. This way your entire filesystem continues to be visible to the target application, and only the paths you want altered are altered.

Who knew that the phenomenon that launched 1000 Low Orbit Ion Canons would return to help with my Linux installs.

I was expecting LD_PRELOAD trickery.

This looks really convenient

but... if you use unprivileged user namespaces, tmux isn't a very good use, because then you can't use any suid programs like su, sudo, doas, pkexec, fusermount, mount (user), etc.

This is pretty cool! It's surprising to see the project be at version 0.2.5 when the first commit was _yesterday_ though. What's the reason behind cutting this many releases?

I cut releases as I find bugs and commit fixes.

If only files and directories starting with a dot were hidden from view

Amazing, I will use this for sure. My home directory is a mess.

nice idea but tmux may not be the right example for the readme example since tmux actually supports XDG and its config in ~/.config/tmux/tmux.conf

TIL! I guess I'll find a better example.

I humbly submit either bash, sh, or zsh --- they all put dotfiles in $HOME that you can't move (zsh technically /can/, but they're still dotfiles and you have to set them in ~/.zshenv). Very annoying IMO.

Course, might not work so well with the way boxxy is run ... unless you chsh to boxxy bash or something.

It's possible to set $ZDOTDIR in /etc/zsh/zshenv, I used to do it before switching to fish.

This person actually has a lot of interesting projects!

Aww, thank you!

This is neat!

What's so bad about symlinks though?

i was using a similar bind-mount trick as Boxxy for a good 6 months or so, and then reworked it to prefer symlinks a couple months ago. nearly everything behaves as you’d expect with symlinks if you’re just symlinking within ~, and it’s easier to tell what’s going on or debug stuff.

notably, at some point i decided to encrypt my valuables: password store, PII, etc, and have them unlocked on login via PAM. i also wanted these to be locked when i lock my session. if you have, say, a ~/private mountpoint with sensitive stuff, and then ~/.password-store (for your password manager) pointing somewhere into this store, 2 things can happen when you `umount ~/private`

1. if ~/.password-store was a bind mount over ~/private/, your decrypted passwords will still be accessible through ~/.password-store.

2. if ~/.password-store was a symlink into ~/private/, then your passwords aren’t accessible.

chances are you wanted (2), and it might be scary when you discover that’s not what you had, months after setting it up…

i’ve also had some nasty mount duplication, where some cron job bind-mounts the same thing every hour. turns out linux will happily let you create identical bind mounts as many times as you want, until `/proc/mounts` has 2000 entries and some O(n^2) behavior somewhere in systemd’s namespace setup makes `systemctl start foo` take 3 minutes before invoking any service code. that was a PITA to figure out. the worst thing that happens when you “mount” the same thing twice when using symlinks, on the other hand, is you get some very obvious nesting. so anyway, i’ve bit myself a few too many times. i’m very weary to reach for bind mounts anywhere symlinks can also do the job.

> have them unlocked on login via PAM

Could you please share a general outline for configuring something like this?

the Arch Wiki is gonna be your best bet here: https://wiki.archlinux.org/title/ECryptfs

if you can make a /etc/fstab entry for your filesystem, then you can configure pam_mount using the same options as the fstab entry and it should work.

for the actual encrypted filestore, i’m using gocryptfs. it’s a more actively developed alternative to eCryptfs: mostly a drop-in replacement. there’s a lot of options here: dm-crypt over a dedicated partition is probably what a cryptographer would recommend, everything else is making tradeoffs (e.g. leaking metadata like file size/directory entry count) for better UX elsewhere. read the wiki to pick the best for your needs :)

on the off-chance you’re using NixOS, i configure these parts here:

- https://git.uninsane.org/colin/nix-files/src/commit/bcfd8e17... - https://git.uninsane.org/colin/nix-files/src/commit/bcfd8e17...

> What's so bad about symlinks though?

I am not smart and will regularly forget the syntax to ln(1)

Easy solution for that is what I do, just cd to the directory you want the symlink placed in, and then create it with one path instead of two. No need to think about whether or not the order is correct. It's really obnoxious that Windows chose the opposite syntax. (Yes. I have an unnecessary number of junction points and hard links on my system. When I reinstall next, I'll have a bad time dealing with it)

`mklink [[/d] | [/h] | [/j]] <link> <target>` `ln [OPTION]... [-T] TARGET LINK_NAME`

This is awesome!! Good stuff

How does this differ from containers?

Interesting someone could downvote this question without at least giving a response.

*she, but thanks! (:

Ok, hi! My name is Boxxy...

That brings back memories... of an era of Internet that many here are probably too young to have experienced.

I wonder what the demographic for HN looks like. I never questioned how much younger the audience would be than me (and I definitely remember Boxxy and the related internet/4chan drama).

I'd think the demographics are more 30+ and thus do probably remember the 4chan stuff.

Yup, that was my assumption as well!

HN is predominately older millennials and genx. This site isn't really making waves among the "kids" and I doubt ever will unfortunately.

It's us taking this ship to its end. o7

I would like to see the ages and sign up numbers over the years.

I don't know if it's making waves among the zoomers, but there isn't yet an alternative for zoomers who've entered the tech workforce, is there?

All the techy ones are on discord nowadays, it's the modern IRC. My go and rust servers are packed with people half my age (late 30s).

YOU'S TROLLIN' I'S NOT TROLLIN I AM BOXXY YOU SEE ^_^

TROOOLUH TROOOLUH

uhmmm... uh....

TROOOLUH TROOOLUH

BEATLES

TROOOLUH TROOOLUG

he, like, remixed

buh buh buh BUUUUUHHHH

God, that title sent me down memory lane https://www.youtube.com/watch?v=6bMLrA_0O5I

and then that day when the stars aligned and Boxxy met the Overly Attached Girlfriend https://www.rouming.cz/archived/boxxy_overly_attached_girlfr...

my favorite Boxxy autotune remix is this one https://www.youtube.com/watch?v=7Q7cqT3BiOI

Boxxy and Laina? Might need to get that framed.

our screamo queen, glad to see this here

She's on regular TV now IIRC

my queen, i kneel.

Oh, god...I'm old now :(

Very glad I'm not the only one who thought of this :)

Hi my name is boxxy

Reply on news.ycombinator.com