Phát hành Homebrew 6.0.0

• JSON API nội bộ gộp toàn bộ metadata vào một lần tải xuống đã được chuyển thành mặc định, giúp tăng tốc cập nhật và giảm lưu lượng giao tiếp mạng
  • Biến opt-in HOMEBREW_USE_INTERNAL_API trước đây đã bị đánh dấu deprecated
• Áp dụng sandbox Bubblewrap trên Linux, cô lập việc chạy các bước build·test·postinstall giống như trên macOS
• Dựa trên khảo sát người dùng, chế độ ask được đổi thành mặc định cho nhà phát triển; khi chạy brew install·brew upgrade sẽ hiển thị tóm tắt dependency và lời nhắc xác nhận
• Trong brew bundle, cài đặt formula song song nay tự động được bật theo mặc định, đồng thời bổ sung mở rộng npm·krew và hỗ trợ winget trên Windows
• Cải thiện hiệu năng trên toàn bộ quá trình khởi động và nâng cấp, bao gồm việc tăng tốc khoảng 30% cho brew leaves
• Bổ sung hỗ trợ ban đầu cho macOS 27 (Golden Gate)
  • Do ngừng hỗ trợ Intel, macOS Intel x86_64 sẽ bị hạ xuống Tier 3 vào tháng 9/2026 và dự kiến ngừng hỗ trợ hoàn toàn vào tháng 9/2027
• Công bố và vá 3 khuyến cáo bảo mật (bỏ qua chuyển hướng HTTPS→HTTP, thực thi mã root trong .pkg postinstall, chiếm quyền sở hữu plist trong /var/tmp)
• Bổ sung các lệnh mới như brew exec tương tự npx, và brew vulns để kiểm tra lỗ hổng của các gói đã cài đặt
• Giới thiệu install steps framework để đưa hành vi postinstall·flight dùng chung ra JSON API dưới dạng dữ liệu DSL literal, giúp không cần tải xuống và đánh giá file Ruby cho các tác vụ đơn giản
• Áp dụng cooldown cho lượt tải xuống trong các hệ sinh thái rủi ro như npm·PyPI nhằm giảm thiểu rủi ro bảo mật chuỗi cung ứng từ phía upstream

[lamanus]

Nguồn lực để tiếp tục hỗ trợ cả Mac Intel cũng không đủ, và GitHub Actions cũng không còn dự định cung cấp image nữa, nên Homebrew cũng buộc phải đi theo hướng này.

[GN⁺]

Ý kiến trên Hacker News

• Tôi là @bfontaine trên GitHub. Tôi từng hỗ trợ bảo trì Homebrew vào khoảng 2014~2016, và lúc nào cũng thấy ngạc nhiên khi Mike đã duy trì nó hơn 16 năm mà vẫn còn ra tính năng mới

  • Tháng 9 này sẽ là 17 năm. Cảm ơn vì những đóng góp tuyệt vời khi đó, chúc bạn mọi điều tốt đẹp
  • Homebrew quá tốt nên nếu có thể tôi cũng dùng nó trên Linux
    Hầu hết trình quản lý gói của Linux không tách được các gói do người dùng cài với gói hệ thống, nên gần như không thể dọn dẹp máy trạm và rất khó biết cái gì có thể xóa
    Thêm nữa, trình quản lý gói gốc thường cập nhật chậm hơn Homebrew nên nhiều khi chỉ nhận được các gói đã cũ

