I've been there, being forced to use it for work..

I tried both Yabai and Amethyst and, frankly, neither provide a clean experience.

Yabai requires disabling some OS security feature iirc, which may or may not be an issue for you. I seem to recall having issues with it, and switching to Amethyst pretty soon after. It might also only support BSP layout, which I dislike - stacks all the way.

Amethyst feels a little half baked. It works well enough, but configuration is through a GUI and saved in some non text format, making it not difficult friendly. It also doesn't support things like moving windows between workspaces, meaning you need to have additional bindings for that through the MacOS command center or whatever it's called.

Overall, I managed with Amethyst for close to 2 years, so that's the one I'd recommend of the two. Luckily I'm back on a Linux machine and can use river now. :)

Good luck!

> It also doesn't support things like moving windows between workspaces

It's been a while since I used Amethyst as the Mac is now on complete corporate lockdown, but I remember that being the biggest feature I used on Amethyst. MacOS doesn't support it, but Amethyst did.

I lost my Amethyst due to corporate lockdown rebuild a few weeks ago. MacOS window management is obnoxious without it and I'm much less productive due to losing my tools.

I am likely misremembering, and mixing it was something else! There definitely was something vital I wasn't able to do through just Amethyst though.

I can recommend Runbox. It's a paid service, but I really think that's for the better.

The exact same as if npm did it.

But this can literally just be done in a simple shell script as well. The makefile ends up just being a redundant way to run a shell script.

> But this can literally just be done in a simple shell script as well.

Only if there's no dependencies. It's unusual that GP's type of usage has no dependencies.

When my shell scripts depend on another script ... they run the other script. Make definitely has its place, especially when dependencies get complex and parallel, but it's hardly necessary for simple cases. Once Make is needed, it's trivial to drop in and have it wrap the standalone scripts.

> When my shell scripts depend on another script ... they run the other script.

I hear you, but you're running the other script unconditionally. If it downloads something, it will download it every time you run the first script.

In this simple case, make runs the other script conditionally, so it need not run every time.

I build .tf files from parameters for each host in the Makefile (and script which knows the vSphere topology) for one-shot execution (it only creates the VM, it doesn’t manage the lifecycle) and also template config that needs to be done before deployment - there are plenty of dependencies

Vendor support.

Shipping with Linux is a good indicator that it's Linux compatible. Buying computers with Linux is also a way of voting for Linux compatibility - even if you reinstall your preferred distro afterwards.

How would me answering how I once "reacted to xyz" make me any more likely to "put the extra neurons in"?

Those types of questions are likely to engage "problem solvers", aka people who don't just wait to be told what to do, but who actually demonstrated proactive critical thinking by reacting to a challenge. Those types of people are more likely to put extra neurons in for future problems (contrary to stock markets, past performance is actually a strong indicator of future success, when it comes to hiring).

If you don't have any scenarios from your work experience where you can demonstrate being a "problem solver" who reacts to stuff, then you probably aren't someone to likes to fire up the extra neurons, and hence wouldn't be a fit for the parent comment's desired team/org profile.

And the only way to mitigate the cancer that is GitHub is to normalize contributing elsewhere.

Then don't just send a PR: maintain your own fork.

I think that's the bigger part of open source. You can fork it, change it to your needs, and not give a damn what anyone else thinks about your changes.

Oh, that other open source trope, I should publish a book.

Because maintaining an entire fork of any non trivial software is... trivial :-)

Let's just admit that these are complex problems and frankly after watching the hype for almost 20 years, open source proved to be an alternative and a good refuge for many things but on the end user side the early hype until 2008 or so was 80% wrong.

If you truly believe it to be trivial, you should just do it rather than complain.

If you don't, then you can't justify putting more work onto the maintainers of upstream for changes they may not even care about.

Is this any different from other alternate YouTube apps like NewPipe?

Newpipe scrapes the HTML, its against the ToS but harder to block.

Scrapping HTML can’t be against ToS…didn’t that judge ruled it legal to do in that case against LinkedIn?

It can be against the ToS, but ToS aren't legally enforceable in a court of law.

NewPipe is also not being sold.

What would be the big gain from this, over the existing approach using multiple return values?