Hehe, the classic rude and mean behavior from homebrew maintainers.
I get their motivation to remove the flag. In fact, it has always been better to run xattr in postinstall, this way the binary is free from quarantine even after updates.
But the way they communicate with people is unacceptable and just unnecessary.
Reading that discussion, I was very surprised at MikeMcQuaid’s reaction to xtqqczze’s concerns, which were calm, brief, and valid. In response, Mike was a dick.
Maybe it’s totally understandable that being a maintainer for the biggest mac package manager conditions a knee-jerk asshole response in a person.
There's a misunderstanding here what the issue tracker is for in Homebrew. In some projects, it's for free-for-all discussion. That's great if those projects want to use it that way.
In this issue's case, you have someone in leadership (p-linnane) communicating that work needs to be done, a maintainer (carlocab) communicating what needs to be done to make this change. xtqqczze's attempt to get us to move backwards on an already made decision doesn't help anyone. We have a discussions forum (and, well, the rest of the internet) for discussion of the pros and cons of decisions made. There's no point maintaining the illusion that we're soliciting feedback or discussion on the issues tracker when we are not.
As to me being a dick: I've been maintaining Homebrew for 16 years. It's used by millions of people. My full-time job has never been doing so and I've never been paid a market rate for my work on it (not that I expect or perhaps even deserve so). My primary concern with Homebrew is keeping the project actually running. This primarily requires the time, energy and work of maintainers doing so in their free time. It also requires contributors who submit pull requests.
Go read through some merged pull requests some time and you will see moderately to very positive responses from me. That's because that's the work that keeps the project alive. It has almost died several times in the past and I've kept it going. You may think it hyperbolic but drive-by negativity by non-code-contributor users is the biggest existential risk to projects like Homebrew.
Thanks for the response. Yes, I think some clarity about the purpose of the issue tracker would help someone unfamiliar with the project's maintenance better understand the conduct of the maintainers. If it is only for coordination of work tasks and not discussion of whether the work should be done, it would seem natural to have somewhere else where the discussion of the merits occurs.
> drive-by negativity by non-code-contributor users is the biggest existential threat
I do believe this, and it's what I was getting at with my "conditions a knee-jerk asshole response" comment. From the outside, I saw someone who wasn't being negative, but just seemed to have unaddressed concerns about the impact of the change. You, however, have been conditioned by hostile users over your many years of work to interpret this as negativity, because other, ruder people pile on to the valid concern in unhelpful ways, or the person with the concern wasn't willing to listen at all and just used a veneer of calm rationality to be a stick in the mud.
The point is, I get why you would be this way, but also that it doesn't look very good from the outside looking in. I know that you are doing unpaid labor and so nothing is owed, but still, both can be true.
I know some people don't like it, but I've always found discussions that are locked to collaborators only to be totally understandable for this reason. If you find yourself making "I know more about x than you ever will" comments to a person, you should probably instead just disregard them and carry on. Likewise, you do know more about x than I ever will, so you should probably just disregard me and carry on.
> There's no point maintaining the illusion that we're soliciting feedback or discussion on the issues tracker when we are not.
You could have just said this (maybe you did when linking the code of conduct) instead of writing a paragraph of confrontational arguments and it would have looked way better imho.
> You may think it hyperbolic but drive-by negativity by non-code-contributor users is the biggest existential risk to projects like Homebrew.
If this was true every oss project would either be dead or be entirely comprised of dicks, neither of which are the case.
Yup, you're right, I should have. We will adjust the CONTRIBUTING.md accordingly.
> If this was true every oss project would either be dead or be entirely comprised of dicks, neither of which are the case.
I didn't say every OSS project, I said projects like Homebrew. I know that Homebrew would be dead without many of my personal interventions. You can believe me or not but, unless you're a Homebrew maintainer, it's unlikely your opinion about what happens behind the scenes is informed.
> As to me being a dick: I've been maintaining Homebrew for 16 years. It's used by millions of people. My full-time job has never been doing so and I've never been paid a market rate for my work on it (not that I expect or perhaps even deserve so). My primary concern with Homebrew is keeping the project actually running. This primarily requires the time, energy and work of maintainers doing so in their free time. It also requires contributors who submit pull requests.
your explanation did nothing to speak to being a dick, did not attempt to apologize, only tried to justify the poor behavior.
I don't think I am a dick, I guess that went without saying.
I'll take critique from other maintainers who have done as much or more open source work for similar returns over similar time periods. Funnily enough, I'm friends with many, and they are supportive the vast majority of the time instead of critical. Maybe that's because they can relate and you cannot.
No one thinks they are a dick. But you are. At least in many instances as many of the comments here and elsewhere point out. I had similar experience trying to start a discussion about something in one of the Homebrew repositories.
The fact that you have many friends who confirm your bias of not being a dick...means exactly nothing. You have people telling you your words made them perceive your comment as being arrogant/blunt and your reply is: I'm successful open-source maintainer and have many friends who think I'm not arrogant and I only take critique from them. Have it your way. But in my eyes, you're being a dick. (Don't misinterpret this as my judgement of your engineering skills. I love Homebrew and it's an incredible feat. Congrats.)
If you love Homebrew, maybe you might want to consider if repeatedly calling me a dick or arrogant/blunt is a particularly nice way to treat someone who spends their spare time building software you rely on.
This, this is being a dick. Holding your project hostage because you want to flex your power over someone. It's entitled behavior. Glad I moved to MacPorts years ago.
It's good to have more documentation on Zig by the community, but I'm gonna throw in a bit of criticism.
One major thing I appreciate about the official Zig Language Reference is that it is no-pagination single html page that I can ctrl+f https://ziglang.org/documentation/master/ I wish more projects published their docs like that.
When I read, my mouse is busy selecting different parts of the text that I'm thinking about.
1. I don't want to move my mouse off the text to click the "next" button.
2. I don't want to move my mouse off the text to expand TOC items.
3. I don't want to waste my time on switching between pages back and forth.
I prefer the raw text on a long scrollable, non-interactive page with TOC on the side.
Otherwise, great to see more guides on the Zig topic.
Well, you can't have different configs for different hosts. Other than that, I can't quickly recall what other limitations are, I see none. I really like the simplicity of the "pure git" approach.
My dotfiles repo dates back to 2018, I'm happy user of this git one-liner for the past 6 years.
Might be niche but for me - I have config files outside $HOME, I use a number of `.gitignore`-aware tools (tree, fuzzy finder), and I just don't like `git status` telling me I'm in a repo in any subdir of $HOME.
I agree that signing by a central authority makes sense. As the readme mentions, I don't have anything against notarization as a concept.
I specifically don't like how painfull Apple does it. (Google for "notarization hell macos")
This is my pet project that I do for fun and for free. Bowing my head to Apple every time I want to release a new version is not fun.
Waking up in the middle of the night, because Apple revoked the app (https://github.com/nikitabobko/AeroSpace/issues/167) is not fun.
AeroSpace is a tool for developers by developers. Developers can audit the code and install the app from sources
1. The "AeroSpace" name means a space for your windows without friction
2. I myself consider the virtual emulation of workspaces to be the strongest feature of the AeroSpace. If I could disable the workspace switching animation in yabai or Amethyst (with SIP enabled, of course), I'd probably not bother myself creating AeroSpace. That's what the "space" part in the app name means. It resembles the strongest feature of AeroSpace - workspaces
re 2: an added benefit of not using actual macOS spaces is that it seems (at least from my limited usage) to be much more reliable than yabai (not blaming yabai here, of course).
I also tried implementing an i3 like workspace numbering/creating on top of yabai - it was an uphill battle due to how limited native macOS space management is and I never finished, so thank you for creating AeroSpace :)
I actually use it in tandem with yabai now - I added an "exec-on-window-hide"[0] option similar to "exec-on-workspace-change", and use it to make the hidden windows transparent (and to make them visible again)[1].
I wonder if hooks like that would be a good way to have a nice middle-ground to let people who don't care as much about SIP to extend upon AeroSpace's model?
I'll probably send over a pull request for your consideration soon.
> Windows get repositioned by normal interactions and the window manager is not able to wrangle them
I'm certainly biased, but no, I don't face issues like that
> and connecting external monitors is a disaster
Connecting and disconnecting external monitors is an important use case for me as well. I dedicated my time to support specifically this case, so hopefully it works correctly for other users as well
I'm a long time Amethyst user, but going to try AeroSpace out!
Based on the documentation the toml syntax is stretched quite a bit to implement some logic and callbacks. Have you considered some scripting language to make it easier to do, or is the need for this kind of advanced use so little that it's not really a problem?
When I started the project, I kept it simple, so I started with the static config
The complexity of the config has grown since then, with the bigest (and, actually, the only) problem being on-window-detected callback as you mentioned.
I've been thinking about using a scripting language like Lua, but I haven't made my mind yet whether it's worth it
I'm curious whether you've figured out a good monetization strategy for Atuin. The article doesn't answer that question.
Like you said, you won't be paying your rent with sponsors any time soon, but you've already quit your job. Are you living on your savings, and trying to come up with valuable paid features meanwhile? Is it the plan?
Anyway, good luck with whatever you're up to! Building a good monetization strategy is hard
