[HN Gopher] Homebrew 3.0
___________________________________________________________________
Homebrew 3.0
Author : blucell
Score : 761 points
Date : 2021-02-05 12:57 UTC (10 hours ago)
(HTM) web link (brew.sh)
(TXT) w3m dump (brew.sh)
| cjdell wrote:
| This is great! Does anyone happen to know how to upgrade from the
| experimental Apple Silicon version (installed to an alternate
| prefix /opt/homebrew) that was released late last year?
| Arcanum-XIII wrote:
| It still use the /opt/homebrew for silicon bottle -- so no
| change. I think `brew upgrade`will do the trick in fact !
| 458aperta wrote:
| > brew bottle and bottle do blocks use a new syntax format (one
| :cellar per platform).
|
| ahh finally. been looking for this nifty feature for a while.
| chris_st wrote:
| Thanks for doing homebrew -- been using it for years!
| Hackbraten wrote:
| Appreciate the comment!
| jwr wrote:
| Seconded -- it brought a huge improvement to the quality of
| life on a Mac. Thank you!
| r_police wrote:
| No problem, man!
| aaronbrethorst wrote:
| To take a (lol) contrarian view compared to the rest of this
| thread, I think brew is great with the exception of the
| upgrade/update nonsense, which makes me utterly furious every
| time I try to update (or is it upgrade?) one of my brew-installed
| tools.
| someonehere wrote:
| If anyone from Homebrew is lurking on here. Thank you. I'm
| working with my management team to send a donation your way.
| We've been using it for IT and Engineering deployment builds for
| years and it's something we feel we owe as a sign of gratitude
| and to keep the project running.
|
| Thank you again!
| MrDOS wrote:
| I'm trying to avoid installing Rosetta 2. Anyone know if there's
| a way to configure Homebrew to never install an x86_64 binary and
| throw an error if I ask it to install a formula which isn't
| native on AArch64?
| FemmeAndroid wrote:
| This is my experience with Homebrew. It'll give you a red error
| message if it needs Rosetta 2 prompting you to manually install
| it.
| markphip wrote:
| Isn't this just how it works already? If you install the native
| Apple Silicon version it seems like it either only downloads
| the pre-built Apple Silicon bottles (which now exist for most
| packages) or it builds from source. I do not think it ever
| downloads an x86_64 package in this mode. It was only when
| running Homebrew via Rosetta that this would happen.
|
| BTW, I periodically check in Activity Monitor to see if any
| Intel binaries are running. The only one ever running for me so
| far is Signal. There is no reason to avoid Rosetta though. It
| is already installed and works pretty seamlessly and
| effectively.
| sschueller wrote:
| What will we do if apple restricts the installation to only
| signed apps and brew no longer works?
| [deleted]
| philshem wrote:
| > Particular thanks on Homebrew 3.0.0 go to MacStadium and
| Apple for providing us with a lot of Apple Silicon hardware and
| Cassidy from Apple for helping us in many ways with this
| migration.
| Hackbraten wrote:
| Apple has made it clear that they're not interested in doing
| that. I believe them (for now).
| numbsafari wrote:
| I personally found Homebrew to be really helpful when I looked at
| MacOS as a unix environment and tried to engage in local
| development as if it were a unix environment.
|
| [Un]fortunately, I've stopped looking at MacOS in this way. I now
| look at MacOS as the better version of ChromeOS that runs on non-
| shit hardware (two time PixelBook owner, both of them had serious
| hardware issues, and getting support from Google for what they
| view as throwaway devices is not at the same level as the Apple
| Store/Genius Bar experience).
|
| Taking the view that MacOS is a fat client for apps and browser
| use, that is capable of also running [Uni|linu]x VMs, and pushing
| myself to adopt the "local editor, remote runtime" working model,
| has been really liberating.
|
| I now no longer look at Homebrew as necessary. Instead, I can use
| package managers built for operating systems that are intended to
| work with package managers and that whole ecosystem, rather than
| fighting against Apple's efforts to improve the local security
| environment.
|
| In many ways, I feel like I've come full circle to where I was at
| in the mid-00's, working in a SaaS/enterprise environment
| developing on Windows using VMs for actual dev work so as to keep
| my local machine safe, healthy, and productive.
|
| Rather than dealing with the annoyance of Docker for Mac, I can
| instead just work in a VM running normal docker, or one of the
| competing solutions, and this translates very closely to what I
| run if I'm working against a VM.
|
| And if you are doing anything "serverless" or "server-light",
| it's even less helpful to try and continue working with the MacOS
| terminal userland.
|
| So, hats off to homebrew for all they do, but I really think the
| puck is moving elsewhere and that's where I'm headed instead.
| foobiekr wrote:
| I agree with this.
|
| I use homebrew on my personal machine mostly to get more modern
| versions of the terribly outdated commands that Apple ships but
| that's .. a small surface. I don't use it for anything really
| appropriate and would not.
|
| Professionally - for people who build locally on the mac - the
| sheer awkwardness of pinning specific versions so all
| developers have a common environment regardless of install
| order or timeframe is quite painful with homebrew vs. apt.
| jdlyga wrote:
| I'm definitely grateful that MacOS has a package manager at all.
| Mac before the unix-like OS X days was like using Windows: you
| had to hunt for installers or DMG's. Except Mac didn't have the
| legacy support that Windows aims for: all your programs would
| break when a major update like MacOS 8 came out.
| zymhan wrote:
| The bigger pain point for me is macOS still has no system-wide
| registry of installed applications. You specifically need to
| keep the uninstaller around for big applications.
|
| So lord help you if the app you want to delete isn't a single
| .app file in /Applications
| Hackbraten wrote:
| Homebrew helps you with that, even if the app was installed
| without Homebrew:
|
| brew uninstall --zap --force CASKNAME
| 4lejandrito wrote:
| I personally consider malware anything that I cannot install with
| homebrew.
|
| Jokes aside, I've loved it for many years now. Thanks!
| aerovistae wrote:
| But does it still try to update literally every time you use it?
| thomaslkjeldsen wrote:
| That has changed recently:
| https://github.com/Homebrew/brew/issues/10386
| ihuman wrote:
| If you set HOMEBREW_NO_AUTO_UPDATE to 1, it won't update when
| you run the install, upgrade, and tap commands like it normally
| does
| sneak wrote:
| Also don't forget HOMEBREW_NO_ANALYTICS=1 in your environment
| to keep it from silently phoning home a machine-specific
| unique identifier and your client IP (city-level geolocation)
| to Google every time you run it.
|
| https://github.com/Homebrew/brew/issues/142
| CamJN wrote:
| So they're just not going to fix the /opt /usr/local split? Real
| dick move.
| andycowley wrote:
| Oh. Came here looking for some sweet technological enhancements
| to the making of beer at home...
|
| I'm sure this is splendid
| freedomben wrote:
| I don't see Linux mentioned at all.
|
| I'm not complaining, but as a Linux user who uses dnf/yum for
| everything there, but also has some needs for things that either
| aren't packaged at all, or are but move too slowly and break
| often (youtube-dl) I use brew. I love that it installs in my home
| directory. Linux Brew is awesome to have for that.
|
| I don't expect Linux will ever be a prime focus, but I do wish it
| would be easier for packages to support Linux. Many times it
| doesn't require any actual formula changes beyond trivial.
|
| Note: If you are on Arch, AUR is often better than home brew. I
| don't use Arch on my daily drivers/work machines anymore but
| deeply miss the AUR :-)
| rattray wrote:
| I didn't even know Homebrew worked on Linux!
| mkrishnan wrote:
| When do we get to install brew without sudo?
| sneak wrote:
| You can install it unprivileged somewhere in your home
| directory and it will generally work fine, even though they
| warn you against it.
| gigatexal wrote:
| So glad I sponsor this project. The mac would be entirely harder
| to use as a development platform without these package managers
| (this praise includes all the efforts not just that of Homebrew).
| Donate here: https://github.com/homebrew/brew#donations
|
| Note: I am not affiliated with the project in anyway other than
| being a backer and a user.
| Hackbraten wrote:
| Thank you so much for your generous support and for the shout-
| out. Much needed and appreciated. You rock!
| sebiw wrote:
| Dear Homebrew maintainers,
|
| one simple effing thing: thank you! For all the hard work and the
| sheer pleasure Homebrew adds to the experience of developing
| software on a Mac.
| offtop5 wrote:
| Does it work natively on M1 Macs yet ?
| timw4mail wrote:
| It's literally the first line item!
| callahad wrote:
| Your question is addressed in the second sentence of the linked
| post.
| rgacote wrote:
| As a long-time Python user, Homebrew jumping versions from 2.7.0
| to 3.0 is a little disorienting. :}
| wejick wrote:
| I'm waiting for comments like this one ahahaha. Can't agree
| more Iz datz some conspiracy?
| rswail wrote:
| The majority of the ports and software I want installed are
| essentially Unix/Linux/GNU environment tools.
|
| Macports has always seemed to me to be a more "unix-y" way of
| doing that, and it works politely with Apple's ways on top of the
| Unix core (eg locking down the system volume).
|
| It also has a very nice "select" and "variants" system that
| allows you to have multiple versions of a package as well as
| packages with more or less functionality (eg integrating with the
| MacOS keychain etc).
|
| When I first got into Macs (only around 5 years ago), I looked at
| both homebrew and macports and as soon as I saw homebrew blasting
| stuff into /usr/local while macports neatly put everything in
| /opt, I was convinced to go with macports. I also had previous
| experience with the BSD's port systems, which helped push me
| towards macports.
|
| But I'm open to being convinced about homebrew, although I've
| never needed something that it had that macports didnt.
| ihuman wrote:
| Why is it bad that homebrew puts files in /usr/local?
|
| Edit: They use /opt if you're on Apple Silicon
| https://github.com/Homebrew/brew/blob/master/docs/Installati...
| gregmac wrote:
| My first experience with homebrew (as a non-mac user) was
| setting up a build agent a few years ago. It seemed like a
| nice way to get everything going, as well as being analogous
| to the ways it was setup on other OSes (using packages to
| manage the SDKs/tooling).
|
| I think my mistake was treating it like any other unix-y
| [multi-user] system, because I installed everything with one
| account, then created a dedicated 'build' account for the
| agent to run as -- exactly as our linux (and even, ahem,
| Windows) agents were setup. This caused all kinds of failures
| for the 'build' user as everything was owned by and had
| permissions setup for the first user.
|
| I came away kind of disgusted at the horrible patterns in
| use. Windows has spent two decades cleaning up that mistake,
| and here's a comparably new system making the same, awful
| mistakes?
|
| User-writable/owned stuff goes in ~. Period.
| joseph wrote:
| There's nothing wrong with installing packages into
| /usr/local, but brew turns /usr/local into a git repository
| and IMO that is wrong. Also, brew acts like it's made for a
| single user, as it changes files and directories to be owned
| by the user running it, but /usr/local is a system directory.
| When I install brew, I always put it into my home directory
| instead of /usr/local.
| mekster wrote:
| How's the experience putting it under your home? I assume
| many packages need to be compiled but does everything
| compile fine?
| vetinari wrote:
| It turns /usr/local/Homebrew into a git repository; not
| /usr/local itself. Whatever it links into
| /usr/local/{bin,include,lib,sbin,share} is just a symlink
| into /usr/local/Cellar.
| saagarjha wrote:
| It used to turn /usr/local into a Git repository, at
| least until that got locked down with SIP.
| ComputerGuru wrote:
| I used to recommend Homebrew but stopped some time ago (v2,
| perhaps?) when they hard-removed all build
| customization/options in order to make it easier to develop
| bottles and close out GitHub issues (on their end) while
| severely restricting what users could do, taking away a lot of
| power and freedom that was previously available. Much more
| inline with the Apple line of thinking, but that's kind of the
| reason people wanted a *nix-esque package manager, no?
| brianzelip wrote:
| Thanks all! Love Homebrew, keep up the good work!
| upbeat_general wrote:
| I realize this is a bit counter to the thread title but can
| someone who's familiar with macports give their take on whether
| it's worth using both brew + macports at once is a good idea?
| I've been solely using brew and very much appreciate the
| convenience but I saw that macports allows multiple versions of a
| single package which has been a pretty big pain point for me with
| brew. It doesn't happen super often but there have been several
| times that this limitation for brew has been a huge pain point,
| forcing me to pollute things by compiling manually, putting it in
| a new location, etc.
|
| I know it's a bit far fetched but if my package manager could
| replace say, pyenv, by just making it easier to install several
| different versions and then letting me pick the default symlink,
| that would be so helpful (or even just not removing python2...).
| talentedcoin wrote:
| One thing I haven't seen mentioned here is that Homebrew forced
| people use Ruby to write formulas (ie packages), whereas MacPorts
| forced people to use Tcl. This one decision, plus hosting
| formulas on Github, was a major contributor to their present
| success.
|
| As much as I sympathize (deeply) with all the criticism of
| Homebrew here on this thread -- I used to use MacPorts
| religiously and love it -- I don't think Homebrew took the field
| purely through sneaky marketing or n00b decisions alone. They
| leveraged the momentum of a lot of new devs coming to OS X and
| provided an easier path for people wanting to help out.
|
| I hate to say it, but if this was a race (?), Homebrew won.
| Thankfully we all still have the choice to use MacPorts if we
| want, but there's no point in being mean about Homebrew at this
| point either.
| [deleted]
| pyro2927 wrote:
| I used both MacPorts and Fink prior to Homebrew being released.
| The fact that it was able to do binary archive installs, and
| then later Homebrew Cask just made it a far friendlier package
| manager. I've added a few formulas over the years and am happy
| to see it continue!
| filmgirlcw wrote:
| I agree with this (other than maybe hating to see Homebrew
| "win"). And I'll add:
|
| And although I'm not arguing Homebrew is above reproach or
| critique, some of the criticism here seems both a little
| unfounded and a little bit ignorant (either willfully or
| because people just don't know/remember) about the state of
| package managers BEFORE Homebrew. Like you, I used
| MacPorts/Darwinports and Fink for years before Homebrew was a
| thing and have immense respect for all three of those projects
| (even though DP merged with MP over a decade ago, my mind still
| sees them as separate things) and the massive role they played
| in my own life and development as a developer, but Homebrew
| didn't just pop-up and supplant the existing options and
| through nefarious means.
|
| At the time that it came to existence, despite the very good
| existing options, those communities and their progress had
| stagnated -- at least from the perspective of the end user.
| There was a wealth of older packages, but newer stuff wasn't
| there. And the death of PPC with Snow Leopard hit subsets of
| that community hard. It wasn't just that Homebrew was easier to
| use and install (though it was, a bit), it was that it had more
| modern and more frequently updated packages.
|
| I distinctly remember when Homebrew first arrived, my initial
| reaction was, "why do I need this, I already have MacPorts?"
| But then I used it and found that people were bottling up newer
| stuff at a much more rapid pace and the tools embraced by that
| community were modern and frankly, to an outsider, much more
| accessible. As you said, choosing GitHub over MacForge or
| whatever was a great choice too.
|
| MP has had a renaissance of sorts over the years which has been
| amazing to see. I think having options is awesome. But Homebrew
| was very much filling a void for some beloved projects that had
| fallen behind. It's hard to win that momentum back, once the
| community (including a whole generation of new users) goes to
| the new thing.
|
| We've seen that with Mac text editors too. TextMate, to me, is
| still one of the best editors I've ever used and I would argue
| is one of the most influential software applications of the
| aughts. But as it faced all of its challenges to move to 2.0
| (the feature creep, the technical challenges, the scope
| changes), it created a window for Sublime to come in and take
| the the extension community (which was really pioneered in the
| way that it worked by TextMate), and thus the userbase with it.
| And when Sublime faced similar challenges in its own troubled
| releases (for some of the same but also different reasons that
| TextMate had), we again saw momentum shift to VS Code.
| zzyzxd wrote:
| It reminds me about this answer from Homebrew's creator, Max
| Howell, on Quora[1]:
|
| > I wrote a simple package manager. Anyone could write one. And
| in fact mine is pretty bad. It doesn't do dependency management
| properly. It doesn't handle edge case behavior well. It isn't
| well tested. It's shit frankly. > Is it any surprise I couldn't
| answer their heavily computer-science questions well? > On the
| other hand, my software was insanely successful. Why is that?
| Well the answer is not in the realm of computer science. I have
| always had a user-experience focus to my software. Homebrew
| cares about the user.
|
| Yes, Homebrew's approach on package management is a bad smell
| to me. It gets broken by every other major OS update, it messes
| up your Python PATH for no good reason, it forces a lot of
| opinionated decisions on users if the maintainers think it
| benefits the majority(and ignores voice from minority)... But
| Homwbrew still wins because users really like it. It is that
| simple. With its popularity and the strong community, it will
| continue to be the top choice for most of the mac users. Max
| Howell may not be a rock star programmer in my mind, but I have
| no doubt that he could've been a very successful product
| manager.
|
| Personally I don't plan to switch from macports to homebrew any
| time soon, but I stopped grumbling about how bad it is years
| ago.
|
| 1. https://www.quora.com/Whats-the-logic-behind-Google-
| rejectin...
| Wowfunhappy wrote:
| As I see it, one problem in software is that when you have a
| problem, it's often not clear what is at fault. Let's say my
| laptop is slow, particularly when I have lots of browser tabs
| open. Should I blame:
|
| 1. My hardware?
|
| 2. My OS?
|
| 3. My web browser?
|
| 4. My browser extensions?
|
| 5. Websites?
|
| 6. The chat app I keep running in the background?
|
| 7. The Electron settings app for my RGB Keyboard?
|
| 8. My internet connection?
|
| 9. A virus?
|
| 10. "Technology", presumably alongside some wistful thoughts
| of "the good old days"?
|
| Most users, even non-technical ones, are going to blame _one
| of these things._ And, more often than not, their conclusions
| will have more to do with marketing and happenstance than the
| actual cause
|
| All of which is to say, that Howell quote kind of bothers me.
| Skimping on technical details means that _you aren 't
| actually focused on user experience._ You may have created an
| experience in which users feel inclined to blame _something
| else,_ but that 's not the same thing.
|
| It is a model plenty of companies have found success with, to
| be sure. But it isn't particularly admirable.
| saagarjha wrote:
| Have you tried uninstalling Chrome? I hear it can make your
| WindowServer go wild :P
|
| More seriously, though, this is why I hate people who use
| software like Electron and claim their users can't notice:
| of course they can, they just complain that their computer
| is slow because they can't pinpoint it on your app. As a
| developer who knows better, your entire charade depends on
| ignorant users being unable to point the blame at you for
| what you have done to them. Combine this with the lock-in
| typical of today where users are resigned to use your
| software even if they don't particularly want to and now
| the people who _do_ know what you 're doing can't do
| anything about it either.
| gabereiser wrote:
| I still prefer MacPorts over Homebrew. However, like you said,
| Homebrew's marketing in the form of embedded into tutorials and
| setup's helped push them to where they are now.
|
| Almost every Ruby on Rails tutorial I've seen in the last
| decade used Homebrew over MacPorts.
|
| I found MacPorts just before Homebrew was a thing. I figure
| since Mac OS was BSD based, why not go with the traditional
| portage way.
|
| I preferred my optional packages to be installed in /opt. I
| preferred MacPorts.
|
| Sadly, in the last 3-4 years, Homebrew has been leading the
| charge, adding more bleeding edge package versions and just
| doing a better job of maintaining the formulas for install.
|
| Happy to see it. I think for python/go/ruby devs they will
| continue to prefer Homebrew simply because the tutorials _they
| learned from_ prefer it. It 's a feedback loop.
| wp381640 wrote:
| Homebrew and Metaspoit prompted me to learn Ruby. It's an
| excellent and well-suited language for that type of DSL
| petard wrote:
| I don't recall how I came across it but remember well the
| relief after using it the first time. It was the first package
| manager on MacOS that worked and made installing common tools
| painless. With MacPorts, fink etc it felt like it would have
| been better to built from source yourself.
| sirn wrote:
| Those were one of the reasons, but I believe the biggest reason
| was MacPorts didn't install from binary archive and requires
| building everything from source in its early days (in the old
| BSD port tradition). Binary archives were added to MacPorts in
| 2011 with MacPorts 2.0, but a lot of people (me included) has
| already moved to Homebrew, leaving MacPorts with an impression
| of old, slow, and make your Mac fry an egg.
|
| MacPorts these days behaves similar to Homebrew by installing
| from binary archives by default and only build from source when
| binary archive is not available. This vastly improved the
| experience, but the old impression remains for those who got
| burned (literally for some) by MacPorts. 10 years is a long
| time, and MacPorts has improved a lot since then.
| kitsunesoba wrote:
| The other downside to MacPorts' original way of building
| everything is that sometimes, for whatever reason, things
| _just wouldn 't build_ and getting help with that was thorny,
| particularly for those who'd just started dabbling in
| software development or CLI usage. Where a vet or moderately
| seasoned user might find the thrown error actionable, the new
| user would google the error, find a couple of semi-related
| but ultimately unhelpful archived mailing list threads from n
| years ago, and probably give up and find some other way to
| get the package they need.
| todd8 wrote:
| Just today my new config for Emacs refused to build libgit.
| I could see the CMake error, but rather than figuring out
| how to fix it I just commented out that part of my config
| (resulting in slightly more overhead in magic). Even with
| many years of serious software development, I really don't
| like debugging build problems.
|
| I used to use Fink and MacPorts for MacOS package
| management, but brew was so easy to use that it won me
| over.
| pjmlp wrote:
| This is one reason why using Rust crates in cargo's current
| form irritates me, if I wanted that kind of experience I
| would be using Gentoo as daily driver.
|
| All the other languages I use support binary libraries on
| their package managers.
| Wowfunhappy wrote:
| MacPorts does also still drop to compiling from source more
| often than Homebrew. But that's mostly because they take a
| more conservative legal approach towards the GPL--for
| instance, they won't distribute binaries of any GPL software
| that links with OpenSSL.
|
| Also, ports for older/ancient versions of OS X are frequently
| source-only, but since Homebrew doesn't support such systems
| at all, it's not really a fair comparison.
|
| (As an aside, MacPorts must have the most incredible legacy
| support of any Mac project, ever. They had ARM working within
| a week of the M1's release, largely because all of the
| infrastructure for multi-arch was already in place--to
| support users on PowerPC!)
| weaksauce wrote:
| > Also, ports for older/ancient versions of OS X are
| frequently source-only, but since Homebrew doesn't support
| such systems at all, it's not really a fair point of
| comparison.
|
| On an old, unsupported, system homebrew drops down to
| compiling. just the other day it compiled for four hours
| just to update one program. kinda infuriating really since
| there are downloads for those packages still.
| saagarjha wrote:
| I'm surprised it still works, to be honest-Homebrew is
| usually fairly aggressive about dropping support for
| older systems.
| Hackbraten wrote:
| We don't support any scenario where things are built from
| source (i. e. we won't help you if things break) so
| technically support has indeed been dropped.
| [deleted]
| stephenr wrote:
| This is a weird take.
|
| Homebrew not only installed from source for a long time, when
| they implemented installing prebuilt binaries, they half-
| assed the dependency resolution of it, so the binary version
| of a package would always end up requiring the binary version
| of the first of any alternate dependencies (ie if A requires
| B or C, binary pkg A will always require binary package B,
| and won't accept C).
| sirn wrote:
| Ah, you're right. Now thinking back, I think it was how
| Homebrew reuse system libraries that make it a better
| experience than MacPorts at the time since it could cut
| over half of the building time (it prevent the situation
| where `port install sl` ended up having to build the entire
| gcc toolchain). This was actually why "reuse system
| library" were such a big deal back then. Bottle come much
| later than that.
| 404mm wrote:
| MacPorts seem to be very "user" friendly for people with Unix
| and/or Gentoo (maybe a bit Arch too) background. I have
| experience with all three and when I needed to decide in
| between HomeBrew and MacPorts, it was very simple choice. I
| tried both to get the actual experience and stuck with
| MacPorts. All the naming in HomeBrew was just too confusing too
| me.
| [deleted]
| fossuser wrote:
| Gentoo is probably the most user hostile Linux distribution I
| can think of other than ones purposely austere for learning
| (LFS) or parody (Suicide Linux).
|
| If Mac Ports requires that level of knowledge to be user
| friendly it's no surprise they lost.
| LiberatedLlama wrote:
| I used gentoo for a few years and found it to be very
| pleasant, with a great wiki. The only reason I ever stopped
| using it is because I realized how senseless it was to
| build everything from source on a laptop with questionable
| thermal characteristics. Running laptop fans full tilt for
| hours on end a few times a week evidently exceeds their
| expected duty cycle, who'd have thunk, but I had to replace
| the fan in my T60p twice before I learned this lesson.
| Building everything with Macports would have the same
| problem, except worse because mac laptops were never as
| easy to repair as thinkpads, particularly not in recent
| years.
| mekster wrote:
| Hostile, as in not everything is mouse clicky for you?
|
| It was a great learning experience nearly 20 years ago.
|
| It's just not for you.
| fossuser wrote:
| It was a great learning experience for me too.
|
| It's just not user friendly.
|
| It was my first experience with linux in 2003, going
| through some 80 page wiki to get things configured and
| built. Learning how to configure an fstab file.
|
| Hostile as in everything requires following a multipage
| guide of commands and manual configuration that often
| didn't quite work. Also when I asked on the forum I was
| told they didn't want more users, but more _skilled_
| users (I was 12).
|
| So not really mouse clicky, more that basic functionality
| takes enormous effort to get working and the community at
| the time wasn't great.
| spijdar wrote:
| If Gentoo makes your particular computer goal easier to
| achieve, I don't think it's "hostile".
|
| Most people will never need Gentoo or want to use it, but
| for those with either a need or a desire for a meta-
| distribution, Gentoo does a pretty good job. I don't think
| calling it "user hostile" is quite right.
|
| I think it's been partially supplanted by other package
| managers now like Nix/NixOS and even (IMO) XBPS/Void, but
| Portage does an alright job.
| thaumasiotes wrote:
| I used Gentoo for a while and mostly liked it. There was
| one reason I stopped using it -- dependency conflicts.
| Every time you update, there's a new set of conflicts
| that you have to personally untangle.
|
| By any other metric, I would consider it more user-
| friendly than average. For example, I was very favorably
| impressed when (not knowing what I was doing), I gave the
| command to uninstall libc, and after confirming that I
| really wanted to do that, I was allowed to.
| zests wrote:
| I've never used MacPorts. Go figure, I just realized that
| "MacPorts" means "bsd ports for mac". I'll have to try it
| sometime and see if I prefer the look and feel of MacPorts.
| curun1r wrote:
| I find it unfortunate that those two occupy the 1-2 in Mac
| packaging options. It never really got much attention, but I've
| always liked Rudix [0] better. The package selection is much
| worse and not really kept as up-to-date, but the installation
| mechanism is far superior to Homebrew and MacPorts (and even
| Fink). It uses actual packages (the kind that Installer.app
| understands) so it integrates much more cleanly with the Mac
| ecosystem and packages installed without using the package
| manager. Compared to the other options, it's an administrator's
| dream in a managed environment since all the first-party Apple
| tools for managing a fleet of Macs just work. Also, users who
| don't want to install the actual rudix tool can simply download
| the packages and install using using Installer.app (which they
| may never even realize they're running because it opens
| automatically when opening a .pkg file).
|
| Unfortunately, most Mac users have never even heard of it and
| it doesn't really have the momentum or mindshare necessary to
| have a complete, up-to-date list of packages.
|
| [0] https://rudix.org/
| sigjuice wrote:
| Rudix seems interesting, so I just installed the nasm .pkg as
| an experiment. There are several things I don't understand
| yet. How is a package uninstalled? If there is an updated
| package, does the whole process of downloading and clicking
| through Installer.app have to be repeated? Also, is there an
| automated way to install a large selection of packages at
| once?
| curun1r wrote:
| There is an actual rudix package that has
| install/uninstall, including for itself.
|
| Otherwise you're using the somewhat cumbersome process of
| backing out a package based on the receipt. It's doable,
| but mostly requires some googling to find the correct
| incantation.
| mekster wrote:
| Why leave out nix? It's been a good alternative that works
| similarly on Linux too for unified environment.
|
| I hate Linuxbrew when it tries to install stuff in a weird
| place that is /home/linuxbrew/.linuxbrew/ and as soon as you
| try to change the installation path, half of your packages
| starts compiling and since it's not the major way to do
| things, it often breaks and can't even compile.
|
| I don't like scaring other users on the same server creating
| stuff at some bizarre location.
|
| No idea how they didn't just settle in /use/local/ as it does
| on Mac or just use /opt/brew/ like a sane choice would be.
| MagerValp wrote:
| Can't upvote enough. Rudix is the only package manager that
| really meshes with the platform, instead of trying to create
| its own weird linux (or bsd) hybrid ecosystem. I used it
| heavily a decade ago, but sadly it never really took off.
| lloeki wrote:
| > I hate to say it, but if this was a race (?), Homebrew won.
| Thankfully we all still have the choice to use MacPorts if we
| want, but there's no point in being mean about Homebrew at this
| point either.
|
| Definitely, plus there's also Nix and pkgsrc now, it's not like
| there's no alternative. And that's one race I lost trying to
| take the matter in my own hands with ArchMac[0] out of
| frustration with the limitations I faced with MacPorts and
| Fink, then Homebrew, so I pulled the plug[1] and trim the
| bills.
|
| If anyone wants to take over just reach out.
|
| [0]: https://www.archmac.org/
|
| [1]: https://lna7n.org/2020/01/06/pulling-the-plug-on-
| archmac.htm...
| chisquared wrote:
| I'd never heard of Arch Mac until I read this comment, but
| reading your post about pulling the plug gave me chills.
|
| I could tell that you poured a lot into this project, and I
| feel a surprising degree of wistfulness over your decision to
| abandon it.
|
| I hope whatever you're working on now is as fulfilling as you
| wanted Arch Mac to be.
| jjtheblunt wrote:
| i honestly don't know the backstory on why you "hate to say
| it", and personally was a NeXT developer 25 years ago which I
| mention for context that I feel I missed out on something
| preferable in MacPorts, having found homebrew adequate.
| talentedcoin wrote:
| No real backstory I guess. I found Homebrew unpleasant to use
| for a lot of the reasons gone through in this thread --
| mostly just the "rolling distro" nature of it -- so I was a
| dedicated user of MacPorts. My experience is probably further
| biased by the fact that I was using the package manager on OS
| X to deal with Python stuff at the time, so the versioning
| issues definitely bit me. But at some point, using MacPorts
| just started to feel like swimming against the tide.
| mojuba wrote:
| Been a MacPorts user for years and I know nothing about Homebrew.
| To those who tried both: should a software engineer switch to
| Homebrew?
|
| MacPorts has its own way of dealing with dev tools and framework
| versioning. E.g. you can have multiple versions of complex
| products like PHP or MySQL at once. You can even have a GCC
| package for a specific target arch as a separate ports package.
| Does Homebrew allow these things?
| shagie wrote:
| MacPorts and Homebrew have a different philosophy of software
| installation.
|
| MacPorts wants to have its own thing over in /opt where it has
| its own toolchain independent from the system tool chain.
|
| This means that all users on the system share the same MacPorts
| software. This has an additional impact that it means that it
| requires privilege to install software there.
|
| Homebrew, on the other hand, uses the system toolchain and
| tries to avoid using root.
|
| In today's world, the "multiple versions of complex products
| like PHP or MySQL at once" isn't a compelling argument for me
| as I use docker to solve that problem.
| ashtonkem wrote:
| Given the moving nature of the OSX toolchain and directory
| structure, having your third party package manager integrated
| into the system toolchain increasingly feels like a bad idea.
| shagie wrote:
| The flip side of that is "do you want to have two scripting
| and compiler toolchains installed on the machine - one that
| gets updates from the vendor and one that gets updates from
| volunteers?"
|
| The spot where this becomes an issue would be say...
| (making up a story here) there's a vulnerability found in
| Ruby which is part of the toolchain for the system and in
| MacPorts toolchain. Apple pushes out a security update that
| updates the system toolchain... but the issue in the
| MacPorts toolchain remains until that is updated.
|
| I had an issue with MacPorts many years ago when I was
| trying to install a python library via MacPorts (I forget
| exactly why) but wasn't being found with python on the
| command line (which was using the system toolchain) and
| then when I resolved the "I'm using the MacPorts version on
| the command line" other issues with software that was
| expecting the system toolchain version started cropping up.
|
| That's a "my experience" story and isn't meant to be
| defining.
|
| I believe that both Homebrew and MacPorts have made design
| choices that reflect how they want to take their respective
| projects and I respect those design choices. They solve
| problems in different ways and have different repercussions
| for how users use them.
|
| For me, on my systems, I've found that I tend to prefer to
| fix the problems that Homebrew causes than the problems
| that MacPorts causes. The big thing that made that
| preferable is that the services (databases and such) are
| not run on the bare machine but rather in containers.
| mojuba wrote:
| Containers cover some use cases but not all. Experimentation
| for one, also if you need specific compiler toolchains that
| you occasionally use on your sources. You don't create a
| Docker image each time you need a specific toolchain.
| MacPorts definitely shines here but it's probably not a great
| option for non-technical users.
| loeg wrote:
| > This means that all users on the system share the same
| MacPorts software. This has an additional impact that it
| means that it requires privilege to install software there.
|
| > Homebrew, on the other hand, uses the system toolchain and
| tries to avoid using root.
|
| What? Homebrew wants you to change ownership of /usr/local to
| your individual user and refuses to run without doing so. How
| is that any different as far "as all users on the system
| share the same software?"
| dylan604 wrote:
| Huh? I'm on Big Sur running homebrew.
|
| 'ls -l /usr' reveals that /usr/local is root:wheel just
| like all other folders under /usr. How exactly is homebrew
| changing ownership?
| Redoubts wrote:
| https://stackoverflow.com/questions/16432071/how-to-fix-
| home...
|
| Dunno if it needs this now anymore -- i think they moved
| to /usr/local/Homebrew some time ago -- but this was a
| big deal for a few years
| loeg wrote:
| Any chance you're on Apple Silicon? For some reason
| homebrew uses /usr/local on Intel macs and /opt/homebrew
| on ARM macs.
|
| Anyway, this requirement is well documented and not new:
|
| https://github.com/Homebrew/brew/issues?q=is%3Aissue+%2Fu
| sr%...
|
| http://github.com/Homebrew/brew/blob/master/docs/Installa
| tio...
|
| Homebrew asks users (on Intel macs) to change the
| ownership of /usr/local to their local user. And it
| refuses to run under sudo.
| djrogers wrote:
| > Homebrew asks users (on Intel macs) to change the
| ownership of /usr/local to their local user.
|
| Nope - intel Mac on Big Sur:
|
| drogers@SJCMACJDYMD6M ~ % ls -l /usr
|
| [snip]
|
| drwxr-xr-x 15 root wheel 480 Dec 14 20:10 local
|
| [end snip]
|
| And for the record, neither of your links support your
| claim.
| anaerobicover wrote:
| This changed in the last few years (I don't recall the
| exact date), but it absolutely was the way that brew
| operated for many years.
|
| https://apple.stackexchange.com/questions/1393/are-my-
| permis...
|
| https://superuser.com/questions/1264673/chown-usr-local-
| oper...
| dylan604 wrote:
| >Any chance you're on Apple Silicon?
|
| No, I'm on an Intel chip, not M1.
|
| >Homebrew asks users (on Intel macs) to change the
| ownership of /usr/local to their local user. And it
| refuses to run under sudo.
|
| Again, no, not on my machine it doesn't. /usr/local is
| root:wheel. This is a newish (to me) machine that I gave
| first birthday to beginning of December 2020. The first
| thing I did was installed brew and started installing the
| things that makes my computer useful to me. No
| permissions were asked to be changed.
| banana_giraffe wrote:
| > Homebrew wants you to change ownership of /usr/local to
| your individual user
|
| If I read homebrew's install.sh correctly, it changes
| ownership of a few directories under /usr/local, not
| /usr/local itself (on x86, on ARM it follows a different
| path). This matches how my current Mac, which has brew, is
| currently setup as well. # Required
| installation paths. To install elsewhere (which is
| unsupported) # you can untar
| https://github.com/Homebrew/brew/tarball/master #
| anywhere you like. ... # On Intel
| macOS, this script installs to /usr/local only
| HOMEBREW_PREFIX="/usr/local" ...
| directories=(bin etc include lib sbin share opt var
| Frameworks etc/bash_completion.d
| lib/pkgconfig share/aclocal share/doc
| share/info share/locale share/man
| share/man/man1 share/man/man2 share/man/man3 share/man/man4
| share/man/man5 share/man/man6 share/man/man7 share/man/man8
| var/log var/homebrew var/homebrew/linked
| bin/brew) group_chmods=() for dir in
| "${directories[@]}"; do if
| exists_but_not_writable "${HOMEBREW_PREFIX}/${dir}"; then
| group_chmods+=("${HOMEBREW_PREFIX}/${dir}") fi
| done ... and further on, after some checks,
| group_chmods turns into chowns ... if [[
| "${#chowns[@]}" -gt 0 ]]; then ohai "The
| following existing directories will have their owner set to
| ${tty_underline}${USER}${tty_reset}:" printf
| "%s\n" "${chowns[@]}" fi
| anaerobicover wrote:
| Parent's information is outdated, but
| originally/historically Homebrew did want you to chown
| /usr/local
| anaerobicover wrote:
| Actually (I can't edit the original comment anymore) it
| looks like they were still recommending this as recently
| as last year?? https://discourse.brew.sh/t/permission-
| problems/3011/29
|
| Haven't used Homebrew in quite a time, so I'm not sure.
| SkyMarshal wrote:
| Fwiw you can use the Nix package manager (https://nixos.org/)
| on OS X to accomplish those same things. Lots of discussion
| about that the past few years:
|
| https://google.com/?q=nix+on+mac+os+x
|
| Nix has more packages than MacPorts - 60k vs 37.6k - though
| that's not necessarily a guarantee the ones you need are there.
|
| And like MacPorts it doesn't do weird, non-Unix-y ownership
| changes of system directories like Homebrew does.
| sirn wrote:
| Unfortunately, Nixpkg doesn't check buildability on Darwin
| when merging PRs, so things can break quite often on the
| nixpkgs-unstable channel (compared to nixpkgs-unstable on
| Linux). It's not hard to rollback, though, but it does makes
| me never want to ever run `nix-channel --update`.
| soraminazuki wrote:
| nixpkgs CI _does_ check for buildability on Darwin, which
| can be confirmed by looking at any of their PRs. However,
| packages do tend to be get marked as broken on Darwin if it
| doesn't build and the packager doesn't own a Mac.
|
| I feel things have stabilized significantly in recent days,
| though. I haven't had a single Darwin breakage on the
| unstable channel since the release of 20.09. Perhaps the
| Zero Hydra Failures effort[1] helped.
|
| [1]: https://github.com/NixOS/nixpkgs/issues/97479
| sirn wrote:
| I think what I meant was darwin failure doesn't block.
|
| Recently I had nomad breakage on -unstable caused by nvml
| support, which pulls in nvidia_x11, which pulls in
| linux_5_4, which of course not installable on darwin[1].
| The maintainer fixed it very quickly (thank you!) but I
| still need to wait few more days for it to be included in
| -unstable.
|
| [1]: https://github.com/NixOS/nixpkgs/issues/108603
| Ericson2314 wrote:
| Use one of the Darwin channels, that won't advance unless
| Darwin things are not too broken.
| abathur wrote:
| I feel similarly and am a little careful about when I
| choose to take an update.
|
| That said, I think most people want darwin failures to be
| able to block, so it's mostly about getting _on top of
| them_ to the point where it 's practical to keep them
| triaged. Domen is working on getting a part-time position
| funded to work on issues here
| (https://opencollective.com/nix-macos), though individual
| package breaks are probably down the list.
| cutler wrote:
| How is that better than a pm specifically designed for Mac?
| SkyMarshal wrote:
| Are you talking about Homerew or MacPorts?
| abathur wrote:
| It probably depends on what you want?
|
| If you like treating your Mac like a very MacMacMac pet, a
| pm designed for Mac is probably better.
|
| If you'd like to treat your Mac like UnixMac livestock, you
| probably want a cross-platform pm.
|
| Using Nix means the core of my dev needs are met by config
| shared between my NixOS and macOS systems, with some
| idiomatic unshareable bits around the edges.
|
| (I don't want to trivialize the gaps or over-sell Nix here.
| Nix forms a foundation for accomplishing this, but I do
| still have non-trivial bootstrap scripts for macOS.)
| Benjamin_Dobell wrote:
| I use Homebrew, and am genuinely appreciative of the amount
| of effort all the contributors have put in. However, as far
| as package managers go, it's kind of awful.
|
| Homebrew _excels_ as a mechanism to install the latest
| software, if you don 't care about breaking things.
| However, traditionally a package manager's job is to ensure
| that if you've installed something, it'll continue to run.
|
| If you've ever updated readline via Homebrew, you can
| pretty much just watch everything burn.
|
| If you've ever tried to use an old version of Postgres,
| good luck. Particularly if you're wanting to mix and match
| versions of PostGIS.
|
| If you're running an old version of macOS, you're out in
| the cold. Although, I must admit, recently this seems to be
| handled much better.
| faitswulff wrote:
| Also any random operation can take 20 minutes to complete
| if you haven't used brew in a while.
| upbeat_general wrote:
| You can disable this but I agree, I hate it.
|
| This comment actually just spurred me to find this
| (https://gist.github.com/jb510/99f12b1ac70f1cf8b780)
| which may fix the issue of forgetting to manually update.
| indemnity wrote:
| I understand why they did it, but it's super annoying.
|
| Given the intervals between running Homebrew, you just
| know it's going to spin for a minute or two updating
| every damn time you try to use it, usually when you want
| something installed fast.
| cutler wrote:
| Seconded, port select is great as is port variant.
| blandflakes wrote:
| I find that MacPorts is a better citizen of my laptop, but the
| mindshare of homebrew means that brew will have both more
| packages and more up to date packages.
|
| And getting the tools team at work to vend both brew and
| macports seems malicious so I just suck it up there.
| brigandish wrote:
| I don't use homebrew (for many of the reasons found in the
| comments here and more) but this is why I do visit their
| repo[1] for a "formula" whenever I need something macports or
| pkgsrc can't supply me.
|
| [1] https://github.com/Homebrew/homebrew-
| core/blob/master/Formul...
| protomyth wrote:
| I think that's the key, MacPorts stays in its lane. I also
| like the variant mechanism. It makes it easy (much like
| OpenBSD flavors) to get what I want out of it.
| my123 wrote:
| No. MacPorts is so much better nowadays.
| dewey wrote:
| In what way?
| my123 wrote:
| Dependency management in Homebrew is nothing short of
| primitive or broken...
| somehnguy wrote:
| Not to mention that the recommended way of installing
| certain packages changes seemingly randomly sometimes.
| Python, PHP, OpenJDK are ones that I've specifically had
| issues with. It starts with finding some random blog post
| on Google that differs from every other blog post on
| Google about how to accomplish the install. Then you
| spend a bit looking for other references to see if the
| one you're following is the new way or the old way that
| won't work right anymore.
|
| I also very rarely update my Homebrew packages because
| there is no telling what will break half the time due to
| this.
|
| And the fact that simply installing a package force
| updates every other package by default! I needed a single
| tiny utility while on a screen share recently, I `brew
| install` it. 15 minutes later Brew was still figuring the
| world out and it ended up being faster to just find the
| utility on Github and download it manually to use while
| letting Brew do its thing in the background. Still no
| idea if it ever ended up installing...
|
| Don't get me wrong, I still think brew has been handy for
| me over the years. But I breathe a sigh of relief
| whenever I `apt-get` something on a Debian box and it
| behaves in a sane manner.
| bhaak wrote:
| Homebrew is what a package manager would look like if Apple was
| doing it.
|
| So quite limited in scope and not much configurable options and
| if you say that you need some features, they'll tell you you're
| doing it wrong.
|
| It is quite easy to install though and has a lot of packages
| but if you have specific needs that are unmet, you are on your
| own.
|
| It's more of a update manager than a true package manager.
| bacon_blood wrote:
| I disagree. Apple would spend the time to make universal
| binaries work (unlike homebrew, who has stated they won't
| support them). Not installing universal binaries has some bad
| implications for Rosetta for developers. Having mixed single
| processor binaries in PATH can cause architectures to switch
| unexpectedly for subprocess chains (like when running a build
| tool), or even get "bad CPU type" errors in some contexts if
| the wrong arch is first in PATH.
| bhaak wrote:
| Universal binaries matter most for closed source. With
| Homebrew being used for Open Source software it's by far
| not a priority for the generic user.
|
| The last years have shown clearly that Apple doesn't go out
| of their way to make things easy for devs if it doesn't
| helps their main client group.
| bacon_blood wrote:
| No. This isn't fixed by open source. Open source projects
| also do binary releases (see brew cask), and those need
| to be universal as well. Someone needs to build those
| universal binaries, and homebrew has decided to be
| incapable as a platform to do that by refusing to ship
| universal binaries.
|
| It is kinda mitigated for end users if you only run an
| x86 homebrew for the foreseeable future and never compile
| any software outside of homebrew, but that's a crappy
| answer.
|
| Universal means you can seamlessly switch between
| architectures as necessary. Split arch homebrew, however,
| means you should probably keep one of them entirely out
| of your path until you need it, as your arch will
| silently change if you have the wrong arch bin in path (I
| encountered this in the wild). Having the wrong arch bin
| first in your path will also result in a bad cpu type
| error if you force arch on any parent process e.g. with
| arch -x86_64 (I encountered this in the wild).
|
| Also, users expecting that their build tools will be x86
| also results in hacks like checking the cpu type sysctl
| and forcing ARM, which in any build tool is likely to
| break the ability to build x86 binaries (I encountered
| this in the wild in several projects).
|
| I've seen all of this in multiple open source projects. I
| had to stop using homebrew entirely for build tools as a
| result.
| my123 wrote:
| And MacPorts is what had/has Apple involvement actually.
| Wowfunhappy wrote:
| And, it does in fact support universal binaries.
| nicolas_t wrote:
| My experience with homebrew is that it doesn't deal well with
| multiple version of packages at the same time. For example, it
| doesn't like to keep outdated openssl in parallel, which is
| good from a security standpoint but can make it difficult if
| your job involves a lot of looking at antique codebases and
| help with updating them... It's why I switched back to macports
| after briefly testing it
| awakeasleep wrote:
| Can you explain exactly what you are describing:
|
| "it doesnt deal well with multiple versions at the same time"
|
| Also what system/os are you comparing to?
| ragnese wrote:
| Probably comparing it to MacPorts, which does allow
| multiple versions of the same packages to be installed
| simultaneously.
| nicolas_t wrote:
| I'm comparing to macports. I remember a brew update that
| removed an old version of openssl causing all of my older
| ruby packages to fail. Now I would definitely not use ruby
| 1.9.x in production but I sometimes do have to be able to
| run locally antique codebases that haven't been used in a
| long time. I was caught off guard because a simple install
| of an unrelated application with homebrew destroyed a big
| part of my work flow.
|
| Macports never did this and kept libraries side by side
| cleanly.
|
| Now, this is from the point of view of a software developer
| with a specific niche requirement. For normal users, from a
| security standpoint, it would most likely make sense to
| remove old versions of openssl.
| cutler wrote:
| Why not just use rbenv with a $HOME/.gem directory. Much
| simpler as Ruby versions come with their own openssl.
| nicolas_t wrote:
| I was using rbenv, but try installing an ancient version
| of ruby through rbenv, I have never been able to get it
| to work without having the existing openssl library in my
| system (not an issue with newer versions)
| cies wrote:
| Nix(OS)?
| capableweb wrote:
| Don't have a ton of experience with either macports or
| homebrew but pretty much any package manager deals with
| running multiple different versions at the same time, or
| projects using different versions of the same dependency,
| without getting in your way. Biggest/most famous example I
| guess would be javascript/npm/npm inc registry.
| masklinn wrote:
| Nope, completely different "package manager". Homebrew
| and Mac ports are more similar to apt or yum or Pacman,
| and those often do not provide for running multiples of
| the same software except in specific edge cases where
| sauf software can be argued to be different from itself
| e.g. python2/3, they sort of things.
| lucideer wrote:
| Have never used MacPorts, but based on your comment, and a few
| of the replies, I may give it a try. Homebrew is quite painful
| in many ways, particularly when managing multiple versions of a
| package (MySQL & PostgreSQL especially has had a lot of issues
| for me).
|
| On the other hand, what I will say in favour of Homebrew is
| that its popularity does make life much easier as there's so
| much software available on it. Even very small / niche / new
| projects will often have a Homebrew package.
| jimbokun wrote:
| This Homebrew MacPorts discussion is giving me a MySQL
| Postgres vibe.
|
| The former is more popular and easier to get started with and
| bigger community, but the latter is higher quality and better
| designed.
| zymhan wrote:
| You would probably enjoy the `port select` command in
| Macports to pick the version you want to launch when
| invoking, say, "python".
|
| Macports is also good about naming different versions, so you
| can have python-34, python-37, and python-29 installed
| together.
| lawnchair_larry wrote:
| Yes
| newscracker wrote:
| Here's a blog post from April 2019 on package managers on
| macOS. [1] The author, saagarjha (who also comments here
| regularly), switched from homebrew to MacPorts. A more current
| update to this post would probably be more helpful.
|
| In my limited experience, I've tried homebrew a few times, but
| found it a bit cumbersome with the "no sudo" requirement.
|
| [1]: https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-
| pack...
| jimbokun wrote:
| This is very interesting, and maybe sheds light on why Google
| decided not to hire Max. There seems to be some consensus
| that MacPorts has the better architecture, while Homebrew has
| been better at responding to users, even according to Max
| himself.
|
| For Google, it's likely the former is more important than the
| latter for a lot of their projects. An architecture that
| doesn't scale or doesn't always do the right thing or
| sometimes messes up data, can be catastrophic at the scale of
| Google.
| hombre_fatal wrote:
| > maybe sheds light on why Google decided not to hire Max.
|
| This is the sort of myths we hold about interviews. That
| the company is doing such deep dive on us that they are
| reading our Github commits and considering the trade-offs
| of MacPorts vs. Homebrew architecture.
| lucideer wrote:
| > _found it a bit cumbersome with the "no sudo" requirement_
|
| This is one of the few features I do love about Homebrew.
| Does MacPorts have a "no sudo" mode or does it just let all
| packages run rampant on your system?
| Wowfunhappy wrote:
| The problem is that the way they do it breaks the UNIX
| model. /usr/local is common to all users, but Homebrew
| gives it the current user's permissions. This consequently
| creates weirdness if you actually use multiple user
| accounts.
| kstrauser wrote:
| Fair point, but I bet the number of Macs in the wild
| shared by multiple people who would want to run Homebrew
| are vanishingly small.
| Wowfunhappy wrote:
| Sure, but it's a native feature built into the Mac
| platform. If software is going to prevent that from
| working properly, then that should be communicated very
| clearly.
| kstrauser wrote:
| Is this an issue in practice in more than a rounding
| error number of Macs? I'd bet lots of money that the vast
| majority of developers (that is, people likely to be
| installing Homebrew in the first place) are using
| effectively single-user systems.
| lucideer wrote:
| Exactly why I prefixed my comment with "this is one of
| the FEW features I do love". The exact technical approach
| Hombrew ends up taking to a lot of problems always seems
| not quite right whenever I've dug a little deeper.
| nrclark wrote:
| I'm not sure about unprivileged installs, but MacPorts is
| very good about sticking to /opt/local. It doesn't ever
| place anything (including config files) outside of
| /opt/local. So you get pretty good assurance that it won't
| trash your system too badly.
| Wowfunhappy wrote:
| And, they actually enforce this with a specially
| provisioned MacPorts user. So although it requires sudo,
| MacPorts installs don't actually run as root.
| mikepurvis wrote:
| My understanding is that the whole reason for running the
| outer commands as sudo is so that the inner build/install
| commands can be run in a far more restricted environment.
| Because brew runs as your own user, every build has access
| to your entire home directory, the whole homebrew folder,
| etc. It's nice in principle to not have to "trust" any of
| homebrew with sudo, but in reality, the trust surface area
| is far larger. With MacPorts, you only have to trust the
| tooling, not the individual package definitions (though
| obviously the calculus does change slightly when bottles
| are in the picture, since then the build/install is
| happening elsewhere).
|
| Relevant: https://xkcd.com/1200/
| lucideer wrote:
| > _every build has access to your entire home directory,
| the whole homebrew folder, etc._
|
| Isn't this just whataboutism though? Yes that's
| potentially a problem but it's an orthogonal one. So not
| really relevant to this discussion.
|
| A hypothetical solution to the problem in the linked XKCD
| would be to somehow prevent an attacker accessing your
| bank, it would not be to allow an attacker to install
| drivers without your permission.
|
| > _With MacPorts, you only have to trust the tooling, not
| the individual package definitions (though obviously the
| calculus does change slightly when bottles are in the
| picture, since then the build /install is happening
| elsewhere)._
|
| This calculus change is basically my primary concern.
|
| Of course it's not ideal that Homebrew apps have access
| to everything in my Home, but that's still better than
| them having access to everything on my system.
| mikepurvis wrote:
| The point is that they wouldn't. Only the core brew
| utility would, because in almost all cases, it would be
| immediately downgrading itself to either a dedicated
| homebrew user, or in the case of builds, to a nobody user
| who does its work in /tmp and only has write access to
| the one install path it has been allocated (which is then
| chowned to the brew user afterward).
|
| The fundamental issue is that the POSIX user model has no
| concept of one user being strictly less privileged than
| another, and therefore all impersonations require root.
|
| And note that the situation on Debian and Ubuntu is much
| worse than either of these models, because every package
| has an opportunity to run arbitrary commands as root as
| part of the postinstall and at various other times during
| the package lifecycle. So basically you've owned yourself
| the first time you add some user's random PPA and run
| `apt dist-upgrade` to pull new versions from it.
| brigandish wrote:
| > inner build/install commands can be run in a far more
| restricted environment
|
| As I seem to remember it, homebrew rankles if you use
| sudo but also complains if you're not an admin account,
| which struck me as ironic and irritating all at once, and
| means that xkcd isn't quite as relevant.
| optimuspaul wrote:
| I am confused by this. sudo seems like a far larger
| surface area than running as me. If it's just me then
| it's just me, but if it's sudo, then it's the entire box.
| mikepurvis wrote:
| It depends whether you trust the tool maintainers more
| than the package definition maintainers. I certainly
| would. But don't take my word for it-- here's a MacPorts
| developer explaining the sandboxing of builds:
|
| https://apple.stackexchange.com/a/106942
| Wowfunhappy wrote:
| > Directories listed in multiple users' $PATH that are
| writable without superuser privileges can be used for
| attacks (e.g., by placing a sudo binary that will log the
| password there). The same can be done by malicious
| software running as your user in order to get your
| password
|
| Yikes. That particular attack did not occur to me.
| lucideer wrote:
| Thank you for this link. This is the first robust
| argument for running as root that I've seen, and
| completely upends my assumptions.
|
| I'd been considering trying macports but this has
| convinced me.
| desmap wrote:
| Not really on-topic but am I the only one? I stopped developing
| locally, my notebook is just a thin client ssh'ing into a remote
| dev server. I get all amenities like developing on the production
| os, no awkward package managers, 1 GBit up and down--always and
| anywhere and Docker pushes within few seconds.
| sz4kerto wrote:
| VSCode made all this so much more convenient.
| warent wrote:
| Not to be the eternally dissatisfied user, but I've never gotten
| homebrew to work properly on a machine with multiple users. It
| only works for 1 user at a time, even if it's owned by a user
| group that both users belong to.
|
| Has anyone else had that problem or found a solution?
| Hackbraten wrote:
| Homebrew maintainer here. I do suffer from the multi-user
| problem myself, and happily work around it on my own Mac by
| maintaining a dedicated `brew` user, to which the actual users
| have passwordless sudo rights.
|
| I've taken notes of my workaround, if it helps:
| https://gist.github.com/claui/ada85e696029cfa8cba9b91723ce2e...
| warent wrote:
| Interesting! Thank you!
| _rend wrote:
| Along with Hackbraten's answer -- I don't know if this would be
| more or less work for you but would a per-user Homebrew
| installation help? I don't have any multi-user machines but for
| years I've kept my Homebrew installation in ~/Homebrew, where I
| have complete ownership of it. (Really you can install Homebrew
| in any directory) Or would the space/compilation cost be
| prohibitive?
|
| Not a Homebrew maintainer, just a satisfied user.
| Hackbraten wrote:
| On macOS, one major drawback is that if you use a non-
| standard installation directory for Homebrew, you can no
| longer install binary packages and everything is compiled
| from source.
|
| If you can live with that, you should be fine though.
| kyleblarson wrote:
| Still love this tweet:
| https://twitter.com/mxcl/status/608682016205344768?lang=en
| TameAntelope wrote:
| I am fascinated by the polarizing nature of Homebrew on HN. I've
| used both MacPorts and Homebrew, and I think the only reason I
| switched to Homebrew years ago was that Homebrew didn't try to
| install stuff at a system level, which felt more in line with a
| package manager that wasn't integrated into the OS.
|
| But I'm sure MacPorts is fine still. Why are people so strongly
| opinionated about this, particularly on the pro-MacPorts side?
| Nothing I've seen in the comments so far jumps out as an obvious
| source of the passion.
| ThankYouBernard wrote:
| HN, and the open source world in general, has no sense of
| perspective. I mean, even as someone who once built my own
| Linux system from scratch I don't understand why there are
| death threats connected to something called "systemd".
|
| It's a bubble that most of us grow out of once we discover that
| there is more to life. Apparently some people never do.
| jakeva wrote:
| People are strongly opinionated about _everything_ if the
| internet forums are any indication. I think the truth is more
| like opinionated people speak up, and most people just enjoy
| life.
| Klonoar wrote:
| It's ideology. They're both fine at what they do at this point,
| and you really only need to choose based on what has the
| packages you need.
|
| For reference, I use MacPorts. I often tell new users to just
| use Homebrew. It really just doesn't matter.
| sevencolors wrote:
| I wasn't even aware it was polarizing. Have enjoyed using it
| for the past 6 years and never thought much about it. The
| comments of "it sux", "worst thing ever" feel very petulant.
|
| Love that i can install/update the packages i might need and
| get on with my day.
| einpoklum wrote:
| I'm not familiar with Homebrew.
|
| Is it the kind of thing I could use to manage packages in my own
| directory as a non-root user (on Linux)?
|
| If so, will it be able to base itself on what my distribution
| offers, or will it build things up from scratch with its own
| toolchain packages?
| Hackbraten wrote:
| > Is it the kind of thing I could use to manage packages in my
| own directory as a non-root user (on Linux)?
|
| Yes, exactly.
|
| Not sure what exactly you mean with your second question
| though.
| bartvk wrote:
| If you wish to donate, then you can do the creator a favor:
| https://mxcl.dev/#donate
| latexr wrote:
| Without taking away from Max Howell, he hasn't been with
| Homebrew for years. Anyone is still free to donate to him
| (naturally), but those will have no impact on Homebrew. To
| donate to Homebrew, see
| https://github.com/Homebrew/brew#donations
| bartvk wrote:
| Great point, thanks!
| bluedino wrote:
| I wrote a post critical of Homebrew a few days ago, but it is a
| really great project.
|
| I first used it 10 years ago when I was doing Rails development.
| It was kind of a pain to get everything setup on our development
| machines, installing new bits and making sure other bits were up
| to date.
|
| After using brew it made our lives much easier. Combined with
| Rubygems it made every other platform and language look silly.
| jrochkind1 wrote:
| I don't understand if there are implications to upgrading to
| homebrew 3.0 for me a lowly user. Will things break? Will I lose
| access to formulae that haven't yet been upgraded to work with
| brew 3.0?
|
| Should I upgrade right away or hold off for a while? Which is
| least likely to interupt my workflow in which I count on brew
| just working?
| mikkelam wrote:
| i migrated with brew bundle in a fresh install and it worked
| wonderfully.
| jrochkind1 wrote:
| i've never even heard of "brew bundle". Not sure if you're
| suggesting I need to do a "fresh install", or how I'd do
| that! But I can google!
|
| I guess I was sort of expecting some migration instructions
| with the release notes...
| romellem wrote:
| I agree. Any type of "migration guide" that I should be aware
| of?
|
| They mention that ["various methods have been deprecated,
| disabled and removed"][0] but its hard to read from that PR
| exactly which commands no longer work.
|
| Thanks for all the great work on homebrew!
|
| 0: https://github.com/Homebrew/brew/pull/10397
| sudhirj wrote:
| Homebrew generally doesn't do breaking changes. I haven't
| experienced any disruption... this version seems to be a
| headliner for full Apple Silicon support. Even if there are any
| changes, `brew doctor` usually handles things for you.
| jrochkind1 wrote:
| Thanks! I know homebrew doesn't generally do breaking
| changes, but they also don't generally do major version
| releases, which can sometimes be a signal for breaking
| changes, thus my concern!
| philistine wrote:
| I'm a lowly, very dumb user too. I ran Brew doctor and realized
| that the default installation is now in /opt/homebrew (which to
| my dumb ears seems like it solves most complaints I've heard
| about Homebrew).
|
| Since Homebrew threw a warning at me with my old install in
| /usr/local, I completely uninstalled and reinstalled Homebrew
| 3.0.
| telaelit wrote:
| Thank you, Homebrew maintainers, for all your hard work. One of
| the very first things I've done on new computers is install
| Homebrew, couldn't live without it :)
| zdw wrote:
| As someone who has used MacPorts for a long time (it started
| years before Homebrew was created), I wonder if anyone whose used
| both for a while can compare the two.
|
| MacPorts has a "patch it to work with macOS" mentality that
| seemed much more needed in the early 00's when PowerPC/big-endian
| and other Mac or BSD specific differences were more common,
| whereas Homebrew tends to want everything to come unpatched from
| upstream, which does seem a bit cleaner.
|
| I think I'm getting thrown off by stories like
| https://news.ycombinator.com/item?id=26017852 and horror stories
| about upgrades or migrations - I've been doing a 'port list
| requested > file', copying that file around, then 'port install
| `cat file`' to get the same setup on a new machine for quite a
| while.
| bilekas wrote:
| > The new HOMEBREW_BOOTSNAP environment variable allows the use
| of the Bootsnap gem to speed up repeated brew calls
|
| Very nice.. Can't wait to do the numbers on this!
| [deleted]
| guytv wrote:
| Homebrew is great!
|
| I love it.
|
| My only complaint is that I never remember 'brew upgrade' from my
| 'brew update'. which is which.
| [deleted]
| rafaelturk wrote:
| Homebrew is amazing!
| mkrishnan wrote:
| 'sudo' installing it sucks
| SomeHacker44 wrote:
| I will likely never move off 10.14 due to hardware and 32-bit
| software requirements. When will homebrew stop supporting this? I
| would have stayed on 10.12 but homebrew stopped working well on
| that after it became unsupported.
| Hackbraten wrote:
| We typically support N-2, N-1 and N, which means you'll be fine
| with Mojave until Big Sur's successor comes out.
| 0xCMP wrote:
| Brew is great. I've switched to using Nix as much as I could but
| most "Apps" aren't supported yet where `brew install --cask` has
| it right away.
|
| Always nice to know Brew will always have the latest version
| around. The only problem with that ends up being that if you use
| brew for development dependencies like Node or Python you can't
| manage multiple versions. Nix being the most powerful in this
| area.
| sneak wrote:
| I've switched to Nix and never looked back, thanks to Homebrew
| embedding spyware into the package manager. I keep my non-
| system apps in ~/Applications and back them up with the rest of
| my files.
| Hackbraten wrote:
| > spyware
|
| Please.
| sneak wrote:
| Apps that silently transmit your activity without consent
| are spyware. It's an objective evaluation.
| cwxm wrote:
| I can't even begin to imagine how much value Max Howell (creator
| of Homebrew) has added to the world. It's the recommended package
| manager at every place I've worked at and saves so much headache.
|
| I use Linux at home and package managers like AUR are great, but
| macOS is where the users are.
| foobarian wrote:
| I only use it because IT forces Macs down our throats. It's
| understandable, the hardware is light years ahead of any other
| manufacturer, along with the OS support. But I just do the bare
| minimum of setup to get VNC and SSH working and GTFO to a
| proper remote dev box.
| djrogers wrote:
| > But I just do the bare minimum of setup to get VNC and SSH
| working
|
| Lucky for you those are both fully supported out-of-the-box,
| and have been for a couple of decades. Sounds like your IT
| team is forcing the right solution down your throats.
| foobarian wrote:
| It's a matter of opinion and the opiner I guess. To go from
| factory OS to be able to run what's on the server side is
| not simple, and has been brittle. For me a better solution
| would be a Linux native box with the same distro &
| configuration to be able to avoid the VNC remote
| altogether. But for the company, perhaps that kind of
| solution would have costs in support and maintenance that
| would make it a bad choice.
| lloeki wrote:
| You would have been happy with ArchMac[0] then.
|
| Unfortunately after a dozen or so years as sole maintainer and
| user I dropped it a month ago[1].
|
| If anyone wants to take over just reach out.
|
| (not in the post but I had to pull the DO storage because I was
| severely out of cash, I still have the packages locally)
|
| [0]: https://www.archmac.org/
|
| [1]: https://lna7n.org/2020/01/06/pulling-the-plug-on-
| archmac.htm...
| yulaow wrote:
| I don't think homebrew has more user than say apt or pacman.
| Maybe there are a bit more people running osx than linux, but
| much of them are not devs or "power users" and never run
| homebrew.
| toyg wrote:
| Apt I can agree, it's still the gold standard of package
| manager and powers the most popular distributions out there
| in bajillion cloud instances.
|
| Pacman, erm what? Arc is a niche of a niche. I'd bet Alpine's
| package manager sees more action than that - let alone
| yum/rpm.
| wejick wrote:
| I have friends working on debian based distro, following
| their discussions on a lot of dpkg packaging intricacies is
| crazy. However that also means it's mature piece of
| software that handle many cases under the sky of software
| packaging and distribution.
| zests wrote:
| Besides, we all know that pacman is nothing compared to the
| one true package manager, portage.
| amw-zero wrote:
| Does it make homebrew less valuable if there are other
| package managers for other OS's that have more users?
| Jestar342 wrote:
| The very premise of this (sub)thread is one of "more users
| == providing more value" so .. yes, for this conversation,
| it matters.
| toyg wrote:
| Was it him who was turned down by Apple and Google, _after_ he
| built homebrew...?
| hello_moto wrote:
| We need to move on from this particular gossips/memes.
| ksec wrote:
| >turned down by Apple and Google
|
| It was Google. Because he didn't know what a binary tree was
| or something similar during the infamous Whiteboard test.
|
| But I mean it make perfect sense. Google is all about
| building AI, ML, Algorithm, K8S etc. Complexity _is_ their
| KPI, usefulness is not.
|
| So may be it isn't so much a bad thing after all. He wouldn't
| have fit in.
|
| Edit: I guess the tone didn't shine through. The "all about"
| is a figure of speech. A more accurate wording would be, in
| my opinion Google doesn't know how to built great "user"
| Product.
|
| And I may also include some of the Google hiring practice [1]
| that were brought to twitter.
|
| [1] https://twitter.com/shaft/status/1355696154990628864?s=20
| openstep wrote:
| Google is not all about that
| tinyhouse wrote:
| I completely disagree with this comment. Not to mention the
| comments to his Quora answer, suggesting he should try a
| TPM position... people are so out of touch.
|
| The main problem is that he went through the standard
| interview process. To prevent bias you need to maintain a
| consistent interview process and bar. All interviewers in
| big tech have annual trainings about this. If someone
| underperforms it's considered bad judgment to be inclined
| based on who the person is or their past experience. This
| is to prevent cases like "he didn't do well but we should
| hire him anyway because he graduated from Stanford".
|
| When you have someone who is an exception you shouldn't
| hire them via the standard interview process. Maybe Google
| didn't think he's an exception. But the reality is, the
| vast majority of Google engineers wouldn't be able to build
| something as successful from scratch like he did. It
| requires more skills than just being a good engineer. They
| could've found him a role that fits his skills. When FB
| hired Yann Lecun I'm sure they didn't ask him how SVMs
| work. (not saying they are on the same level, clearly not,
| just an extreme example)
|
| Another possible option is that he came across too arrogant
| in more than one interview and the hiring committee was
| worried he wouldn't be a good fit culturally.
| throwaway29831 wrote:
| This seems off - based on most interactions Googlers and
| especially ex-Googlers, arrogance must be a practical
| requirement to work there.
| ghaff wrote:
| That sounds about right. I'm guessing the last time I was
| hired it wouldn't have happened through a "standard
| interview process" because my background is somewhat
| eclectic and I frankly probably wouldn't tick enough of
| the boxes for obvious positions I might have been
| inclined to apply for. But people knew me, a job
| description was written for me, and here I am quite a few
| years later.
| capableweb wrote:
| > Google is all about building AI, ML, Algorithm, K8S
|
| No, no big companies are "all about" anything, there is so
| many different areas of work, that rejecting a person
| because the company is "all about" X, doesn't really apply.
| If they wanted to work with him, they would have made it
| work. But they didn't, so they didn't.
| yokaze wrote:
| You are right, certainly there could be a fit, but
| finding the right place for someone implies that the
| hiring decision has already been made.
|
| For me, it sounds like he applied for a standard software
| developer job through the standard process. Would you
| hire someone _as a software developer_ without knowing
| the basics?
|
| From that resume, I would see him rather in a product
| owner role or some other full or semi-management
| position.
| pydry wrote:
| It also made sense that they'd make an absolute dogs dinner
| of golang package management after turning him down.
|
| Some things are not in google's DNA.
| simias wrote:
| I think golang's handling of packages makes a lot of
| sense... if you're Google, and you have a huge monorepo
| anyway.
|
| I think this reasoning explains a lot of my frustrations
| with Go: it's Google's language that they kindly let you
| use, it didn't grow organically within many communities
| and companies across a whole range of use cases and
| codebase sizes.
|
| You have a similar thing with git, it was the kernel's
| VCS that you could also use if you wanted, but especially
| early on it was rather hostile if you didn't actually
| need to maintain a gigabyte-sized monorepo with hundreds
| of third-party contributors mailing patches to various
| subsystem maintainers that would then have their branches
| merged into the mainline. Fortunately git's usability has
| improved a lot since then.
| ericmay wrote:
| Yep. And I don't know the story and certainly wasn't there -
| but technical prowess alone doesn't get you the job. And
| honestly he may not be a good fit. Is he going to want to fix
| bugs or work on Google's schedule and have a boss? Some
| people aren't cut out for the work lifestyle.
| Jestar342 wrote:
| Yes, he posted more information in an answer on Quora[1] to
| clarify why he felt he was turned down.
|
| [1]: https://www.quora.com/Whats-the-logic-behind-Google-
| rejectin...
| CydeWeys wrote:
| > But ultimately, should Google have hired me? Yes,
| absolutely yes. I am often a dick, I am often difficult, I
| often don't know computer science, but. BUT. I make really
| good things, maybe they aren't perfect, but people really
| like them. Surely, surely Google could have used that.
|
| Actually, no. There's no level of rockstarness that excuses
| being a dick and difficult to work with. That kind of
| attitude can turn a whole team's culture sour and result in
| way more damage than any one person can make up for through
| their individual contributions.
|
| It's clear from reading his thoughts on the matter _why_
| Google didn 't hire him, and it's also clear he still
| doesn't understand why either.
| cromka wrote:
| Absolutely this. I sense no work ethic, no humility ("I
| make really good things"). This, from my experience,
| usually correlates with an overgrown ego and
| unwillingness to confess to a mistake allowing to act
| quickly to mitigate the side effects. So when it actually
| happens the damage can be catastrophic.
| plorkyeran wrote:
| Yeah, my takeaway from _his_ telling of the story was
| that he is someone I would give a Strong No to, and not
| because of anything related to his CS ability. The fact
| that he wrote that after an unsuccessful short tenure at
| Apple where he ran into the exact same problems as he
| would have at Google yet still thinks Google should have
| hired him just reinforces that.
| worker767424 wrote:
| > I am often a dick, I am often difficult, I often don't
| know computer science, but. BUT.
|
| I'll stop him right there. Definitely not googley.
| bryanrasmussen wrote:
| a dreaded quora question answered by Max Howell -
| https://www.quora.com/Whats-the-logic-behind-Google-
| rejectin...
| one-punch wrote:
| I use nixpkgs and home-manager for a consistent package
| management and configuration across MacOS and Linux (NixOS),
| which others also reported great success [1]. As noted in the
| article [1], home-manager has a steeper learning curve, but is
| much more powerful (e.g., supports providing development
| dependencies and environment, or even extend to Ops).
|
| For the interested, search for some variants of "homebrew home-
| manager nix", and you may find lots of resources [2][3][4].
|
| [1]: https://lucperkins.dev/blog/home-manager/
|
| [2]: https://www.softinio.com/post/moving-from-homebrew-to-nix-
| pa...
|
| [3]: https://wickedchicken.github.io/post/macos-nix-setup/
|
| [4]: https://dev.to/louy2/use-nix-on-macos-as-a-homebrew-
| user-22d
| soraminazuki wrote:
| I started using Home Manager long after I adopted Nix. I must
| say, I should've used it far more earlier on. With the power
| of the Nix language, Home Manager gives me so much more
| control and customizability over packages that just can't be
| provided with traditional package managers.
|
| While it takes some learning to leverage the full capability
| of Home manager, it's also easy to get started. People new to
| Nix can start out with a basic configuration specifying a
| list of packages to install and then gradually move to a more
| capable configuration as they learn more.
| peteretep wrote:
| Contrarian view here: brew fucking sucks. It's the worst
| package manager I've used for doing random unwanted updates at
| odd times. Someone else would have filled the void if homebrew
| hadn't shown up, and it would hopefully have been better. I
| hate that brew is good enough that it's got some kind of local
| maximum such that there's no replacement forthcoming. There, I
| said it.
| [deleted]
| [deleted]
| jacobsenscott wrote:
| brew is an amazing achievement. It doesn't do random unwanted
| updates at odd times. It doesn't do anything at all unless
| you run run it. And it tells you want it will do beforehand.
| Nobody would have "filled the void" - building software isn't
| a zero sum game. If someone had something better they would
| have continued to work on it and it would have "taken over".
| There, I said it.
| qntty wrote:
| What do you mean by random unwanted updates? As far as I
| know, the only way to update is by running brew upgrade.
| stonesweep wrote:
| To codify both replies to yours as an outsider who watches
| macOS coworkers struggle: brew is akin to running Arch,
| where the concept is latest-tagged-release of any given
| software.
|
| The newest version of X introduces a feature which has a
| need of Y library (dependency) >= n+1, where n is your
| already installed version. It just so happens that Y is
| shared between 3 applications; so if you upgrade Y to
| satisfy X, you now have to recompile/upgrade (depending on
| details) A, B and C as well to use the newly updated
| version of Y.
|
| Arch (and other rolling releases) do/does this every day,
| it's just that the work is offloaded to upstream packagers.
| Brew is more "AUR-like" where it's all down downstream on
| your own system, so you get to deal with the work and churn
| through the recompiles yourself.
| Hackbraten wrote:
| > Brew is more "AUR-like" where it's all down downstream
| on your own system, so you get to deal with the work and
| churn through the recompiles yourself.
|
| I don't see how Homebrew would be similar to AUR.
|
| Unlike AUR contributors, Homebrew maintainers curate the
| packages, test them, monitor upstream projects for
| updates, build and upload binary packages and do their
| best to support users when anything breaks.
|
| Anytime a Homebrew user installs a formula from homebrew-
| core and the system starts to (re-)compile, almost
| certainly something is wrong.
| stonesweep wrote:
| It depends on the formula, designs and maintainers of
| them - we run an internal tap and some items are casks,
| some are bottles and some are compile as you go. It just
| depends on what that widget is and does, and in some
| cases there are tools which are broken on latest-tagged
| releases and people have to pin older versions or using
| git HEAD for (some period of time) until the tagged
| released is fixed upstream. (we're looking at you,
| sshuttle-who-deprecated-remote-
| python2-in-v1.0-thru-1.0.4-and-broke-lots-of-workflows-
| with-jumphosts)
| regulation_d wrote:
| one time i ran "brew upgrade ffmpeg" which somehow forced a
| major version bump of postgres.
| [deleted]
| juandazapata wrote:
| I installed awscli and somehow emacs ended up installed
| in my system.
| w0m wrote:
| Personally; only issue i tend to have is that when I
| install X, it breaks Y forcing reinstallation of
| ~everything. What should be a small install ends up taking
| 30m of cleanup.
|
| Entirely likely it's user error on my part; but also
| problem I haven't really had with other 'nix package
| managers.
| [deleted]
| Doctor_Fegg wrote:
| Which isn't funny when Y is Postgres and your database is
| no longer readable post-upgrade. Happened to me.
| peteretep wrote:
| I ran `brew install graphviz` today and caught it running
| an upgrade of zeromq
| jeremycw wrote:
| I ran `brew install graphiz` a week ago and got a new
| major postgres version.
| ilikepi wrote:
| For some time now, in the default configuration, `brew
| upgrade` is run automatically any time you run `brew
| install`. You have to set HOMEBREW_NO_AUTO_UPDATE to
| disable this behavior.
|
| EDIT: whoops, that was incorrect. It's actually `brew
| update` that is run automatically, which updates Homebrew
| itself plus all of its formulae. However, I think often the
| effect can't be similar. If formulae are updated, and the
| new package you're trying to install shares a dependency
| with other packages, the dependency will be automatically
| updated as part of the install process. I'm not sure if
| this can also trigger an update of an existing leaf package
| though.
| bargsteen wrote:
| Yes, figuring this out I created an alias a few months
| ago. #LifeImproved :D
|
| Add this to your .zshrc or equivalent (f for fast):
|
| alias brewf="HOMEBREW_NO_AUTO_UPDATE=1 brew"
| martpie wrote:
| The usual non-productive rant.
|
| What prevents you to do it better then? What prevent you from
| forking it? Sharing improvement ideas? Contributing to the
| project?
|
| "It sucks" doesn't help anyone understand your frustrations
| and does not serve the message you're trying to share (let
| this one be valid or not).
|
| Also, as everything that is open-source/free: if you hate it,
| don't use it, that's it. And let the people who appreciate it
| be productive and build awesome tools with it.
| w0m wrote:
| > What prevents you to do it better then? What prevent you
| from forking it? Sharing improvement ideas? Contributing to
| the project?
|
| I think ~everything he stated is generally assumed true. I
| use Brew installed software every single day, and
| appreciate it. That doesn't put it above criticism though.
| bastardoperator wrote:
| There is no criticism in their statement though, just a
| generalized opinion/rant that doesn't point out single
| issue and is factually inaccurate.
| zimpenfish wrote:
| > doesn't point out single issue > is factually
| inaccurate.
|
| I think these two might be somewhat contradictory.
| bastardoperator wrote:
| I don't, he said someone else would have filled the void,
| there was no void considering this project came after
| macports and fink
| bakedbeanz wrote:
| "brew fucking sucks" is just whining, not reasonable
| criticism IMHO
| biktor_gj wrote:
| Not parent, and I'm not going to say it sucks, the project
| takes a lot of work from a lot of people and I ain't the
| one pissing on other people's work, it definitely could use
| some improvements syntax wise though, What was it, brew
| install? Brew cask? Oh , now is brew cask install... or was
| it brew install --cask?
|
| I get the analogy, but being a package manager, but was it
| really that bad to use 'brew install', 'brew update', and
| 'brew upgrade' for everything?
|
| And it's true that it is a little frustrating at times when
| you don't use it for a while, you 'brew install xx' and
| wait 4 minutes until "Updating homebrew" finished with its
| dozens loops between shells, ruby etc doing its stuff
| (which I assume is refetching repos, but couldn't know it
| from the output)
|
| I use it because it's the most common thing for mac, but I
| miss APT and DNF everytime I use it, not going to lie
| MarkyC4 wrote:
| Homebrew (and CocoaPods, perhaps famously) uses github as
| a CDN for their package listings, syncing the git repos
| likely takes the most time here
| latexr wrote:
| > I get the analogy, but being a package manager, but was
| it really that bad to use 'brew install', 'brew update',
| and 'brew upgrade' for everything?
|
| That's how it works now. You only need `--cask` for
| (rare) disambiguations.
|
| Homebrew Cask started as a different project (casks and
| formulae are still inherently different), so not having
| `brew cask` only became viable after the two projects
| merged.
|
| > it is a little frustrating at times when you don't use
| it for a while, you 'brew install xx' and wait 4 minutes
| until "Updating homebrew" finished
|
| Use `HOMEBREW_NO_AUTO_UPDATE=1`. Just don't open an issue
| if something breaks and you didn't update beforehand.
|
| > which I assume is refetching repos, but couldn't know
| it from the output
|
| `--verbose`.
| senjin wrote:
| Do you mean apt or apt-get or apt-get install or was it
| apt-install --get?
| Schalter wrote:
| even on old infrastructure its already apt and nothing
| else anymore. So they advanced.
| FireBeyond wrote:
| No, it's really not. apt-get works just fine on my
| current Ubuntu instances.
| [deleted]
| curun1r wrote:
| > What prevents you to do it better then?
|
| The mindshare of nearly the entire community that develops
| software for the Mac. Homebrew, the tool, is inferior to
| several other options, but developers of software treat it
| as the one true package manager on Mac. It's so frustrating
| to see projects offer it as the only supported way to
| install their software on Mac apart from building it from
| source.
|
| Your question reads like "What prevents you from building a
| better social network than Facebook?" response to
| criticisms of that platform. And the answer is that in a
| tool like Facebook or Homebrew, all the value is in the
| ecosystem. Building a better tool is useless until everyone
| is using it. And no one will use it until everyone else is
| using it. It's a classic network effect, and it inhibits
| viable competition.
| Zarel wrote:
| I think the big difference is that Homebrew, unlike
| Facebook, is open-source (and doesn't have a huge trove
| of data to protect, leading them to go after third-party
| clients).
|
| It's plausible that you could just write a front-end that
| keeps using the same remote package repository, that
| fixes everything you complain about.
|
| I suppose it depends on what exactly your complaints are,
| but most of the complaints here (CLI, auto-update, etc)
| seem like they could be addressed with just a client
| fork.
| overgard wrote:
| > What prevents you to do it better then? What prevent you
| from forking it? Sharing improvement ideas? Contributing to
| the project?
|
| Time?
|
| > Also, as everything that is open-source/free: if you hate
| it, don't use it, that's it. And let the people who
| appreciate it be productive and build awesome tools with
| it.
|
| This is such an unhealthy attitude. Just because something
| is free doesn't make it above criticism. Also doesn't mean
| that the maintainers don't benefit from their projects even
| if there isn't direct compensation (more career
| opportunities, visibility, etc.) This idea that we need to
| walk on eggshells around anyone that does any volunteer
| work is kinda absurd.
| FemmeAndroid wrote:
| > Just because something is free doesn't make it above
| criticism.
|
| What was being responded to wasn't criticism. It was
| whining without any substance.
| Gelob wrote:
| +1. i like it but yes if i dont use it everyday and 2 weeks
| later go to brew install something, omg it has some gigantic
| update to do before i can brew install anything.
| dylan604 wrote:
| so, you don't do a 'yum update' before installing software
| on your system (or 'apt-get update' or whatever)? Are you
| also the type of person that refuses to update system
| software because "it takes too long, and I'm too busy"?
| ratww wrote:
| Not GP, but I do it quite often, but not every single
| time. Also yum/apt/etc updates are way faster and much
| more responsive than brew.
| Schalter wrote:
| I have the same issue and for me there is a simple
| difference:
|
| I probably use homebrew for a handfull of tools, in
| debian etc. my packagetmanager manages everything.
|
| Its not a huge issue but the thought of 'ah shit i need
| to run update' comes with 'that will be slow'
| eknkc wrote:
| I generally don't do an apt update before installing a
| package that I needed at that moment.
|
| However I do full update / upgrades when it is convenient
| for me.
|
| That's the point.
| wpm wrote:
| No, I don't like forced 5 minute stops to my work.
|
| Yes, I'm the type of person who only updates on my
| schedule when notified, or when I need something.
|
| These little tools installed by home brew aren't just
| little tools, they're dependencies for whatever else
| they're used in. The fact that I need package "X" doesn't
| mean I want package Y, something entirely unrelated,
| updated without my consent.
|
| It's MY fucking computer. Let ME decide what software
| gets installed on it and when.
| pwinnski wrote:
| That _is_ frustrating, but fortunately
| `HOMEBREW_NO_AUTO_UPDATE=1` will take care of it. Then you
| have to remember to update every now and then yourself,
| though.
| m000 wrote:
| Would you happen to know how to disable upgrading
| unrelated packages?
|
| I often do `brew upgrade X`. Brew indeed does what is
| necessary to upgrade package X + deps. But then goes on
| and starts upgrading unrelated packages.
| jacobsenscott wrote:
| Brew does not start randomly upgrading unrelated
| packages.
|
| Packages have dependencies, and those dependencies have
| dependencies. Try `brew deps ---tree x` to see all the
| dependencies for you package.
|
| Look at `brew pin` to pin packages you don't want brew to
| upgrade.
|
| Many formula are versioned. For example if you install
| `postgresql` it will do major upgrades of postgres as
| they become available, but if you install `postgres@9.6`
| it will only install updates to 9.6.
| kspacewalk2 wrote:
| "Someone else would have filled the void if homebrew hadn't
| shown up, and it would hopefully have been better."
|
| MacPorts and fink existed before homebrew took over, and they
| weren't better. That's why homebrew took over.
| quesera wrote:
| But Homebrew wasn't (and isn't) better than MacPorts,
| either.
|
| They both work well (we can and do quibble about the
| internal mechanics of each), and appeal to different groups
| of people.
|
| My theory is that Homebrew was announced at exactly the
| right time in the MacOS adoption curve. A huge number of
| new users arrived with no existing knowledge of MacPorts or
| Fink. Most of them didn't know they needed a package
| manager at first, but when the momentum picked up, Homebrew
| was the new option with a better web page, a more
| collaborative working model, and hosted at GitHub (also
| ascendant).
|
| I'd also argue that similar factors were involved in
| Linux's popularity over BSD in the 1990s.
|
| Timing, environment, adequacy, and luck. All are required.
| Superiority is not.
| tristor wrote:
| > But Homebrew wasn't (and isn't) better than MacPorts,
| either.
|
| Hard disagree. Maybe that situation has improved for
| MacPorts, but when I made a decision to move from a
| Thinkpad running FreeBSD to a MBP for work, I gravitated
| immediately towards MacPorts and found it to be
| horrendously broken and significantly less friendly than
| using Ports on FreeBSD. I was expecting a similar UX, and
| found something that had the trappings of Ports with none
| of the underlying maintenance that makes it actually
| work.
|
| Then someone recommended Homebrew. I tried it, and it
| worked perfectly the first time. I actually kept both on
| my system for awhile and tried to make MacPorts work, but
| eventually over the years I gave up on that and I've been
| a Homebrew user now for more than 5 years. Homebrew is
| strictly better in the most important factor: It actually
| works.
| volta83 wrote:
| I used MacPorts before hombrew. Homebrew "just worked",
| MacPorts sucked.
|
| Maybe I was too dumb to use MacPorts, but all other
| MacPort used I knew back then all moved to homebrew very
| quickly.
| tclancy wrote:
| Same. I wrestled with it and Fink for a while. Maybe
| things have gotten a lot better elsewhere and I have
| Stockholm Syndrome, but so far so good.
| jacurtis wrote:
| Yep, I have to agree. I started using a mac about 11-12
| years ago. Homebrew was new. At the time MacPorts was the
| "defacto" package manager and Homebrew was the "new kid
| on the block" or "experimental" one.
|
| I started with Macports and it never did what I wanted it
| to. Packages were broken and it required me to do a lot
| of stuff that I didn't understand. A friend told me that
| he had recently done all the same installs on Homebrew
| and it was easy. So I gave Homebrew a try and the exact
| same packages installed easily and quickly. Homebrew has
| only gotten easier to use since then.
|
| Maybe I am just not doing anything complicated enough
| with Homebrew to run into the issues other people have
| had, but my experience with Homebrew has been a breeze. I
| really don't have any complaints. I'd maybe prefer if
| packages were Python instead of Ruby, but at the end of
| the day that really doesn't matter.
| thaeli wrote:
| This, so much this. I tried to use MacPorts. It was
| pulling teeth every time. Brew was a It Just Works breath
| of fresh air.
|
| I agree that it's a very opinionated tool, and note that
| those opinions fit in well with the Mac ecosystem. They
| aren't as good a fit for Linux or Windows.
| novok wrote:
| I think often 'it just works' and 'opinionated' goes hand
| in hand. Without choosing what to say no to, you create
| infinite workload with finite amounts of people and thus
| something breaks, somewhere.
| the_other wrote:
| I tried MacPorts. Then I tried brew and stopped using
| MacPorts. Maybe I just don't use my computer the way you
| do?
| jasonwatkinspdx wrote:
| I used MacPorts before Homebrew was a thing, and had
| plenty of experience with bsd ports going back to the
| late 90s.
|
| Homebrew was just straight up better, no doubt about it.
| It wasn't "noobs," "good timing," or "tricky marketing."
| They were just better, even if still not what these
| posters desire.
| quesera wrote:
| You're imputing far more judgementalness than I intended.
|
| As for better vs worse, let's just say that opinions
| vary.
| cmehdy wrote:
| For some users I would argue brew was indeed better - I
| can't judge for the technical level, but definitely so
| for the UX and troubleshooting.
|
| I might have liked MacPorts with my current experience,
| but when I first needed to install CLIs and tools I did
| not have extensive knowledge of shells and paths and
| such, and MacPorts felt significantly less "integrated"
| especially when something would fail (as opposed to brew
| occasionally just asking if you want to overwrite
| symlinks essentially).
|
| I'll never know if MacPorts was better once you're past
| the initial hurdles since I'm so used to brew these days,
| and I believe that sort of experience is probably not
| isolated. Given the propensity for Mac users to want
| something that just kinda works and gets details out of
| the way, I can see why brew succeeded.
| quesera wrote:
| You're probably right about Homebrew feeling more
| comfortable for new users.
|
| Opinions on Homebrew may diverge with the answers to "How
| would you prefer to install? a) curl pipe to shell, or b)
| Download a DMG, double-click to install, and update your
| PATH." :)
| Macha wrote:
| a) curl pipe to shell
|
| b) Download a DMG, double-click to install
|
| These are not morally that different, the DMG
| installation can also do pretty much whatever, and I
| doubt people are picking apart the DMG to find the
| install script to verify that either.
| quesera wrote:
| I'm definitely not resuscitating that old argument here.
|
| Just noting that people have strong opinions about the
| preferability of either approach.
| selfsimilar wrote:
| About 11 years ago I moved over to then OS X and Homebrew
| was very new compared to MacPorts at the time. I started
| with the more established MacPorts, but quickly became
| frustrated with how many broken and outdated packages
| were hosted on MacPorts. So I moved over to Homebrew and
| haven't looked back.
|
| This is not to say that Homebrew is perfect; there's lots
| of big and little things I'd change. But I'd argue that
| at least at the inflection point of its introduction,
| Homebrew definitely solved a problem I was having with
| its competition. Timing helped for sure, but in my
| experience it won on technical merits.
| kstrauser wrote:
| I'm in that same boat. Homebrew irks some people, but for
| me it's always _just worked_ to the point that I just don
| 't have to think about it, ever. That's what I really
| want from a package manager: to be able to forget that
| it's there and start taking it for granted.
| saurik wrote:
| Homebrew "took over" because of a combination of web 2.0
| marketing that prematurely shat on its competitors while
| claiming it was the "modern and beautiful approach" while
| ignoring hard-learned lessons about the extents to which
| Apple doesn't care about breaking things and removing
| programs or libraries from their base system--the Homebrew
| people were really pissy about "MacPorts insists on
| installing its own version of X... I already have X!" and
| would claim "Apple used to chance stuff back six years ago,
| but they surely stopped by now" and then slowly had to
| relearn this lesson over time--or supporting binary
| packages (which both fink and MacPorts had great support
| for, but the Homebrew people insisted on ignoring that as
| part of the "I shouldn't have to recompile the world to
| install software", which was nonsensical) or even basic
| security mandates (some of which they still haven't fixed,
| such as the insecure way they handle /usr/local). It was
| honestly ridiculous, and they only really got to a place of
| being "better" only by eventually becoming more like the
| things they insisted were dumb and by capturing all of the
| new blood contributors mostly due to messaging/marketing
| (and so eventually ending up in a state where new software
| now ends up being brought to brew by default). If anything,
| the only thing I can think of where Homebrew even slightly
| offered an "advantage" worthy of arguing "this is why they
| won" is by choosing to dump their stuff in /usr/local
| instead of making a new root (such as Fink's /sw or Nix's
| /nix) or carefully next organizing it under /opt (such as
| was done by MacPorts), which did in fact mean that more
| software tended to just detect automatically stuff (as some
| things do their own searches instead of using configured
| environment variable search paths).
| kergonath wrote:
| Thanks. It's nice to see I'm not the only one remembering
| their arrogant attitude and approach to development, or
| with these concerns about technical details. It's
| unfortunate that Macports became the boring one compared
| to Homebrew's new hotness, because Macports is the better
| design, TCL port files notwithstanding.
| throw0101a wrote:
| Besides the already-mentioned MacPorts, NetBSD's pkgsrc is
| multi-platform, including macOS (AFAICT):
|
| * https://www.pkgsrc.org/
| smazga wrote:
| Yeah, it works on macOS and is actually very nice, but its
| package catalog is not quite as comprehensive and OS
| upgrades are a huge headache. In other words, a solid
| alternative with a different set of issues.
| jperkin wrote:
| macOS users may want to use my binary package repository,
| updated every few days from pkgsrc trunk:
|
| https://pkgsrc.joyent.com/install-on-osx/
| eyjafjallajokul wrote:
| Mate, can you tone it down a little? Your opinion is fine but
| it's unnecessarily inflammatory towards basically volunteer
| work.
| game_the0ry wrote:
| I am cool with constructive criticism, but you do realize
| brew is free, right?
|
| If you are not happy with open source, you have a couple of
| options:
|
| - build your own brew
|
| - brew is open source, so you can make contributions to
| improve
|
| - pay for something like brew (though probably not an option
| for brew)
|
| Have you done any of the above before complaining? I am
| guessing - no. Otherwise, say "thank you" and move on, my
| friend.
| dmitriid wrote:
| Being free doesn't absolve it of criticism.
| Enginerrrd wrote:
| I get where you're coming from, but I think the open source
| community benefits from being, well, open. Walling yourself
| off from user frustrations and criticism with the attitude
| that they are ungrateful is not how projects evolve to
| better meet user needs.
| oreille wrote:
| You sure sound absolutely cool with criticism.
| volta83 wrote:
| > There, I said it.
|
| What a waste of bytes and bandwidth. "[homebrew] It's the
| worst package manager I've used" is true for all users that
| have only used one package manager. The opposite claim ("it's
| the best I've used") would simultaneously be true.
|
| You could at least have mentioned _why_ and that could have
| kickstarted a meaningful discussion, but instead your comment
| is the equivalent on a thumbs down in a youtube video.
| anaerobicover wrote:
| Pot, meet kettle:
|
| https://news.ycombinator.com/item?id=26037357
|
| > volta83 1 hour ago | parent [-] | on: Homebrew 3.0
|
| > I used MacPorts before hombrew. Homebrew "just worked",
| MacPorts sucked.
|
| > Maybe I was too dumb to use MacPorts, but all other
| MacPort used I knew back then all moved to homebrew very
| quickly.
|
| > reply
| my123 wrote:
| MacPorts meanwhile existed years before Homebrew, and is
| alive and well.
| tomlin wrote:
| If you've used Valet, you know truly that Brew is the worst.
| onedognight wrote:
| export HOMEBREW_NO_AUTO_UPDATE=1
| filleduchaos wrote:
| That doesn't solve the evergreen packages problem, and I'm
| tired of people trotting out this flag when people
| (rightfully in my opinion) complain about brew upgrading
| literally everything it can get its hands on.
| yardie wrote:
| Macports? They've been around even longer than brew. But they
| were always a bit too Linuxy for most Mac users.
| flemhans wrote:
| I always thought that brew was the "Linuxy" one and
| Macports was FreeBSD Ports for the Mac.
| sirn wrote:
| Jordan Hubbard was involved in the creation of both
| FreeBSD Ports and MacPorts (DarwinPort), so it makes
| sense that it shares the BSD ways of doing things. His
| decision to use Tcl for MacPorts also came from his
| experience dealing with Makefiles[1]
|
| [1]: https://netbsd.org/gallery/10years.html#hubbard
| yardie wrote:
| Well I don't mean Linuxy in the architecture sense but
| Linuxy in the preparation and final stage installation
| sense. Like Homebrew does not need elevated privileges to
| work and actively discourages it. MacPorts, when
| something breaks, is a rabbit hole of elevated commands
| to bring it back to functional.
|
| Of course this is my opinion as I had Macports and
| Homebrew installed on my MBP 2012. I've swapped to a
| newer MBP and I only have HB installed. Since most
| packages are on HB I no longer need to have both
| installed.
| sirn wrote:
| > Like Homebrew does not need elevated privileges to work
| and actively discourages it
|
| It does this by chowning /usr/local to a local user,
| which is worse for security than running sudo because now
| any malicious process can overwrite /usr/local/bin/bash
| without asking for privileges. macOS having
| /usr/local/bin in its $PATH by default also doesn't help.
| Homebrew made this security vs usability tradeoff because
| most Mac users are a single user, which makes sense in
| its context.
|
| The recent change of moving Homebrew to /opt/homebrew (at
| least for M1 Mac) is a better solution for this as it is
| no longer in the default $PATH. On the other hand,
| MacPorts approach of requiring sudo allows it to drop
| privileges to other unprivileged non-admin user
| (macports) during build in addition to building
| everything via sandbox-exec.
| LiberatedLlama wrote:
| Running untrusted software on these sort of systems is
| fundamentally broken, no matter what the package manager
| chooses chown or not chown. A malicious program could
| edit ~/.bashrc to modify the user's PATH, or wrap sudo
| with a keylogger then use that password to chown anything
| it likes. That's not even a theoretical but unlikely sort
| of attack; it's quite trivial. > alias
| sudo='echo not what I expected' > sudo foo
| not what I expected
| sirn wrote:
| That's fair, but it's only affecting single user, while
| writable /usr/local affects all users. However most Mac
| users are single user, so the tradeoff makes sense in
| this context.
| eecc wrote:
| Linux? Macports take direct inspiration from FreeBSD ports
| one-punch wrote:
| > I hate that brew is good enough that it's got some kind of
| local maximum such that there's no replacement forthcoming.
|
| You may be interested in trying out nix for package
| management [1], or even for configurations and providing
| development environments (see my other comment [2]).
|
| [1]: https://builtwithnix.org/
|
| [2]: https://news.ycombinator.com/item?id=26038614
| novok wrote:
| When I tried nix on my mac a while back, it took forever to
| install basic things, had very verbose logs, was far more
| complicated and was missing packages. Is it still like
| that?
| ris wrote:
| Nix on macos only got a pre-built binary cache a couple
| of years ago - before that, yes, almost everything had to
| be built from the ground up.
| brailsafe wrote:
| This seems like a rather exceptional, unsubstantiated, and
| mean spirited take. I've run into _some_ strange issues with
| brew over the years, but compared to npm and apt it 's been
| far less prone to causing me headaches.
| woodruffw wrote:
| Homebrew maintainer here: I'm sorry that we don't meet your
| expectations.
|
| Two things for your consideration:
|
| 1. It's uniquely _visible_ among system package managers.
| When people have problems with a package in `apt` or `dnf`,
| they find a community or third-party repository for the
| package _or_ bug the upstream directly. By contrast, Homebrew
| has _always_ been visible on GitHub, does not require a
| special login to a bugtracker on some random domain, and thus
| receives direct community support volume that we need to
| address.
|
| 2. Homebrew is not an official system package manager. We
| operate at Apple's whim, which generally ranges between
| neutral disinterest and actively trying to remove parts of
| the macOS userspace that we rely on. Many of our changes over
| the last decade (installing our own Ruby, rolling back custom
| source options) can be _directly_ traced back to changes that
| Apple imposes that produce _disproportionately_ greater
| maintenance effort from us.
| jedbrown wrote:
| Point 2 here is huge. If Apple cared about open source or
| cross-platform developers, they would pay at least one
| full-time Homebrew developer and upgrades would be smooth.
| It speaks volumes that they are swimming in money and can't
| be bothered to make a token gesture.
| woodruffw wrote:
| > It speaks volumes that they are swimming in money and
| can't be bothered to make a token gesture.
|
| I agree with a lot of the sentiment here, but I want to
| make one important correction: Apple _has_ helped us. In
| particular, they gave us access to DTKs for the M1 and
| provided us with a liaison for the migration. We 're very
| thankful for that help.
|
| That being said, Apple is a massive company and they have
| their own development goals and velocity for macOS.
| They're not _actively_ looking to break Homebrew, but
| they 're also not going to halt everything for us.
| lostcolony wrote:
| Thanks for calling that out. This is totally unrelated to
| everything, but it's refreshing to see people giving
| credit -and thanks- to behemoth companies here on HN,
| with the proper nuance to also call out places they could
| have helped more (and the understanding of why they
| didn't). It's too easy, and common, to pile on the
| shortcomings. It struck me as a standout comment even in
| this generally polite community.
| neuronic wrote:
| Apple swims in money and can't even be bothered to
| implement a hassle-free way of changing your Apple ID,
| especially if you own more than one device and even worse
| if you have 'Find My' enabled on them.
|
| More than one person just last week got stuck in a loop
| where the system wants credentials for your old
| _deactivated_ Apple ID. The solution isn 't hard but the
| UX flow fucking sucks.
|
| You must manually sign out of all devices using your old
| ID and sign in again. Except before you can do that you
| have to disable Find My. With the deactivated credentials
| again.
|
| It shows the OLD email and wants the old password but you
| have to actually enter the NEW password in the dialogue
| so Find My deactivates and you can sign out.
| Wowfunhappy wrote:
| I think that #2 wouldn't happen as often if Homebrew made
| more of an effort to play by the rules of UNIX and of
| Apple. For Apple in particular, there is a sort of
| philosophy to how they operate, even if you can't predict
| exactly what they will do.
|
| MacPorts hasn't had as many of these issues over the years,
| and I suspect that's largely down to mindset. They have a
| somewhat classical mindset, and rarely invent new ways of
| doing things.
| michaelcampbell wrote:
| > We operate at Apple's whim, which generally ranges
| between neutral disinterest and actively trying to remove
| parts of the macOS userspace that we rely on.
|
| <sigh> I know you're not unique in this assessment or
| consequence, and that's truly a shame.
| smoldesu wrote:
| I agree with you wholeheartedly. Homebrew was my least
| favorite part of the MacOS experience, which is a shame since
| it was basically the most important piece of software I had
| installed on that thing.
| [deleted]
| loriverkutya wrote:
| When I get angry about brew sucks I always remind myself
| there is npm.
| cmehdy wrote:
| When I get angry about npm, I remind myself there is
| gradle.
| Gaelan wrote:
| When I get angry about gradle, I remind myself there is
| autotools.
| [deleted]
| paultopia wrote:
| Yes. I'm really torn about brew. On the one hand, I hate to
| crap on the work that the maintainers have done, and it's
| clearly the best thing out there for macos. On the other
| hand, it's a terrible dictatorial piece of software that
| wants to command precisely how you use your computer; those
| same maintainers are actively hostile to users, as evidenced
| by the endless stream of nasty responses to issues, arbitrary
| changes to disable any functionality that they believe anyone
| has ever misused by their standards ever, etc. I pray daily
| that someone will fork it.
| fishywang wrote:
| I already stopped using Mac, but for people still using
| Mac: you really should give nixpkgs a try.
| milch wrote:
| +1. I've been using it for a while, and it fixes my
| problems with homebrew - mostly that homebrew breaks
| features every couple of weeks in small point releases,
| which you get automatically upgraded to
| NegativeLatency wrote:
| Auto upgrade sucks but it is possible to turn it off
| fishywang wrote:
| But then what? You still have to deal with the mess when
| you do manual upgrades.
| Hamuko wrote:
| > _it 's a terrible dictatorial piece of software that
| wants to command precisely how you use your computer_
|
| I've also seen examples of where Homebrew is basically
| dictating on how to release your software as well. There
| was that one case where they decided to delete the formula
| for mpv since mpv didn't have a recent enough of a tagged
| release.
|
| https://github.com/danielbair/homebrew-
| core/commit/b18f104f1...
|
| There was also an instance with mpv where Homebrew devs got
| pissy about mpv not supporting Lua 5.3 and mpv devs got
| angry at Homebrew devs for asking to break existing user
| scripts to appease one package manager.
| [deleted]
| kemayo wrote:
| That one doesn't seem unreasonable. They have a "we only
| support tagged releases" policy. mpv moved away from
| tagging releases for a bit, and their latest tagged
| release couldn't build on current MacOS. So they switched
| it to the part of their system (casks) that supports
| downloading and installing arbitrary binaries instead.
|
| I think it's a fair conflict, too. For a package manager,
| saying "just download and compile master wherever it is
| right now" is rough, and I can understand them not
| wanting to have to look at mpv's repo and pick a good
| commit to pin as their "release". Offloading picking a
| stable release point to someone else is legitimate.
| ihuman wrote:
| To add to what you said, the formula came back a week and
| a half later when they returned to tagging releases.
|
| https://github.com/Homebrew/homebrew-
| core/commit/82a45025682...
| LiberatedLlama wrote:
| I suppose their hand was probably forced by Apple in some
| way, but simply offering binary downloads for mpv in
| particular is subpar. There are a lot of unusual options
| for mpv that, in my experience, don't get pulled into
| prebuilt binaries. For instance, last I checked, the
| prebuilt packages for mpv from homebrew didn't have
| librubberband support. LibRubberband is great, but to
| effectively integrate it into your workflow you need some
| userscripts that mpv doesn't ship with, so many users
| (including packagers evidently) may not see the value in
| it. When I was still using MacOS, I had to build mpv
| myself to enable it. My memory is hazy, but I think
| libarchive support was in a similar situation. Eventually
| I cut homebrew out of the picture and chose to build mpv
| myself, since homebrew wasn't helping at all, just
| getting in the way.
| [deleted]
| bzb6 wrote:
| Ah, this reminds me of how shitty the maintainers were to
| me when I said I was using hackintosh (for an issue that
| had nothing to do with it).
| Hackbraten wrote:
| Apologies about that. I'm sure none of us wants to be
| shitty to anyone. It's never ok when we are.
| sneak wrote:
| I find Nix to work better on macOS than Homebrew, and it
| doesn't embed spyware in the package manager like Homebrew
| does.
| jacobsenscott wrote:
| How does it "command you how to use your computer?" A brew
| formula is a simple ruby script that lists the packages
| dependencies, and calls "make; make install". Typically it
| allows you to set any autoconfig vars and remembers them
| for next time. This is literally just a thin layer of
| abstraction over grabbing the tarball and installing the
| software yourself.
|
| Also brew does not stop you from installing a piece of
| software literally any other way you prefer if for some
| reason you don't like what the brew formula is doing,
| including just creating your own tap.
| personjerry wrote:
| > dictatorial piece of software
|
| Isn't that generally the point, for Apple consumers? At HN
| we have a skewed sample but I imagine for a lot of users
| (myself included), having an easy solution with
| configurations set for you is exactly what they want.
| anaerobicover wrote:
| Not for developers, no. "Normal" Apple consumers have
| little reason to use brew.
| personjerry wrote:
| I think that's a false dichotomy. I think there are
| plenty of "normal" Apple consumers who may not be an HN-
| level hacker but would still be considered "developers".
| apocolyps6 wrote:
| What is a "HN-level hacker"? I write code for a living
| and I read news on this website. Do I count?
|
| I'm an apple "consumer" because I don't want to think
| about any hardware gotchas when I'm trying to do my job.
| That's the same thing I want out of my package manager,
| sensible defaults I don't have to think about so I can do
| real work instead.
| LiberatedLlama wrote:
| Homebrew has clear value even if you aren't a developer.
| It's the best way to install a whole lot of software, not
| just dev tools.
| the_other wrote:
| That's what I want.
|
| I build web apps for a living, and I used to do it by
| contracting. I don't have time, patience or interest for
| fiddly configuration. I want a mostly-good initial
| experience so I can get on with my work rather than mess
| about with my tools. I'm aware there's some gain to be
| had by knowing more about my tools, but the payoff isn't
| obvious enough to make me change my ways.
|
| Thanks for being mostly-great, brew.
| jack_riminton wrote:
| Exactly, it's the same reason I use Mac instead of Linux.
| I want to make things. I don't want to waste time
| fiddling with endless verbose details I don't need to
| know
|
| Yours, A Noob
| busterarm wrote:
| You left out the entire generation of developers who are
| totally disconnected from how systems work and think that
| "it runs on my machine" should be good enough.
|
| Brew has lowered the bar enough that lots of folks simply
| don't have a clue how to deploy anything and worse, don't
| have a clue how to troubleshoot when something goes wrong
| in production.
|
| Obviously it's a double-edged sword. It's good to not waste
| time configuring your workstation, but ultimately I'd argue
| in brew's case too good to be true.
| panopticon wrote:
| I don't understand this critique. Is this a complaint
| about package managers in general, or is `brew install
| git` lowering the bar from `apt install git`?
| busterarm wrote:
| It's about a trend of developers who don't know how to
| interact with their system beyond `brew X Y` and the
| disconnect between the software on their Mac and the
| software on a production system.
|
| There's a huge disconnect between A & B so much so that
| it's created an entire role for people like me that
| otherwise shouldn't exist.
|
| I've been in the industry long enough to see a decline in
| ability for lots of developers beyond kicking deployment
| over the wall for someone else to figure out (not that
| this didn't exist before).
|
| Notice how many companies have dedicated DevOps roles in
| their ranks whereas everyone and their mother who is a
| practitioner has been saying since the very beginning
| that that's now how it should be.
| bluefirebrand wrote:
| > Notice how many companies have dedicated DevOps roles
| in their ranks whereas everyone and their mother who is a
| practitioner has been saying since the very beginning
| that that's now how it should be.
|
| I dunno who says that but they're dead wrong. I'm working
| as a dev somewhere with a dedicated DevOps finally after
| years of being dev + ops (+dba +sysadmim +qa) and I can't
| tell you how much of a relief it is to have other people
| shoulder that stuff so I don't have to think about it.
|
| I understand your point that devs who have a higher level
| understanding of systems and deploy pipelines and such
| are probably able to write good systems themselves, but
| when it comes to the humans doing the work? I absolutely
| love having it separated.
| busterarm wrote:
| It feels nice but organizations with cross-functional
| teams are outmaneuvering yours and probably by at least
| 3x.
|
| I'd rather work harder at a business that succeeds and
| has equity that's worth a damn.
| bluefirebrand wrote:
| That's fine, I'd rather work on stuff I enjoy and have a
| life outside of work.
| panopticon wrote:
| I don't buy the premise that package managers are the
| reason why companies need DevOps.
|
| Software deployment has gotten complicated for a variety
| of reasons (containerization, micro-services, continuous
| integration, cargo-culting FAANG practices, etc). When I
| first started my career, I FTP'd my code changes into the
| single production server that ran both Apache and MySQL.
| Homebrew is not the reason I don't do that anymore.
| busterarm wrote:
| That's not really the argument that I'm making.
|
| I am a deployment engineer.
|
| Deployment is actually really easy.
|
| I'd argue that it's not far off from FTPing your code
| changes over in terms of difficulty.
|
| No, my argument is that more engineers today do not know
| how computers work. I'd even argue that many engineers
| would find FTPing over code changes to be too difficult
| (or they'd screw it up). My argument is that homebrew
| makes some amount of contribution (not 100% the reason
| for) engineers remaining ignorant about computers.
| vetinari wrote:
| While I sympathize, I think that train left long time
| ago.
|
| I had that aha moment, when during early 2000s I found
| myself explaining to C++ developer what linker is and
| what exactly it does. Until then, it was just the thing
| that VC++ did as the last step after clicking the Build
| menu item.
|
| It certainly didn't improve since then.
| mercer wrote:
| Do you know how to directly 'talk' to the CPU or GPU? Do
| you build everything from source? Are you comfortable
| writing assembly? Have you recently soldered shit or
| built a PC from scratch?
| busterarm wrote:
| Yes, when it makes sense to, yes and yes.
|
| I'd be happy to work with people who know system calls &
| exit codes though. And basic network protocols. And how
| to read an RFC.
| mercer wrote:
| Your complaints seem to boil down to "get off my lawn"
| and it's rather tedious. what do you get out of it other
| than a feeling of superiority?
| busterarm wrote:
| It's not at all. It's a reaction to the learned
| helplessness from colleagues I've had to work with. It's
| exhausting to be relied upon for everything, especially
| when the compensation isn't matched appropriately
| (although most management I've encountered have
| appropriately engineers who do disproportionate heavy
| lifting). Our industry needs to do better.
| TameAntelope wrote:
| Well, to be clear, developers who say "it runs on my
| machine" aren't a "new generation of developers" so much
| as "bad software developers".
|
| There's no world where that excuse is okay. It's also not
| all that related to Homebrew, though...
| jacobsenscott wrote:
| This makes no sense. First, nobody deploys anything to
| macos in production. Second, dragging an icon the
| applications folder (pre-brew method) does not "connect
| you to how the system works".
| upbeat_general wrote:
| Not everyone wants to troubleshoot things in production.
| In fact I'd argue most people _dont_ want to do that.
|
| I'd certainly prefer to stay away from that type of
| hassle when I'm just trying to install a random package.
| busterarm wrote:
| Nobody's saying you should want to.
|
| This is a conversation about ability level.
| thomaslkjeldsen wrote:
| The decisions to enable auto update, the removal of
| `--with-foo` options, breaking the `brew list` command and
| the removal of `depends_on :x11` were all mistakes, as I
| see it. I have read loads of issues and pull requests to
| understand the reasoning but have yet to find arguments
| that I think justifies those breaking changes.
|
| I get it, it's all made by volunteers, but I wish there was
| a package manager for macOS that was focused on
| professional users.
|
| I wonder if the decision process in Homebrew has relied
| perhaps too much on analytics data leading to the
| dismissal/ignorance of features used primarily by users who
| have disabled analytics via the HOMEBREW_NO_ANALYTICS
| environment flag.
| upbeat_general wrote:
| It's hard to disprove this but IMO brew is the best package
| manager I've used (at least out of any of the widely used
| ones). I'm sure there is a better way to do things but given
| other common package managers that I find to be much worse,
| I'd argue it's equally (if not more) likely that the
| alternative to homebrew would be worse.
| prpl wrote:
| It might not cover everything, but it also has a superset of
| other things more - conda + conda-forge (with mamba too for
| better performance)
|
| The had also apple silicon support for many things more than
| a month ago.
| dcchambers wrote:
| I agree. Is Brew perfect? No, far from it. But I think that
| given the tools available at the time, Brew is the right
| balance between technically good and being really easy to use.
| The dependence on git means speed isn't great, especially if
| you don't use it often, but it keeps things simple and
| maintainable. I also think it's been fantastic to see the level
| of support from the community and the efforts of the
| maintainers. For example, merging Linuxbrew back into Homebrew
| itself.
|
| Honestly I can't imagine using my mac without Brew.
| Hackbraten wrote:
| Thank you so much. Comments like yours are what keeps us
| going. Much appreciated!
| alpineidyll3 wrote:
| The fact that AAPL doesn't support brew's maintenance and
| development is a great reason to not buy more macs.
| KenanSulayman wrote:
| Apple is invested into MacPorts (and also pays several
| employees working on it).
| jaboutboul wrote:
| They support them with Hardware and technical resources.
| Seeing what happened with the whole CentOS mess, I am kind of
| glad that homebrew remains independent and can continue to do
| so without relying on Apple's money.
| salzig wrote:
| Without this, the developer experience on Apple would be way
| worse, if not just plain shit.
| loeg wrote:
| I agree with the general sentiment, but there are other,
| similar tools that also function fine as duct-tape over the
| missing pieces in MacOS (i.e., MacPorts).
| bluedino wrote:
| Wouldn't we all just be using MacPorts/Fink, like we were
| before Homebrew?
| chrisdhal wrote:
| I still only use MacPorts.
| acomjean wrote:
| It's Weird that Apple doesn't do this themselves. It's not like
| they don't have a cash. And it's important for devs to have up
| to date tooling.
|
| This intrepid band of volunteers are adding huge value to one
| of the largest corporations on earth. I appreciate the DIY
| effort of anyone who volunteers, though I see the donate tab on
| their website and sigh a little.
| agsnu wrote:
| https://en.wikipedia.org/wiki/MacPorts (nee DarwinPorts) was
| started with the involvement/sponsorship of Apple and was
| probably the most popular Mac OS X package manager / port
| library around the mid-00s.
| chrisfinazzo wrote:
| In the case of Swift, they actually took this advice to heart
| - and hired Max to help them do it.
|
| That said, it remains disappointing to me that unless you're
| producing content with Apple's hardware or building apps for
| the Stores, they don't really do much to help you.
|
| For example, if you're writing client or server-side web
| code, they will acknowledge your existence, and are more than
| willing to sell you a Mac, but that's about it.
|
| ^ This doesn't even get into the concerns around all of the
| supporting pieces that go along with this code - e.g,
| documentation, training materials, and outreach - the tooling
| for this part of the process is voluminous in its own right.
|
| https://en.wikipedia.org/wiki/Comparison_of_documentation_ge.
| ..
| [deleted]
| cies wrote:
| If someone is doing it for free, why step up and spend money
| on it? /s
|
| For sure Apple employees are using lots of homebrew every day
| :)
| [deleted]
| reaperducer wrote:
| _It's Weird that Apple doesn't do this themselves._
|
| If Apple did it, HN would be awash in "Walled garden!" and
| "Monopoly!" hysteria.
| Phenix88be wrote:
| > It's Weird that Apple doesn't do this themselves. It's not
| like they don't have a cash. And it's important for devs to
| have up to date tooling.
|
| There is no money to get from it. And developers are not the
| "end user" for Apple anymore. I don't see why Apple should
| even care about Homebrew.
| Steltek wrote:
| It saddens me as I see this massive infusion of developer
| time and energy being donated to one of the biggest tech
| companies around. If that effort had instead gone into making
| Linux better, which Homebrew obviously builds on, where would
| Linux workstations be now? Would I get a nice Linux laptop
| from my company instead of being forced to use a MacBook?
| taylodl wrote:
| Contributing to Linux also helps the biggest tech companies
| around - namely IBM and Oracle amongst a host of others.
| When you contribute to free and open source software you
| should know and understand you're providing your labor for
| free to tech behemoths. For most it's a labor of love and
| aligns with their passion and so everything is cool but you
| run across a few who's feelings get hurt and feel like
| they're getting ripped-off.
| LiberatedLlama wrote:
| Contributing specifically to the desktop experience of
| Linux is another matter (unless maybe you're a GNOME
| developer.)
| augustl wrote:
| It seems to me that if you compare Apple and Microsoft, it's
| only the latter that cares deeply about the developer
| experience on their platform.
|
| https://github.com/microsoft/winget-cli
| taylodl wrote:
| That's been mostly true since both of the company's
| founding (Microsoft in 1975 and Apple's in 1976). What was
| Microsoft's first product? Basic. Microsoft's Basic ran on
| the most popular home computer platforms of the day (except
| Apple's). Even Commodore's Basic was fully interoperable
| with Microsoft's.
|
| What was Apple's first product? A computer. A computer
| meant for people not having a CS background. The Apple II
| kicked off the home computing revolution, i.e. bringing
| computing to the masses. The Mac was the computer "for the
| rest of us" and was aimed squarely at graphic artists,
| desktop publishers, musicians, and the like.
|
| So yes, Microsoft has always been developer and business
| focused whereas Apple has always been the computer "for the
| rest of us."
| zests wrote:
| It's a shame that the windows experience is so poor that it
| negates any positives introduced by the developer
| experience improvements.
| redwall_hp wrote:
| It's really weird adjusting to a post-Ballmer Microsoft. I
| have plenty of existing loathing for that company from
| their behavior towards Netscape and Linux in the 90s and
| early 2000s (among other, smaller players). However, their
| developer-focused offerings are amazing, now that they made
| .NET Core open. C# is great to work with.
|
| Meanwhile, Apple is now engaging in anticompetitive
| behavior that I find frustrating. (App Store stuff.) Things
| have turned on their head.
| teilo wrote:
| Apple is not a good steward of open source projects. We saw
| what happened with CUPS. Apple took it over and it basically
| died.
| busterarm wrote:
| Too much of the tooling that people want to use is GPL.
|
| Apple is more allergic to the GPL than any other company on
| Earth. They would never do something official that would even
| put GPL software in their orbit.
| OskarS wrote:
| > It's Weird that Apple doesn't do this themselves. It's not
| like they don't have a cash.
|
| I can understand them not wanting to do it themselves. I
| don't think they want to take on the responsibility for
| maintaining all those packages (for legal reasons or
| otherwise). Because it's a "not officially Apple" thing,
| Homebrew can probably get away with a "no warranty" sticker
| that an official Apple project couldn't.
|
| What Apple should do, however, is ship a DUMP TRUCK OF MONEY
| to every Homebrew maintainer on a regular basis. That project
| is crucial to basically every Apple developer, and it
| massively enriches macOS as a general purpose development
| platform. Apple would be fools to not support it financially.
| GlitchMr wrote:
| Apple did help with implementing support for ARM CPUs as
| mentioned in the changelog: "Particular thanks on Homebrew
| 3.0.0 go to MacStadium and Apple for providing us with a
| lot of Apple Silicon hardware and Cassidy from Apple for
| helping us in many ways with this migration." Making sure
| Homebrew works on ARM Mac devices made sense for Apple.
|
| Meanwhile providing money for no reason to Homebrew
| wouldn't make business sense. As far Apple is concerned,
| Homebrew works, and providing financial support wouldn't
| make it work better.
| jimbokun wrote:
| Might provide stability by making it less likely for key
| maintainers to walk away because they don't have time for
| both homebrew and their day job.
| JeremyBanks wrote:
| _Meanwhile providing money for no reason to Homebrew
| wouldn 't make business sense. As far Apple is concerned,
| Homebrew works, and providing financial support wouldn't
| make it work better._
|
| This is idiotic.
| 9dev wrote:
| Try putting on your management hat. Would you approve
| donating money to some random project that vaguely
| benefits the users of your platform, with no apparent
| reason? After all, the Tool seems to work fine and nobody
| is complaining. You can surely imagine the course of such
| an initiative inside Apple.
| zimpenfish wrote:
| > some random project that vaguely benefits the users of
| your platform
|
| Be interesting to see what percentage of users actually
| install Homebrew - I'd wildly stab in the dark about
| 25-30%, tops?
| guytv wrote:
| >Meanwhile providing money for no reason to Homebrew
|
| >wouldn't make business sense. As far Apple is concerned,
|
| >Homebrew works, and providing financial support wouldn't
|
| >make it work better.
|
| Well, I think that funding really smart people running
| really valuable projects tend to make them even more
| valuable.
|
| Besides, there's some cosmic Karmic justice if this
| happens.
| littlecranky67 wrote:
| IIRC, Apple does (or at least did) donate Hardware to some
| of the maintainers. I remember some of the Homebrew
| maintainers answering in comments here on HN that hey
| received M1-based MacMinis - this is of course in the
| interest of Apple but also shows that they do care about
| it.
| capableweb wrote:
| > I don't think they want to take on the responsibility for
| maintaining all those packages
|
| That's not how a package manager works. The people
| responsible for APT/AUR do not maintain all the packages
| within the repositories themselves. This even applies to
| the App Store. Apple does not maintain the apps there
| themselves, it's up to the people publishing the apps. So
| there really isn't any reasons except they can't make money
| on it, hence it doesn't exist as an officially sanctioned
| way of pulling down programs.
| offtop5 wrote:
| Yes and no, Apple doesn't want the support issues going
| into their queue and clogging up their customer support
| system.
|
| When Billy Bob installs the wrong package from Homebrew
| now he just complains on a forum like this, or on stack
| overflow. He doesn't email Apple
| OskarS wrote:
| Yeah, if Apple says "This is our official package
| manager, and you can use it to install
| OpenSSL/nginx/whatever", like or not, they are on the
| hook if it breaks, and they have to fix it. Like,
| companies are going to be like "we trusted you and now
| our website is broken, and we're going to sue you".
|
| Homebrew gets away with this a little bit by basically
| being unofficial, implicitly saying "we're not
| guaranteeing anything here, this is purely for
| convenience". It would be much harder to make this
| argument if you were an official Apple project.
| WJW wrote:
| > Apple would be fools to not support it financially.
|
| Since people are already doing an excellent job for free,
| why would they start paying them? Clearly the lack of Apple
| funding has not hurt the project thus far.
| capableweb wrote:
| One could say Homebrew is successful despite Apple not
| trying to even mention their name, even less help them be
| successful. Many groups also look at successful groups
| and think "How can we make them more successful?" but
| don't think that's in Apples DNA.
| saagarjha wrote:
| Apple has mentioned Homebrew; a screenshot of it is the
| banner on their Twitter account.
| OskarS wrote:
| I mean, I don't run any billion dollar companies, so what
| do I know, but Apple donating a couple of million to
| ensure that Homebrew stays active seems like a no-brainer
| investment to me.
|
| Yeah, Homebrew has been doing this work for free thus
| far, but open source projects die all the time. It's very
| much in Apple's interest to ensure this one doesn't.
| EForEndeavour wrote:
| Side note: Apple has been a _trillion_ -dollar company
| since 2018. https://en.wikipedia.org/wiki/List_of_public_
| corporations_by...
| acdha wrote:
| Microsoft is investing a ton of money in developer
| productivity for non-traditional Windows developers.
| Apple has had a mindshare lead there but it's not a
| permanent situation and a tiny fraction of their cash on
| hand is much cheaper than trying to win people back.
| jaboutboul wrote:
| As I mentioned in another comment, Apple supports them with
| hardware and technical resources. Seeing what happened with
| the whole CentOS mess, I am kind of glad that homebrew
| remains independent and can continue to do so without
| relying on Apple's money.
| maliker wrote:
| Yeah, the app store has become a source of a lot of
| controversy around policies, so signing up for more public
| criticism of how they handle a package manager is probably
| a headache they don't need.
| dave_aiello wrote:
| I don't know about the "DUMP TRUCK OF MONEY", but a program
| that formalizes support for the Open Source community on
| MacOS would be a win for Apple as well as Apple's
| customers.
| OskarS wrote:
| Potato, potahto :)
| novok wrote:
| Apple needs to dump a truck of money on their own developer
| tooling team and double every team size. If you knew how
| small they were you would be surprised!
|
| Xcode / swifts build speed is still pretty bad, xcode still
| chokes on large projects, codesign is an eternal flaky
| nightmare, they still don't have first class command line
| support for many things, they don't have network indexing &
| build caching like bazel does, it's worse than android for
| maintaining a device lab for testing (adb vs...
| `instruments` kind of) and on and on it goes.
| shp0ngle wrote:
| Apple did sort of half-officially supported MacPorts,
| precursor of Brew.
|
| Nowadays they don't want to touch anything GPL so that might
| be it
| Yaggo wrote:
| I don't think it's weird. Actually I think it's important to
| keep this as a community effort, in the spirit of FOSS. From
| developers, to developers, you know. Surely it would be nice
| for the maintainers if Apple could throw in some cash, though
| :)
| nailer wrote:
| > I use Linux at home and package managers like AUR are great,
| but macOS is where the users are.
|
| Windows is where the users are, and apt-get works just as well
| on WSL2 as natively.
| remix2000 wrote:
| Homebrew was nice up until they packed it with spyware and then
| subsequently forced full tree clones+ down the users' throats.
| It still might be useful for some people, but it certainly fell
| by the wayside. What a shame...
|
| +) As a result, Homebrew grew _literally_ hundreds times larger
| and became unbearably sluggish.
|
| .
|
| PS: I'm wondering what drives some people to downvote this very
| comment... Stockholm syndrome maybe? ;P
| evgen wrote:
| People are probably downvoting it because in a scant few
| lines you manage to pack in two lies and a half-truth. It is
| not packed with spyware, it has not fallen by the wayside,
| and the full clone is due to a request from github to reduce
| the load caused by homebrew users (as in it is so popular
| that it caused a noticeable impact on github servers.)
| remix2000 wrote:
| Stop calling names and searching for lies where there are
| none. I didn't bother explaining that all, because I
| assumed people coming here are already Homebrew users, as
| those who are usually already know that all. It's just pity
| to see where is it going[0][1]...
|
| --
|
| [0] Regarding spyware: https://github.com/Homebrew/brew/blo
| b/master/Library/Homebre...
|
| [1] Regarding the forceful approach to unshallowing, they
| just chose the easiest way they could. You'd literally had
| to meddle with the code in order to accept shallow clones
| again. They didn't even bother to make a switch for
| advanced users.
| Hackbraten wrote:
| Re. [0]: how does anonymous telemetry (number of unique
| installs per package) constitute spyware?
|
| Re. [1]: GitHub pays the bills for (a large part of) the
| infrastructure we're using. They reached out to us,
| explained the problem and asked us to unshallow.
| Honestly, what would you have done instead of complying?
| dqpb wrote:
| But can he invert a binary tree?
| batterylow wrote:
| "But well, what the fuck does comp-sci have to do with modern
| app development?" [1]
|
| [1] Max Howell, https://www.quora.com/Whats-the-logic-behind-
| Google-rejectin...
| m463 wrote:
| I would say he's stuck in the shitty interface between truly
| creative people and macos.
|
| I think creative people are getting the shaft from apple.
|
| "Here's to the crazy ones" went out the window, maybe with the
| end of the Steve era. If you don't do it the apple way, apple
| doesn't care.
|
| I mean, they support the xcode factory workers with apple
| languages. It's the apple equivalent of visual studio. But its
| sort of monochrome (like the 1984 ad)
|
| I truly believe apple itself should have more direct/overt
| support for other software on their platform in a
| macports/homebrew way. (scripting languages?)
|
| xquartz is sort of an example of this "forgotten lawn furniture
| left out in the rain". It's critical to a lot of mac users, but
| they distance themselves from it. Gah, at least bring it
| indoors when there's snow on the ground.
| ikawe wrote:
| Thanks to Max Howell for having the initial vision and
| maintaining it for the first 4 years!
|
| Thanks to Mike McQuaid (et al) for the last 10!
|
| https://github.com/Homebrew/brew/graphs/contributors
| pgt wrote:
| /me searches changelog for "`brew update` now runs asynchronously
| and doesn't block the process to install a 3 year-old package."
| Dismayed, I do not find it.
|
| Asynchronous formula updates would IMO save the most Mac man-
| years of almost any macOS tool.
| c0nsumer wrote:
| I feel like it would be a /tremendous/ amount of work to
| install packages -- which often have dependencies --
| asynchronously.
|
| When is this really a problem, anyway? You should probably not
| have something like 'brew update' scheduled to run
| periodically, as then a broken package could break something
| unexpectedly. It should really only be run when you're ready to
| check for broken things, which means you can also schedule it
| to run when you can deal with waiting for the process to
| complete.
| rrdharan wrote:
| That's what I did - I have `@daily brew update` in my
| crontab.
| jrochkind1 wrote:
| Homebrew now runs `brew update` before every `brew install`,
| no? That's how it gets in the way, you just wanted to install
| a thing, and now you are stuck waiting for `brew update` --
| which I feel takes longer than it used to?
|
| (You also may be confused between `brew update` and `brew
| upgrade`. I know I often am!)
| Spiritus wrote:
| Then `HOMEBREW_NO_AUTO_UPDATE` is probably for you.
|
| > If set, do not automatically update before running brew
| install, brew upgrade or brew tap.
| thomaslkjeldsen wrote:
| Running `brew install hello` triggers `brew update`
| automatically unless the environment variable
| HOMEBREW_NO_AUTO_UPDATE is set:
|
| echo export HOMEBREW_NO_AUTO_UPDATE=1 >> $HOME/.zshrc
|
| I do not think it was a wise decision to enable auto update
| on `brew install` as long time users expect `brew update`
| and `brew install` to be two separate steps (as it was for
| years) and because Homebrew no longer operates like `apt`
| and other package managers.
|
| Looks like it was changed in 2016:
| https://github.com/Homebrew/brew/issues/288
| jrochkind1 wrote:
| It makes sense semantically to me, and would be
| fine/preferable if `brew update` only took a few seconds
| to complete.
|
| Cause otherwise I'm not necessarily going to remember to
| brew update _ever_ , and am going to be getting old
| formulae. I think I'm not alone, I suspect this was done
| because too many users were never updating.
|
| I am not super familair with how apt works, but I think
| the "workflows" of brew are already different than
| typical apt uses, with continuous incremental releases,
| and users expected to stay up to date with them -- things
| aren't necessarily going to _keep working_ (installing
| properly) if you never run `brew update`, and I think
| many users were not.
|
| I _do_ want `brew install` to get me the latest formula
| for the thing I 'm installing.
|
| The problem is when it can add several minutes to a `brew
| install` invocation, interupting my ability to get on
| with my business.
|
| But good to know about the env variable so at least I can
| choose which tradeoff I want!
| fnord123 wrote:
| Optimizations to brew would save many many watthours. If I were
| to guess, it would be over a MWh per year.
| Hackbraten wrote:
| PRs are welcome.
| jeffbee wrote:
| Well, that right there may be the reason you've had
| difficulty finding gainful employment.
| abalaji wrote:
| this is unnecessarily mean spirited
| matsemann wrote:
| How often are you running brew? Not using MacOS anymore, but I
| mostly did it when configuring the computer the first time, and
| maybe some more when changing projects. So like two times a
| year or so.
| notretarded wrote:
| Why is this important
| amarshall wrote:
| It's possible to set `HOMEBREW_NO_AUTO_UPDATE` and
| `HOMEBREW_AUTO_UPDATE_SECS` to somewhat alleviate this.
|
| https://docs.brew.sh/Manpage#environment
| chisquared wrote:
| You can set up launchd to run `brew update` and `brew upgrade`
| regularly -- it's what I do.
|
| Don't do this if you're attached to specific versions of any
| formulae you have installed. You can try `brew pin`ning them
| though.
___________________________________________________________________
(page generated 2021-02-05 23:01 UTC)