Well, at least thy were trying, whil other archtiects just use the rnd() function for placement:
Spoiler

Well, at least thy were trying, whil other archtiects just use the rnd() function for placement:

actually it is already meged and on v16.0 milestone list
I definitively also observe the recent increase of spam (mostly on info@domain) however spamassassin (after some training) does a decent job sorting the trash out. Also I use a unique email address for each website I register, this way a lot of spam was removed by blocking an email-address I’ve used for login to facebook 10 years ago.


Never got warm with all the UIs available. But things change very fast on that front. For me it looks like that they only differ by the time it takes to provide support for the newest headscale version. Just take the one supporting yours :) For SSO , the OIDC provider from Nextcloud is working as good as any other. Having some kind of static IP also helps but the headscale server runs on HTTPS port plus some optional ones (not sure if I remember correctly) dynamic dns should be ok as well.


Yes… sry wasn’t clear about that…


My two cents: Hugo+HTTP-Server should perform better when confronted with all the AI crawler bots as only a static site is served. Lemmy or Pifed is diffrent in that aspect. For small blogs it shouldn’t matter (jet)…


did it one 8-Months ago or so…just works… like black magic. Fire and forget VPN (But SSO is a must in my opinion otherwise key exchange is too tideous ) I did it about 8 months ago… it just works like black magic. It’s a “fire and forget” VPN, but SSO is a must in my opinion; otherwise, key exchange is too tedious.


Cool, also like the style of the blog, however the “Loading…” animation is kind a strange. It lasts almost 2sec , while the page data is completely loaded after 500ms or so.


I absolutely feel your pain. However, there is also the side that all this complexity must be handled somehow. The other extreme is that you’d have to compile all the software and its dependencies from scratch, as well as read and understand the source code.
In the end, it boils down to the people who actually care (like you, who is probably one of them) to exercise caution—looking at the output of curl https://some.rando.url/install.sh before doing the | sudo bash -c and constantly insisting on the validity and absolute necessity of signature checks, transparency, and so on.
Meanwhile, all the other folks get at least a foothold in self-sovereignty without being completely smashed by the details of compiler flags.


All these speeds the providers advertise (especially the faster ones) are often cut down by bad peering. I often had an issue downloading bigger files from my storage when I was traveling. Only got some single digit MBit transfer speeds due to bad peering, while speed tests has shown decent results. When it comes down to Selfhosting the upload/download figures alone not always tell the truth. In my point of view 20Mbps is actually even sufficient for most of private stuff, even streaming HD content to one ore two peers simultaneously.


I will say, these days, anything less than 10/10 is criminal. 20/20 is slow but manageable. 30/30 is more than most normal people realistically need,
… till the start torrenting


Unless you’ve been arrested and are in pretrial detention without access to any devices that would allow you to do that. But in that case, the Arr stack on your server is probably the least of your problems.
Yes, this would work — but it comes with a subtle statistical bias: the character ‘W’ ends up underrepresented. With a naïve “avoid COW” approach, only about 25% of the grid will typically be ‘W’.
A more elegant solution would be:
That keeps the distribution much closer to uniform while still guaranteeing a valid puzzle. Then just insert the single “COW” manually wherever you want the hidden solution to be.
Julia code example
The neat part is that this preserves an almost perfectly balanced character frequency.
For comparison, the puzzle in the example image seems to contain roughly:
C: ~260 (~25%) O: ~520 (~50%) W: ~244 (~25%)
So the original author clearly used a different generation strategy.
Possibly on purpose: visually, ‘C’ and ‘O’ are much easier to confuse than ‘W’. Reducing the number of 'W’s therefore increases the search difficulty. In that sense, the approach suggested by @Snazz@lemmy.world is probably preferable: keep the distribution mostly balanced, but intentionally bias it just enough to make the puzzle psychologically annoying.
I wonder if there is a non iterative way to generate this puzzle with a ‘uniform’ character distribution 🤔