
Dotfile madness - boreq
https://0x46.net/thoughts/2019/02/01/dotfile-madness/
======
nycticorax
To me, the real problem is not the dotfiles, but the regular (i.e. non-hidden)
files that applications surreptitiously create in my home folder. (Which the
author does mention as being particularly bad.) dotfiles in the home folder
are not a new thing on Linux (e.g. .bashrc, .profile, .emacs, etc.), even if
it would be better if more applications used the XDG folders. And if I don't
see them when I "ls", they don't bother me.

But nowadays, lots of applications seem to think it's OK to put _normal_ files
in my home folder without asking first. This is just outright barbarism. In
particular, Ubuntu now seems like it's all-in on snaps, and if you use snaps,
they create a non-hidden "snap" folder in the user's home folder. Madness! And
when people complain, the devs have the gall to suggest that this is all fine:

[https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053](https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053)

I like the idea of snap/flatpak in the abstract, but until they get their act
together, and stop creating non-hidden files in my home folder without asking
first, I am _never_ going to use snaps.

And of course, all this is on top of the new fashion for the OS to "helpfully"
create Documents, Music, Video, etc folders in my home folder, and set the XDG
environment variables to point to them. Noooooope.

But at least in that case the user can change the environment variables and
delete the stupid folders. No such luck with ~/snap.

~~~
ljm
This strongly reminds me of installing software on Windows, where most games
and programs would use My Documents as a dumping ground.

~~~
user5994461
It's fair to store documents and saved games in My Documents.

Much better than storing them in C:\Windows or C:\Program Files, as was the
case a decade ago, before windows introduced UAC and blocked write access to
these.

~~~
SpaceManiac
It's senseless to store files that don't have user-facing meaning in My
Documents. I know games that use it varyingly for web caches, shader caches,
binary config files, debug logs, Lua scripts, downloaded mods, and even
_executables_. And while arguably most gamers understand what save files _are_
, they can't be double-clicked to open them, so I don't consider them
_documents_ (Maybe this is pedantic).

All this kind of stuff is what Appdata\Roaming and Appdata\Local are supposed
to be for.

~~~
Dayshine
Save games is a poor example.

Users often need to back them up. Backup systems often include Documents by
default but not AppData.

Files in AppData are hidden, and you would not expect users to find them.

Further, many save games can be opened with a text editor just fine :)

~~~
ChrisSD
As noted below there's a special folder called "Saved Games" that's
specifically meant for this purpose. A lot of games still don't use it.

~~~
runxel
And here I am, still wanting my save files to reside next to the games exe...

~~~
ChrisSD
Fair enough but on multi-user systems you can surely see the value in separate
save game folders?

~~~
chii
when was the last time a gaming machine is a multi-user system?!

~~~
h1d
Since when every person in a house has their own gaming PC?

------
sakoht
The real problem is that any app I run accesss all files I own with equal
permissions. App1 and App2 shouldn’t write their data to my home, or read each
other’s data, or, please, be able to write each other’s data.

A video game can read my tax forms. WTF.

Mobile & tablet OSs solve this. Everything has to follow.

Until then, basically every app should run in a docker container. Then it can
do what it wants.

~~~
userbinator
_Mobile & tablet OSs solve this. Everything has to follow._

No no _no_ _NO!!!!_

Think of all the things you can't do on a mobile device that you can do on a
PC, or which require ridiculous workarounds like uploading from one app to
some server on the Internet and then downloading again into another.
Effortless data interchange is what makes computing great, and stops
proprietary walled-garden data-silos from becoming the norm.

~~~
jen729w
Agreed, and we’re now in serious danger of “Okay button fatigue” or whatever
you’d like to call it.

If every normal app has to ask for permission to use your disk, you’re just
going to click “Okay” when malware asks. Then the whole system was for naught.

~~~
AnIdiotOnTheNet
So just don't do that. The application needs an "Open" dialog already so you
can tell it what files to open, just have that dialog be a process run by the
system instead of the application, treat the permission as implicit since the
user is the one selecting the file, and pass a handle back to the application.

