Rilis Homebrew 6.0.0

• API JSON internal yang menggabungkan seluruh metadata dalam satu unduhan kini menjadi default, sehingga pembaruan lebih cepat dan komunikasi jaringan berkurang
  • Variabel opt-in HOMEBREW_USE_INTERNAL_API yang lama kini berstatus deprecated
• Sandbox Bubblewrap diterapkan di Linux, mengisolasi tahap build, test, dan postinstall agar berjalan sama seperti di macOS
• Berdasarkan survei pengguna, mode ask diubah menjadi default untuk pengembang; saat brew install dan brew upgrade, ringkasan dependensi serta prompt konfirmasi akan ditampilkan
• Di brew bundle, instalasi formula paralel kini otomatis aktif secara default, serta ditambahkan ekstensi npm, krew, dan dukungan Windows winget
• Peningkatan performa di seluruh proses startup dan upgrade, termasuk brew leaves yang sekitar 30% lebih cepat
• Ditambahkan dukungan awal untuk macOS 27 (Golden Gate)
  • Seiring penghentian dukungan Intel, macOS Intel x86_64 akan menjadi Tier 3 pada September 2026, dan sepenuhnya tidak didukung mulai September 2027
• Tiga advisory keamanan dipublikasikan dan diperbaiki (bypass redirect HTTPS→HTTP, eksekusi kode root pada .pkg postinstall, pengambilalihan kepemilikan plist di /var/tmp)
• Ditambahkan perintah baru seperti brew exec yang mirip npx, serta brew vulns untuk memeriksa kerentanan pada paket yang terpasang
• Diperkenalkan install steps framework yang mengekspos perilaku postinstall dan flight umum ke API JSON sebagai data DSL literal, sehingga untuk tugas sederhana tidak perlu mengunduh dan mengevaluasi file Ruby
• Diterapkan cooldown unduhan pada ekosistem berisiko seperti npm dan PyPI untuk mengurangi risiko keamanan pasokan dari upstream

[lamanus]

Sumber daya juga tidak cukup untuk terus mendukung bahkan Mac Intel, dan karena GitHub Actions juga tidak lagi berencana menyediakan image, Homebrew pun tidak punya pilihan selain menyesuaikan langkahnya dengan kondisi ini.

[GN⁺]

Komentar Hacker News

• Saya @bfontaine di GitHub. Saya sempat membantu pemeliharaan Homebrew sekitar 2014–2016, dan saya selalu kagum melihat Mike terus memeliharanya selama lebih dari 16 tahun dan masih merilis fitur baru

  • Pada September nanti genap 17 tahun. Terima kasih atas kontribusi hebatmu saat itu, dan semoga kamu baik-baik saja
  • Homebrew sangat bagus sampai saya memakainya juga di Linux jika memungkinkan
    Sebagian besar manajer paket Linux tidak bisa memisahkan paket yang dipasang pengguna dari paket sistem, sehingga hampir mustahil merapikan workstation dan sulit menentukan apa yang aman untuk dihapus
    Selain itu, manajer paket bawaan biasanya lebih lambat diperbarui dibanding Homebrew, jadi sering kali kita hanya mendapat paket yang sudah lama