• Tôi đã thử chuyển toàn bộ môi trường phát triển cấp độ OS từ Homebrew+pipx+npm sang https://mise.jdx.dev/ và thực tế là nó chạy rất tốt
  Nhiều công cụ được cài trực tiếp từ GitHub Releases hoặc trình quản lý gói tương ứng của chúng (uv, pnpm, go get, v.v.), nên không cần lớp mã keo để đóng gói lại và cũng không bị trễ phiên bản
  Có thể cài phiên bản tùy ý hoặc nhiều phiên bản cùng lúc, đồng thời đổi động phiên bản đang kích hoạt theo từng thư mục làm việc hoặc từng môi trường
  Điều thú vị là Mise không hỗ trợ phụ thuộc theo kiểu đầy đủ, nhưng phần lớn không thành vấn đề. Hoặc là pnpm/uv xử lý, hoặc là nhị phân tĩnh nên cứ thế chạy
  Trước đây tôi từng đóng gói một ứng dụng Python cho Homebrew, phải kéo 50 phụ thuộc vào resources, tự build tất cả từ mã nguồn hoặc kiểm tra thủ công xem Homebrew đã có chưa, khai báo toolchain build của 5 ngôn ngữ làm phụ thuộc, rồi mỗi lần cập nhật phải đợi CI hơn 1 tiếng, sau đó một bản cập nhật upstream còn tạo ra “vòng lặp phụ thuộc ở thời điểm build” khiến Homebrew không thể giải được
  Vì vậy tôi hoàn toàn hiểu vì sao Mise chọn “con đường dễ hơn” là phụ thuộc trực tiếp vào trình quản lý gói của từng ngôn ngữ
  Thứ duy nhất tôi chưa thay được từ Brewfile là Docker CLI cần để giao tiếp với Colima, còn cask thì tôi vẫn dùng Homebrew. Tôi khuyên nên thử nghiệm môi trường dev của mình. Dạo này có rất nhiều công cụ mới rất hay

  • Mise đúng là có vẻ ở một đẳng cấp riêng. Như tôi đã nói ở chỗ khác, nó phụ thuộc vào các registry như aqua hay asdf
    Với ai muốn dùng Mise cho các gói Homebrew, có https://github.com/kennyg/mise-zerobrew
  • Với tư cách là lập trình viên PHP, tôi thấy mức hỗ trợ của Mise vẫn kém khá xa so với đóng gói PHP mà Shivam Mathur đã làm cho Homebrew
    Dù sao thì đa số dự án cũng dùng Docker, còn PHP cục bộ chỉ dành cho những việc không cần Docker như phân tích tĩnh
    Tôi cũng có vài dự án dùng Nix, và Nix đúng là áp đảo mọi thứ khác, nhưng trải nghiệm người dùng tổng thể còn thù địch hơn cả git
  • Rất mừng vì bạn có trải nghiệm tốt, nhưng cá nhân tôi đã quay lại từ Mise sang Brew
    Có thể là do trình độ của tôi, nhưng có quá nhiều gói gặp vấn đề trên Mise
  • Tôi rất thích Mise, nhưng chỉ dùng nó cho việc quản lý công cụ theo từng dự án hoặc những thứ như phiên bản JDK
    Tôi cũng đã thử dùng cho các công cụ toàn hệ thống, nhưng nó không hợp với các công cụ như Helix, NeoVim, RipGrep, nơi chỉ cần tương đối mới là được và không quá quan tâm phiên bản chính xác
  • Mise cũng có hỗ trợ phụ thuộc ở mức nào đó, nhưng không theo cách mọi người thường kỳ vọng ở các trình quản lý gói khác
    Phụ thuộc trong Mise không tự động mà đều phải khai báo thủ công. Mục đích là tránh vấn đề thứ tự phát sinh do cài song song. Ví dụ nếu dùng pipx:black thì phải đợi Python cài xong. Đó là tùy chọn depends của công cụ
    Đây là thiết kế có chủ ý. Mise không được thiết kế như một giải pháp bootstrap hoàn chỉnh kiểu Homebrew hay Nix, mà là một lớp phủ đặt lên trên hệ thống sẵn có
    Vì thế bạn có thể quản lý Python bằng Brew và black bằng Mise mà gần như vẫn hoạt động ngay, không cần cấu hình riêng. Tôi cho rằng quyết định thiết kế này rất thành công. Nghe có vẻ là điểm yếu, nhưng rốt cuộc đây có lẽ lại là lý do lớn nhất khiến người dùng thấy Mise dễ dùng