~~~
detaro
E.g. Flatpak has the concept of "Portals" for that:
[https://github.com/flatpak/flatpak/wiki/Portals](https://github.com/flatpak/flatpak/wiki/Portals)

------
saagarjha
One thing I’ve been thinking about is that it would be nice to tag files with
the program that created them. Aside from the clutter in my home directory, I
have a lot of files that I have to guess as to where they originated from
based on metadata like modification timestamps or permissions, but it would be
nice to see something like “~/.config was created by some-tool”.

~~~
nine_k
A general tagging mechanism, reasonably supported _across filesystems_ , would
be great to have. Not only for media collections.

It's not easy to implement nicely, though.

~~~
netsec_burn
Why wouldn't it to be easy to implement? You could probably make a global
LD_PRELOAD library that hooks into all open() CREAT calls and tags the inode's
xattr with the program that created the file. You could use an attribute like,
user.created_by.

~~~
cma
Programs can use programs like 'touch' to create the files so you'd have to
get meta into a chain of process ownership or something while exempting the
user's shell.

~~~
ksherlock
Have you seen actual programs (not shell scripts) that do that? I've heard of
code smells, but that's a programmer smell with there.

~~~
netsec_burn
I think touch is a generic example, but not a practical one. The idea is that
program A can launch program B, and you'd have to recursively search for the
parent. But it's not easy to find which parent is the true owner, maybe an
exception can be made for init but shells can't have that exception as they
are sometimes the owner.

------
gumby
The lack of useful names on the files is IMHO the most egregious issue. (OK
using names that don’t start with ‘.’ is worse). I don’t ls -A my homedir as
much, but what the hell are .517827.padl? Who created .android (I don’t use
android and don’t develop for it) etc.

These people are arrogant shitheads and I’d like to know who they are so I can
avoid their software. I assume if they do crap like this their software does
other nefarious things.

~~~
CGamesPlay
> These people are arrogant shitheads and I’d like to know who they are so I
> can avoid their software.

Wow, this is really assuming the worst in people. It’s much more likely to be
ignorance because the other developer doesn’t know where the file came from
either (some compiler flag on a library accidentally enabled), or also doesn’t
ls -a in their home.

~~~
gumby
> Wow, this is really assuming the worst in people.

Yes, I am. I'm fed up with programs that spam my system without asking:
install plug ins, menu items, directories on the desktop, dock items etc for
"convenience" \-- it's convenient for them, not me. It's especially painful
when I _pay_ for an app and it sprays shrapnel through my filesystem.

> It’s much more likely to be ignorance

Indeed, but if they can't be bothered to learn basic system hygiene how can I
be confident the rest of their package is safe to use?

A big driver for sandbox/containers in user systems is not protection against
malign actors per se but against the lazy and ignorant.

Have I written bugs into code? Of course I have, I'm human. But at least I
_try_ to get things right up front; to be a good citizen.

(there are additional reasons for containers in server systems, hence my
qualification of "user systems" above).

------
charlesdaniels
A lot of other people have made some fantastic points here, so I won't harp on
"putting random crap in ~/ bad!" any further.

However, since it has not been mentioned, I would like to shout out to the
Python "appdirs" module[1], which neatly solves this issue for those writing
programs in Python with minimal effort. The best part is that it uses the
platform's native standards, so XDG on Linux, plus whatever macOS and Windows
call their implementations.

Sadly I am not aware of comparable options for other programming languages. I
think having high-quality easy to use libraries for this sort of thing would
go a long way.

1 - [https://pypi.org/project/appdirs/](https://pypi.org/project/appdirs/)

~~~
int_19h
In C# and other .NET languages, you'd use this:

[https://developers.redhat.com/blog/2018/11/07/dotnet-
special...](https://developers.redhat.com/blog/2018/11/07/dotnet-special-
folder-api-linux/)

Many of these are named Windows-centric because of the history of the API. But
where possible, they still map to something reasonable elsewhere. Looking at
the mapping table, I can't think of anything it doesn't cover.

------
chrisweekly
Related pet peeve: macOs '.DS_Store' files. Can someone better-informed than
me please explain how to prevent heir creation? Barring that, I'd settle for a
justification.

~~~
zackmorris
They're a bug/feature from the early days of OS X. Apple should have done the
work of storing directory metadata in something like
~/Library/Preferences/com.apple.finder.plist but they were too busy getting
anything at all to work.

This is the type of low hanging fruit that Apple evidently doesn't care about
anymore, but would go really far towards improving user sanity. It's like when
you go to a restaurant and order the cheapest thing on the menu as a way to
gauge the overall quality of the food there.

~~~
asveikau
Leaving it next to the files means if directories are moved, copied, or
renamed, the metadata is still there. So you or I might prefer it to live in a
separate file under ~/ but I cannot say littering the whole tree with the
metadata buys nothing or can't serve a purpose.

~~~
zackmorris
macOS knows when files and directories are moved via inodes:

[https://eclecticlight.co/2018/03/03/how-macos-tracks-your-
fi...](https://eclecticlight.co/2018/03/03/how-macos-tracks-your-files-inside-
the-inode/)

so I can't see any conceptual reason to keep .DS_Store.

~~~
zapzupnz
Because macOS doesn't know when files and directories are moved _on other
devices, network drives_ , etc.

Nor can it preserve that metadata across other devices, network drives, etc.
without copying it across somehow; the easiest solution was to store that data
in hidden files and let Finder handle their automatic transfer.

Failure of your imagination isn't failure on someone else's part.

~~~
zackmorris
Hmmm this is the first good argument I've heard for the existence of .DS_Store
files. You get a point :-)

I'd be curious to test this, by zipping folders, copying them to other
machines, etc. My gut feeling is that Apple probably missed something and it
doesn't quite preserve the metadata like it should (most likely due to version
incompatibilities or duplication of state somewhere else in the OS that
overrides it). I'd be pleasantly surprised if it did work though.

It brings up another point however, that probably metadata is as important as
data (and sometimes more important, if you look at how we organize data
today). The earliest filesystems probably should have implemented
multidimensional storage somehow, similar to the metadata in the BeOS
filesystem. I'm not familiar with how it's implemented, and it probably also
breaks when files are copied to another filesystem, unfortunately:

[https://news.ycombinator.com/item?id=12309686](https://news.ycombinator.com/item?id=12309686)

------
TheRealPomax
This kind of just sounds like more standard crazy unix/linux "someone did the
wrong thing and now everyone's doing the wrong thing and it's too late to
realistically fix", for which it's easier to just come up with another
subversion ( _waves at the three different 'user' solutions_) like not just
building a user home dir, but creating a dir inside that the user's usename as
well, so that ~ is for all the bullshit dotfiles and ~/yourusername is
actually your data. And then someone will no doubt come up with an alias that
takes you to that dir instead of just the original homedir, like "cd `"
instead of "cd ~" (and no, ~ doesn't make any more sense than ` would, it's
just what we got used to)

------
ryandrake
This is a symptom of a bigger problem, which is that programmer respect for
resources that belong to the user is at an all-time low.

* CPU: We'll just have this web page peg the user's CPU running gobs of code because our designer wants to unnecessarily animate this thinggy or our ad network wants to mine bitcoins. (Related resource: Mobile phone battery)

* Memory: We'll just use this web framework and embedded browser that uses up 1GB of the user's RAM, for a one-window chat application we're writing because we can't be bothered to learn anything but Javascript.

* Disk/Storage: We'll just cache 20GB of easily-regeneratable internal data so the app seems faster than it is, dumping it somewhere for the user to find and clean up.

* Network Bandwidth: Our shopping cart web page load is larger than the full installation of a 2000-era video game because we have to have 6 layers of framework abstraction and taking the time to optimize/minimize it wouldn't let us release fast and "crush it" in the market!

Nobody seems to care. "Oh, Xyz is cheap, programmer time is expensive!" is the
rallying cry. So let's push the cost our shitty practices to the user and make
her buy more hardware.

------
jecxjo
Oddly I feel completely the opposite about this topic. I think dot files in
your home directory are exactly the way to go. Using the XDG standard leaves
you with whatever the distro decides is the correct location for these files.
While their recommendation is all in the home directory, I wouldn't put it
past some of these distro developers to make some crazy
/var/users/{uid}/config directory. This is important when setting up your
partitions. I keep home and the system separate so that I can easily swap out
the OS. Home should be the only location a user has write access.

~~~
jarcane
Yeah, when I got to this:

 _To those of you reading this: I beg you. Avoid creating files or directories
of any kind in your user 's $HOME directory in order to store your
configuration or data._

My immediate response was pretty much "where the hell else should they put
them then?"

What exactly else is the /home dir even _for_ otherwise?

The purpose of home is for user-level persistent files. Giving it access to
something else means giving random programs write access to some global part
of the file tree, and I'd rather not allow that except when actually
necessary. As it is I hate having stuff that manual installs in /opt, or the
way too many programs on Ubuntu are configured to require sudo to work.

I'm actually totally on board with more stuff that installs entirely local
only, especially if it's from outside the distro's package system. I don't
like stuff mangling the global tree with no clear standardized path for
removal and uninstallation. At least if it's in /home, I can just delete it
myself without even needing to go sudo.

And the purpose of .dotfiles in /home is because it prevents those user
configuration files and other such local data from cluttering your directory
when doing a plain ls for regular user files.

This article just sounds like a misunderstanding of how the file tree is even
supposed to work.

~~~
nickjj
> My immediate response was pretty much "where the hell else should they put
> them then?"

He didn't mean to avoid $HOME as a whole. Just the root of the $HOME
directory.

I too much prefer having programs write their config files to
$HOME/.config/program-name instead of $HOME because it's less clutter and now
I can think "ok, $HOME/.config is where all of my app's configuration is",
instead of having a bunch of files littered in $HOME while other apps use
$HOME/.config/file_name or $HOME/.app_name.

It bothers me that .pypirc exists in $HOME, rubygems credentials are in
$HOME/.gem/credentials and Docker's credentials are in
$HOME/.docker/config.json. That's 3 different location styles for an app's
config file. They should all be in $HOME/.config/$app_name/relevant_file_name
for whatever the config is for.

------
aerovistae
I have long deplored the sheer amount of config files that clutter the top
level of any project nowadays. .gitignore, package.json, webpack.config.js,
babelrc, travis.yml, it’s endless. This very short list is really the tip of
the iceberg. These things need to be in a dedicated config folder.

It’s so nice to see this article at the top of HN. I had long thought I was
the only one who felt this way.

------
Jaruzel
This isn't just a Linux problem. In Windows, the users /documents folder is
polluted in exactly the same way these days.

~~~
franky47
Also on macOS, where [~]/Library/ApplicationSupport is the designed and
recommended place to store config files, logs, preferences and all kinds of
persistent data, the home directory still gets cluttered.

It's a laziness issue, it won't be solved solely by making is easier to access
the right locations on each system/platform, but that would be a step in the
right direction.

~~~
afiori
I would honestly like to blacklist my home folder. Do you want to create a new
file/folder? I am notified with a popup and if you ask to often I am gonna
stop using that. Not really workable but one can still dream...

~~~
gh02t
This is actually possible (on Linux, at least, probably Mac/Windows too) with
something like selinux. It ends up being a huge headache though, both because
selinux is kinda hard to configure, and because you will get a constant
barrage of requests.

~~~
giornogiovanna
That sounds pretty funny, it reminds me of
[UAP]([https://blog.codinghorror.com/windows-vista-security-
through...](https://blog.codinghorror.com/windows-vista-security-through-
endless-warning-dialogs/)).

------
kardos
It seems to me that distros are in the right position to nudge this in the
right direction. For example, Fedora did the /usr merge, moved to systemd,
wayland, etc. The great dotfile cleanup would probably work by patching all
packaged software to do config files the right way, plus sending the patches
upstream. Then in a few release cycles this would be more or less solved.

------
Epskampie
On the one hand this is annoying, on the other it’s great that you can just
backup your home dir and have all your files and settings in one go.

Also this annoyance is easy to solve, just make one dir in home (my is called
after my name) and put all your own files in there.

~~~
s3m4j
So you're running everything under `/home/Epskampie/Epskampie` ?

~~~
edoceo
It's /home/Epskampie/.home

------
darkpuma
Slight tangent, but I wish there was a standardized way to tell running
processes to re-read their dotfiles.

If I change my .zshrc, I have to re-source it in each running instance of zsh.
Sure, I could automate this. But I'd also like the same done in vim. And in
weechat. And in mpv. And in everything using GNU Readline... you get the
picture.

This is probably at the top of my list _" biggest complaints that won't be
resolved for numerous reasons."_ It sure would be nice though.

~~~
ethelward
Some programs (I can think of Termite and Kitty) use the USR1 signal to this
end.

~~~
pseudalopex
Be careful. Some programs terminate when sent USR1.

------
bauerd
I don't get the problem. Why bother where dotfiles are written to? GUI file
managers and userland tools hide them by default. What would I gain by having
them written outside of $HOME?

~~~
sowbug
It avoids the realization that you have been paying AWS to back up ~/.cache
and ~/.local for the last 6 months.

~~~
int_19h
The whole point of .cache is that it's supposed to be that one folder that you
know you shouldn't back up. As opposed to a dozen different app-specific ones
that we have today.

~~~
sowbug
Yes, it's a great idea in principle -- and would be even better if its
location were configurable, per the XDG spec.

My comment wasn't meant as a criticism of the basic idea of a standard
directory scheme; it was a reply to someone asking why anyone would ever care
about files you can't see.

------
rb808
I think it makes a lot of sense to have all apps run in a sandbox or container
by default. Everything is segregated and easy to monitor and track what its
doing.

~~~
johnchristopher
Was thinking about that when tinkering with docker: why are volumes created
outside the user's home directory by default ?

~~~
diegoperini
On my fedora ec2 created with a standard ami, docker doesn't work without sudo
(didn't try to reconfigure, so it may if I hack), so that behavior is
understandable, though not desirable.

~~~
johnchristopher
Did you add your user to the docker group ?

~~~
diegoperini
Nope, just installed and started to use.

------
eeeeeeeeeeeee
I definitely have looked at my home directory in awe at the number of dot
files, but I think the article is a bit hyperbolic. I get that it's "clutter"
but I think the simplicity of storing configuration in $HOME might be worth
that trade-off.

Even the $XDG_ env variables still require the user to set that up, or the OS
maintainer needs to set it up. If the OS maintainer sets it up, the user
probably won't know where to find configuration.

The reason $HOME is so commonly used is because the developer knows with
almost 100% certainty that the unprivileged user will 1) be able to read/write
to it without superuser privileges and 2) it keeps all configuration data
contained in the user's home directory for portability, instead of throwing it
all over the file system in locations nobody will know.

That portability will come in handy when you're backing up or restoring from
backups, which I just did yesterday. It means restoring is as simple as
copying your entire home directory back. I don't need to tell each app where
my configuration is, it just knows it will be in $HOME.

