1/13/2024 0 Comments Macports github![]() + Brew you can setup autoupdate for your personal customizations with github actions since the main repo is using them, Ports does it manually, so you can't copy&paste their action for your use + Port, Brew dropped support for custom install flags a while ago While neither is great as a package manager, especiall with their dependency resolution, here are a few pros&cons:Īpps: ++ Brew has a much more up-to-date collection, also more non-source binaries. Switched to MacPorts on an older machine which Homebrew dropped support for (and deleted all prebuilt binaries) However I have sufficient experience now to package crucial missing ones into MacPorts. The cons of the move are that not all the packages I want are available in MacPorts. Overall, MacPorts appears more mature and more Unix-like than Homebrew. * Noisy messages and undesired colors in the command line output. Multiple user accounts on the same Mac can't easily use Homebrew, as far as I know, and I dislike software with such design choices. * The permissions model means that Homebrew-managed parts of the system become a single user system, as far as I know. * It has a Frankenstein permissions model for example "brew install" writes files into /usr/local/* with your regular user account as the owner of the files. When I revisited the choice last year, I chose MacPorts. I chose Homebrew some years ago when I was not as experienced a programmer, because it was more popular than MacPorts. I moved from Homebrew to MacPorts on a local, personal-use Intel Mac. pass a file or directory path as a command-line argument to a CLI program, then that CLI program should be auto-granted a capability on that file/directory during that run. gVim packaging its own command-line `vi` or Sublime Text with its `subl` command) - where all the same capability-manifest sandboxing applies to the command-line executables that applies to the GUI app and where the CLI version of the executable linker-loader is made slightly smarter re: auto-granting capabilities, such that if you e.g. The App Store should allow at least apps that contain both GUI and CLI versions (e.g. (And, ideally, rather than needing to care about PATH ordering re: these applications’ exposed bin/ executables, instead make a generic system for interactively choosing preference-ordering, like Debian’s update-alternatives(1) but as a per-user runtime-bound preference.)Ģ. app hasn’t yet been Gatekeeper-blessed.) Kind of surprised this hasn’t always been a thing since NeXTSTEP, actually. (And probably, just like with file extension bindings, you’d want to give the user the same “this is a program downloaded from the Internet…” Gatekeeper warning the first time a command-line invocation causes the user to end up running an executable from a given. app bundles can “provide” file extension bindings that cause things to open in them. app bundles should be able to “provide” a bin/ directory that gets added (appended, not prepended!) to your PATH while you have the package available on disk + non-quarantined. I think the idea is that there should be an option to have Apple-App-Store-audited capability-manifest-sandboxed CLI apps with auto-updates, as well as untrusted, non-sandboxed CLI apps.ġ. In fact, I would argue that the other package managers that use sudo are taking the easy way out (albeit insecure). I don't think the current solution is perfect, but I do think the motivation to prevent usage of sudo is correct in terms of security. If you have a multi-user computer, you can install Homebrew to a local user folder to have isolation and not using a global location like /opt/homebrew, or you can make a special Homebrew user account (rather than using root), which is what the docs suggest ( ). ![]() Instead, Homebrew prefers to run in a user account, default to yours. (Note that /opt/homebrew is not world writable as you suggested. Most package manager forces you to use sudo to run them as root, and I think that's much much worse in terms of security practices and encourages the wrong behaviors and potentially allowing build/install scripts to wreck havoc on your system. It does matter though? /opt/homebrew is specifically used by Homebrew, whereas /usr/local is kind of a more shared location that old Homebrew hijacked.Įither way, I think bad default folders is better than bad default security practices.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |