8 ms·
Homebrew 7.0.0
- pietz 19d agoThanks for the hard work, but the Tahoe limitation for the GUI app is absolutely ridiculous.
- mikemcquaid 20d agoToday, I’m proud to announce Homebrew 7.0.0. The most significant changes since 6.0.0 are faster installations and upgrades, stronger sandboxing, a native macOS app, built-in vulnerability checks and an advisory database, the end of macOS 10.15 support and Intel Macs moving to Tier 3 (announced last year).
- d3Xt3r 20d agoLiterally just upgraded before seeing this post; I had 31 outdated packages and the first thing I saw was how blazing fast it was! I looked online to see if something changed and saw this post. Speed was my biggest complaint about brew, so I'm glad to cross that one off my list of things I don't like about brew. Thank you for your hard work BTW, brew's been a lifesaver on macOS and immutable distros.
- mikemcquaid 20d agoGlad to hear it. A lot of time and energy has gone into performance work so glad that’s noticeable! Thanks for the kid words too <3
- bitexploder 19d agoIt is Rust now?
- staplung 19d agoIt's still in ruby, although I see the new GUI is in swift: https://github.com/homebrew https://github.com/homebrew Rewriting a program in Rust (specifically) really only makes sense for a few reasons: 1) the existing implementation is in an unsafe, cumbersome language (C, C++). 2) the existing implementation language is too slow and that slowness cannot be worked around. 3) the implementation is enormous, in a dynamic language and you desperately need stricter types. But this doesn't really favor Rust specifically. 1 doesn't apply because Ruby is garbage collected. It's doubtful 2 applies just given what homebrew does: the long pole is always going to be I/O. The performance improvements in version 7 seem to mostly be due to doing more concurrently. I highly doubt the Ruby-ness gets meaningfully in the way.
- bitexploder 19d agoI was kinda kidding because parent called it "blazing" fast lol. I didn't think it was Rust. Blazing fast software is reserved as a descriptor for Rust programs :)
- jdxcode 19d agoi just tested and `mise bootstrap` is over twice as fast at installing when a bottle was in the cache. other commands like `status/check` are 20-30x faster. that's without spending much work at all on perf—i'm sure i could bring these numbers down much further.
- lukeify 20d agoI don't know what I would do without brew on my Macs. Thank you and everyone who contributes!
- lifty 19d agoI think at one point you said you’re working on a rust rewrite? Is that still in the cards?
- sillywalk 19d agohttps://fishshell.com/blog/rustport/ https://fishshell.com/blog/rustport/ Fish 4.0: The Fish of Theseus (fishshell.com) 906 points by jdxcode on Dec 28, 2024 | hide | past | favorite | 198 comments https://news.ycombinator.com/item?id=42535217 https://news.ycombinator.com/item?id=42535217
- mikemcquaid 19d agoI tried it. It ended up being slower on most non-synthetic benchmarks (like repeatedly installing the same thing with warm caches). The lessons learned were instead used to make the Ruby frontend much faster.
- clumsysmurf 19d agoI don't know anything about homebrew, but have a question ... I see some parallels between homebrew and Gradle ... for the longest time Gradle was using Groovy for build scripts. The Gradle / Groovy build script DSL was a little too magic and dynamically typed. It looked cute, but led to issues in developer UX (awful stack traces), tooling (documentation and autocomplete), robustness, and performance. There are other reasons why Gradle is moving away from Groovy. I suspect that the number of people that use and know Groovy is steadily declining. Declarative Gradle, which is the future, is not Turing complete. I can't help but notice the parallels between Gradle / Groovy and Homebrew / Ruby: using a dynamically typed Ruby DSL with Turing completeness like the olden Gradle ways, and Ruby is declining in popularity like Groovy. I would have to imagine at some point, the people who know Ruby well enough to create / debug formulae will dwindle. What are the plans?
- robertlagrant 19d ago> I suspect that the number of people that use and know Groovy is steadily declining One big surprise for me at a genomics/bioinformatics company was that of the three main technologies for orchestating bioinformatics workflows, Snakemake, Cromwell, and Nextflow, Nextflow was in a language based on Groovy. It took me back.
- mikae1 19d agoThank you for Linux Homebrew! It works so damn well. For me the distro package manager is for system packages, Homebrew and Flatpak for the user facing apps.
- curt15 19d agoWhere do you draw the line between system packages and user facing apps? Some software defies such an easy categorization. If your default install doesn't come with docker and you install docker later for development, does that make docker a user-facing app? What about language toolchains like golang, rust, npm, etc?
- mikae1 19d ago> Where do you draw the line between system packages and user facing apps? If it works in Homebrew, I almost always pick Homebrew. :) I have a pretty good feeling for what works since for the past few years I've mostly used an atomic distro (Aurora, based on Universal Blue, based on Fedora). It just comes naturally for me on Fedora too. I've found that this way you can get many of the stability pros of using an atomic distro even on a non-atomic one.
- setopt 19d ago> I've found that this way you can get many of the stability pros of using an atomic distro even on a non-atomic one. Digression, but I’m curious since you brought it up: Are you saying that Silverblue-based distros are noticeably more stable than Fedora? Or is it more a theoretical benefit, that you believe more in the long-term stability of that architecture?
- mikae1 19d ago> Are you saying that Silverblue-based distros are noticeably more stable than Fedora? TBH, I can only say it's far more stable than openSUSE, Ubuntu and Manjaro which are the non-atomic distros I've used for a long time. Aurora has never broken and I've never had any major problems that I can recall in over two years. I never initiate updates of the system, my Flatpaks or Homebrew. That happens in the background and whenever i restart (without me noticing). It's Linux for those who have work to do and don't want to be a sysadmin for their desktop.
- darkamaul 19d agoSilly question - but how do you apply the cooldown to brew itself ? I would think this is one of the most critical dependency that you would not want to get right away at let it rest for a couple of days
- mikemcquaid 19d agoYou can’t, by design. We instead apply if for you on upstream packages from NPM, PyPi, etc. Our model is very different to those where cooldowns exist and make sense. As-is if would just delay security updates too.
- larodi 19d agowould you please share what amount of the new dev (work done on brew) is AI/LLM-assisted. this major version bump was very quick to arrive compared to when v6 got released?
- mikemcquaid 19d agoCan’t speak for others but a lot of my work. I review it all locally first. The flow feels a lot like reviewing human PRs locally. https://github.com/MikeMcQuaid/AgentIDE https://github.com/MikeMcQuaid/AgentIDE I actually wrote my own “Agent IDE” to make this prompt/review/push flow easier.
- larodi 19d agoThank you, very insightful. TBH, expected an actual flow of nonsense and suspicion meanwhile, but a daly later there is still none, perhaps the general sentiment already shifted enough. It also confirms the notion that the credibility of the author is more important than the credibility of the means to develop. Also, of course, we're all going to move to newer brew sooner or later, so this all effort is much appreciated.
- threecheese 19d agoLooks cool! Building. `The macOS deployment target is set to 27.0, but the range of supported ....` Golden Gate AAAAAARRRGGGHHHHHH Just another few days, right? :)
- jdorfman 19d agoCongrats and thank you to you and your team for maintaining critical infrastructure we all take for granted.
- animanoir 19d ago[dead]
- e40 19d agoDefinitely notice the speed increase. Thank you for Homebrew. It's one thing that makes macOS bearable.
- dostick 18d agoWas issue with upgrade running out of disk space fixed?
- touwer 19d agoFantastic, thx for the effort!
- roger_ 19d agoDoes installation still require root and a dedicated user account on Linux? That really put me off.
- wscott 19d agoThe dedicated user isn't really required; it just expects that /home/linuxbrew/.linuxbrew exists. That can just be a symlink to your home directory. But yes, creating that symlink requires root on most systems. Brew itself doesn't require root or that pathname; you can put packages anywhere, but then many will have to be built from scratch since the pre-built packages don't work. And you need bubblewrap installed (which requires root) to use the sandbox, but again that is optional. All that said, when you are running without a sandbox installing to a nonstandard location, not everything works consistently. I run this mode all the time. But it has been getting better.
- trallnag 19d agoBubblewrap is history starting with 7.0.0 according to the release notes
- dghlsakjg 19d agoThe dedicated user account is optional. It uses root once to chown its prefix directory /home/linuxbrew/.linuxbrew
- mikemcquaid 19d agoSee the release notes: we now have experimental support for using any prefix shorter than the Linux default. We are aiming to eventually fully support (Tier 1) any prefix under 64 bytes long.
- mort96 19d agoWait what? Why prefix length limits? Linux paths can be 4096 bytes long, I can't imagine y'all are hitting that?
- yard2010 19d agoThank you so much for doing this, for years you make me feel like home, or the year 2010. Please don't ever stop!
- basedpolymer 19d agoAnd that's the end of Homebrew for me as a user. I like the app, but my old Intel MacBook apparently can't handle it anymore. I'm back to the old installation methods !
- yladiz 19d agoHow long do you expect them to support Intel processors though? It’s been like 6 years since the last MacBook release had any Intel processor, and Apple doesn’t make OS updates anymore, so it doesn’t surprise me that Homebrew stopped too.
- basiliobeltran 19d agoI have one of the last Intel Macs and works perfectly fine (on Sonoma). How long should I expect working tech being supported? I am already looking at Linux, but still need to get out of the Apple ecosystem. I am not going to spend +2500 Euros every 5 years on a laptop
- lnenad 19d agoWhat does saying "working tech" do for you? If I have a working Samsung CRT from 25 years ago do I ping them about smart TV support? Nowadays it's a shitty situation with planned obsolescence; but 6 years for an open source project dedicating resources to a dead end is more than enough and appreciated.
- deleted 19d ago[deleted]
- mrpippy 19d agoSonoma will be getting its last security update imminently (possibly tomorrow).
- watermelon0 19d agoAre you implying that a 6 year old hardware is as good as a paperweight? Outside of the Apple fairyland this is just bonkers. I'm not blaming the Homebrew project/developers here, but the fact that many people are okay with deprecating perfectly fine hardware.
- asadhaider 19d agoAwesome, I just checked and had already upgraded at some point. I run the alias command below every now and then which keeps everything up to date. alias u="brew update && brew upgrade --greedy -y && brew upgrade --cask -y && brew cleanup"
- aydgn 19d agoFarewell, Homebrew. It's been a good run. - 2019 Intel iMac user.
- mikemcquaid 19d agoSorry we couldn’t support this for longer :( From the release notes: > The Intel support decision reflects the limits of a volunteer-run project: Apple have dropped Intel x86_64 support from macOS 27 Golden Gate and GitHub Actions will retire Intel macOS runners in autumn 2027. If Apple and Microsoft’s GitHub, two of the world’s largest technology companies, cannot continue supporting macOS Intel x86_64, sadly neither can Homebrew. MacPorts still supports macOS Intel x86_64 and is likely to provide better results on this platform.
- eu 19d agovery disappointed about this
- xtracto 19d agoI think they would be able to support older architectures under a paid contract if absolutely needed, for the right price. Other than that, I'm grateful for the free software.
- jezek2 19d agoHow come that MacPorts supports macOS versions all the way back to 10.5 Leopard in the latest version?
- AbuAssar 19d agothe gui homebrew manager is a nice addition! it can be installed with: brew install homebrew-app
- deleted 19d ago[deleted]
- max979 19d agoTime to `brew update && brew upgrade` later today. Always a little nervous, but Homebrew usually makes it painless.
- inatreecrown2 19d agoI have this bound to an alias: bu Run it every couple of days, easy peasy.
- x3n0ph3n3 19d agoIf you're going to update that frequently, you may want to consider something that allows for cooldown like this [1]. I've gotten more nervous about supply-chain attacks over the last few months. 1. https://github.com/whoschek/homebrew-cooldown https://github.com/whoschek/homebrew-cooldown
- inatreecrown2 19d agoThat's a very good idea. Thanks for the link. Ideally this should be a feature in homebrew.
- x3n0ph3n3 19d agoIt absolutely should be.
- lrvick 19d ago[flagged]
- mikemcquaid 19d agohttps://docs.brew.sh/Homebrew-Security-and-Supply-Chain https://docs.brew.sh/Homebrew-Security-and-Supply-Chain We take supply chain security very seriously, moreso than many package managers.
- lrvick 19d agoI hate to have to be this harsh as it is clear you did a lot of work, but I have warned members of the brew team about serious gaps here multiple times over the years and seemingly nothing has been done. Brew is not anywhere close to a level of supply chain security to be allowed anywhere near production access or production code review. Language package managers are a joke and not worth comparing to but at least we can quarantine those. No security conscious person would run NPM outside of a VM or a container with code they did not review. But brew is a system package manager so the risk is not comparable. It might be the thing that installs the VM or container tools in the first place, so users have little way to protect themselves. Your setup is based on the honor system and it is important people know that so they do not use it on any system they need to be able to trust. If I were to create a fake identity and contribute my way to becoming a brew maintainer, I would have the power to create yet another pseudonym to submit malicious code that I "review" and merge. Or since builds are mostly not reproducible a compromise of a single CI/CD pipeline could inject a trusting trust attack into a dependency of a dependency of the compiler, and then I own every downstream system that uses brew forever even after version updates. Or maybe I compromised the github credentials of a single engineer and did a merge as them at the right moment when they were doing a bunch of others to get it lost in the noise. Without signing impersonation is easy. I would not actually do any of these things, but someone else could have already, a year ago. You will never solve any of these holes without full source bootstrapping, deterministic builds, mandating every maintainer sign every commit, and review with a well known and pinned keys individually controlled on smartcards, and then also sign every binary artifact with multiple keys after independent reproducible builds. This is the bare minimum for a system package manager. Comparing ourselves to others does not cut it anymore, because patient humans and AI bots will absolutely take advantage of honor system security models. Implying brew is secure enough for production use is going to get people hurt. A responsible system package manager must trust no single human, no single credential, and no single machine.
- Sytten 19d agoI found that Mise handles all my needs for development and it is scoped so it doesn't try to update Python and break all my virtual env when I install something new /shrug
- hk1337 19d agoI split my usage. Homebrew for OS things mise for the various tooling. The only problem some things still have a dependency on requiring python and others on the system. The problem being that they’re there, mise works just fine.
- impulser_ 19d agoYou can use mise for install homebrew items btw so if you get a new computer you just drop the config.toml inside the mise and install. This is all you have to add to the config file: [bootstrap.packages] "brew:git" = "latest" "brew-cask:ghostty" = "latest"
- threecheese 19d agoHomebrew does this as well, I keep my packages synced with a Brewfile in chezmoi. Obv this only works for brewed packages though.
- 9dev 19d agoWhy would you even use python without uv anymore, and have a system python binary and virtual envs linked to it?
- gdevenyi 19d agoDoes it still need root on Linux? That makes it an instant no go.
- mikemcquaid 19d agoFor initial installation to the default prefix someone needs to create the home directory and that person is probably root. We hope to allow all prefixes under 64 bytes in future.
- internet2000 19d agoThe GUI is pretty sharp, but I don’t like it uses emoji instead of SF symbols. Is it Claude or Codex built?
- illiac786 19d agoI don’t get these questions asking if it’s codex or Claude – I see them often. Does it matter? There are other options out there also, it feels strange to ask this. Like asking “is your car a Toyota or a BMW?“
- csande17 19d agoIf you say "AI tools", some vibe-coders try to equivocate between tools that generate the whole program for you and, like, an editor that uses an scoring algorithm to decide which method to show at the top of an autocomplete list. But if you say "vibe coding", some vibe-coders try to claim that what they're doing technically isn't vibe coding because they applied some non-zero amount of testing or review during the process. If you ask "did you build this using Codex or Claude", it removes most of the wiggle room. And it's worded pretty neutrally, so it will often get vibe-coders who aren't technically using either of those tools to say something like, "Actually, I've built a custom harness for DeepSeek..." instead of an outright denial.
- tbeseda 19d agoLong term it matters very much if your car is Toyota or BMW or Kia or John Deere though. I think some users are also conscious about the longevity of their tooling related to LLM usage, too. Whether it has an effect or not, we've yet to find out.
- illiac786 19d agoMy point was “why do you assume it’s one of the two”.
- deleted 19d ago[deleted]
- launchkitcodes 19d ago[dead]
- blixt 19d agoI was surprised to see my Homebrew consider my macOS a Tier 2 for using the very latest macOS version and Xcode version… But I think it's because I don't have Xcode 27.0, which is presumably releasing tomorrow?
- illiac786 19d agoWhat is the impact of being tier 2? I’ll update Xcode, but I will definitely not install macOS 27.0
- mikemcquaid 19d agoThis is a bug, sorry. Working on it.
- mikemcquaid 19d agoFixed and in 7.0.1.
- gwking 19d agoYou can download Xcode 27 RC now from https://developer.apple.com/download/applications/ https://developer.apple.com/download/applications/.
- simonw 19d agoTIL Homebrew has its own sandbox mechanism - looks like it's built around their own sandbox-exec wrapper, at least on macOS: https://github.com/Homebrew/brew/blob/d79ef822ab8136e393ed5f86e2b56afc68d04874/Library/Homebrew/sandbox.rb#L227 https://github.com/Homebrew/brew/blob/d79ef822ab8136e393ed5f...
- mikemcquaid 19d agoYup! We’ve been using it for a really long time at this point. Were using Bubblewrap on Linux and moved to Landlock this release. P.S. HUGE fan of your blog and writing Simon, keep up the great work. It’s the #1 resource I recommend to anyone in the industry wanting to learn more about LLMs (and pelicans).
- assimpleaspossi 19d ago[flagged]
- mcsniff 19d agoIt's a package manager. The second header on the main page: What Does Homebrew Do? Homebrew installs the command-line tools and applications you need across macOS, Linux and WSL.
- assimpleaspossi 19d agoThat doesn't make sense. Why do I need Homebrew to install the command line tools of macOS on macOS? Doesn't macOS already have them installed? Same for Linux, etc.
- atombender 19d agoReplace "need" with "want" and it might make more sense? Homebrew is the Mac equivalent of APT, Pacman, RPM, BSD ports, etc. It's a fairly traditional package manager for software that doesn't come with macOS. "brew install postgresql" installs Postgres into /opt/homebrew, for example.
- assimpleaspossi 19d agoSo how does one install postgresql on a Mac?
- fetzu 19d agohttps://www.postgresql.org/download/macosx/ https://www.postgresql.org/download/macosx/
- atombender 19d ago"brew install postgresql", unless you meant without Homebrew, in which case you could download the sources manually and compile with "make".
- monocularvision 19d agoNot usually a “+1” or “Me too!” kinda guy but homebrew is incredible and makes dev on Mac quite seamless. Huge thanks to the team.
- 12345hn6789 19d agoUnfortunately this project has a case of dread with every update to me. To see what is being force changed, worse support or even removed features. Looks like this release breaks Intel Macs. Very very sad. Not even 5+ year old hardware is apparently supportable to some devs
- throw0101a 19d agoAs a MacPorts users (generally light-weight, just a few things here and there): Has anyone gone from MP to HB, or vice versa? Why did you switch from one to the other (and perhaps back again)? What did you find as the pros/cons of each?
- ryandrake 19d agoI switched from Homebrew to MacPorts a few years ago because of Homebrew's aggressive dropping of macOS versions they consider "too old." Even in the top-comment announcement here[1] they are making sure to include that they are removing support, as if they're proud of it! MacPorts generally doesn't care what version of macOS you run, so here I am. I'll probably never go back to Homebrew. MP is great! 1: https://news.ycombinator.com/item?id=49681546 https://news.ycombinator.com/item?id=49681546
- vor_ 19d agoYes, the pride in aggressively dropping support for Macs that just received a major OS release from Apple only 12 months ago (and they were selling just three years ago) is a little off-putting.
- apothegm 19d agoI switched from MP to Homebrew over a decade ago. At the time, Homebrew was less finicky and better at resolving dependency conflicts. It was a lot easier to get a system running MacPorts into a an irretrievably borked state. Not long after, Homebrew install instructions became ubiquitous, whereas with MacPorts it seemed like you always had to figure it out for yourself — if the package was even available, which it more often wasn’t. Haven’t used MacPorts since. Has it gotten any better at those things?
- teh64 19d agoI switched from brew to macports, and I have not experienced the first problem at all. In fact, I had more problems with brew, where some package needed to be updated that I did not want, and I caused a cascade of issues. The second has also never happened to me. macports installs the packages into a separate prefix, and you just add that to the path, so I wonder how it could bork irretrievably. Regarding instructions: for most packages, I found that just replacing `brew` with `sudo port` is enough, as most ports are available. And quite a few install instructions mention homebrew together with macports. I have not run into missing packages, but sometimes the ones that existed were a little out of date.
- jjice 19d agoAlways a joy to see security and performance as a big highlight on a release. Brew is notably slow compared to the other package managers I use, but never in an unbearable way. I've always used it on my Mac work machines, but always used my native package managers on Linux. What are the reasons to run homebrew on Linux? Better newer package support when you're on something slower moving like a Debian distro? I've standardized my config scripts on using language managers for those tools (go, cargo, uv), which isn't perfect, so maybe brew is worth a chance.
- tkel 19d agoPeople have been integrating/recommending brew on immutable distributions.
- andriy_koval 19d ago> Better newer package support when you're on something slower moving like a Debian distro? exactly
- tkel 19d agoThese release notes appear generated by LLM, with the usual extreme verbosity. Wish a human had done a better job editing these.
- mikemcquaid 19d agoAn LLM helped with the initial tedium of rewording 1000s of PRs from maintainer centric language into user centric language. It was reviewed and edited (by a human) probably >20 times. Go look at the PR if you don’t believe me. I used to do these all by hand and they took me multiple hours. I still probably spent over an hour, including a bunch of time on a family holiday today. Comments like this make me wonder why I bother sometimes.
- csande17 19d agoFWIW, I also got a bit of an LLM vibe skimming the changelog. In particular, the section about Linux sandboxing jumped out at me: > Status in 7.0.0: kernels without Landlock continue working without Linux sandboxing in the less secure pre-6.0.0 configuration; brew doctor reports missing protection as an advisory. > No replacement opt-out; unavailable Landlock remains advisory. With that being said, I can kind of see why "eliminate all traces of AI writing styles" wouldn't be a goal of the review/editing process. I've been out of the Apple ecosystem for a while, but I imagine Homebrew has enthusiastically adopted LLMs for a lot of tasks. If the public communications reflect that, then people who don't like LLMs can bounce immediately, rather than getting invested in the project and feeling betrayed later.
- perardi 19d agoDon’t let the reflexive grumps get you down. homebrew is a critical, important piece of software, and I appreciate the effort. I certainly don’t appreciate the non-effort from reflexive LLM-haters. We get it. You don’t like LLMs. Try to have an opinion and a personality that doesn’t revolve around nitpicking AI writing.
- elixirnogood 19d agoDoes it surprise you that people are getting more skeptical when the software that installs system packages is getting more and more generated by AI?
- azuanrb 19d agoI prefer to use Mise for everything nowadays. homebrew bootstrap specifically. A lot easier to manage all of my packages in one single file, homebrew, Node packages, etc. https://mise.jdx.dev/bootstrap/packages/brew.html https://mise.jdx.dev/bootstrap/packages/brew.html
- bullfightonmars 19d agoI migrated our monorepo to use mise with bootstrap and mise-tasks. I was able to delete a whole heap of setup scripts and our brewfile. First time setup is extremely simple now and re-running for updates is blazing fast. mise has been an absolute delight.
- 1matin 19d agoI guess the Hackintosh era is (finally) facing its death...
- khalic 19d agoI've been using homebrew for so long, I can't tell you how much it has helped me to spend more hours developing and less managing packages and updates, etc. Thank you so much, congratulations on the update!
- mkrishnan 19d agostill needs fucking 'sudo'
- xvilka 19d agoI am quite disappointed by their decision to remove wine[1] from brew. The utility of it is obvious, and it's very popular software. [1] https://formulae.brew.sh/cask/wine-stable https://formulae.brew.sh/cask/wine-stable
- mechanicum 19d agoI don’t think utility or popularity had anything to do with the decision. It’s just that they no longer support casks with unsigned binaries. You could create a third-party tap to install wine via homebrew.
- MattDamonSpace 19d agoA new era of native macOS apps is upon us. GUIs abound. Rejoice!
- ryanmerket 19d ago[flagged]
- ricksunny 19d agodoes it self-uninstall cleanly (i.e. without leaving a footprint behind) yet? if not I don’t care about this or the next ‘upgrade’, and I can’t believe Homebrew project leaders push upgrades without addressing this basic flaw.
- jasonmp85 19d ago[dead]
- mikemcquaid 19d agoYes. If/when it doesn’t: it’s a bug and we’ll fix it. We can’t fix things people don’t report. Also: this is open source: you also could choose to fix it. Unsurprisingly the Homebrew maintainers do not spend a lot of their time uninstalling Homebrew.
- spdustin 19d agoExcellent update, very speedy on upgrades now. Amazing what a little (safe) concurrency will do. Homebrew.app, however, has a show-stopper for me. "Failed to decode Homebrew JSON output" on the installed/upgrades panel. I'm guessing the Discover panel would normally indicate which Formulae/Casks are already installed, but because it couldn't parse the JSON output, that feature (if it exists) doesn't work. I'll file an issue—I know HN isn't your bug tracker :) Edit: there's an issue there already, and I sorted out the root cause: iTerm2's shell integration. If you're using zsh as your shell, the solution is here [^0] in the second comment. [0]: https://github.com/Homebrew/BrewUI/issues/167/ https://github.com/Homebrew/BrewUI/issues/167/
- mpweiher 19d agoTried the app. Just gives me the error message "Failed to decode Homebrew JSON output". ]brew -v Homebrew 7.0.1
- yougotwill 19d agoCongrats on the release @mikemcquaid. I like how the trusted taps feature could be opted into early. It made it easier to migrate my setup before it became compulsory. Hope big changes like that can keep the same flow. Keep up the great work!
- denkmoon 19d agoI’ve really been enjoying nix as my package manager on macos. It’s on a separate volume so feels even more isolated from clobbering my macos and has, in my uninformed opinion, better sandboxing and reproducible builds
- Erold 19d ago[flagged]