Earlier quoted context omitted.
I use nix on both mac and linux, also on CI where homebrew is especially brittle
Don’t you have to disable SIP to use nix on macOS?
Our audit of Homebrew
111–120 of 205 posts
Re: Our audit of Homebrew
#112[flagged]
Re: Our audit of Homebrew
#113If macs supported PKGBUILDs like Pacman with a similar level of performance and there were correctly maintained packages for core programs I'd feel like using a mac would have a lot less compromises for convenience. Homebrew is great and the formulae are maintained really well but the simplicity of PKGBUILDS, the fast syncing, and lack of cognitive burden of recalling multiple arguments/flags for package managers mak…
The vanilla pacman will not work on macos as expected but there are attempts [1],[2] to make it works with some modifications/hacks.
[1] https://github.com/liudongmiao/pacman [2] https://github.com/kladd/pacman-osx
Re: Our audit of Homebrew
#114Earlier quoted context omitted.
Apple should have written it themselves. It's embarrassing that they didn't. Nonprofit Linux distros with one-millionth the resources manage to write package managers and run repos, and then with MacOS, Apple gives you diddly-squat.
IMO, it's just counter to what Apple aspires MacOS to be. If they would do it all over again, I would bet that they would have wanted to make MacOS be like iOS.
> IMO, it's just counter to what Apple aspires MacOS to be.
Every OS wants to be attractive to developers. Apple has a long history of underdelivering this core proposition. To me it's an odd situation to reason about - look at Apple's dev conferences and then look at what it's like on the ground in dev's reality.
Re: Our audit of Homebrew
#115Earlier quoted context omitted.
Nix also allows github.
Sure, Nix is extremely flexible in input definition, but it's different in the sense that Homebrew exposes a single command to e.g. install a cask from a user-inputted GitHub repository. So all an attacker needs to do is typo squat or take control of the GitHub repository that people are using to install a certain cask. In Nix, flakes are pure functions and run in pure evaluation mode. One needs to consciously add a…
All the Nix commands that take an 'installable' can take GitHub URLs. For instance:
$ nix run github:NixOS/nixpkgs#hello
Hello world!
> But to find out what the flake exposes at all, reading the flake (or its documentation) is pretty much necessary.
If the flake exposes default packages or apps, then you do not need to provide a flake attribute:
$ nix run github:NixOS/nixpkgs
error: flake 'github:NixOS/nixpkgs' does not provide attribute 'apps.aarch64-darwin.default', 'defaultApp.aarch64-darwin', 'packages.aarch64-darwin.default' or 'defaultPackage.aarch64-darwin'
$ nix run github:kamadorueda/alejandra
EDIT: For what it's worth, I think this feature can be useful sometimes, but it does also suffer from the same typosquatting problems as we see in other ecosystems.
Re: Our audit of Homebrew
#116[flagged]
Can you supply supporting evidence (links etc.) regarding "the author was being extremely upset (...) about not passing a Google interview" and "Homebrew having... weird design decisions"?
Re: Our audit of Homebrew
#117MacPorts is always waiting for you with more packages, a better design, and Jordan Hubbard’s history with BSD/Apple :)
I was wondering recently if there are any downsides of using MacPorts and homebrew for different packages on the same system. Homebrew excels at keeping all my single binary CLI tools up to date, but I don't particularly like how it forces me to upgrade more complex software packages like MySQL or FFmpeg constantly. There is also the issue, that my iMac is stuck on Ventura, and soon won't be supported by homebrew any…
The approach of Mac ports and Homebrew have been the complete opposite when Homebrew came into existence.
Mac ports tried to make packages compatible with whatever Apple shipped, aka their own twists on Perl, python, OpenSSL etc.
While Homebrew tried to make macOS compatible with whatever existed out there.
As a developer Homebrew gave you a more up to date and fully functional experience.
Can’t tell you how it is today since Apple removed all interpreters and such from macOS.
Re: Our audit of Homebrew
#118[flagged]
Can you supply supporting evidence (links etc.) regarding "the author was being extremely upset (...) about not passing a Google interview" and "Homebrew having... weird design decisions"?
(I'm not the other poster)
They're probably referring to this tweet from Max Howell [0]
> Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off.
I personally wouldn't hold that against him (or Homebrew). We also don't really know if Google rejected him based on the binary tree, or if it was something else (personality?).
Re: Our audit of Homebrew
#119If macs supported PKGBUILDs like Pacman with a similar level of performance and there were correctly maintained packages for core programs I'd feel like using a mac would have a lot less compromises for convenience. Homebrew is great and the formulae are maintained really well but the simplicity of PKGBUILDS, the fast syncing, and lack of cognitive burden of recalling multiple arguments/flags for package managers mak…
Is MacPorts not the same? Genuinely asking.
The concept is the same (given a definition file, build a package from a central repo, aka ports-like), but one of the features of PKGBUILD has is that it's easy to build an ad-hoc package outside the main tree. For example, you can download a bundle of PKGBUILD and `makepkg` in any directory to build a package.
In other ports-like build systems, this can be a bit more complicated. For example, MacPorts allows you to use a local repository, but it requires configuring that local repository in `/opt/local/etc/macports/sources.conf` and `portindex` it beforehand before MacPorts could pick it up. Some others don't support building out of the main tree at all.
Personally, out of all ports-like building systems, I like MacPorts' Portfile the most. It's similar to FreeBSD Ports' BSD Makefile (MacPorts was created by Jordan Hubbard who also co-created FreeBSD Ports) but using DSL via Tcl interp instead of being a shell script (POSIX shell in the case of Alpine's APKBUILD, bash in the case of others). From my experience, the syntax is very nice to work with, though you need to know a bit of Tcl for a non-trivial package.
Re: Our audit of Homebrew
#120Apple should have been the one funding the audit.
Apple should have written it themselves. It's embarrassing that they didn't. Nonprofit Linux distros with one-millionth the resources manage to write package managers and run repos, and then with MacOS, Apple gives you diddly-squat.
>Apple should have written it themselves.
Please don't. It would be a resource hog SwiftUI monstrosity like the new Settings app. And while they are at it, they would probably introduce the 46353th bespoke feature into the Swift language too, because why not?