ppp_thing VS go-plugin

I wrote a PPPoE client with failover so I can keep the session even when one of my gateways fails or is rebooted (this lets me do regular maintenance without interrupting my internet connection); I put it on github[1], but I doubt anyone will use it. I hope there are few people left with the scourge that is PPPoE, and my OS choice means many people would need to switch OSes to use it, so yeah. Also, I don't care to make it easy to use or to promote it, really. (I've mentioned it once or twice and did a Show HN that got less than ten votes, which I kind of expected).

I've also got my personal (network) monitoring software, some 'IoT' stuff to capture temperature and humidity data around my house, and I'm working on a ESP32 based alarm clock pulling data from iCalendar.

[1] https://github.com/russor/ppp_thing

I just published https://github.com/russor/ppp_thing which lets me (and maybe you) failover my PPPoE session between two FreeBSD hosts, so I can do regular maintenance without losing my IP or impacting TCP sessions.

I used to let my DSL modem handle PPPoE and NAT, so failover was easy, but found out fragmented IPv6 crashed the leased modem, and the replacement modem also sucks, so bridge mode + a custom PPPoE client (but from netgraph pieces) it is. Sadly useful in 2021, because PPPoE is somehow still a thing.

I am looking forward to a mix of both - I am hoping to add a concept called "operator" which would be a go-plugin [1], just like terraform providers, but build backends. So, someone would be able to, say, write a Slack plugin (in Go, or anything over RPC) which sends a message once a build is complete - like Jenkins/GitHub actions, or just scripts that we can reuse like GitLab CI through `modules`.

Perhaps a new registry where we can push custom modules and providers (operators in this case), I'm curious to know about if we have any existing implementations we could reuse for the registry.

[1]: https://github.com/hashicorp/go-plugin

I'd recommend looking into a different approach for plugins such as hashicorp/go-plugin (which uses multiple process PIDs and RPC communication between them) or traefik/yaegi (which implements a Go-compatible scripting language that can be interpreted at runtime and which still supports most Go modules).

You'll never fully protect your code from someone who's dead-set on reverse-engineering it, however, you can use https://github.com/hashicorp/go-plugin or a similar RPC technique, which will let you ship binary plugins and will also be less fragile and janky compared to something made with `-buildmode=plugin`.

The plugin system that hashicorp uses for all their projects works very well. It's essentially a local RPC implementation. https://github.com/hashicorp/go-plugin

The leader is almost for certain https://github.com/hashicorp/go-plugin which uses RPC. This prevents some of the binary compatibility issues from the standard library option, operating system issues from the standard library option, and it is in use by lots of large projects from Terraform to Packer, Nomad, and Vault.

can you try older go-plugin versions? The only major change in v1.4.4 was a bugfix for automtls. https://github.com/hashicorp/go-plugin/blob/master/CHANGELOG.md