• Sebagai eksperimen, saya memindahkan seluruh lingkungan pengembangan level OS dari Homebrew+pipx+npm ke https://mise.jdx.dev/, dan ternyata bekerja sangat baik
  Banyak alat dipasang langsung dari rilis GitHub atau manajer paket yang sesuai (uv, pnpm, go get, dll.), jadi tidak ada kode lem tambahan untuk repackaging dan tidak ada jeda versi
  Kita bisa memasang versi arbitrer atau beberapa versi sekaligus, lalu mengganti versi aktif secara dinamis per folder kerja atau per environment
  Menariknya, Mise tidak mendukung dependensi, tetapi dalam kebanyakan kasus itu tidak jadi masalah. pnpm/uv yang menanganinya, atau karena binernya statis jadi langsung berjalan
  Dulu saya pernah memaketkan aplikasi Python untuk Homebrew sambil menarik 50 dependensi sebagai resources, membangun semuanya dari source atau memeriksa manual apakah sudah ada di Homebrew, mendeklarasikan toolchain build dari 5 bahasa sebagai dependensi, lalu menunggu CI lebih dari 1 jam setiap kali update, sampai akhirnya update upstream menciptakan “build-time dependency loop” yang tidak bisa diselesaikan di Homebrew
  Jadi saya sepenuhnya paham kenapa Mise memilih “jalan mudah” dengan langsung bergantung pada manajer paket per bahasa
  Satu-satunya yang belum bisa saya ganti dari Brewfile hanyalah Docker CLI yang diperlukan untuk berkomunikasi dengan Colima, dan untuk cask saya masih memakai Homebrew. Saya sarankan bereksperimen dengan lingkungan pengembangan. Sekarang ada banyak alat baru yang hebat

  • Mise memang terasa berada di kelasnya sendiri. Seperti yang pernah saya katakan di tempat lain, ia bergantung pada registry seperti aqua atau asdf
    Bagi yang ingin memakai Mise untuk paket Homebrew, ada https://github.com/kennyg/mise-zerobrew
  • Sebagai developer PHP, dukungan Mise terasa cukup tertinggal dibanding pemaketan PHP yang dilakukan Shivam Mathur untuk Homebrew
    Kebanyakan proyek toh memakai Docker, dan PHP lokal dipakai untuk hal-hal seperti analisis statis yang tidak butuh Docker
    Saya juga punya beberapa proyek yang memakai Nix, dan Nix memang membuat semua yang lain terlihat remeh, tetapi pengalaman penggunanya secara keseluruhan bahkan lebih tidak ramah daripada git
  • Senang mendengar pengalamannya bagus, tetapi secara pribadi saya akhirnya kembali dari Mise ke Brew
    Mungkin ini keterbatasan saya, tetapi terlalu banyak paket yang bermasalah di Mise
  • Saya sangat suka Mise, tetapi hanya memakainya untuk pengelolaan alat per proyek atau hal seperti versi JDK
    Saya juga pernah mencobanya untuk alat sistem global, tetapi kurang cocok untuk alat seperti Helix, NeoVim, dan RipGrep, yang penting kira-kira versi terbaru dan tidak perlu peduli versi persisnya
  • Mise memang mendukung dependensi sampai batas tertentu, tetapi tidak seperti yang biasanya diharapkan dari manajer paket lain
    Dependensi di Mise tidak otomatis; semuanya harus didefinisikan manual. Ini dipakai untuk menghindari masalah urutan yang muncul karena instalasi paralel. Misalnya, jika memakai pipx:black, ia harus menunggu sampai instalasi Python selesai. Itulah fungsi opsi depends di alat tersebut
    Ini memang desain yang disengaja. Mise dirancang bukan sebagai solusi bootstrap lengkap seperti Homebrew atau Nix, melainkan sebagai overlay di atas sistem yang sudah ada
    Karena itu, Anda bisa mengelola Python dengan Brew dan black dengan Mise, dan semuanya hampir langsung berjalan tanpa konfigurasi tambahan. Menurut saya keputusan desain ini sangat berhasil. Kedengarannya seperti kekurangan, tetapi justru mungkin itulah alasan terbesar pengguna merasa Mise mudah dipakai

• Homebrew adalah cara yang sangat bagus untuk melakukan bootstrap environment dengan cepat di distribusi Linux immutable
  Penggunanya memang tidak banyak, tetapi menurut https://formulae.brew.sh/analytics/os-version/365d/, sistem operasi seperti Universal Blue Bazzite (1,28%), Bluefin (0,49%), dan Aurora (0,28%) menyertakan Homebrew secara bawaan
  Repositori terkaitnya adalah https://github.com/ublue-os/brew

  • Konsep manajer paket ruang pengguna terasa seperti sesuatu yang seharusnya sudah diselesaikan Linux 20 tahun lalu
    Lucu bahwa situasi umum bagi pengguna non-root adalah “Anda tidak boleh memasang XY, tapi silakan bebas build dari source”
    Homebrew, Mise, dan Nix sekarang mengisi kekosongan itu. Flatpak lebih dekat ke aplikasi GUI, dan Snap… ya, itu memang ada
  • Saya memakai Nix bersama home-manager di Bazzite

• Tiga hal pertama yang saya pasang adalah Sublime Text, Homebrew, dan Bash terbaru. Saya tidak berniat pindah ke Zsh
  Alat yang bagus membuat komputasi terasa menyenangkan

  • Pasang Homebrew dulu, lalu gunakan itu untuk memasang Sublime dan Bash

