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.

Seems to be specific to rewrites using an un-named capture.

grep -rnE "\$[0-9.*].*\?" /etc/ngnix

should show if you have any potentially vulnerable directives in your config.

It’s a function of a “pod” within podman.

I wrote the podman examples for AudioMuseAI using a pod: https://github.com/NeptuneHub/AudioMuse-AI/tree/main/deployment/podman-quadlets

And I have an example *arr suite on my GitHub page: https://github.com/K3CAN/podman-arr-quadlets

I’ll second podman quadlets. Good security, full integration with systemd, pods allow applications to easily share a namespace, and you can manage graphically through Cockpit if you really want to.

The only systems with ip6v in my network are Wi-Fi devices and my public-facing reverse proxy. I use a prefix delegated by my ISP.

All of my non-public servers have ipv4 only.

I use Wireguard.

For my phone, I use the “WG Tunnel” app: https://github.com/wgtunnel/android

It’s nice because it’ll automatically enable/disable it as I move between networks.

Before that, though I used the official client and I just kept it on 24/7. It’s not like it uses extra data or battery or anything.

Correct. Full-upgrade is the new term. It’s an alias, though, so using either will accomplish the same thing.

I’ll second that

Jellyfin can function as a music server, but it’s definitely a video server first. All the other media (music, books, podcasts, etc) are basically still treated like TV shows when it comes to how they need to be rigidly organized.

Navidrome on the other hand, can just take a pile of mp3s and sort everything out based on tags. Navidrome can also handle additional artists, so it can understand that “Eminem feat Elton John” isn’t a single artist. That was ultimately what made me switch from Jellyfin.

Personally, I ripped my CDs to MP3S, and convert anything I downloaded to MP3, as well. I’m no audiophile, so I really can’t tell the difference when listening; the difference is only noticeable when I look at my storage and bandwidth.

I think they just meant as far as user popularity. More people are hearing about Linux thanks to the SD and other SteamOS handhelds. Maybe the SD 2 help show that ARM can play games beyond just emulators?

What is the specific problem?

A dynamic IP address just requires dynamic DNS.

CGNAT and carrier firewalls, on the other hand, will require an alternative entry point. That is, you’ll need a different, externally accessible service that can route requests back to your first server.

They’re accepted, of course, but with the maximum power limit being only 20w, I don’t intend to introduce additional power classes or multipliers.

Another part of trying to make it more accessible is keeping the rules fairly simple. Addressing differences in band/mode limitations with multipliers seemed like a necessary evil, but I’m using the 20w limit to create a somewhat level playing field without adding any additional scoring complexity.

Unfortunately, this also ruled out satellites, which is a favorite of mine, but I think it’s worth it to keep the contest simple.

You can still give it shot! There are significant multipliers for VHF and higher bands to account for the generally more limited range. It’s really intended to be something that every ham can participate in and enjoy.
There’s even an table at the bottom of the “About and Rules” page showing example scoring comparisons between several different band/mode combos.

Cool to hear you’re building a rig, though! Is it a kit? I built a bitx40 several years ago, but it sounds like you’re tackling something a bit more complex. lol