Yeah, YunoHost explains why http://localhost:8536/ wouldn’t be working. If cloudflared and Lemmy are in separate containers you have to put an actual IP in, since localhost points to the container itself.

How are you accessing it without Cloudflare? How do you know that Lemmy is actually listening?

What’s the URL you using to access it without Cloudflare?

Edit: Also that curl tells me it’s not listening on that IP/port.

Can you access it without Cloudflare?

Does curl http://localhost:8536/ work?

You are using cloudflared right? Because normal (non-cloudflared) Cloudflare doesn’t support port 8536.

With dynamic DNS? Yeah it always has, as long as you can host a http server.

With a dynamic IP? It should do, the certs are only valid for 6 days for that reason.

You can host a page with an iframe, but you can’t directly change the DNS record to point to something that isn’t GitHub.

Perhaps there was an easier lighter-weight way of doing this?

Yeah, SSH tunneling. What I would do (and have done in the past) is something like:

ssh -L 8080:192.168.0.1:80 myserver

That will forward port 8080 on your host to port 80 on 192.168.0.1, so you can access your router’s web UI with http://localhost:8080/ in your own web browser.

You can also setup full tunneling with SSH, but that requires messing around with SOCKS and I usually can’t be bothered.

Ahh sorry, I thought you meant you plugged it into the input side. If that’s the case then are you running anything that measures CPU usage? I run the TIG stack, it might be able to give you some hits. Also back to my original point which is already unlikely, if it’s a modified sinewave UPS, it can confuse some measuring devices while it’s on battery.

It’s weird to do this daily, but it’s possible that the UPS is doing a self test, which would drain the battery a little and the load is from charging it back up.

You have to be on the March update, then go to Developer options -> Linux environment, and enable it. Then ‘Terminal’ will appear in your apps drawer.

TCP and UDP can listen on the same port, DNS is a great example of such. You’d generally need it to be part of the same process as ports are generally bound to the same process

They don’t even need to be the same process. I’m pretty sure that’s just a common practice if something needs both protocols, but there’s nothing stopping you from having a web server on TCP 443 and a VPN server on UDP 443. Ports are an abstraction brought by each protocol, they aren’t in anyway related.

There’s The Serial Port, It’s not really ‘home networks’, but he finds and sets up very early (~80-90s) ISP gear and explains how it works and the history of it. Similar to how Ben Eater uses an ‘old’ 6502 to explain stuff.

I have no idea how CoW interacts with NTFS

With btrfs you can disable COW for specific files, that might give you a little performance boost.

Cloudflare tunnels uses a QUIC connection between the cloudflared on the server and Cloudflare itself, which is encrypted similarly to HTTPS.

Whatever protocol cloudflared uses to talk to your webserver locally is configurable through the Cloudflare access web UI (just change http to https). I’ve actually got it configured to use unix sockets, which lets me treat it differently in my nginx config.

IIRC the RTL chip inside them was originally designed for TV, so it works great! I’m actually using very cheap AliExpress clones for the TV ones, because they otherwise don’t work very well.

I’m also using the outdoor TV antenna on my roof (common in Australia, idk elsewhere), and a splitter and adaptors. And with that I get every channel with no artifacts, at 30% strength, but that’ll probably be higher with not awful SDRs.

I’ve got an interesting setup I’d like to share:

So I’ve got a Raspberry Pi with 4 RTL-SDRs, 2 for TV, 1 for radio, and 1 for plane transponders. That runs SatPi for the 2 TV SDRs, which TVHeadend running on my main server connects to, to record and stream. Jellyfin also connects to TVHeadend to properly index everything and for easy access to recordings and live TV.

Looks like 2x 4 pin fan headers:

But yeah I’ve got an AliExpress X99 board, which threw all sorts of hardware errors, had no fan speed control (100% all the time), no working hwmon sensors, and I ended up buying a used Supermicro board instead.

Will I see any performance increase?

Like others have said LLMs mostly use VRAM, they can use system RAM if you’re running them on CPU, but that’s ridiculously slow.

It will however increase the speed of your compile times, which is especially useful if you’re compiling something large like the Linux kernel on a regular basis.

I’m also worried about not having ECC RAM.

If you are using it purely for LLMs, if it’s going to get bit flips, it’ll happen in VRAM.

If you are compiling large things for customers, I’d recommend ECC, just in case, e.g. you don’t want a bricking firmware from a bit flip. But according to EDAC and my TIG stack, my server’s ECC RAM has never even detected an error in the past year, if I understand EDAC properly, so it’s really not important.

If the HOA’s router supports UPnP/NAT-PMP/PCP then you might be able to use that to get some ports forwarded.

I have also added all Cloudflare IPs in Jellyfin’s known proxies

You should only need to add the IP of the last proxy before reaching Jellyfin, which would be Caddy.