• Baru-baru ini beralih kembali dari Nix ke Homebrew, dan ada tiga alasan besar
  Dukungan Brew untuk paket-paket yang dimilikinya tampak lebih baik daripada Nix. Sepertinya beberapa paket di Nix tidak terawat dengan baik
  Dukungan Mac juga lebih baik. Beberapa paket Nix menonaktifkan fungsinya di macOS, dan tampaknya itu karena maintainer paket tersebut tidak punya Mac untuk pengujian
  Pengalaman penggunanya juga lebih baik
  Tentu saja saya merindukan reproduksibilitas lingkungan Nix dan kemampuannya untuk dengan mudah membuat flake berisi paket tertentu, tetapi secara keseluruhan Brew membawa saya kembali. Meski begitu saya tetap suka Nix, dan di perusahaan juga memakai Nix

  • Saya memakai nix-darwin dan juga mengelola paket Homebrew dari sana. Layak dilihat
    Penasaran perusahaan Anda memakai Nix untuk apa. Ada beberapa tempat yang tampaknya cocok untuk Nix, tetapi sulit menunjukkannya secara tepat
  • Saya tertarik pada Nix karena sepertinya bisa mengotomatisasi pengaturan dan konfigurasi fitur macOS
    Tetapi biasanya ujung-ujungnya hanya menjalankan defaults atau alat perantara
    Pada akhirnya saya tetap mempertahankan Brew, dan menulis fungsi setupmac() yang idempoten di bash_profile. Saya memakai Bash 5, dan ChatGPT membantu karena tahu banyak perintah defaults yang bagus
    Bersama Brewfile yang saya simpan di dotfiles, itu sudah hampir menyelesaikan semua masalah saat menyiapkan akun baru atau Mac baru, jadi saya tidak memerlukan alat sebesar itu

• Homebrew adalah proyek nirlaba yang dijalankan sepenuhnya oleh sukarelawan, bukan pegawai
  Mereka membutuhkan dana untuk membayar continuous integration, perangkat lunak, perangkat keras, dan biaya hosting yang dibutuhkan untuk perbaikan ke depan
  Karena semua donasi dipakai untuk membuat Homebrew lebih baik bagi pengguna, mungkin layak mempertimbangkan dukungan rutin melalui GitHub Sponsors, OpenCollective, atau Patreon
  Saya sudah banyak berdonasi ke proyek open source yang saya pakai, tetapi tidak pernah benar-benar memikirkan Homebrew, jadi sekarang saya rasa saya harus ikut mendukung

  • Mengejutkan bahwa Apple, atau setidaknya perusahaan pengembang besar yang berfokus pada Mac, tidak mendanai Homebrew

• Saya penasaran apakah Homebrew tidak bisa menambahkan semacam mekanisme cooldown
  Satu-satunya pihak yang ingin saya percayai untuk cepat menyebarkan kode baru ke mesin saya hanyalah Apple dan browser. Browser menanganani input yang paling tidak dapat dipercaya dibanding apa pun
  Untuk yang lain seperti vscode dan ekstensinya, npm, homebrew, dan aplikasi auto-update, saya lebih memilih menunggu beberapa hari
  Beberapa 0-day yang luar biasa mungkin perlu melewati cooldown, tetapi bahkan sekarang pengguna tetap rentan terhadap 0-day sampai mereka menjalankan brew upgrade

  • Di https://docs.brew.sh/Supply-Chain-Security dijelaskan bagaimana mereka menangani cooldown dan mengapa profil risikonya sangat berbeda dibanding hal-hal seperti NPM
    Selain itu, untuk item yang diambil dan dikemas ulang dari NPM/PyPI/RubyGems, yang menjadi target serangan semacam ini, cooldown sudah diterapkan saat pengemasan dan saat membuat PR pembaruan versi baru
  • Yang dimaksud di sini adalah fitur seperti --minimum-release-age atau minimumReleaseAge untuk mengurangi kerentanan terhadap serangan rantai pasok
    Serangan semacam ini sering kali terdeteksi dalam beberapa hari setelah kompromi
    Contoh di Bun: https://bun.com/docs/pm/cli/install#minimum-release-age
  • Kebanyakan ditangani lewat kanal rilis. Misalnya sesuatu seperti brew set-channel stable/edge
    Minggu ini saya hanya sempat beberapa menit mencoba pengumuman Elixir 1.20, dan kesal karena Brew tertinggal
    erl dan elixir bisa dipasang dengan cara lain, dan saya pribadi lebih suka toolchain mereka sendiri, tetapi pada saat itu rasanya tidak layak dilakukan
    Brew punya atau pernah punya opsi source pada beberapa recipe, dan kalau dipandang agak longgar, itu pada dasarnya juga menjadi solusi
  • Semuanya adalah rolling release, tetapi di Homebrew maintainer Homebrew-lah yang harus menaikkan versinya, bukan penulis perangkat lunaknya
    Pengecualiannya jika penulis mengirim PR ke Homebrew core atau menerbitkan Tap mereka sendiri. Penasaran bagaimana Arch menangani hal ini
  • Itu sudah ada di rilis ini. Lihat bagian “Cooldowns, livecheck and bumping”