• Homebrew từng là một cách tuyệt vời để bootstrap môi trường nhanh trên các bản phân phối Linux bất biến
  Không nhiều người dùng, nhưng theo https://formulae.brew.sh/analytics/os-version/365d/ thì các hệ điều hành như Bazzite (1.28%), Bluefin (0.49%), Aurora (0.28%) của Universal Blue đều đi kèm Homebrew theo mặc định
  Kho liên quan là https://github.com/ublue-os/brew

  • Khái niệm trình quản lý gói trong không gian người dùng nghe như thứ Linux đáng ra phải giải quyết từ 20 năm trước
    Tình huống phổ biến của người dùng không có quyền root là “không thể cài XY nhưng cứ tự build từ mã nguồn thì thoải mái”, điều đó thật nực cười
    Homebrew, Mise và Nix hiện đang lấp vào khoảng trống đó. Flatpak thì gần với ứng dụng GUI hơn, còn Snap thì… cũng tồn tại
  • Tôi đang dùng Nix cùng với home-manager trên Bazzite

• Ba thứ đầu tiên tôi cài là Sublime Text, Homebrew và Bash mới nhất. Tôi không có ý định chuyển sang Zsh
  Công cụ tốt khiến việc dùng máy tính trở nên vui hơn

  • Bạn có thể cài Homebrew trước, rồi dùng nó để cài Sublime và Bash

• Gần đây tôi đã quay lại từ Nix sang Homebrew, và có ba lý do lớn.
  Có vẻ Brew hỗ trợ các gói mà tôi dùng tốt hơn Nix. Một số gói trên Nix dường như không được bảo trì tốt lắm.
  Hỗ trợ cho Mac cũng tốt hơn. Một số gói Nix bị tắt tính năng trên macOS, có lẽ vì người bảo trì gói đó không có máy Mac để thử nghiệm.
  Trải nghiệm người dùng cũng tốt hơn.
  Tất nhiên tôi vẫn nhớ tính tái lập của môi trường Nix và khả năng dễ dàng tạo flake chứa các gói cụ thể, nhưng xét tổng thể thì Brew đã kéo tôi quay lại. Dù vậy tôi vẫn thích Nix, và công ty tôi cũng dùng Nix.

  • Tôi dùng nix-darwin và cũng quản lý các gói Homebrew từ đó. Đáng để xem thử.
    Tôi tò mò không biết ở công ty bạn dùng Nix vào việc gì. Có vài chỗ trông có vẻ hợp với Nix, nhưng khó chỉ ra chính xác.
  • Tôi từng quan tâm đến Nix vì nghĩ rằng có thể tự động hóa việc thiết lập và cấu hình các tính năng trên macOS.
    Nhưng thường thì cũng chỉ là chạy defaults hoặc vài công cụ trung gian.
    Cuối cùng tôi vẫn giữ Brew, và viết một hàm setupmac() có tính idempotent trong bash_profile. Tôi dùng Bash 5, và ChatGPT đã giúp khá nhiều vì nó biết nhiều lệnh defaults hay ho.
    Cùng với Brewfile tôi duy trì trong dotfiles, như vậy gần như đã giải quyết hết việc thiết lập tài khoản mới hoặc xử lý sự cố cấu hình Mac, nên tôi không cần những công cụ hoành tráng như thế.

