[HN Gopher] Brew Is a Bad Neighbor
___________________________________________________________________
Brew Is a Bad Neighbor
Author : zdw
Score : 118 points
Date : 2022-09-03 18:06 UTC (4 hours ago)
(HTM) web link (gist.github.com)
(TXT) w3m dump (gist.github.com)
| rvieira wrote:
| I've always used brew, but sometime in the last few of years
| (Mojave?) I was plagued with these problems when installing
| different versions of Python simultaneously. Either brew broke
| Python installs, broke things like asdf, couldn't build Python
| from scratch, virtualenvs broke. Hair-pulling stuff.
|
| I decided to use MacPorts just for Python and switching Python
| versions worked perfectly. Eventually I migrated most of the brew
| stuff to MacPorts.
|
| I'm not saying one is superior to another, it's just that in my
| very personal experience and uses, I don't find anything in brew
| that MacPorts doesn't give me.
| rcarmo wrote:
| I use brew with pyenv and never looked back.
| NegativeLatency wrote:
| asdf has been nice for managing programming language versions
| b3morales wrote:
| It's been a while since I've looked into it, but last I knew
| MacPorts was much more aggressive than brew about just not
| sharing dependencies between packages, to avoid this kind of
| thing. In effect, trading disk space against fragility.
| blindseer wrote:
| I did something like this a long time ago, and installing clang,
| gcc or ghc took FOREVER. I think I spent a whole day trying to
| install qmk just because various things required compiling.
| Granted my computer is old (MBP 2012).
|
| I'm not sure it is worth the trouble. Can someone explain to me
| why I shouldn't just "trust" that the homebrew developers and
| maintainers know what they are doing and just have it installed
| in the default location? I get the theoretically I'm more
| susceptible to accidentally running a script that requires sudo,
| but are they any other downsides?
| monkellipse wrote:
| Unexpected overwrites of system tools are the problem I've
| faced. Not sure how common that really is but once can be
| enough to leave a bad taste!
| kayodelycaon wrote:
| Is homebrew actually overwriting system files or is your
| shell's path set up so homebrew's versions take precedence?
| oneplane wrote:
| On SIP-enabled systems that can't really be done anymore. But
| on Linux (LinuxBrew) that can definitely happen. The brew
| link system is supposed to help with that, but there are no
| guarantees.
| mdaniel wrote:
| As someone who runs Linuxbrew, I can assure you it does no
| such thing unless someone is misguided enough to have
| "NOPASSWD: ALL" in sudoers. Filesystem permissions didn't
| magically stop existing because Linuxbrew showed up, and it
| does not use any setuid binaries
| oneplane wrote:
| Keep in mind that /usr/local might contain user-created
| files and directories and might not have their
| permissions set strictly like other system directories.
| If you create something in there and then run brew, your
| normal user permissions are enough to silently overwrite
| things.
|
| That said, brew is (usually) smart enough to notice if a
| file already exists, and it will simply leave it be and
| prompt the user. The problem at that point is that the
| force link command works without sudo and will happily
| overwrite anything with a symlink to the Cellar-installed
| version.
| leokennis wrote:
| This guide is written like the homebrew people force you at
| gunpoint to use it.
|
| They don't.
|
| If you don't like homebrew's defaults and want to write a guide
| on how to change that, there's no need to make it sound this
| aggressive.
|
| For most people homebrew is an easy to use solution to install
| software and its dependencies and keep them up to date.
| manmal wrote:
| This kind of behavior is an extension of the problematic
| entitlement towards OSS imo. ,,Brew is a bad neighbor" is not a
| fair description for a free (!) tool that made millions of dev
| lives easier.
| tomxor wrote:
| > not a fair description for a free (!) tool that made
| millions of dev lives easier.
|
| I think part of the problem is for those stuck with Macs, for
| whatever reason - brew doesn't merely make their life as a
| dev easier, it makes being a dev possible - which only
| worsens the sense of entitlement.
| Razengan wrote:
| So many assumptions in one entitled comment.
| robertlagrant wrote:
| I can't see anything entitled in the comment. What do you
| mean?
| bardworx wrote:
| Are you implying you cannot be a dev w/o brew?
| tomxor wrote:
| No. I'm saying on _MacOS_ , for certain types of
| development where you need BSD or GNU userland tools not
| included in _MacOS_ - a package manager for installing
| such tools like brew is required to make life sane and
| workable.
| bardworx wrote:
| > brew doesn't merely make their life as a dev easier, it
| makes being a dev possible
|
| Your comment made it seemed as if there was no way to
| develop on a Mac before homebrew, which I think is silly.
|
| It's just a tool. Makes your life easier but that's it.
| kweingar wrote:
| Pointing out the flaws in open source software is totally
| fair, especially when the software is popular enough to have
| a gravitational pull on the rest of the ecosystem.
|
| Of course, you need to be mindful not to be a jerk to the
| developers and maintainers, but that is different from
| criticizing the software.
|
| If criticism of open source software was "problematic
| entitlement", then I guess we'd have to swallow our tongues
| when Linux, Android, Chromium, Firefox, etc. make poor
| decisions. After all, they've helped billions of users, so
| who are we to question them?
| acdha wrote:
| This article is aggressive but does it really point out a
| flaw? It alleged a few problems but didn't substantiate
| anything (doing so would likely have helped the author
| learn why the security point is mostly theater) and the
| bulk of it was describing how it was more work to use an
| unsupported configuration but still relatively easy because
| the Homebrew authors documented how to do so.
|
| That seems like an appropriate title would be "TIL: how to
| install Homebrew in a custom path" rather than the
| hyperbolic one he picked.
| manmal wrote:
| > you need to be mindful not to be a jerk to the developers
| and maintainers
|
| And you don't think the article ticks that box?
| jchw wrote:
| It's not written as if Homebrew developers are forcing you to
| use it. It's written from the perspective of someone who
| doesn't really want to use Homebrew but still does so as a
| result of some decision calculus but finds it frustrating to
| use. If you find the tone to be too aggressive or unfriendly,
| that's fine. But also, in the same token, I don't think it's
| fair to invoke the "you don't have to use it" argument for
| fairly reasonable frustration. It's also not obligatory that
| anyone take someone's rant personally, after all.
| acdha wrote:
| That's a very charitable reason: this post is long on
| unsupported allegations starting with the title and boils
| down to the author not understanding security as well as he
| thinks and claiming it's Homebrew's fault that something
| unsupported requires more work.
| jchw wrote:
| Well, I find it pretty frustrating when software on my
| machine breaks due to namespace pollution that happened
| automatically and without warning. Some MSys distributions
| do similar things on Windows, and I find it no less
| agitating (To be fair, at least Homebrew _doesn 't_
| generally override e.g. system utilities with GNU
| utilities, and is somewhat careful about it, but it
| nonetheless does generally require itself to be on $PATH
| iirc. Still, my build processes regularly pick up things
| like Homebrew OpenSSL completely unintentionally...)
|
| Ignoring the security issue for a moment, though, I think
| it is genuinely quite irritating that Homebrew doesn't
| support installing in a more self-contained manner. I'm not
| saying Homebrew developers did anything wrong to me
| personally or that they are obligated to work on the
| problem, but the other edge of that sword is that I don't
| have to like it either. It can be done, as shown, but it is
| pretty intentional about not supporting this workflow. I
| think that's a bummer.
|
| (P.S.: I honestly didn't really grasp exactly what they
| were complaining about, but if they are trying to enforce a
| setup where the only binaries in the default shell $PATH
| are in directories that are not world-writable, that really
| does seem like a totally valid security mitigation.)
| acdha wrote:
| I mean, yes, namespace pollution is a problem but
| Homebrew goes to a fair amount of effort to avoid that. I
| have to add things like OpenSSL, etc. to my direnv for
| projects where I want to use those instead of the system
| versions and they support using /opt/homebrew on older
| systems, too, for people who don't mind skipping bottle
| builds.
|
| > if they are trying to enforce a setup where the only
| binaries in the default shell $PATH are in directories
| that are not world-writable, that really does seem like a
| totally valid security mitigation.
|
| Think about what threats you're concerned about. Homebrew
| installs are writable only by the user who installed them
| and members of the admin group. If you're not on a system
| with other users, this doesn't matter: someone who can
| run code or drop files into arbitrary locations as you
| can already do whatever they want (e.g. maybe you lock
| down /usr/local but do they even care as they drop
| something into your .profile or LaunchDaemons?). That's
| why Apple has worked on the various sandboxing methods
| because this model is too brittle.
|
| If you are on a multiuser system, this could be a way to
| move sideways but it comes down to the question of how
| likely it is that an attacker would compromise the admin
| user who installed Homebrew without getting the ability
| to use their administrative privileges. That's certainly
| possible but it seems relatively uncommon and that's part
| of why I think it's a huge stretch to go from "there's an
| obscure edge case I want to hit" to "These people who've
| given me thousands of hours of their work for free are
| bad neighbors".
| gumby wrote:
| In fact the ranter's "solution" works only because the homebrew
| team go out of their way to make sure it will work -- and even
| document it.
| RodgerTheGreat wrote:
| From the title, I expected a mention of brew's telemetry (which
| can be opted out of, but are broadcast by default):
| https://github.com/Homebrew/brew/blob/master/docs/Analytics....
| theonemind wrote:
| I saw a comment that stuck with me once: "Ruby people don't get
| root", referring to an unwillingness to trust Ruby tools or the
| ruby community as it got closer to his system.
|
| This rule works surprisingly well.
| treeman79 wrote:
| Its good Practice to never use root for any ruby application.
|
| RVM or rbenv with Gemfile do a great job in giving you any
| version you need and keeping the system clean.
|
| Way back in the day you basically had to reverse engineer each
| developers environment to let another person use it. Now it's
| common to grab any semi decent project and be up in running in
| a couple minutes.
|
| Brew usually takes care of any system level stuff. Nokogiri,
| image magic, etc.
| NegativeLatency wrote:
| even just 'gem install PACKAGE ---user' will get you pretty
| far
| skunkworker wrote:
| I don't think I've touched system ruby in years. With RVM
| everything is just installed into my home ~/.rvm folder and
| keeps it tidy.
| marcosdumay wrote:
| I try not to use anything in PHP; Python and Ruby are isolated
| as well as possible (optimally, not having access to my homedir
| and definitively not getting "installed"); Bash will get
| thoroughly reviewed for data validation red flags; and I will
| avoid anything that imposes a code convention and is written in
| Go.
|
| Now I am surprised that I don't have any general rule for C and
| Java.
| KerrAvon wrote:
| First rule of Unix security is that no tool should have
| unnecessary root. Ruby isn't special in this regard, and
| Homebrew doesn't particularly seem to be problematic. I've had
| a lot bigger problems with Python-based tooling, tbh, but I
| imagine it's the developers and not the language.
| monkellipse wrote:
| I really got fed up with Homebrew after something got clobbered,
| this looks like a nice simple solution to that! Thanks! Curious
| to know how effective it is in practice. I resorted to abusing
| Docker for nifty command line tricks on the Mac but it sure is a
| heavy solution and some things really are better on the metal!
| pcr910303 wrote:
| Or instead of all this, try MacPorts[0], which in my experience
| has 99% of what you need.
|
| The biggest drawbacks are less support from quite niche packages
| (the ones that sets up its own homebrew tap), and a bit slower
| updates. But then I found it bearable much more than homebrew's
| downsides.
|
| [0]: https://macports.org
| oneplane wrote:
| The Gist's contents apply to macports too, but instead of only
| clobbering /usr/local or /opt it does both.
| pcr910303 wrote:
| Hmm... can you elaborate? AFAIK MacPorts never touches
| outside /opt/local in it's default configuration, and it
| requires sudo, so it doesn't have the finicky permission
| problems that homebrew had on multiuser systems.
| oneplane wrote:
| Back in the PowerPC days (when I used Fink and later
| switched to MacPorts) it often didn't integrate with any
| expected paths that were used when building software. This
| meant that you either have to symlink things in yourself or
| have a persistent directory symlink to make sure any ports
| you installed could be picked up by other software. Similar
| problems happened the other way around if MacPorts was
| first in your path as your includes couldn't find the
| system files anymore since it was looking for files
| relative to the files you found in /opt/local.
|
| Regarding the permission problem: have never had any issue,
| but that's probably because I don't mix multiple users and
| developer tools.
| yunohn wrote:
| You made an unsupported assertion about Macports, based
| on your experience from "the PowerPC days"?
|
| I don't even use Macports, but that's just plain unfair.
| oneplane wrote:
| I described the origin of the current situation.
| Considering you are not a consumer of MacPorts there is
| no point of reference for you, so you would not know how
| the current inadequacies came to be.
|
| Trying to judge the fairness of a technical aspect of a
| piece of software as a non-user seems rather pointless,
| don't you agree?
| b3morales wrote:
| It's also not _too_ much trouble (albeit a little annoying
| mostly because of TCL) but to have local port definitions for
| anything you need that isn 't in the tree:
| https://guide.macports.org/#development.local-repositories
| kitsunesoba wrote:
| I might try MacPorts again next time I do a fresh OS install.
|
| Last time I used it was back in the mid-late 2000s, before my
| technical capabilities were decent (could only barely write
| code and was basically clueless about the GNU toolchain and the
| like) and at that point, MacPorts packages were frequently
| broken and would sometimes remain that way for long stretches
| of time, with the only fixes being manually applied local
| patches (if they existed at all). It was very frustrating, and
| so when Homebrew came around and packages generally "just
| worked" I was an instant convert. I wouldn't be surprised if a
| lot of other people who were newbies during that time span have
| similar stories.
| kergonath wrote:
| > MacPorts packages were frequently broken and would
| sometimes remain that way for long stretches of time, with
| the only fixes being manually applied local patches (if they
| existed at all)
|
| That was my experience as well a couple of years ago, with
| some quite painful OS transitions. Still, I've been using it
| for I think a decade now, and I cannot remember any problem
| in the last 4 years or so. It does not have everything as
| Homebrew is the cool kid and cool devs do not care about
| anything else, but it is solid. And last time I looked it had
| a much more sensible way of working than brew and a better
| security model, even if it leads to some duplication in the
| installed packages.
| icedchai wrote:
| I prefer MacPorts, which uses /opt/local by default. /usr/local
| is for things I build myself / install manually.
| oneplane wrote:
| Brew uses /opt by default as well (but it wasn't always the
| case, and it used to symlink into /usr/local too while keeping
| the actual files in the Cellar).
| icedchai wrote:
| Good to know. Last time I used brew was on an Intel Mac.
| sashk wrote:
| /opt by default is for M1 and later based Macs. intel based
| Macs still use /usr/local.
| mdaniel wrote:
| Heh, you and I posted about the same time, but it seems
| that's actually only true for arm64: https://github.com/Homeb
| rew/install/blob/master/install.sh#L...
| mdaniel wrote:
| I was going to say that recent installs have switched to
| /opt/Homebrew, but while digging up supporting evidence I
| noticed that they bizarrely only do that for arm64 installs:
| https://github.com/Homebrew/install/blob/master/install.sh#L...
| duskwuff wrote:
| Changing the install prefix for a project like Homebrew is
| hard, because directory names frequently get embedded in
| executables and configuration files. The ARM migration was a
| convenient time to make the switchover, because everything
| had to be rebuilt anyway.
| spaceywilly wrote:
| >homebrew (grudgingly?) supports being installed in a non-
| standard folder. They just don't suggest it to you up front. It's
| tucked away in the detailed installation page under "Alternative
| Installs"
|
| Oh good, another user of an open source project expecting the
| devs to support their special setup, while (presumably) not
| contributing anything back.
| guimplen wrote:
| Your comment would be relevant if the guy written something to
| the devs. He has a sacred right to rant on his own page as he
| likes.
| spaceywilly wrote:
| But his rant could've easily been a pull request in the Brew
| repo. Would've taken just as much (maybe even less) than what
| he did to come up with his own solution. Let's say he added a
| --sandbox option to the home brew install script that did all
| this automatically. Now it benefits everyone using homebrew.
|
| The whole tone of the article is pretty hostile and childish,
| which is a toxic attitude in my opinion. Better to be
| cooperative and help out the community.
| hk1337 wrote:
| yeah, I have had Homebrew installed under ~/.brew for quite
| awhile. I don't really like that idea of it out in /usr/local for
| one but it also helps with permissions as Apple "secures" the OS
| with each update.
| zenlf wrote:
| I clicked on this and expected something really bad about brew.
| It turns out just the default setting doesn't satisfy the
| writer's use case. The energy and attitude of this article really
| sticks me as odd especially considering Brew is free to use and
| not some sort of default package manager that comes with your
| macOS.
|
| If you want to write a guide to do something, great. You
| contribute to the collective knowledge base, but there is
| absolutely no need having this combative attitude towards
| somebody are doing the same.
| lapcat wrote:
| Serious question: Why do Hacker News commenters constantly
| "tone police" articles that are not written for Hacker News?
|
| I don't know what criticisms of an article's tone contribute to
| the collective knowledge base.
|
| If an article author did not show the respect toward something
| that you think something deserves, you're entitled to your
| personal feelings, but are we here just to say "I like this" or
| "I don't like that"? It always seems like HN revels in
| diversions, irrelevancies, and nitpicking, which typically
| distracts from the main points of an article. As proof of this,
| the OP is currently the top voted comment for the article.
| Decker87 wrote:
| It's what gets the clicks.
| iepathos wrote:
| Yeah, I was surprised the author had an issue with using /opt
| since that's the expected location in *nix for the installation
| of add-on application software packages. Maybe he's running a
| multi-user machine and really wants brew in his home directory
| for that reason.
| nerdponx wrote:
| If anything, Brew going in /opt makes a whole lot more sense
| than the old default of /usr/local. Supporting individual
| per-user installs in the home directory would be really nice
| of course, but I guess that's just not something they intend
| to support (it's offered on Linux on the "you are on your
| own, good luck" basis).
| craigching wrote:
| Agreed. When brew installed in /usr/local I ranted much
| like this post. I'm much happier with brew since the move
| to /opt.
| nerdponx wrote:
| I think it's "cool" in some circle to hate on Homebrew. It's
| not my favorite piece of software (I prefer MacPorts), but it's
| improved a lot over the years and its existence does a lot of
| good for a hell of a lot of people.
| jxi wrote:
| Aloha wrote:
| why should I care if its in /usr/local or /opt I thought that
| those are the standard place to put third party unix software?
| jlg23 wrote:
| From the article:
|
| > Since it was installed in your home directory - no need to
| change any permissions. No sudo required.
|
| Although I'd argue sudo vs no-sudo-but-in-your-home-directory
| is the same difference. Local exploits are trivial to find,
| plentiful and still not even necessary: 99% of the time some
| sloppy local configuration can be exploited to gain root
| access. I've switched to "let's try a few minutes on our own
| before asking the admin" a long time ago - and haven't required
| an admin's help ever since..
| DominoTree wrote:
| FWIW, using the `--force-bottle` flag will force homebrew to
| install its existing pre-built packages into a non-standard path
| you've configured instead of compiling them from scratch, and
| I've _never_ run into an issue with a package doing it that way.
| racl101 wrote:
| I've never hated a package manager more.
| FullyFunctional wrote:
| My worry with brew and literally any software installed from
| "random" sources is that I don't want to trust it, but it runs
| with all my credentials and can do just about anything on my
| behalf. When using, say, macOS or Ubuntu, I have made the
| deliberate decision to trust the vendor to not be subversive, but
| as soon as you bring in outside sources you expose yourself. This
| isn't an academic concern, Log4J and the ongoing phishing attacks
| on PyPI are good reminders.
|
| Apple at least seems to be taking it seriously and has started
| requiring explicit authorization to access various locations
| (like Photos), but treats the shell as single security domain, so
| it's (AFAICT) a global setting for brew installed binaries. For
| Linux I don't know of anything similar.
|
| _Obviously_ there are many things one can do but it needs to be
| the default and it needs to be not so inconvenient that people
| just turns it off (hello Microsoft Vista 's UAC).
|
| What are the solutions here?
| pxc wrote:
| What the OP describes is how I use Homebrew on macOS: non-
| standard prefix, not on the PATH. The other thing I do is use it
| exclusively for 'Casks' (pre-built .app bundles distributed as
| .dmg or .pkg).
|
| If you do this, you can use any combination of Nix, pkgsrc, and
| MacPorts for your traditional Unix-y package needs.
| OrderlyTiamat wrote:
| Is there a guide like this for anaconda? I'd really prefer to
| have it "shoved into its own little corner " without it touching
| my bashrc and the like. I'm currently isntalling it with nix-env,
| which is great, but nix is a tad overkill, and if/when I'm done
| experimenting with nix, I'd like to have a way to use conda for
| projects that require it, but have it otherwise leave me the hell
| alone.
| OrderlyTiamat wrote:
| Is there a guide like this for anaconda? I'd really prefer to
| have it "shoved into its own little corner " without it touching
| my bashrc and the like. I'm currently isntalling it with nix-env,
| which is great, but nix is a tad overkill, and if/when I'm done
| experimenting with nix I'll still probably require conda.
| hosh wrote:
| I abandoned brew for asdf.
|
| And then a new coworker introduced nix. The kind of issues I get
| with brew just isn't there when using nix.
|
| I still don't know how to write nix expressions, but I don't
| really see any reason to go back to using brew.
| fredoliveira wrote:
| It doesn't sound to me like you were using brew as brew was
| intended to be used, if you are able to replace it with asdf.
| Asdf is extensible, but it doesn't have any kind of way to
| replace casks, or system package management. It is fine for
| managing js/ruby/etc environments, but that's it.
| hosh wrote:
| You missed the part where I said I switched to nix.
|
| I don't care about casks or system package management. My
| use-case requires specific versions of tools, maybe GNU
| coreutils, and limped along with glibc or openssl, and that's
| about it. What asdf did not provide, Docker containers did.
| Until nix.
| fossuser wrote:
| I'm 0 for 2 so far trying to get stuff built with nix working
| on an M1 machine (for open source projects that use it). Maybe
| I'm doing something wrong, but my personal experience with it
| so far has been bad.
| hosh wrote:
| Same here, though my coworker got it working on an M1. I use
| a cloud Linux box and nix has been working great there.
| ravenstine wrote:
| asdf is an awesome tool, but isn't it isn't a replacement for
| Homebrew. It is in the sense of installing and managing
| versions of programming languages, but Homebrew is more than
| that. You can't run `asdf install vs-code`, for example, unless
| you overload its functionality with a custom plugin.
| hosh wrote:
| I think you missed the part about nix.
| ohCh6zos wrote:
| No worries if you don't know, but how hard is it to get Nix
| setup on macOS?
| mdaniel wrote:
| A recent tooling announcement
| <https://news.ycombinator.com/item?id=32600821> that uses nix
| under the hood finally got me to look further into it and
| while I know this isn't exactly what you asked, looking at
| their uninstall instructions <https://nixos.org/manual/nix/st
| able/installation/installing-...> leads me to believe ...
| it's probably not a great fit. I recognize that I'm probably
| more skeptical than most about "curl into bash" but if one
| needs to run that many sudo commands plus whatever "dscl"
| does in order to change your mind, that tool is not for me
| teg4n_ wrote:
| What does asdf have to do with package management? It's only a
| version manager as far as I know and one of the suggested ways
| to install asdf is to install it with brew
| hosh wrote:
| That's a pretty narrow idea of a "package manager" if you
| don't consider a version manager to also be a kind of package
| manager.
|
| It's more accurate to say that asdf does not comprehensively
| provide as many software that brew provides, and asdf does
| not manage library dependencies. What asdf does that brew is
| very crappy at is being able to run things in isolation from
| the home directory, and being able to run specific versions
| of a software. asdf installs things in the home directory by
| default, and so for the software it does have in its repos,
| it was something I use instead of brew.
|
| Besides, you missed the part I wrote about nix. Even with a
| higher learning curve, nix does the things brew and asdf
| don't do well. It provides package management, library
| dependency management, can run things from the home
| directory, can have multiple versions running, and works with
| direnv to autoload the correct software based on the current
| directory.
| sgammon wrote:
| excited for max's clapback to this
| pxc wrote:
| Despite the title, the OP is not a rant, but a guide to using
| Homebrew in a more broadly compatible and self-contained way.
| happyopossum wrote:
| It is a guide, but it is also a rant. You can't intersperse
| passive-aggressive, angry, and condescending comments
| throughout a guide and not expect people to call it a rant.
| skybrian wrote:
| I have less of a problem with Brew and more with installation
| procedures that require Brew. For example, instructions for using
| the Raspberry Pi Pico C SDK typically start with "brew install
| cmake".
|
| CMake itself supports Mac OS 10.10 or later. Brew requires 10.15,
| so if you depend on CMake via Brew then you're cutting off people
| with older systems.
|
| Furthermore, trying to install via brew means you'll pull in
| other unnecessary dependencies. It tried to install Python for
| some reason but failed. (Python itself supports Mac 10.11 or
| later, but Brew apparently tries some other way of doing it.)
|
| Yes, I should buy a newer machine, but many other programming
| tools work fine.
| alexjurkiewicz wrote:
| 10.10 has been eol for five years without security updates. How
| long should downstream tools support an eol OS?
| skybrian wrote:
| I'd guess CMake supports it just because they haven't seen a
| reason to require a newer version yet. Command line tools are
| like that. (The Go SDK requires 10.13.)
|
| That's the difference between what people can do for
| individual tools versus an entire ecosystem like Brew that's
| trying to do everything.
| jordemort wrote:
| I used to be cranky about it taking over /usr/local but since I
| upgraded to an M1 I have no problem with it hanging out in /opt.
| I don't understand why the path switched when the architecture
| did but I'm happy about the change.
| frizlab wrote:
| I think it's easier to maintain the bottles for two different
| architectures at two different paths, and the /usr/local path
| take over was a recurrent complaint, so the devs took advantage
| of the new arch to change the path.
| Hackbraten wrote:
| Ex-Homebrew maintainer here. You're correct. I couldn't have
| explained it better.
| fijiaarone wrote:
| Brew moving to /opt was nice on M1 but nothing being able to
| compile on M1 is a bit inconvenient.
|
| But that's not brew's fault.
| jordemort wrote:
| Not sure if your issue is brew-specific, I've compiled plenty
| of stuff since getting my M1
| mdaniel wrote:
| I mean, that can't possibly be true, right? The bottles don't
| appear out of nowhere. So "brew install --build-from-source
| bash" dies for you?
| acdha wrote:
| No legacy systems meant they didn't have to worry about whining
| when they switched since everyone was by definition using a new
| install.
| orliesaurus wrote:
| I use brew all the time, and I found the title of this article
| was super-negative for no reason?
| FullyFunctional wrote:
| I have mixed feelings about brew; it's very convenient but the
| one time I reported a bug I instantly got banned and yelled at
| because of my wording. It was very one-sided as I wasn't able to
| apologize or even explain due to the insta-ban. My one other
| interaction with brew community was similar; absolutely any
| critique is taken as a holy war.
|
| I'd really rather Apple made it unnecessary to plug this hole and
| render brew redundant.
|
| ADD: for the record my "offense" was saying "Are you for real?"
| when they screwed up and reverted back to an ancient version. I
| was shocked by that lack of QA but sure, I could have said it
| better. Still, cancel culture meant the end of that conversation.
| userbinator wrote:
| It's not just you; I've only had to touch brew a rare few times
| (because I normally don't work on Apple stuff unless I
| absolutely need to for some reason), and I also quickly noticed
| how the "discussions" on issues are absolutely one-sided most
| of the time. They are extremely quick to take offense.
|
| In other words, they basically have the same attitude as Apple
| itself.
| TillE wrote:
| > for the record my "offense" was saying "Are you for real?"
| when they screwed up
|
| It's really not hard to just not be a jerk, even when someone
| else has made a mistake.
|
| Just be kind. Or at the very least, be calm and factual and
| nothing else. It makes everyone's lives a little better,
| including your own.
| userbinator wrote:
| It says a lot that you perceive such a short and IMHO well-
| deserved expression of frustration as "being a jerk".
|
| If I was on the receiving end of that, I would only apologise
| as being the one at fault. That's what defuses the situation
| instead of aggravating it.
|
| _It makes everyone 's lives a little better, including your
| own._
|
| No it doesn't. This "forced positivity" is far worse in the
| long term.
| FullyFunctional wrote:
| Hindsight is so easy and I wanted to apologize, but wasn't
| allowed.
|
| It was certainly taken as more offensive than I had intended
| and I realized that, but too late.
| politelemon wrote:
| I find the comments responding to you, defending their
| behaviour, thoroughly unsettling. But neither is the behaviour
| of the team, nor these comments, surprising. It's a slice of
| the culture that pervades the user base and development team
| and has been so for several years.
| jasonlotito wrote:
| > cancel culture
|
| It's not cancel culture. It's breaking the rules and someone
| upholding rules.
|
| "I wanted to apologize"
|
| I'm pretty sure if you really wanted to apologize, you could
| have. Being banned in one location doesn't preclude you from
| reaching out in other ways.
|
| Finally, you say that was your only offense, but I need proof
| that this was the _ONLY_ thing you did that was offensive, or
| that was just the straw that broke the camels back.
|
| Considering you equated "upholding rules" as "cancel culture"
| you aren't really unbiased.
| massysett wrote:
| Try Macports. I've been using it for years with no issues.
| thiht wrote:
| > my "offense" was saying "Are you for real?" when they screwed
| up
|
| Volunteers banning someone with an asshole tendency is not
| cancel culture. Just don't be like that. People screw up and
| make mistakes, no need to insult them for it. The proper way to
| react is to thank them for fixing it.
| Mordisquitos wrote:
| > People screw up and make mistakes, no need to insult them
| for it.
|
| One could just as well argue that GP commenter screwed up and
| made a mistake, no need to instantly ban them with no
| recourse to even apologise for it.
| FullyFunctional wrote:
| I would agree with this, but judging and banning people on
| one single exchange is as bad as being a jerk.
| comboy wrote:
| Personally I think it's perfectly fine. Just a few people
| can take a lot of your mental energy and make you less
| interested in your own project. Not being a company you
| don't have to deal with this and somehow there seem to be
| power law distribution like everywhere else - I mean if you
| provide support, a few people will use as much of your time
| as the whole bottom half of them.
|
| So even if you would have 90% chance of false positive it
| may be worth it.
|
| At the same time, if you treat them charitable, ignore
| emotions and do your best with such people/comments, they
| may also turn out to be great contributors and valuable
| feedback. Just the fact that somebody takes his time, his
| most valuable resource, to provide any kind of feedback is
| something. There are popular projects with known bugs which
| take a lot of time to reach developers because everybody is
| busy with their own stuff and doesn't have time to report
| stuff which others may just as well report. Plus, such
| person is more likely to share their experience with others
| which may discourage or encourage some potential
| contributors like it is happening right now.
|
| It is amazing how much PR can a single person do over the
| years when she has really strong opinion about something.
| voxl wrote:
| This has nothing to do with cancel culture, you're just a
| moron. An open source maintainer gets to set their boundaries
| with you however they want. If they want to instantly ban you
| for being an ass that's on them.
|
| If anything, what you are doing RIGHT NOW is inciting cancel
| culture. You want the culture of Mac users to know you were
| slighted by a brew maintainer, and that they should be punished
| in some way for that interaction.
| FullyFunctional wrote:
| It is interesting that you feel it necessary to use name
| calling in a thread about abusive language.
| amelius wrote:
| IT seems to be stuck in an endless loop of package
| management/versioning/install problems.
| armchairhacker wrote:
| I wish there was one universal package manager which provides
| binaries for all platforms, stable/beta/nightly, unverified and
| verified
|
| No more "apt get", "pacman -S", "brew install", etc. you just
| run "pkg add <package>" and it will a) actually have the
| package and b) download or build it whether you're on debian,
| arch, macos, openBSD, etc.
|
| You can configure to use the stable or nightly packages, you
| can add custom package repos including an AUR-equivalent
| "unverified" repo (and remove the default "verified but not
| securely audited" repo), you can configure to build everything
| manually if you want or only download prebuilt binaries, or
| download source code, or documentation. And you can do this
| globally, for users, for groups of packages, or for individual
| packages. You can patch local packages, you can define a
| buildscript and publish your own packages from their git repos,
| etc. You can even use a stable version of one package and force
| it to have nightly dependencies (or vice versa), probably not a
| good idea but you do you.
|
| Honestly it sounds so simple but it isn't implemented. Instead
| we have Debian for stable packages, Arch for nightly packages
| and AUR, macOS has homebrew with all its criticisms or
| MacPorts, and BSD has 3 different package managers all with
| their own flaws. And languages have their own package managers,
| which is fine (bc you're not going to use one language's
| package manager for another) but it would be nice to get that
| unified as well and have superior dependency resolution,
| workspaces, etc. for every language.
| Beltalowda wrote:
| There are cross-platform package managers: pkgsrc and nix for
| example, and I believe HomeBrew runs on Linux too.
|
| It's not that simple though as certain choices are
| fundamentally incompatible. In Debian packagers are expected
| to take "ownership" of the package, backport fixes, apply
| patches or fixes to integrate better with the Debian system,
| etc.
|
| On Arch Linux, it will ship the latest stable version from
| upstream with as little modifications as possible.
|
| You can go with one approach or you can go with the other,
| but you can't really do both at the same time.
|
| Then there's the design of the tooling itself: apt behaves
| fundamentally different from pacman.
|
| Some things can probably be unified here and there, but I
| don't think it's _quite_ that simple.
| encryptluks2 wrote:
| Arch doesn't use nightly packages. They use stable and Debian
| often use several releases behind. Your statement is like
| saying that using the latest official stable version of Nginx
| is the same as nightly and doesn't instill a lot of
| confidence in whatever point you're trying to make.
| joe_guy wrote:
| The tooling side isn't the tricky part, it's the insane
| amount of work that is required to create and maintain each
| package. You need massive community buy in. Because of this,
| unfortunately, the best package managers aren't the most
| sound, the best are the most popular.
| dima55 wrote:
| If you use an OS that doesn't do package management, maybe.
| Linux distros work just fine.
| dmitriid wrote:
| Which one of the distros with which flavor of a package
| manager do you suggest?
|
| And have those package managers manage to work without sudo
| in 2022?
| pxc wrote:
| Nix, Guix, and Flatpak all work fine without root
| privileges.
|
| But why is that a requirement? Homebrew doesn't work
| without root; it only pretends to.
| dmitriid wrote:
| > Nix, Guix, and Flatpak
|
| How many of those are "built in into OS unlike the other
| OSes"?
|
| > But why is that a requirement? Homebrew doesn't work
| without root; it only pretends to.
|
| Can't remember when I last needed to run sudo with brew.
| Whereas I've yet to see a Linux distribution able to
| install anything per user.
| IshKebab wrote:
| As long as you only ever use packages from your distro's
| packaging system.
| adhesive_wombat wrote:
| Until you have something that uses conda.
| bzxcvbn wrote:
| The existence of nix, nvm, conda, venv... or even docker
| suggests otherwise.
| oneplane wrote:
| Out of that list, only nix is a system package manager. The
| rest are developer tools and runtime configurations.
| aprdm wrote:
| How is conda different than nix in this regard?
| oneplane wrote:
| Conda is a subset of Nix in this regard.
| bscphil wrote:
| > The rest are developer tools and runtime
| configurations.
|
| I wish people understood this, but sadly they seem to be
| more and more common as primary modes for software
| distribution.
| rstat1 wrote:
| Except for when they don't. Which is more often than it
| should be.
|
| If I had a dime for every hour of my life wasted by distro
| package managers (or really any package manager) breaking
| when I try to do some basic operation, I'd be a very rich
| person.
| pessimizer wrote:
| > Which is more often than it should be.
|
| How did you calibrate this? I've certainly had no more (
| _far less_ ) trouble with apt-get over the past decade than
| I have with any commercial OS package installation. What
| standard is Linux package management being measured against
| that currently exists? Package management is a dream on
| Linux compared to wrangling Windows software.
| ravenstine wrote:
| It's been a long while since I've used Linux for anything
| but servers, but I have to agree. Not just with package
| management but pretty much anything in Linux outside the
| server domain. I used to waste so much time dealing with
| conflicts between packages, but also on weird bugs with
| graphics and audio, xorg.conf, etc., just to get things to
| work as expected. This comment kinda just turned into a
| rant about Linux in general. Unless things have changed, I
| wouldn't recommend Linux as a desktop to anyone but
| masochists. It's definitely a good thing that Linux distros
| have package management built-in, but that doesn't mean
| there aren't significant drawbacks to the way the Linux
| community approaches it. In contrast, I rarely have issues
| when I run `brew install`. My memories of Aptitude aren't
| particularly fond.
| still_grokking wrote:
| Honest question: Why are you talking about something you
| haven't seen for more than at least 20 years?
|
| Linux is the desktop with the least amount of WTFs. With
| a big margin!
|
| All other OSes break with every update.
|
| Even the perpetual "beta"-system Debian Testing is much
| more robust in day to day use than things like macOS or
| Windows (and that holds even while installing whatever
| daily Debian updates come along without thinking)..
|
| On a (semi-stable) Linux (like Testing) there are never
| "conflicts between packages", btw. This can only happen
| if you make a mess and mix up different distros...
|
| Please don't spread FUD in the future if you don't know
| what you're talking about. Thanks.
| rstat1 wrote:
| >All other OSes break with every update.
|
| I've never had a Windows install break because of a dodgy
| update. Not saying it doesn't happen but its never
| happened to me, whereas when it has happened, its always
| been some Linux distro. Doesn't matter which because I've
| seen it happen on all the major ones (Ubuntu, Fedora,
| etc..)
|
| In fact I have a Linux VM right now, pegging the host's
| CPU to 100% because of a broken update.
|
| Honestly you should probably take your own advice re: not
| know what you're talking about.
|
| >>Linux is the desktop with the most amount of WTFs. With
| a big margin!
|
| FTFY
| still_grokking wrote:
| > I've never had a Windows install break because of a
| dodgy update.
|
| Now you're _obviously_ trolling.
| blep_ wrote:
| xorg.conf doesn't even _exist_ anymore on most systems.
| The others have been improved quite a bit since "a long
| while" ago.
|
| That doesn't mean you have to try it again to update your
| opinions, if you have something else you're happy with
| now, but it does mean you should consider not spreading
| nonsense about things you haven't used.
| Beltalowda wrote:
| I can't even remember the last time I had to look at an
| xorg configuration file. I think it must have been a
| decade; maybe longer.
|
| Back in the XFree86 and early Xorg days it could be a
| pain though, but that was a long time ago. "X -configure"
| asking you about monitor refresh rates that I never knew
| the answer to ... ah, old times.
| howinteresting wrote:
| I'm not a masochist. I want tools to get out of my way. I
| happily use Linux because it is the _only OS with decent
| tiling window managers_.
|
| macOS and Windows feel like toys in comparison to Linux
| which is an actual productivity tool.
| kitsunesoba wrote:
| All of the common Linux package managers make it really
| easy to accidentally shoot yourself in the foot in my
| experience. apt and yum/dnf are the most frequent offenders
| in my case, but I've managed to do it with pacman and
| portage too.
| still_grokking wrote:
| How can you "accidentally shoot yourself in the foot"
| with a Linux package manager?
|
| Would be curious to know what's the point as this never
| happened to me. In almost 25 years of Linux usage.
| kitsunesoba wrote:
| Most commonly, dependency conflicts. Probably the most
| well known example of this was Linus of the Linus Tech
| Tips YouTube channel accidentally rendering his Pop!OS
| install unusable by installing Steam.
|
| The second most common way is installing random packages
| from the internet in attempt to get something working.
| This is one I ran into years ago trying to get audio
| working under Fedora on some random laptop.
| still_grokking wrote:
| What are "dependency conflicts"?
|
| Something like that could probably only happen on a
| broken OS, I guess.
|
| Pop!OS? Isn't that a FrankenDebian in the first place, so
| all bets are off anyway?
|
| https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_Fr
| ank...
|
| > The second most common way is installing random
| packages from the internet [...]
|
| How any package manager on any OS could prevent breakage
| when the user tries hard to break the system at will?
|
| Now I'm a little bit confused.
| riolu wrote:
| Rather than trying to force macOS to support package
| management, developers should be containerizing their
| environments where possible with docker/podman.
|
| The best package manager for macOS is Docker with an Alpine
| container. Not ruby scripts with git as a backend and
| questionable permissions.
| amelius wrote:
| Does that work well for libraries that you use during
| software development? Or do you develop inside the container?
| What if you use two libraries and each has to live in its own
| container?
| ricardobeat wrote:
| > a package management system that will literally yell at you if
| you try to do something about "huh, maybe it's not great my
| executables are writeable by my account without requiring
| authorization first"
|
| I assume "asking for authorization" means sudo. That's a lot more
| dangerous, since installers can then modify _anything_ on your
| system, this is the reason homebrew is set up to avoid it.
| DavideNL wrote:
| Note that you could just setup/run brew as another Admin
| useraccount (without using sudo.)
|
| So from your main non-Admin account you can then do `su -
| myadminuser` to then run `brew install vim`, etc.
| password4321 wrote:
| I quit using homebrew after the auto-update-everything kicked in
| as part of installing some new tiny utility. Both Apple and
| homebrew had transitioned away from supporting my OS recently...
| several working versions of software were uninstalled, then
| something failed to build, leaving behind a total disaster.
|
| I wouldn't even consider using it again without
| HOMEBREW_NO_AUTO_UPDATE=1. MacPorts has been good to me, it even
| has an ncdu1 package since Zig doesn't support legacy macOS
| either.
|
| Ask HN: Best Alternative to Homebrew in 2021?
|
| https://news.ycombinator.com/item?id=29079096
| pgorczak wrote:
| Seconding this, I have lots of Python virtual environments with
| packages that link to brew libs. It's a bummer coming back to
| an env after a while and then realizing auto update has removed
| linked files due to a minor version bump
| rjzzleep wrote:
| I used gentoo prefix for a long time and it was a much much
| better citizen than homebrew(which isn't hard TBH). But gentoo
| has a terrible way of engaging the community. I tried to
| contribute but it was just cumbersome. So in the end back in
| the days I still had my own clang patches(basically before all
| the apple changes were upstreamed).
| laserlight wrote:
| I wonder who thought the autoupdate is a good idea. It's
| absolutely crazy. Lots of things break down and some of them do
| silently, making it really difficult to find the problem when
| one discovers it days or weeks after the autoupdate.
| acdha wrote:
| On a clean system it's rare to have things break so if you're
| an open source developer you prefer people use the current
| release of something rather than re-reporting bugs you fixed
| 3 years ago.
| hparadiz wrote:
| Thank you for this little bit of sanity.
| FiloSottile wrote:
| > "huh, maybe it's not great my executables are writeable by my
| account without requiring authorization first"
|
| I'm very confused as to what threat model leads to this concern
| on an unsandboxed (predominantly) single-user desktop OS such as
| macOS.
| mdaniel wrote:
| I would guess the same risk as "npm i" or "pip install":
| exfiltration of credentials or other supply chain attacks. My
| greatest threat is not a bitcoin miner but rather taking
| advantage of the _data_ on my machine that I 'd rather not
| leave my machine
| acdha wrote:
| This is orthogonal to that point: if I can run code as you, I
| can exfiltrate your data or write an exploit anywhere
| writable. The only case where having Homebrew be read-only
| matters is on a multiuser system where you can do something
| as a non-admin user.
| still_grokking wrote:
| https://xkcd.com/1200/
| FullyFunctional wrote:
| That's exactly it, except it's worse in that every time you
| run an application, you are essentially letting the code
| author do anything as you on your machine (obvious, but worth
| stating). The only reason this works is because we trust
| "people" to discover this and fix it (and it will usually
| have consequences for the perpetrator). I'm just not sure
| this model works anymore, just like we don't use telnet, rcp,
| and all the other things that assumed you could trust the
| network.
| pxc wrote:
| You're not wrong about the way macOS is typically used, but...
|
| I love that the things people will say about macOS include
| _both_ 'certified Unix' and 'single-user OS'.
___________________________________________________________________
(page generated 2022-09-03 23:02 UTC)