Hacker News Reader

Comment by nothrabannosir | Hacker News Reader

Honestly, as both a Mac and a Debian user, I’m not sure which one I prefer. I understand your frustration, but random strangers not being allowed to push updates to my operating system in 5.34 seconds doesn’t sound all bad. To me.

(Obviously not that TFA paints a rosy picture..)

View on HN

Those changes are reviewed by maintainers. The fact that a random stranger is able to push a change and get it reviewed, approved, merged, and available in minutes should be the goal of most open source projects. On the contrary, older projects tend to be too reactionary when it comes to infrastructure tools, so in turn they get very slow interactions. This becomes a demotivator for anybody who is used to more efficient workflows.

It is not a coincidence that the author became demotivated after doing some professional experience.

> The fact that a random stranger is able to push a change and get it reviewed, approved, merged, and available in minutes should be the goal of most open source projects

> On the contrary, older projects tend to be too reactionary when it comes to infrastructure tools, so in turn they get very slow interactions

Well said.

'Open source' doesn't say anything about infrastructure. But it's just as important.

> The fact that a random stranger is able to push a change and get it reviewed, approved, merged, and available in minutes should be the goal of most open source projects.

That sounds like a security risk to me.

How much safer is it if pushing in a malicious change takes two months?

I had to re-read it too. He does not say that the same dev should do all these things

> but random strangers not being allowed to push updates to my operating system in 5.34 seconds doesn’t sound all bad. To me.

So that's what the frustrating to maintainers crumbling infrastructure and crappy tooling are for. Now it all makes sense!

Actually, I'd very much prefer quickly pushed updates in case of severe security issues. Debian had lots of really ancient packages with problems in "stable" last time I looked.

If there's a severe security issue, Debian will quickly push an update containing a backported version of the fix, assuming you have the debian-security repository enabled (which you should). Just because the version number on the package is old doesn't mean it's insecure.

https://www.debian.org/security/faq#oldversion

The problem is: what defines a security issue. A developer (more often then not) doesn't know if a fixed bug could have lead to a security issue.

You're misunderstanding the point of Debian.

Debian's "stable" release is that. Stable. No updates are issued for packages except for critical security updates, which are backported to the released version.

It's essentially an LTS release. This isn't what everyone wants or needs, but if you do, Debian does it very well.

Homebrew is effectively a "rolling release" with fast turnover of package versions. So in that sense it's not directly comparable to Debian stable (or even unstable). That rapid turnover has led to numerous breaking bugs over the last five years or so that I've been using it. It's a lot simpler, but it also lacks the sophisticated versioned dependencies which dpkg/apt provide. Both have their tradeoffs, but I wouldn't want to use Homebrew for anything serious; it can break at any moment, and can be very painful to manage. It's got better over the years, but still has some way to go to match up to Linux package management.

Try macports for a BSD style packaging for the mac.

What's the advantage of using macports over Homebrew?

For example proper runtime dependency management?

Try updating a single homebrew package to a new major version and watch the other homebrew packages depending on it breaking.

To be fair, that's not a problem unique to homebrew. Gentoo used to break runtime dependencies, too. Although that was a long time ago. Nowadays libs used by other programs are preserved and only deleted when all dependencies have been updated, so breakage no longer occurrs.

For one, it works just fine on multi-user Macs as it installs software under the uid/gid of the user who installed Homebrew somewhere under /usr/local whereas Homebrew installs it the proper way as root:admin and doesn't create a shitload of permission problems.

I can't understand whether you're saying Homebrew does it right or not on multiuser systems.

I have a lot of trouble with Homebrew on multiuser Mac systems. Running `brew install ...` or `brew update` as anyone but the user who originally installed Homebrew almost always fails because of permission errors (or it successfully installs, but then causes permission errors in the future for the user who installed Homebrew). Whenever I need to use Homebrew commands now, I use `sudo -iu otheruser` to switch to the user account who first installed Homebrew in order to avoid the permissions issues. I'm really baffled that Homebrew doesn't support the multiuser system case. Is it so rare to share a system nowadays? I've had this issue on multiple Macs and fresh installs, so I don't think this is some fluke bug.

I’d argue that Debian’s “stability” should be a process/policy thing. It should be orthogonal to the tooling. Just because you have a “stability-first” policy doesn’t mean you should be enforcing it through crappy tooling.

Reply on news.ycombinator.com