[HN Gopher] Firefox 147 Will Support the XDG Base Directory Spec...
___________________________________________________________________
Firefox 147 Will Support the XDG Base Directory Specification
Author : bradrn
Score : 303 points
Date : 2025-11-20 14:20 UTC (8 hours ago)
(HTM) web link (www.phoronix.com)
(TXT) w3m dump (www.phoronix.com)
| ndegruchy wrote:
| 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.
| darkamaul wrote:
| 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.
|
| [1]: https://wiki.archlinux.org/title/XDG_Base_Directory
| aidenn0 wrote:
| 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.
|
| 1: https://marc.info/?l=openssh-unix-dev&m=170687803731931&w=2
| Avamander wrote:
| I think most people are okay with software such as OpenSSH
| keeping its long-existing conventions. In the same way I
| don't think a lot of people mind ".bashrc" being where it is.
| It's manageable if there's just a few and they're well-known.
|
| 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.
| aidenn0 wrote:
| $ find ~ -maxdepth 1 -name '.??*'|wc -l 435
|
| [edit]
|
| A sampling... $ (cd && find . -maxdepth 1
| -name '.*'|sort -R|head) ./.texlive2023
| ./.stl ./.stp ./.repo_.gitconfig.json
| ./.xsel.log ./.msmtprc ./.fonts
| ./.bash_logout ./.steampath ./.compose-
| cache
| encom wrote:
| >$HOME as the dumping ground
|
| 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.
| redwall_hp wrote:
| Windows-oriented developers bring that mess to Macs, too,
| and it's incredibly aggravating. For over 25 years, Apple
| has had
| Documents/Pictures/Movies/Applications/Downloads/etc
| folders under the user's home folder, and convention is
| predominantly that you _never_ put non-hidden files or
| folders in the user 's home directory. And you don't put
| application configuration in Documents, because that's
| what ~Library is for.
|
| 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.
| tensegrist wrote:
| how else will you remember where you stored your 3d
| objects
| johnisgood wrote:
| > configuration smeared across several possible paths
|
| 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.
| smaudet wrote:
| > inconvenient, it is not a security risk
|
| 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.
| johnisgood wrote:
| Okay, that makes sense and I do not disagree.
| PunchyHamster wrote:
| 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
| amiga386 wrote:
| At last! Mozilla fixing longstanding bugs! (I jest)
|
| 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?
| darkamaul wrote:
| I was curious about how old the original bug report was, and it
| appears to be 21 years old [0]!
|
| [0] https://bugzilla.mozilla.org/show_bug.cgi?id=259356
| layer8 wrote:
| It's right in the first sentence of the article.
| ndegruchy wrote:
| 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.
| abdullahkhalids wrote:
| Extension data also lives in the profile folder. Some of
| those might start failing because of splitting up the profile
| into multiple folders.
| ndegruchy wrote:
| Oh, I hadn't even _thought_ of that. Yeah, that's going to
| be a fun debate. Realistically, extensions shouldn't care
| about the folder structure of other parts of the profile,
| but I also know that there is a _lot_ of history there.
| amiga386 wrote:
| That's true, but they've already done it for macOS...
| ~/Library/Application Support/Firefox/ (for both the config
| and non-config data) versus ~/Library/Caches/Firefox/ (for
| cached data that can always be deleted)
| shmerl wrote:
| FYI, they do use $HOME/.cache/mozilla already for a long
| time.
| shevy-java wrote:
| > I think there is probably a lot of work to do to fully pry
| the .mozilla folder apart.
|
| 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.
| philo23 wrote:
| 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.
| paulddraper wrote:
| That's the safest.
|
| Who knows what might be touching that data today. Or backing
| it up, etc
| gen2brain wrote:
| I know a few apps that did the same (mpv for example). If
| you still have it in home root it uses that, when you move
| it to .config it uses that instead. Auto migrating could
| and would create issues.
| shmerl wrote:
| So is it safe to just manually move $HOME/.mozilla to
| $HOME/.config/mozilla ?
| aallaall wrote:
| That's the hard part to answer, that Mozilla leaves to you!
| Gabrys1 wrote:
| I think yes. And that's maybe the reason they didn't
| properly split the files to .cache/ .config etc
| neilv wrote:
| I would guess not. I see `.mozilla` absolute pathnames
| within some files in a profile directory (specifically,
| `extensions.json` and `pkcs11.txt`).
|
| (This has bitten me before. I don't know why it was done
| that way.)
| johnisgood wrote:
| This is very important to know if this is really the
| case. And if it is, then what is the best way to migrate?
| Is there an official, supported method if "mv" is not it?
| badsectoracula wrote:
| It seems Firefox doesn't really _rely_ on these. My
| profile directory has been around for more than a decade,
| went through three computers and even between Windows and
| Linux and from plain Firefox to Firefox Developer Edition
| and pretty much everything transferred just by copying
| the files around (however i didn 't copy the full Mozilla
| directory, first i let Firefox make a new empty profile
| by itself and copy/pasted the files in it, overwriting
| whatever was already there).
|
| 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
| neilv wrote:
| Interesting. I have had extensions lose their storage
| when the profile directory path changed, and at the time
| it seemed to be because of the pathnames within the
| files.
| KwanEsq wrote:
| 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.
|
| [0] https://hg-
| edge.mozilla.org/integration/autoland/rev/8a6d6c0...
| shmerl wrote:
| Nope, they just moved $HOME/.mozilla to $HOME/.config/mozilla
| it seems.
|
| Which already is a huge improvement and better than
| bikeshedding for decades that they also should use
| $HOME/.local/share/mozilla in addition.
| sph wrote:
| Which means my .config directory, which is under backup, is
| gonna be spammed with temporary and cache files. Though not
| XDG-compliant, at least ~/.mozilla was in place for decades
| and it's already being excluded in my backup set on my
| machines.
|
| Either they adopt XDG fully, putting cache files where they
| belong, or don't just change things haphazardly for little
| benefit.
| shmerl wrote:
| Not cache files if I understand correctly, they are using
| $HOME/.cache/mozilla for a long time already.
|
| 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.
| mulmen wrote:
| > You can exclude $HOME/.config/mozilla from your back up
| all the same anyway if that causes you some issues.
|
| And then just not have Firefox backups?
| shmerl wrote:
| Person above already didn't have them, so not sure what
| you are asking.
| ryandrake wrote:
| 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 :(
|
| More of this, less AI-cramming, please!
| weaksauce wrote:
| > 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.
| georgefrowny wrote:
| Holy shit does this mean I can disable Ctrl-Shift-C and get
| my muscle memory for terminal copy back?
| Gabrys1 wrote:
| There's an extension for that. Quite handy for in-browser
| terminals like one in AWS etc.
|
| https://addons.mozilla.org/en-US/firefox/addon/ctrl-
| shift-c-...
| cookiengineer wrote:
| I installed this extension 5 minutes ago and it's already
| such an improvement. Never occured to me that there can
| be extensions to override shortcut defaults.
|
| Thanks!
| suprjami wrote:
| This was my first thought too!
| weaksauce wrote:
| as a matter of fact... yes https://i.imgur.com/0uxzr4H.png
| marcosdumay wrote:
| Is CRTL-Q included? They always insisted that applications
| can't change that shortcut on Linux.
| mikkupikku wrote:
| Ctrl-Q (quit application) right next to Ctrl-W (close tab)
| has been bad UX since forever.
| sevg wrote:
| I bind ctrl-q to lock screen in gnome, which is less bad
| than losing the whole browser.
|
| I suppose you could also bind it to a noop.
| PaulDavisThe1st wrote:
| You can tell firefox to ask before quitting ...
| sevg wrote:
| You can also tell Firefox to ignore it completely:
| browser.quitShortcut.disabled
|
| As well as to warn: browser.warnOnQuit
| browser.warnOnQuitShortcut
|
| Well, apparently I once was aware of these because I have
| it set in my custom user.js. But I guess ctrl-q will
| always be lock screen for me, old habits die hard.
| Pet_Ant wrote:
| > Ctrl-Q (quit application) right next to Ctrl-W (close
| tab)
|
| That bug was actually fixed in the Dvorak release...
| blueflow wrote:
| I need source on that Ctrl+Q thing
| weaksauce wrote:
| https://i.imgur.com/8a9Jbj6.png it seems to be available
| to remap/cancel.
| weaksauce wrote:
| yes... https://i.imgur.com/8a9Jbj6.png
| stronglikedan wrote:
| was that a bug though? cuz it sounds like it was just a new
| feature that was added
| batisteo wrote:
| > 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.
| johnisgood wrote:
| I agree, because of XDG_CONFIG_HOME vs. XDG_CACHE_HOME vs.
| XDG_DATA_HOME.
|
| See https://wiki.archlinux.org/title/XDG_Base_Directory.
| eitland wrote:
| 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).
| Lammy wrote:
| > so now I have two different context menus and one of them
| lack the thing I am looking for most of the time
|
| 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
| ndriscoll wrote:
| That domain is blocked on my network. What kind of
| information is it collecting?
| Lammy wrote:
| Events: screenshots.canceled#canceled
| screenshots.copy#copy screenshots.download#download
| screenshots.failed#failed
| screenshots.selected#selected
| screenshots.started#started
|
| Counters: screenshots.copy
| screenshots.custom screenshots.download
| screenshots.element screenshots.full_page
| screenshots.upload screenshots.visible
|
| inb4 mention of "Send technical and interaction data to
| Mozilla" setting, like it's okay for software to be
| privacy-adversarial by default lol
| wpm wrote:
| Maybe I'm just too stupid, but goddamn what could the
| possible value in knowing if someone cancelled a
| screenshot or something. Like, *who cares*
| johnisgood wrote:
| About time. Every piece of software should be XDG-compliant. I am
| surprised it was not the case at all to begin with.
| freeone3000 wrote:
| XDG is newer than firefox and hasn't been widely adopted for
| the majority of its life.
| amiga386 wrote:
| Do you mean Firefox specifically?
|
| 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.
| johnisgood wrote:
| I think it is possible for software to keep working and I can
| think of many ways to implement automatic "migration", which
| is essentially just copying files to the new directory (or
| just do a move operation which is atomic) and then deleting
| the previous directory if the copy was successful[1], and if
| one wants, could create a compressed backup of the directory
| prior to doing that.
|
| [1] Could (and should) implement a verification step as well.
| Someone wrote:
| > which is essentially just copying files to the new
| directory and then deleting the previous directory if the
| copy was successful
|
| 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.
| Avamander wrote:
| Migration might be nontrivial but there's absolutely zero
| good excuse for creating _new_ noncompliant directories
| for 17 years.
|
| There's lot less to migrate if you don't wait that long.
| johnisgood wrote:
| You are listing edge cases that exist, but the relevant
| question is whether they meaningfully apply to Firefox
| profile migration on typical systems.
|
| 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.
| lovedaddy wrote:
| This is awesome! Been tracking the bug for what seems like Gimp 3
| levels of time. But great job all involved.
| shmerl wrote:
| Sincere congrats! It only took 21 years.
| ceving wrote:
| 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.
| wpm wrote:
| 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.
| RealCodingOtaku wrote:
| This, I set an alias for `adb` to use
| `"$XDG_DATA_HOME"/android` instead of `~/.android` because it
| stores the keys there for whatever reason. I would rather not
| see my home folder being cluttered with hidden files, it
| makes backing things up unnecessarily complex.
| export ANDROID_USER_HOME="$XDG_DATA_HOME"/android
| alias adb='HOME="$ANDROID_USER_HOME" adb'
| Avamander wrote:
| Don't forget Gradle ("GRADLE_USER_HOME") and OpenJDK
| ("-Djava.util.prefs.userRoot"), those too litter.
| akdev1l wrote:
| You could try flatpak Firefox, if that works for you then it
| takes care of that
| adgjlsfhk1 wrote:
| 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
| sfink wrote:
| Firefox already had the benefit with respect to cache files.
| They've been in ~/.cache/mozilla for at least 7 years now.
|
| Your point is valid for config/data split, but that seems to
| be a judgement call and many applications do things
| differently there.
| kennywinker wrote:
| 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.
| Avamander wrote:
| There are multiple reasons for this.
|
| 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.
| akdev1l wrote:
| > It shouldn't take a custom script cleaning up after every
| special snowflake that decided to use some arbitrarily-named
| directory in $HOME.
|
| 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
| wpm wrote:
| > In the end, I made my $HOME not writeable so I could
| instantly find out if some software wants to take a dump
|
| A brilliant idea, but goddamn what a shame it is that we have
| to do such things to keep our homes clean
| codedokode wrote:
| 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!
| tasn wrote:
| 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.
| joestrouth1 wrote:
| If one user kept their files in the root directory, where would
| a second user keep theirs?
| aallaall wrote:
| Most operating systems mounts things dynamically. You can
| never trust that a path for you exists for another user.
| pwg wrote:
| This is a _very recent_ aspect time wise in the very long
| history of Unix (and Linux) systems.
| neoden wrote:
| > 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.
| PunchyHamster wrote:
| very important for /var/log, pretty easy to have log spamming
| app fill the drive, and you don't want logs filling get your
| database into out of disk space state
| mixmastamyk wrote:
| 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.
| hnarn wrote:
| 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?
| pwg wrote:
| Today, in 2025, neither are _safe_ assumptions to make. Much
| in line with the Internet meme 's of "new college freshmen in
| 2025 have never known a world without cell phones" and the
| like, in 2025 there is now some rather large subset of the
| computer using population who have never known of nor used a
| "multi-user computer" and have only ever seen and used
| "single user computers" (even if the OS on their computer is
| inherently multi-user, the overall 'computer' is 'single-
| user' from their viewpoint).
|
| 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.
| encom wrote:
| AI startup idea: A plugin that scores HN posts on likelihood
| of bait. ChatGPT when prompted "Give [the post] a score from
| 1 to 10, where 1 is complete sincerity and 10 is low effort
| bait" thinks this is 7.
| PunchyHamster wrote:
| there is good chance with any bait to just have someone
| clueless.
|
| I heard actual devs complaining they don't need logrotate
| because containers are restarted often enough...
| PunchyHamster wrote:
| It's a learning experience, when you see something, ask
| yourself "why it is so complicated" and try to do it simpler
|
| 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
| einpoklum wrote:
| Partitioning a drive lets you use different file systems on
| different parts.
|
| 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.
| AdmiralAsshat wrote:
| I wonder if the original reporter is still around to see their
| enhancement ticket closed?
| aallaall wrote:
| Perhaps their grand children are still around?
| PunchyHamster wrote:
| probably using chrome tho, FF really squandered the
| marketshare
| kjkjadksj wrote:
| Nothing they could do when the de facto search engine and
| de facto video player for the entire internet started
| shilling its own product relentlessly.
| ksec wrote:
| I am wondering what other long standing bug or feature that is
| still missing on Firefox.
|
| 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 wrote:
| 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.
| phoronixrly wrote:
| Bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=259356
|
| Source: https://hg-
| edge.mozilla.org/integration/autoland/rev/8a6d6c0...
| shevy-java wrote:
| Not bad - with a delay of only 21 years, Firefox is just about to
| make a strong come back now. :D
| johnisgood wrote:
| Someone asked what the blocker is, and the guy replied:
| Time ? I'm focused on other things.
|
| I mean, he _only_ had 21 years. :D
| kernc wrote:
| Now that everyone is kindly on board, IBM can finally bury this
| standard. /s
| jaredhallen wrote:
| Will it stop enabling dns over https by default?
| enriquto wrote:
| that's great!
|
| 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
|
| You can also be an xdg ninja if you want:
| https://github.com/b3nj5m1n/xdg-ninja
|
| 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!
| smaudet wrote:
| (hard) links to the rescue.
|
| 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 wrote:
| TIL about xdg-ninja, thanks for sharing.
|
| 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.
| PaulDavisThe1st wrote:
| # export XDG_CONFIG_HOME $HOME
|
| though more seriously # export XDG_CONFIG_HOME
| $HOME/config
|
| why another dotfile dir?
| andriamanitra wrote:
| 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!
| sfink wrote:
| 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.
| butz wrote:
| Let's hope this will inspire other software developers to follow
| conventions and move their configs to appropriate directories.
| s1mplicissimus wrote:
| bless them
| sam_lowry_ wrote:
| 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
|
| See here
| https://github.com/chromium/chromium/blob/5e4e38173b33159b0e...
___________________________________________________________________
(page generated 2025-11-20 23:01 UTC)