* 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?
> At last! Mozilla fixing longstanding bugs! (I jest)
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.
From that diff it looks to me that if ~/.mozilla exists OR if MOZ_LEGACY_HOME is set it uses ~/.mozilla, otherwise it uses the $XDG_CONFIG_HOME/.mozilla directory instead.
So no migration to the XDG directory, but also no throwing away your existing data either.
Looking at the full diff[0] it certainly looks like it's using ~/.cache (and has been for some time), but I cannot see anything about ~/.local/share, no.
> there doesn't appear to be a proper split between ~/.cache (always-removable cached data) ~/.config (configuration) and ~/.local/share
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.
I think there is probably a lot of work to do to fully pry the .mozilla folder apart. For a long time they've simply shipped everything in that folder and rolled with it. Making decisions on what is actually cache and what is user config vs "application data" is probably going to be harder than splitting the folder.
Someday they'll stop changing the context menu if I accidentaly select something.
(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).
You may jest, but sadly, that was my first knee-jerk reaction to the headline, too. "Wow, Mozilla actually fixes Firefox bugs? Let's go!" This is how low the bar has gotten :(
This is a meaningful step! For years, XDG Base Directory compliance has been spotty across major applications. Firefox's adoption matters because it's widely used and its implementation may encourage others to follow suit.
The Arch Wiki documentation will likely need updates [1], but sadly the list of non-compliant software is far too long.
FWIW, the OpenSSH devs believe it to be a potential security risk to adopt XDG:
> 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.
Chromium is still polluting stuff with $HOME/.pki because it's not using libnss correctly and developers don't care to fix it, despite a longstanding open bug report.
Which results in everything that embeds Chromium (like QtWebEngine and etc.) polluting $HOME as well.
the most "fun" I had it with the mess recently was after icedove -> thunderbird name migration (it was renamed in Debian coz of some trademark issue).
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
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 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.
This is great news. Firefox respects the system-defined folders on Windows and macOS. Linux, being the free spirit it is, doesn't have a 'standard'. XDG makes recommendations that make a certain amount of sense and aligning to that is a great step forward for such a large project.
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.
First .mkv support and now this! I really like what Firefox has been doing recently. The only major annoyance that still remains is hard-coded keyboard shortcuts, fingers crossed!
Firefox Nightly has about:keyboard (as I just found out from the comment thread on phoronix). Hopefully it sticks. It's bare-bones but functional and I like it that way.
I’m not sure if its because of my ad blocker but I get the occasional link that wont click when I am say going through a job application flow. Could be the way their saas vender implements things. For things that are important like that or say banking/credit card websites I usually am forced to defer to Safari.
So... did they also implement the horrendous quirk of Chrome that breaks XDG when XDG_DESKTOP_DIR and XDG_DOWNLOAD_DIR point to the same directory? It probably costed a combined million hours wasted and made many people genuinely hate Linux
I think the XDG spec is pretty petty. What difference does it make that the files are in ~/.config/mozilla instead of ~/.mozilla? And calling it a bug is presumptuous.
The difference is that I don’t use standard XDG directories because I loathe dot-files, loathe hidden directories, and so I declare my own environment variables to put everything where I want.
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.
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.
the main benefit (which even with this change, Firefox won't get) is the separation of configuration, cache files, binaries etc which sysadmins likely want completely different policies for. e.g. cache shouldn't be backed up, config shouldn't be executable etc
Have you ever `ls -al ~/` on a heavily used unix system? Absolute rot and chaos. I have like 100 hidden directories+files in the root of my home directory. Some of them are caches, some are configs.
I don't like Unix filesystem structure in general. What's the point of having directories like /usr or /lib in the root directory, when they could be all under for example, /ubuntu24? And the user could keep files in the root directory and not in /home with lot of system files.
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!
> you can run out of space at one partition, but have lot of free space at another
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.
There are a lot of reasons. Just three from the top of my head:
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.
It’s just historical. Believe the large number of top level directories was a result of ken not having enough space on a single disk on his PDP, when that was precious.
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.
I’m honestly having issues deciding if this is bait or not. Surely you understand that UNIX is a multi-user operating system and that partitioning drives exactly for the reason you describe is critical to ensure that, for example, runaway log growth doesn’t cause a database to shut down?
amiga386|3 months ago
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?
weaksauce|3 months ago
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.
philo23|3 months ago
So no migration to the XDG directory, but also no throwing away your existing data either.
KwanEsq|3 months ago
[0] https://hg-edge.mozilla.org/integration/autoland/rev/8a6d6c0...
batisteo|3 months ago
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.
ndegruchy|3 months ago
eitland|3 months ago
(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).
darkamaul|3 months ago
[0] https://bugzilla.mozilla.org/show_bug.cgi?id=259356
ryandrake|3 months ago
More of this, less AI-cramming, please!
pjmlp|3 months ago
darkamaul|3 months ago
The Arch Wiki documentation will likely need updates [1], but sadly the list of non-compliant software is far too long.
[1]: https://wiki.archlinux.org/title/XDG_Base_Directory
aidenn0|3 months ago
> 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
shmerl|3 months ago
Which results in everything that embeds Chromium (like QtWebEngine and etc.) polluting $HOME as well.
PunchyHamster|3 months ago
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
indolering|3 months ago
enriquto|3 months ago
The ~/.mozilla folder is one of the last remaining dotfiles in my home directory
You can also be an xdg ninja if you want: https://github.com/b3nj5m1n/xdg-ninjaAnnoyingly, 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!
smaudet|3 months ago
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).
wpm|3 months ago
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.
ndegruchy|3 months ago
johnisgood|3 months ago
freeone3000|3 months ago
amiga386|3 months ago
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.
lovedaddy|3 months ago
andriamanitra|3 months ago
sfink|3 months ago
shevy-java|3 months ago
johnisgood|3 months ago
AdmiralAsshat|3 months ago
aallaall|3 months ago
phoronixrly|3 months ago
Source: https://hg-edge.mozilla.org/integration/autoland/rev/8a6d6c0...
ksec|3 months ago
Firefox excel in terms of Multi Tab and memory usage. And I have yet to encounter a rendering issues in the past 12 months.
kjkjadksj|3 months ago
PaulDavisThe1st|3 months ago
butz|3 months ago
shmerl|3 months ago
sam_lowry_|3 months ago
See here https://github.com/chromium/chromium/blob/5e4e38173b33159b0e...
jaredhallen|3 months ago
s1mplicissimus|3 months ago
trizuz|3 months ago
[deleted]
kernc|3 months ago
jason-richar15|3 months ago
[deleted]
ceving|3 months ago
wpm|3 months ago
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.
Avamander|3 months ago
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.
adgjlsfhk1|3 months ago
kennywinker|3 months ago
codedokode|3 months ago
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!
neoden|3 months ago
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.
tasn|3 months ago
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.
mixmastamyk|3 months ago
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.
joestrouth1|3 months ago
hnarn|3 months ago
einpoklum|3 months ago
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.