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.
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)
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.
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.
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.
I've not had much of a problem with Time Machine. It works as advertised and does so quietly and without much input. The only thing I've had to do is turn off scheduled backups, as it tries to do a backup while I'm on a slow connection. This is because it can still see my NAS over Tailscale. I just put the menubar icon up there and trigger it when I get home.
I wonder if most folks have different expectations from it. Most of the HN crowd are probably already familiar with the usual suspects, so the lack of options and visibility into the process are probably concerns. For most folks, though, I imagine it's turn it on and forget it.
`<thead>` and `<tfoot>`, too, if they're needed. I try to use all the free stuff that HTML gives you without needing to reach for JS. It's a surprising amount. Coupled with CSS and you can get pretty far without needing anything. Even just having `<template>` with minimal JS enables a ton of 'interactivity'.
macOS isn't Linux, and as much as I _absolutely support_ the XDG BaseDir spec, I don't think it's fair to try and apply it to macOS. Linux has no 'proper' directory for storing configuration, cache and application user data. macOS and Windows _do_. It's only proper to support those systems in the way that they intend. I wouldn't put stuff in to `%HOME%\.config` on Windows any more than I would put data in `$HOME/.Application Data/Local/` on Linux. Why would macOS get bundled in with Linux? Because it's a unix? That's silly.
Personally, I have my zsh config repoint those directories into `~/Library/Application Data`, though (as some have pointed out) it's probably better to put some of those folders in `~/Library/Preferences`.
I kinda wonder if this is an age thing as the English language morphs over time.
I'm a bit old school, I like the XDG standard, but the arguments against "~/Library/Application Support" don't make sense to me.
The people arguing against it are saying that a program that uses the CLI is not an "App". That argument seems wrong. App is short for "application" and I've been using the long form of that term since before the GUI even existed. A command line application is still an App in my mind.
---
It looks like Finder only treats files with an .app extension as "App Bundles" by showing an icon for them. But Apple seems to be careful with their language around macOS and (usually) calls these either "App Bundles" or "Bundles" and not "Apps" or "Applications". That's not always the case though. Here are some quotes from their docs:
> A bundle is a directory with a standardized hierarchical structure that holds executable code and the resources used by that code.
> In this document the term app refers to a main executable packaged in a bundle structure. This encompasses apps, app extensions, App Clips, system extensions...
It's even in the name: a command line application. The disconnect comes from Apple adopting the term "app" when they launched the App Store in 2008. And the aggressive marketing campaign with phrases like "there's an app for that". The word changed (in some minds) from meaning "any executable" to one that is on a phone.
Before they rebased onto UNIX, Mac files had two parts: a data fork and a resource fork. Data had the binary. Resource had strings, images, and other assets that the binary needed.
It was great for local portability: you could put the file wherever you wanted, and it would still be colocated with its stuff. It was bad for network portability, because a lot of transport layers didn't respect the forks.
So Apple migrated to bundles - magic folders that look like a single file in the Finder, but contain all the resources it might need.
> Why would macOS get bundled in with Linux? Because it's a unix? That's silly.
I'm somewhat on the fence about this topic in general & I think you've hit upon why. This isn't silly. At all.
Linux & Mac environments are by no means compatible but for anyone who cares about the location of their dotfiles, the two systems have demonstrably been "compatible enough". To the point that having coordinated standards on some aspects of (at the very least cli) applications would invariably be a net positive for users of both systems.
I run a Linux desktop & a Mac laptop between which I sync dotfiles & personal scripts. The scripts I sync work seamlessly on Linux & BSD systems because the incompatibilities are eminently manageable, so the topic of this post is definitely an inconvenience for me. I'm sure I'm not the only one.
Plenty of commenters are using Windows as a comparator stating "you wouldn't expect this in Windows" but in actual fact, I would like to have this in WSL2 (if I ever had a Windows machine). Powershell & CMD have never had anything resembling Unix compat so for those this is irrelevant, but Windows isn't a monolith.
In fact the more I read arguments against this in HN comments, the more I'm being persuaded to come off the fence & argue that XDG should be a *nix standard rather than a Linux one.
Though the flip side of my own subjective take here is that "home directory dotfile vomit" has just never seemed as big an issue to me as many make out.
> Though the flip side of my own subjective take here is that "home directory dotfile vomit" has just never seemed as big an issue to me as many make out.
When I first switched from Windows to Ubuntu, I considered it an amazing feature for discoverability, especially since there was a pretty reliable pattern of using the executable's name for the dotfile/dir.
> Though the flip side of my own subjective take here is that "home directory dotfile vomit" has just never seemed as big an issue to me as many make out.
This is a fair take, and something that I've considered when going down the obsessively organized path.
Does it _ultimately_ matter? No, of course not. A file is a file is a file and if it's located in $HOME or $HOME/.config is immaterial to the OS and, generally, a program. Just so long as it can be read and written to is ultimately what _matters_.
However. Insofar as directories are a construct for humans to mentally parse out and organize data that may be just abstractly written to any number of non-consecutive sectors on a disk, _I'd_ like to at least have a clean mental image of "where" that data is. Apparently, enough people had that same idea and started the excellent XDG spec.
> This isn't silly. At all.
I will grant you that it's pedantic. Both are POSIX-esque systems and to a large degree, talk the same way and expose the underlying infrastructure in a similar manner. However, I think ignoring the platform's preferred organizational methodology is doing a disservice to the end user. If the user wants a vomit of hundreds of .<whatever> files in their home directory, fine, I'm not your mom. You do you, but I think you should follow the law of least surprise and put things where they're _supposed_ to go, first, then if over-riden, then follow the user.
> but Windows isn't a monolith
It is the very definition of said. There is only one version of Windows, and any marketing faff about different editions are just different coats of paint on the same underlying system. Windows is Windows. You don't have Windows on ARM supporting %HOME%\.datadir\local\system\noreally instead of "AppData". You have AppData and that's it. You can bank on it being the same across all versions of Windows that are still in production, even going back a long way.
WSL1/2 are bolt ons that should behave differently. They're emulating a foreign system, configuration should be stored within, to whatever specification that happens to be.
It's a stretch to say /var is for application _user_ data. For a certain value of "user" sure, like MariaDB or Redis. They're "users", and have data in /var but it's a non-interactive session.
User data is stored in the user's $HOME, of which none of those locations are, generally, writable to an end-user, and wouldn't be a place to permanently store that data.
Had a chuckle at "classic Linux-first development", it's every OS except Windows - Windows is the outlier here, and I know plenty of engineers (myself included) which have no interest in trying to make things work in the Windows ecosystem. So I guess in the same way that roads are "classic wheel-first infrastructure", you don't try to pave a swamp.
What about Android? The only thing Android shares with Linux is the kernel; the entire user mode environment is completely different, and this includes how 'users' and their data are handled. What about automotive stuff like VxWorks?
> I know plenty of engineers (myself included) which have no interest in trying to make things work in the Windows ecosystem.
Good for you; then why even bother releasing stuff for Windows? Because it checks the 'here's your Windows release, now bugger off' box? As a parent commenter says,
> it is because they thought 'with -target darwin I don't get any compilation errors. ship it!'
What happened to actually caring about users, their expectations, and user-friendliness, without worrying about platform dogmas?
As an aside, Windows has the objectively superior filesystem permissions model. It supports a massive variety of access modes, uses ACLs by default, and this is what allows straightforward fleet management with AD. It is easier to map down Windows ACLs to POSIX octal file permissions than to map up the reverse.
You must be aware that ACLs are well supported by all major UNIX operating systems (yes, Linux is UNIX, there are/were two general-purpose Linux distributions certified as UNIX). It's just that basically nobody is using them because they're rarely necessary, and there are easier ways to implement access control if you want something simpler, and also far more powerful mechanisms for when that's needed.
It's hard to tell how your commment was a sincere response rather than derision for anyone using or targeting Windows. There was nothing technical. Here's a technical response:
There's nothing 'hidden' about dotfiles on UNIX-likes, unlike on Windows where, as I mentioned, there is such a thing that is exposed by the OS filesystem API (it's a normal attribute and can be straightforwardly set/unset with right-click -> Properties; not an extended attribute which refers to a very specific thing).
That files and directories beginning with a full stop are hidden in `ls` was openly acknowledged as a bug[1] in the original implementation, that gave rise to 'a bad precedent'. Ergo all the repeated gnashing of teeth (see this very article) by UNIX-like consumers who end up noticing the dotfiles anyway, because a significant plurality of people use a variant of `ls -la` for the utility of its tabular output.
It's standard convention for (mostly GUI) applications to visually hide files and directories that start with a ., I don't know what you think a hidden folder is if it's not this and it has been widely accepted in the industry as a whole (except in Windows) for a very long time.
What you seem to be confusing it with is file system ACLs, something that *nix for quite some time. In fact it was available on consumer desktop environments in the early 2000s - roughly the same era as Windows (when Microsoft brought their NTFS filesystem to the desktop).
Anyway, don't feed the trolls and all that, you're welcome to enjoy your windows ecosystem - just don't expect all engineers to write their software specifically to cater for it.
I am confused. My point was that if engineers target Windows at all, they ought to do it properly, but you retorted with 'I don't target Windows'. Okay, well and good, then my advice isn't for you and developers like you.
Then again, you said 'don't expect all engineers to write their software specifically to cater for it', seemingly ignoring my and essentially every parent commenter's plea for developers targeting non-Linux platforms to be good citizens on that platform, and adopt platform conventions. If you're not writing software for Windows, then sure, no need to think about Windows. If you are, or you are going to, then this platform convention business needs to happen and needs to be done correctly, whatever your thoughts on Windows, or, in the thread's case, macOS, where application data should go in `~/Library/Application\ Support` and not dot-dirs in $HOME.
The conversation digressed into cherry-picking my explanation of 'hidden file'. I'm not sure the troll epithet is fair.
> Windows is the outlier here, and I know plenty of engineers (myself included) which have no interest in trying to make things work in the Windows ecosystem.
... But it's still much larger than everything else put together, no?
Not for servers, containers, embedded or IoT devices which is the vast majority of the internet.
I'm not sure what a reliable way of counting for developer machines would be but I'd doubt it'd be anything like it was in the 90s and early 2000s - as a consultant it's pretty rare that I'd see a developer running windows these days, even big old enterprises like banks and insurance seem to be largely Mac for technical users it seems. I have no doubt that I'll have some folks jump on this comment and disagree stating they see the opposite and I'm in a bubble - but that is the honest truth (at least here in Australia anyway).
Personally (and most people I know) see windows as user stuff. Not developer stuff. So CLI tools etc are linux/mac-first. Lots of projects I find nowadays don't even have a windows build...
On the other end, when Windows first started having multiple users and locking down write access to system directories (*), lots of video games (and some other programs besides) decided to just dump their files anywhere. Just looking at my own system, I see all of the following used:
%userprofile%\Documents (which used to be called "My Documents")
%userprofile%\Documents\My Games
%userprofile%\Documents\Saved Games
%userprofile%\Documents\SavedGames
%userprofile%\Saved Games
%appdata%
%userprofile%\AppData\LocalLow
%localappdata%
As far as I can tell, there's no rhyme or reason to any of this. I know the three AppData folders have distinct meanings, but I don't think video game developers are using them according to their proper meanings. Also, I'm being generous with my use of variables above. Some programs have hardcoded the drive letters and paths.
* = I'm well aware of the real history of Windows NT but from the consumer perspective it went from 98/Me -> XP
Unfortunately, there is a reason. During the Vista timeframe, Microsoft published guidance recommending that game developers use the Documents folder for save games, as part of the push to make games compatible with UAC and non-elevated user accounts.
Yeah, the Windows directory story is a mess. Of all the vaunted backwards compatibility they offer, there are some very strange user-facing breaks that don't make much sense. The Home directory structure being one of them.
%APPDATA% is _fairly_ consistent for the past ~20 years. Local and LocalLow are odd distinctions, but have some interesting backgrounds. I don't find many programs abusing them. Roaming being the only real oddball that I find preferences for that aren't overridden by one of the other two folders.
Oh, I'm well aware of this on Windows. It's stupid and easy enough to fix for the developer, but I'm also aware there is virtually no desire to implement.
Free software developers are rarely interested in spending time on supporting unusual proprietary operating systems. You should be grateful all this software works there at all — some Windows users did not just moan on internet forums, but actually went and implemented support for their OS of choice in all these packages.
I feel like most folks misunderstand Eshell when going into it. It's not really their fault, as they _expect_ something bash-like, and in many ways it is. However, Eshell is _not_ bash. It's not zsh. It's not fish. It's Eshell. When you use Eshell, you get a marriage of command-line tools and Emacs. This isn't always the best case, and some tools are awful to try and use in Eshell.
Eshell shines when you're looking to use Emacs to do stuff in the shell, but not really deal with the shell itself. It will dutifully run whatever program you feed it, but the real magic is when you want to deal with the output. You can redirect outputs to buffers, which you can then manipulate with Emacs familiarity. You can even handle remote sessions just as easily as you would open a remote file in TRAMP. I've used this on many occasions to edit a remote config file, then trigger Eshell, which puts me in that directory, to then restart the service without having to launch a separate SSH session or terminal.
While there are a lot of clunky bits of Emacs, I feel like Eshell gets an especially bad rap. Some of it's justified: It presents itself as a bash-like interface, while actually having vastly different ways of handling things. I feel like folks don't really get the idea that it's an interactive Emacs session, a worksheet for the command-line that lets you ingest data from external tools in a more ergonomic way than doing `shell-command` or similar.
Yes it may be the case that the achilles heel of Eshell is that it tries to be too bash-like. Just making it clear that this is an "elisp thing that interacts with both emacs and your system" and call it "dialog" or "interactive scripter" or something and dispense with following normal shell conventions (while still offering tab completion etc) might have been wiser.
I honestly wish this were the case for 80% of the calls I make to local stores. Most people they have working the phones do not care about the inventory and will just say they're out of stock or don't know if there are any on the shelves. This goes double for requesting a special item from a store that would normally carry it, but doesn't. They put the order into their "system" and then it disappears, never to be heard from again.
Calling retail stores to do anything other than to see if they're open or, in the case of restaurants, get a reservation is just wasting time. At least for the retailers that I've communicated with.
It's responsibility-washing. Like GP said, those answers are totally unacceptable coming from an engineering professional. Which is exactly why they took on interns to do it.
Neat, this looks a lot like the Linux-focused Profile Sync Daemon[1], which can move your profile to a RAM-backed tmpfs. PSD does more browsers, though. I wonder if PSD could work on macOS, too.
The reason I created this was because I missed the profile sync daemons commonly found in Linux. I haven’t looked into this specific one, but most available solutions are Linux-only.
reply