• Salut untuk semua orang yang membuat Homebrew mungkin ada. Layak mempertimbangkan untuk mendukung proyek ini: https://opencollective.com/homebrew

• Penghentian dukungan Intel terasa agresif
  Hampir semua penghobi yang memakai Mac sebagai server menggunakan mesin lama, dan kebanyakan adalah Intel. Dukungan mereka hilang setahun lebih cepat daripada dari Apple
  Saya paham bahwa mendukung Intel itu pekerjaan berat dan soal pilihan, tetapi saya cenderung berpikir Homebrew harus mencari cara agar dukungan Intel dipertahankan selama mungkin

  • Sebaliknya, tampaknya mayoritas mutlak penggemar Apple sudah sepenuhnya beralih ke Apple Silicon
    Saya rasa orang yang memakai Mac lama sebagai server bahkan tidak sampai tingkat galat pembulatan
  • Jika Apple memakai setidaknya sebagian sumber dayanya untuk memelihara sesuatu seperti Homebrew atau membayar orang-orang yang mengerjakannya, situasinya mungkin berbeda
  • Pada titik ini Mac Intel yang dimaksud kemungkinan sekitar Mac mini 2018, yang hanya bisa menjalankan sampai Sequoia dan dukungannya berakhir bersamaan saat Homebrew menghentikan dukungan Intel
    Jika butuh dukungan Intel, MacPorts masih berjalan bahkan sampai Leopard
  • Dukungan untuk flag --no-quarantine juga dihapus
    Akhir-akhir ini saya hanya memakai Homebrew untuk beberapa cask dan berusaha menghindarinya sebisa mungkin. Untuk alat CLI saya memakai Nix, Home-Manager, dan Nix-Darwin
  • Untungnya, mesin-mesin seperti itu sempurna untuk distro Linux

• Saya pribadi berhenti menggunakan Homebrew karena terlalu sering kena upgrade paksa yang tidak bisa dikunci
  Sekarang saya memakai kombinasi Mise dan MacPorts untuk menghindari kerusakan tanpa peringatan dan penuaan paksa
  Selain itu, Mise bisa dinaikkan ke versi baru secara arbitrer, sedangkan di Homebrew Anda harus menunggu kapan Tap di-upgrade. Tap llama.cpp bahkan kadang melewati 10 rilis sekaligus

  • Senang sekali Anda menemukan workflow yang cocok
    Banyak pekerjaan telah dilakukan agar upgrade hanya terjadi saat benar-benar dibutuhkan dan agar ditampilkan ke pengguna sebelum upgrade, dan itu juga termasuk dalam rilis ini
  • Saya juga tadi ingin bertanya apakah ada orang lain yang mengalami hal serupa
    Saya sudah memakai MacPorts selama beberapa tahun untuk memasang alat pengembangan, dan jauh lebih konsisten serta tidak membuat saya kaget karena versi mayor baru Python tiba-tiba muncul secara acak
    Saya hanya memakai Homebrew untuk memasang aplikasi seperti Firefox, Slack, dan Spotify yang tidak ada di MacPorts
    Tentu saja, selama bertahun-tahun saya juga sudah berusaha pindah ke uv untuk Python dan pnpm untuk nodejs, jadi sekarang ini mungkin bukan masalah besar lagi bagi saya
  • Saya pindah ke MacPorts karena jadwal penghapusan tahap dukungan Homebrew yang agresif: https://docs.brew.sh/Support-Tiers
    iMac yang saya pakai setiap hari sekarang masuk ke bucket Tier-3 “silakan mati”
    Saya benar-benar menyukai Homebrew selama masa singkat ketika saya bisa memakainya, tetapi saya tidak berniat naik ke treadmill upgrade hardware hanya agar bisa terus memakainya
  • Saya sudah di tahap memindahkan sebagian besar hal ke Mise, dan untuk sisanya sepertinya saya perlu melihat MacPorts
  • Nix juga layak dilirik. Packaging Darwin memang agak tidak stabil, tetapi sangat enak punya shell pengembangan lintas platform saat harus sering bolak-balik antara Mac dan Linux