jpillora

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.

The problem with git ops only manifests after it’s become a standard within an org:

With 1 git ops pipeline, it’s fine, it’s the human merge gate, it’s doing its job protecting downstream

With multiple git ops pipelines however, they start to get in the way of progress - especially when they need to be joined in series

The better approach is to build API-first then optionally, add an API client into your git pipeline

This is not the Go way. This abstraction appears to come for free, but it does not.

Simple backoff ftw https://github.com/jpillora/backoff

They're different things, solving different problems:

- Containers are wrappers for binaries. Any binary can be contained, and when run, it gets a constrained (fake) view of the kernel.

- WASM defines a portable binary format. WASM is intermediate-representation, in the same vein as Java byte-code.

You could reasonably put WASM binaries inside containers

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

See also https://github.com/jpillora/md-tmpl

Please make a live demo version of this using only JavaScript and HTML :D

RIP Stefan

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

Correct, it’s equivalent to ssh tunneling except there’s some HTTP/websocket wrappers around it

That’s exactly what it is, see releases

Tailscale is a virtual network device (works on L3, tun not tap device) whereas chisel just listens on ports (works on L4)

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

Hey all, I’m the author of chisel. Feel free to send any questions my way

Relevant https://securitycryptographywhatever.buzzsprout.com/1822302/...

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.

Interesting, thanks for the reply

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.

This. And now begins the decline of x86 and Intel.

Demo shows root shell. So an attacker could simply install a RAT into /Library/LaunchDaemons and it's permanent.

Any know much about Nova, and how hard it would be to integrate the Go Language Server with it? seeing as it conforms to LSP

MikroTik have recent added support https://forum.mikrotik.com/viewtopic.php?f=1&t=165248

Do not use this. Full of Go anti-patterns.

See also https://www.sharedrop.io/ (WebRTC-based AirDrop clone)

The lost master key problem is addressed here: https://www.grc.com/sqrl/idlock.htm

Does this include AppEngine?

I remember trying run SSH (the current TCP multiplexing protocol) over straight HTTP and found there were issues so I added WS to the mix. There probably is a way to do it though it does the job as is.

No, TCP has not been reimplemented.

It doesn't. I'd like to support UDP at some point, maybe rewrite using https://github.com/xtaci/kcp-go.