And that assumption will be correct for almost any *NIX-based operating
system.

I do agree that non-dotfiles should not be created in $HOME, that is a
nuisance.

~~~
eletious
You missed the point - they default to a dotfolder where all of those dotfiles
go. You likely already have one!

The default is there to allow users and OS maintainers to not worry about it.
It still goes in your home directory, but at least it's organised.

------
Waterluvian
.files are very useful. I like the consistent idiom for where your "global"
settings go for virtualenv, npm, tslint, flake8, git, whatever.

But it would have been so nice just to move it into a ~/cfgs or fine... even a
~/.cfgs or whatever.

I'm guessing engineers went, "ewww, I'd have to walk down the tree to find the
next most relevant config file to use and then go UP into a directory when I
hit home."

~~~
toflon
Most of what I use supports the XDG ~/.config directory, which is nice. But
there's still some that doesn't support it.

[https://wiki.archlinux.org/index.php/XDG_Base_Directory#Hard...](https://wiki.archlinux.org/index.php/XDG_Base_Directory#Hardcoded)

------
krschultz
I appreciate that this article doesn't just end with the complaint but follows
through on a recommendation on how to do handle this correctly.

------
howard941
I tend to carry $HOME around with me when I change systems. When I ls -Alr it
was like opening up a time capsule, or a hope chest. The first 4 pages on a 23
line terminal had file and directory names for content old enough to buy
liquor in all 50 states, old friends like .cshrc, .addressbook, .X11Startup,
.nofinger, amd.home, .zirconrc, dot.signature, aub.home, and so on.

------
xaduha
> We are no longer in control of our home directories.

I can axe my home folder and rebuild it with `nixos-rebuild switch`, it's
pretty minimal.

~~~
seqizz
Do you mean `home-manager switch` or is there a feature in nixos to touch home
folders?

~~~
xaduha
I just keep my home folder in /etc/username and use this construct:

(just an example, not actual)

environment.etc = {

    
    
        "qemu/bridge.conf".text = ''allow br0'';
    
        "username/.inputrc".text = ''
          \$include /etc/inputrc
          "\e[A": history-search-backward
          "\e[B": history-search-forward
          set show-all-if-ambiguous on
          set completion-ignore-case on
        '';
    

};

to write configs into /etc proper and my home folder.

~~~
seqizz
Hmm that's way radical than I thought. If I understand correctly, this is a
read-only home folder. Would be interesting to use, I'll give it a try.

~~~
xaduha
It's not read-only, but you need to reset the rights on it if you delete and
rebuild it (chown probably can be put here
[https://nixos.org/nixos/options.html#activationscripts](https://nixos.org/nixos/options.html#activationscripts))

I haven't used home-manager, but it looks like a bloated thing that I don't
need in my life.

------
toss1
Indeed!!

Some of us would like to manage our systems, and processes like backups,
transfer to a new system, etc., in something resembling an orderly process.

The very concept that architects, designers, &/or programmers think it's OK to
just litter our systems with their stuff wherever happens to be convenient to
them to code up this afternoon is no better than people just deciding to crap
wherever they feel. When I see software doing this, I automatically downgrade
them in my assessment of what I want to use going forward.

The simple concept is that there are a few categories of storage used -- these
should each be kept separate & independent, under the USER's control.

Why is this a difficult concept?

Program code, system-config, per-user-config, user data. A simple table of the
default and user-overridden location for each.

If you as a coder have a problem with this, I really have to wonder what other
complexity you will handle badly.

If this simple system is a mess, why would I expect other parts of your system
to be any good?

------
AnonymousRider
I agree. If I hit ‘Ctrl-H’ my lovely, clean Nautilus File Manager becomes a
heinous, ugly clutter which is impossible to navigate. I’ve tried to delete
some or move others to no avail. Please follow this standard. It’s clean,
organized, and beautiful. Once done, we can then tackle the next problem (I’m
looking at you & Snaps Shuttleworth!).

------
rnhmjoj
I have been fighting this but I gave up: people just don't care or are
somewhat opposed, even when presented with a backword compatible patch.

Now I just mount the home directory with rewritefs and try make the mess more
or less compliant to the spec. It's not ideal: it's a hack and it causes a
performance hit but I can be at peace in my ~.

~~~
orangeshark
What were some of the reasons people opposed it?

~~~
rnhmjoj
Mainly increasing the complexity: it usually requires moving the files to
three different locations and handling the migration from the old location.

------
frankz00
I think this is a silly complaint. These are preferences storage. The home
directory is absolutely the most logical place for these.

I actually like that there are applications that actually still have
preferences. My biggest pet peeves are applications WITHOUT preferences.
Careful what you wish for.

~~~
pi-maker
I agree that the home directory is the most logical place for files like
these, but it would still be nice if they were in a consistent place. That
way, if you wanted to delete your preferences for a specific application, you
know exactly where to go without searching around. Personally, I think this
should be enforced by the operating system instead of leaving it up to the
developers.

------
abathur
I have a short, related tale.

In a long battle to be more intentional about what I keep around, I wanted ~/
to function both as my desktop and downloads directory, on both macOS and
nixos. Using it like this would force me to deal with cruft quickly, and avoid
crap silently piling up out of sight until its origin is forgotten (though
desktops will hide the .dotfiles; those could still accumulate unnoticed).

It was easy to set this up on nixos, but I found the handful of apps dropping
non-hidden files there grating. Magic folder behavior on macOS didn't work as
well with this.

I ended up replacing ~/Desktop and ~/Documents with links to ~/Downloads. The
naming isn't sensible, but I'm happy with how this works on both systems so
far.

------
drivingmenuts
All of this is a leftover from the days when *nix was a multiuser OS and used
as such. It completely ignores the way we use machines now, with only one
owner, and expectations of only one user. In fact, I can’t imagine loaning my
work laptop to anyone, for security reasons, nor my personal laptop, because
that’s just gross AND a security violation.

Computing power is so cheap now, that we don’t need to share machines when
working in the cloud, either. We can, and do, log into our own VMs, work on
data and software and commit back to an intermediary before final merge into a
shared repository.

Perhaps it’s time to return to some version of single user OSes and clean up
the relics left behind by no-loner-needed multiuser environments.

------
jesseschalken
You're never going to be able to stop developers dumping their shit in ~/. The
best you can do is create your own directory like ~/Data to put your stuff in.
Since programs don't already know about it, it will stay clean.

------
michaelcampbell
> Avoid creating files or directories of any kind in your user's $HOME
> directory in order to store your configuration or data. This practice is
> bizarre at best

I believe the article itself is an existence proof that it is in fact, not
bizarre.

------
20190202
Crazy idea: what if we were to just nest a personal directory within ~?

i.e., New standard directory `~/personal`, new environment variable,
$PERSONAL.

If we could come up with a default `~` like character for globbing to
`$PERSONAL` like `~` does to `$HOME`, say, `@` (obviously that isn't the char
to go with and I'm not a BASH expert to be able to pick one not already
occupied). All your personal dotfiles are in `~`, all your personal files are
in `@`. Default `cd` without args to `$PERSONAL`. No worries about tons of
files that are in `~` because you live in `@`.

~~~
katbyte
I already kinda do this, ~/company for work, ~/kt for personal, and a bash
scrip it’s alias’ and vars to make it easy

------
rkagerer
Same mess on Windows with the My Documents folder. I simply abandoned it,
treating the folder as "My Spam From App Programmers", and keep the meaningful
stuff in a totally different place.

------
quotemstr
I have the opposite perspective. Dotfiles are fine, and I find the
proliferation of XDG directories confusing, mostly because they're misused.
Why should a game's save files be under .config? Making dotfiles under $HOME
is a simple approach that's worked for a long time and that doesn't cause
serious problems, and I see no need to adopt the XDG approach, which I see as
overengineered.

~~~
yesco
> I find the proliferation of XDG directories confusing, mostly because
> they're misused. Why should a game's save files be under .config?

A game's save should be $XDG_DATA_HOME, misuse is exactly that, misuse. I have
hundreds of games installed on my linux machine and not a single one has put
it's save files into my $XDG_CONFIG_HOME folder. On the other hand many DO
outright ignore XDG and dump all their garbage into .game_name/.dev_name
folders (looking at you Factorio). I think you are exaggerating the issue.

> Making dotfiles under $HOME is a simple approach that's worked for a long
> time and that doesn't cause serious problems, and I see no need to adopt the
> XDG approach, which I see as overengineered.

What exactly is over engineered here? It's just a set of environmental
variables, developers ALREADY use $HOME to spam up my home directory. The only
real effort a developer needs to put into this is making sure they separate
their config, data and cache folders which is something most already do within
their cute .program_name folders.

while maybe not "serious" I certainly do find it do be quite the problem that
all user-specific program data is randomly dumped into poorly named hidden
folders within my home directory. *Nix systems at a root level already divide
config files into /etc, cached files into /var and /tmp, and data files into
/usr. Why can't there be at least a little symmetry with how the home folder
is handled?

~~~
quotemstr
The XDG approach _is_ over-engineered: it adds complexity and provides no
benefit. What is the specific concrete advantage of putting some parts of
foo's state in ~/.config/foo, some in ~/.local, and so on? All this approach
does is scatter what's conceptually a single state blob across different parts
of the filesystem. I dealt with this stuff in Windows for years, and we don't
need it in the Unix world.

The conventional dotfile approach is just fine: there's an application and it
puts state under a directory named after itself.

~~~
pseudalopex
XDG just extends the traditional Unix approach to home directories.

$XDG_CONFIG_HOME is equivalent to /etc. It has small files you probably want
to back up.

$XDG_DATA_HOME is equivalent to /var. It has potentially large files you might
want to back up.

$XDG_CACHE_HOME is equivalent to /var/cache. It has potentially large files
you probably don't want to back up. You can delete them if you need space.

------
crooked-v
I just published an NPM package to help deal with this kind of thing for
Electron apps and the like:
[https://www.npmjs.com/package/basedirs](https://www.npmjs.com/package/basedirs)

Warning, its Windows support is all theorycraft so far (Travis CI + Windows is
totally broken for Node projects right now). PRs welcome if anyone wants to
give it a try.

------
macjohnmcc
I'll take dotfile madness over registry madness. I have been trying to figure
out where in the registry Visual Studio 2015 puts its install location so I
can remove that registry value when I reinstall it to put it in it's default
location. So far I've wasted a ton of time trying to accomplish this. A single
file .VS2015 would be preferable.

~~~
lphnull
There is a program for windows that does this if I recall correctly. It
records every file and registry entry created during installation and allows
you to compare snapshots of "before" and "after" installation.

~~~
macjohnmcc
I recorded the installation of VS2015 and it was a shocking number of files
and registry values. 10's of thousands of each!

------
Crontab
I personally detest the whole XDG thing but lots of non-XDG applications are
guilty of littering the home directory. For example, every time I use the Less
pager, it creates a .lesshst file (fixable by setting "LESSHISTFILE" to "-").
Vim creates .viminfo files so I had to create an alias to it where vim equals
"vim -i NONE".

------
geggam
This is not a problem. This is the design.

It makes things completely controllable and you know where to look for
configuration files.

~~~
reaperducer
If it was completely controllable, I’d have the ability to control where they
are and put them out of my way. Lazy programmers use home as a default.

Home directories have become the *nix version of the Windows Registry.

~~~
geggam
Very likely you do have the control. You simply haven't taken the time to
learn how to configure things.

~~~
reaperducer
Or not likely at all, since the whole point of TFA is that many popular
programs do not follow specifications and user configuration.

------
pointytrees
I prefer to use `ls -lah` which always shows the dot files. It sure would be
nice if these were placed in a different folder. Maybe ~/.../ to put all the
things. Sure, cat ~/.bash_history would need to be cat ~/.../.bash_history
which isn't as convenient.

But, I sure do agree with the frustration. My work machine has nearly a
hundred hidden things. My Chrome usually downloads things to ~/Downloads/ but
Firefox often likes to store the file in ~ which then is often hard to find
when I jump over to a console.

I've made an effort to clean things up. Trying to set firefox to download to
the Downloads folder, deleting everything personal out of the home folder.
But, of course, then that just goes to prove that I do not have control of my
~ folder. I'm doing everything I can to keep my own stuff out of it. Which is
sad.

------
kevinpet
To me, there's a big difference between:

If you want to override the defaults of this command line program, create a
.programrc file in your home directory.

and

Thanks for trying out this program, I'll just create a whole directory
structure of config files and caches in your home directory.

------
tomxor
I realised that keeping a clean user home directory was futile long ago...
this is not even unique to linux or *nix.

Just don't put anything you care about in home directories: in the modern
world people own computers not user accounts, you likely have ultimate control
over your system, therefore designate your own "home" directory, don't give
the other "developers" the choice to polute it by making it non-standard.

I like to be able to nuke my user-home directory whenever I like, I achieve
this without pain by additionally placing my hand picked application
configurations that I care about into a read only XDG config directory.

------
palotasb
That's why I never use $HOME for personal files. All of _my_ files are in the
Dropbox folder or another custom folder on my work PC. It's nonstandard, so no
one litters in it besides me.

~~~
vandorjw
I do something similar, everything I want to keep is under /storage.

------
bigbugbag
I have abandoned my home directory to this madness. I have a home sub folder
where my actual home lives allowing for portability.

This trend is killing the usefulness and practical aspects of having a home
folder.

------
Tucanix
I create a "Library" directory on my machines because of this, it's not a
great fix at all but it makes it a little more sane.

With this I can also more easily sync my files across machines.

------
upofadown
Yeah, great, rather than just going to the .foo directory for the foo program
to find user specific state for that program I have to first figure out where
the particular distribution likes to put things by default and then hunt
through something like 5 different hierarchies for the foo directory.

The "old" way forced program developers to put things in a very specific
place. The new way allows then to interpret the XDG standard however they want
and scatter everything all over the place.

------
avip
node_modules and yarn.lock etc. in the location where the tool was run is a
feature, not a bug. Ask any python user digging to find where pip decided to
drop it this time.

~~~
godot
I was going to say, I've been actively working with nodejs for a few years and
I've never had node_modules, package-lock.json and yarn.lock in my home dir,
on either Linux or macOS. If you run npm/yarn commands in your home dir for
some reasons, then you should expect those files there. On the less than
handful of times where I ran npm in my home dir accidentally, I make sure to
immediately go and delete those files.

It's also possible that the author runs a lot of scripts from various projects
from github and sometimes those scripts' authors are not careful about running
npm/yarn within their projects. I guess I don't play around with OSS enough.
:)

~~~
eeeeeeeeeeeee
I think most of that can be chalked up to someone simply mistakenly running
those commands in the wrong directory (root of $HOME). I've never heard of a
JS app just randomly storing a global node_modules or yarn.lock to the root of
$HOME.

------
eithed
On Windows I've never put anything in C:/, yet I have a shitload of
install.res.xxxx.dll files, shitload of eula.xxxx.txt files, globdata.ini,
vcredist.bmp, install.ini, VC_RED.msi. In my home folder I've
.QtWebEngineProcess folder (never installed qt), .mongorc.js (which is empty),
.v8flags.xxxx.json, .dbshell, and so on and so on. I'm not delving into
insanity which is /Program Data, Windows/Temp, or [user]/AppData

------
mcnichol
Gonna say I expect to see the dot files and don't really care.

I think to be upset over that is just looking for a fight.

It works across all of my OS's, I know its config specific to the app, and if
I want to jump in and get some info it is just a ~/ away...the overhead is so
low I've spent more time thinking about it in this statement vs all the time
ever wrestling through them or battling tribal knowledge.

I guess I just don't see a strong enough argument here.

------
sneak
Would exporting HOME to something else (eg the xdg root/appname) prior to
invoking programs solve this problem for most apps without code changes?

~~~
pseudalopex
XDG has different roots for configuration, cache, and data files.

------
zapzupnz
And to Linux developers who've made the jump to macOS development or are
making a cross-platform port, __please __use NSFileManager to find the paths
for this or that, don 't hardcode everything into Library/Application Support.
Not only that, but a lot of stuff ported from Linux could stand to put things
in .app bundles rather than _every bloody where_.

------
durbatuluk
TIL I'm using ~ in the wrong way. For me ~ was always the default place for
user-level configurations and time taught me to do so: .X* .bash* .vimrc and
others.

Than I create my personal folders ~/{src, docs, bin, porn, anime etc}. ~ is
for temporary files I'll delete after use like windows users do with their
Desktop folder.

Also my ls isn't an alias with -a flag...I'm alone here? :|

~~~
rovr138
I think an issue I have with it is if I want to move the configuration to
another place, the only way I can do it is via a symlink. If applications used
the variables above, you would be able to easily organize things differently
if you choose to.

This would also allow you to test if something there is causing issues or if
you wanted to format and reset things. Just delete that directory or set the
variable to another path.

I don’t set ls to ls -a, but sometimes I create hidden folders and files on ~/
so it’s not distracting. Scanning through a lot of things because everything
is dumped there is a mess.

~~~
durbatuluk
Indeed, without env. var we are stuck with ~ "madness"

------
grok2
Not sure what the problem is -- dotfiles or other application files need to be
somewhere, whether in the home directory or somewhere else (that the OS
doesn't enforce but just requires by convention) makes no difference. What
would really help is what another comment mentioned -- the ability to tell
which modules owns a particular file -- that would be really cool.

------
angusp
One of the advantages, though, is per-user config for the same program, e.g.
the .bash files. It's pretty common to have separate /home and / partitions
too, and less common but doable to dual-boot different distros but share the
same /home partition. Which is itself actually a reason to be very careful
with back-compatability of dotfiles

------
spacesuitman2
If only everyone would just put it in the `.config` dir and be done with it.
Predictable. Simple. And without shrapnel in home.

------
h1d
Homebrew just started offering Linux support but they would put stuff under
/home/linuxbrew/ but wtf is this about? Won't be using until this is fixed.

[https://docs.brew.sh/Linuxbrew](https://docs.brew.sh/Linuxbrew)

~~~
saagarjha
I haven't used Linuxbrew, but Homebrew is kind of finicky if you try to
install anything to a non-standard folder. I remember a while back they used
to say "you can change the default folder" but then later said that this was
not recommended.

~~~
eeeeeeeeeeeee
Yep, I tried to run mine in ~/.homebrew but gave up. I can't remember why, but
stuff was breaking and it was clear Homebrew didn't want you to do it.

I've spent some of my career building packages from source and I know the
assumptions you get stuck with because the app developer hard-codes certain
things. So it makes sense they just go for what is most standard and expected.

------
actionowl
The "Serverless Framework" modified my .bashrc and for that they will never be
forgiven.

------
CivBase
The title seems misleading. The problem here isn't dotfiles. The problem is
that developers are using $HOME instead of a standard directory for storing
user-level config files. I had never even heard of $XDG_DATA_HOME before
reading this article.

------
oh5nxo
~/etc would have been so nice.

~~~
nine_k
Aka ~/.config.

~~~
afiori
maybe ~/etc would have sounded more "cool"

------
Skunkleton
Why should non-desktop applications follow the XDG standard? Even for
applications designed for "desktop" use, the standard is questionable IMO.
After all, the "Desktop" folder that OP is complaining about is an XDG
recommendation.

------
qwerty456127
Why do we even need hidden files? Why not just put all the configuration
files/directories under a single directory specifically dedicated for this and
use file system attributes for all the directory-local metadata?

------
j16sdiz
My program is not X-based, it is not designed for Desktop. Why should XDG
apply ?

------
jxramos
Wow I though this was going to be about graphing dot files and I was like what
could this madness possibly be about. But hidden dot files, eg “.fileXYX” is
spot on in the problems of their proliferation.

------
akerro
So, what's gonna happen on Wayland when these X-variables aren't defined? Am I
going to lose config and have to copy directories from XDG to .config/ because
that's new default?

~~~
yakubin
By "X-variables" you mean $XDG_CONFIG_DIRS, $XDG_DATA_DIRS etc.? They aren't
related to the X server. The "XDG" is for the old name of the Freedesktop.org
project (X Desktop Group) [1]. Freedesktop.org is the host for the XDG Base
Directory Specification [2]. Apart from that they are also involved in
Wayland. So I see no reason for worry.

[1]
[https://en.wikipedia.org/wiki/Freedesktop.org](https://en.wikipedia.org/wiki/Freedesktop.org)

[2] [https://specifications.freedesktop.org/basedir-
spec/basedir-...](https://specifications.freedesktop.org/basedir-spec/basedir-
spec-latest.html)

------
minitech
> It is beyond me why my home directory ended up up containing a node_modules
> directory, package-lock.json, a yarn.lock file (I have never even
> consciously used yarn!),

Sounds like there’s a bigger problem.

------
miguelmota
What's the equivalent of $XDG_CONFIG_DIRS for macOS and Windows?

~~~
pseudalopex
macOS has Application Support, Caches, and Preferences folders under
/System/Library, /Library, and ~/Library. Windows has %ProgramData%,
%AppData%, and %LocalAppData%.

------
basicplus2
I create my own "home" area so nothing messes with it.. only my stuff resides
there as no program knows where it is

------
dkarl
This smacks of somebody looking for a problem. If it's not a problem when you
don't look, and you have to go out of your way to look, how is it a problem?

Anything where your own way of seeing it creates the problem, and you can't
describe the problem any other way, you're not ready to pitch it as a problem
to other people. Find some harm independent of your perception, and then
you've got a reason for people to listen.

~~~
zapzupnz
They've explained why it's a problem. Having an alternative viewpoint on "why
programs are randomly polluting my home folder, a sensitive location with my
personal data, with unwanted files without leaving any trace of their origin"
isn't going to help.

------
Memosyne
Why do programmers do this? What thought process leads to someone thinking
this is a good idea?

~~~
eknkc
It is safe. Everybody does it, there is .gitconfig, .ssh etc so one more would
not hurt.

Until there is 500 dotfiles, some long forgotten.

------
calvinmorrison
Wouldn't a simple union mount + cron job solve this problem relatively easy?

------
omnifischer
Dont forget .cache. Both chromium and firefox dump gigabytes of space there!

------
gesman
This is the consequence of enterprise practices of hiring el-cheapo, hit-and-
run contractors or outsourcing development to middlemen in “cost-efficient”
regions.

End developer is inexperienced, temporary, not valued and hence his
deliverables

------
_pmf_
If you think this is madness, try the alternatives.

~~~
quickthrower2
Like Windows Registry. Yay!

------
user501254
Somebody had to say it! Thank you!

------
est
maybe we do need some kind of registry, tree based key-value with an API for
access.

------
git-pull
My project cihai ([http://cihai.git-pull.com/](http://cihai.git-pull.com/))
and unihan-etl ([https://github.com/cihai/unihan-
etl](https://github.com/cihai/unihan-etl)) both use the XDG specification.

The reason I like it is it provides directories to use across platforms (edit:
Not sure about Windows), relative to the user. Since the applications download
a file (UNIHAN database [1]) to bootstrap, we want to store it in the user's
files, not the systems. The other thing I do that's helpful is using sqlite
(which is often built with Python).

This combination gives a database, and a place to store configuration,
downloaded/built files, in an organized way across systems.

The nice things XDG "standardizes" which I'm using:

$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_CACHE_HOME defines the base directory relative to which user specific
non-essential data files should be stored. If $XDG_CACHE_HOME is either not
set or empty, a default equal to $HOME/.cache should be used.

Why the implementation is helpful:

It defines a common directory for cache/data/config files, with applications
inside them, e.g. ~/.config/i3, ~/.config/tmuxp, rather than adding more stuff
to ~/.i3, ~/.tmuxp. When standards aren't being followed, programs end up
storing their configurations / data / etc all over.

Another thing is it defines directories relative to the user themselves and
for the system files. Dotfiles may imply configuration / artifacts in the
users home directory, it doesn't have. The thing I like is I can check for
configuration in user files (for instance ~/.gtk-3.0/), then fall back on
checking the system files (/etc/gtk-3.0).

The benefit of user files is they're writable out of the box, so if there's
going to be any file generated that the user needs to keep (like an unzipped
version of UNIHAN) that can be cached so they don't have to download it again.

(XDG Link: [https://specifications.freedesktop.org/basedir-
spec/basedir-...](https://specifications.freedesktop.org/basedir-spec/basedir-
spec-latest.html))

[1]
[https://www.unicode.org/reports/tr38/](https://www.unicode.org/reports/tr38/)

~~~
quotemstr
> $HOME/.local/share

Just look at that path:

"$HOME": It's my home directory. Cool.

".local": It's in my home directory, but local to it, and not somewhere else?
This doesn't make a lot of sense, but er, Okay.

"shared": For Christ's sake, what is this? It's in my home, and local within
it, but also _shared_? With whom? How? Why? I give up.

Why would anyone want to do this? What concrete benefit does this path give
us? What specific thing does it let you do that ~/.myprogram doesn't? The
article is bad, and the XDG standard is bad. The traditional approach is fine.

~~~
git-pull
Some things XDG is trying to do that's not readily apparent:

~/.local:

It's intended to be /usr/local in the user's home directory. There's a bit of
a backstory here though: Linux distros don't follow `/usr/local` as well as
BSD's, not much may be there.

~/.local/share:

Same idea, for /usr/local/share. But on many linux distros, this is
`/usr/share`. XDG is trying to do is mirror the system directories in the
user's filespace.

Let's assume there's going to be a lot of applications: they won't agree on
where cache, config, and data storage is kept at within ~/.myprogram. With
XDG, if someone wants to clean out all their cache files? rm -rf ~/.cache.

The other thing is: Typically the user won't be looking at
~/.local/share/myprogram - it's for data the application itself is going to
use. It doesn't really count against it. What I think we will be looking at
though: configuration files. That's where I think XDG is kind of original -
but it's really close to what /etc is.

As for ~/.myprogram: I'd be okay with that, if it were purely configuration.
But XDG serves the article writer's purpose fine: Keeping $HOME clean. I kind
of think splitting between ~/.config, ~/.local/share, and ~/.cache ends up
feeling more consistent with how linux/bsd organizes files.

------
fxfan
To name and shame some culprits (the one's who have shame, I won't name java
because I won't expect them to care)

1) Mozilla

2) Gnome

3) Gimp

4) GPG

5) Thunderbird (Why is there a sep directory and not under .mozilla)

6) mplayer

I guess one reason why this occurs is that it's easier for to be carelessly
cross-platform this way. Except you'd expect better from mozilla, specially
because they store Windows stuff very well inside %localappdata%

~~~
sandov
Speaking of Windows, their situation is worse. I remember installing a couple
of games and suddenly my "My Documents" folder had "EA", "EA Games",
"Electronic arts", "Rockstar games" folders.

~~~
georgeecollins
Games do that by design so that they can be cleanly uninstalled without
removing saved games and preferences. Also you should be able to backup your
documents folder and not your programs folder and be safe. A good uninstaller
should ask if you want to save them and remove them if you don’t.

I am not saying it is the best way. But I don’t think it is malicious or lazy.

~~~
amaccuish
There is literally a folder in every Windows profile (Vista onwards) called
"Saved Games", it should all go there.

~~~
Wowfunhappy
^ This. And the amazing thing is it's probably the _least_ common place for
games to put save data. I think I've played exactly one game that ever used
it.

~~~
dmitrygr
Most likely because the proper API to get the path to that folder was vista-
or-later and games preferred to be backward compatible

~~~
Wowfunhappy
Okay, but now nothing supports XP, so there's no excuse!

------
oskkejdjdkjd
Files in the Linux ecosystem are a mess. Files scattered everywhere and each
instance of Linux uses some different arbitrary directory scheme. We really
need a reboot. New micro kernel based OS with clear directory logic and
dedicated directories for applications to keep stuff.

~~~
zozbot123
> dedicated directories for applications to keep stuff.

That's what /opt is for!

~~~
jandrese
I thought /opt was for fully self-contained applications. Sort of prehistoric
version of snaps.

------
nine_k
What the article describes is indeed "dot file sanity".

------
LoSboccacc
> decided to hijack the primary location designed as a storage for my personal
> files.

that's the basic misunderstanding, the user folder is for everything that's
not system wide on a multiuser system; it's not there for your convenience,
it's there to allow programs a writable space that doesn't conflict with
everyone's else.

instead of subdirectoring everything else pretending programs to follow some
weird never agreed upon specification, just add a "document" folder and put
your user generated content there, problem solved.

Edit: apparently even on "hacker news" the mentality of forcing everyone else
into obeying instead of solving minor inconveniences the only logical way has
taken hold. Not even on widows with their nice buckets and environment
variables could solve this, resulting in an exposion of games, my games, three
app datas, documents/pictures/videos with apps doing whatever (i.e. shadow
play putting screenshots under videos) but no, Rando comes over recycling
three environmental variables that are specific of a program and everyone
sucks up to it ignoring all the technical, social and other issues to the
approach, while shitting upon the only sensible action that can and will work.

So much for applied brains.

------
gryfft
From a user standpoint, a lot of of unrecognizable things show up if you pass
that -l flag.

In my opinion, having a conventional place to look for user configuration in
plain text is a _good_ thing, not a bad thing, and of course I would want it
to be in the directory on my system where I'm the sole owner. As somebody else
mentioned, this means backing up my personal settings and files is braindead
simple, too.

Asking programmers to respect $XDG_HOME_CONFIG is not a bad idea, but it's no
replacement for home directory hygiene. I believe that ultimately, cleanliness
is a personal responsibility.

Edit: reduced smugness quotient while trying to preserve my argument. I
apologize for the pre-edit tone issues with this post.

~~~
reaperducer
_The other way-- and I 'm sorry for how smug this sounds-- is to just not
litter in your own home directory without cleaning it up._

How about the other way is I’ll just stop using your product/service/business
that doesn’t respect my machine?

~~~
gryfft
That's my point exactly. Most of these programs have command line flags you
can pass to indicate the configuration file that should be used. Doing that,
and then by default putting my configuration in the most reasonable place for
it--a dotfile-- is, in my opinion, the most respectful way a programmer can
treat someone's machine.

Not to mention that most of these are free and open source, so building
according to convention is the best way to keep their userbase happy (as
fiddlerwoaroof pointed out, $HOME was the original conventional dotfile
location pre-2003.)

So if your program doesn't respect my machine (meaning allow me to configure
it to prevent unwanted behavior) then yes absolutely, into the bin with it.
And rm -rf its dotfiles after.

~~~
afiori
you could check if ~/.local/share and ~/.config exist. also there is a
difference between files that the user is supposed to interact with and inner
configuration of random apps. ~/.ssh is fine, I need to look at it for many
.emacs.d is fine as is something you are expected to edit manually, but I
don't even know what some of these are: .aspell.en.prepl .dmrc .dropbox
.dropbox-dist .gtkrc-2.0 .joe_state .oracle_jre_usage .pdfsam .pylint.d snap
.texlive2016 .wget-hsts .vscode .xdvirc

This is from a fresh install 3 months ago, do I need 2 dot-folders for
dropbox?