• Homebrew là một dự án phi lợi nhuận được vận hành hoàn toàn bởi tình nguyện viên chứ không phải nhân viên.
  Họ cần kinh phí để chi trả cho tích hợp liên tục, phần mềm, phần cứng và hosting cần cho các cải tiến trong tương lai.
  Vì mọi khoản quyên góp đều được dùng để làm Homebrew tốt hơn cho người dùng, có lẽ đáng cân nhắc ủng hộ định kỳ qua GitHub Sponsors, OpenCollective hoặc Patreon.
  Tôi đã quyên góp khá nhiều cho các dự án mã nguồn mở mà mình hưởng lợi, nhưng chưa từng thực sự nghĩ kỹ về Homebrew, nên giờ chắc tôi sẽ tài trợ.

  • Thật ngạc nhiên khi Apple, hoặc ít nhất là các công ty phát triển lớn tập trung vào Mac, lại không tài trợ cho Homebrew.

• Tôi tự hỏi liệu có thể thêm một kiểu cơ chế cooldown vào Homebrew hay không.
  Những thứ duy nhất tôi muốn tin tưởng để triển khai mã mới thật nhanh lên máy mình là Apple và trình duyệt. Lý do là trình duyệt phải xử lý lượng đầu vào không đáng tin cậy nhiều hơn bất cứ thứ gì khác.
  Còn với vscode và extension, npm, homebrew, hay các ứng dụng tự động cập nhật khác, tôi thích chờ vài ngày hơn.
  Một số ngoại lệ kiểu 0-day có thể cần bỏ qua cooldown, nhưng ngay cả bây giờ người dùng vẫn dễ bị 0-day cho đến khi họ tự chạy brew upgrade.

  • Trong https://docs.brew.sh/Supply-Chain-Security có giải thích Homebrew xử lý cooldown như thế nào và vì sao hồ sơ rủi ro của nó rất khác với thứ như NPM.
    Ngoài ra, với các mục được lấy từ NPM/PyPI/RubyGems rồi đóng gói lại, vốn là mục tiêu của kiểu tấn công này, họ đã áp dụng cooldown ngay từ khi đóng gói và khi tạo PR cập nhật phiên bản mới.
  • Ý ở đây là các tính năng như --minimum-release-age hay minimumReleaseAge để giảm lỗ hổng trước các cuộc tấn công chuỗi cung ứng.
    Những cuộc tấn công này thường bị phát hiện trong vòng vài ngày sau khi bị xâm phạm.
    Ví dụ của Bun: https://bun.com/docs/pm/cli/install#minimum-release-age
  • Phần lớn chuyện này được xử lý bằng kênh phát hành. Ví dụ như brew set-channel stable/edge.
    Tuần này sau khi Elixir 1.20 được công bố, tôi chỉ có vài phút để thử mà Brew lại chưa cập nhật nên khá bực.
    erl và elixir có thể cài bằng cách khác, và cá nhân tôi thích toolchain riêng của chúng hơn, nhưng lúc đó thấy không đáng công.
    Brew có hoặc từng có tùy chọn source cho một số recipe, và nếu nheo mắt nhìn thì về cơ bản đó cũng là một giải pháp.
  • Tất cả đều là rolling release, nhưng trong Homebrew thì người nâng phiên bản phải là maintainer của Homebrew chứ không phải tác giả phần mềm.
    Ngoại lệ là khi tác giả gửi PR vào Homebrew core hoặc phát hành Tap riêng. Tôi tò mò Arch xử lý chuyện này ra sao.
  • Nó có trong bản phát hành lần này. Hãy xem mục “Cooldowns, livecheck and bumping”.

• Xin gửi lời tán dương tới tất cả những người đã làm nên Homebrew. Rất đáng cân nhắc tài trợ cho dự án: https://opencollective.com/homebrew

