The devil is in the details though: https://hg-edge.mozilla.org/integration/autoland/diff/8a6d6c...
Looking briefly at this,
* there doesn't appear to be any migration from old directory to new directory. Does the code just use ~/.mozilla if it still exists, ~/.config/mozilla otherwise.. or does it _require_ MOZ_LEGACY_HOME=1 to be set to keep using your existing config, and just lose all config if you don't set that?
* there doesn't appear to be a proper split between ~/.cache (always-removable cached data) ~/.config (configuration) and ~/.local/share (application data that is not user-editable configuration and is not just cached data either), they just moved the entire set of profile stuff to ~/.config
Is that about right, or do I need to read the code more carefully?
you joke but they did just close out the initial implementation of a something like 27 year old bug. about:keyboard was recently added to nightly to allow you to change or clear the built in keyboard shortcuts of a bunch of menu items like save, back, refresh, or open dev tools or whatever.
So no migration to the XDG directory, but also no throwing away your existing data either.
Who knows what might be touching that data today. Or backing it up, etc
[0] https://hg-edge.mozilla.org/integration/autoland/rev/8a6d6c0...
Which already is a huge improvement and better than bikeshedding for decades that they also should use $HOME/.local/share/mozilla in addition.
If that’s true, the title of the issue (and blog post) is quite untrue. Shoving everything in ~/.config is different than following the XDG Base Directory spec.
At least it’s one dotfile less that’s polluting my home.
So, things change over time. The question is: is the codebase at Mozilla still "living" in that it can adjust or be adjusted?
https://www.linuxfromscratch.org/blfs/view/svn/xsoft/firefox...
Requiring a mozconfig file shows that the code base has failed to transition to cmake or meson/ninja (directly; there is some python wrapper which may help here but I refer to the primary configuration). Mozilla gave up on Firefox a long time ago already.
(Some UX designer or developer thought it was a great idea to remove the back and forward buttons from the context menu if text is selected so now I have two different context menus and one of them lack the thing I am looking for most of the time which is the back button.
Or fixing the tabstrip API (someone has decided we users are now too stupid to use only tree style tabs and for our own good we must be prevented from hiding the original tab bar).
This annoys me constantly trying to get Firefox to show the “Take Screenshot” context-menu item. Yes I know about Control+Shift+S, but I'm still annoyed when my hand is already on the mouse and it won't do what I want.
Although perhaps I should stop using that feature since I just while writing this comment realized how much it spies on you: https://probes.telemetry.mozilla.org/?search=screenshots
More of this, less AI-cramming, please!
The Arch Wiki documentation will likely need updates [1], but sadly the list of non-compliant software is far too long.
The ~/.mozilla folder is one of the last remaining dotfiles in my home directory
$ ls -a ~
. .. .bashrc .mozilla .profile .ssh bak config local pro src
Annoyingly, many programs hardcode ~/.config and ~/.local (instead of using XDG_CONFIG_HOME etc) and try to recreate them every time they run. This is a good indication to stop using these careless programs!
I like environment variables, but developers/operating systems have trouble using them well.
I could almost see XDG_CONFIG_HOME being a setting read by a driver that provides access to a "virtual" path (on *nix, all paths are virtual anyways).
Now you have even more complexity. Programs will have to know where this "virtual" path is unless you're suggesting it should be hard-coded.
> on *nix, all paths are virtual anyways
What does this mean?
I despise programs that think they can just run a goddamn train on my home directory. I'm sick of hidden files I'm expected to edit by hand for configuration. I sick of ugly dotfiles everywhere.
The reason most software is not "XDG-compliant" is because most software predates the XDG basedir spec which only came into existence in 2021 (edit: oops, that's just version 0.8; version 0.6 was available in 2003)
It will be nice for software, as it updates, to support this standard which seems to be gaining adoption, and it will make users homedirs much cleaner. But it's most important for software to _keep working_, and have a migration path that doesn't lose the user's config or end up with two configs and not have a clear rule on which one it will use.
[1] Could (and should) implement a verification step as well.
Time ? I'm focused on other things.
Firefox excel in terms of Multi Tab and memory usage. And I have yet to encounter a rendering issues in the past 12 months.
# export XDG_CONFIG_HOME $HOME
# export XDG_CONFIG_HOME $HOME/config
See here https://github.com/chromium/chromium/blob/5e4e38173b33159b0e...
Also I don't like that some distributions suggest partitioning a drive. This is inconvenient, because you can run out of space at one partition, but have lot of free space at another. It simply doesn't make sense. And if you have swap as a partition, you get slightly faster access, but cannot change the size!
> Adding additional configuration paths is confusing and potentially risky for .ssh as, quite unlike usual "desktop" apps, it grants system access and having its configuration smeared across several possible paths makes managing this more confusing and brittle.[1]
I think this is clearly true for something like ~/.ssh/authorized_keys; it is perhaps less true for ~/.ssh/config and or ~/.ssh/known_hosts which could go in XDG_CONFIG_HOME and XDG_DATA_HOME, but if part of the point of the XDG BDS is to reduce dotfiles in $HOME then it makes less sense to move some, but not all of those files.
1: https://marc.info/?l=openssh-unix-dev&m=170687803731931&w=2
However this "exemption" does not and should not apply to anything newer. Things like Cargo, Snap, Steam, Jupyter, Ghidra, Gradle, none of those should be putting their stuff (especially temporary junk) directly and unsegmented into $HOME.
At some point I had more than 50 different dotfiles and dotfolders in my $HOME. It was unwieldy and nasty to look at. I couldn't even figure out what created some of those files because they were so generic.
Plain $HOME as the dumping ground simply does not scale beyond a select few.
This does make things confusing, and while it may be inconvenient, it is not a security risk.
I use firejail with most apps and they do not have access to any other files than their own (most of the time).
FWIW, I am completely fine with ~/.ssh and I hope it keeps being ~/.ssh. I prefer SSH-related stuff to be in one place. Same with ~/.gnupg. I do not want to miss anything when I am making backups.
Which results in everything that embeds Chromium (like QtWebEngine and etc.) polluting $HOME as well.
Tunderbird, of course, kept mail and config in same directory. The migration process renamed .icedove to .thunderbird and removed it.
But the config for mailboxe still had .icedove/xyz path. So once config migration is finished, mails start to download in old location, and after restarting thunderbird goes "hey, there is both .icedove and .thunderbird dir, I'm not starting".
with XDG that config would be separate so there would be no need to even move the data dir
Then Firefox (and ansible, and many others) comes barreling in dropping an unconfigurable dot-directory in my fucking home folder ignoring the perfectly good XDG variables I have set.
It is a constant struggle to stop my home folder from not feeling like my home. Developers ought to learn some fucking respect.
export ANDROID_USER_HOME="$XDG_DATA_HOME"/android
alias adb='HOME="$ANDROID_USER_HOME" adb'One being that it's _my_ $HOME, not some random developers'. I literally had more than 50 different dotfiles and dotfolders in my $HOME at some point. It was a garbage dump and I couldn't even identify the culprit with some of them. Simply disrespectful.
Then there's the issue of cleaning up leftovers and stale cache files. It shouldn't take a custom script cleaning up after every special snowflake that decided to use some arbitrarily-named directory in $HOME.
Not following the spec also makes backing up vital application state much much harder.
In the end, I made my $HOME not writeable so I could instantly find out if some software wants to take a dump. It turns out it's often simply unnecessary as well, the software doesn't even care, just prints an error and continues.
Not to take away from your point but I shall introduce you to systemd-tmpfiles
no scripts needed, it can clean up for you if you keep a list of directories/files to clean up
A brilliant idea, but goddamn what a shame it is that we have to do such things to keep our homes clean
Your point is valid for config/data split, but that seems to be a judgement call and many applications do things differently there.
that's exactly the point — you can run out of space in your /home but that does not affect, for example, /var. or vice versa, log explosion in /var is contained within its own partition and does not clog the entire filesystem.
Also, there are quotas for this purpose.
1. The way Unix works, a directory is a file, so if you can write in a directory you'll also be able to move directories around (and thus break the structure you mentioned completely).
2. Doesn't make sense for multi-user. Yes, I understand most people have their own computers, but (1) why design it in a way that breaks multi-user unnecessarily? (2) there are a lot of utility users, and having them get access to user files because of the way this is structured is silly.
3. `grep -r` is going to be a pain in the ass when searching your own files, because it'll also search all the other system subdirectories too.
Well, maybe this should be changed, or we could just use the sticky bit.
Other users, except for primary user, can use /ubuntu24/home/. Primary user uses the root of hard drive however they want.
> because it'll also search all the other system subdirectories too.
It's already a pain because /home contains lots of system files, caches etc. And it would not be difficult to add a flag "skip system files".
For years I’ve been putting all user data into a separate /data partition and have kept the OS partition small (~30gb). But you have to fix the system when first installed. When I still used Windows I had the same c:/d: split.
More recently started putting kernels into a bigger ESP (EFI) partition with sdboot or uki.
With terabyte system disks, running out of space mostly doesn’t happen anymore unless you made the system partition(s) small. Don’t do that, give them plenty of GB, each of which are now thousandths of the disk.
And, if they have never seen nor used "multi-user computers" they also have not encountered "runaway log growth" or the like -- or if they did it was from their own process that they immediately killed, not by some other user on the same computer filling /var/log/ in the background.
Also, databases usually store data in /var so it won't even help. Also, mysql simply hangs instead of shutting down in this case.
Then fix bug after bug after bug in your new "simpler" thing and realize why the thing you decided to "fix" was that complicated in the first place
It also lets you somewhat-better enforce things like:
* Setting some data aside as read-only-never-touch-it.
* Excluding some files and directories from searching and indexing.
although admittedly you don't _have_ to partition for that purpose.
here's the 25 year old bug. https://bugzilla.mozilla.org/show_bug.cgi?id=57805
I'm not saying it's a bad idea to try to follow xdg, just that it's a complex and ongoing thing. It's a good example of the "Just do X!" fallacy.
Let's say that there are just two possible paths for an authorized_keys file (P1 and P2).
The choices are:
1. Check P1, if it doesn't exist use P2
2. Check P2, if it doesn't exist use P1
3. Merge the contents of P1 and P2 somehow
You need to remove authorization for a key (or certificate); you confirm it has been removed from P1. In both cases #2 and #3 above, you may have failed to actually remove authorization!
Obviously if there are more than 2 possible paths, things get even worse. Also, if you follow XDG to the letter (where things can be redirected by environment variables), there are even more confounding issues, because the environment that sshd sees could be different from the environment that the user sees.
Mmm...not exactly. When security is difficult, the default fix is to turn it off, workaround, etc. Security should be relatively simple.
Increasing the difficulty of correctly configuring additional directories increases the chance something "bad" may happen. As a theorical example, for ssh say that config is not protected the same way keys are (on the file system or by policy). Pair this with some option that, when configured, exposes the contents of the keys.
Increasing the complexity required to secure something makes it inherently less secure.
I heard actual devs complaining they don't need logrotate because containers are restarted often enough...
That bug was actually fixed in the Dvorak release...
I suppose you could also bind it to a noop.
That was a big problem when I switched to macOS. I kept hitting CMD+Q every time I tried to type an email address.
Databases store data where you tell them to.
https://addons.mozilla.org/en-US/firefox/addon/ctrl-shift-c-...
Thanks!
And deleting the partially copied data if the copy wasn’t successful, and making sure “just copying files to the new directory” didn’t overwrite data, and probably a few more tricky scenarios, e.g. ones involving access rights.
Also, if you think it could be a directory rename, there are tricky corners there, too. How do you determine whether source and target are on the same disk, for example?
It _is_ possible, but doing it robustly is far from trivial.
Same-disk detection can be done through stat() on both paths and comparing st_dev, which is trivial. But more importantly, why does this matter for migration? If it is cross-filesystem, copy and move works fine. If you are concerned about atomicity, that is a different problem, but Firefox profiles are not typically manipulated concurrently during a migration that happens once at startup.
Partial copy cleanup is reasonable, but again, context matters. For a one-time migration triggered at browser start with exclusive access to the profile, you verify checksums or sizes post-copy, and if verification fails, you do not delete the source. User gets an error, tries again later. Not complex.
As for overwrites: do not overwrite if target exists. Check once before starting. If the XDG path already has data, skip migration entirely or prompt. This is not a continuous sync operation.
FWIW "cp -a" preserves access rights on Unix. On Windows, ACLs can be trickier but for user-owned profiles it is usually a non-issue.
The real complexity in robust file operations show up with network filesystems (SMB, NFS), concurrent access patterns, or where atomicity guarantees are critical (and a move operation is indeed atomic, assuming typical systems). For a single-user profile migration that happens once with exclusive lock? The corner cases you mentioned are either straightforward to handle or do not apply.
There's lot less to migrate if you don't wait that long.
It's been a while since I used Windows, but I remember the "My Documents" folder being trash pile of configs, save games, data files and whatnot, making it the worst place to actually store your documents.
Then ignorant developers who don't care about the platform throw random configuration folders in ~/ or ~/Documents, or think their app needs a central workspace folder for all of its projects, instead of letting you manage your own damn files.
The folder for config is even older. CSIDL_APPDATA has been able to be used to get the path to the AppData folder since the update for Windows 95 that added Internet Explorer 4.0.
$ find ~ -maxdepth 1 -name '.??*'|wc -l
435
A sampling...
$ (cd && find . -maxdepth 1 -name '.*'|sort -R|head)
./.texlive2023
./.stl
./.stp
./.repo_.gitconfig.json
./.xsel.log
./.msmtprc
./.fonts
./.bash_logout
./.steampath
./.compose-cacheNot at all. You can read `XDG_CONFIG_HOME` to know where the config path actually is.
Or, if you're lazy, just hard code to `.config`.
I think maybe you are unfamiliar with how paths work on *nix.
All paths are virtual, meaning they are provided by something. Part of the "everything is a file" nix thing. Normally, files are provided by your file system, which (usually) examines stuff like inodes and partition bits, but they are also provided by processes, sockets, pipes, etc.
Everything is a file. So .config is just another "file", if you move the whole disk directory aside, it still exists, provided by the driver.
So your program has to do exactly nothing, other that use either a path, or maybe the env var (maybe useful if you move the physical location of the folder, e.g.)
> I like environment variables, but developers/operating systems have trouble using them well.
So then read `XDG_CONFIG_HOME` to find the "virtual" path where the driver will mount the config "virtual" path that could have just been referenced directly in `XDG_CONFIG_HOME`?
> All paths are virtual, meaning they are provided by something.
As opposed to not being provided by something? That's nonsense and even if it did make sense, if ALL paths are virtual, the distinction is meaningless.
Also, you're taking "everything is a file" too literally.
> that could have just been referenced directly in `XDG_CONFIG_HOME`?
It is referenced directly though...
> That's nonsense
What exactly are you asserting to be nonsense? Exactly nothing I said about paths on unix is nonsense, please provide a specific example of what you think is nonsense.
screenshots.canceled#canceled
screenshots.copy#copy
screenshots.download#download
screenshots.failed#failed
screenshots.selected#selected
screenshots.started#started
screenshots.copy
screenshots.custom
screenshots.download
screenshots.element
screenshots.full_page
screenshots.upload
screenshots.visible
(This has bitten me before. I don't know why it was done that way.)
It even had the original XUL-based DownThemAll version, got disabled after XUL addons were disabled and some time one or two years later it got re-enabled again after the dev released a webextensions compatible version (sadly with several limitations, but still useful for bulk downloads).
Amusingly, there are a couple Windows absolute paths in there even though this profile has been on Linux for a few years now :-P
> there is no migration path supported at this point: only new profiles are expected to use the new setup. Migrating manually is at your own risk, make a backup before.
I'll try to do it manually, replacing paths in the couple of files mentioned above first.
Either they adopt XDG fully, putting cache files where they belong, or don’t just change things haphazardly for little benefit.
You can exclude $HOME/.config/mozilla from your back up all the same anyway if that causes you some issues.
I personally appreciate them not cluttering $HOME with this move. It is better than waiting another 21 years for them to support XDG spec fully by splitting share and config.
And then just not have Firefox backups?
browser.quitShortcut.disabled
browser.warnOnQuit
browser.warnOnQuitShortcut
The setting is there, it's editable, but Firefox seems to completely ignore it on Linux.
At least up to 145.0.1.
This says gnome has ctrl-q to quit applications:
https://wiki.gnome.org/Design/OS/KeyboardShortcuts
I don’t know if the above is still the default, but I have this in my gnome setup scripts anyway:
gsettings set org.gnome.settings-daemon.plugins.media-keys screensaver “[‘<Control>q’]”
Well, ok, whatever. This is a fairly trivial thing to discuss...
It is rather obvious why a software designer want to know how a piece of software is used and also to know it over time. If number of cancelled screenshots increases (or decreases) compared to general usage of the screenshot feature it might give an early indication that a recent change was bad (or good).
As long as it only logs counters like this and not who I am or any of my data or who I am I actually want them to log it and if it was disabled and there was an easy way to enable it I would do it.
The problem is that they have:
- a history of not being completely honest (unlike certain other actors who have a history of being actively dishonest)
- no easy way for people to choose what they send
- and a number of other problems, for example what I suspect is that they ignore actual users seemingly in favour of what their ux designers and developers think a user should want. (And that seems to always be dumbing down, "simplifying" and making it more like Chrome.)