Great job!

Would be nice if the messages are formatted with just date, sender and message and the metadata is hidden in a popup or whatever.

Thank you for the feedback.

Unfortunately it's several thousand raw text files, and determining a single relevant date, sender and message for each file is a bit more complex than I had time for this week. Next week we'll make the files more readable, ingest & display the images, amongst other usabillity improvements.

I also hate it. Cant read it properly on mobile and cant copy it if needed.

But the worst thing is that these are not even real screenshots, the author pasted the text into some terminal window screenshot generator tool.

The problem is Whatsapp is now being used more and more in a professional context, even in Europe, and it's just not a pro software by any means. Searching for old messages is a pain, the web version is slow, there is now optimized overview or folders, etc...

And now it seems that there is not even a benefit to installing the native vbersion, they will probably do the same for Mac also now.

My Brazilian friend told me they use Whatsapp as a replacement for Slack since they don't want to pay for Slack As an Indian, I can confirm the same here for many companies

is there no way to disable this on mac silicon?

Im still on intel, and its ok here, but once I switch, will there be constant headaches and fumbling around because of this?

if you read any old issues on the homebrew github you can see how these maintainers are always very aggressive and anti-discussion, especially the main guy.

Homebrew is not really pro in any way: they force updates, deprecate old software that is still widely in use, the maintainers are always very combative and dont allow any discussions or other opinions.

In the end it's a package manager for consumers that hand holds you and is not really useful in a pro context.

I've been meaning to jump to macports anyway, maybe ill do it now...

So-called “homebrew” has only ever grudgingly provided the barest minimum of hooks to locally build your own variants of their packages, and compares most unfavourably to, say, maintaining your own easily-rebased fork of a BSD-style ports tree. Don’t even get me started on its janky dependency resolution, versioning, “services”, and lifecycle.

The hostility and self-righteousness from the maintainers in the thread linked above just adds to the general shittiness of using it at all, and yet somehow it seems to be the lowest common denominator choice for far too many teams I’ve worked with, I suppose by sheer inertia.

I started on Macports 20 years ago, switched to homebrew because it was the new thing, and this year switched back to Macports on a brand new M4 mini, after having this gnawing feeling that I should have never switched after installing Macports on a PowerBook G4 running Tiger and building something relatively modern from source without any problems.

I know, is there any point in calling it Homebrew anymore when it's like an extension of the App Store?

As someone who migrated from macports to Homebrew, I'd like to see a third option (or maybe re-investigate macports again to see what's changed recently).

Homebrew's insistence on leaving OSes behind that they deem to be "too old" is becoming a problem as the years click by. One of the reasons to use third party software and a third party package manager is to avoid Apple's own insistence on abandoning old OSes. Homebrew following their example is very disappointing.

EDIT: From the linked issue:

    "Intel support is coming to an end from both Apple and Homebrew."

Deeply, deeply disappointing. I know Open Source doesn't owe us anything, but this seems like a terrible turn for what was once great software.

Nix is sort of that third option, though I really wish there was a well-documented way to use it on macOS as purely a binary/source package manager. A lot of stuff I read online goes into setting up nix-darwin to manage desktop settings and etc. and I just don't need or want that.

That being said, if you haven't used MacPorts in years, I'd say it's worth the jump. I recall moving from MacPorts in the first place because Homebrew was faster and allowed for customising packages.

When I switched back to MacPorts again, it was because Homebrew had become slow and no longer allowed package customisation. Now, MacPorts is much faster and has the variants system for package customisation.

Thank you for this helpful information. It might be worth a try. I initially moved to brew because it was "new", because I liked the command line interface, and because it seemed more "segregated" from the rest of the OS's files (/usr/local/Cellar and so on). But it's increasingly aggressive messages reminding me I am a second-class (or third-class) citizen due to the age of my OS is really off-putting.

I actually migrated from Homebrew to Macports after ending up in dependency hell in Homebrew with Postgresql + Postgis, and not being able to fix this properly even with my own brew recipes.

So for now that works a lot better in Macports. The portfile stuff needed some digging to understand, but that's doable.

Not sure what made you move from Macports to Homebrew. (Should I worry?)

"Homebrew's insistence on leaving OSes behind that they deem to be "too old" is becoming a problem as the years click by"

Indeed! I have a VERY usable Macbook Pro from 2015. Even with the newest version supported macOS version (11) Big Sur (which is still quite modern) it doesn't have any binaries for apps, which means it has to compile every single app and dependency.

