> Most people I know are not installing too many casks
Casks are the only things Homebrew does that some other package manager available on macOS doesn't reliably do better. Nix, Pkgsrc, MacPorts, and (and now Spack) all have better fundamental designs;
sane, multi-user-friendly permissions; and enough isolation from the base system that they break neither each other nor manually-installed software.
I use Homebrew exclusively tucked away in isolated prefixes, only to install casks, and without ever putting any binaries it installs along the way on my PATH. I don't remember which programs it is, exactly, but I do use a few that are unsigned.
It also doesn't seem to me that the signing process is as vital in determining actual risk as the curation and moderation processes involved in maintaining "third-party" software distributions like Homebrew or Debian or whatever.
`--no-quarantine` in particular is one of the conveniences that makes Homebrew casks useful. If I have to give my consent anew for each app update, I might as well install the apps manually and live in the usual auto-update pop-up hell.
> Most people I know are not installing too many casks
I did a wipe and install of Tahoe like 2–3 weeks ago and used a Brewfile [1] I've had for years to install ~30 casks via Homebrew, including from the App Store, not to mention 50-60 formulas.
I haven't used Homebrew in a long time, but if I ever did it would be in the way that you describe (so far I've always found reasonable alternatives for the software I want). What I'm wondering is if this is entirely to support unsigned casks, why does Homebrew not simply resign the software itself at install time with an adhoc signature as though it had just built it?
Yeah, my nix-darwin config is pretty nice and perfectly hermetic and reproducible, save for a now-growing list of casks in my brew.nix that looks like this:
> 1password # breaks in nix, must go in /Applications folder
> softwareB # not available in nixpkgs
> softwareC # available in nixpkgs, but because nixpkgs
maintainers are hardline purists it takes 15 minutes to compile from source and ain't nobody got time for that
> softwareD # ostensibly available in nixpkgs, but the package is completely broken (more general case of 1password)
Why not wrap the binaries yourself in flake.nix you say? Well, sure, would love to, if it wasn't such a pain in the ass to do so for each one and keep them up to date.
> softwareC # available in nixpkgs, but because nixpkgs maintainers are hardline purists it takes 15 minutes to compile
What actually happened is that non free software may not be legal to distribute from nixpkgs caches, so you're on your own with building those. That's not really a purist approach.
Only because the purist inventors of nixpkgs structured the policy of what must go into nixpkgs to have this rule. Why doesn’t the same limitation exist for homebrew, for instance? It isn’t some idiosyncracy of the way they are building things, it was a conscious and deliberate policy decision.
And it might be the right one for what they are trying to achieve, but if the goal of the project is to make it more accessible and see more widespread adoption, stuff like this is a shot in the Achilles heel
> purist inventors of nixpkgs structured the policy of what must go into nixpkgs to have this rule
No. Both lib.licenses.unfree and lib.licenses.unfreeRedistributable are accepted into Nixpkgs, but the former marker indicates that the developer has declared it illegal to distribute builds so the official binary cache (sorry, “substituter”) does not.
What Homebrew likely does is fetch the upstream binaries from the upstream download server. Nixpkgs does have a policy against that when buildable source code is available, but that’s mostly because the way Nix achieves isolation (both from the host system and between packages) is by placing almost all shared libraries and data files in hash-decorated places that are emphatically different from what an upstream binary expects. On Linux, it’s possible, if very distasteful, to cram that peg into this hole using mount namespaces and bind mounts (see buildFHSEnv et al.); not sure about Darwin, but the general response to asking Nixpkgs maintainers to keep this sort of fragile mess working is, indeed, pretty much exactly “ain’t nobody got time for that”.
If something gets built it likely means the sources available in some way, just not opensource. There may be many reasons they're preferred over a binary.
On the contrary, Nixpkgs is generally made by the most pragmatic people and takes a flexible approach to a lot of issues. For instance, very few package managers have packages for proprietary software like 1Password in their official repositories. Nixpkgs also doesn't insist on building everything from source when it's hard to do so. As a result, Nixpkgs contains many packages for NPM or Maven projects. Other package managers insist on packaging all its dependencies from source, which is why they're struggling to package software written in modern programming languages.
As for 1Password, it works fine on NixOS. When installing proprietary GUI apps like 1Password on macOS, I just use Casks. I suspect many people do the same, which might lead to the 1Password package not working as well on macOS because fewer people bother with it.
The Nixpkgs community is internally diverse, but broadly values both "purity" and pragmatism. You can see debates and compromises play out in PRs all the time, or read traces of such careful weighing in the source code of Nixpkgs itself.
For the record, the Nix community's largest public cache doesn't cache binaries of proprietary software because doing so would be illegal— the public doesn't generally have the rights to redistribute proprietary software.
The phenomenon of having to compile free software from source via Nix typically happens when free software depends on proprietary software (which is common on macOS). Maybe this could be ameliorated on a technical level, but I think it's mostly historical accident and ease of implementation that got us to the current situation, where the whole dependency tree has to have a free license for something to make it into the binary cache.
Yes the cask is fine. The problem with 1pass installed via nix is that it doesn’t put it in applications folder because that defeats the hermeticity of the solution. However the 1Password devs designed the binary on Mac to only boot out of applications folder, presumably for security reasons. Most other apps you can get around this by setting up trampoline links to the nix store versions, but if the app straight up refuses to boot anywhere else besides applications folder, you can’t use the typical nix installation path
IIRC there are some macOS APIs that you can only access if your app runs out of /Applications. There are some features of an app called "Secretive" (an SSH agent that stores keys in the Secure Enclave) that only work if you have the app installed under /Applications (whereas I'd normally install it under ~/Applications).
1pass probably does this to ensure that people can't accidentally install the app the "wrong way" and break some features.
Yep. It goes back to “some things nix does are straight up exclusive to the way macOS needs things to be”, as long as that dichotomy exists nix-Darwin will always have hacky idiosyncrasies like this. It’s not an easily solved problem, and it’s not necessarily Nix’s or Apple’s problem to fix. It’s just two antithetical design philosophies. I would love to see Apple support that kind of sandboxing Nix offers here for these apps though
What he is doing in there is kinda cool but the trampoline app solution is quite similar and unfortunately does not fix this problem. Fundamentally the problem is that when you install stuff with nix it gets a folder that is unique to that nix generation. That is by design nix, because you want to be able to go back and forth between generations etc. Apple does not think of things the same way. Applications is a single folder that you can’t subdivide with iterations and it’s “speshul”. These core philosophies are antithetical to each other. This is fine for Most applications who don’t need to be in Applications. You let Nix install into its own little /nix/ generation folder and then create a “trampoline” in applications which is basically like a symlink. Then your app shows up in spotlight etc. where this falls apart is applications like 1Password that MUST boot from the speshul Applications folder
However, you are right, it definitely makes some other pieces of this cleaner. In particular, if you just use homebrew directly with nix, you aren't deterministic or reproducible. You have an impure setup because if you remove a cask from the list, it doesn't actually delete it from homebrew, and you can't go back and forth with generations because homebrew is stuffing things in /applications. The project you linked forces brew stuff to behave like Nix applications and go in /nix instead, which allows it to be able to walk between generations. So it solves most of the issues with brew and nix but not all of them.
> softwareC # available in nixpkgs, but because nixpkgs maintainers are hardline purists it takes 15 minutes to compile from source and ain't nobody got time for that
Which package is that? Is it proprietary but source available? Any free software which is built from source is built by hydra and available from the binary cache to downstream users.
When Hashicorp did their rug pull, I just switched my team to OpenTofu as soon as it had a stable release. No regrets; it's been great. (I did evaluate both projects at that time, of course. But it ended up being a clear decision.)
> If I have to give my consent anew for each app update, I might as well install the apps manually and live in the usual auto-update pop-up hell.
Really? That's a whole lot of UI actions/clicks (and a variable number per .app) versus ... I think two always-the-same UI actions at most. Not like, a huge hassle either way, but I have trouble seeing how Homebrew's not still the winner here even without quarantine bypassing.
Casks are the only things Homebrew does that some other package manager available on macOS doesn't reliably do better. Nix, Pkgsrc, MacPorts, and (and now Spack) all have better fundamental designs; sane, multi-user-friendly permissions; and enough isolation from the base system that they break neither each other nor manually-installed software.
I use Homebrew exclusively tucked away in isolated prefixes, only to install casks, and without ever putting any binaries it installs along the way on my PATH. I don't remember which programs it is, exactly, but I do use a few that are unsigned.
It also doesn't seem to me that the signing process is as vital in determining actual risk as the curation and moderation processes involved in maintaining "third-party" software distributions like Homebrew or Debian or whatever.
`--no-quarantine` in particular is one of the conveniences that makes Homebrew casks useful. If I have to give my consent anew for each app update, I might as well install the apps manually and live in the usual auto-update pop-up hell.