• Việc ngừng hỗ trợ Intel có cảm giác khá quyết liệt.
  Những người đam mê dùng Mac làm máy chủ hầu như đều dùng máy cũ, và phần lớn là Intel. Họ sẽ mất hỗ trợ sớm hơn Apple một năm.
  Tôi hiểu rằng việc hỗ trợ Intel là cực nhọc và là vấn đề lựa chọn, nhưng tôi vẫn nghiêng về phía Homebrew nên tìm cách duy trì hỗ trợ Intel lâu nhất có thể.

  • Ngược lại, có vẻ đại đa số người đam mê Apple đã chuyển hẳn sang Apple Silicon.
    Tôi không nghĩ số người dùng Mac cũ làm máy chủ vượt quá mức sai số làm tròn.
  • Nếu Apple dùng dù chỉ một phần tài nguyên của mình để bảo trì thứ như Homebrew hoặc trả tiền cho những người làm việc đó, có lẽ tình hình đã khác.
  • Ở thời điểm này, chiếc Intel Mac đó có lẽ chỉ cỡ Mac mini 2018, chỉ chạy được đến Sequoia và cũng hết hỗ trợ đúng lúc Homebrew ngừng hỗ trợ Intel.
    Nếu cần hỗ trợ Intel thì MacPorts vẫn còn chạy được tận Leopard.
  • Hỗ trợ cờ --no-quarantine cũng đã bị gỡ bỏ.
    Dạo này tôi chỉ dùng Homebrew cho một vài cask và cố tránh dùng khi có thể. Với công cụ CLI thì tôi dùng Nix, Home-Manager và Nix-Darwin.
  • May mắn là những chiếc máy như vậy vẫn hoàn hảo để chạy bản phân phối Linux.

• Tôi đã bỏ dùng Homebrew vì cá nhân đã quá nhiều lần bị nâng cấp cưỡng bức mà không thể ghim phiên bản
  Giờ tôi dùng kết hợp Mise và MacPorts để tránh các lần hỏng vặt không báo trước và việc bị ép lỗi thời
  Hơn nữa, Mise có thể nâng lên bất kỳ phiên bản mới nào, còn với Homebrew thì phải chờ Tap cập nhật khi nào họ muốn. Tap llama.cpp thậm chí có lúc bỏ qua tới 10 bản phát hành

  • Thật lòng mừng vì bạn đã tìm được quy trình làm việc phù hợp
    Vì những người vẫn đang dùng Homebrew, đã có rất nhiều công sức được bỏ vào để chỉ nâng cấp khi thực sự cần và hiển thị cho người dùng trước khi nâng cấp, và điều đó cũng có trong bản phát hành lần này
  • Tôi cũng đang định hỏi xem có ai khác từng có trải nghiệm tương tự không
    Tôi đã dùng MacPorts để cài công cụ phát triển suốt nhiều năm, và nó nhất quán hơn nhiều, không khiến tôi giật mình vì một phiên bản major mới của Python đột nhiên xuất hiện ngẫu nhiên
    Tôi chỉ dùng Homebrew để cài các ứng dụng như Firefox, Slack và Spotify, những thứ MacPorts không có
    Tất nhiên, suốt nhiều năm qua tôi cũng đã cố chuyển Python sang uv và nodejs sang pnpm, nên giờ chuyện này có thể không còn là vấn đề lớn với tôi nữa
  • Tôi đã chuyển sang MacPorts vì lịch ngừng hỗ trợ theo từng giai đoạn quá quyết liệt của Homebrew: https://docs.brew.sh/Support-Tiers
    Chiếc iMac tôi dùng hằng ngày giờ đã rơi vào bucket Tier-3 kiểu “biến đi”
    Tôi thực sự rất thích Homebrew trong quãng thời gian ngắn còn dùng được nó, nhưng không có ý định bước lên guồng quay phải nâng cấp phần cứng chỉ để tiếp tục dùng nó
  • Tôi đã chuyển phần lớn sang Mise rồi, có lẽ nên xem thử MacPorts cho những thứ còn lại
  • Nix cũng đáng để xem qua. Dù việc đóng gói cho Darwin hơi thiếu ổn định, nhưng có một dev shell đa nền tảng khi thường xuyên qua lại giữa Mac và Linux thực sự rất tuyệt