That's a good way of verbalizing how I've felt with the last few iterations of macOS as well as Homebrew's perpetually changing behavior. Most of it feels like change for the sake of change. I've also used FreeBSD for several years, and it's the opposite approach - everything that used to work still does, and things are well-documented. Usually the man page is enough, or the FreeBSD handbook.

It's still all just Fire and Motion [0].

[0] https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

The interesting thing about Homebrew is that there were perfectly good systems before it that were more stable and better designed (Fink and Macports, neither of which install to /usr/local) and apparently the only reason people switched to Homebrew is that it was "cool" because it was written in Ruby.

When I switched to MacOS (about 11 years ago) I tried Macports first, but ended up with Homebrew because Macports required me to learn more things than Homebrew required of me before I could successfully install the 10 or so small command-line packages I wanted to install. (At that time, Fink was lacking a maintainer IIRC.)

Note that I didn't want to take the time to try to determine which one had the better design and engineering.

(I didn't not know or want to learn Ruby when I made the decision.)

Also, it displays a cool beer emoji when you install a package. And colors! Fancy colors and progress bars. And no sudo, except when needed of course.

And then goes the Ruby factor, of course.

It ticks all the important dopamine checkboxes of a MacBook-wielding, Starbucks-resident hipster type who has just purchased an .io domain and is ready to code their world-changing app.

Took me a while to figure out how to disable this stuff.

After years spent with Linux, then with macOS, my solution has been to finally move to Windows 10. My linux subsystem is as stable as I want it to be, I have full control over it. It takes a bit of time to get used to the Windows world and find the good GUI tools, but once you get more familiar with it things work ok. And Windows doesn't break my system with every upgrade the way macOS does (the things that change over time are mostly UI updates, not fundamental changes).

That's not for everybody, but after ~1.5 year I can say I'm satisfied with my choice, WSL has really been a game changer.

> As a hacker, it's particularly frustrating to feel at the whims of someone else.

Isn't this the very definition of what a hacker is - somebody who finds creative ways to get things done with systems they didn't create and don't control. If you are pushing the boundaries of a system, you have to expect that sometimes the underlying system stop supporting you

A guarantee that the system you're "hacking" on will always continue to support your customizations in perpetuity as it updates seems to me to be the opposite of the hacker ethos. That's not hacking, that's using a system in a supported manner.

Before going to Windows, I left Homebrew and went back to Macports for a couple of years.

It did everything I needed and while you might argue that writing a Ruby formula is easier than packaging something for Macports, it was a feature I never really needed compared to the ability to easily install specific versions of software going as far back as I needed. Much more akin to the Debian approach, but with faster updates for newer versions.

But, as a hacker, I agree. If it's not neatly wrapped up for you by a package manager then you're perfectly equipped to pull down a prebuilt binary from a repo or compile it from source. If I felt at the whim of the apt package manager I'd still be complaining about the lack of XDG support in tmux, instead of wget'ing a tarball and doing a good old make && make install.

I like this approach and thought about it as well.

The only thing holding me back is that it's just so much effort. It's frustrating that we need to work-around MacOS. That's why I decided to refuse to update and I want to sit out Mojave until EOL. There are a few known problems, but the workarounds are well known. My experience has been good so far.

> I think my next setup will be using my (company-issued) macbook as a thin client against a beefy unix machine. That way I'd keep a number of affordances (trackpad, iTerm, fancy Emacs etc) while having my core tooling absolutely stable.

You mind going into a little detail on how you’ll go about this?

So I'd have th unix box and macbook both at home, networked locally.

In the macbook I'd try hard to have no npm/rubygems/maven/... because these are all a security risk.

The unix box would be heavily firewalled so that no bad code could not talk home or reach my macbook.

Communication would happen primarily via ssh (e.g. macos iTerm -> unix box), but also as a NFS share so that I can edit files from my IDE flawlessly (I use Emacs which has a thing called Tramp which makes this unnecessary, but I'm hesitant about its effectiveness).

So, in my macbook I'd have a small number of trusted tools like iTerm and Emacs while everything else, like Ruby/node.js/Java/postgresql processes would happen in the unix box. My workflow would be typically:

- edit files to the NFS share;

- issue commands to the unix box via ssh (an IDE can abstract this away); and

- have some port forwarding for accessing e.g. the webapp I'm working on from macOS chrome.

In the end it would be a pretty vanilla approach and not tremendously different from using a virtual machine via Vagrant. The difference would be that the macOS machine would be thinner, and that the unix box would have greater focus on security and stability.

And of course performance - with a real box I don't have to worry about Vagrant/Docker/... making my macbook overheat.

Not OP, but I've dabbled doing just that with a Digital Ocean droplet and using VS Code's Remote SSH extension. It's not lag free, but it's nice being able to access the same dev environment from multiple computers.

Good luck getting this new feature worked out while on a long flight. Remote dev setups are nice, until internet is not being nice to you (either non-existent or wobbly)

Ignoring the last year, how often do you need to code while flying. I can't even use a laptop in a seat unless I pay extra for the extra leg room seats.

As someone who used to live on another continent as where my employers office was, I coded while flying at least 6 times a year, sometimes even more.

And while most would not fly that often, being able to code when internet is not available or in a bad shape is not only a 'nice to have' option, but almost a 'must have'

Thanks for sharing!