What I might consider is a “winterized” variable per hose/pipe that may be a concern, and only notify if winterized is false for those, and have the notification list specifically not winterized.

That state would be manual per, but then you would be able to get a more meaningful reminder to only those that would be at risk.

No worries!

Because it creates an OT discussion and the tag doesn’t apply. A discussion I won’t necessarily know about until after its gone on and gotten heated.

Comments aren’t for rule policing, just use the report button please.

Italics = fixed crappy autocorrect. Be a use? Wtf.

Up until the point the resources available (CPU/ram/storage) become a problem.

That said, managing those apps as installations can be troublesome, which is why people like podman/docker. Updates are more contained, system updates don’t break services, and vice-versa.

A more comprehensive option is to use Proxmox or similar to manage services as a combination of Virtual Machines, LXC’S (Linux containers), and maybe podman/docker on a VM. Note that Proxmox techincally supports importing a docker container as an LXC, but this is a one-time action. Not recommended. (EDIT: For the record, there is a Proxmox on pi effort, but its community supported not Proxmox supported as of the last time I looked.)

Navidrome and pihole are the easy ones on that list also. Jellyfin itself is easy, but you aren’t going to be transcoding video on the fly, so make sure its in a format that is friendly to all of your devices, transcoding in advance if needed.

I’d sum it up with:

“Ew.”

Its one thing to offer bespoke customization for businesses. Its entirely another to work to prevent any indication that the software is being run by someone other than the creator of the software. IMO, it goes against self hosting as a practice.

It could be everything I want and more, and it would immediately turn me away. Which, in turn, would also turn me away from recommending it to others, including businesses.

I’d call it a pretty bad strategy.

Secure enough I suppose.

f2b at the FW, auth with MFA for anything exposed, anything local only has restricted access at the FW level, with exposed (via proxy) and local-only (separate proxy) on different vlans. Each service is (typically, with some exceptions) an LXC, with additional rules and templated out based on use case. The few cases where docker is involved is local-only and that has its own vlan with additional rules.

rclone crypt

Aside from “local model”, you might see things like whisper.cpp, llama.cpp, ollama, or “OpenAI compatible endpoint”, or a reference to getting models from HuggingFace (you can think of it like github for llm’s - its more and less, but accurate enough for what we’re talking about here).

whisper.cpp is a c++ implementation of whisper (ASR as mentioned), llama.cpp is a high performance and lightweight tool to support llm/llm inference, ollama is a very user friendly way to do the same, and OpenAI compatible endpoint is just using the protocol for communication, so you can point the client at llama.cpp or similar running on the same machine or another you have access to.

Most things with an extemely tight purpose like this (like listening for some birds singing) will use much leaner models, and may be able to run even from a phone.

Audio processing by ai can absolutely happen on a pi.

As an example, whisper.cpp is a high performance speech recognition model, and it does a great job. The biggest version of it as a model requires less than 5GB to live fully in memory, the large model at about 1.5billion parameters, and it works great even CPU only.

The one used most often is small, which has about 244million parameters, and needs about a gig of ram and nothing more.

For a pi 5, usually the base or tiny model are used. Small could be used in most scenarios, but tiny and base are able to run real-time.

So it depends for how local - sometimes its all self contained and can do just fine on a pi, sometimes its local in that it needs an LLM endpoint to hit, but that can be running on another system entirely.

It would really depend on the project for how/where/why for a definition of local.

Feedback or questions is appropriate. We don’t need to come in abrasive, and you didn’t need chatgpt to ask a followup, so we don’t need to be antagonistic.

Choosy self-hosters choose Debian.

That said, I don’t recommend hosting software at the bare metal level - use VMs or containers. Far easier to manage and isolate.