If yes, this sounds a lot like the android side loading the Google just reversed

Just dropping this here for those who don't know about it. It solves most of my CLI dependencies.

Well!

Note: I think one problem of homebrew is called ... Apple. That is, they depend on whatever Apple decides.

Granted, this is similar to Microsoft; and to some extent to Linux, though people can make more modifications on Linux normally.

I am a Linux users so this does not affect me, and I also wrote my own "package" manager (basically just some ruby scripts to compile things from source), but at the same time I also think that at the end of the day, the user should decide what he or she wants. This is also why my scripts support systemd - I don't use/need systemd myself, but my tools should be agnostic, so I don't project my own opinion onto them.

There is of course a limitation, which is available time - often I just lack time to support xyz. But I keep that spirit alive - software should serve the human, not the other way around. (I have no substantial opinion on the feature itself here, that is to me it seems ok to remove it; the larger question is who dictates something onto users and what workarounds exist. Do workarounds exist? From reading the issue tracker, it seems the homebrew maintainers say that there are no workarounds, and thus it should be removed. If that is true then they have a point, but people also downvoted that, so perhaps there are workarounds - in which case these should be supported. I really don't know myself - to me apple is more like a glorified Windows, so basically the same. All software should be liberated eventually.)

Homebrew is removing --no-quarantine because:

Apple is killing Intel support.

Apple Silicon won’t run unsigned apps anyway.

Homebrew will soon require all apps to pass Gatekeeper.

They don’t want to help users bypass macOS security.

This is basically a security + future-compatibility cleanup.

I do recognize that there's a bit of ambiguity around when the "compiling" happens, since even the binaries being distributed are still being compiled from homebrew's formulas. The main point I was trying to make was that there was a transition from the "compile everything on the user's local machine when installing" model that homebrew started with to "use the pre-built binaries that homebrew has compiled in advance for installing when possible if the user hasn't specifically expressed they want to compile it themselves". To be clear, I think this is a good thing, and it's a pretty huge quality of life improvement, but I've noticed a few times over the years that this change seems to have not been as widely noticed as I'd expect given how visible it seemed to me even as someone who only uses MacOS on my work machines and not my personal ones. I still sometimes get frustrated with homebrew feeling a bit slow compared to my preferred Linux package manager, but overall it's become far faster and less error-prone over the past decade, and I think it's worth calling out efforts they've taken (like pre-compiling and distributing binaries) that have made a noticeable impact.

In some ways, I think I think understanding the previous efforts they've taken might even help explain why they've chosen not to put in the effort to work around the quarantine issues (e.g. by using local signing like some other comments on this story have mentioned); they're a volunteer project that, unlike most standard package manages for Linux distros, are not in a position where they can easily influence the development of the OS features that might be useful for them. It makes sense to me that the most valuable use of their efforts would be on things that aren't swimming against the current of where MacOS is going. Getting to the point where they could have seamless binary installations at all can't have been an easy task, and the infrastructure needed for it takes additional effort beyond the local compilation model (which still exists). If cutting down on the scope in one dimension makes it easier for them to continue providing the overall feature set they have, this seems like a worthwhile tradeoff to me.

That is the default on the internet, and even enforced. I'm merely saying that for average users (or power users even, who understand the risks) the default should be that the same guarantees apply to desktop apps as well (especially considering those usually have far more access).

HTTPS shows that such a world where people live with this restriction is possible and practical, and far from the jackbooted tyranny you describe.

Stability is an issue (as I tested it with M1 Pro throughout the years).

Not all of the hardware features are supported. For example no external monitors through the usb-c port.

Also the project seems somewhat dead, having some core developers leave the project.

I had high hopes for Asahi but currently it doesn't seem like it will ever be fully production ready for currently relevant hardware.

The M1 and M2 are still great laptops, so it's still a good experience if you're looking for a second-hand Linux laptop with Apple quality hardwre.

Even developer tools on Windows tend to be fairly graceful about you running Windows 7 or whatever.

Somehow Apple and their entire ecosystem has adopted this "Latest Version Or GTFO" attitude towards users and developers.

if you're good with tools that don't support global installs there are also Spack, Mise, and pkgx

none of those are quite suitable for managing macOS app bundles, though.

(Part /s, part not)

And because GPLv3 is incompatible with how Apple operates, they ship versions of pre-GPLv3 software like Bash 3.2.

Apple now ships openrsync [1] as a replacement for rsync due to licensing issues.

[1]: https://appleinsider.com/inside/macos-sequoia/tips/what-you-...

xattr -dr com.apple.quarantine /Applications/LibreWolf.app

If the homebrew team signed everything, they would immediately become a target for bad actors. The bad actors would flood homebrew with malicious binaries, which homebrew would auto-sign, users would download & run, and the bad actors would laugh all the way to the bank.

Users will need to `brew install myorg/mytap/appname` instead of just `brew install appname`, but I think that's the only real option at this point.

If that's not what you're saying then your point is effectively moot, because if indeed Apple's platform control gets too egregious for some individuals then those people will switch at that point so there's no point in panic-switching now just in case.

In other words, users will switch when what Apple is offering does not meet what those users require. Some users will literally never care because all the software they use is signed and gatekept and so on; some users have jumped ship already because they want to be able to change whatever they want whenever they want. If things continue to "slippery slope" then more people will hit their own tipping point but asserting that it's going to happen all at once and apply to everyone is nonsense.

It remains easy to disable Gatekeeper if you want. New MacBooks still allow you to install other OSes, even though that would be trivial to lock down with signed boot requirements.

So far, none of the frog in boiling water predictions have actually come true at all. It’s just people parroting the same conspiracy every time the word Gatekeeper comes up, just like we went through every time Secure Boot came up.

I eventually found on Reddit that setting the default via the Get Info dialog was the only path that worked, so now I can click a CSV and open it in VS Code without needing to send Apple my passport and fingerprints. I keep seeing mixed opinions whether it's a bug that Get Info associations work differently vs the right click context menu, or if it's a deliberately obtuse garden path like the Settings/Open Anyway routine and "working" as intended.

Either way I hate it but it would be slightly more forgivable as a bug (assuming it was then fixed).

My work issued MacBook is incapable of running unsigned binaries enforced by the MDM kext, and I do all sorts of development all day long. Occasionally I have to resign a precompiled dylib if it was compiled on a coworkers machines, but that’s it. I have never seen anything like you’re describing.

>I can't help but think, "Don't obey in advance."

They aren't obeying in advance. They simply aren't doing the work to find another Gatekeeper bypass for ARM64.

  xcode-select --install

So you haven’t had a Mac since 2017, but you believe all of us using Macs are stuck in some walled garden?

These comments are so weird. Gatekeeper can be turned off easily if that’s what you want. Most of us leave it on because it’s not actually a problem in practice. The homebrew change doesn’t even impact non-cask formulas.

Why isn't a binary condition valid? Isn't that the ethos inherent to a literal walled garden?

If you're inside, trust us. If you're outside, you don't, but don't expect us to bail you out.

> So in the name of "increased security" they've needlessly turned it into a binary thing where it's completely unprotected or accept my own computer that I paid for will deliberately waste my time constantly.

Remember when Apple made fun of Microsoft for doing exactly this? https://www.youtube.com/watch?v=8CwoluNRSSc

Funny, there's even some regression in layer backed NSView rendering where the app I'm working on is faster (in some aspects) in a macOS 15 VM than on bare metal under macOS 26.

> drive-by negativity by non-code-contributor users is the biggest existential threat

I do believe this, and it's what I was getting at with my "conditions a knee-jerk asshole response" comment. From the outside, I saw someone who wasn't being negative, but just seemed to have unaddressed concerns about the impact of the change. You, however, have been conditioned by hostile users over your many years of work to interpret this as negativity, because other, ruder people pile on to the valid concern in unhelpful ways, or the person with the concern wasn't willing to listen at all and just used a veneer of calm rationality to be a stick in the mud.

The point is, I get why you would be this way, but also that it doesn't look very good from the outside looking in. I know that you are doing unpaid labor and so nothing is owed, but still, both can be true.

I know some people don't like it, but I've always found discussions that are locked to collaborators only to be totally understandable for this reason. If you find yourself making "I know more about x than you ever will" comments to a person, you should probably instead just disregard them and carry on. Likewise, you do know more about x than I ever will, so you should probably just disregard me and carry on.

You could have just said this (maybe you did when linking the code of conduct) instead of writing a paragraph of confrontational arguments and it would have looked way better imho.

> You may think it hyperbolic but drive-by negativity by non-code-contributor users is the biggest existential risk to projects like Homebrew.

If this was true every oss project would either be dead or be entirely comprised of dicks, neither of which are the case.

your explanation did nothing to speak to being a dick, did not attempt to apologize, only tried to justify the poor behavior.

Although I should say that I haven’t tried to go back many major versions, I wonder if they provide 7.x for example.

That’s true but that’s probably only so that it wouldn’t have been a subject when Apple Silicon Macs were released because Intel Macs weren’t locked.

In reality, the bootloader isn’t closed (yet) but the hardware is so much undocumented that it’s easy to understand that Apple doesn’t want anything else than their OS on your mac. The « alternative os » situation is actually worse than it used to be with Intel Macs and Apple is paying a lot of attention in never talking about this "feature".

IMO, they will just quietly remove this possibility on new generations when everyone will have forgotten that boot camp used to be a thing.

Like not documenting their hardware? Like making Asahi Linux becoming a multi-year reverse engineering project that may possibly never achieve perfect compatibility?

> They make it easy to run Windows

On apple silicon without virtualisation? Sorry, didn't know that.

If you want something specific than that: the package manager cannot help you here. This is no longer some random thing that you just use; it's one of your product's honest-to-goodness dependencies. You can't outsource this any more. You need to make your own arrangements to ensure that the specific version required is in use.

"pro" users need EOL version support because sometimes some client still didn't want to update his age old web app the newest node or python or whatever. sometimes it's not up to the dev himself, and he needs to make money either way.

so in the end brew makes decisions for the most common denominator, and that will be the user that uses it to install youtube-dl and nothing more.

You can find a somewhat similar situation on Linux, with other non-Apple ARM hardware.

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.

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.

https://github.com/BatteredBunny/brew-nix

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.

1pass probably does this to ensure that people can't accidentally install the app the "wrong way" and break some features.

are you running < 15.1?