There are multiple GH issues around better sync.Map. Among other alternatives, xsync.Map is also mentioned. But Golang core team doesn't seem interested in sync.Map (or a generic variant of it) improvements.
Gaseous form is a problem, but have you seen the Fraunhofer POWERPASTE? I was optimistic when the news was first announced, but that was a decade ago and of course it's not widely used.
Clearing of the secrets is a separate issue from memory allocation mechanism. It must be done all the way from the encryption layer to the program to avoid the leaks.
This is typically not done, only certain parts such as handling of the crypto keys. That's because it's pervasive and requires reworking everything with that in mind (TLS library, web framework, application).
On the other hand the centralization and global usage of GC in the process allows to modify it to always zero out the memory that it deallocated and to do GC at regular intervals so it can have advantage here (it's very easy to inadvertly leak the secrets to some string).
You can see the spirit of what they're going for also with the MIT binaries - that's also like saying the whole project is AGPL, but a loosening for using it as-is.
Given their goals seem to be
- Permissive use without modification, even in combined works ("MIT binaries"); but
- Copyleft with modification, including for the Affero "network hole", or commercial terms
could you suggest a clearer license option? AGPL triggers copyleft across combined works, LGPL doesn't cover the network hole, GPL has both problems. Their goals seem really reasonable, honestly, there should be a simple answer. It seems messy but I like it more than the SSPL/BSL/other neo-licenses.
I don't know anything more reasonable, but I would argue that this (isn't) reasonable precisely because it causes so much confusion due to the ambiguity and their refusal to clarify exactly what the terms really are.
Dokku user for a decade here, congrats on shipping, love to see more self-hosted PaaS options like this.
Why are binaries checked into the bin/ directory in the repo?
Compared to Dokku, I like how your LE support is builtin instead of a plugin. Is your main www ingress server an nginx that gets externally configured (like Dokku) or are you using net/http or libcaddy directly?
Dokku has a history of trying to compete with Heroku buildpacks - as a non Heroku/non Ruby developer this never resonated with me and there are a lot of vestigal parts (e.g. .web.1) that i would just put in my own Dockerfile directly. So focusing solely on Dockerfiles i personally feel is a good move.
One issue i faced with Dokku is eventually the build process for my Dockerized app was too memory-intensive to run on the VPS. I switched to running docker build locally, sending the container via `docker export | ssh | docker import`, and having a single `FROM myapp` dockerfile in Dokku. This was not particularly ergonomic to set up. Is it possible you can improve the UX of client-side built containers, or will you focus solely on the GitOps deploy?
The binaries are for local testing for now, the actual binaries are built on the server/VPS on installation, we are planning to distribute single binaries in future.
The reverse proxy + TLS is Handled by traefik running in a docker container itself, we chose traefik because of the automatic docker label based dynamic routing, I hope we don't need to switch to something else anytime soon .
We have plans for remote/local builds using a small docker registry instance on the server/VPS to eliminate the need of any external registry
There are a bunch of reddit users leaving reddit comments but I'm not seeing any info from reputable sources. As of now no public commentators seem to know what these keys are truly for - I'm sure whoever extracted them knows so we'll have to wait to find out...
WSL2 distros only use Linux namespaces, same as docker, and the WSL2 --system distro can see PIDs from all running WSL2 distros.