Brickfrog

Yikes, I hadn’t looked into the screen size until you mentioned it. They seem to be going after the XL / tablet size type of devices, exactly the ones that I avoid. Oh well, maybe they’ll eventually release a phone with a more normal screen size closer to 6.3".

A lot of the software targets Ubuntu compatibility so that would be the easy distro choice. But, you should be able to get this stuff running on any/most distros as long as you’re comfortable building/compiling the software as needed. Or using containers like Docker, etc. I doubt you’d have any issue doing this with Mint if that’s your preference.

I’m just tinkering with this stuff so other people here will have way more experience. But as a point of reference I have no trouble running llama.cpp / sd.cpp on current Debian Trixie (with/without an updated Linux Kernel). This is with an AMD R9700 (32 GB VRAM) in an older Intel based system. Everyone says that running with Vulkan is faster but I’ve found it’s good to test your own setup - My overall inference speed is actually faster using ROCm. ROCm gives me less tokens per second but for whatever reason the RAM-VRAM operations are much faster when using ROCm which leads to the overall time from prompt to result being shorter. There’s likely more tweaking I could try to get more speed but I’m not heavily using AI at the moment so am happy with how it works now.

Before that had the same setup with a old Nvidia gaming GPU (6 GB VRAM), it sort of worked but was slow as hell and I could only get it to run with Vulkan. That GPU supported an older CUDA version (7.5 I think) and I never figured out how to get that working with llama.cpp + Nvidia software + Debian.

Is there a set up where some remote service handles email exchange, and you just sync with it eg through POP style interfaces?

Yup, that’s signing up for a email provider. I wouldn’t call that self hosting since you’re just referring to email client software on your end to store the emails that are being synchronized at the email provider’s hosted server(s).

IMAP is sync so that might be what you meant. POP is even older but that’s for downloading only. And SMTP is for sending.

Those all still exist, most paid email providers still offer them just make sure to check before signing up. It’s harder to find that with free email providers, they usually disable IMAP/POP/SMTP on free accounts.

I’m definitely in the thinking with others that keep admin/privileged and normal users separate. I kind of look at it as a way to minimize fallout from any unexpected security compromises. Will always do my best to prevent/avoid that, but if it happens it better happen on a non-privileged account.

But the downside is it can be quite inconvenient, especially if I need to administer or debug something quickly.

A bit, but I don’t find that to be too cumbersome. The initial setup period yeah, you’re constantly jumping into admin mode, but once things are configured and settled down you hopefully don’t need to jump into admin mode often.

I’m also not sure if my homelab expands, should I share the admin user credentials with other human admins or not.

That’s a fair question and it depends on the service(s) really. I don’t know what the general consensus is on that but I’d say that other admins should have their own separate admin account and user account (e.g. call it “joe” and “joe_admin” or whatever). Sharing credentials, especially admin credentials, seems like its own security risk. But I also get that sometimes it’s simply not possible to maintain multiple admin accounts and you just have to do the best you can.