I use Linux at home and package managers like AUR are great, but macOS is where the users are.
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.
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.
> alias sudo='echo not what I expected'
> sudo foo
not what I expectedEntirely likely it's user error on my part; but also problem I haven't really had with other 'nix package managers.
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.
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.
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.
Add this to your .zshrc or equivalent (f for fast):
alias brewf="HOMEBREW_NO_AUTO_UPDATE=1 brew"
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.
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.
I think these two might be somewhat contradictory.
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
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`.
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.
What was being responded to wasn’t criticism. It was whining without any substance.
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.
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.
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.
However I do full update / upgrades when it is convenient for me.
That's the point.
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'
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.
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.
MacPorts and fink existed before homebrew took over, and they weren't better. That's why homebrew took over.
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.
Maybe I was too dumb to use MacPorts, but all other MacPort used I knew back then all moved to homebrew very quickly.
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.
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.
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.
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." :)
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.
Just noting that people have strong opinions about the preferability of either approach.
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.
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.
As for better vs worse, let's just say that opinions vary.
No offense but we are talking about a "package manager" which:
- complained when you installed things in /use/local (where they belong) not managed by itself;
- had a flag to install packages somewhere else which broken half of the packages because they were so poorly written and no one was checking;
- messed with the permission of the file system for no good reason wahtsoever;
- would fail to properly update its own package list if you waited too long because the way they used git was broken beyond belief.
As I never had any of these issues with MacPorts, I might suggest you have a very low ceiling for what you call better. It pains me so much that you have to use Homebrew if you want to have recent packages.
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.
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.
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.
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.
https://github.com/Homebrew/homebrew-core/commit/82a45025682...
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.
How do you know someone uses Nix? They'll tell you :D
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.
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.
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.
Yours, A Noob
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.
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.
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.
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.
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.
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.
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.
I'd rather work harder at a business that succeeds and has equity that's worth a damn.
There's no world where that excuse is okay. It's also not all that related to Homebrew, though...
I’d certainly prefer to stay away from that type of hassle when I’m just trying to install a random package.
This is a conversation about ability level.
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.
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.
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
The had also apple silicon support for many things more than a month ago.
export HOMEBREW_NO_AUTO_UPDATE=1Two 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.
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.
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.
The thing is efforts like homebrew is basically the only thing that keeps Apple platforms as a viable developer's platform (without it it'd be intolerable, as Apple has zero official solutions for managing software not coming in pointy-clicky Appstore packaging) - and given that macs are still popular among many developers, it's a mystery why Apple corporate pays so little attention to it. It's like they sold a car without any tires and wouldn't even acknowledge the existence of tire manufacturers, let alone how vital they are for the actual users of the product.
<sigh> I know you're not unique in this assessment or consequence, and that's truly a shame.
MacPorts hasn't had as many of these issues over the years, and I suspect that's largely down to mindset. Broadly speaking, MacPorts seems to have "first, do no harm" approach to almost everything. They don't install files in directories they didn't create, and they avoid depending on systems which are out of their control.
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]).
https://docs.brew.sh/FAQ#why-does-brew-upgrade-formula-also-...
However brew does support your use case, but it take some extra effort. If you want to use brew to install an exact version of python you need to create a tap: https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap
Also, you aren't forced to use brew to install that version of python. You can do so yourself using the standard make; make install. It would be best to install it under /opt. Or use any other available method of installing software on your mac.
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.
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.
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.
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
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.
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.
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.
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.
>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.
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.
For sure Apple employees are using lots of homebrew every day :)
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.
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...
Nowadays they don’t want to touch anything GPL so that might be it
If Apple did it, HN would be awash in "Walled garden!" and "Monopoly!" hysteria.
Meanwhile, Apple is now engaging in anticompetitive behavior that I find frustrating. (App Store stuff.) Things have turned on their head.
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."
Also, to be fair to "graphic artists ... and the like", one of the reasons the Mac platform remained popular among graphics arts professionals through the '90s was that system-level inter-application scripting, added to the platform in 1993, was well-supported by both Apple and third-party application vendors, whereas analogous cross-application scripting in Windows was mostly limited to Microsoft Office products.
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.
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
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.
[1]: https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
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.
I'll stop him right there. Definitely not googley.
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
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.
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.
Some things are not in google's DNA.
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.
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.
Honestly I can't imagine using my mac without Brew.
Thanks to Mike McQuaid (et al) for the last 10!
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.
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.
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)
[1]: https://lna7n.org/2020/01/06/pulling-the-plug-on-archmac.htm...
[1] Max Howell, https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
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.
Windows is where the users are, and apt-get works just as well on WSL2 as natively.