Comment by pxc
3 months ago
> 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.
As of today, I have 44 casks.
[1]: https://docs.brew.sh/Brew-Bundle-and-Brewfile
I do something similar. I bootstrap all my new installs with brew cask https://github.com/fastily/autobots/tree/master/macOS/setup
I bootstrap it using Brewfile (plaintext file read by Homebrew), which supports Casks too.
Same here.
1 reply →
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
1 reply →
Why can't you distribute it from the developer's website?
1 reply →
> nixpkgs maintainers are hardline purists
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.
The 1Password cask will almost certainly continue to work. 1Password distributes a signed installer.
3 replies →
Brew-Nix might be able to cover some of those gaps, but probably not all of them. But almost certainly SoftwareC, at least!
https://github.com/BatteredBunny/brew-nix
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.
Terraform is a notable example yeah. Takes like 7 minutes to compile it when you would get it in seconds by pulling the binary
1 reply →
> 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.
Spack is a really unfortunate name for a project given that it's a slur derived from 'spastic' in the UK.
Can you just "pronounce" it (even in your head) S-pack, as in "source package"?