This is also true from the inverse. Making every tool visible may feel good to some users. They sit in their F16 cockpit, and they like having all those buttons, and knowing what they do.
But this does not scale. You can fit 100 buttons in front of you. You can learn each one and the best situations to use each. But can you fit 1000 buttons in front of you? No.
Different humans have different complexity thresholds. Some humans can deal with 10 buttons, and some 250 buttons! But no human can deal with 2000 buttons. There exists a hard limit on tool complexity.
If you want your tool to be useful, then as you increase the number of different humans that sit in your cockpit, you naturally must lower the number of buttons in front of them. The tools must tend towards invisibility.
If you’re a Java dev, and you try to force Java-isms into Go, you’re gonna have a bad time.
The Go philosophy http://go-proverbs.github.io/ pays off less in the short term, within a single file, or a single stdlib function, or with syntactic sugar to code golf 3 lines into 1 - it pays off in the long term, across time and people - and this makes all the difference
You’re right, that’d be a better test - and I think the gap between chisel and crowbar would grow even more. Chisel is effectively doing ssh tunnelling, with extra layers. Performance is lost in packet wrapping/unwrapping, reduced MTU but it shouldn’t result in more round trips
I was tempted to play the cat and mouse AV detection game though decided against it. It’s open source and with effort, one can make it avoid detection, but I’ll leave that up the reader
Port forwarding is fairly simple. All routers should support it. Forward port 443 to local-rpi-ip-address:443. Setup caddy/traefik. Create A record to public ip. Enable tls. Enable file hosting. Done: you now have TLS static website without any 3rd parties.
That said, cloudflare is super handy for dns, and for proxying specific domains, where you don't want to expose your public ip.
I use Docker (preview) on my M1 everyday for work and it's great. You can run `aarm64` containers natively, or you can emulate, for example, with `--platform linux/amd64`.
I'm guessing you're running into issues with C dependencies. You can go also go full Rosetta: create an alias to your terminal, right-click enable "Run in Rosetta", open it, then everything you run from this terminal will also be Rosetta (amd64), and you run Rosetta homebrew, node, etc. You can confirm what is running under Rosetta in Activity Monitor.
I've recently switched my default homebrew from Rosetta (/usr/local) to native (/opt), by switching my PATHs around since I was mostly waiting for go1.16 to arrive.
But this does not scale. You can fit 100 buttons in front of you. You can learn each one and the best situations to use each. But can you fit 1000 buttons in front of you? No. Different humans have different complexity thresholds. Some humans can deal with 10 buttons, and some 250 buttons! But no human can deal with 2000 buttons. There exists a hard limit on tool complexity.
If you want your tool to be useful, then as you increase the number of different humans that sit in your cockpit, you naturally must lower the number of buttons in front of them. The tools must tend towards invisibility.