It needs to convey concepts that are infinitely variable rather than binary.
When a poet or novelist says something in an unusual way, they are being more accurate not less accurate. If there is ambiguity, it is because the concept or observation they mean to express has some ambiguous element.
Trying to avoid that is just downsampling analog color reality to a 200ppi 1bpp fax.
A related concept that even the most aspbergers STEM head should be able to understand, is how a scientist almost never asserts anything unequivocally. Almost every statement is qualified with whatever is appropriate to the context. Even the most fundamental constants of the universe like the speed of light are famously relative. Are those scientists being more or less ambiguous when they decline to say something simple and direct?
Everything they don't say is deliberate and carefully crafted to be as correct as possible, not some sloppy ommission.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T05:46:23.000Z","created_at_i":1722404783,"id":41116653,"options":[],"parent_id":41116554,"points":null,"story_id":41114839,"text":"One should try to avoid using double negatives in both speech and programming to make intent more obvious ;-)","title":null,"type":"comment","url":null},{"author":"Brian_K_White","children":[],"created_at":"2024-07-31T06:07:31.000Z","created_at_i":1722406051,"id":41116733,"options":[],"parent_id":41116554,"points":null,"story_id":41114839,"text":""not inconsistent" is a common phrase and is used for a reason. It's a subtle difference but "not inconsistent" is not exactly the same as "is consistent".","title":null,"type":"comment","url":null},{"author":"simonklitj","children":[],"created_at":"2024-07-31T06:26:29.000Z","created_at_i":1722407189,"id":41116812,"options":[],"parent_id":41116554,"points":null,"story_id":41114839,"text":"That\u2019s not necessarily what was meant though.
\u201cNot inconsistent\u201d is more cautious and less assertive. It allows for some ambiguity rather than claiming perfect consistency.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T05:13:51.000Z","created_at_i":1722402831,"id":41116554,"options":[],"parent_id":41115862,"points":null,"story_id":41114839,"text":"My dumb brain had to read it 3 times before realizing that by saying "the findings were not inconsistent with what I'd expect" you meant "the findings _were_ consistent with what I'd expect"","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T02:05:29.000Z","created_at_i":1722391529,"id":41115862,"options":[],"parent_id":41115692,"points":null,"story_id":41114839,"text":"Given that I did the audit, I don\u2019t think it\u2019s appropriate for me to offer an endorsement (or a negative endorsement) in this context. What I\u2019ll say is this: the findings on Homebrew were not inconsistent with what I\u2019d expect to find on any similarly sized userspace package manager that serves its own binary builds.","title":null,"type":"comment","url":null},{"author":"Cloudef","children":[{"author":"lifty","children":[{"author":"Cloudef","children":[],"created_at":"2024-07-31T07:22:27.000Z","created_at_i":1722410547,"id":41117059,"options":[],"parent_id":41117029,"points":null,"story_id":41114839,"text":"No. Even though SIP is slightly annoying because you can't have strace equivalent with it.","title":null,"type":"comment","url":null},{"author":"socksy","children":[{"author":"FireBeyond","children":[{"author":"Cloudef","children":[],"created_at":"2024-08-01T00:38:26.000Z","created_at_i":1722472706,"id":41125083,"options":[],"parent_id":41122954,"points":null,"story_id":41114839,"text":"The installer does it all for you.\nTheres even graphical installer https://determinate.systems/posts/graphical-nix-installer/","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T20:11:16.000Z","created_at_i":1722456676,"id":41122954,"options":[],"parent_id":41117122,"points":null,"story_id":41114839,"text":"If there's any hope of Nix seeing widespread adoption as a Mac package manager, uh... this link kinda shoots it down a lot.
From that:
- create a new APFS volume for your Nix store
- update /etc/synthetic.conf to direct macOS to create a "synthetic" empty root directory to mount your volume\n- specify mount options for the volume in /etc/fstab: rw: read-write, noauto: prevent the system from auto-mounting the volume (so the LaunchDaemon mentioned below can control mounting it, and to avoid masking problems with that mounting service), nobrowse: prevent the Nix Store volume from showing up on your desktop; also keeps Spotlight from spending resources to index this volume
- if you have FileVault enabled: generate an encryption password, put it in your system Keychain, use it to encrypt the volume
- create a system LaunchDaemon to mount this volume early enough in the boot process to avoid problems loading or restoring any programs that need access to your Nix store
Even as someone who knows how to do all that... no thanks.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T07:40:33.000Z","created_at_i":1722411633,"id":41117122,"options":[],"parent_id":41117029,"points":null,"story_id":41114839,"text":"No, see https://nix.dev/manual/nix/2.18/installation/installing-bina...","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T07:15:48.000Z","created_at_i":1722410148,"id":41117029,"options":[],"parent_id":41116168,"points":null,"story_id":41114839,"text":"Don\u2019t you have to disable SIP to use nix on macOS?","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T03:28:27.000Z","created_at_i":1722396507,"id":41116168,"options":[],"parent_id":41115692,"points":null,"story_id":41114839,"text":"I use nix on both mac and linux, also on CI where homebrew is especially brittle","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T01:23:58.000Z","created_at_i":1722389038,"id":41115692,"options":[],"parent_id":41115051,"points":null,"story_id":41114839,"text":"I cannot reply to your top comment for some reason, so asking here:
What is your personal recommendation for Mac users? Would you suggest a different package manager and, if so, which?","title":null,"type":"comment","url":null}],"created_at":"2024-07-30T23:16:44.000Z","created_at_i":1722381404,"id":41115051,"options":[],"parent_id":41115037,"points":null,"story_id":41114839,"text":"Yep. We use the TOB-$PRODUCT-$XXXX convention for our audit findings, where $PRODUCT is the target under audit and $XXXX is a unique incrementing counter for each finding.
(As far as I know, a lot of audit firms do similar things.)","title":null,"type":"comment","url":null}],"created_at":"2024-07-30T23:14:02.000Z","created_at_i":1722381242,"id":41115037,"options":[],"parent_id":41114839,"points":null,"story_id":41114839,"text":"There's a bunch of TOB-BREW-n listed - are those like CVE numbers just for this project?
Edit: Oh, it's "Trail Of Bits - homeBREW". But probably still yes.","title":null,"type":"comment","url":null},{"author":"apitman","children":[{"author":"bagels","children":[{"author":"cqqxo4zV46cp","children":[{"author":"chatmasta","children":[],"created_at":"2024-07-31T00:51:19.000Z","created_at_i":1722387079,"id":41115551,"options":[],"parent_id":41115196,"points":null,"story_id":41114839,"text":"I\u2019ve had a few build pipelines break over the years because of a watchman dependency. IIRC it was usually an issue with an npm library depending on watchman but downloading a binary that was incompatible with the architecture or implemented the wrong syscalls for the operating system.","title":null,"type":"comment","url":null}],"created_at":"2024-07-30T23:45:08.000Z","created_at_i":1722383108,"id":41115196,"options":[],"parent_id":41115173,"points":null,"story_id":41114839,"text":"My short experience with Watchman (a few years ago) indicates this. It\u2019s pretty clearly only technically open-source, without much regard at all paid to third parties actually using it.","title":null,"type":"comment","url":null},{"author":"apitman","children":[{"author":"nightpool","children":[],"created_at":"2024-07-31T00:54:42.000Z","created_at_i":1722387282,"id":41115572,"options":[],"parent_id":41115234,"points":null,"story_id":41114839,"text":"I don't think that's accurate\u2014homebrew specifically says that it only uses the .linuxbrew directory when a formula contains a hardcoded path (which it scans for), and only if you choose not to install it from source.
So, based on the responses from the maintainers, for the .linuxbrew directory to be used, you have to satisfy 2 conditions:
1. you have to be installing one of the ~10% of formula that isn't trivially relocatable.
2. you have to be using a precompiled binary (which it seems like homebrew is smart enough to not do if condition #1 fails and you're not using sudo)","title":null,"type":"comment","url":null}],"created_at":"2024-07-30T23:52:26.000Z","created_at_i":1722383546,"id":41115234,"options":[],"parent_id":41115173,"points":null,"story_id":41114839,"text":"That makes sense. The weird part to me is that Homebrew would limit their approach and eliminate an entire class of use cases to accommodate programs that work this way. There has to be more to it.","title":null,"type":"comment","url":null}],"created_at":"2024-07-30T23:40:24.000Z","created_at_i":1722382824,"id":41115173,"options":[],"parent_id":41115130,"points":null,"story_id":41114839,"text":"In the case of Watchman, I have to assume that internal use is the most supported use case, and uniformity of deployment is desirable across the fleet there, and so, configurability wasn't as big of a concern?","title":null,"type":"comment","url":null},{"author":"woodruffw","children":[],"created_at":"2024-07-30T23:59:01.000Z","created_at_i":1722383941,"id":41115258,"options":[],"parent_id":41115130,"points":null,"story_id":41114839,"text":"The short (but possibly not satisfying) answer is that Homebrew's relocation of packages (including binary relocation) is best effort, in part because of the myriad ways in which packages can embed absolute (or incorrect relative) paths and other state in their build products. macOS bottles are generally more relocatable (in part because of a lot of scar tissue around binary relocation), but it's a general problem with build system quality, build complexities, and - reasonably - disinterested upstreams.","title":null,"type":"comment","url":null},{"author":"KolenCh","children":[],"created_at":"2024-08-01T03:48:27.000Z","created_at_i":1722484107,"id":41125981,"options":[],"parent_id":41115130,"points":null,"story_id":41114839,"text":"This a not a unique problem to homebrew. Any pre-built binaries potentially shares this problem unless the build system the software use is intentionally written to avoid this problems.
Any package managers that is designed to not hard code the prefix, ie you can choose where the binaries go into, needs to handle this problem and have their own ways to deal with it. Conda for example has a long string of \u2026placehold_placehold_\u2026 to facilitate editing the hardcoded path\u2026
Source distribution is more robust against this problem comparing to binary distribution. (But sometimes the authors of the software did not package them well and would have hardcoded some paths somewhere.)
That\u2019s why when you change the homebrew prefix, they will built from source instead, and it (using a different prefix) might not work.","title":null,"type":"comment","url":null}],"created_at":"2024-07-30T23:32:14.000Z","created_at_i":1722382334,"id":41115130,"options":[],"parent_id":41114839,"points":null,"story_id":41114839,"text":"A while back I was trying to understand why Homebrew requires pre-built executables to be installed into /home/linuxbrew. I asked about it here[0]. This requirement basically makes it impossible to use homebrew to quickly install programs on systems where you don't have root, or at least have homebrew already configured (not sure if that would solve it but I assume so).
They pointed me to an example program that would break if not run this way: Facebook's Watchman[1].
It bizarrely (to me) has hard coded paths compiled into it, which force you to run it from specific directories.
Would love to understand what's going on here and why you would ever make software work this way. I feel I'm missing a fairly obvious Chesterton's Fence.
[0]: https://github.com/orgs/Homebrew/discussions/5371
[1]: https://facebook.github.io/watchman/docs/install#prebuilt-bi...","title":null,"type":"comment","url":null},{"author":"woodruffw","children":[],"created_at":"2024-07-30T23:49:02.000Z","created_at_i":1722383342,"id":41115214,"options":[],"parent_id":41114839,"points":null,"story_id":41114839,"text":"I'm the author of this post and one of the people behind the audit; happy to answer questions about it.
If you're having trouble finding the audit itself (it's linked indirectly), I'm linking a copy here as well[1].
[1]: https://github.com/trailofbits/publications/blob/eb9344f2261...","title":null,"type":"comment","url":null},{"author":"jmbwell","children":[{"author":"ggm","children":[],"created_at":"2024-07-31T00:04:08.000Z","created_at_i":1722384248,"id":41115288,"options":[],"parent_id":41115255,"points":null,"story_id":41114839,"text":"For people who don't know, pkgsrc works fine on macOS, the complaint was well made: its not the default.
I use brew, and have used pkgsrc in the past. I could go back for low pain.","title":null,"type":"comment","url":null},{"author":"CaliforniaKarl","children":[{"author":"nsagent","children":[{"author":"throwaway290","children":[],"created_at":"2024-07-31T01:05:11.000Z","created_at_i":1722387911,"id":41115613,"options":[],"parent_id":41115543,"points":null,"story_id":41114839,"text":"Same here.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T00:49:38.000Z","created_at_i":1722386978,"id":41115543,"options":[],"parent_id":41115307,"points":null,"story_id":41114839,"text":"Yeah, I switched from Homebrew to MacPorts a few years ago and couldn't be happier.","title":null,"type":"comment","url":null},{"author":"wwalexander","children":[],"created_at":"2024-07-31T01:10:56.000Z","created_at_i":1722388256,"id":41115634,"options":[],"parent_id":41115307,"points":null,"story_id":41114839,"text":"MacPorts is awesome. The PortGroups also make it super easy to make new packages.","title":null,"type":"comment","url":null},{"author":"brandall10","children":[{"author":"llimllib","children":[],"created_at":"2024-07-31T01:55:00.000Z","created_at_i":1722390900,"id":41115812,"options":[],"parent_id":41115766,"points":null,"story_id":41114839,"text":"Here\u2019s why I switched early on in homebrew\u2019s life from ports
- brew had and has many more packages available
- brew updates versions more quickly
- brew uses much more simple paths that fit my brain better
- brew has a pleasing simplicity","title":null,"type":"comment","url":null},{"author":"1123581321","children":[{"author":"steve_adams_86","children":[],"created_at":"2024-07-31T02:14:10.000Z","created_at_i":1722392050,"id":41115904,"options":[],"parent_id":41115818,"points":null,"story_id":41114839,"text":"> Also, back then there were lots of people experiencing package managers for the first time and they took to homebrew easily.
I suppose it was almost 15 years ago now but this is what I recall. Homebrew was easier, snappier, and the general friction coefficient felt smaller.
It's a little funny reading this and then wonder... Why did I leave MacPorts behind? I don't think I put much thought into it at the time and rather went by feel. I was still somewhat new to this stuff having started my career more in design than development.","title":null,"type":"comment","url":null},{"author":"BeFlatXIII","children":[],"created_at":"2024-07-31T12:19:41.000Z","created_at_i":1722428381,"id":41118575,"options":[],"parent_id":41115818,"points":null,"story_id":41114839,"text":"I\u2019d push back slightly on the \u201cmore space\u201d claim due to Apple\u2019s notorious stinginess for SSD & RAM.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T01:57:09.000Z","created_at_i":1722391029,"id":41115818,"options":[],"parent_id":41115766,"points":null,"story_id":41114839,"text":"MacPorts was slower (bringing in its own dependencies for everything meant longer build steps) and required sudo more. There were some annoying fiddly parts that made it seem like the homebrew users around you were having more fun exploring packages.
It was also exciting how many packages and casks were in homebrew and it was easy to make your own.
Also, back then there were lots of people experiencing package managers for the first time and they took to homebrew easily.
Then so many projects started to publish brew install links as a way to get started; homebrew felt like a default.
Now, with our faster computers, more space, and more packages installed, and macports shipping more binaries and using its own normal user, macports' duplication of dependencies looks more like an advantage than a disadvantage. And because homebrew taught so many people how to use package managers, macports is not their first so easier to start using.","title":null,"type":"comment","url":null},{"author":"jrochkind1","children":[],"created_at":"2024-07-31T02:26:34.000Z","created_at_i":1722392794,"id":41115954,"options":[],"parent_id":41115766,"points":null,"story_id":41114839,"text":"At the point I switched from MacPorts to Homebrew, homebrew just worked more reliably in my experience. It installed things quicker and with fewer build/install failures. i don't know enough about what was going on under the hood to have any theory as to why this was my experience; I don't want to know what's going on under the hood, I just want to type `install whatever`, and have it work.","title":null,"type":"comment","url":null},{"author":"sizeofchar","children":[{"author":"CaliforniaKarl","children":[{"author":"saagarjha","children":[],"created_at":"2024-07-31T05:56:56.000Z","created_at_i":1722405416,"id":41116693,"options":[],"parent_id":41116193,"points":null,"story_id":41114839,"text":"I think MacPorts builds basically everything and offers it as a binary if they think they can distribute it legally","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T03:34:22.000Z","created_at_i":1722396862,"id":41116193,"options":[],"parent_id":41116052,"points":null,"story_id":41114839,"text":"I don't know when they introduced it, but I believe MacPorts will build the common variants of the more-used packages. So, if you install a package with the default variants, you'll get a binary download instead of building from source.
But indeed; fast SSDs, parallel compilation, and modern CPUs really help!","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T02:54:06.000Z","created_at_i":1722394446,"id":41116052,"options":[],"parent_id":41115766,"points":null,"story_id":41114839,"text":"When I started using a Mac in 2009, MacPorts, Fink (and I think there was another I can't recall the name) simply wouldn't work for me. They would take very long to build what I wanted, there weren't nearly as many packages as was in Debian/Ubuntu, and many were old versions. Worse, many build attempts would just fail.
In that scenario, brew worked like a charm. It was quick, had most or even more packages than Debian/Ubuntu and they were newer. Failure to install was rare.
Then, Apple started yearly release of OS X, and that both broke brew and my system hard, so I started investigating and found out about the many "shortcuts" that brew took and how it violated systems components. I was dismayed, and abandoned brew for good.
So, I stood a period where I would use many of my tools inside a Ubuntu VM, until probably 2013-2014, when for some reason I tried again MacPorts, and I don't know why, but that time it was much more reliable, and because of Apple's insane atm SSDs with 2 GB/s bandwidth, install became quick enough. Packages were still somewhat lagging behind in available versions, but the variety of them kinda reached the levels of what was in Debian/Ubuntu, so it was good enough for me.
Then, the killer feature, I found out about macports variants and selectors, which I find the most awesome thing to this date in package managers (I haven't tried nix, still, it might be magnitude better in that regard). No needing to use rvm, pyenv, custom installs of gcc messing with make/autotools, and the only sane way of compiling various Haskell projects (before haskell-stack).","title":null,"type":"comment","url":null},{"author":"steve1977","children":[],"created_at":"2024-07-31T05:01:27.000Z","created_at_i":1722402087,"id":41116509,"options":[],"parent_id":41115766,"points":null,"story_id":41114839,"text":"I guess MacPorts was (and is) geared more towards users with some proper UNIX or BSD background, e.g. people coming from FreeBSD.
Whereas Homebrew targets the typical Mac user who might need a CLI application occasionally, i.e. someone looking for simplicity, without being too technically savvy.
The latter group certainly makes up a much bigger share of users on macOS, especially nowadays.","title":null,"type":"comment","url":null},{"author":"fragmede","children":[],"created_at":"2024-07-31T05:14:31.000Z","created_at_i":1722402871,"id":41116556,"options":[],"parent_id":41115766,"points":null,"story_id":41114839,"text":"this was a while back, in the Gentoo Linux heyday, so it was popular to compile things, except that this was when computers were slow, so that meant waiting for compiles. the problem with macports was that (iirc, it's been a while) it compiled its own version of Python instead of just using the system python, which also broke sometimes. and then you had to compile all that shit again. brew won out because it was faster, and didn't duplicate redundant shit for no perceived reasom.","title":null,"type":"comment","url":null},{"author":"pxc","children":[],"created_at":"2024-07-31T05:34:15.000Z","created_at_i":1722404055,"id":41116613,"options":[],"parent_id":41115766,"points":null,"story_id":41114839,"text":"Here's my guess.
Homebrew had at least these things going for it:
- it has always had a strong emphasis on presenting a simple, clean, pleasant, pretty, playful UI and executed that well\n - when it came out, source-based package managers for macOS generally didn't have any binary caching mechanisms, so compile time mattered\n - Homebrew's embrace of the base system as opposed to bringing its own dependencies bought it greater reuse at the cost of robustness, driving down total time to install many packages\n - the language that `brew` and its packages were written in was trendy at thw time as well as pre-installed on macOS, which made them instantly accessible to huge numbers of web developers\n - the older macOS package managers generally drew on traditions and tooling from the Linux world (e.g., Fink, with Debian tooling) or the wider Unix world (e.g., MacPorts and various *BSD ports systems and packages written in some Tcl IIRC).\n\nWhen you installed a port with brew it used as much of the OSX, X11, and XCode installed utilities as possible so it was faster and used less storage. But then you would install an update from Apple and things would break cause of that reliance, things like /usr/bin/perl.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T01:41:27.000Z","created_at_i":1722390087,"id":41115766,"options":[],"parent_id":41115307,"points":null,"story_id":41114839,"text":"Anyone know why Homebrew overtook MacPorts? I only have a vague recollection of a Rails colleague pushing me to switch circa 2013 or so and haven't given it much thought since, but it (MacPorts) seemed to be similarly ubiquitous prior.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T00:08:16.000Z","created_at_i":1722384496,"id":41115307,"options":[],"parent_id":41115255,"points":null,"story_id":41114839,"text":"I've been using MacPorts for as long as I've wanted a macOS package manager, and it's been working very well for me.","title":null,"type":"comment","url":null},{"author":"paholg","children":[{"author":"SOLAR_FIELDS","children":[{"author":"paholg","children":[],"created_at":"2024-07-31T01:58:09.000Z","created_at_i":1722391089,"id":41115827,"options":[],"parent_id":41115730,"points":null,"story_id":41114839,"text":"Huh, interesting. I did primarily use FOSS and CLI applications. It's been a couple years, so I don't remember what exactly I used it for. I probably installed Docker Desktop via whatever method docker recommends, and I'm not sure about Firefox.
For alacrity, I remember it being annoying to integrate into Mac's launcher, but it otherwise worked.
Pretty much everything else was programming-related and just worked.","title":null,"type":"comment","url":null},{"author":"Cloudef","children":[{"author":"SOLAR_FIELDS","children":[],"created_at":"2024-07-31T19:54:14.000Z","created_at_i":1722455654,"id":41122833,"options":[],"parent_id":41116358,"points":null,"story_id":41114839,"text":"Tried this when it was released on HN. It does not work out of the box. There is some problem with launching apps from outside of the applications folder. The trampoline Mac-app-\u00fatil approach does not work. Though in theory it probably should for most applications. I don\u2019t know enough about the code signing process to be able to debug what is wrong with it.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T04:13:21.000Z","created_at_i":1722399201,"id":41116358,"options":[],"parent_id":41115730,"points":null,"story_id":41114839,"text":"If you want graphical apps to be handled by nix on macos, you might be interested in <https://github.com/BatteredBunny/brew-nix>. nixpkgs does not package macos sandboxed apps AFAIK, that means typically only cli utilities, libraries and development tools only work.","title":null,"type":"comment","url":null},{"author":"pxc","children":[{"author":"SOLAR_FIELDS","children":[{"author":"pxc","children":[{"author":"SOLAR_FIELDS","children":[{"author":"pxc","children":[{"author":"SOLAR_FIELDS","children":[],"created_at":"2024-08-01T14:40:50.000Z","created_at_i":1722523250,"id":41129590,"options":[],"parent_id":41126387,"points":null,"story_id":41114839,"text":"As for your first question, about why 1Password refuses to run outside of Applications, I\u2019m pretty sure it\u2019s security. There is something special about Applications on MacOS that apparently AgileBits views as an attack vector when run outside of it.
I was curious about your final question as well, but I know little about how this works. The error when I tried vscode looked to be that the signature had gotten malformed somehow during brew-nix\u2019s copy operation but since I had no idea what a correct signature should even look like I got stumped there.","title":null,"type":"comment","url":null}],"created_at":"2024-08-01T05:20:34.000Z","created_at_i":1722489634,"id":41126387,"options":[],"parent_id":41125645,"points":null,"story_id":41114839,"text":"I just tried 1Password and it refused to start not being in `/Applications`. I've seen this happen with one other app (Secretive), although it doesn't quite refuse to run. I can't remember all the details, but I think it has to do with a limitation in newer versions of macOS, where apps that try to register launchd services can only do so if they live in /Applications rather than ~/Applications. The problem with launching those background services from binaries that live in ~/Applications disappears if you disable SIP. When I first encountered it, it made me wonder if ~/Applications is not really supported on modern macOS. I wish I could find the issue for that but I didn't, when I looked just now. :-\\
Oh, here's that issue: https://github.com/maxgoedjen/secretive/issues/77
1Password definitely acts weird for me, to where I kind of wonder if the .app folder is malformed somehow. The version installed in the Nix store actually works fine-- but not if I double-click it or open it with the `open` command. In that case it kinda acts like something is going to launch but then it never comes up. But if I manually invoke `/Applications/Nix\\ Apps/1Password.app/Contents/MacOS/1Password` from my terminal, it starts up fine! But when I directly launch that executable from Finder, the application does not start and I see that same message about not living in /Applications printed in the terminal. Idk why 1Password refuses to run from anywhere other than /Applications but that seems to be it's message rather than the operating system's.
It's a shame 1Password's Mac app can't run from the Nix store. They clearly have at least one Nixer at the company because they have cool integrations like this:
https://developer.1password.com/docs/cli/shell-plugins/nix/
I couldn't even get the Docker Desktop package to build from `brew-nix`. OrbStack in the Nix store died on signature errors, but when I visited Security & Privacy in System Preferences after that, there was a little notice that OrbStack had been blocked from running because it was from an unrecognized developer, with the option to allow it. After being allowed, it seemed to work as normal. Same for Podman Desktop.
Why do the signatures for those apps end up getting replaced with this setup anyway?","title":null,"type":"comment","url":null}],"created_at":"2024-08-01T02:25:01.000Z","created_at_i":1722479101,"id":41125645,"options":[],"parent_id":41125553,"points":null,"story_id":41114839,"text":"1Password and docker desktop are two good test subjects. 1Password especially is the one I mentioned above as being a problem child in general with nix setups on Mac
VScode in particular was the one that broke for me, though that is actually available and mostly functional in nixpkgs so that one is not a showstopper.but might be a good test case to repro","title":null,"type":"comment","url":null}],"created_at":"2024-08-01T02:01:54.000Z","created_at_i":1722477714,"id":41125553,"options":[],"parent_id":41122838,"points":null,"story_id":41114839,"text":"Ugh! How annoying. Which apps did you try that with? I just gave it a try with a couple random ones. I tried Marta, CyberDuck, IINA, KeePassXC, and CotEditor and they all worked.
(Spotify didn't build because the Brew package doesn't have a hash, and Karabiner Elements didn't build bc idk why, but that's actually in Nixpkgs already and that version works fine.)
I did double-check that I have SIP enabled and everything. I'd be interested in trying to repro!
Aside: that mac-app-util works so nicely for the macOS apps that are already in Nixpkgs makes it feel much more worth it to me to package GUI apps for macOS, if that'll mean I can get rid of `brew` entirely. I wonder if this will spur others to also package more GUI apps this way.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T19:54:47.000Z","created_at_i":1722455687,"id":41122838,"options":[],"parent_id":41116539,"points":null,"story_id":41114839,"text":"I tried this exact combination but it did not work out of the box for the apps I tried. For gui apps bundled with brew-nix they will panic due to something about how the code signing keys are copied with brew-nix. The Mac-app-util trampoline launcher does work with the regular way that brew is managed with nix (which under the hood just shells out to brew) though. So the problem is likely related to brew-nix installing apps outside of the Applications folder.
I hacked around a bit trying a few different approaches before giving up and switching back to the regular nix-Darwin homebrew approach. But the issue is probably solvable by someone who knows a lot more about how the code signing process works with Macs and the Applications folder","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T05:10:17.000Z","created_at_i":1722402617,"id":41116539,"options":[],"parent_id":41115730,"points":null,"story_id":41114839,"text":"I recently tried out mac-app-util\u00b9, which fixes some of the usual pain with GUI apps. In conjunction with brew-nix\u00b2, it looks like it might be most of what I'll need to move away from having Nix manage Homebrew for me.
I don't use very many GUI apps so now that the installation piece is taken care of, I can just package everything I use if it really comes down to it. That'd be worth it for me just to get rid of the painfully slow `brew` invocations that lurk in my activation scripts.
--
1: https://github.com/hraban/mac-app-util
2: https://github.com/BatteredBunny/brew-nix","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T01:32:52.000Z","created_at_i":1722389572,"id":41115730,"options":[],"parent_id":41115339,"points":null,"story_id":41114839,"text":"Do you not use many packages and only strictly use FOSS tooling? I have a large and growing list of packages that have to be managed in Homebrew still because the package is one of the following:
1. Not available at all in nixpkgs (e.g. Docker Desktop, BetterTouchTool, etc)
2. In nixpkgs, but completely broken or missing some architecture support (e.g. Firefox)
3. Actually available and somewhat functional in nixpkgs, but some significant features don't work because of code signing requirements and needing to be managed in the Applications folder (e.g. 1Password)
Quite a few tools do in fact work well with nix on Mac. Especially if it's FOSS and/or a cli-only based tool. And for FOSS tooling such as Firefox, there is often a convoluted workaround (I'm currently using `github:bandithedoge/nixpkgs-firefox-darwin`). And of course you can always package it yourself by doing things The Hard Way.
But the platform is still quite a ways away from being able to be used as a daily driver on Mac without Homebrew.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T00:12:32.000Z","created_at_i":1722384752,"id":41115339,"options":[],"parent_id":41115255,"points":null,"story_id":41114839,"text":"When I've had to use a Mac, I've used nix to good success. I'm actually surprised how well it worked; I was able to basically just use the same config I use on Linux, removing just the few Linux-specific packages.","title":null,"type":"comment","url":null},{"author":"arprocter","children":[{"author":"jonhohle","children":[],"created_at":"2024-07-31T02:56:26.000Z","created_at_i":1722394586,"id":41116063,"options":[],"parent_id":41115357,"points":null,"story_id":41114839,"text":"Switch to MacPorts. It supports precompiled packages, doesn\u2019t take over the world and force anything on you the same way Homebrew does.
I\u2019m really disappointed in how Homebrew took a lot of attention away from the existing package managers, made a bunch of terrible decisions related to packaging and flexibility and genera Unix philosophy, and then ate the world.
: shakes fist at clouds, get off my lawn","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T00:16:34.000Z","created_at_i":1722384994,"id":41115357,"options":[],"parent_id":41115255,"points":null,"story_id":41114839,"text":"It'd be nice if brew was a little more apt-y, and all the beer nomenclature is a bit silly
My first exposure to Mac package stuff was fink in the early aughts - compiling everything on a Pismo G3 was pretty slow going","title":null,"type":"comment","url":null},{"author":"bainganbharta","children":[{"author":"throw0101a","children":[],"created_at":"2024-07-31T13:12:35.000Z","created_at_i":1722431555,"id":41118902,"options":[],"parent_id":41115469,"points":null,"story_id":41114839,"text":"> https://pkgsrc.smartos.org/install-on-macos/
Note that Pkgsrc is a NetBSD-derived project.
The Joyent folks leveraged it to allow their customers, who were perhaps not as familiar with Solaris/SmartOS, a larger pool of packages. Pkgsrc was running on Solaris before Joyent, Joyent built on top of it.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T00:36:17.000Z","created_at_i":1722386177,"id":41115469,"options":[],"parent_id":41115255,"points":null,"story_id":41114839,"text":"This is the pkgsrc-based package manager I use on macOS. It's simple and has the packages I need.
https://pkgsrc.smartos.org/install-on-macos/","title":null,"type":"comment","url":null},{"author":"8b16380d","children":[],"created_at":"2024-07-31T00:51:30.000Z","created_at_i":1722387090,"id":41115553,"options":[],"parent_id":41115255,"points":null,"story_id":41114839,"text":"Just use pkgsrc or macports. IMO way easier and less intrusive than homebrew.","title":null,"type":"comment","url":null},{"author":"rahen","children":[],"created_at":"2024-07-31T20:54:42.000Z","created_at_i":1722459282,"id":41123355,"options":[],"parent_id":41115255,"points":null,"story_id":41114839,"text":"I've been using pkgin and pkgsrc for years on macOS. Occasionally, I still need a small brew prefix when a dependency is missing or difficult to build. Molten-vk was the last such package.
pkgsrc is by far the most KISS package manager for macOS, I like it.","title":null,"type":"comment","url":null}],"created_at":"2024-07-30T23:58:35.000Z","created_at_i":1722383915,"id":41115255,"options":[],"parent_id":41114839,"points":null,"story_id":41114839,"text":"With so many other package managers available, I often wish something else was the de facto package manager on macOS. Something like pkgsrc, which follows conventions much better and is thereby much easier to manage.","title":null,"type":"comment","url":null},{"author":"neverrroot","children":[],"created_at":"2024-07-31T00:05:02.000Z","created_at_i":1722384302,"id":41115294,"options":[],"parent_id":41114839,"points":null,"story_id":41114839,"text":"Not surprised to see some problems. Still sad to see security take a backseat as opposed to convenience.","title":null,"type":"comment","url":null},{"author":"greggsy","children":[{"author":"dotBen","children":[{"author":"brimwats","children":[{"author":"azurezyq","children":[{"author":"greggsy","children":[],"created_at":"2024-08-01T05:06:51.000Z","created_at_i":1722488811,"id":41126331,"options":[],"parent_id":41121604,"points":null,"story_id":41114839,"text":"It was a well organised operation. I don\u2019t believe we\u2019ll ever know. It likely wasn\u2019t even one person.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T18:05:45.000Z","created_at_i":1722449145,"id":41121604,"options":[],"parent_id":41121555,"points":null,"story_id":41114839,"text":"Also for that case, I don't think we have any clue who the guy is. Name just not meaning anything. Or anyone has any link to a formal trace to the origin?","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T18:02:01.000Z","created_at_i":1722448921,"id":41121555,"options":[],"parent_id":41121068,"points":null,"story_id":41114839,"text":"> enough publicized cases of Chinese CCP operatives gaining
Like? not doubting you, just not aware of multiple cases beyond the big near-miss earlier this year","title":null,"type":"comment","url":null},{"author":"lionkor","children":[{"author":"0xedd","children":[{"author":"aibrahem","children":[],"created_at":"2024-08-02T03:26:03.000Z","created_at_i":1722569163,"id":41135844,"options":[],"parent_id":41123771,"points":null,"story_id":41114839,"text":"So is aiding and actively supporting a genocide and celebrating a war criminal, so what is your point?","title":null,"type":"comment","url":null},{"author":"lenkite","children":[],"created_at":"2024-08-04T15:50:10.000Z","created_at_i":1722786610,"id":41154291,"options":[],"parent_id":41123771,"points":null,"story_id":41114839,"text":"The U.S. also harvests the organs of dead prisoners without consent. This is well-documented. 2 Democratic senators even proposed a bill to "reduce sentences" by "donating" your organs.
The U.S. runs the world's most extensive biological weapons research program and firmly opposes any verification for the BWC to which the U.S. is a signatory. The Pentagon operates a ridiculous number of bio labs in other nations.
The U.S. NIH was indirectly responsible for Covid - thanks to sponsorship of gain-of-function research into bat coronaviruses via the Ecohealth alliance, sponsorship of which was approved by good old "I represent Science" Dr Fauci. A massive and desperate cover up operation was performed by the NIH here. Hell, there were e-mails sent to delete everything and deflect all inquiries.
The U.S. deliberately sponsors coups in nations across the world for leaders they don't like - as evidenced by de-classified documents. The U.S. military budget is 7 times higher than that of China. Nearly a million people were killed directly and in-directly in Yemen thanks to good old American bombs.
Let's not even get into earlier acts - like Obama's "moderate rebels" in Syria who were busy chaining women in Aleppo and who devolved into ISIS after the Syrian army kicked them out and decided to conquer Iraq instead - all with the latest American weaponry in hand! (I strongly suggest speaking to a native Syrian who lived in Aleppo during that time to know about the horror)
Other than these very small misdemeanours, the U.S. is a saint! Doubly so on the internet. /s","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T21:42:40.000Z","created_at_i":1722462160,"id":41123771,"options":[],"parent_id":41123664,"points":null,"story_id":41114839,"text":"Yeah, well, harvesting human organs (selling them to US customers) and maintaining death camps in 2024 is kind of "bad guys" for me. But, to each his own, I suppose.
https://www.ohchr.org/en/press-releases/2021/06/china-un-hum... \nhttps://theconversation.com/killing-prisoners-for-transplant... \nhttps://www.bbc.com/news/world-asia-china-54277430
Other than these small misdemeanours, they're saints! Doubly so on the internet. /s","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T21:31:10.000Z","created_at_i":1722461470,"id":41123664,"options":[],"parent_id":41121068,"points":null,"story_id":41114839,"text":"Ah yes, the "bad guys".","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T17:14:24.000Z","created_at_i":1722446064,"id":41121068,"options":[],"parent_id":41115374,"points":null,"story_id":41114839,"text":"I can't emphasize enough how much of a genuine issue this is, especially where package managers are being used on production environments or within CI/CD pipelines. There's enough publicized cases of Chinese CCP operatives gaining pull request access to key packages, and I'm sure many more get discovered that are covered up/not made public. Even just turn over of package ownership from reputable entities to lesser known individuals is of course worrying.
As a SWE/EngMgr turned VC, I'm curious if there's startups or commercial companies providing some kind of assurance here (but also worried the $ TAM for solving this problem probably isn't enough to make it a standalone business).","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T00:18:46.000Z","created_at_i":1722385126,"id":41115374,"options":[],"parent_id":41114839,"points":null,"story_id":41114839,"text":"Excellent work - a methodical review like this is exactly what I\u2019ve been looking for in these sorts of open source solutions.
I know it\u2019s not the focus of a code review like this, but I\u2019m interested to hear your views on the general supply chain lifecycle problems inherent to open-source package management platforms. Principally, are vetting processes appropriate to ensure that new formulas refer to the correct source? How does the user gain confidence that their brew update is still referencing a trusted source? What happens when a domain is taken over? How quickly can the team respond to untrusted sources from formulas?
I know these aren\u2019t all Homebrew problems to solve, but they\u2019re important ecosystem considerations.
(These problems also exist in the winget and choco platforms, but less so in commercially supported repos like apt and yum. For me, and many other admins, they are a major concern when it comes to the Windows Store.)
Edit: lastly, in case the homebrew team are watching: an npm-style vulnerability notice would be awesome","title":null,"type":"comment","url":null},{"author":"user3939382","children":[{"author":"bdangubic","children":[],"created_at":"2024-07-31T00:40:36.000Z","created_at_i":1722386436,"id":41115492,"options":[],"parent_id":41115404,"points":null,"story_id":41114839,"text":"honebrew works too :)","title":null,"type":"comment","url":null},{"author":"8b16380d","children":[],"created_at":"2024-07-31T00:50:02.000Z","created_at_i":1722387002,"id":41115547,"options":[],"parent_id":41115404,"points":null,"story_id":41114839,"text":"Nah I\u2019ve been on macports for years now. No problems; the community is very active, just follow the mailing lists etc","title":null,"type":"comment","url":null},{"author":"paradox460","children":[],"created_at":"2024-07-31T00:52:39.000Z","created_at_i":1722387159,"id":41115558,"options":[],"parent_id":41115404,"points":null,"story_id":41114839,"text":"I keep ports around for things like lilypond (which I use for quasi-professional score engraving) and some other packages that homebrew is weird on. The removal of options a few years back still stinks for be","title":null,"type":"comment","url":null},{"author":"wwalexander","children":[],"created_at":"2024-07-31T01:29:16.000Z","created_at_i":1722389356,"id":41115720,"options":[],"parent_id":41115404,"points":null,"story_id":41114839,"text":"There are dozens of us!","title":null,"type":"comment","url":null},{"author":"blt","children":[],"created_at":"2024-07-31T02:11:02.000Z","created_at_i":1722391862,"id":41115885,"options":[],"parent_id":41115404,"points":null,"story_id":41114839,"text":"I got sick of Homebrew after a while and tried switching to MacPorts, but it feels like an endless uphill battle when so many packages only offer source and Homebrew distributions.","title":null,"type":"comment","url":null},{"author":"pxc","children":[],"created_at":"2024-07-31T05:43:48.000Z","created_at_i":1722404628,"id":41116641,"options":[],"parent_id":41115404,"points":null,"story_id":41114839,"text":"I mostly just use Nix, but I also have pkgsrc, MacPorts, and (kinda) Homebrew installed on my Mac.
The only ones with any CLI tools installed, though, are Nix and pkgsrc.","title":null,"type":"comment","url":null},{"author":"_0xdd","children":[],"created_at":"2024-07-31T14:23:26.000Z","created_at_i":1722435806,"id":41119429,"options":[],"parent_id":41115404,"points":null,"story_id":41114839,"text":"You are not. I've been using MacPorts for 15+ years at this point. Started with fink and then made the switch around the days of Snow Leopard. I'm also a BSD user, so no surprise there. I enjoy being able to compile ports with non-standard variants (e.g., non-free codecs in ffmpeg, removing un-needed interpreters from packages, etc.)","title":null,"type":"comment","url":null},{"author":"RandomThoughts3","children":[],"created_at":"2024-08-01T08:29:10.000Z","created_at_i":1722500950,"id":41127191,"options":[],"parent_id":41115404,"points":null,"story_id":41114839,"text":"I'm still sour that homebrew gained so many user when it was started by basically FUD-ing Macports and arguing that their ability to reuse the existing toolchain of OSX with the superior choice while Macports pointed out that homebrew design was flawed.
Fast forward to now, Homebrew actually had to make all the changes Macports pointed out as flawed design decisions because, well, they were but enjoy more users and has tainted Macports reputation. It's very much a case of the inferior product winning as far as I'm concerned. I know that most of the original team is not there anymore but I still mostly refuse to use it.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T00:25:43.000Z","created_at_i":1722385543,"id":41115404,"options":[],"parent_id":41114839,"points":null,"story_id":41114839,"text":"I\u2019m still good on MacPorts. Seems I\u2019m alone these days. Works fine for me.","title":null,"type":"comment","url":null},{"author":"scovetta","children":[],"created_at":"2024-07-31T00:45:26.000Z","created_at_i":1722386726,"id":41115522,"options":[],"parent_id":41114839,"points":null,"story_id":41114839,"text":"Well done! And thank you to the Open Tech Fund for sponsoring work to protect everyone who uses Homebrew.","title":null,"type":"comment","url":null},{"author":"marxisttemp","children":[{"author":"jagged-chisel","children":[{"author":"ggm","children":[{"author":"eduction","children":[{"author":"parhamn","children":[{"author":"ggm","children":[],"created_at":"2024-07-31T02:13:27.000Z","created_at_i":1722392007,"id":41115898,"options":[],"parent_id":41115814,"points":null,"story_id":41114839,"text":"The person you're responding to may have been using homebrew on Intel. It's been in /opt on ARM since inception on ARM.","title":null,"type":"comment","url":null},{"author":"eduction","children":[{"author":"azinman2","children":[{"author":"eduction","children":[],"created_at":"2024-07-31T20:21:51.000Z","created_at_i":1722457311,"id":41123030,"options":[],"parent_id":41116599,"points":null,"story_id":41114839,"text":"That seems like a totally valid perspective. Macports page I linked claims that Apple is often too slow to update, and in some cases only does so when there is a security breach. I can\u2019t vouch for if that\u2019s true. In my experiments maybe 10 yrs ago it took substantially longer for me to install a certain set of packages on Macports vs homebrew due to the parallel library thing. But I had had some broken packages with brew and found Macports more reliable.
Does seem like something Apple should fund / handle IMO.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T05:28:33.000Z","created_at_i":1722403713,"id":41116599,"options":[],"parent_id":41116103,"points":null,"story_id":41114839,"text":"I much rather them use system libraries than build parallel libs that don\u2019t go through Apple\u2019s vetting / changes. This has worked well for me in practice. I\u2019ve actually never run into an issue where the system library got updated and that broke homebrew\u2019s apps.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T03:08:10.000Z","created_at_i":1722395290,"id":41116103,"options":[],"parent_id":41115814,"points":null,"story_id":41114839,"text":"I did not know about the new directory practice, thanks.
From what their site says it looks like it was done this way to keep ARM native stuff separate from old intel code which can still work under Rosetta. But I don't see any indication homebrew stopped linking system libraries as a matter of course (correct me if I'm wrong).
MacPorts makes a point of not doing this. /opt/local is its own universe and dependencies can be upgraded more or less aggressively than Apple's. https://trac.macports.org/wiki/FAQ#syslibs","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T01:55:55.000Z","created_at_i":1722390955,"id":41115814,"options":[],"parent_id":41115806,"points":null,"story_id":41114839,"text":"> Key difference is Mac ports keeps its tree separate in /opt
What do you mean by this? brew has been linking from /opt/homebrew for years now.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T01:52:36.000Z","created_at_i":1722390756,"id":41115806,"options":[],"parent_id":41115750,"points":null,"story_id":41114839,"text":"Key difference is Mac ports keeps its tree separate in /opt. This means things take longer initially to install because it can\u2019t just leverage system stuff already there. Upside is greater reliability because it doesn\u2019t have to worry about a system update changing its dependencies.
I prefer the greater reliability of macports.","title":null,"type":"comment","url":null},{"author":"dmd","children":[{"author":"ggm","children":[],"created_at":"2024-07-31T02:13:55.000Z","created_at_i":1722392035,"id":41115902,"options":[],"parent_id":41115813,"points":null,"story_id":41114839,"text":"On reflection I think you are very probably right. I should have thought more about my origin story before posting.
Once, long ago...","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T01:55:34.000Z","created_at_i":1722390934,"id":41115813,"options":[],"parent_id":41115750,"points":null,"story_id":41114839,"text":"That was probably true in homebrew\u2019s first year. At this point I would be shocked if more than a fraction of a percent of homebrew users have ever even heard of macports or fink.","title":null,"type":"comment","url":null},{"author":"atribecalledqst","children":[],"created_at":"2024-07-31T05:43:10.000Z","created_at_i":1722404590,"id":41116637,"options":[],"parent_id":41115750,"points":null,"story_id":41114839,"text":"On an old Macbook I keep around for various rare offline tasks, I actually did go back to MacPorts from Homebrew. Chief reason being: Homebrew doesn't support old versions of the OS so I was SOL trying to install a new package on it. The backwards compatibility is a nice feature!
My current machine is also not on the latest so I wonder if an attempt to brew update would nag me now...","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T01:38:29.000Z","created_at_i":1722389909,"id":41115750,"options":[],"parent_id":41115704,"points":null,"story_id":41114839,"text":"Most homebrew users started in macports, or fink. Very few I talk to (admittedly not many and curmugeons) want to go back.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T01:25:58.000Z","created_at_i":1722389158,"id":41115704,"options":[],"parent_id":41115626,"points":null,"story_id":41114839,"text":"so many projects release only formulas for homebrew. I keep both and try to use McPorts first.","title":null,"type":"comment","url":null},{"author":"eviks","children":[{"author":"remram","children":[{"author":"eviks","children":[],"created_at":"2024-07-31T13:37:23.000Z","created_at_i":1722433043,"id":41119049,"options":[],"parent_id":41118968,"points":null,"story_id":41114839,"text":"- too much sudo friction
- homebrew's design of having a single app's folder is better, e.g., can use your basic file manager to see the total size
- updates requiring manual inervention
- fewer/less updated packages (mabye due to the previous deficiency?)
- large duplicate database wasting space (and think it's even uncompressed) (brew got better when it moved to it API)","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T13:22:27.000Z","created_at_i":1722432147,"id":41118968,"options":[],"parent_id":41116310,"points":null,"story_id":41114839,"text":"For example?","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T03:57:40.000Z","created_at_i":1722398260,"id":41116310,"options":[],"parent_id":41115626,"points":null,"story_id":41114839,"text":"It's also a worse design in some aspects, so not a clear winner","title":null,"type":"comment","url":null},{"author":"MilaM","children":[{"author":"Asmod4n","children":[],"created_at":"2024-07-31T08:56:22.000Z","created_at_i":1722416182,"id":41117465,"options":[],"parent_id":41116691,"points":null,"story_id":41114839,"text":"The approach of Mac ports and Homebrew have been the complete opposite when Homebrew came into existence.\nMac ports tried to make packages compatible with whatever Apple shipped, aka their own twists on Perl, python, OpenSSL etc.\nWhile Homebrew tried to make macOS compatible with whatever existed out there.\nAs a developer Homebrew gave you a more up to date and fully functional experience.\nCan\u2019t tell you how it is today since Apple removed all interpreters and such from macOS.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T05:56:03.000Z","created_at_i":1722405363,"id":41116691,"options":[],"parent_id":41115626,"points":null,"story_id":41114839,"text":"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 anymore.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T01:08:09.000Z","created_at_i":1722388089,"id":41115626,"options":[],"parent_id":41114839,"points":null,"story_id":41114839,"text":"MacPorts is always waiting for you with more packages, a better design, and Jordan Hubbard\u2019s history with BSD/Apple :)","title":null,"type":"comment","url":null},{"author":"pmarreck","children":[{"author":"bokchoi","children":[{"author":"Brian_K_White","children":[{"author":"pmarreck","children":[],"created_at":"2024-07-31T20:48:50.000Z","created_at_i":1722458930,"id":41123291,"options":[],"parent_id":41117019,"points":null,"story_id":41114839,"text":"> It works but it feels kind of 70's or assembly.
I mean, this is basically all of Bash lol. A very clever idea that has endured since the 70's but also shows it... And yet we get obsessed with "writing perfect Bash" still.
The amazing thing is that there are also old "functional shells" like es-shell https://wryun.github.io/es-shell/ (he still works on this and it is indeed very interesting!)","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T07:14:43.000Z","created_at_i":1722410083,"id":41117019,"options":[],"parent_id":41116670,"points":null,"story_id":41114839,"text":"So do I ;)
I've had some form of `grep '^#h ' $0` in most of my scripts forever.
This one is a purity stunt and doesn't use grep, or anything else:\nhttps://github.com/bkw777/pdd.sh
(the script itself is of no use to you since it only talks to a piece of hardware)
The command dispatcher case statement and all the embedded help is in do_cmd() at 2857, and the help reader is help() at 425
I like their explicit #args vs #help
One jank in mine is I have a verbosity level setting which affects most messages, and help() uses it to filter some of the help. Normal verbosity shows only the normal help for the normal commands. If verbosity is set higher, then help() shows more commands.
The way that's implimented in help() is extra comments that change the behavior of help() as it's scanning the file from top to bottom.
When it hits a '#v 2' it starts only displaying the help if the user has currently set verbosity>=2 until further notice. Later down the file it hits a '#v 1' and starts displaying help again...
It works but it feels kind of 70's or assembly.
#v 1\n #h normal help for mortals\n #h ...\n #v 2\n #h don't confuse the simple folk with this dangerous powerful stuff...\n #h ...\n #v 1\n #h a few more normal commands\n #h ...\n #v 0\n #h display this even the user has set verbosity to 0 to request silence\n #h ...Helped that I'm good at regex lol","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T05:50:57.000Z","created_at_i":1722405057,"id":41116670,"options":[],"parent_id":41115843,"points":null,"story_id":41114839,"text":"I also find the nix command line annoying. I'll give this a try. I like the embedded `#help` documentation!","title":null,"type":"comment","url":null},{"author":"pyjamafish","children":[{"author":"pmarreck","children":[],"created_at":"2024-07-31T20:45:31.000Z","created_at_i":1722458731,"id":41123252,"options":[],"parent_id":41119238,"points":null,"story_id":41114839,"text":"Thanks for the mention!
I just noticed there's a bug with uninstalling. Probably a parsing issue, they must have changed the output of nix for that (this isn't the first time that happened...)","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T14:00:02.000Z","created_at_i":1722434402,"id":41119238,"options":[],"parent_id":41115843,"points":null,"story_id":41114839,"text":"I wish I had known about ixnay earlier! I also got annoyed of the user experience, to the point where I also wrote my own tool, hdn: https://github.com/seasonedfish/hdn
I added a mention of ixnay to its readme :)","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T02:00:59.000Z","created_at_i":1722391259,"id":41115843,"options":[],"parent_id":41114839,"points":null,"story_id":41114839,"text":"I ditched `brew` for `nix` a while back and while the TUI could be more end-user-friendly (to the point that I wrote a wrapper called "ixnay" just so I could do "ixnay install <packagename>" as easily as with brew, https://github.com/pmarreck/ixnay), the overall guarantees make it worth it.","title":null,"type":"comment","url":null},{"author":"arandomhuman","children":[{"author":"pxc","children":[],"created_at":"2024-07-31T04:50:59.000Z","created_at_i":1722401459,"id":41116472,"options":[],"parent_id":41116180,"points":null,"story_id":41114839,"text":"There have been a few attempts at this. I think some of them may even be working.","title":null,"type":"comment","url":null},{"author":"megamix","children":[{"author":"sirn","children":[],"created_at":"2024-07-31T09:29:00.000Z","created_at_i":1722418140,"id":41117608,"options":[],"parent_id":41116678,"points":null,"story_id":41114839,"text":"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.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T05:52:28.000Z","created_at_i":1722405148,"id":41116678,"options":[],"parent_id":41116180,"points":null,"story_id":41114839,"text":"Is MacPorts not the same? Genuinely asking.","title":null,"type":"comment","url":null},{"author":"izik","children":[],"created_at":"2024-07-31T08:09:07.000Z","created_at_i":1722413347,"id":41117249,"options":[],"parent_id":41116180,"points":null,"story_id":41114839,"text":"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\n[2] https://github.com/kladd/pacman-osx","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T03:31:23.000Z","created_at_i":1722396683,"id":41116180,"options":[],"parent_id":41114839,"points":null,"story_id":41114839,"text":"If 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 make me wish pacman just worked on macs.","title":null,"type":"comment","url":null},{"author":"nothrowaways","children":[{"author":"CydeWeys","children":[{"author":"rurban","children":[{"author":"pxc","children":[{"author":"saagarjha","children":[],"created_at":"2024-07-31T05:54:47.000Z","created_at_i":1722405287,"id":41116685,"options":[],"parent_id":41116621,"points":null,"story_id":41114839,"text":"You should read https://en.wikipedia.org/wiki/MacPorts#History. But to answer your question: why not? Apple employs thousands of software engineers.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T05:37:15.000Z","created_at_i":1722404235,"id":41116621,"options":[],"parent_id":41116601,"points":null,"story_id":41114839,"text":"Then why did Apple hire the creator of Homebrew to work on the package manager for Swift?","title":null,"type":"comment","url":null},{"author":"dewey","children":[],"created_at":"2024-07-31T07:04:00.000Z","created_at_i":1722409440,"id":41116972,"options":[],"parent_id":41116601,"points":null,"story_id":41114839,"text":"No need to call someone\u2019s free open source project \u201crubbish\u201d.","title":null,"type":"comment","url":null},{"author":"latexr","children":[{"author":"rurban","children":[],"created_at":"2024-08-01T07:44:14.000Z","created_at_i":1722498254,"id":41126988,"options":[],"parent_id":41118455,"points":null,"story_id":41114839,"text":"Wrong. MacPorts started as official DarwinPorts, supported by Apple. It became independent later. It is a proper ports package manager.
Homebrew would have a good head start, because it can use a better language, ruby. But it blew its chances with many questionable choices, they are just amateurs. But as always, worse is better.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T12:04:53.000Z","created_at_i":1722427493,"id":41118455,"options":[],"parent_id":41116601,"points":null,"story_id":41114839,"text":"That is provably false from so many angles.
* Apple has no aversion to Ruby, and on the contrary has multiple developers pushing for it. They themselves had MacRuby, a project that allowed one to create Mac OS X (at the time) applications with Ruby.\u00b9
* The reason there\u2019s even an Xcode command line tools package available officially from Apple is because of Homebrew. A third-party made it first by extracting the necessary bits and then Apple officially supported it.\u00b2
* There\u2019s a liaison between Homebrew and Apple, who helped during the Intel to Apple Silicon transition.\u00b3
\u00b9 https://web.archive.org/web/20100908131627/http://developer....
\u00b2 I know this from a reliable source and it is public information, but it was so long ago it\u2019s hard to find.
\u00b3 The official Homebrew Twitter account tweeted about this at the time. I no longer have a Twitter account so can\u2019t dig it up.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T05:29:30.000Z","created_at_i":1722403770,"id":41116601,"options":[],"parent_id":41116544,"points":null,"story_id":41114839,"text":"Apple would certainly favor macports over that rubbish ruby thing. Ports are from FreeBSD, MacOS is from FreeBSD.","title":null,"type":"comment","url":null},{"author":"arvinsim","children":[{"author":"Lio","children":[{"author":"throw0101a","children":[],"created_at":"2024-07-31T13:20:24.000Z","created_at_i":1722432024,"id":41118952,"options":[],"parent_id":41117008,"points":null,"story_id":41114839,"text":"> Back in the day Apple marketed macOS as a serious Unix system for scientists and engineers boasting about NASA\u2019s use of it.
They still jump through the necessary hoops to be certified as UNIX\u00ae with each macOS release:
* https://www.opengroup.org/openbrand/register/","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T07:12:41.000Z","created_at_i":1722409961,"id":41117008,"options":[],"parent_id":41116636,"points":null,"story_id":41114839,"text":"I\u2019m not sure.
Back in the day Apple marketed macOS as a serious Unix system for scientists and engineers boasting about NASA\u2019s use of it.
I think if Apple aspired to lockdown general purpose computing they would push the ipad pro range with more models and slowly kill off the Mac but they\u2019re not doing that.","title":null,"type":"comment","url":null},{"author":"robxorb","children":[],"created_at":"2024-07-31T08:17:22.000Z","created_at_i":1722413842,"id":41117295,"options":[],"parent_id":41116636,"points":null,"story_id":41114839,"text":"> 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.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T05:42:48.000Z","created_at_i":1722404568,"id":41116636,"options":[],"parent_id":41116544,"points":null,"story_id":41114839,"text":"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.","title":null,"type":"comment","url":null},{"author":"freep1zza","children":[{"author":"CydeWeys","children":[],"created_at":"2024-07-31T15:38:00.000Z","created_at_i":1722440280,"id":41120139,"options":[],"parent_id":41116644,"points":null,"story_id":41114839,"text":"I thought it was clear from my comment that I was suggesting Apple would do it better. Think of how useful something like apt, npm, or pip is, and then realize that MacOS has no in-house equivalent.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T05:43:58.000Z","created_at_i":1722404638,"id":41116644,"options":[],"parent_id":41116544,"points":null,"story_id":41114839,"text":"What a nonsensical conclusion. Homebrew existing is no reason for Apple to do replicate that trainwreck.","title":null,"type":"comment","url":null},{"author":"meindnoch","children":[{"author":"CydeWeys","children":[],"created_at":"2024-07-31T15:36:30.000Z","created_at_i":1722440190,"id":41120125,"options":[],"parent_id":41117891,"points":null,"story_id":41114839,"text":"It would be (or at least have) a command-line utility like rpm, npm, apt, or pacman. That's necessary for it to integrate well with various installation scripts. So you wouldn't have to use a UI at all, especially if it's bad.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T10:31:22.000Z","created_at_i":1722421882,"id":41117891,"options":[],"parent_id":41116544,"points":null,"story_id":41114839,"text":">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?","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T05:11:04.000Z","created_at_i":1722402664,"id":41116544,"options":[],"parent_id":41116275,"points":null,"story_id":41114839,"text":"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.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T03:51:57.000Z","created_at_i":1722397917,"id":41116275,"options":[],"parent_id":41114839,"points":null,"story_id":41114839,"text":"Apple should have been the one funding the audit.","title":null,"type":"comment","url":null},{"author":"sohrob","children":[],"created_at":"2024-07-31T04:05:27.000Z","created_at_i":1722398727,"id":41116336,"options":[],"parent_id":41114839,"points":null,"story_id":41114839,"text":"Great that there are people looking into this. I wonder if there would be similar findings were they to perform an audit on MacPorts or the Nix package manager.","title":null,"type":"comment","url":null},{"author":"eddyg","children":[{"author":"mikemcquaid","children":[],"created_at":"2024-07-31T05:56:05.000Z","created_at_i":1722405365,"id":41116692,"options":[],"parent_id":41116342,"points":null,"story_id":41114839,"text":"Workbrew wraps a vanilla, unmodified Homebrew on Macs running it under a \u2018workbrew\u2019 user for user privilege separation and better multi-user support.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T04:07:16.000Z","created_at_i":1722398836,"id":41116342,"options":[],"parent_id":41114839,"points":null,"story_id":41114839,"text":"Any idea how much impact the audit has and/or applies to Workbrew[0], their new business-oriented MDM-manageable package tool?
[0] https://workbrew.com/","title":null,"type":"comment","url":null},{"author":"koito17","children":[{"author":"justusw","children":[{"author":"wredue","children":[{"author":"woodruffw","children":[{"author":"KolenCh","children":[{"author":"woodruffw","children":[],"created_at":"2024-08-01T04:00:46.000Z","created_at_i":1722484846,"id":41126035,"options":[],"parent_id":41125839,"points":null,"story_id":41114839,"text":"I don\u2019t really understand what the problem you\u2019re referring to is: /usr/local is explicitly the non-OS software hierarchy, which is why Homebrew used it. When Apple Silicon came out, the prefix was changed as part of allowing native and Rosetta-driven Homebrew installations to co-exist. There\u2019s no nefarious reasoning behind it.
Edit: a thread with a bit of the history can be found here[1].
[1]: https://github.com/Homebrew/brew/issues/9177","title":null,"type":"comment","url":null}],"created_at":"2024-08-01T03:17:43.000Z","created_at_i":1722482263,"id":41125839,"options":[],"parent_id":41123513,"points":null,"story_id":41114839,"text":"But the problem is that /usr/local/bin is in the default PATH. They defended this discussion to take over until Apple silicon came and they \u201csilently\u201d fixed it avoiding admitting anything wrong in the beginning","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T21:12:16.000Z","created_at_i":1722460336,"id":41123513,"options":[],"parent_id":41122968,"points":null,"story_id":41114839,"text":"I don't think this is a fair characterization: on Intel, Homebrew uses `/usr/local`, which Apple has (historically) left empty as a location for non-OS managed software to be placed. To my understanding, this is an artifact of macOS's partial BSD ancestry. On ARM-based Macs, Homebrew uses `/opt` to avoid even this confusion (a trait it shares with other non-OS software but administrative-type software).
On the other hand, if Homebrew used `/usr` by default, this would be a fair characterization. But it doesn't.","title":null,"type":"comment","url":null},{"author":"RandomThoughts3","children":[],"created_at":"2024-08-01T08:31:45.000Z","created_at_i":1722501105,"id":41127200,"options":[],"parent_id":41122968,"points":null,"story_id":41114839,"text":"The really shameful behaviour at the time was that if you changed it (which you theorically could), some packages were so poorly written than they just broke and homebrew just warned you it was going to be this way instead of actually fixing the issue.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T20:13:02.000Z","created_at_i":1722456782,"id":41122968,"options":[],"parent_id":41116591,"points":null,"story_id":41114839,"text":"For the life of me, I will never understand how developers, of all people, see \u201cjust take ownership of system directories, which we will relentlessly pollute\u201d as acceptable behavior for homebrew.
Flabbergasted.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T05:25:31.000Z","created_at_i":1722403531,"id":41116591,"options":[],"parent_id":41116380,"points":null,"story_id":41114839,"text":"Funny that you mention it, I also went Homebrew -> MacPorts -> Nix.\nHomebrew had analytics and broke versions too often. MacPorts is way more stable, but some niche packages would not build well, and I had terminfo issues with tmux.
Nix allows me to override most of that, and I can share home manager config with my Debian workstation.","title":null,"type":"comment","url":null},{"author":"ninetyninenine","children":[{"author":"koito17","children":[{"author":"duijf","children":[],"created_at":"2024-07-31T08:40:13.000Z","created_at_i":1722415213,"id":41117389,"options":[],"parent_id":41116845,"points":null,"story_id":41114839,"text":"All the Nix commands that take an 'installable' can take GitHub URLs. For instance:
$ nix run github:NixOS/nixpkgs#hello\n Hello world!\n> 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\n error: flake 'github:NixOS/nixpkgs' does not provide attribute 'apps.aarch64-darwin.default', 'defaultApp.aarch64-darwin', 'packages.aarch64-darwin.default' or 'defaultPackage.aarch64-darwin'\n $ nix run github:kamadorueda/alejandra\nEDIT: 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.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T06:34:27.000Z","created_at_i":1722407667,"id":41116845,"options":[],"parent_id":41116607,"points":null,"story_id":41114839,"text":"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 Git repository (URL + commit hash, branch, or tag) and then make use of something malicious exported by the input. But to find out what the flake exposes at all, reading the flake (or its documentation) is pretty much necessary.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T05:32:43.000Z","created_at_i":1722403963,"id":41116607,"options":[],"parent_id":41116380,"points":null,"story_id":41114839,"text":"Nix also allows github.","title":null,"type":"comment","url":null},{"author":"tadfisher","children":[],"created_at":"2024-07-31T22:48:36.000Z","created_at_i":1722466116,"id":41124360,"options":[],"parent_id":41116380,"points":null,"story_id":41114839,"text":"Nix doesn't sandbox builds by default on macOS. You can try enabling it yourself with `sandbox = true` in nix.conf, but Things May Break.
The Nix sandbox is also not really meant as a security boundary; there's no effort put into preventing sandbox escapes, and lots of stuff leaks from the host into the sandbox environment. You really want something like gVisor or a full VM if you want to build untrusted packages.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T04:19:37.000Z","created_at_i":1722399577,"id":41116380,"options":[],"parent_id":41114839,"points":null,"story_id":41114839,"text":"Before moving to Nix, I was using MacPorts since Homebrew had some...eccentric behavior at the time (didn't work with multi-user setups, owned your /usr/local, lots of "works on my machine" problems from auto-updating and lack of version control, ...). One thing that has always felt insecure about Homebrew to me was the ability to use GitHub (not Git) URLs as ad-hoc packages. I wonder if that is how TOB-BREW-13 worked? That feature of Homebrew has always sounded like a security incident waiting to happen.
In any case, I'd be interested in seeing an audit of Nix on Mac OS. Especially if there is a flaw in how `nix develop` and related commands work.","title":null,"type":"comment","url":null},{"author":"efitz","children":[{"author":"zargon","children":[],"created_at":"2024-07-31T04:49:45.000Z","created_at_i":1722401385,"id":41116468,"options":[],"parent_id":41116442,"points":null,"story_id":41114839,"text":"https://brew.sh/2024/07/30/homebrew-security-audit/","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T04:40:07.000Z","created_at_i":1722400807,"id":41116442,"options":[],"parent_id":41114839,"points":null,"story_id":41114839,"text":"Were the reported issues all addressed by the Homebrew maintainers or are any still unmitigated?","title":null,"type":"comment","url":null},{"author":"razodactyl","children":[],"created_at":"2024-07-31T05:23:55.000Z","created_at_i":1722403435,"id":41116586,"options":[],"parent_id":41114839,"points":null,"story_id":41114839,"text":"The amount of value returned to the Apple ecosystem through brew is remarkable and while this post makes me even more in awe of the care that goes towards the community, I'm sad that one of the richest companies in the world isn't giving more back.","title":null,"type":"comment","url":null},{"author":"saagarjha","children":[{"author":"js2","children":[],"created_at":"2024-07-31T15:18:29.000Z","created_at_i":1722439109,"id":41119968,"options":[],"parent_id":41116721,"points":null,"story_id":41114839,"text":"The commit message could have answered that question, but instead, it only repeats what the diff already tells us: "Don't allow special characters in sandbox rule paths". It doesn't explain why, or what's special about the particular characters that it disallows. A better message would have said something like "Prevent certain characters in the path because otherwise ... We need to worry about these specific characters but not others because..."
Even if I wrote this code and knew what it did today, if I come across this it a year from now, I'm left scratching my head: why did I make this change?
A real world example of a good commit message:
https://github.com/git/git/commit/92fe7c7d42cc941ed70d6fce98...","title":null,"type":"comment","url":null},{"author":"frenchman99","children":[],"created_at":"2024-07-31T15:19:12.000Z","created_at_i":1722439152,"id":41119975,"options":[],"parent_id":41116721,"points":null,"story_id":41114839,"text":"Surprised too, if that is the fix. Wouldnt a whitelist be better than a blacklist?","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T06:04:09.000Z","created_at_i":1722405849,"id":41116721,"options":[],"parent_id":41114839,"points":null,"story_id":41114839,"text":"I peeked at the sandbox escape bug and its associated fix: https://github.com/Homebrew/brew/pull/17700/commits/f4e5e0c7.... Is this\u2026correct? Like, this is to prevent it from being interpolated into a sandbox profile and messing things up. How confident are we about this list of characters?","title":null,"type":"comment","url":null},{"author":"tucosan","children":[{"author":"j16sdiz","children":[],"created_at":"2024-07-31T13:18:34.000Z","created_at_i":1722431914,"id":41118941,"options":[],"parent_id":41118793,"points":null,"story_id":41114839,"text":"They noted that and just assume formulae are trustworthy.
> ... These avenues do not necessarily violate Homebrew\u2019s core security assumptions (which assume trustworthy formulae),...","title":null,"type":"comment","url":null},{"author":"woodruffw","children":[],"created_at":"2024-07-31T13:19:23.000Z","created_at_i":1722431963,"id":41118948,"options":[],"parent_id":41118793,"points":null,"story_id":41114839,"text":"I don\u2019t think the current Homebrew core formulae reviewers consider their team too small to sufficiently review all new incoming formula requests. But even if it was: this is one of the vagaries of packaging that\u2019s explicitly called out in the post: the boundary between first- and third-party execution is inherently murky, and there\u2019s IMO relatively more security \u201cvalue\u201d in determining where third-party execution can surprisingly happen than pointing out all of the unsurprising things that happen when you intentionally run third-party code.
(With that being said, I think packagaging ecosystems in general should be reviewed for those kinds of acceptance processes. But that would be closer to a \u201cred team\u201d style audit than a software audit, since it\u2019s about human processes.)","title":null,"type":"comment","url":null},{"author":"Bluecobra","children":[],"created_at":"2024-07-31T18:50:49.000Z","created_at_i":1722451849,"id":41122165,"options":[],"parent_id":41118793,"points":null,"story_id":41114839,"text":"Yeah, I just had a scare the other day with someone downloading a console emulator called "Cmder" which is a collection of a bunch of FOSS tools. It literally had ~1,000 files that could be malicious including powershell scripts, perl scripts, python scripts, shell scripts, DLLs, EXEs, etc. It turned out it was benign, but it's really scary that people just clone these Git repos and hope for the best.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T12:53:34.000Z","created_at_i":1722430414,"id":41118793,"options":[],"parent_id":41114839,"points":null,"story_id":41114839,"text":"The main attack vector IMHO is the simple fact that one can sneak in new packages with malicious intent by simply contributing a new formula. \nThe team of maintainers is too small to audit all of the newly contributed formulae.\nI'm suprised that this attack vector wasn't part of the audit.","title":null,"type":"comment","url":null},{"author":"hk__2","children":[{"author":"woodruffw","children":[{"author":"hk__2","children":[],"created_at":"2024-07-31T14:22:42.000Z","created_at_i":1722435762,"id":41119425,"options":[],"parent_id":41119263,"points":null,"story_id":41114839,"text":"Thank you!","title":null,"type":"comment","url":null},{"author":"Ylpertnodi","children":[],"created_at":"2024-08-01T13:49:18.000Z","created_at_i":1722520158,"id":41129033,"options":[],"parent_id":41119263,"points":null,"story_id":41114839,"text":"Why, oh why....are TL;DR's at the end of articles/ comments?","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T14:02:09.000Z","created_at_i":1722434529,"id":41119263,"options":[],"parent_id":41119130,"points":null,"story_id":41114839,"text":"I wasn\u2019t a maintainer at the time I did the audit :-). I\u2019ve been a non-maintaining \u201cmember\u201d of the project for a long time, which is the pseudo-emeritus position we give to previous maintainers who want to continue participating in internal conversations and governance. I was then offered membership again, months after the audit, due to some unrelated work on Homebrew that didn\u2019t exist and wasn\u2019t planned before the audit was planned.
This was all disclosed as part of a conflict-of-interest disclosure I did, both with my company and with the Homebrew maintainers, but I agree that the blog post could also say that explicitly. I\u2019ll try and get it added today.
TL;DR: I was not a maintainer at the time the audit was performed, but I was previously (years before) and am currently a maintainer. The audit was performed by myself and my colleagues in our professional capacities.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T13:46:01.000Z","created_at_i":1722433561,"id":41119130,"options":[],"parent_id":41114839,"points":null,"story_id":41114839,"text":"I\u2019m a bit puzzled by the wording of this blog post, because it says you\u2019ve worked with Homebrew to do this audit, but your name sounds familiar to me, and indeed if we check Homebrew\u2019s README [1]:
> Homebrew's maintainers are [\u2026long list of names\u2026] William Woodruff [\u2026]
[1]: https://github.com/Homebrew/brew
Is there any reason this is not mentioned in the blog post? I don\u2019t think it would make a difference, but just to clarify things.","title":null,"type":"comment","url":null},{"author":"mootoday","children":[{"author":"charlie0","children":[{"author":"mootoday","children":[{"author":"replete","children":[{"author":"mootoday","children":[],"created_at":"2024-08-02T21:50:43.000Z","created_at_i":1722635443,"id":41142971,"options":[],"parent_id":41121617,"points":null,"story_id":41114839,"text":"I had done the same before I learned about Devbox.
It's very lightweight and gets very powerful combined with `git worktree` to work on multiple branches in parallel, each with its own database instance.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T18:06:43.000Z","created_at_i":1722449203,"id":41121617,"options":[],"parent_id":41119409,"points":null,"story_id":41114839,"text":"Oh this looks pretty cool. I started using Docker a while ago for dev projects to avoid package/language version hell, but sometimes its a bit overkill","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T14:21:29.000Z","created_at_i":1722435689,"id":41119409,"options":[],"parent_id":41119316,"points":null,"story_id":41114839,"text":"For me, the key push towards using it as a Homebrew replacement was the fact that I already used Devbox to create isolated dev environments for individual projects I work on.
Now I have one tool to manage all dependencies.
Other than that, it likely comes down to personal preference.
One neat thing is `devbox global push/pull <repo>` to persist my config in a repo.","title":null,"type":"comment","url":null},{"author":"KolenCh","children":[],"created_at":"2024-08-01T03:37:23.000Z","created_at_i":1722483443,"id":41125925,"options":[],"parent_id":41119316,"points":null,"story_id":41114839,"text":"You might say devbox gives nix a brew-like interface and ergonomic.
More accurately, when you use a package manager, you use the \u201cecosystem\u201d including the package index and pre-built binaries, and the cli. There aren\u2019t many alternatives to homebrew as an ecosystem, especially including cask. Macports isn\u2019t a homebrew replacement in the sense that it doesn\u2019t have \u201ccask\u201d. Nix has something similar, although not as many packages. This makes nix probably the only viable alternative to homebrew with cask.
But nix is very hard to onboard. Devbox just makes it much easier to start using in say the first 30 min.","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T14:10:32.000Z","created_at_i":1722435032,"id":41119316,"options":[],"parent_id":41119302,"points":null,"story_id":41114839,"text":"As someone unfamiliar with Nix, how is this better than Homebrew?","title":null,"type":"comment","url":null}],"created_at":"2024-07-31T14:08:30.000Z","created_at_i":1722434910,"id":41119302,"options":[],"parent_id":41114839,"points":null,"story_id":41114839,"text":"There's an interesting alternative to Homebrew: Devbox
It abstracts Nix in a way you don't have to know or learn anything about the Nix language.
I wrote a few words on how I use it instead of Homebrew [1].
[1] https://mootoday.com/blog/i-replaced-homebrew-with-devbox
https://mootoday.com/blog/i-replaced-homebrew-with-devbox","title":null,"type":"comment","url":null},{"author":"alberth","children":[],"created_at":"2024-07-31T15:52:05.000Z","created_at_i":1722441125,"id":41120272,"options":[],"parent_id":41114839,"points":null,"story_id":41114839,"text":"
> Since 2012, Trail of Bits has helped secure some of the world\u2019s most targeted organizations and products. We combine high-\u00adend security research with a real\u00ad world attacker mentality to reduce risk and fortify code.\nFor some very loose definition of "recently." It's been a team of multiple maintainers, spread across the world, for well over a decade at this point.","title":null,"type":"comment","url":null}],"created_at":"2024-08-01T15:22:15.000Z","created_at_i":1722525735,"id":41130103,"options":[],"parent_id":41129942,"points":null,"story_id":41114839,"text":"You realise flatpak had been around almost 20 years and has a HUGE community and commercial vendors behind it?
Brew was until recently just one guy in SF.
But let's agree to disagree.","title":null,"type":"comment","url":null}],"created_at":"2024-08-01T15:08:25.000Z","created_at_i":1722524905,"id":41129942,"options":[],"parent_id":41127985,"points":null,"story_id":41114839,"text":"> They have far more manpower, experience and connections than brew.
And Homebrew\u2019s maintainer team, in turn, has far more of all that than the average Flatpak app developer has, which your earlier comment suggested as an alternative to Homebrew.
> I see it as a red flag in projects since it usually indicates lack of first class Linux support.
In most distros, upstream projects have very little say in whether or not the distro is going to include them.\nIt\u2019s the distro maintainers who make that decision, and it depends on many different factors, some of them outside of the upstream project\u2019s control, but none of them related to \u201efirst class Linux support.\u201c
For example: is the upstream license an acceptable fit for the distro? How many dependencies does it have, and are those already available as packages in that distro? Does it make technical assumptions that clash with the distro\u2019s assumptions? Has anyone stepped up and authored the package yet? And so on.
Never have I seen \u201clack of first class Linux support\u201d as a scale-tipping argument against including a particular package in a distro.","title":null,"type":"comment","url":null}],"created_at":"2024-08-01T11:14:46.000Z","created_at_i":1722510886,"id":41127985,"options":[],"parent_id":41127744,"points":null,"story_id":41114839,"text":"Core system package managers (apt etc) handle security issues quickly and in collaboration with security researchers and authorities. They have far more manpower, experience and connections than brew.
Bleeding edge is handled by rolling package managers, and these often build automatically from source as soon as a commit is tagged.
I don't see a clear reason to use brew, which does everything a little bit worse. In fact, I see it as a red flag in projects since it usually indicates lack of first class Linux support.","title":null,"type":"comment","url":null}],"created_at":"2024-08-01T10:32:32.000Z","created_at_i":1722508352,"id":41127744,"options":[],"parent_id":41127609,"points":null,"story_id":41114839,"text":"> we got things like flatpak, appimage directly from developers
Some people prefer timely, high-quality, well-tested bugfixes and security updates for the underlying low-level dependencies of an app.
An upstream app developer is much less likely to provide an updated flatpak mere minutes after e.g. a critical OpenSSH security fix comes out of embargo. Distro maintainers on the other hand, such as the Homebrew core maintainers, can do that. They also have security audits, see TFA, and established processes. Nothing wrong with that at all.
> and nix
That just comes down to personal preference. Some people like Nix due to the amazing level of isolation it provides, and that\u2019s perfectly fine. Some prefer Homebrew instead because it\u2019s easy to use and respects the FHS.
All the things we\u2019ve discussed so far are highly subjective, come down to personal preference, and say absolutely nothing about how skilled a user is.","title":null,"type":"comment","url":null}],"created_at":"2024-08-01T10:08:05.000Z","created_at_i":1722506885,"id":41127609,"options":[],"parent_id":41126814,"points":null,"story_id":41114839,"text":"I don't see that. Brew on Linux is a copy of dito on osx which itself was inspired by Linux package managers.
Instead of using the real deal, people generally suggest Brew because that's what they are familiar with from osx.
If you need bleeding edge of something (and don't want to build from source) we got things like flatpak, appimage directly from developers or AUR and nix and other stuff.
I'm yet to find someone proposing brew over the rest because of some new package genuinely being available only on brew only.","title":null,"type":"comment","url":null}],"created_at":"2024-08-01T07:06:02.000Z","created_at_i":1722495962,"id":41126814,"options":[],"parent_id":41126722,"points":null,"story_id":41114839,"text":"Even though Homebrew isn\u2019t meant as a replacement for the system package manager, there are legitimate use cases.
For example, if you\u2019re on Debian but need a newer version of just one tool, it makes absolute sense to install Homebrew alongside. It\u2019s designed to play well with the system package manager, uses its own separate prefix so it won\u2019t cause shared libs confusion, and only shadows the packages you install with it. Nothing wrong with that inherently, and certainly not a sign of limited knowledge.","title":null,"type":"comment","url":null}],"created_at":"2024-08-01T06:48:38.000Z","created_at_i":1722494918,"id":41126722,"options":[],"parent_id":41114839,"points":null,"story_id":41114839,"text":"Kinda off topic, but when I see a project or an article use brew on Linux instead of their native package manager or something like flatpak I generally assume the author has very limited knowledge about Linux and I can ignore this project/article.","title":null,"type":"comment","url":null},{"author":"lrvick","children":[],"created_at":"2024-08-01T17:14:29.000Z","created_at_i":1722532469,"id":41131320,"options":[],"parent_id":41114839,"points":null,"story_id":41114839,"text":"I am a bit surprised this did not highlight major low skill attack surface in Homebrew as compared to almost all Linux and *BSD package managers: Supply chain integrity.
Homebrew maintainers mostly do not sign commits/packages, do not sign reviews/merges, do not verify author/reviewer sigs at compile time, do not reproduce builds in separately controlled CI, do not enforce hardware 2FA on Github.
Every user of brew is only as secure as whichever of hundreds of brew maintainers has the worst opsec today.
Also since dependabot automatically makes commits, you could get a malicious commit into an external project you control, wait for dependabot to make a commit to homebrew to upgrade it, then merge it yourself (as becoming a homebrew maintainer has almost no vetting, just fix a few easy bugs)
You could also just take over one of the expired email domains of a maintainer and send a password reset email to yourself and take over an account of someone on vacation or hiatus.
Can likely get thousands of companies compromised before anyone notices.
Honestly I would never allow Brew on any company machines I have authority over. It is giving hundreds of randos, (and anyone that takes advantage of their poor opsec) the ability to execute any code on user systems.
Major Linux package managers do not go nearly far enough with things like review signing, but most at -least- do author-level package signing, human review, and independent reproduction for most packages.
Given how many high value targets like corporate sysadmins allow brew on their computers, Brew is on track to overshadow Crowdstrike any day now for most harm caused by insufficient supply chain management.","title":null,"type":"comment","url":null},{"author":"amai","children":[],"created_at":"2024-08-03T15:02:15.000Z","created_at_i":1722697335,"id":41146959,"options":[],"parent_id":41114839,"points":null,"story_id":41114839,"text":"Nowadays even Windows has a package manager (https://en.wikipedia.org/wiki/Windows_Package_Manager). Why does Apple/Mac OS X not develop something similar?","title":null,"type":"comment","url":null}],"created_at":"2024-07-30T22:39:21.000Z","created_at_i":1722379161,"id":41114839,"options":[],"parent_id":null,"points":845,"story_id":41114839,"text":null,"title":"Our audit of Homebrew","type":"story","url":"https://blog.trailofbits.com/2024/07/30/our-audit-of-homebrew/"}