What the top commenter probably failed to mention, and jensneuse tried to explain is that sync.Pool makes an assumption that the size cost of pooled items are similar. If you are pooling buffers (eg: []byte) or any other type with backing memory which during use can/will grow beyond their initial capacity, can lead to a scenario where backing arrays which have grown to MB capacities are returned by the pool to be used for a few KB, and the KB buffers are returned to high memory jobs which in turn grow the backing arrays to MB and return to the pool.
If that's the case, it's usually better to have non-global pools, pool ranges, drop things after a certain capacity, etc.:
Yes, when using Alpine in a container context you're getting the "MINI ROOT FILESYSTEM" [1] experience; the parity differences are in the kernel (they're easily ""fixable"" and the team is open to enabling things that people actually use, I've opened such issues on their GitLab and they're very active and friendly)
Alpine is a solid distro for servers from my experience.
The only bad experiences I've had with it, come from the lack of parity between the x86_64 and aarch64 virt images. So our x86_64 setup doesn't work without building our own image with kernel params and addons. Even ZFS I don't think is built into the virt-aarch64 image.
All in all, I would recommend more devs/sysadmins to try alpine outside the container world, and run it in test VMs, host servers, etc.
Currently migrating from it (not writing any new files to it), but keeping it for read/shared files. The migration plan is to eventually move everything to a DS923 (Synology), with most files being mirrored on client machines and weekly offsite backups (encrypted). Would like something off-continent eventually but haven't given it any thought.
I cannot possibly trust Nextcloud again. I was very skeptical to begin with, because it's a rather large and complex project built on PHP over many years (call this a personal/subjective view). But what really made my decision was when they broke the ability to delete (and/or modify) encrypted files. [0]
For caching the query results you get from your database. Also it's easier to spin up Redis and replicate it closer to your user than doing that with your main database. From my experience anyway.
I also only have Caddy running locally to proxy different dev environments and serve certain files, and it is an exceptional tool, but I would never deploy it in production:
1) Nginx configs are (from my experience) easier to template (in our Nomad & Consul cluster architecture)
2) From what I could gather, Nginx is more stable and performant
3) I don’t trust Caddy’s codebase security. It simply has too many dependencies, and Go makes it very easy to get into dependency hell
Honestly if 3) wouldn’t be an issue, and stability from 2) would be proven, I would probably give Caddy a try in production.
Ok, I'll have to look more in-depth into the Microsoft link, they link to many more pages including a whitepaper.
Regarding all the blockchain centric DID methods, would someone wanting to validate a DID (eg: did:thecoin:whatever_would_go_here), need to hold a copy of the blockchain? (in a scenario where one doesn't want to be dependent on a third party for blockchain interactions).
I was initially pretty hyped when I read the abstract for DIDs, bookmarked the spec and read it later. The "spec" is a bunch of buzzwords and vague generic "concepts". The DIDs themselves mean basically nothing, it's the "methods" that actually must have their own specification and actually "do something".
Another feeling you can quickly get from DIDs is that they're blockchain centric.
The entire concept is "jack of all trades, master of none". I actually hope to be wrong, and see some more fully fledged implementations/examples of real world use-cases, because I love the idea of federated/decentralized identity.
IANAL, but shouldn't a data deletion request also apply to the data inside backups, even when no recovery is planned?
Edit: I am also skeptical about the logs part, I don't think logs can be a magical excuse to log everything that comes in, and should still only log "legitimate" use-cases.
I wouldn't throw Jetbrains in the same boat. I quite like their pricing model. You get to keep the last version, so you're basically paying for updates in the end (which are worth it IMO). On top of that, you get a discount after the first year.
If that's the case, it's usually better to have non-global pools, pool ranges, drop things after a certain capacity, etc.:
https://github.com/golang/go/issues/23199 https://github.com/golang/go/blob/7e394a2/src/net/http/h2_bu...