Live data from Hacker News

Homebrew 3.0

brew.sh

391–400 of 516 posts

Re: Homebrew 3.0

#391
post #292

Earlier quoted context omitted.

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. M…

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).

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.

Re: Homebrew 3.0

#392

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 Homebre…

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…

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?

Re: Homebrew 3.0

#393

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 Homebre…

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…

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.

Re: Homebrew 3.0

#394

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 Homebre…

Homebrew and Metaspoit prompted me to learn Ruby. It’s an excellent and well-suited language for that type of DSL

Re: Homebrew 3.0

#395
post #250

Earlier quoted context omitted.

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.

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.

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.

Re: Homebrew 3.0

#396
post #374

Earlier quoted context omitted.

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 home…

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?

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.

Re: Homebrew 3.0

#397
post #373

Earlier quoted context omitted.

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 be…

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?

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.

Re: Homebrew 3.0

#399
post #376
post #315

Earlier quoted context omitted.

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...

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.

How's the experience putting it under your home? I assume many packages need to be compiled but does everything compile fine?

Re: Homebrew 3.0

#400

Earlier quoted context omitted.

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 be…

> 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 o…

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.

Post reply on HN