It'd be massively overkill for me, so even if it's technically a "good value", it doesn't make sense to buy one if my cluster of $60 thinkcentres is chugging along without an issue (and I get HA).
On the other hand, if you need all that extra performance for something, then it's probably a great buy (hence its popularity here).
Yeah. I briefly explored some other possibilities in the post, including a potential self-hosted option, but ultimately landed on CF as a practical compromise.
Crowdsec does it by using crowd-sourced blocklists (hence the name). So if an IP triggers a scenario on other machines, that malicious address will be proactively added to your blocklist before it ever gets a chance to impact your machine.
That is the big advantage of crowdsec over reactive-only solutions, like fail2ban.
On one hand, hardware is a fundamental aspect of self hosting. There's already a portion of the community who considers self-hosting to include using commercially-hosted cloud services (as long as it's not Google), so prohibiting hardware discussion just reinforces that concept. Plus, it can be really fun to see what creative hardware people come up. I'm pretty sure I posted about my Fediverse server running on a WiFi router here, for example. The focus was on the unusual hardware, but it was also clearly related to self-hosting.
On the other hand, looking at what is posted in other communities, I don't think there's a ton of value in seeing a dozen photos of a bone-stock rpi or a closed laptop sitting on a desk. Same with the nth post asking if their 30-year-old 1u would be a good choice for Jellyfin; so I see why the rule exists.
Overall, though, I think hardware should be allowed, but maybe add a rule along the lines of "if you're posting a question, please include what resources you've already reviewed or troubleshooting steps you've already taken."
Heck, that might be a good rule for all questions, regardless of topic...
I use LOTW because my logging software of choice, Wavelog, can automate most of the process. The only headache is the initial certification, and the process I had to go through to request a new one after accidentally wiping the previous one. I thankfully never have to touch TSQL to submit my QSOs.
I sort of understand the other ham's opinion that "doing it for the other station" might provide motivation to submit logs to a service you don't personally use, but that's less true when the service in question is as poorly implemented as LOTW.
QRZ, while it has some drawbacks, does a great job as an online QSO book. It supports 2FA to secure your account, but requires no extra software or presents barriers to prevent you from adding records to your own logbook once signed in. It also offers a fairly simple API for use with 3rd party software. It can match within its own logs, and will also honor matches imported from LOTW, making it my central "source of truth" for QSL-based awards.
LOTW is a hacky solution in search of a question. Despite its GPG-esque security, it does nothing to prove that a contact actually occurred and I could just as easily submit false records to LOTW as I could any other logbook.
boost seems to use a substring method when filtering, meaning if I add "republic", that blocks any post containing "Republic of congo" or "republican".
It looks like you've got some pretty short words in there, though, like "us" and "oil".
Wouldn't that block things like "boiling spaghetti", "user", "bus", and a ton of other benign words?
Also, for what it's worth, some of the words can be used pretty often in non-political connexts. "Fpv" is "first person view" in RC hobbies, for example, and "jail" is used in BSD-based operating systems.
Really depends.
It'd be massively overkill for me, so even if it's technically a "good value", it doesn't make sense to buy one if my cluster of $60 thinkcentres is chugging along without an issue (and I get HA).
On the other hand, if you need all that extra performance for something, then it's probably a great buy (hence its popularity here).
I use beets to add synced lyrics to my library automatically.
To display them in the web browser interface, click the lyrics button (looks like a book).
Yeah. I briefly explored some other possibilities in the post, including a potential self-hosted option, but ultimately landed on CF as a practical compromise.
I didn't see an obvious link to the source code, so here it is for those interested: https://github.com/Drop-OSS/drop
Crowdsec does it by using crowd-sourced blocklists (hence the name). So if an IP triggers a scenario on other machines, that malicious address will be proactively added to your blocklist before it ever gets a chance to impact your machine.
That is the big advantage of crowdsec over reactive-only solutions, like fail2ban.
Yep.
Never noticed a difference, myself.
The 3DS on the other hand...
https://github.com/zoeyjodon/moonlight-N3DS
What is the advantage of this over just dropping HTML files onto a USB drive?
Not often, but there's a niche. I wish I could remember the details, but I saw someone earlier this year that was hosting a public BBS on a c64.
Same experience. 🫤
Personally, whenever I need to process anything text-based, I use perl.
Read the json into a hash, parse the values if desired, then plug the values into an html template.
It's pretty quick to write, much easier to learn than python (in my opinion), and super powerful.
I'm a bit torn on the hardware bit, myself.
On one hand, hardware is a fundamental aspect of self hosting. There's already a portion of the community who considers self-hosting to include using commercially-hosted cloud services (as long as it's not Google), so prohibiting hardware discussion just reinforces that concept. Plus, it can be really fun to see what creative hardware people come up. I'm pretty sure I posted about my Fediverse server running on a WiFi router here, for example. The focus was on the unusual hardware, but it was also clearly related to self-hosting.
On the other hand, looking at what is posted in other communities, I don't think there's a ton of value in seeing a dozen photos of a bone-stock rpi or a closed laptop sitting on a desk. Same with the nth post asking if their 30-year-old 1u would be a good choice for Jellyfin; so I see why the rule exists.
Overall, though, I think hardware should be allowed, but maybe add a rule along the lines of "if you're posting a question, please include what resources you've already reviewed or troubleshooting steps you've already taken."
Heck, that might be a good rule for all questions, regardless of topic...
The first one. The service is owned by root, but the application is running as an unprivileged system user.
Quadlets work like any other systemd service.
You create the user/group you want to run as on the underlying system, then just specify that user/group in the quadlet file.
If you look at my *arr examples, you can see the user and groups they're running as.
Podman quadlets can also auto-update and auto rollback, if needed.
I use LOTW because my logging software of choice, Wavelog, can automate most of the process. The only headache is the initial certification, and the process I had to go through to request a new one after accidentally wiping the previous one. I thankfully never have to touch TSQL to submit my QSOs.
I sort of understand the other ham's opinion that "doing it for the other station" might provide motivation to submit logs to a service you don't personally use, but that's less true when the service in question is as poorly implemented as LOTW.
QRZ, while it has some drawbacks, does a great job as an online QSO book. It supports 2FA to secure your account, but requires no extra software or presents barriers to prevent you from adding records to your own logbook once signed in. It also offers a fairly simple API for use with 3rd party software. It can match within its own logs, and will also honor matches imported from LOTW, making it my central "source of truth" for QSL-based awards.
LOTW is a hacky solution in search of a question. Despite its GPG-esque security, it does nothing to prove that a contact actually occurred and I could just as easily submit false records to LOTW as I could any other logbook.
Same here.
Pulling doesn't work if you don't know when a system will be online, so it only makes sense for my laptop to push.
Regex would be a nice addition.
Unfortunately, I think Boost is still closed source, so there's little that can be done to improve it.
It looks like you've got some pretty short words in there, though, like "us" and "oil".
Wouldn't that block things like "boiling spaghetti", "user", "bus", and a ton of other benign words?
Also, for what it's worth, some of the words can be used pretty often in non-political connexts. "Fpv" is "first person view" in RC hobbies, for example, and "jail" is used in BSD-based operating systems.
Seems to be specific to rewrites using an un-named capture.
grep -rnE "\$[0-9.*].*\?" /etc/ngnixshould show if you have any potentially vulnerable directives in your config.