331–340 of 380 posts
Ah, I was excited by 'sandboxing on Linux', but it's only for build. How many more supply chain attacks will it take for someone to build a really great sandboxing/permissioning system, that's easy enough to use that we actually use it? Say I install an `ls` alternative (because it's on the HN front page as 'ls but in lang du jour' or whatever) – it should be really simple for me to allow it read-only access to only…
Ah, I was excited by 'sandboxing on Linux', but it's only for build. How many more supply chain attacks will it take for someone to build a really great sandboxing/permissioning system, that's easy enough to use that we actually use it? Say I install an `ls` alternative (because it's on the HN front page as 'ls but in lang du jour' or whatever) – it should be really simple for me to allow it read-only access to only…
Sounds like a great idea, thanks for volunteering to pitch in and help!
Earlier quoted context omitted.
Maybe among the general mac population they are a rounding error. But among the mac population who actually peeks behind the curtain and uses homebrew?
Yes, to such a stunning degree that I’m having a hard time believing you’re serious. The M1 was utterly transformative. The install base of homebrew is enormous. The proportion who are keeping old Mac hardware around as home servers is minuscule. The proportion of those who are keeping old Intel Macs are a fraction of that, and the ones who aren’t just running Linux on them are yet another fraction. That’s not to say…
Intel homebrew is larger than Linuxbrew, yet I think it'd be shocking if they dropped support for Linuxbrew.
Old machines still work. They're still deeply useful. I'm still using daily an Intel Macbook with homebrew on it. When I no longer use it daily in some years more, it'll still make a perfect server.
Does this handle macOS installs with multiple local users? I have to su into account 1 if I want to brew install something from account 2
brew as-console-user may help here. We don’t support a multiuser setup so there may be some limitations but we try our best to address problems as they come up.
> as-console-user command [args …]
> Run a Homebrew command as the active macOS console user.
> This is intended for MDM, Munki and Jamf workflows where brew is invoked as root but Homebrew operations should run as the logged-in console user. The nested command is always dispatched through HOMEBREW_BREW_FILE.
— https://docs.brew.sh/Manpage#as-console-user-command-args-
This isn’t very informative. Is there more documentation somewhere else that I’m missing? Google search doesn’t really find much.
I currently have a dedicated `homebrew` user that I access with `alias brew='sudo --set-home --user=homebrew --chdir /Users/homebrew -- brew' but it’s got a number of shortcomings. What will as-console-user do differently to this?
Earlier quoted context omitted.
That's kind of weird that you're using this announcement to steer people to another project. Or am I missing something..?
I agree, but HN doesn't like metacomments that just complain on how an article/comment is being upvoted, hence you being downvoted. See guidelines: https://news.ycombinator.com/newsguidelines.html Just downvote and move on.
Earlier quoted context omitted.
So the incident really happened lol
Ostensibly it did. But worth noting that despite many people still thinking of Max Howell when they think of Homebrew, he hasn’t been there for a long long time. Pretty sure he wasn’t there at the time of that Google interview, even. Mike and all the other contributors deserve much more credit for Homebrew. There are even contributors who since left who were there for longer and had a bigger impact than Max. And he h…
I'd personally love a "Homebrew light", compatible with most of the ecosystem (sans git taps, Ruby formulas and binary packages), written in a language with fast startup times, not keeping unnecessary files on disk, with support for parallel downloads, and terminology that is much easier for the newcomers to remember and keep straight.
Earlier quoted context omitted.
Apple employees did. Not Apple themselves. As for hosting, it was hosted on an equivalent of SourceForge, where many other opensource projects unaffiliated with Apple were. And we all know how MacPorts failed to actually gain any significant momentum.
No, Apple employees originally authored the project on Apple’s time . And it was first hosted at OpenDarwin — which was Apple-run and not available for arbitrary public hosting. It was then hosted at OpenDarwin’s successor — Mac OS Forge. That was also Apple-run and not available for arbitrary project hosting. MacPorts was an Apple-authored and ultimately Apple-supported project for ~15 years. As for momentum, the pr…
I am referring to a significant momentum. You know, like the momentum Brew has.
Earlier quoted context omitted.
Maybe I’m just biased because it’s what I’ve done personally, but almost everyone using an old Intel Mac as a server is surely running Linux?
If your clients are all macs it is just nicer keeping the server on macos imo. mac os is unix after all so you don't have any software incompatibilities for tools you'd probably run on the server. Time machine support on the server is built in, instead of being a sort of hack with samba if you wanted to try and run it on a linux server. I haven't messed with it much but there might be some clever stuff you could do w…