cplli
Joined 6 years ago
Karma
161
Submissions
39
Member since
Mar 2
[ my public key: https://keybase.io/cpl_li; my proof: https://keybase.io/cpl_li/sigs/wzG33fiFpJEyDvpEMDIwdvAMbczxCtVW6JY-ovgV494 ]
View on Hacker NewsRecent submissions
Comment · 1 year ago
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.:
https://github.com/golang/go/issues/23199 https://github.com/golang/go/blob/7e394a2/src/net/http/h2_bu...
Comment · 2 years ago
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)
Comment · 2 years ago
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.
Comment · 3 years ago
Don’t forget to update your regex appropriately (/s hopefully)
Comment · 3 years ago
First thing that comes to mind is an overhaul mod for OpenTTD which has a "Steeltown" economy that resembles the AIST Steel Wheel.
Comment · 3 years ago
Threads are Phase 3
https://github.com/WebAssembly/proposals
You can also check out:
https://webassembly.org/roadmap/
And for Go, the proposal project on Github has many interesting conversations from the devs.
And as a reminder to anyone interested in using Go WASM, it’s experimental and does not come with the same compatibility promise as Go itself:
Comment · 3 years ago
Personally tried it, it can handle logs nicely. And from their page, many more things
Comment · 3 years ago
Now we need a tool called NeighbourhoodWatch to monitor the cluster monitors.
Comment · 3 years ago
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.
Comment · 3 years ago
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]
Comment · 3 years ago
Someone will definitely get 42.zip or 42kb.zip just to host a “zip bomb as a service”.
On a more serious note, new gTLDs are so spammy, and “.zip” as others have mentioned will surely lead to some surprises somewhere.
Comment · 3 years ago
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.
Comment · 4 years ago
An article on a site that has a cookie banner the size of my mobile screen :)
Comment · 4 years ago
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.