I managed to update to macOS 14 (with the help of OpenCore Legacy Patcher).

But this just buys me one year to use Homebrew. Next year they will retire macOS 14.

And my machine is still very usable, but it will become junk from a developer perspective unless I have homebrew (or something similar).

It annoys me because I think this problem is fixable. Either community repos or more donations to homebrew to compile apps for older macs.

It's too bad that homebrew adopted the "Apple Attitude" around dealing with legacy OS versions. I don't recall ever seeing a message while working in Linux saying "Oh, you're using an OLD version of Linux, that's unsupported! You're a Tier-3 Loser and we don't guarantee this is going to work!"

Even developer tools on Windows tend to be fairly graceful about you running Windows 7 or whatever.

Somehow Apple and their entire ecosystem has adopted this "Latest Version Or GTFO" attitude towards users and developers.

I went through the same experience with an old macbook. Switching to macports solved that problem.

How much are you willing to donate before concluding it's more efficient to just buy a new MacBook? Even the cheapest models now are faster, more energy efficient and more secure. You don't have to throw the old one away if you can find a use case for running old software but I don't think there are many people running 'power user / developer' like tasks on old hardware, especially if their jobs depend on it.

> I'd like to see a third option

Nix, perhaps?

Also Pkgsrc

if you're good with tools that don't support global installs there are also Spack, Mise, and pkgx

none of those are quite suitable for managing macOS app bundles, though.

Make Fink modern. ;)

(Part /s, part not)

Honestly conda does a lot of heavy lifting for me. I know people have strong feelings about it on here but it works great for my purposes.

What is the pro vs consumer distinction here? What consumers use homebrew?

im talking about developers for example, that may need specific/old versions of php or node or whatever, which then get deprecated and uninstallable via brew as soon as they officially reach EOL. Or once installed, get forcefully and inadvertently updated by brew.

On the other side is some consumer who uses brew to install youtube downloader and doesnt care about versions/upgrades, etc...

If you are a developer who needs a specific old version of PHP or Node or whatever and you're not using Docker then I have great news for you on how you can solve your problem.

When all you have is a hammer, everything looks like a nail.

yes, docker is a great solution nowadays for this problem, but it wasnt always like that. In PHP land there is a tool called Laravel Valet, which relies heavily on homebrew and lets you switch PHP versions on the fly directly your system. I just remember how much of a pain it was to set up because of homebrew's unnecessary restrictions and deprecations. But once done it worked quite well.

so don't use brew at all? Great, what else should we not use?

I personally use and enjoy Homebrew for most of my development tasks. The thing I would not use it for is to exactly simulate a specific combination of tool versions.

Yes. The package manager's job is to give you some sensible version of some useful common standardized thing(s) you want to use. There might well be some legacy/current/edge options, but overall you are putting your trust in their judgement and assuming that they'll do something at least vaguely sensible.

If you want something specific than that: the package manager cannot help you here. This is no longer some random thing that you just use; it's one of your product's honest-to-goodness dependencies. You can't outsource this any more. You need to make your own arrangements to ensure that the specific version required is in use.

It works until PHP officially EOLs the version. Then brew stops supporting it and you have to install some finicky 3rd party taps/repos to get the older versions. A huge pain...

In the real world there are still apps running PHP 7.4 and even older!

I seriously can't accept this as valid criticism.

Homebrew not allowing users to install EOL versions of software with no security patches or updates is a _good_ idea. Just because a fraction of a tiny minority needs some ancient version of PHP doesn't make it a good idea.

yea, that's why it's not "pro" grade, and that's my point.

"pro" users need EOL version support because sometimes some client still didn't want to update his age old web app the newest node or python or whatever. sometimes it's not up to the dev himself, and he needs to make money either way.

so in the end brew makes decisions for the most common denominator, and that will be the user that uses it to install youtube-dl and nothing more.

“Pro” users are using containers, venvs, version managers (nvm, rvm, etc.). They definitely aren’t installing project-specific stuff directly to the system.

> is not really useful in a pro context.

Huh, I guess I didn't use it in a "pro" context for 14 years then? Must have imagined that.

But what about the resale value??

The bag will turn blue

You have to go deeper than that, I think in the end our whole species’ goal is growth at all costs and this is subconsciously baked into every decision we make…

Its crazy they didnt even use any expensive materials to maybe somewhat justify the price.

Just the cheapest stuff you can get away with.